SRE (Site Reliability Engineering) ແມ່ນວິທີການຮັບປະກັນການມີໂຄງການເວັບ. ມັນໄດ້ຖືກພິຈາລະນາເປັນກອບສໍາລັບ DevOps ແລະເວົ້າກ່ຽວກັບວິທີທີ່ຈະປະສົບຜົນສໍາເລັດໃນການປະຕິບັດການປະຕິບັດ DevOps. ການແປໃນບົດຄວາມນີ້ ບົດທີ 6 ການຕິດຕາມລະບົບການແຈກຢາຍ ປື້ມ ວິສະວະກໍາຄວາມຫນ້າເຊື່ອຖືຂອງສະຖານທີ່ ຈາກ Google. ຂ້າພະເຈົ້າໄດ້ກະກຽມການແປນີ້ດ້ວຍຕົນເອງແລະອີງໃສ່ປະສົບການຂອງຕົນເອງໃນການເຂົ້າໃຈຂະບວນການຕິດຕາມ. ໃນ​ຊ່ອງ telegram​ @monitorim_it и blog ໃນ Medium ຂ້າພະເຈົ້າຍັງໄດ້ເຜີຍແຜ່ການເຊື່ອມຕໍ່ກັບການແປບົດທີ 4 ຂອງປື້ມດຽວກັນກ່ຽວກັບເປົ້າຫມາຍລະດັບການບໍລິການ.

ການ​ແປ​ພາ​ສາ​ໂດຍ cat. ມ່ວນກັບການອ່ານ!

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

ຄໍານິຍາມ

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

ການຕິດຕາມ

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

ການຕິດຕາມກ່ອງສີຂາວ

ການຕິດຕາມໂດຍອີງຕາມການວັດແທກທີ່ສະແດງໂດຍອົງປະກອບຂອງລະບົບພາຍໃນ, ລວມທັງບັນທຶກ, metrics profiling Java Virtual Machine, ຫຼືຕົວຊີ້ວັດຕົວຈັດການ HTTP ທີ່ສ້າງສະຖິຕິພາຍໃນ.

ການຕິດຕາມກ່ອງດຳ

ການທົດສອບພຶດຕິກໍາຄໍາຮ້ອງສະຫມັກຈາກຈຸດຂອງຜູ້ໃຊ້.

ແຜງໜ້າປັດ

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

ແຈ້ງເຕືອນ (ການແຈ້ງເຕືອນ)

ການແຈ້ງເຕືອນທີ່ມີຈຸດປະສົງທີ່ຈະໄດ້ຮັບໂດຍບຸກຄົນຜ່ານທາງອີເມລ໌ຫຼືວິທີການອື່ນໆ, ເຊິ່ງອາດຈະຖືກກະຕຸ້ນໂດຍຄວາມຜິດພາດຫຼືການເພີ່ມຂຶ້ນຂອງແຖວການຮ້ອງຂໍ. ແຈ້ງ​ການ​ຖືກ​ຈັດ​ປະ​ເພດ​ເປັນ​: ປີ້​, ການ​ແຈ້ງ​ເຕືອນ​ອີ​ເມລ​໌​ແລະ​ຂໍ້​ຄວາມ​ທັນ​ທີ​.

ສາເຫດຮາກ

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

ໂຫມດແລະເຄື່ອງຈັກ (node ​​​​ແລະເຄື່ອງຈັກ)

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

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

Push

ການປ່ຽນແປງໃດໆໃນການຕັ້ງຄ່າຊອບແວ.

ເປັນຫຍັງຕ້ອງຕິດຕາມ?

ມີຫຼາຍເຫດຜົນວ່າເປັນຫຍັງຄໍາຮ້ອງສະຫມັກຕ້ອງໄດ້ຮັບການຕິດຕາມກວດກາ:

ການວິເຄາະແນວໂນ້ມໃນໄລຍະຍາວ

ຖານຂໍ້ມູນໃຫຍ່ເທົ່າໃດ ແລະມັນເຕີບໂຕໄວເທົ່າໃດ? ຈໍານວນຜູ້ໃຊ້ປະຈໍາວັນມີການປ່ຽນແປງແນວໃດ?

ການປຽບທຽບປະສິດທິພາບ

ການຮ້ອງຂໍໄວຂຶ້ນຢູ່ໃນ Acme Bucket of Bytes 2.72 ເມື່ອປຽບທຽບກັບ Ajax DB 3.14? ການຮ້ອງຂໍຖືກເກັບໄວ້ໃນແຄດທີ່ດີກວ່າເທົ່າໃດຫຼັງຈາກຮູບລັກສະນະຂອງ node ເພີ່ມເຕີມ? ເວັບໄຊທ໌ເຮັດວຽກຊ້າລົງເມື່ອທຽບກັບອາທິດທີ່ຜ່ານມາບໍ?

ການ​ແຈ້ງ​ເຕືອນ

ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ແຕກ​ຫັກ​ແລະ​ຜູ້​ໃດ​ຜູ້​ຫນຶ່ງ​ຕ້ອງ​ການ​ແກ້​ໄຂ​ມັນ​. ຫຼືບາງສິ່ງບາງຢ່າງຈະແຕກໃນໄວໆນີ້ແລະຜູ້ໃດຜູ້ຫນຶ່ງຕ້ອງກວດເບິ່ງມັນໃນໄວໆນີ້.

