ການປ່ຽນແຜ່ນອັດຕະໂນມັດດ້ວຍ Ansible

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

ບົດຄວາມນີ້ແມ່ນປະເພດຂອງການແປ ການສະແດງ ທີ່ HighLoad+ 2018

ການສ້າງຂະບວນການປ່ຽນແຜ່ນ

ຫນ້າທໍາອິດຈໍານວນຫນຶ່ງ

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

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

ເຫດການ

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

ອຸປະກອນເກັບຮັກສາແມ່ນບໍ່ມີຂໍ້ຍົກເວັ້ນ. ສະຖານະພາບຂອງພວກເຂົາຖືກຕິດຕາມໂດຍ Zabbix. ພວກ​ເຮົາ​ຕິດ​ຕາມ​ກວດ​ກາ​ຂໍ້​ຄວາມ​ໃນ Syslog ສໍາ​ລັບ​ຄວາມ​ຜິດ​ພາດ​ໃນ​ການ​ຂຽນ / ອ່ານ​, ວິ​ເຄາະ​ສະ​ຖາ​ນະ​ພາບ​ຂອງ​ການ​ໂຈມ​ຕີ HW / SW​, ຕິດ​ຕາມ​ກວດ​ກາ SMART​, ແລະ​ການ​ຄິດ​ໄລ່​ການ​ສວມ​ໃສ່​ສໍາ​ລັບ SSDs​.

ແຜ່ນຖືກປ່ຽນແປງແນວໃດກ່ອນ

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

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

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

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

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

ຂັ້ນຕອນການທົດແທນໃຫມ່

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

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

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

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

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

ກ່ອນ​ຫນ້າ​ນີ້​ມັນ​ເປັນ​ດັ່ງ​ນີ້​:

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

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

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

ຖ້າຜູ້ບໍລິຫານມີສ່ວນຮ່ວມໃນການເຮັດວຽກ, ໂຄງການຈະສັບສົນຫຼາຍ.

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

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

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

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

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

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

ບົດຮຽນທີ່ຮຽນຮູ້ໃນເວລາສ້າງ Workflow

• ເມື່ອກໍ່ສ້າງຂັ້ນຕອນ, ທ່ານຈໍາເປັນຕ້ອງເກັບກໍາຂໍ້ມູນຈາກແຫຼ່ງຕ່າງໆ.
  ບາງຄົນຂອງຜູ້ບໍລິຫານຂອງພວກເຮົາບໍ່ຮູ້ວ່າວິສະວະກອນປ່ຽນແຜ່ນດິດດ້ວຍຕົນເອງ. ບາງຄົນຄິດວ່າ MD RAID synchronization ໄດ້ຖືກຈັດການໂດຍວິສະວະກອນ, ເຖິງແມ່ນວ່າບາງສ່ວນຂອງພວກເຂົາບໍ່ມີການເຂົ້າເຖິງ. ວິສະວະກອນຊັ້ນນໍາບາງຄົນໄດ້ເຮັດສິ່ງນີ້, ແຕ່ບໍ່ແມ່ນສະເຫມີເພາະວ່າຂະບວນການດັ່ງກ່າວບໍ່ໄດ້ຖືກອະທິບາຍຢູ່ບ່ອນໃດກໍ່ຕາມ.
• ຂັ້ນຕອນຄວນຈະງ່າຍດາຍແລະເຂົ້າໃຈໄດ້.
  ມັນເປັນເລື່ອງຍາກສໍາລັບບຸກຄົນທີ່ຈະຮັກສາຫຼາຍຂັ້ນຕອນຢູ່ໃນໃຈ. ສະຖານະພາບໃກ້ຄຽງທີ່ສໍາຄັນທີ່ສຸດໃນ Jira ຄວນຖືກວາງໄວ້ໃນຫນ້າຈໍຫລັກ. ທ່ານສາມາດປ່ຽນຊື່ໃຫ້ເຂົາເຈົ້າ, ຕົວຢ່າງ, ພວກເຮົາໂທຫາ In progress Ready to change. ແລະສະຖານະອື່ນໆສາມາດຖືກເຊື່ອງໄວ້ໃນເມນູເລື່ອນລົງເພື່ອບໍ່ໃຫ້ພວກມັນເປັນຕາ. ແຕ່ມັນກໍ່ດີກວ່າທີ່ຈະບໍ່ຈໍາກັດຄົນ, ໃຫ້ພວກເຂົາມີໂອກາດທີ່ຈະຫັນປ່ຽນ.
  ອະທິບາຍຄຸນຄ່າຂອງການປະດິດສ້າງ. ເມື່ອປະຊາຊົນເຂົ້າໃຈ, ເຂົາເຈົ້າຍອມຮັບຂັ້ນຕອນໃຫມ່ຫຼາຍຂຶ້ນ. ມັນເປັນສິ່ງສໍາຄັນຫຼາຍສໍາລັບພວກເຮົາທີ່ປະຊາຊົນບໍ່ໄດ້ກົດໂດຍຜ່ານຂະບວນການທັງຫມົດ, ແຕ່ປະຕິບັດຕາມມັນ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາກໍ່ສ້າງອັດຕະໂນມັດກ່ຽວກັບເລື່ອງນີ້.
