Slurm SRE. ການທົດລອງທີ່ສົມບູນກັບຜູ້ຊ່ຽວຊານຈາກ Booking.com ແລະ Google.com

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

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

ຜູ້ເຂົ້າຮ່ວມໄດ້ຖືກແບ່ງອອກເປັນທີມເພື່ອວ່າຈິດໃຈແຂ່ງຂັນທີ່ເຂັ້ມແຂງຈະບໍ່ອະນຸຍາດໃຫ້ຜູ້ໃດນອນຫລັບຫຼືເປີດຕົວ "Angry Birds" ໃນ iPhone, ຕາມຕົວຢ່າງຂອງ Dmitry Anatolyevich.

ບັນຫາ, ຂໍ້ບົກຜ່ອງ, ຂໍ້ບົກພ່ອງ ແລະ ວຽກງານຕ່າງໆ ໄດ້ຖືກສະໜອງໃຫ້ຜູ້ເຂົ້າຮ່ວມໂດຍຄູຝຶກ 4 ຄົນ. Ivan Kruglov, ຜູ້ພັດທະນາຫຼັກຢູ່ Booking.com (ເນເທີແລນ). Ben Tyler, ຜູ້ພັດທະນາຫຼັກຢູ່ Booking.com (ສະຫະລັດ). Eduard Medvedev, CTO ຢູ່ Tungsten Labs (ເຢຍລະມັນ). Evgeniy Varavva, ຜູ້ພັດທະນາທົ່ວໄປຢູ່ Google (San Francisco).

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

Ivan, Ben, Eduard ແລະ Evgeniy ເບິ່ງຜູ້ເຂົ້າຮ່ວມ Slurm SRE ທີ່ທຸກຍາກທີ່ມີປະເພດ Leninist squints ກ່ອນທີ່ຈະເລີ່ມຕົ້ນການແຂ່ງຂັນ.

ດັ່ງ​ນັ້ນ​ວຽກ​ງານ​:

ພວກເຮົາເປັນຂອງພວກເຮົາ, ພວກເຮົາຈະສ້າງໂລກໃຫມ່ ...

ມີເວັບໄຊທ໌ລວມປີ້ຮູບເງົາ. ເຫດການແມ່ນ invented ໂດຍພີ່ລ້ຽງໃນສະຖານະການທີ່ເຮັດວຽກກ່ອນ (ເຖິງແມ່ນວ່າບໍ່ມີໃຜຍົກເວັ້ນ improvisation sophisticated ໂດຍສະເພາະແລະ insidious), ການປະຕິບັດຂອງເວັບໄຊທ໌ໄດ້ຖືກອະທິບາຍໂດຍ metrics ຕ່າງໆ. ບັນຫາສາມາດແຕກຕ່າງກັນຫຼາຍ: ປີ້ສໍາລັບໂຮງລະຄອນ Moulin Rouge ບໍ່ໄດ້ຖືກໂຫລດເຂົ້າໄປໃນຖານຂໍ້ມູນ; ໂປສເຕີຂອງຮູບເງົາແລະການສະແດງໄດ້ຖືກໂຫລດເຂົ້າໄປໃນຖານຂໍ້ມູນໃນເວລາຫຼາຍກວ່າ 10 ວິນາທີ; ລາຍລະອຽດຂອງຮູບເງົາສ່ວນບຸກຄົນ freezes; 0,1% ຂອງຄໍາສັ່ງຖືກຈອງໄວ້ແລ້ວ; ບາງຄັ້ງລະບົບການປະມວນຜົນການຈ່າຍເງິນຈະຂັດຂ້ອງເປັນເວລາໜຶ່ງ ຫຼື ສອງນາທີ. ແລະຈໍານວນຫຼາຍ, ຈໍານວນຫຼາຍ, ຫຼາຍສິ່ງທີ່ບໍ່ຫນ້າພໍໃຈທີ່ສາມາດເກີດຂຶ້ນກັບຜູ້ເຂົ້າຮ່ວມ Slurm SRE ໃນວຽກເຮັດງານທໍາທີ່ແທ້ຈິງຂອງລາວ.

ພວກເຮົາພ້ອມແລ້ວທີ່ຈະຈັດການທຸກຢ່າງ...ແລະທຸກຄົນ.

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

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

SLO, SLI, SLA