ການສ້າງ dashboards

Dashboards ຄວນຕອບຄໍາຖາມພື້ນຖານແລະປະກອບມີບາງສິ່ງບາງຢ່າງຈາກ "4 ສັນຍານທອງ" — ຄວາມ​ຊັກ​ຊ້າ (latency​)​, ການ​ຈະ​ລາ​ຈອນ (ການ​ຈະ​ລາ​ຈອນ​)​, ຄວາມ​ຜິດ​ພາດ (ຄວາມ​ຜິດ​ພາດ​) ແລະ​ຂະ​ຫນາດ​ການ​ໂຫຼດ (ການ​ອີ່ມ​ຕົວ​)​.

ປະຕິບັດການວິເຄາະຄືນຫຼັງ (ດີບັກ)

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

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

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

ການກໍານົດຄວາມຄາດຫວັງທີ່ສົມເຫດສົມຜົນສໍາລັບລະບົບການຕິດຕາມ

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

ໂດຍລວມແລ້ວ, Google ໄດ້ຍ້າຍໄປໃຊ້ລະບົບການຕິດຕາມທີ່ງ່າຍດາຍ ແລະໄວດ້ວຍເຄື່ອງມືການວິເຄາະຫຼັງຄວາມເປັນຈິງທີ່ດີທີ່ສຸດ. ພວກເຮົາຫຼີກເວັ້ນລະບົບ "magic" ທີ່ພະຍາຍາມຄາດຄະເນຂອບເຂດຫຼືອັດຕະໂນມັດກວດພົບສາເຫດຂອງຮາກ. ເຊັນເຊີທີ່ກວດພົບເນື້ອຫາທີ່ບໍ່ໄດ້ຕັ້ງໃຈໃນຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້ສຸດທ້າຍແມ່ນຕົວຢ່າງດຽວເທົ່ານັ້ນ; ຕາບໃດທີ່ເຊັນເຊີເຫຼົ່ານີ້ຍັງງ່າຍດາຍ, ພວກເຂົາສາມາດກວດຫາສາເຫດຂອງຄວາມຜິດປົກກະຕິທີ່ຮ້າຍແຮງໄດ້ໄວ. ຮູບແບບອື່ນໆສໍາລັບການນໍາໃຊ້ຂໍ້ມູນການຕິດຕາມ, ເຊັ່ນ: ການວາງແຜນຄວາມອາດສາມາດຫຼືການພະຍາກອນການຈະລາຈອນ, ແມ່ນສັບສົນຫຼາຍ. ການສັງເກດການໃນໄລຍະເວລາຫຼາຍ (ເດືອນຫຼືຫຼາຍປີ) ໃນອັດຕາຕົວຢ່າງທີ່ຕໍ່າ (ຊົ່ວໂມງຫຼືມື້) ຈະເປີດເຜີຍແນວໂນ້ມໃນໄລຍະຍາວ.

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

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

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

ອາການທຽບກັບສາເຫດ

ລະບົບການຕິດຕາມຂອງທ່ານຄວນຕອບສອງຄໍາຖາມ: "ສິ່ງທີ່ແຕກຫັກ" ແລະ "ເປັນຫຍັງມັນຈຶ່ງແຕກ."
"ສິ່ງທີ່ແຕກຫັກ" ເວົ້າກ່ຽວກັບອາການ, ແລະ "ເປັນຫຍັງມັນແຕກ" ເວົ້າກ່ຽວກັບສາເຫດ. ຕາຕະລາງຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນຕົວຢ່າງຂອງການເຊື່ອມຕໍ່ດັ່ງກ່າວ.

ອາການ
ເຫດຜົນ

ໄດ້ຮັບ HTTP Error 500 ຫຼື 404
ເຄື່ອງແມ່ຂ່າຍຂອງຖານຂໍ້ມູນປະຕິເສດການເຊື່ອມຕໍ່

ເຊີບເວີຕອບສະໜອງຊ້າ
ການນໍາໃຊ້ CPU ສູງຫຼືສາຍ Ethernet ເສຍຫາຍ

ຜູ້ໃຊ້ຢູ່ໃນ Antarctica ບໍ່ໄດ້ຮັບ GIFs cat
CDN ຂອງທ່ານກຽດຊັງນັກວິທະຍາສາດແລະແມວ, ດັ່ງນັ້ນບາງທີ່ຢູ່ IP ສິ້ນສຸດລົງເຖິງບັນຊີດໍາ

ເນື້ອຫາສ່ວນຕົວໄດ້ກາຍເປັນທີ່ມີຢູ່ຈາກທຸກບ່ອນ
ການເປີດຕົວຂອງຊອບແວໃຫມ່ເຮັດໃຫ້ firewall ລືມ ACLs ທັງຫມົດແລະປ່ອຍໃຫ້ທຸກຄົນເຂົ້າມາ

"ແມ່ນຫຍັງ" ແລະ "ເປັນຫຍັງ" ແມ່ນບາງສ່ວນຂອງການກໍ່ສ້າງທີ່ສໍາຄັນສໍາລັບການສ້າງລະບົບການຕິດຕາມທີ່ດີທີ່ມີສັນຍານສູງສຸດແລະສຽງຫນ້ອຍທີ່ສຸດ.

Black-box vs White-box

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

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

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

