ການຖອດຂໍ້ຄວາມຂອງ webinar "SRE - hype ຫຼືອະນາຄົດ?"

webinar ມີສຽງບໍ່ດີ, ດັ່ງນັ້ນພວກເຮົາໄດ້ເຮັດບົດບັນທຶກສຽງ.

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

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

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

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

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

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

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

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

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

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

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

ນີ້ແມ່ນຜິດພາດທັງຫມົດ, ແນ່ນອນ. ແລະຄົນເຫຼົ່ານີ້ມັກຈະໄດ້ຮັບບາດເຈັບຈາກລະຫັດປະເພດນີ້ໃນການປະຕິບັດ, ເພາະວ່າສິ່ງທີ່ແຕກຫັກ. ບາງ​ຄັ້ງ​ສິ່ງ​ທີ່​ແຕກ​ຫັກ​ໃນ​ວິ​ທີ​ທີ່​ບໍ່​ຄາດ​ຄິດ​ທີ່​ສຸດ. ບາງຄັ້ງຄົນເວົ້າວ່າບໍ່, ມັນຈະບໍ່ມີວັນເກີດຂຶ້ນ. ແລະມັນຍັງເກີດຂຶ້ນ. ເກີດຂຶ້ນເລື້ອຍໆ. ແລະນັ້ນແມ່ນເຫດຜົນທີ່ບໍ່ມີໃຜພະຍາຍາມສໍາລັບຄວາມພ້ອມ 100%, ເພາະວ່າ 100% ບໍ່ເຄີຍມີມາກ່ອນ. ນີ້ແມ່ນມາດຕະຖານ. ແລະນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາເວົ້າສະເໝີກ່ຽວກັບເກົ້າເມື່ອພວກເຮົາເວົ້າກ່ຽວກັບການມີບໍລິການ. 2 ເກົ້າ, 3 ເກົ້າ, 4 ເກົ້າ, 5 ເກົ້າ. ຖ້າພວກເຮົາແປເປັນເວລາ downtime, ຕົວຢ່າງ, 5 nine ແມ່ນຫນ້ອຍກວ່າ 5 ນາທີຂອງການ downtime ຕໍ່ປີ, 2 nine ແມ່ນ 3,5 ມື້ຂອງ downtime.

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

