ເປັນຫຍັງທະນາຄານຕ້ອງການ AIOps ແລະການຕິດຕາມ umbrella, ຫຼືຄວາມສໍາພັນຂອງລູກຄ້າແມ່ນອີງໃສ່ຫຍັງ?

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

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

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

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

ຜະລິດຕະພັນທີ່ພວກເຮົາຜະລິດເປັນຂອງຊອບແວວິສາຫະກິດ, ພາກສ່ວນ AIOps (ປັນຍາປະດິດສໍາລັບການປະຕິບັດງານ IT, ຫຼື ITOPs). ເປົ້າ​ຫມາຍ​ຕົ້ນ​ຕໍ​ຂອງ​ການ​ປະ​ຕິ​ບັດ​ລະ​ບົບ​ດັ່ງ​ກ່າວ​ເປັນ​ລະ​ດັບ​ການ​ໃຫຍ່​ເຕັມ​ຕົວ​ຂອງ​ຂະ​ບວນ​ການ​ໃນ​ບໍ​ລິ​ສັດ​ເພີ່ມ​ຂຶ້ນ​:

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

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

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

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

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

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

ດັ່ງນັ້ນ, ພວກເຮົາຈຶ່ງໄດ້ກໍານົດຂອບເຂດການຮ່ວມມືຫຼາຍດ້ານ:

1. ຂັ້ນ​ຕອນ​ທໍາ​ອິດ​ແມ່ນ​ການ​ຕິດ​ຕາມ umbrella ເພື່ອ​ເພີ່ມ​ຄວາມ​ໄວ​ຂອງ​ການ​ແກ້​ໄຂ​ເຫດ​ການ​
2. ຂັ້ນຕອນທີສອງແມ່ນອັດຕະໂນມັດຂະບວນການເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງແລະຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍສໍາລັບການຂະຫຍາຍພະແນກ IT.

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

ສິ່ງທີ່ສໍາຄັນຫຼາຍ, ໃນຄວາມຄິດເຫັນຂອງພວກເຮົາ, ໃນການພົວພັນກັບລູກຄ້າແມ່ນຄວາມຊື່ສັດ. ຫຼັງຈາກການສົນທະນາຄັ້ງທໍາອິດແລະການຄິດໄລ່ຄ່າໃຊ້ຈ່າຍຂອງໃບອະນຸຍາດ, ມັນໄດ້ຖືກກ່າວວ່ານັບຕັ້ງແຕ່ຄ່າໃຊ້ຈ່າຍຕ່ໍາ, ມັນອາດຈະມີມູນຄ່າຊື້ໃບອະນຸຍາດທັນທີ (ເມື່ອປຽບທຽບກັບ Dynatrace Klyuch-Astrom ຈາກບົດຄວາມຂ້າງເທິງກ່ຽວກັບທະນາຄານສີຂຽວ, ຂອງພວກເຮົາ. ໃບອະນຸຍາດບໍ່ມີຄ່າໃຊ້ຈ່າຍໃນຫນຶ່ງສ່ວນສາມຂອງຕື້, ແຕ່ 12 ພັນຮູເບີນຕໍ່ເດືອນສໍາລັບ 1 gigabyte, ສໍາລັບ Sber ມັນຈະມີລາຄາຖືກກວ່າຫຼາຍເທົ່າ). ແຕ່​ພວກ​ເຮົາ​ໄດ້​ບອກ​ເຂົາ​ເຈົ້າ​ທັນ​ທີ​ສິ່ງ​ທີ່​ພວກ​ເຮົາ​ມີ​ແລະ​ສິ່ງ​ທີ່​ພວກ​ເຮົາ​ບໍ່​ມີ. ບາງທີຜູ້ຕາງຫນ້າຝ່າຍຂາຍຈາກຜູ້ປະສົມປະສານຂະຫນາດໃຫຍ່ສາມາດເວົ້າວ່າ "ແມ່ນແລ້ວ, ພວກເຮົາສາມາດເຮັດໄດ້ທຸກຢ່າງ, ແນ່ນອນ, ຊື້ໃບອະນຸຍາດຂອງພວກເຮົາ," ແຕ່ພວກເຮົາຕັດສິນໃຈວາງບັດທັງຫມົດຂອງພວກເຮົາຢູ່ເທິງໂຕະ. ໃນເວລາເປີດຕົວ, ກ່ອງຂອງພວກເຮົາບໍ່ມີການເຊື່ອມໂຍງກັບ Prometheus, ແລະຮຸ່ນໃຫມ່ທີ່ມີລະບົບຍ່ອຍອັດຕະໂນມັດກໍາລັງຈະອອກມາ, ແຕ່ພວກເຮົາຍັງບໍ່ທັນໄດ້ສົ່ງມັນໃຫ້ກັບລູກຄ້າ.

ໂຄງການທົດລອງໄດ້ເລີ່ມຕົ້ນ, ຂອບເຂດຂອງມັນໄດ້ຖືກກໍານົດແລະພວກເຮົາໄດ້ຮັບເວລາ 2 ເດືອນ. ໜ້າທີ່ຕົ້ນຕໍແມ່ນ:

• ກະກຽມແພລະຕະຟອມສະບັບໃຫມ່ແລະນໍາໄປໃຊ້ໃນໂຄງສ້າງພື້ນຖານຂອງທະນາຄານ
• ເຊື່ອມຕໍ່ 2 ລະບົບຕິດຕາມກວດກາ (Zabbix ແລະ Prometheus);
• ສົ່ງການແຈ້ງເຕືອນໃຫ້ຜູ້ທີ່ຮັບຜິດຊອບໃນ Slack ແລະຜ່ານ SMS;
• ແລ່ນສະຄຣິບ autohealing.

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

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