ການຕິດຕາມກ່ອງດຳມີປະໂຫຍດທີ່ສຳຄັນໃນເວລາສົ່ງການແຈ້ງເຕືອນ: ທ່ານກະຕຸ້ນການແຈ້ງເຕືອນໃຫ້ຜູ້ຮັບເມື່ອບັນຫາໄດ້ສົ່ງຜົນໃຫ້ເກີດອາການຕົວຈິງແລ້ວ. ໃນທາງກົງກັນຂ້າມ, ການຕິດຕາມແມ່ນບໍ່ມີປະໂຫຍດສໍາລັບບັນຫາ Black-box ທີ່ຍັງບໍ່ທັນເກີດຂຶ້ນແຕ່ໃກ້ຈະເກີດຂຶ້ນ.

ສີ່ສັນຍານທອງ

ສີ່ສັນຍານຕິດຕາມກວດກາສີທອງແມ່ນ latency, ການຈະລາຈອນ, ຄວາມຜິດພາດ, ແລະການອີ່ມຕົວ. ຖ້າທ່ານພຽງແຕ່ສາມາດວັດແທກສີ່ຕົວຊີ້ບອກລະບົບຜູ້ໃຊ້, ສຸມໃສ່ສີ່ອັນນັ້ນ.

ການຊັກຊ້າ

ເວລາທີ່ຕ້ອງການເພື່ອປະມວນຜົນການຮ້ອງຂໍ. ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຈໍາແນກລະຫວ່າງ latency ຂອງການຮ້ອງຂໍສົບຜົນສໍາເລັດແລະບໍ່ສໍາເລັດ. ຕົວຢ່າງ, ຂໍ້ຜິດພາດ HTTP 500 ທີ່ເກີດຈາກການສູນເສຍການເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນຫຼື backend ອື່ນໆສາມາດຖືກວິນິດໄສຢ່າງໄວວາ, ຢ່າງໃດກໍ່ຕາມ, ຂໍ້ຜິດພາດ HTTP 500 ອາດຈະຊີ້ໃຫ້ເຫັນເຖິງຄໍາຮ້ອງຂໍທີ່ລົ້ມເຫລວ. ການກໍານົດຜົນກະທົບຂອງຄວາມຜິດພາດ 500 ກ່ຽວກັບການ latency ໂດຍລວມອາດຈະນໍາໄປສູ່ການສະຫຼຸບທີ່ຜິດພາດ. ໃນທາງກົງກັນຂ້າມ, ຄວາມຜິດພາດທີ່ຊ້າກໍ່ແມ່ນຄວາມຜິດພາດທີ່ໄວ! ດັ່ງນັ້ນ, ມັນເປັນສິ່ງ ສຳ ຄັນທີ່ຈະຕິດຕາມຄວາມຕ້ານທານຂອງຂໍ້ຜິດພາດແທນທີ່ຈະພຽງແຕ່ກັ່ນຕອງຂໍ້ຜິດພາດອອກ.

ການຈະລາຈອນ

ຈໍາ​ນວນ​ຂອງ​ການ​ຮ້ອງ​ຂໍ​ໃຫ້​ລະ​ບົບ​ຂອງ​ທ່ານ​ແມ່ນ​ການ​ວັດ​ແທກ​ໃນ​ລະ​ດັບ​ສູງ​ຂອງ​ລະ​ບົບ​ການ​ວັດ​ແທກ​. ສໍາລັບການບໍລິການເວັບໄຊຕ໌, ການວັດແທກນີ້ໂດຍປົກກະຕິເປັນຕົວແທນຂອງຈໍານວນຄໍາຮ້ອງຂໍ HTTP ຕໍ່ວິນາທີ, ແບ່ງອອກຕາມລັກສະນະຂອງຄໍາຮ້ອງຂໍ (ຕົວຢ່າງ, ເນື້ອຫາຄົງທີ່ຫຼືແບບເຄື່ອນໄຫວ). ສໍາລັບລະບົບການຖ່າຍທອດສຽງ, ການວັດແທກນີ້ອາດຈະເນັ້ນໃສ່ຄວາມໄວຂອງເຄືອຂ່າຍ I/O ຫຼືຈໍານວນຂອງເຊດຊັນພ້ອມໆກັນ. ສໍາລັບລະບົບການເກັບຮັກສາທີ່ສໍາຄັນມູນຄ່າ, ການວັດແທກນີ້ອາດຈະເປັນການເຮັດທຸລະກໍາຫຼືຜົນການຄົ້ນຫາຕໍ່ວິນາທີ.

ຂໍ້ຜິດພາດ