ຄໍາຖາມທີ່ສໍາຄັນແມ່ນຄວາມຫນ້າເຊື່ອຖືຂອງອົງປະກອບທີ່ຍັງເຫຼືອແມ່ນຫຍັງ. ເນື່ອງຈາກວ່າຄວາມແຕກຕ່າງລະຫວ່າງ 4 ແລະ 5 ເກົ້າຈະບໍ່ເຫັນໄດ້ໃນໂທລະສັບສະຫຼາດທີ່ມີ 2 ຄວາມຫນ້າເຊື່ອຖືເກົ້າ. ເວົ້າໂດຍປະມານ, ຖ້າບາງສິ່ງບາງຢ່າງແຕກຢູ່ໃນໂທລະສັບສະຫຼາດໃນການບໍລິການຂອງທ່ານ 10 ເທື່ອຕໍ່ປີ, ສ່ວນຫຼາຍອາດຈະ 8 ຄັ້ງການແຕກຫັກເກີດຂື້ນໃນດ້ານ OS. ຜູ້​ໃຊ້​ໄດ້​ຖືກ​ນໍາ​ໃຊ້​ເພື່ອ​ນີ້​, ແລະ​ຈະ​ບໍ່​ໄດ້​ເອົາ​ໃຈ​ໃສ່​ກັບ​ມັນ​ຫນຶ່ງ​ຄັ້ງ​ພິ​ເສດ​ຕໍ່​ປີ​. ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະປຽບທຽບລາຄາຂອງຄວາມຫນ້າເຊື່ອຖືທີ່ເພີ່ມຂຶ້ນແລະຜົນກໍາໄລທີ່ເພີ່ມຂຶ້ນ.
ພຽງແຕ່ຢູ່ໃນປື້ມກ່ຽວກັບ SRE ມີຕົວຢ່າງທີ່ດີຂອງການເພີ່ມຂຶ້ນເປັນ 4 ເກົ້າຈາກ 3 ເກົ້າ. ມັນ turns ໃຫ້​ເຫັນ​ວ່າ​ການ​ເພີ່ມ​ຂຶ້ນ​ໃນ​ການ​ມີ​ແມ່ນ​ເລັກ​ນ້ອຍ​ຫນ້ອຍ​ກ​່​ວາ 0,1%. ແລະຖ້າລາຍຮັບຂອງການບໍລິການແມ່ນ 1 ລ້ານໂດລາຕໍ່ປີ, ລາຍໄດ້ເພີ່ມຂຶ້ນແມ່ນ 900 ໂດລາ. ຖ້າການມີໃຫ້ເພີ່ມຂຶ້ນເກົ້າເຮັດໃຫ້ພວກເຮົາຫນ້ອຍກວ່າ 900 ໂດລາຕໍ່ປີ, ການເພີ່ມຂຶ້ນເຮັດໃຫ້ຄວາມຮູ້ສຶກທາງດ້ານການເງິນ. ຖ້າມັນມີລາຄາຫຼາຍກວ່າ 900 ໂດລາຕໍ່ປີ, ມັນບໍ່ມີຄວາມ ໝາຍ ຫຍັງອີກຕໍ່ໄປ, ເພາະວ່າການເພີ່ມຂື້ນຂອງລາຍໄດ້ພຽງແຕ່ບໍ່ໄດ້ຊົດເຊີຍຄ່າແຮງງານແລະຄ່າຊັບພະຍາກອນ. ແລະ 3 ເກົ້າຈະພຽງພໍສໍາລັບພວກເຮົາ.

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

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

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

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

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