SLI - ຕົວຊີ້ວັດລະດັບການບໍລິການ. SLOs ແມ່ນເປົ້າຫມາຍລະດັບການບໍລິການ. SLA - ຂໍ້ຕົກລົງລະດັບການບໍລິການ.

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

SLO ແມ່ນຈຸດປະສົງລະດັບການບໍລິການ: ມູນຄ່າເປົ້າຫມາຍຫຼືຂອບເຂດຂອງຄ່າສໍາລັບລະດັບການບໍລິການທີ່ວັດແທກໂດຍ SLI. ຄ່າປົກກະຕິຂອງ SLO ແມ່ນ “SLI ≤ ເປົ້າໝາຍ” ຫຼື “ຂີດຈຳກັດຕ່ຳກວ່າ ≤ SLI ≤ ຂີດຈຳກັດເທິງ”.

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

ກ່ອນ​ອື່ນ​ຫມົດ​, ພວກ​ເຮົາ​ຈະ​ທໍາ​ລາຍ​ຍົນ​, ແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ສາວ​, ແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ຜູ້​ຍິງ ...

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

"- ຜູ້ເຂົ້າຮ່ວມທີ່ຮັກແພງ, ຂ້າພະເຈົ້າເລັ່ງເຮັດໃຫ້ເຈົ້າພໍໃຈ, ສິ່ງທໍາອິດທີ່ທ່ານລົ້ມເຫລວແມ່ນ ... ທຸກສິ່ງທຸກຢ່າງ!"

ຄຽງ​ຄູ່​ກັນ​ນັ້ນ, ບັນດາ​ຜູ້​ນຳ​ໄດ້​ປຶກສາ​ຫາລື​ກ່ຽວ​ກັບ​ຄວາມ​ໝັ້ນຄົງ, ງົບປະມານ​ຄວາມ​ຜິດ​ພາດ, ການ​ປະຕິບັດ​ການ​ທົດ​ສອບ, ການ​ຄຸ້ມ​ຄອງ​ການ​ຂັດ​ແຍ້ງ ​ແລະ ການ​ປະຕິບັດ​ງານ.

ເຮົາ​ບໍ່​ແມ່ນ​ຊ່າງ​ໄມ້, ບໍ່​ແມ່ນ​ຊ່າງ​ໄມ້...

ຫຼັງຈາກນັ້ນ, ຜູ້ເຂົ້າຮ່ວມໄດ້ເລີ່ມແກ້ໄຂສິ່ງຕ່າງໆ - ສິ່ງທີ່ສໍາຄັນແມ່ນເຂົ້າໃຈສິ່ງທີ່ຕ້ອງຈັບກ່ອນ.

"- ພຣະຜູ້ເປັນເຈົ້າ, ຂ້າພະເຈົ້າບໍ່ເຄີຍເຫັນມັນແຕກແບບນີ້, ໃນຮູບແບບນີ້ແລະໃນຕໍາແຫນ່ງດັ່ງກ່າວ!"

ດັ່ງນັ້ນ, ອຸບັດຕິເຫດເກີດຂຶ້ນ. ບໍລິການປະມວນຜົນການຈ່າຍເງິນຫຼຸດລົງ. ວິທີການປະຕິບັດເພື່ອຟື້ນຟູການທໍາງານໃນເວລາອັນສັ້ນທີ່ສຸດ?

ຜູ້ຊ່ຽວຊານ, ເບິ່ງດ້ວຍຄວາມຮັກຕໍ່ຜູ້ເຂົ້າຮ່ວມ, ກໍາລັງກະກຽມເຄັດລັບອື່ນ.

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

“ຄວາມຢ້ານອັນໃດອອກມາ?!”

ຫາຍໃຈອອກ ... ແລະສໍາເລັດການອອກກໍາລັງກາຍ

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

“ໃຜ​ຢາກ​ທົນ​ທຸກ! - ຂ້ອຍ!"

ຜົນສໍາເລັດຂອງທີມໄດ້ຖືກບັນທຶກໄວ້ຢ່າງເຂັ້ມງວດແລະຊັດເຈນຢູ່ໃນກະດານຄະແນນເອເລັກໂຕຣນິກ.

ສໍາລັບສະຖານທີ່ທໍາອິດ - ໂບນັດຈາກພາກສ່ວນກ່ຽວຂ້ອງ.

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