ນີ້ແມ່ນອັດຕາການຮ້ອງຂໍທີ່ລົ້ມເຫລວທີ່ຈະແຈ້ງ (ເຊັ່ນ HTTP 500), implicit (ເຊັ່ນ HTTP 200 ແຕ່ລວມກັບເນື້ອຫາທີ່ບໍ່ຖືກຕ້ອງ) ຫຼືນະໂຍບາຍ (ເຊັ່ນ: "ຖ້າທ່ານຈັບຄໍາຕອບໃນຫນຶ່ງວິນາທີ, ຫນຶ່ງໃນວິນາທີແມ່ນຄວາມຜິດພາດ"). ຖ້າລະຫັດຕອບໂຕ້ HTTP ບໍ່ພຽງພໍເພື່ອສະແດງເງື່ອນໄຂຄວາມລົ້ມເຫລວທັງຫມົດ, ໂປໂຕຄອນຂັ້ນສອງ (ພາຍໃນ) ອາດຈະຈໍາເປັນຕ້ອງໄດ້ກວດພົບຄວາມລົ້ມເຫລວບາງສ່ວນ. ການຕິດຕາມທຸກຄໍາຮ້ອງຂໍທີ່ຜິດພາດດັ່ງກ່າວອາດຈະບໍ່ເປັນຂໍ້ມູນ, ໃນຂະນະທີ່ການທົດສອບລະບົບ end-to-end ຈະຊ່ວຍໃຫ້ກວດພົບວ່າທ່ານກໍາລັງປະມວນຜົນເນື້ອຫາທີ່ບໍ່ຖືກຕ້ອງ.

ການອີ່ມຕົວ

metric ສະແດງໃຫ້ເຫັນວ່າການບໍລິການຂອງທ່ານຖືກໃຊ້ຫຼາຍເທົ່າໃດ. ນີ້ແມ່ນມາດຕະການຕິດຕາມລະບົບທີ່ກໍານົດຊັບພະຍາກອນທີ່ມີຂໍ້ຈໍາກັດທີ່ສຸດ (ຕົວຢ່າງເຊັ່ນໃນລະບົບຄວາມຈໍາຈໍາກັດ, ສະແດງຫນ່ວຍຄວາມຈໍາ, ໃນລະບົບ I/O-ຈໍາກັດ, ສະແດງຈໍານວນ I/Os). ໃຫ້ສັງເກດວ່າຫຼາຍລະບົບເຮັດໃຫ້ປະສິດທິພາບກ່ອນທີ່ຈະບັນລຸ 100%, ດັ່ງນັ້ນການມີເປົ້າຫມາຍການນໍາໃຊ້ແມ່ນສໍາຄັນ.

ໃນລະບົບທີ່ສັບສົນ, ການອີ່ມຕົວສາມາດປະກອບໄດ້ໂດຍການວັດແທກການໂຫຼດລະດັບສູງ: ການບໍລິການຂອງເຈົ້າສາມາດຈັດການການຈະລາຈອນສອງເທົ່າໄດ້ຢ່າງຖືກຕ້ອງ, ຈັດການການຈະລາຈອນພຽງແຕ່ 10% ເທົ່ານັ້ນ, ຫຼືຈັດການການຈະລາຈອນຫນ້ອຍກວ່າທີ່ມັນເຮັດໃນປັດຈຸບັນບໍ? ສໍາລັບການບໍລິການທີ່ງ່າຍດາຍທີ່ບໍ່ມີຕົວກໍານົດການທີ່ປ່ຽນແປງຄວາມຊັບຊ້ອນຂອງຄໍາຮ້ອງຂໍ (ຕົວຢ່າງ, "ໃຫ້ຂ້ອຍບໍ່ມີຫຍັງ" ຫຼື "ຂ້ອຍຕ້ອງການຕົວເລກ monotonic ດຽວທີ່ເປັນເອກະລັກ"), ທີ່ບໍ່ຄ່ອຍຈະປ່ຽນການຕັ້ງຄ່າ, ມູນຄ່າການທົດສອບການໂຫຼດຄົງທີ່ອາດຈະພຽງພໍ. ຢ່າງໃດກໍຕາມ, ດັ່ງທີ່ໄດ້ສົນທະນາໃນວັກທີ່ຜ່ານມາ, ການບໍລິການສ່ວນໃຫຍ່ຈະຕ້ອງໃຊ້ສັນຍານທາງອ້ອມເຊັ່ນການນໍາໃຊ້ CPU ຫຼືແບນວິດຂອງເຄືອຂ່າຍ, ເຊິ່ງມີຂອບເຂດທີ່ຮູ້ຈັກ. ການເພີ່ມເວລາ latency ມັກຈະເປັນຕົວຊີ້ວັດຊັ້ນນໍາຂອງຄວາມອີ່ມຕົວ. ການວັດແທກເວລາຕອບໂຕ້ເປີເຊັນທີ 99 ຢູ່ໃນປ່ອງຢ້ຽມຂະຫນາດນ້ອຍ (ເຊັ່ນ: ຫນຶ່ງນາທີ) ສາມາດໃຫ້ສັນຍານຂອງການອີ່ມຕົວໄວຫຼາຍ.

ສຸດທ້າຍ, ການອີ່ມຕົວຍັງກ່ຽວຂ້ອງກັບການຄາດຄະເນກ່ຽວກັບການອີ່ມຕົວທີ່ກໍາລັງຈະມາເຖິງ, ຕົວຢ່າງ: "ເບິ່ງຄືວ່າຖານຂໍ້ມູນຂອງທ່ານຈະຕື່ມຂໍ້ມູນໃສ່ຮາດດິດຂອງທ່ານໃນ 4 ຊົ່ວໂມງ."

ຖ້າທ່ານວັດແທກທັງສີ່ສັນຍານທອງຄໍາແລະໃນເວລາທີ່ມີບັນຫາກັບຫນຶ່ງຂອງ metrics (ຫຼື, ໃນກໍລະນີຂອງການອີ່ມຕົວ, ບັນຫາທີ່ຢູ່ໃກ້), ທ່ານເຕືອນບຸກຄົນໃດຫນຶ່ງ, ການບໍລິການຂອງທ່ານຈະກວມເອົາຫຼາຍຫຼືຫນ້ອຍໂດຍການຕິດຕາມ.