ຕອນແລງຂອງການໂຕ້ວາທີກັບທີມງານພັດທະນາໄດ້ສິ້ນສຸດລົງດ້ວຍການຄົ້ນຫາທີ່ປະສົບຜົນສໍາເລັດສໍາລັບການແກ້ໄຂ. ມີ rummaged ຜ່ານ backlog, ພວກເຮົາພົບເຫັນວຽກງານຫນຶ່ງທີ່ພວກເຮົາບໍ່ເຄີຍມີເວລາພຽງພໍແລະຄວາມສໍາຄັນ - ເພື່ອສ້າງລະບົບ plug-in ເພື່ອໃຫ້ທີມງານປະຕິບັດຫຼືລູກຄ້າສາມາດຂຽນ add-ons ດ້ວຍຕົນເອງ, ຂະຫຍາຍຄວາມສາມາດຂອງເວທີ.

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

ອີງຕາມ Sergei, ຫົວຫນ້າສະຖາປະນິກຂອງພວກເຮົາ, ມັນໃຊ້ເວລາຢ່າງຫນ້ອຍຫນຶ່ງເດືອນເພື່ອປະຕິບັດລະບົບ plug-in.

ພວກເຮົາບໍ່ມີເວລາ ...

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

ຜົນຂອງການທົດລອງ, ຜົນໄດ້ຮັບດ້ານວິຊາການແລະບົດສະຫຼຸບທີ່ສໍາຄັນຫຼາຍໄດ້ຮັບ:

ພວກເຮົາໄດ້ທົດສອບຟັງຊັນໃໝ່ສຳລັບການປະມວນຜົນການແຈ້ງເຕືອນ

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

ການໂຕ້ຕອບ "ຜົນກະທົບຕໍ່ສັງເຄາະ". ຕັ້ງຄ່າການປະມວນຜົນການແຈ້ງເຕືອນຈາກລະບົບການຕິດຕາມທີ່ເຊື່ອມຕໍ່

ກໍ່ສ້າງສະຖານະຂອງ "ສຸຂະພາບ" ຂອງລະບົບ

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

ການໂຕ້ຕອບສໍາລັບການເຮັດວຽກກັບຮູບແບບການບໍລິການຊັບພະຍາກອນ. ນັກບິນ RSM.

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

ການໂຕ້ຕອບການວິເຄາະ. ຫນ້າຈໍຕິດຕາມກວດກາດຽວ.

ເປີດຕົວອັດຕະໂນມັດຂະບວນການ

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

ການໂຕ້ຕອບການຕັ້ງຄ່າການປະຕິບັດ. ສົ່ງການແຈ້ງເຕືອນໄປທີ່ Slack ແລະປິດເປີດເຊີບເວີຄືນໃໝ່.

ຂະຫຍາຍການເຮັດວຽກຂອງຜະລິດຕະພັນ

ເມື່ອສົນທະນາກ່ຽວກັບ script ອັດຕະໂນມັດ, ລູກຄ້າໄດ້ຮ້ອງຂໍໃຫ້ມີການສະຫນັບສະຫນູນ bash ແລະການໂຕ້ຕອບທີ່ scripts ເຫຼົ່ານີ້ສາມາດໄດ້ຮັບການກໍານົດຢ່າງສະດວກ. ຮຸ່ນໃຫມ່ໄດ້ເຮັດຕື່ມອີກເລັກນ້ອຍ (ຄວາມສາມາດໃນການຂຽນໂຄງສ້າງທີ່ມີເຫດຜົນເຕັມຮູບແບບໃນ Lua ດ້ວຍການສະຫນັບສະຫນູນ cURL, SSH ແລະ SNMP) ແລະປະຕິບັດຫນ້າທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດຈັດການວົງຈອນຊີວິດຂອງສະຄິບ (ສ້າງ, ແກ້ໄຂ, ການຄວບຄຸມເວີຊັນ. , ລຶບແລະເກັບໄວ້).

ການໂຕ້ຕອບສໍາລັບການເຮັດວຽກກັບ autohealing scripts. Server reboot script ຜ່ານ SSH.

ການຄົ້ນພົບຫລັກ

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

• ປະຕິບັດຄວາມສາມາດໃນການສົ່ງຕໍ່ຕົວແປໂດຍກົງຈາກການແຈ້ງເຕືອນໄປຫາ script autohealing;
• ເພີ່ມການອະນຸຍາດໃນເວທີຜ່ານ Active Directory.

ແລະພວກເຮົາໄດ້ຮັບສິ່ງທ້າທາຍທົ່ວໂລກຫຼາຍຂຶ້ນ - ເພື່ອ "ສ້າງ" ຜະລິດຕະພັນດ້ວຍຄວາມສາມາດອື່ນໆ:

• ການກໍ່ສ້າງອັດຕະໂນມັດຂອງຮູບແບບການບໍລິການຊັບພະຍາກອນໂດຍອີງໃສ່ ML, ແທນທີ່ຈະເປັນກົດລະບຽບແລະຕົວແທນ (ອາດຈະເປັນສິ່ງທ້າທາຍຕົ້ນຕໍໃນປັດຈຸບັນ);
• ສະຫນັບສະຫນູນສໍາລັບພາສາ scripting ແລະເຫດຜົນເພີ່ມເຕີມ (ແລະນີ້ຈະເປັນ JavaScript).

ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ ສໍາ​ຄັນ​ທີ່​ສຸດສິ່ງ​ທີ່​ນັກ​ບິນ​ຄົນ​ນີ້​ສະ​ແດງ​ໃຫ້​ເຫັນ​ສອງ​ຢ່າງ:

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

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