• ລໍຖ້າ, ວິເຄາະ, ຄິດອອກ.
  ມັນໃຊ້ເວລາພວກເຮົາປະມານຫນຶ່ງເດືອນເພື່ອສ້າງຂັ້ນຕອນ, ການປະຕິບັດດ້ານວິຊາການ, ກອງປະຊຸມແລະການສົນທະນາ. ແລະການຈັດຕັ້ງປະຕິບັດໃຊ້ເວລາຫຼາຍກວ່າສາມເດືອນ. ຂ້າພະເຈົ້າໄດ້ເຫັນວິທີທີ່ຄົນເຮົາເລີ່ມໃຊ້ນະວັດຕະກໍາຢ່າງຊ້າໆ. ມີ​ການ​ລົບ​ກວນ​ຫຼາຍ​ໃນ​ໄລ​ຍະ​ຕົ້ນ. ແຕ່ມັນເປັນເອກະລາດຢ່າງສົມບູນຂອງຂັ້ນຕອນຂອງມັນເອງແລະການປະຕິບັດດ້ານວິຊາການຂອງມັນ. ຕົວຢ່າງ, ຜູ້ບໍລິຫານຄົນຫນຶ່ງບໍ່ໄດ້ໃຊ້ Jira, ແຕ່ plugin Jira ໃນ Confluence, ແລະບາງສິ່ງທີ່ບໍ່ມີສໍາລັບລາວ. ພວກເຮົາໄດ້ສະແດງໃຫ້ເຂົາເຫັນ Jira, ແລະຜົນຜະລິດຂອງຜູ້ເບິ່ງແຍງໄດ້ເພີ່ມຂຶ້ນທັງສໍາລັບວຽກງານທົ່ວໄປແລະສໍາລັບການປ່ຽນແຜ່ນດິດ.

ອັດຕະໂນມັດຂອງການທົດແທນແຜ່ນ

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

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

ການຕັ້ງຄ່າສວນສັດ

ກ່ອນທີ່ພວກເຮົາຈະສົນທະນາກ່ຽວກັບ bot ໄດ້, ໃຫ້ໃຊ້ເວລາທັດສະນະສັ້ນເຂົ້າໄປໃນສວນສັດຂອງພວກເຮົາຂອງການຕິດຕັ້ງ. ກ່ອນອື່ນ ໝົດ, ມັນແມ່ນຍ້ອນຂະ ໜາດ ໃຫຍ່ຂອງໂຄງສ້າງພື້ນຖານຂອງພວກເຮົາ. ອັນທີສອງ, ພວກເຮົາພະຍາຍາມເລືອກການຕັ້ງຄ່າຮາດແວທີ່ດີທີ່ສຸດສໍາລັບແຕ່ລະບໍລິການ. ພວກເຮົາມີປະມານ 20 ແບບຮາດແວ RAID, ສ່ວນໃຫຍ່ແມ່ນ LSI ແລະ Adaptec, ແຕ່ຍັງມີ HP ແລະ DELL ຂອງຮຸ່ນທີ່ແຕກຕ່າງກັນ. ແຕ່ລະຕົວຄວບຄຸມ RAID ມີຜົນປະໂຫຍດການຈັດການຂອງຕົນເອງ. ຊຸດຂອງຄໍາສັ່ງແລະການອອກຂອງພວກເຂົາອາດຈະແຕກຕ່າງກັນຈາກສະບັບພາສາສໍາລັບແຕ່ລະຕົວຄວບຄຸມ RAID. ບ່ອນທີ່ HW-RAID ບໍ່ໄດ້ຖືກນໍາໃຊ້, mdraid ອາດຈະຖືກນໍາໃຊ້.

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

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

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

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