ອີກເທື່ອຫນຶ່ງ, ມີຫຼາຍບົດຄວາມ, ຫຼາຍວິທີການ, ຫຼາຍວິທີ, ເຖິງແມ່ນວ່າຢູ່ໃນຫນັງສືທີ່ຂ້າພະເຈົ້າມັກຈະອ້າງເຖິງ, ວິທີການໃຫ້ແນ່ໃຈວ່າຜູ້ພັດທະນາອື່ນໆບໍ່ເລີ່ມກຽດຊັງ SRE. ໃນທາງກົງກັນຂ້າມ, MTTR ແມ່ນກ່ຽວກັບການເຮັດວຽກໃນ SLO ຂອງທ່ານ (ຈຸດປະສົງລະດັບການບໍລິການ). ແລະນີ້ສ່ວນໃຫຍ່ແມ່ນອັດຕະໂນມັດ. ເນື່ອງຈາກວ່າ, ສໍາລັບການຍົກຕົວຢ່າງ, SLO ຂອງພວກເຮົາແມ່ນເປັນ uptime ຂອງ 4 nine ຕໍ່ໄຕມາດ. ນີ້​ຫມາຍ​ຄວາມ​ວ່າ​ໃນ 3 ເດືອນ​ພວກ​ເຮົາ​ສາ​ມາດ​ອະ​ນຸ​ຍາດ​ໃຫ້ 13 ນາ​ທີ​ຂອງ downtime​. ແລະມັນປະກົດວ່າ MTTR ຂອງພວກເຮົາບໍ່ສາມາດມີຫຼາຍກ່ວາ 13 ນາທີ. ຖ້າພວກເຮົາໃຊ້ເວລາ 13 ນາທີເພື່ອຕອບສະຫນອງຢ່າງຫນ້ອຍ 1 ເວລາຢຸດເຮັດວຽກ, ນີ້ຫມາຍຄວາມວ່າພວກເຮົາໄດ້ຫມົດງົບປະມານທັງຫມົດສໍາລັບໄຕມາດ. ພວກເຮົາລະເມີດ SLO. 13 ນາທີເພື່ອປະຕິກິລິຍາ ແລະແກ້ໄຂຄວາມລົ້ມເຫຼວແມ່ນຫຼາຍສໍາລັບເຄື່ອງຈັກ, ແຕ່ໜ້ອຍຫຼາຍສຳລັບຄົນ. ເນື່ອງຈາກວ່າໃນເວລາທີ່ບຸກຄົນໃດຫນຶ່ງໄດ້ຮັບການເຕືອນ, ເມື່ອລາວມີປະຕິກິລິຍາ, ເມື່ອລາວຄິດເຖິງຄວາມຜິດພາດ, ມັນແມ່ນສອງສາມນາທີແລ້ວ. ຈົນກ່ວາຄົນເຂົ້າໃຈວິທີການແກ້ໄຂ, ສິ່ງທີ່ແນ່ນອນຕ້ອງແກ້ໄຂ, ຈະເຮັດແນວໃດ, ມັນຈະໃຊ້ເວລາອີກສອງສາມນາທີ. ແລະໃນຄວາມເປັນຈິງ, ເຖິງແມ່ນວ່າທ່ານພຽງແຕ່ຕ້ອງການ reboot ເຄື່ອງແມ່ຂ່າຍ, ຍ້ອນວ່າມັນຫັນອອກ, ຫຼືເພີ່ມ node ໃຫມ່, ຫຼັງຈາກນັ້ນ MTTR ດ້ວຍຕົນເອງໃຊ້ເວລາປະມານ 7-8 ນາທີ. ໃນເວລາທີ່ອັດຕະໂນມັດຂະບວນການ, MTTR ຫຼາຍມັກຈະໄປຮອດວິນາທີ, ບາງຄັ້ງ milliseconds. Google ມັກຈະເວົ້າກ່ຽວກັບ milliseconds, ແຕ່ໃນຄວາມເປັນຈິງ, ແນ່ນອນ, ສິ່ງຕ່າງໆບໍ່ດີຫຼາຍ.

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

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

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

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

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

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

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

ມັນ turns ໃຫ້ ເຫັນ ວ່າ ການ ທົດ ລອງ ໃນ ການ ຜະ ລິດ ເປັນ ສ່ວນ ຫນຶ່ງ ທີ່ ສໍາ ຄັນ ແລະ ເກືອບ ສໍາ ຄັນ ຂອງ SRE ໃນ ທີມ ງານ ໃຫຍ່ . ແລະມັນມັກຈະໄປໂດຍຊື່ວິສະວະກໍາ chaos, ເຊິ່ງມາຈາກທີມງານຂອງ Netflix ທີ່ປ່ອຍຕົວເຄື່ອງໃຊ້ທີ່ເອີ້ນວ່າ Chaos Monkey.
Chaos Monkey ເຊື່ອມຕໍ່ກັບທໍ່ CI/CD ແລະການສຸ່ມເຮັດໃຫ້ເຄື່ອງແມ່ຂ່າຍ crashes ໃນການຜະລິດ. ອີກເທື່ອຫນຶ່ງ, ໃນໂຄງສ້າງ SRE ພວກເຮົາເວົ້າວ່າເຄື່ອງແມ່ຂ່າຍທີ່ crashed ແມ່ນບໍ່ບໍ່ດີໃນຕົວມັນເອງ, ຄາດວ່າຈະມີ. ແລະຖ້າຫາກວ່າມັນໄດ້ຖືກລວມເຂົ້າໃນງົບປະມານ, ມັນເປັນການຍອມຮັບແລະບໍ່ເປັນອັນຕະລາຍຕໍ່ທຸລະກິດ. ແນ່ນອນ, Netflix ມີເຄື່ອງແມ່ຂ່າຍທີ່ຊ້ໍາກັນພຽງພໍ, ການຈໍາລອງຢ່າງພຽງພໍ, ທັງຫມົດນີ້ສາມາດແກ້ໄຂໄດ້ໂດຍບໍ່ມີຜູ້ໃຊ້ທັງຫມົດສັງເກດເຫັນ, ແລະແນ່ນອນວ່າບໍ່ມີໃຜອອກຈາກເຄື່ອງແມ່ຂ່າຍສໍາລັບງົບປະມານໃດໆ.

