ກອງປະຊຸມສໍາລັບ fans ຂອງວິທີການ DevOps

ພວກເຮົາກໍາລັງລົມກັນ, ແນ່ນອນ, ກ່ຽວກັບ DevOpsConf. ຖ້າທ່ານບໍ່ເຂົ້າໄປໃນລາຍລະອຽດ, ຫຼັງຈາກນັ້ນໃນວັນທີ 30 ກັນຍາແລະວັນທີ 1 ເດືອນຕຸລາພວກເຮົາຈະຈັດກອງປະຊຸມກ່ຽວກັບການລວມຂະບວນການຂອງການພັດທະນາ, ການທົດສອບແລະການດໍາເນີນງານ, ແລະຖ້າທ່ານເຂົ້າໄປໃນລາຍລະອຽດ, ກະລຸນາ, ພາຍໃຕ້ cat.

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

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

ຫລັງ scenes ໄດ້

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

• ວິສະວະກອນອາວຸໂສ;
• ນັກພັດທະນາ;
• ທີມງານນໍາພາ;
• CTO.

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

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

ພາກສ່ວນກອງປະຊຸມຈະຍັງຄົງຄືກັນກັບໃນ ຄັ້ງ​ສຸດ​ທ້າຍ.

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

ໂທຫາເອກະສານ: ປະເພດຂອງບົດລາຍງານທີ່ພວກເຮົາກໍາລັງຊອກຫາ

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

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

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

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

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

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

ຖ້າ​ເຈົ້າ​ມີ​ບາງ​ສິ່ງ​ທີ່​ຈະ​ເວົ້າ​ກ່ຽວ​ກັບ​ເລື່ອງ​ເຫຼົ່າ​ນີ້, ຢ່າ​ຢູ່​ງຽບ, ສົ່ງບົດລາຍງານຂອງທ່ານ. ເສັ້ນຕາຍສໍາລັບການໂທຫາເອກະສານແມ່ນວັນທີ 20 ສິງຫາ. ຍິ່ງເຈົ້າລົງທະບຽນກ່ອນໜ້ານັ້ນ, ເຈົ້າຈະຕ້ອງໄດ້ສະຫຼຸບລາຍງານຂອງເຈົ້າ ແລະ ກຽມຕົວສຳລັບການນຳສະເໜີຂອງເຈົ້າ. ດັ່ງນັ້ນ, ຢ່າຊັກຊ້າ.

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

ພວກເຮົາເບິ່ງ DevOps ແນວໃດ

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

DevOps ເປັນລະບົບທີ່ສັບສົນ, ມັນຕ້ອງປະກອບມີ:

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

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

ທ່ານສາມາດເບິ່ງວິດີໂອຂອງບົດລາຍງານ ທີ່ນີ້.

ແລະໃນປັດຈຸບັນຈະມີໂບນັດ: ວິດີໂອຫຼາຍອັນຈາກ RIT++ 2019, ເຊິ່ງສໍາຜັດກັບບັນຫາທົ່ວໄປທີ່ສຸດຂອງການຫັນປ່ຽນ DevOps.

ໂຄງສ້າງພື້ນຖານຂອງບໍລິສັດເປັນຜະລິດຕະພັນ

Artyom Naumenko ນໍາພາທີມງານ DevOps ຢູ່ Skyeng ແລະດູແລການພັດທະນາໂຄງສ້າງພື້ນຖານຂອງບໍລິສັດລາວ. ລາວບອກວິທີການໂຄງສ້າງພື້ນຖານຜົນກະທົບຕໍ່ຂະບວນການທຸລະກິດຢູ່ SkyEng: ວິທີການຄິດໄລ່ ROI ສໍາລັບມັນ, ຕົວຊີ້ວັດອັນໃດຄວນຖືກເລືອກສໍາລັບການຄິດໄລ່ແລະວິທີການເຮັດວຽກເພື່ອປັບປຸງພວກມັນ.

ຢູ່ໃນເສັ້ນທາງໄປສູ່ການບໍລິການຈຸລະພາກ

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

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

ຜູ້ຈັດການຂອງໂຄງການດັ່ງກ່າວ inevitably ປະເຊີນກັບຄວາມຕ້ອງການທີ່ຈະຫັນປ່ຽນຂະບວນການເຕັກໂນໂລຊີທັງຫມົດ. ໃນບົດລາຍງານຂອງລາວ, Boris ເວົ້າວ່າ:

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

