PagerDuty, ຫຼືເປັນຫຍັງພະແນກປະຕິບັດງານບໍ່ສາມາດນອນໃນຕອນກາງຄືນ

ລະບົບສະລັບສັບຊ້ອນຫຼາຍ, ມັນຈະກາຍເປັນ overgrown ກັບທຸກປະເພດຂອງການແຈ້ງເຕືອນ. ແລະມີຄວາມຕ້ອງການທີ່ຈະຕອບໂຕ້ກັບການແຈ້ງເຕືອນດຽວກັນນີ້, ລວບລວມພວກມັນແລະເບິ່ງເຫັນພວກມັນ. ຂ້າພະເຈົ້າຄິດວ່ານີ້ແມ່ນສະຖານະການທີ່ຄຸ້ນເຄີຍກັບຫຼາຍຄົນຈົນເຖິງຈຸດປະສາດ.

ການແກ້ໄຂທີ່ຈະໄດ້ຮັບການປຶກສາຫາລືບໍ່ແມ່ນສິ່ງທີ່ບໍ່ຄາດຄິດທີ່ສຸດ, ແຕ່ການຄົ້ນຫາບໍ່ໄດ້ກັບຄືນບົດຄວາມເຕັມທີ່ກ່ຽວກັບຫົວຂໍ້ນີ້.

ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈທີ່ຈະແບ່ງປັນປະສົບການຂອງ FunCorp ແລະສົນທະນາກ່ຽວກັບວິທີການປະຕິບັດຫນ້າທີ່ມີໂຄງສ້າງ, ໃຜໂທຫາ, ເປັນຫຍັງແລະວິທີທີ່ເຈົ້າສາມາດເບິ່ງທັງຫມົດ.

PagerDuty ແມ່ນຫຍັງ?

ດັ່ງນັ້ນ, ເພື່ອແກ້ໄຂບັນຫາເຫຼົ່ານີ້ທັງຫມົດ, ພວກເຮົາເລີ່ມຊອກຫາເຄື່ອງມືທີ່ສະດວກ. ຫຼັງຈາກການຊອກຫາບາງຢ່າງ, ພວກເຮົາເລືອກ PagerDuty. PD ເບິ່ງຄືວ່າພວກເຮົາເປັນການແກ້ໄຂທີ່ຂ້ອນຂ້າງຄົບຖ້ວນແລະຊັດເຈນດ້ວຍການປະສົມປະສານແລະການຕັ້ງຄ່າຈໍານວນຫລາຍ. ນາງເປັນແນວໃດ?

ໃນສັ້ນ, PagerDuty ເປັນແພລະຕະຟອມການປະມວນຜົນເຫດການທີ່ສາມາດປະມວນຜົນເຫດການທີ່ເຂົ້າມາໂດຍຜ່ານການປະສົມປະສານຕ່າງໆ, ກໍານົດຄໍາສັ່ງຂອງຫນ້າທີ່ແລະຫຼັງຈາກນັ້ນເຕືອນວິສະວະກອນໃນຫນ້າທີ່ຂຶ້ນກັບລະດັບຂອງເຫດການ (ໃນລະດັບສູງ - ໂທ, ໃນລະດັບຕ່ໍາ - ການ​ຊຸກ​ຍູ້​ຈາກ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ / SMS​)​.

ໃຜເປັນເຈົ້າໜ້າທີ່?

ນີ້ອາດຈະເປັນບ່ອນທໍາອິດທີ່ຈະເລີ່ມຕົ້ນການຕັ້ງຄ່າ PD.