Netflix ໃນເວລາດຽວມີຊຸດເຄື່ອງໃຊ້ດັ່ງກ່າວທັງຫມົດ, ຫນຶ່ງໃນນັ້ນ, Chaos Gorilla, ປິດການໃຊ້ງານຫນຶ່ງໃນເຂດທີ່ມີຢູ່ໃນ Amazon. ແລະສິ່ງດັ່ງກ່າວຊ່ວຍໄດ້ດີໃນການກໍານົດ, ທໍາອິດ, ການເພິ່ງພາອາໄສທີ່ເຊື່ອງໄວ້, ໃນເວລາທີ່ມັນບໍ່ຊັດເຈນທັງຫມົດວ່າມີອິດທິພົນຫຍັງ, ຂຶ້ນກັບຫຍັງ. ແລະນີ້, ຖ້າທ່ານກໍາລັງເຮັດວຽກກັບ microservice ແລະເອກະສານບໍ່ສົມບູນແບບທັງຫມົດ, ນີ້ອາດຈະຄຸ້ນເຄີຍກັບທ່ານ. ແລະອີກເທື່ອຫນຶ່ງ, ນີ້ຊ່ວຍຈັບຄວາມຜິດພາດຂອງລະຫັດທີ່ທ່ານບໍ່ສາມາດຈັບໄດ້ໃນລະຫວ່າງການສະແດງ, ເພາະວ່າຂັ້ນຕອນໃດໆບໍ່ແມ່ນການຈໍາລອງທີ່ຖືກຕ້ອງ, ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າຂະຫນາດການໂຫຼດແຕກຕ່າງກັນ, ຮູບແບບການໂຫຼດແມ່ນແຕກຕ່າງກັນ, ອຸປະກອນແມ່ນຄືກັນ. ອາດຈະ, ອື່ນໆ. ການໂຫຼດສູງສຸດຍັງສາມາດເປັນສິ່ງທີ່ບໍ່ຄາດຄິດແລະບໍ່ສາມາດຄາດເດົາໄດ້. ແລະການທົດສອບດັ່ງກ່າວ, ອີກເທື່ອຫນຶ່ງບໍ່ໄດ້ໄປເກີນງົບປະມານ, ດີຫຼາຍຊ່ວຍຈັບຄວາມຜິດພາດໃນໂຄງສ້າງພື້ນຖານທີ່ staging, autotests, ແລະ CI / CD pipelines ຈະບໍ່ຈັບໄດ້. ແລະຕາບໃດທີ່ມັນລວມຢູ່ໃນງົບປະມານຂອງເຈົ້າ, ມັນບໍ່ສໍາຄັນວ່າການບໍລິການຂອງເຈົ້າໄດ້ຫຼຸດລົງ, ເຖິງແມ່ນວ່າມັນເບິ່ງຄືວ່າເປັນຕາຢ້ານຫຼາຍ, ເຄື່ອງແມ່ຂ່າຍໄດ້ຫຼຸດລົງ, ຝັນຮ້າຍຫຍັງ. ບໍ່, ນັ້ນແມ່ນເລື່ອງປົກກະຕິ, ມັນດີ, ມັນຊ່ວຍຈັບຄວາມຜິດພາດ. ຖ້າທ່ານມີງົບປະມານ, ທ່ານສາມາດໃຊ້ມັນ.

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

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

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

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

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

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

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

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

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

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

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