ໂຄງການທົ່ວໄປ

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

ຄໍາຮ້ອງສະຫມັກ DiskoBot, ລາຍລັກອັກສອນໃນ Python, ແຕ່ລະໄລຍະສໍາຫຼວດ Jira ສໍາລັບປີ້ໃຫມ່. ມັນສັງເກດເຫັນວ່າປີ້ຢູ່ໃນຄວາມຄືບຫນ້າໃຫມ່ໄດ້ປາກົດ, ກະທູ້ທີ່ສອດຄ້ອງກັນໄດ້ຖືກກະຕຸ້ນ, ເຊິ່ງເປີດຕົວ playbook ໃນ Ansible (ນີ້ແມ່ນເຮັດສໍາລັບແຕ່ລະສະຖານະພາບໃນ Jira). ໃນກໍລະນີນີ້, Prepare2change ຖືກເປີດຕົວ.

Ansible ຖືກສົ່ງໄປຫາເຈົ້າພາບ, ເອົາແຜ່ນອອກຈາກການຫມຸນແລະລາຍງານສະຖານະໃຫ້ກັບແອັບພລິເຄຊັນຜ່ານ Callbacks.

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

ອີງຕາມໂຄງການທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ, ປີ້ກັບຄືນໄປຫາ bot, ເຊິ່ງເປີດຕົວ playbook ອື່ນ, ໄປຫາເຈົ້າພາບແລະວາງແຜ່ນເຂົ້າໄປໃນການຫມຸນ. bot ປິດປີ້. ໂຫ້ຍ!

ຕອນນີ້ໃຫ້ເວົ້າກ່ຽວກັບບາງອົງປະກອບຂອງລະບົບ.

Diskobot

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

JQL ແລະໄລຍະການລົງຄະແນນສຽງແມ່ນຖືກກໍານົດໄວ້ໃນໄຟລ໌ການຕັ້ງຄ່າແອັບພລິເຄຊັນ.

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

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

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

ຖ້າ playbook ລົ້ມເຫລວ, Jira ມອບຫມາຍປ້າຍ dbot_failed ເພື່ອໃຫ້ສາມາດຈັດຮຽງຕາມພາຍຫຼັງ.

ການຮ່ວມມືກັບ Ansible

ຄໍາຮ້ອງສະຫມັກຕິດຕໍ່ສື່ສານກັບ Ansible ຜ່ານ Ansible Python API. ເພື່ອ playbook_executor ພວກເຮົາຜ່ານຊື່ໄຟລ໌ແລະຊຸດຂອງຕົວແປ. ນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດຮັກສາໂຄງການ Ansible ໃນຮູບແບບຂອງໄຟລ໌ yml ປົກກະຕິ, ແທນທີ່ຈະອະທິບາຍໃນລະຫັດ Python.

ນອກຈາກນີ້ໃນ Ansible, ຜ່ານ *extra_vars*, ຊື່ຂອງອຸປະກອນຕັນ, ສະຖານະຂອງປີ້, ເຊັ່ນດຽວກັນກັບ callback_url, ເຊິ່ງປະກອບດ້ວຍລະຫັດບັນຫາ - ມັນຖືກນໍາໃຊ້ສໍາລັບການໂທຫາກັບຄືນໄປບ່ອນໃນ HTTP.

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

ນີ້ແມ່ນຕົວຢ່າງຂອງວຽກງານທີ່ປະຕິບັດ HTTP callback.

ພວກເຮົາໄດ້ຮັບຜົນຂອງການປະຕິບັດ playbooks ໂດຍໃຊ້ callaback(s). ພວກ​ເຂົາ​ເຈົ້າ​ມີ​ສອງ​ປະ​ເພດ​:

• ປັ໊ກອິນໂທກັບທີ່ໃຊ້ໄດ້, ມັນສະຫນອງຂໍ້ມູນກ່ຽວກັບຜົນໄດ້ຮັບຂອງການປະຕິບັດ playbook. ມັນອະທິບາຍວຽກງານທີ່ໄດ້ຖືກເປີດຕົວ, ສໍາເລັດຫຼືບໍ່ສໍາເລັດ. ການເອີ້ນຄືນນີ້ຖືກເອີ້ນເມື່ອ playbook ໄດ້ສໍາເລັດການຫຼິ້ນ.
• ການໂທກັບ HTTP ເພື່ອຮັບຂໍ້ມູນໃນຂະນະທີ່ຫຼີ້ນປຶ້ມຫຼິ້ນ. ໃນວຽກງານ Ansible ພວກເຮົາປະຕິບັດຄໍາຮ້ອງຂໍ POST / GET ກັບຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ.