ຢູ່ FunCorp, ຄືກັນກັບບໍລິສັດອື່ນໆ, ມີຕໍາແໜ່ງກຽດຕິຍົດຂອງເຈົ້າຫນ້າທີ່. ມັນໄດ້ຖືກຖ່າຍທອດຈາກວິສະວະກອນໄປຫາວິສະວະກອນຫນຶ່ງຄັ້ງຕໍ່ມື້. ມີອັນທີ່ເອີ້ນວ່າເສັ້ນທໍາອິດແລະທີສອງຂອງການຕອບສະຫນອງຕໍ່ການແຈ້ງເຕືອນຈາກ PagerDuty. ສົມມຸດວ່າການແຈ້ງເຕືອນທີ່ມີຄວາມສໍາຄັນສູງມາຮອດ, ແລະຖ້າ 10 ນາທີຫຼັງຈາກໂທຫາເຈົ້າຫນ້າທີ່ຈາກສາຍທໍາອິດບໍ່ມີປະຕິກິລິຍາກັບມັນ (i. ວິສະວະກອນຫນ້າທີ່. ນີ້ແມ່ນການຕັ້ງຄ່າໃນ PagerDuty ຕົວຂອງມັນເອງໂດຍຜ່ານນະໂຍບາຍການເພີ່ມຂື້ນ.

ຖ້າເຈົ້າໜ້າທີທີ່ສອງບໍ່ຕອບສະໜອງ, ແຈ້ງການຈະກັບຄືນມາ ຫຼັກ ຕໍ່​ເຈົ້າ​ໜ້າ​ທີ່.

ດັ່ງນັ້ນ, ການແຈ້ງເຕືອນບູລິມະສິດສູງໃດໆທີ່ເຂົ້າມາບໍ່ສາມາດຍັງຄົງບໍ່ໄດ້ຮັບການປຸງແຕ່ງ. 

ບັດ​ນີ້​ເຮົາ​ມາ​ເບິ່ງ​ວ່າ​ເຫດ​ການ​ຈະ​ມາ​ຈາກ​ໃສ.

ພວກເຮົາໃຊ້ການເຊື່ອມໂຍງແນວໃດ?

PD ໄດ້ຮັບເຫດການທີ່ແຕກຕ່າງກັນຫຼາຍຈາກການບໍລິການຕ່າງໆ. ໃນປັດຈຸບັນພວກເຮົາມີປະມານ 25 ບໍລິການດັ່ງກ່າວ, ແລະເພື່ອປະມວນຜົນພວກມັນ, ພວກເຮົາໃຊ້ບາງການປະສົມປະສານທີ່ກຽມພ້ອມ.

• Prometheus

ລະບົບການເກັບລວບລວມ metrics ຕົ້ນຕໍແມ່ນ Prometheus. ຫຼາຍໆຢ່າງໄດ້ຖືກຂຽນໄວ້ແລ້ວກ່ຽວກັບມັນຢູ່ໃນHabre, ຂ້ອຍຈະເວົ້າວ່າພວກເຮົາມີຫຼາຍໆອັນສໍາລັບສະພາບແວດລ້ອມທີ່ແຕກຕ່າງກັນ: ຫນຶ່ງເກັບກໍາ metrics ຈາກເຄື່ອງ virtual ແລະ dockers, ອີກອັນຫນຶ່ງຈາກບໍລິການ Amazon, ອັນທີສາມຈາກເຄື່ອງຮາດແວ. Telegraf ສ່ວນໃຫຍ່ແມ່ນໃຊ້ເປັນຜູ້ສົ່ງອອກ metrics.

• Email

ນີ້ເຊັ່ນດຽວກັນ, ຂ້າພະເຈົ້າຄິດວ່າ, ທຸກສິ່ງທຸກຢ່າງແມ່ນຈະແຈ້ງຈາກຫົວຂໍ້. ການປະສົມປະສານນີ້ຖືກນໍາໃຊ້ເພື່ອສົ່ງການແຈ້ງເຕືອນຈາກບາງສະຄິບທີ່ດໍາເນີນການໂດຍ cron. PD ໃຫ້ເຈົ້າທີ່ຢູ່ທີ່ແນ່ນອນທີ່ທ່ານສົ່ງຈົດຫມາຍ. ເມື່ອສ້າງການບໍລິການທີ່ມີການປະສົມປະສານດັ່ງກ່າວ, ທ່ານສາມາດກໍານົດບູລິມະສິດ, ໃນສິ່ງທີ່ຄໍາສັ່ງເຂົ້າມາຈະດໍາເນີນການ, ວິທີການສ້າງການແຈ້ງເຕືອນ (ສໍາລັບແຕ່ລະຈົດຫມາຍຂາເຂົ້າ, ສໍາລັບຈົດຫມາຍຂາເຂົ້າ + ກົດລະບຽບທີ່ແນ່ນອນ, ແລະອື່ນໆ).

• slack

ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ການເຊື່ອມໂຍງທີ່ຫນ້າສົນໃຈຫຼາຍ. ມີບາງຄັ້ງທີ່ບາງສິ່ງບາງຢ່າງເກີດຂຶ້ນແຕ່ບໍ່ໄດ້ກວມເອົາໂດຍເຫດການ. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ເພີ່ມການເຊື່ອມໂຍງຈາກ Slack ເພື່ອສ້າງເຫດການ. ນັ້ນແມ່ນ, ທ່ານສາມາດຂຽນໄປຫາບໍລິສັດ Slack /callofduty ທຸກສິ່ງທຸກຢ່າງແມ່ນຊ້າແລະຈະແຕກໃນໄວໆນີ້ ແລະ PD ຈະປຸງແຕ່ງມັນແລະສົ່ງເຫດການໄປຫາວິສະວະກອນທີ່ຮັບຜິດຊອບ.

ເຮົາ​ເຮັດ:

ພວກເຮົາເບິ່ງ:

• API

ການເຊື່ອມໂຍງ HTTP. ໃນຄວາມເປັນຈິງ, ບໍ່ມີຫຍັງທີ່ຫນ້າສົນໃຈໂດຍສະເພາະຢູ່ທີ່ນີ້, ພຽງແຕ່ຄໍາຮ້ອງຂໍ POST ທີ່ມີເນື້ອໃນໃນຮູບແບບ JSON. ຕົວຢ່າງ, ບາງສິ່ງບາງຢ່າງທີ່ຫນ້າສົນໃຈ: ພວກເຮົາໃຊ້ມັນສໍາລັບການກວດສອບພາຍນອກໂດຍໃຊ້ https://www.statuscake.com/. ບໍລິການນີ້ກວດສອບການເຂົ້າເຖິງຂອງສະຖານທີ່ຂອງພວກເຮົາຈາກພາກສ່ວນຕ່າງໆຂອງໂລກ. ໃນກໍລະນີທີ່ພວກເຮົາໄດ້ຮັບລະຫັດຕອບສະຫນອງທີ່ບໍ່ສາມາດຍອມຮັບໄດ້ (ຕົວຢ່າງ, 502), ເຫດການຖືກສ້າງຂື້ນແລະຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງປະຕິບັດຕາມລະບົບຕ່ອງໂສ້ທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ. StatusCake ຕົວຂອງມັນເອງມີຄວາມສາມາດໃນການຕິດຕາມ URL ພາຍໃນ, ໃບຢັ້ງຢືນ SSL ຫຼືການຫມົດອາຍຸຂອງໂດເມນ.

• LibreNMS

ນີ້ແມ່ນລະບົບການຕິດຕາມອື່ນ, ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບມັນຢູ່ໃນເວັບໄຊທ໌ຂອງພວກເຂົາ https://www.librenms.org/. ດ້ວຍການຊ່ວຍເຫຼືອຂອງມັນ, ພວກເຮົາຕິດຕາມການໂຕ້ຕອບເຄືອຂ່າຍ ແລະ iDRAC ຈາກເຊີບເວີ.

ນອກຈາກນີ້ຍັງມີການເຊື່ອມໂຍງເຊັ່ນ Datadog, CloudWatch. ທ່ານສາມາດເບິ່ງເພີ່ມເຕີມກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນກັບເຂົາເຈົ້າ right here.

ການເບິ່ງເຫັນ

ລະບົບລາຍງານເຫດການຕົ້ນຕໍແມ່ນ Slack. ເຫດການທັງຫມົດທີ່ມາຮອດ PD ຈະຖືກຂຽນໄວ້ໃນການສົນທະນາພິເສດ, ແລະຖ້າສະຖານະພາບຂອງພວກເຂົາມີການປ່ຽນແປງ, ນີ້ຈະຖືກສະແດງຢູ່ໃນການສົນທະນາເຊັ່ນກັນ.

ເມື່ອມີໂອກາດທີ່ຈະສະແດງຂໍ້ມູນທີ່ເປັນປະໂຫຍດໃນຫນ້າຈໍຂອງຈໍສະແດງຜົນທີ່ຫ້ອຍຈາກເພດານ, ພວກເຮົາທັນທີທັນໃດຮູ້ວ່າພວກເຮົາ (ໃນພະແນກ devops) ບໍ່ມີຫຍັງທີ່ຈະສະແດງຢູ່ໃນພວກມັນ. ມີ Grafana ທີ່ປະເສີດ, ແຕ່ມັນບໍ່ໄດ້ກວມເອົາທຸກສິ່ງທຸກຢ່າງ, ແລະພະນັກງານຕອບສະຫນອງກັບການແຈ້ງເຕືອນ, ບໍ່ແມ່ນຕາຕະລາງ.

ຫຼັງຈາກການຄົ້ນຫາຢ່າງລະອຽດແຕ່ບໍ່ປະສົບຜົນສໍາເລັດໃນ GitHub ສໍາລັບ "ກະດານ" ທີ່ຊັດເຈນແລະໃຫ້ຂໍ້ມູນສໍາລັບ PD, ພວກເຮົາໄດ້ຕັດສິນໃຈຂຽນຂອງພວກເຮົາເອງ - ພຽງແຕ່ກັບສິ່ງທີ່ພວກເຮົາຕ້ອງການ. ເຖິງແມ່ນວ່າໃນຕອນທໍາອິດມີຄວາມຄິດທີ່ຈະສະແດງການໂຕ້ຕອບ PD ຕົວຂອງມັນເອງ, ມັນເບິ່ງຄືວ່າບໍ່ສະດວກຫຼາຍ.

ເພື່ອຂຽນມັນ, ສິ່ງທີ່ທ່ານຕ້ອງເຮັດແມ່ນໄດ້ຮັບລະຫັດຈາກ PD ທີ່ມີສິດອ່ານເທົ່ານັ້ນ.
ແລະນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາໄດ້ຮັບ:

ຫນ້າຈໍສະແດງເຫດການທີ່ເປີດໃນປັດຈຸບັນ, ຊື່ຂອງວິສະວະກອນປະຈຸບັນຢູ່ໃນຫນ້າທີ່ຈາກຕາຕະລາງທີ່ເລືອກ, ແລະເວລາທີ່ບໍ່ມີເຫດການທີ່ມີບູລິມະສິດສູງ (ກະດານທີ່ມີເຫດການບູລິມະສິດສູງຈະຖືກເນັ້ນໃສ່ເປັນສີແດງ).

ເບິ່ງແຫຼ່ງຂອງການຈັດຕັ້ງປະຕິບັດນີ້ ທີ່ນີ້.

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບ dashboard ທີ່ສະດວກສໍາລັບການເບິ່ງເຫດການທັງຫມົດຂອງພວກເຮົາ. ຂ້ອຍຈະດີໃຈຖ້າບາງເຈົ້າພົບວ່າປະສົບການຂອງພວກເຮົາເປັນປະໂຫຍດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com