ກັງວົນກ່ຽວກັບ "ຫາງ" (ຫຼືເຄື່ອງມືແລະການປະຕິບັດ)

ເມື່ອສ້າງລະບົບການຕິດຕາມຕັ້ງແຕ່ເລີ່ມຕົ້ນ, ມີການລໍ້ລວງທີ່ຈະພັດທະນາລະບົບໂດຍອີງໃສ່ຄ່າສະເລ່ຍ: latency ສະເລ່ຍ, ການນໍາໃຊ້ CPU ສະເລ່ຍຂອງ nodes, ຫຼືຄວາມເຕັມຂອງຖານຂໍ້ມູນສະເລ່ຍ. ອັນຕະລາຍຂອງສອງຕົວຢ່າງສຸດທ້າຍແມ່ນເຫັນໄດ້ຊັດເຈນ: ໂປເຊດເຊີແລະຖານຂໍ້ມູນຖືກກໍາຈັດຢູ່ໃນວິທີທີ່ບໍ່ສາມາດຄາດເດົາໄດ້ຫຼາຍ. ດຽວກັນໃຊ້ກັບການຊັກຊ້າ. ຖ້າທ່ານດໍາເນີນການບໍລິການເວັບທີ່ມີ latency ສະເລ່ຍ 100ms ກັບ 1000 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ, 1% ຂອງການຮ້ອງຂໍອາດຈະໃຊ້ເວລາ 5 ວິນາທີ. ຖ້າຜູ້ໃຊ້ຂຶ້ນກັບການບໍລິການເວັບຫຼາຍອັນ, ເປີເຊັນທີ 99 ຂອງ backend ຫນຶ່ງສາມາດກາຍເປັນເວລາຕອບສະຫນອງປານກາງຂອງ frontend ໄດ້ຢ່າງງ່າຍດາຍ.

ວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະແຍກຄວາມແຕກຕ່າງລະຫວ່າງຄໍາຮ້ອງຂໍສະເລ່ຍຊ້າແລະຫາງຊ້າຫຼາຍແມ່ນການເກັບກໍາການວັດແທກການຮ້ອງຂໍທີ່ສະແດງຢູ່ໃນສະຖິຕິ (ເຄື່ອງມືທີ່ດີທີ່ຈະສະແດງແມ່ນ histograms) ແທນທີ່ຈະເປັນ latencies ຕົວຈິງ: ຈໍານວນຄໍາຮ້ອງຂໍໃຫ້ບໍລິການທີ່ໃຊ້ເວລາລະຫວ່າງ 0 ms. ແລະ 10 ms, ລະຫວ່າງ 10 ms ແລະ 30 ms, ລະຫວ່າງ 30 ms ແລະ 100 ms, ລະຫວ່າງ 100 ms ແລະ 300 ms, ແລະອື່ນໆ. ການຂະຫຍາຍຂອບເຂດຂອງ histogram ປະມານ exponentially (ໂດຍປັດໄຈປະມານຂອງ 3) ມັກຈະເປັນວິທີທີ່ງ່າຍດາຍທີ່ຈະສະແດງພາບການແຈກຢາຍ. ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​.

ການຄັດເລືອກລະດັບທີ່ເຫມາະສົມຂອງລາຍລະອຽດສໍາລັບການວັດແທກ

ອົງປະກອບທີ່ແຕກຕ່າງກັນຂອງລະບົບຕ້ອງໄດ້ຮັບການວັດແທກໃນລະດັບທີ່ແຕກຕ່າງກັນຂອງລາຍລະອຽດ. ຍົກ​ຕົວ​ຢ່າງ:

• ການຕິດຕາມການນໍາໃຊ້ CPU ໃນໄລຍະເວລາໃດຫນຶ່ງຈະບໍ່ສະແດງໃຫ້ເຫັນການເພີ່ມຂື້ນໃນໄລຍະຍາວທີ່ນໍາໄປສູ່ການ latencies ສູງ.
• ໃນທາງກົງກັນຂ້າມ, ສໍາລັບການບໍລິການເວັບທີ່ກໍາຫນົດເປົ້າຫມາຍການຢຸດເວລາບໍ່ເກີນ 9 ຊົ່ວໂມງຕໍ່ປີ (99,9% ປະຈໍາປີ), ການກວດສອບການຕອບສະຫນອງ HTTP 200 ຫຼາຍກວ່າຫນຶ່ງຄັ້ງຫຼືສອງຄັ້ງຕໍ່ນາທີແມ່ນມັກຈະບໍ່ຈໍາເປັນເລື້ອຍໆ.
• ເຊັ່ນດຽວກັນ, ການກວດສອບພື້ນທີ່ຮາດດິດສໍາລັບການມີ 99,9% ຫຼາຍກວ່າຫນຶ່ງຄັ້ງໃນທຸກໆ 1-2 ນາທີອາດຈະບໍ່ຈໍາເປັນ.