ຕົວແປແມ່ນຜ່ານ HTTP callback(s) ທີ່ຖືກກໍານົດໃນລະຫວ່າງການປະຕິບັດຂອງ playbook ແລະວ່າພວກເຮົາຕ້ອງການທີ່ຈະບັນທຶກແລະນໍາໃຊ້ໃນການດໍາເນີນງານຕໍ່ໄປ. ພວກເຮົາຂຽນຂໍ້ມູນນີ້ໃນ sqlite.

ພວກເຮົາຍັງອອກຄໍາເຫັນແລະປ່ຽນສະຖານະປີ້ຜ່ານ HTTP callback.

ໂທກັບ HTTP

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

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

ແລະນີ້ແມ່ນຕົວຢ່າງຈາກ playbook, ເຊິ່ງພວກເຮົາອອກແຜ່ນຈາກອຸປະກອນ MD:

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

ວຽກງານນີ້ຈະໂອນປີ້ Jira ໄປສະຖານະ “ພ້ອມທີ່ຈະປ່ຽນແປງ” ແລະເພີ່ມຄຳເຫັນ. ນອກຈາກນີ້, ຕົວແປ mdam_data ເກັບຮັກສາບັນຊີລາຍຊື່ຂອງອຸປະກອນ md ທີ່ແຜ່ນໄດ້ຖືກໂຍກຍ້າຍ, ແລະ parted_info ເກັບຮັກສາການ dump ການແບ່ງປັນຈາກການແຍກ.

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

ຮູບ​ແບບ​ການ​ກວດ​ສອບ​ອະ​ນຸ​ຍາດ​ໃຫ້​

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

ການເປີດຕົວດັ່ງກ່າວແມ່ນດໍາເນີນການຜ່ານໂມດູນການໂທກັບແຍກຕ່າງຫາກ, ແລະຜົນຂອງການປະຕິບັດ playbook ຖືກບັນທຶກໄວ້ໃນ Jira ເປັນຄໍາເຫັນ.

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

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

ນອກຈາກນັ້ນ, ປຸ່ມຖືກນໍາໃຊ້ເພື່ອ restart playbook ຖ້າມັນຂັດຂ້ອງ.

ໂຄງສ້າງຂອງ Playbooks

ຂ້າພະເຈົ້າໄດ້ກ່າວເຖິງແລ້ວວ່າຂຶ້ນກັບສະຖານະພາບຂອງປີ້ Jira, bot ເປີດຕົວປື້ມຫຼິ້ນທີ່ແຕກຕ່າງກັນ.

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

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

ພວກເຮົາໃຊ້ບົດບາດ Ansible ສໍາລັບແຕ່ລະກຸ່ມຂອງເຄື່ອງແມ່ຂ່າຍ. ທີ່ນີ້ທ່ານສາມາດເບິ່ງວິທີການ playbook(s) ຖືກຈັດຢູ່ໃນຫນຶ່ງໃນນັ້ນ.

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

Investigation.yml

ແລ່ນສໍາລັບຕົ໋ວໃນສະຖານະການສືບສວນແລະເປີດ. ສິ່ງທີ່ສໍາຄັນທີ່ສຸດສໍາລັບ playbook ນີ້ແມ່ນຊື່ອຸປະກອນຕັນ. ຂໍ້ມູນນີ້ບໍ່ມີຢູ່ສະເໝີ.

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

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

ກຽມ2change.yml

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

ໃນກໍລະນີງ່າຍດາຍທີ່ສຸດ, ພວກເຮົາເວົ້າກ່ຽວກັບການຖອນແຜ່ນຈາກ HW / MD RAID.

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

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

ປ່ຽນ.yml

ຫຼັງ​ຈາກ​ການ​ທົດ​ແທນ​ແຜ່ນ​, ພວກ​ເຮົາ​ທໍາ​ອິດ​ກວດ​ສອບ​ການ​ມີ​ຢູ່​ຂອງ​ມັນ​.

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