ມີຄໍາຖາມກ່ຽວກັບເຄື່ອງມື SRE. ນັ້ນແມ່ນ, ມີບາງສິ່ງບາງຢ່າງສະເພາະທີ່ SREs ຈະໃຊ້ທີ່ຄົນອື່ນຈະບໍ່? ໃນຄວາມເປັນຈິງ, ມີບາງສິ່ງອໍານວຍຄວາມສະດວກພິເສດ, ມີບາງຊອບແວທີ່, ສໍາລັບການຍົກຕົວຢ່າງ, simulates ການໂຫຼດຫຼືເຮັດການທົດສອບ canary A / B. ແຕ່ໂດຍພື້ນຖານແລ້ວ, ເຄື່ອງມື SRE ແມ່ນສິ່ງທີ່ນັກພັດທະນາຂອງທ່ານໃຊ້ແລ້ວ. ເນື່ອງຈາກວ່າ SRE ພົວພັນໂດຍກົງກັບທີມງານພັດທະນາ. ແລະຖ້າຫາກວ່າທ່ານມີເຄື່ອງມືທີ່ແຕກຕ່າງກັນ, ມັນ turns ໃຫ້ເຫັນວ່າມັນໃຊ້ເວລາເພື່ອ synchronize. ໂດຍສະເພາະຖ້າ SREs ເຮັດວຽກເປັນທີມໃຫຍ່, ໃນບໍລິສັດຂະຫນາດໃຫຍ່ທີ່ອາດຈະມີຫຼາຍໆທີມ, ມາດຕະຖານຂອງບໍລິສັດຈະເປັນປະໂຫຍດຫຼາຍຢູ່ທີ່ນີ້, ເພາະວ່າຖ້າ 50 ທີມໃຊ້ 50 ເຄື່ອງມືທີ່ແຕກຕ່າງກັນ, ນີ້ຫມາຍຄວາມວ່າ SRE ຕ້ອງຮູ້ຈັກພວກເຂົາທັງຫມົດ. ແລະແນ່ນອນນີ້ຈະບໍ່ເກີດຂຶ້ນ. ແລະຄຸນນະພາບຂອງການເຮັດວຽກ, ຄຸນນະພາບຂອງການຄວບຄຸມຢ່າງຫນ້ອຍບາງທີມງານຈະຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ.

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