ເອົາໃຈໃສ່ໃນວິທີທີ່ທ່ານສ້າງໂຄງສ້າງ granularity ຂອງການວັດແທກຂອງທ່ານ. ການລວບລວມການໂຫຼດ CPU ຫນຶ່ງຄັ້ງຕໍ່ວິນາທີສາມາດສະຫນອງຂໍ້ມູນທີ່ຫນ້າສົນໃຈ, ແຕ່ການວັດແທກເລື້ອຍໆດັ່ງກ່າວສາມາດມີລາຄາແພງຫຼາຍເພື່ອເກັບກໍາ, ເກັບຮັກສາແລະວິເຄາະ. ຖ້າເປົ້າຫມາຍການຕິດຕາມຂອງທ່ານຮຽກຮ້ອງໃຫ້ມີຄວາມລະອຽດສູງແລະບໍ່ຮຽກຮ້ອງໃຫ້ມີການຕອບສະຫນອງສູງ, ທ່ານສາມາດຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍເຫຼົ່ານີ້ໂດຍການຕັ້ງຄ່າການເກັບລວບລວມ metrics ໃນເຄື່ອງແມ່ຂ່າຍແລະຫຼັງຈາກນັ້ນສ້າງຕັ້ງລະບົບພາຍນອກເພື່ອເກັບກໍາແລະລວບລວມ metrics ເຫຼົ່ານັ້ນ. ເຈົ້າ​ສາ​ມາດ:

1. ວັດແທກການໂຫຼດ CPU ທຸກໆວິນາທີ.
2. ຫຼຸດລາຍລະອຽດລົງເປັນ 5%.
3. ການວັດແທກລວມທຸກນາທີ.

ຍຸດທະສາດນີ້ຈະຊ່ວຍໃຫ້ທ່ານສາມາດເກັບກໍາຂໍ້ມູນໃນລະດັບ granularity ສູງໂດຍບໍ່ມີການເກີດການວິເຄາະສູງແລະການເກັບຮັກສາ overhead.

ງ່າຍດາຍເທົ່າທີ່ເປັນໄປໄດ້, ແຕ່ບໍ່ແມ່ນງ່າຍກວ່າ

ການຊ້ອນກັນຂອງຄວາມຕ້ອງການທີ່ແຕກຕ່າງກັນຢູ່ດ້ານເທິງຂອງກັນແລະກັນສາມາດສົ່ງຜົນໃຫ້ລະບົບການຕິດຕາມທີ່ສັບສົນຫຼາຍ. ຕົວຢ່າງ, ລະບົບຂອງທ່ານອາດມີອົງປະກອບທີ່ສັບສົນຕໍ່ໄປນີ້:

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

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

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

• ກົດ​ລະ​ບຽບ​ທີ່​ມັກ​ຈະ​ຈັບ​ເຫດ​ການ​ທີ່​ແທ້​ຈິງ​ຄວນ​ຈະ​ເປັນ​ງ່າຍ​ດາຍ​, ຄາດ​ຄະ​ເນ​ແລະ​ເຊື່ອ​ຖື​ໄດ້​ເທົ່າ​ທີ່​ເປັນ​ໄປ​ໄດ້​.
• ການຕັ້ງຄ່າສໍາລັບການລວບລວມຂໍ້ມູນ, ການລວບລວມ, ແລະການແຈ້ງເຕືອນທີ່ປະຕິບັດເລື້ອຍໆ (ຕົວຢ່າງ, ຫນ້ອຍກວ່າປະຈໍາໄຕມາດສໍາລັບບາງທີມ SRE) ຄວນຖືກລຶບອອກ.
• ເມຕຣິກທີ່ເກັບກໍາແຕ່ບໍ່ໄດ້ສະແດງຢູ່ໃນ dashboard ສະແດງຕົວຢ່າງຫຼືໃຊ້ໂດຍການແຈ້ງເຕືອນໃດໆແມ່ນຜູ້ສະຫມັກສໍາລັບການລຶບ.

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

ຜູກມັດຫຼັກການຮ່ວມກັນ

ຫຼັກການທີ່ໄດ້ສົນທະນາໃນບົດນີ້ສາມາດຖືກລວມເຂົ້າກັນເປັນປັດຊະຍາການຕິດຕາມແລະການແຈ້ງເຕືອນທີ່ໄດ້ຮັບການຮັບຮອງແລະປະຕິບັດຕາມໂດຍທີມງານ Google SRE. ການປະຕິບັດຕາມປັດຊະຍາການຕິດຕາມນີ້ແມ່ນຄວາມປາຖະຫນາ, ເປັນຈຸດເລີ່ມຕົ້ນທີ່ດີສໍາລັບການສ້າງຫຼືປັບປຸງວິທີການແຈ້ງເຕືອນຂອງທ່ານແລະສາມາດຊ່ວຍທ່ານຖາມຄໍາຖາມທີ່ເຫມາະສົມຂອງຫນ້າທີ່ປະຕິບັດງານຂອງທ່ານ, ໂດຍບໍ່ຄໍານຶງເຖິງຂະຫນາດຂອງອົງການຈັດຕັ້ງຫຼືຄວາມຊັບຊ້ອນຂອງການບໍລິການຫຼືລະບົບ.