ພວກເຮົາເບິ່ງຄຸນລັກສະນະໃດແດ່?ພາກສ່ວນທີ່ຈັດສັນຄືນໃໝ່ນັບ (5) < 100
ປະຈຸບັນຍັງຄ້າງ Sector Count (107) == 0

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

ready.yml

ກໍ​ລະ​ນີ​ທີ່​ງ່າຍ​ທີ່​ສຸດ​: ການ​ກວດ​ສອບ HW / SW ການ​ໂຈມ​ຕີ synchronization ຫຼື​ສໍາ​ເລັດ​ການ synchronization ຂໍ້​ມູນ​ໃນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​.

API ແອັບພລິເຄຊັນ

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

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

ບົດຮຽນທີ່ຖອດຖອນໄດ້ຈາກ Ansible

ຂ້ອຍຮັກ Ansible ແທ້ໆ. ແຕ່ເລື້ອຍໆ, ເມື່ອຂ້ອຍເບິ່ງໂຄງການ opensource ທີ່ແຕກຕ່າງກັນແລະເບິ່ງວ່າຄົນຂຽນ playbooks, ຂ້ອຍຢ້ານເລັກນ້ອຍ. interweavings ຢ່າງມີເຫດຜົນທີ່ຊັບຊ້ອນຂອງເວລາທີ່ / loop, ການຂາດຄວາມຍືດຫຍຸ່ນແລະ idempotency ເນື່ອງຈາກການນໍາໃຊ້ເລື້ອຍໆຂອງ shell / ຄໍາສັ່ງ.

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

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

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

ພວກເຂົາເຈົ້າແມ່ນງ່າຍແລະໄວທີ່ຈະຂຽນ. ຕົວຢ່າງ, ໂມດູນ backlight ແຜ່ນ, ຕົວຢ່າງທີ່ສະແດງຢູ່ຂ້າງເທິງ, ປະກອບດ້ວຍ 265 ເສັ້ນ.

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

ຈຸດແຂງທີ່ສຸດຂອງ Ansible ແມ່ນຄວາມລຽບງ່າຍ ແລະປຶ້ມຫຼິ້ນທີ່ຈະແຈ້ງ. ຂ້າ​ພະ​ເຈົ້າ​ເຊື່ອ​ວ່າ​ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ນໍາ​ໃຊ້​ນີ້​ແລະ​ບໍ່​ໄດ້​ສ້າງ​ໄຟລ​໌ yaml ທີ່​ຫນ້າ​ຢ້ານ​ແລະ​ຈໍາ​ນວນ​ຫຼາຍ​ຂອງ​ເງື່ອນ​ໄຂ​, ລະ​ຫັດ shell ແລະ loops​.

ຖ້າທ່ານຕ້ອງການເຮັດຊ້ໍາປະສົບການຂອງພວກເຮົາກັບ Ansible API, ຈົ່ງຈື່ໄວ້ສອງຢ່າງ:

• Playbook_executor ແລະ playbooks ໂດຍທົ່ວໄປບໍ່ສາມາດໃຫ້ເວລາຫມົດເວລາ. ມີການໝົດເວລາໃນເຊດຊັນ ssh, ແຕ່ບໍ່ມີການໝົດເວລາໃນ playbook. ຖ້າພວກເຮົາພະຍາຍາມ unmount disk ທີ່ບໍ່ມີຢູ່ໃນລະບົບ, playbook ຈະດໍາເນີນການບໍ່ສິ້ນສຸດ, ດັ່ງນັ້ນພວກເຮົາຕ້ອງຫໍ່ການເປີດຕົວຂອງມັນຢູ່ໃນ wrapper ແຍກຕ່າງຫາກແລະຂ້າມັນຫມົດເວລາ.
• Ansible ເຮັດວຽກຢູ່ໃນຂະບວນການ forked, ດັ່ງນັ້ນ API ຂອງມັນບໍ່ປອດໄພ. ພວກເຮົາດໍາເນີນການທັງຫມົດຂອງ playbooks ຂອງພວກເຮົາ single-threaded.

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

ແຕ່ດຽວນີ້ພວກເຮົາເລີ່ມມີບັນຫາອີກຢ່າງໜຶ່ງ: ຜູ້ບໍລິຫານໃໝ່ບາງຄົນບໍ່ຮູ້ວິທີປ່ຽນໄດຣຟ໌. 🙂

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