Slurm SRE ແມ່ນຫຼັກສູດທີ່ເຂັ້ມງວດສາມມື້ເຊິ່ງຈະກວມເອົາປະມານສິ່ງທີ່ຂ້ອຍເວົ້າກ່ຽວກັບໃນປັດຈຸບັນ, ແຕ່ມີຄວາມເລິກຫຼາຍກວ່າເກົ່າ, ດ້ວຍກໍລະນີທີ່ແທ້ຈິງ, ດ້ວຍການປະຕິບັດ, ທັງຫມົດແມ່ນສຸມໃສ່ການປະຕິບັດຕົວຈິງ. ຄົນຈະຖືກແບ່ງອອກເປັນທີມ. ທ່ານທັງຫມົດຈະເຮັດວຽກກ່ຽວກັບກໍລະນີທີ່ແທ້ຈິງ. ດັ່ງນັ້ນ, ພວກເຮົາມີຄູສອນຈາກ Booking.com Ivan Kruglov ແລະ Ben Tyler. ພວກເຮົາມີສິ່ງມະຫັດ Evgeniy Varabbas ຈາກ Google, ຈາກ San Francisco. ແລະຂ້ອຍຈະບອກເຈົ້າບາງຢ່າງເຊັ່ນກັນ. ເພາະສະນັ້ນ, ໃຫ້ແນ່ໃຈວ່າມາແລະໄປຢ້ຽມຢາມພວກເຮົາ.
ດັ່ງນັ້ນ, ບັນຊີລາຍຊື່ຂອງເອກະສານອ້າງອີງ. ມີການເຊື່ອມຕໍ່ຢູ່ໃນ SRE. ກ່ອນອື່ນ ໝົດ ໃນປຶ້ມດຽວກັນນັ້ນ, ຫຼືແທນທີ່ຈະຢູ່ໃນ 2 ປຶ້ມກ່ຽວກັບ SRE, ຂຽນໂດຍ Google. ອີກອັນນຶ່ງ ບົດຄວາມນ້ອຍໆກ່ຽວກັບ SLA, SLI, SLO, ບ່ອນທີ່ຂໍ້ກໍານົດແລະຄໍາຮ້ອງສະຫມັກຂອງເຂົາເຈົ້າໄດ້ຖືກອະທິບາຍໃນລາຍລະອຽດເພີ່ມເຕີມເລັກນ້ອຍ. 3 ຕໍ່ໄປແມ່ນບົດລາຍງານກ່ຽວກັບ SRE ໃນບໍລິສັດທີ່ແຕກຕ່າງກັນ. ຫນ້າທໍາອິດ - ລະຫັດ SRE, ນີ້ແມ່ນຄໍາສໍາຄັນຈາກ Ben Trainer ຈາກ Google. ສອງ - SRE ໃນ Dropbox. ອັນທີສາມແມ່ນອີກເທື່ອຫນຶ່ງກ່ຽວກັບ SRE ໃນ Google. ບົດລາຍງານທີສີ່ຈາກ SRE ໃນ Netflix, ເຊິ່ງມີພຽງແຕ່ 5 ພະນັກງານ SRE ທີ່ສໍາຄັນໃນ 190 ປະເທດ. ມັນຫນ້າສົນໃຈຫຼາຍທີ່ຈະເບິ່ງທັງຫມົດນີ້, ເພາະວ່າຄືກັບ DevOps ຫມາຍເຖິງສິ່ງທີ່ແຕກຕ່າງກັນຫຼາຍກັບບໍລິສັດທີ່ແຕກຕ່າງກັນແລະແມ້ກະທັ້ງທີມງານທີ່ແຕກຕ່າງກັນ, SRE ມີຄວາມຮັບຜິດຊອບທີ່ແຕກຕ່າງກັນຫຼາຍ, ເຖິງແມ່ນວ່າຢູ່ໃນບໍລິສັດທີ່ມີຂະຫນາດທີ່ຄ້າຍຄືກັນ.

2 ການເຊື່ອມຕໍ່ເພີ່ມເຕີມກ່ຽວກັບຫຼັກການຂອງວິສະວະກໍາ chaos: (1​), (2​). ແລະໃນຕອນທ້າຍມີ 3 ບັນຊີລາຍຊື່ຈາກຊຸດ Awesome Lists ກ່ຽວກັບ ວິສະວະກໍາ chaos, ກ່ຽວກັບ SRE ແລະກ່ຽວກັບ ຊຸດເຄື່ອງມື SRE. ບັນຊີລາຍຊື່ໃນ SRE ແມ່ນໃຫຍ່ຫຼວງຫຼາຍ, ທ່ານບໍ່ຈໍາເປັນຕ້ອງຜ່ານມັນທັງຫມົດ, ມີປະມານ 200 ບົດຄວາມ. ຂ້າພະເຈົ້າຂໍແນະນໍາໃຫ້ບົດຄວາມກ່ຽວກັບການວາງແຜນຄວາມອາດສາມາດແລະ postmortem ທີ່ບໍ່ມີຕໍານິ.

ບົດຂຽນທີ່ ໜ້າ ສົນໃຈ: SRE ເປັນທາງເລືອກຊີວິດ

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

PS: ສໍາລັບຜູ້ທີ່ມັກອ່ານ, Eduard ໃຫ້ບັນຊີລາຍຊື່ຂອງການອ້າງອີງ. ຜູ້ທີ່ມັກເຂົ້າໃຈໃນການປະຕິບັດແມ່ນຍິນດີຕ້ອນຮັບຢູ່ທີ່ Slurme SRE.

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