ເມື່ອສ້າງກົດລະບຽບການຕິດຕາມກວດກາແລະການແຈ້ງເຕືອນ, ການຖາມຄໍາຖາມຕໍ່ໄປນີ້ສາມາດຊ່ວຍທ່ານຫຼີກເວັ້ນການບວກທີ່ບໍ່ຖືກຕ້ອງແລະການແຈ້ງເຕືອນທີ່ບໍ່ຈໍາເປັນ:

• ກົດລະບຽບນີ້ກວດພົບສະຖານະທີ່ບໍ່ສາມາດກວດພົບໄດ້ຖ້າບໍ່ດັ່ງນັ້ນຂອງລະບົບທີ່ຮີບດ່ວນ, ຮຽກຮ້ອງໃຫ້ດໍາເນີນການ, ແລະມີຜົນກະທົບຢ່າງຫຼີກລ່ຽງຕໍ່ຜູ້ໃຊ້ບໍ?
• ຂ້າ​ພະ​ເຈົ້າ​ສາ​ມາດ​ບໍ່​ສົນ​ໃຈ​ຄໍາ​ເຕືອນ​ນີ້​ໂດຍ​ຮູ້​ວ່າ​ມັນ​ເປັນ​ການ​ບໍ່​ດີ​? ເມື່ອໃດ ແລະເປັນຫຍັງຂ້ອຍຈຶ່ງບໍ່ສົນໃຈຄຳເຕືອນນີ້ ແລະຂ້ອຍຈະຫຼີກລ່ຽງສະຖານະການນີ້ໄດ້ແນວໃດ?
• ການແຈ້ງເຕືອນນີ້ຫມາຍຄວາມວ່າຜູ້ໃຊ້ໄດ້ຮັບຜົນກະທົບທາງລົບບໍ? ມີສະຖານະການທີ່ຜູ້ໃຊ້ບໍ່ໄດ້ຮັບຜົນກະທົບທາງລົບ, ເຊັ່ນ: ຜ່ານການກັ່ນຕອງການຈະລາຈອນຫຼືເມື່ອນໍາໃຊ້ລະບົບການທົດສອບສໍາລັບການແຈ້ງເຕືອນທີ່ຄວນຈະຖືກກັ່ນຕອງ?
• ຂ້ອຍສາມາດດໍາເນີນການເພື່ອຕອບສະຫນອງຕໍ່ການແຈ້ງເຕືອນນີ້ບໍ? ມາດຕະການເຫຼົ່ານີ້ແມ່ນຮີບດ່ວນຫຼືພວກເຂົາສາມາດລໍຖ້າຈົນກ່ວາຕອນເຊົ້າ? ການປະຕິບັດສາມາດອັດຕະໂນມັດໄດ້ຢ່າງປອດໄພບໍ? ການປະຕິບັດນີ້ຈະເປັນການແກ້ໄຂໄລຍະຍາວຫຼືການແກ້ໄຂໄລຍະສັ້ນ?
• ບາງຄົນໄດ້ຮັບການເຕືອນຫຼາຍສໍາລັບບັນຫານີ້, ດັ່ງນັ້ນມີວິທີທີ່ຈະຫຼຸດຜ່ອນຈໍານວນການແຈ້ງເຕືອນບໍ?

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

• ທຸກໆຄັ້ງທີ່ມີການແຈ້ງເຕືອນເຂົ້າມາ, ຂ້ອຍຕ້ອງໂຕ້ຕອບທັນທີ. ຂ້ອຍສາມາດຕອບສະໜອງຢ່າງຮີບດ່ວນຫຼາຍເທື່ອຕໍ່ມື້ກ່ອນທີ່ຂ້ອຍຈະເມື່ອຍ.
• ແຕ່ລະການແຈ້ງເຕືອນຕ້ອງມີຄວາມກ່ຽວຂ້ອງ.
• ທຸກໆການຕອບໂຕ້ຕໍ່ການເຕືອນຕ້ອງຮຽກຮ້ອງໃຫ້ມີການແຊກແຊງຂອງມະນຸດ. ຖ້າການແຈ້ງເຕືອນສາມາດຖືກປະມວນຜົນໂດຍອັດຕະໂນມັດ, ມັນບໍ່ຄວນມາຮອດ.
• ການແຈ້ງເຕືອນຄວນຈະກ່ຽວກັບບັນຫາໃຫມ່ຫຼືເຫດການທີ່ບໍ່ເຄີຍມີມາກ່ອນ.

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

ການຕິດຕາມໄລຍະຍາວ

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

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

Bigtable SRE: A Tale of Over-Alert

ໂຄງສ້າງພື້ນຖານພາຍໃນຂອງ Google ໂດຍທົ່ວໄປແມ່ນຈັດຫາ ແລະວັດແທກລະດັບການບໍລິການ (SLO). ຫລາຍປີກ່ອນ, ການບໍລິການຂອງ Bigtable SLO ແມ່ນອີງໃສ່ການປະຕິບັດສະເລ່ຍຂອງທຸລະກໍາສັງເຄາະຈໍາລອງລູກຄ້າທີ່ມີຊີວິດຊີວາ. ເນື່ອງຈາກບັນຫາໃນ Bigtable ແລະລະດັບຕ່ໍາຂອງ stack ການເກັບຮັກສາ, ການປະຕິບັດໂດຍສະເລ່ຍໄດ້ຖືກຂັບເຄື່ອນໂດຍຫາງ "ໃຫຍ່": ທີ່ຮ້າຍແຮງທີ່ສຸດ 5% ຂອງການສອບຖາມມັກຈະຊ້າກວ່າສ່ວນທີ່ເຫຼືອ.

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

