ເປັນຫຍັງວິສະວະກອນຈຶ່ງບໍ່ສົນໃຈກັບການຕິດຕາມແອັບພລິເຄຊັນ?

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

ການຕິດຕາມແມ່ນ ພຽງແຕ່. ນີ້ແມ່ນຄວາມຈິງທີ່ຮູ້ຈັກ. ເອົາ Nagios ຂຶ້ນ, ແລ່ນ NRPE ໃນລະບົບທາງໄກ, ຕັ້ງຄ່າ Nagios ໃນ NRPE TCP port 5666 ແລະທ່ານມີການຕິດຕາມ.

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

(ໂດຍປົກກະຕິແລ້ວພວກເຂົາຕິດຕັ້ງ PNP4Nagios, RRDtool ແລະ Thruk, ຕັ້ງຄ່າການແຈ້ງເຕືອນໃນ Slack ແລະໄປກົງກັບ nagiosexchange, ແຕ່ປ່ອຍໃຫ້ມັນອອກໄປໃນປັດຈຸບັນ).

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

ການຕິດຕາມຍາກບໍ?

ເຄື່ອງແມ່ຂ່າຍໃດກໍ່ຕາມ, ບໍ່ວ່າຈະເປັນ Linux ຫຼື Windows, ໂດຍຄໍານິຍາມຈະຮັບໃຊ້ຈຸດປະສົງບາງຢ່າງ. Apache, Samba, Tomcat, ການເກັບຮັກສາໄຟລ໌, LDAP - ການບໍລິການທັງຫມົດເຫຼົ່ານີ້ແມ່ນຫຼາຍຫຼືຫນ້ອຍເປັນເອກະລັກໃນຫນຶ່ງຫຼືຫຼາຍ. ແຕ່ລະຄົນມີຫນ້າທີ່ຂອງຕົນເອງ, ຄຸນລັກສະນະຂອງຕົນເອງ. ມີວິທີທີ່ແຕກຕ່າງກັນທີ່ຈະໄດ້ຮັບ metrics, KPIs (ຕົວຊີ້ວັດການປະຕິບັດທີ່ສໍາຄັນ), ທີ່ຫນ້າສົນໃຈສໍາລັບທ່ານໃນເວລາທີ່ເຄື່ອງແມ່ຂ່າຍກໍາລັງໂຫລດ.

ຜູ້ຂຽນຂອງຮູບ ລູກາ Chesser ສຸດ Unsplash

(ຂ້ອຍຢາກໃຫ້ແຜງໜ້າປັດຂອງຂ້ອຍເປັນສີຟ້ານີອອນ - ຫາຍໃຈຝັນດີ -... ຮືມ...)

ຊອບແວທີ່ສະຫນອງການບໍລິການຕ້ອງມີກົນໄກເພື່ອເກັບກໍາ metrics. Apache ມີໂມດູນ mod-status, ສະແດງຫນ້າສະຖານະຂອງເຄື່ອງແມ່ຂ່າຍ. Nginx ມີ - stub_status. Tomcat ມີ JMX ຫຼືຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ກໍາຫນົດເອງທີ່ສະແດງໃຫ້ເຫັນ metrics ທີ່ສໍາຄັນ. MySQL ມີຄໍາສັ່ງ "ສະແດງສະຖານະພາບທົ່ວໂລກ" ແລະອື່ນໆ.
ດັ່ງນັ້ນເປັນຫຍັງນັກພັດທະນາບໍ່ສ້າງກົນໄກທີ່ຄ້າຍຄືກັນໃນຄໍາຮ້ອງສະຫມັກທີ່ພວກເຂົາສ້າງ?

ມີພຽງແຕ່ນັກພັດທະນາເຮັດສິ່ງນີ້ບໍ?

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

ຜູ້ຂຽນຂອງຮູບ ທິມ Gouw ສຸດ Unsplash

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

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

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

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

ນີ້ devops ສິ່ງ