ອັດຕະໂນມັດຂອງການປ່ອຍຫຼືວິທີການຈັດສົ່ງຢ່າງໄວວາແລະບໍ່ເຈັບປວດ

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

ອຸບັດຕິເຫດຊ່ວຍໃຫ້ທ່ານຮຽນຮູ້ແນວໃດ?

Alexey Kirpichnikov ໄດ້ປະຕິບັດ DevOps ແລະໂຄງສ້າງພື້ນຖານຢູ່ SKB Kontur ເປັນເວລາ 5 ປີ. ໃນໄລຍະສາມປີ, ປະມານ 1000 fakaps ຂອງລະດັບທີ່ແຕກຕ່າງກັນຂອງ epic ເກີດຂຶ້ນໃນບໍລິສັດຂອງລາວ. ໃນບັນດາພວກເຂົາ, ສໍາລັບການຍົກຕົວຢ່າງ, 36% ແມ່ນເກີດມາຈາກ rolling ອອກຄຸນນະພາບຕ່ໍາໃນການຜະລິດ, ແລະ 14% ແມ່ນເກີດມາຈາກການເຮັດວຽກບໍາລຸງຮັກສາຮາດແວໃນສູນຂໍ້ມູນ.

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

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

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

ບົດລາຍງານອັນໃດທີ່ພວກເຮົາໄດ້ຮັບການຍອມຮັບເຂົ້າໃນໂຄງການ?

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

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

• ສິ່ງທີ່ຕ້ອງໄດ້ຮັບການປົກປ້ອງແລະຈາກໃຜ;
• ຂະບວນການຄວາມປອດໄພປົກກະຕິແມ່ນຫຍັງ;
• ຂະບວນການ IT ແລະຄວາມປອດໄພຂອງຂໍ້ມູນຕັດກັນແນວໃດ;
• CIS CSC ແມ່ນຫຍັງແລະວິທີການປະຕິບັດມັນ;
• ວິທີການແລະໂດຍຕົວຊີ້ວັດອັນໃດທີ່ຈະດໍາເນີນການກວດສອບຄວາມປອດໄພຂໍ້ມູນຂ່າວສານເປັນປົກກະຕິ.

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

Maxim ຈະສະແດງໃຫ້ເຫັນວ່າຮູບແບບການຈັດວາງລະຫັດເຮັດວຽກແນວໃດ, ແນໃສ່ເຮັດໃຫ້ລະບົບອັດຕະໂນມັດ ແລະການພັດທະນາງ່າຍຂຶ້ນ.

ອື່ນ ລາຍງານ ພວກເຮົາຈະໄດ້ຍິນກ່ຽວກັບໂຄງສ້າງພື້ນຖານຈາກ Vladimir Ryabov ຈາກ Playkey. ໃນທີ່ນີ້ພວກເຮົາຈະເວົ້າກ່ຽວກັບເວທີພື້ນຖານໂຄງລ່າງ, ແລະພວກເຮົາຈະຮຽນຮູ້:

• ວິທີການເຂົ້າໃຈວ່າພື້ນທີ່ເກັບຮັກສາຖືກນໍາໃຊ້ຢ່າງມີປະສິດທິພາບ;
• ຜູ້ໃຊ້ຫຼາຍຮ້ອຍຄົນສາມາດຮັບເນື້ອຫາໄດ້ 10 TB ຖ້າໃຊ້ບ່ອນຈັດເກັບຂໍ້ມູນພຽງແຕ່ 20 TB;
• ວິທີການບີບອັດຂໍ້ມູນ 5 ເທື່ອ ແລະສະໜອງໃຫ້ຜູ້ໃຊ້ໃນເວລາຈິງ;
• ວິທີການ synchronize ຂໍ້ມູນໃນການບິນລະຫວ່າງສູນຂໍ້ມູນຫຼາຍ;
• ວິທີການກໍາຈັດອິດທິພົນຂອງຜູ້ໃຊ້ຕໍ່ກັນແລະກັນໃນເວລາທີ່ໃຊ້ເຄື່ອງ virtual ດຽວກັນຕາມລໍາດັບ.

ຄວາມລັບຂອງ magic ນີ້ແມ່ນເຕັກໂນໂລຢີ ZFS ສໍາລັບ FreeBSD ແລະສ້ອມສົດຂອງມັນ ZFS ເທິງ Linux. Vladimir ຈະແບ່ງປັນກໍລະນີຈາກ Playkey.

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

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

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