ເພື່ອແກ້ໄຂສະຖານະການ, ທີມງານໄດ້ໃຊ້ວິທີການສາມດ້ານ: ໃນຂະນະທີ່ເຮັດວຽກຫນັກເພື່ອປັບປຸງການປະຕິບັດຂອງ Bigtable, ພວກເຮົາກໍານົດເປົ້າຫມາຍ SLO ຂອງພວກເຮົາຊົ່ວຄາວເປັນເປີເຊັນທີ 75 ສໍາລັບການຕອບໂຕ້ແບບສອບຖາມ. ພວກເຮົາຍັງໄດ້ປິດການແຈ້ງເຕືອນທາງອີເມລ໌ເພາະວ່າມີພວກມັນຫຼາຍຈົນບໍ່ສາມາດໃຊ້ເວລາໃນການວິນິດໄສພວກມັນໄດ້.

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

Gmail: ສາມາດຄາດເດົາໄດ້, ປະຕິກິລິຍາຂອງມະນຸດຕາມສູດການຄິດໄລ່

ໃນຕອນເລີ່ມຕົ້ນຂອງມັນ, Gmail ຖືກສ້າງຂຶ້ນໃນລະບົບການຈັດການຂະບວນການ Workqueue ທີ່ຖືກດັດແປງທີ່ຖືກອອກແບບມາເພື່ອຈັດຊຸດຂະບວນການຂອງດັດສະນີຄົ້ນຫາ. ຄິວບ່ອນເຮັດວຽກຖືກປັບໃຫ້ເຂົ້າກັບຂະບວນການທີ່ມີຊີວິດຊີວາ ແລະຕໍ່ມາໄດ້ນຳໃຊ້ກັບ Gmail, ແຕ່ບາງຂໍ້ບົກຜ່ອງໃນລະຫັດຕົວກຳນົດເວລາທີ່ມືດມົວໄດ້ພິສູດໄດ້ວ່າຍາກທີ່ຈະແກ້ໄຂໄດ້.

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

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

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

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

ໄລ​ຍະ​ຍາວ

ຫົວຂໍ້ທົ່ວໄປເຊື່ອມຕໍ່ຕົວຢ່າງ Bigtable ແລະ Gmail: ການແຂ່ງຂັນລະຫວ່າງການມີຢູ່ໃນໄລຍະສັ້ນແລະໄລຍະຍາວ. ເລື້ອຍໆ, ຄວາມພະຍາຍາມທີ່ເຂັ້ມແຂງສາມາດຊ່ວຍໃຫ້ລະບົບທີ່ອ່ອນແອບັນລຸຄວາມພ້ອມທີ່ສູງ, ແຕ່ເສັ້ນທາງນີ້ມັກຈະມີຊີວິດສັ້ນ, ເຕັມໄປດ້ວຍຄວາມອຶດຫີວຂອງທີມງານແລະການເພິ່ງພາອາໄສສະມາຊິກຈໍານວນນ້ອຍຂອງທີມ hero ດຽວກັນ.

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

ສະຫລຸບ

ເສັ້ນທາງໄປສູ່ການຕິດຕາມກວດກາສຸຂະພາບແລະການແຈ້ງເຕືອນແມ່ນງ່າຍດາຍແລະຊັດເຈນ. ມັນສຸມໃສ່ອາການຂອງບັນຫາທີ່ເຮັດໃຫ້ເກີດການແຈ້ງເຕືອນ, ແລະການຕິດຕາມສາເຫດເຮັດຫນ້າທີ່ເປັນການຊ່ວຍເຫຼືອໃນການແກ້ໄຂບັນຫາ. ການຕິດຕາມອາການແມ່ນງ່າຍກວ່າທີ່ທ່ານຢູ່ໃນ stack ທີ່ທ່ານຄວບຄຸມ, ເຖິງແມ່ນວ່າການຕິດຕາມການໂຫຼດແລະການປະຕິບັດຂອງຖານຂໍ້ມູນຄວນຈະເຮັດໂດຍກົງໃນຖານຂໍ້ມູນຂອງມັນເອງ. ການແຈ້ງເຕືອນອີເມລ໌ມີຂໍ້ຈໍາກັດຫຼາຍທີ່ເປັນປະໂຫຍດແລະມີແນວໂນ້ມທີ່ຈະໄດ້ຢ່າງງ່າຍດາຍກາຍເປັນສິ່ງລົບກວນ; ແທນທີ່ຈະ, ທ່ານຄວນໃຊ້ dashboard ທີ່ຕິດຕາມບັນຫາໃນປະຈຸບັນທັງຫມົດທີ່ກະຕຸ້ນເຕືອນອີເມລ໌. ແຜງໜ້າປັດຍັງສາມາດຈັບຄູ່ກັບບັນທຶກເຫດການເພື່ອວິເຄາະຄວາມສຳພັນທາງປະຫວັດສາດໄດ້.

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

ຂອບໃຈທີ່ອ່ານການແປຈົນຈົບ. ຈອງຊ່ອງທາງໂທລະເລກຂອງຂ້ອຍກ່ຽວກັບການຕິດຕາມ @monitorim_it и blog ໃນ Medium.

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