ຈິດຕະວິທະຍາຂອງ devops ອະທິບາຍເຖິງການສົມທົບລະຫວ່າງການພັດທະນາ (dev) ແລະການດໍາເນີນການ (ops). ບໍລິສັດໃດທີ່ອ້າງວ່າ "ເຮັດ devops" ຕ້ອງ:

1. ເວົ້າສິ່ງທີ່ເຂົາເຈົ້າອາດຈະບໍ່ເຮັດ (ໂດຍອ້າງອີງໃສ່ The Princess Bride meme - "ຂ້ອຍບໍ່ຄິດວ່າມັນຫມາຍຄວາມວ່າເຈົ້າຄິດວ່າມັນຫມາຍຄວາມວ່າແນວໃດ!")
2. ຊຸກຍູ້ທັດສະນະຄະຕິຂອງການປັບປຸງຜະລິດຕະພັນຢ່າງຕໍ່ເນື່ອງ.

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

ເລື່ອນຊ້າຍ, ຊ້າຍ, ຂ້ອຍເວົ້າວ່າ LEEEE—

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

ຜູ້ຂຽນຂອງຮູບ NESA ໂດຍຜູ້ຜະລິດ ສຸດ Unsplash

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

ເວົ້າສັ້ນໆ

1. ນໍາພາມ້າຂອງເຈົ້າໄປຫານ້ໍາ. ສະແດງໃຫ້ເຫັນນັກພັດທະນາວ່າພວກເຂົາສາມາດຫລີກລ້ຽງບັນຫາຫຼາຍປານໃດສໍາລັບຕົນເອງ, ຊ່ວຍໃຫ້ພວກເຂົາກໍານົດ KPIs ແລະ metrics ທີ່ຖືກຕ້ອງສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງພວກເຂົາເພື່ອໃຫ້ມີສຽງຮ້ອງຫນ້ອຍຈາກເຈົ້າຂອງຜະລິດຕະພັນທີ່ຖືກ yelled ໂດຍ CTO. ເອົາພວກມັນເຂົ້າໄປໃນແສງສະຫວ່າງ, ຄ່ອຍໆແລະສະຫງົບ. ຖ້າມັນບໍ່ເຮັດວຽກ, ໃຫ້ສິນບົນ, ຂົ່ມຂູ່, ແລະຊັກຊວນໃຫ້ເຂົາເຈົ້າຫຼືເຈົ້າຂອງຜະລິດຕະພັນເພື່ອປະຕິບັດການໄດ້ຮັບ metrics ເຫຼົ່ານີ້ຈາກຄໍາຮ້ອງສະຫມັກໄວເທົ່າທີ່ເປັນໄປໄດ້, ແລະຫຼັງຈາກນັ້ນແຕ້ມແຜນວາດ. ນີ້ຈະມີຄວາມຫຍຸ້ງຍາກຍ້ອນວ່າມັນຈະບໍ່ຖືກເຫັນວ່າເປັນບູລິມະສິດແລະແຜນທີ່ເສັ້ນທາງຜະລິດຕະພັນຈະມີໂຄງການສ້າງລາຍໄດ້ຫຼາຍທີ່ຍັງຄ້າງຢູ່. ດັ່ງນັ້ນ, ທ່ານຈະຕ້ອງການກໍລະນີທຸລະກິດເພື່ອ justify ທີ່ໃຊ້ເວລາແລະຄ່າໃຊ້ຈ່າຍໃນການປະຕິບັດການຕິດຕາມເຂົ້າໄປໃນຜະລິດຕະພັນ.
2. ຊ່ວຍໃຫ້ວິສະວະກອນລະບົບນອນຫຼັບໄດ້ສະບາຍ. ສະແດງໃຫ້ພວກເຂົາຮູ້ວ່າການໃຊ້ "ໃຫ້ປ່ອຍ" ບັນຊີລາຍການກວດສອບສໍາລັບຜະລິດຕະພັນໃດໆທີ່ຖືກປ່ອຍອອກມາແມ່ນເປັນສິ່ງທີ່ດີ. ແລະໃຫ້ແນ່ໃຈວ່າທຸກຄໍາຮ້ອງສະຫມັກໃນການຜະລິດຖືກປົກຄຸມດ້ວຍ metrics ຈະຊ່ວຍໃຫ້ທ່ານນອນຫລັບໄດ້ດີຂຶ້ນໃນເວລາກາງຄືນໂດຍໃຫ້ຜູ້ພັດທະນາເບິ່ງສິ່ງທີ່ຜິດພາດແລະບ່ອນໃດ. ຢ່າງໃດກໍຕາມ, ວິທີທີ່ຖືກຕ້ອງທີ່ຈະລະຄາຍເຄືອງແລະອຸກອັ່ງຜູ້ພັດທະນາໃດໆ, ເຈົ້າຂອງຜະລິດຕະພັນ, ຫຼື CTO ແມ່ນເພື່ອສືບຕໍ່ແລະຕ້ານທານ. ພຶດຕິກໍານີ້ຈະສົ່ງຜົນກະທົບຕໍ່ວັນທີປ່ອຍຜະລິດຕະພັນໃດໆຖ້າທ່ານລໍຖ້າຈົນກ່ວານາທີສຸດທ້າຍອີກເທື່ອຫນຶ່ງ, ດັ່ງນັ້ນໃຫ້ເລື່ອນຊ້າຍອີກເທື່ອຫນຶ່ງແລະເອົາບັນຫາເຫຼົ່ານີ້ເຂົ້າໄປໃນແຜນການໂຄງການຂອງທ່ານໄວເທົ່າທີ່ຈະໄວໄດ້. ຖ້າຈໍາເປັນ, ໄປຫາກອງປະຊຸມຜະລິດຕະພັນ. ໃສ່ mustache ປອມແລະຮູ້ສຶກຫຼືບາງສິ່ງບາງຢ່າງ, ມັນຈະບໍ່ເຄີຍລົ້ມເຫລວ. ສື່ສານຄວາມກັງວົນຂອງເຈົ້າ, ສະແດງໃຫ້ເຫັນຜົນປະໂຫຍດທີ່ຊັດເຈນ, ແລະປະກາດຂ່າວປະເສີດ.
3. ໃຫ້ແນ່ໃຈວ່າທັງການພັດທະນາ (dev) ແລະການດໍາເນີນງານ (ops) ເຂົ້າໃຈຄວາມຫມາຍແລະຜົນສະທ້ອນຂອງ metrics ຜະລິດຕະພັນທີ່ເຄື່ອນຍ້າຍໄປໃນເຂດສີແດງ. ຢ່າປ່ອຍໃຫ້ Ops ເປັນຜູ້ປົກຄອງພຽງຜູ້ດຽວຂອງສຸຂະພາບຂອງຜະລິດຕະພັນ, ໃຫ້ແນ່ໃຈວ່ານັກພັດທະນາມີສ່ວນຮ່ວມຄືກັນ (#productsquads).
4. ບັນທຶກເປັນສິ່ງທີ່ດີ, ແຕ່ຕົວຊີ້ວັດແມ່ນຄືກັນ. ຜະສົມຜະສານພວກມັນແລະບໍ່ໃຫ້ໄມ້ທ່ອນຂອງເຈົ້າກາຍເປັນຂີ້ເຫຍື້ອໃນບານຂະຫນາດໃຫຍ່ທີ່ບໍ່ມີປະໂຫຍດ. ອະທິບາຍ ແລະສະແດງໃຫ້ນັກພັດທະນາເຫັນວ່າ ເປັນຫຍັງບໍ່ມີໃຜຈະເຂົ້າໃຈບັນທຶກຂອງເຂົາເຈົ້າ, ສະແດງໃຫ້ເຂົາເຈົ້າເບິ່ງບັນທຶກທີ່ບໍ່ມີປະໂຫຍດໃນເວລາ 3:15 ຕອນເຊົ້າ.

ຜູ້ຂຽນຂອງຮູບ Marko Horvat ສຸດ Unsplash

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

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