DevOps ແມ່ນຫຍັງ

ຄໍານິຍາມຂອງ DevOps ແມ່ນສັບສົນຫຼາຍ, ດັ່ງນັ້ນພວກເຮົາຕ້ອງເລີ່ມຕົ້ນການສົນທະນາກ່ຽວກັບມັນອີກເທື່ອຫນຶ່ງທຸກຄັ້ງ. ມີຫຼາຍພັນສິ່ງພິມກ່ຽວກັບຫົວຂໍ້ນີ້ຢູ່ໃນHabéຢ່າງດຽວ. ແຕ່ຖ້າຫາກວ່າທ່ານກໍາລັງອ່ານນີ້, ທ່ານອາດຈະຮູ້ວ່າ DevOps ແມ່ນຫຍັງ. ເພາະວ່າຂ້ອຍບໍ່ແມ່ນ. ສະບາຍດີ ຂ້ອຍຊື່ Alexander Titov (@osminog), ແລະພວກເຮົາຈະເວົ້າກ່ຽວກັບ DevOps ແລະຂ້ອຍຈະແບ່ງປັນປະສົບການຂອງຂ້ອຍ.

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

ໃນເວລາຫນຶ່ງຂ້າພະເຈົ້າໄດ້ຂີ່ຄື້ນຟອງຂອງການລວມຕົວແລະການຊື້ກິດຈະການ. ທໍາອິດ, ຂ້າພະເຈົ້າໄດ້ເຮັດວຽກສໍາລັບການເລີ່ມຕົ້ນຂະຫນາດນ້ອຍທີ່ເອີ້ນວ່າ Qik, ຫຼັງຈາກນັ້ນມັນຖືກຊື້ໂດຍບໍລິສັດຂະຫນາດໃຫຍ່ເລັກນ້ອຍທີ່ເອີ້ນວ່າ Skype, ເຊິ່ງຫຼັງຈາກນັ້ນໄດ້ຖືກຊື້ໂດຍບໍລິສັດຂະຫນາດໃຫຍ່ເລັກນ້ອຍທີ່ເອີ້ນວ່າ Microsoft. ໃນເວລານັ້ນ, ຂ້າພະເຈົ້າໄດ້ເລີ່ມຕົ້ນເບິ່ງວ່າແນວຄວາມຄິດຂອງ DevOps ກໍາລັງປ່ຽນແປງແນວໃດໃນບໍລິສັດຂະຫນາດຕ່າງໆ. ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ສົນໃຈເບິ່ງ DevOps ຈາກທັດສະນະຂອງຕະຫຼາດ, ແລະເພື່ອນຮ່ວມງານຂອງຂ້ອຍແລະຂ້ອຍກໍ່ຕັ້ງບໍລິສັດ Express 42. ສໍາລັບ 6 ປີໃນປັດຈຸບັນພວກເຮົາໄດ້ເຄື່ອນຍ້າຍໄປຕາມຄື້ນຂອງຕະຫຼາດ.

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

ເປັນຫຍັງ DevOps

ຄໍາຖາມທໍາອິດທີ່ haunts ທຸກຄົນແລະສະເຫມີ - ເປັນຫຍັງ? ຫຼາຍຄົນຄິດວ່າ DevOps ແມ່ນພຽງແຕ່ອັດຕະໂນມັດຫຼືສິ່ງທີ່ຄ້າຍຄືກັນທີ່ທຸກໆບໍລິສັດມີຢູ່ແລ້ວ.

— ພວກເຮົາມີການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ - ນີ້ຫມາຍຄວາມວ່າພວກເຮົາມີ DevOps ແລ້ວ, ແລະເປັນຫຍັງສິ່ງທັງຫມົດນີ້ຈຶ່ງຈໍາເປັນ? ເຂົາເຈົ້າກຳລັງມ່ວນຢູ່ຕ່າງປະເທດ, ແຕ່ເຂົາເຈົ້າຫ້າມພວກເຮົາເຮັດວຽກ!

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

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

ໃນຫຼັກການ, ທຸກສິ່ງທຸກຢ່າງໃນ IT ຄວນຖືກສ້າງຂຶ້ນຕາມວິທີການນີ້. ທີ່ນີ້ IT ຖືກນໍາໃຊ້ສະເພາະເພື່ອອັດຕະໂນມັດຂະບວນການ.

ອັດຕະໂນມັດບໍ່ປ່ຽນແປງເລື້ອຍໆ, ເພາະວ່າເມື່ອບໍລິສັດລົງໄປໃນ rut ດີ, ມີຫຍັງປ່ຽນແປງ? ມັນເຮັດວຽກ - ຢ່າແຕະຕ້ອງມັນ. ໃນປັດຈຸບັນວິທີການຕ່າງໆໃນໂລກກໍາລັງປ່ຽນແປງ, ແລະອັນທີ່ເອີ້ນວ່າ Agile ແນະນໍາວ່າຈຸດສິ້ນສຸດ B ແມ່ນບໍ່ເຫັນທັນທີທັນໃດ.

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

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

ຜະລິດຕະພັນນີ້ຖືກຊື້ໂດຍ Unilever ໃນລາຄາ 1 ຕື້ໂດລາ. ໃນປັດຈຸບັນມັນແຂ່ງຂັນກັບ Gillette ແລະໄດ້ເອົາສ່ວນແບ່ງທີ່ສໍາຄັນຂອງຜູ້ບໍລິໂພກໃນຕະຫຼາດອາເມລິກາ. One Box Shave ເວົ້າວ່າ:

— 4 ແຜ່ນ? ເຈົ້າຈິງຈັງບໍ? ເປັນຫຍັງທ່ານຕ້ອງການນີ້ - ມັນບໍ່ໄດ້ປັບປຸງຄຸນນະພາບຂອງໂກນຫນວດ. ຄຣີມທີ່ເລືອກພິເສດ, ກິ່ນຫອມ ແລະໃບມີດຄຸນນະພາບສູງ 4 ໃບ ແກ້ບັນຫາໄດ້ຫຼາຍກວ່າ 10 ໃບ Gillette ທີ່ໂງ່ຈ້າ! ພວກເຮົາຈະໄດ້ເຖິງ XNUMX ໃນໄວໆນີ້ບໍ?

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

ຈຸດຂອງ Time-to-market ບໍ່ແມ່ນວ່າພວກເຮົານຳໃຊ້ເລື້ອຍໆສໍ່າໃດ. ເຈົ້າສາມາດນຳໃຊ້ໄດ້ເລື້ອຍໆ, ແຕ່ຮອບປ່ອຍຈະຍາວ. ຖ້າຮອບປ່ອຍສາມເດືອນແມ່ນ superimposed ໃນແຕ່ລະອາທິດ, ມັນ turns ໃຫ້ເຫັນວ່າບໍລິສັດເບິ່ງຄືວ່າຈະ deploy ຫນຶ່ງອາທິດ. ແລະຈາກແນວຄວາມຄິດໄປສູ່ການຈັດຕັ້ງປະຕິບັດສຸດທ້າຍມັນໃຊ້ເວລາ 3 ເດືອນ.

Time-to-market ແມ່ນກ່ຽວກັບການຫຼຸດຜ່ອນເວລາຈາກຄວາມຄິດໄປສູ່ການຈັດຕັ້ງປະຕິບັດສຸດທ້າຍ.

ໃນກໍລະນີນີ້, ຊອບແວພົວພັນກັບຕະຫຼາດ. ນີ້ແມ່ນວິທີທີ່ເວັບໄຊທ໌ One Box Shave ພົວພັນກັບລູກຄ້າ. ພວກເຂົາບໍ່ມີພະນັກງານຂາຍ - ພຽງແຕ່ເວັບໄຊທ໌ທີ່ນັກທ່ອງທ່ຽວກົດແລະອອກຈາກຄວາມປາດຖະຫນາ. ຕາມ​ນັ້ນ​ແລ້ວ, ສິ່ງ​ໃໝ່​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ປະກາດ​ຢູ່​ໃນ​ເວັບ​ໄຊ​ຢ່າງ​ບໍ່​ຢຸດ​ຢັ້ງ ​ແລະ ປັບປຸງ​ຕາມ​ຄວາມ​ປາດ​ຖະໜາ. ສໍາລັບຕົວຢ່າງ, ໃນເກົາຫລີໃຕ້ພວກເຂົາໂກນຫນວດທີ່ແຕກຕ່າງກັນກ່ວາໃນລັດເຊຍ, ແລະພວກເຂົາມັກກິ່ນຫອມບໍ່ແມ່ນຂອງແປກ, ແຕ່, ສໍາລັບການຍົກຕົວຢ່າງ, ຂອງ carrots ແລະ vanilla.

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

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

ໃນປີ 1968, ຜູ້ມີວິໄສທັດ, Melvin Conway, ໄດ້ສ້າງແນວຄວາມຄິດຕໍ່ໄປນີ້.

ອົງການຈັດຕັ້ງທີ່ສ້າງລະບົບໄດ້ຖືກຈໍາກັດໂດຍການອອກແບບທີ່ replicates ໂຄງສ້າງການສື່ສານຂອງອົງການຈັດຕັ້ງນັ້ນ.

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

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

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

Time-to-market ແມ່ນວິທີດຽວທີ່ມັນສາມາດເຮັດໄດ້. ສໍາລັບປະຊາຊົນຜູ້ທີ່ເຮັດວຽກຢູ່ໃນຂະບວນການເກົ່າ, ນີ້ເບິ່ງຄືວ່າ cosmic ບາງຢ່າງ, ແລະໂດຍທົ່ວໄປແລ້ວ.

ດັ່ງນັ້ນເປັນຫຍັງທ່ານຕ້ອງການ DevOps?

ສໍາລັບການພັດທະນາຜະລິດຕະພັນດິຈິຕອນ. ຖ້າບໍລິສັດຂອງທ່ານບໍ່ມີຜະລິດຕະພັນດິຈິຕອນ, DevOps ແມ່ນບໍ່ຈໍາເປັນ - ມັນເປັນສິ່ງສໍາຄັນຫຼາຍ.

DevOps ເອົາຊະນະຂໍ້ຈຳກັດຄວາມໄວຂອງການຜະລິດຊອບແວຕາມລຳດັບ. ໃນມັນຂະບວນການທັງຫມົດເກີດຂຶ້ນພ້ອມໆກັນ.

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

ດ້ວຍ DevOps, ສິ່ງຕ່າງໆຈະສັບສົນຫຼາຍເທົ່ານັ້ນ.

ໃນກອງປະຊຸມຢູ່ບ່ອນຢືນຂອງ Avito, ທ່ານສາມາດເຫັນໄດ້ວ່າມັນເປັນແນວໃດໃນການຕິດຕັ້ງ Docker container - ເປັນວຽກງານທີ່ບໍ່ເປັນຈິງ. ຄວາມສັບສົນກາຍເປັນຂໍ້ຫ້າມ; ທ່ານຕ້ອງຕີລູກຫຼາຍໜ່ວຍໃນເວລາດຽວກັນ.

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

ຄໍາຖາມສໍາລັບຜູ້ຊ່ຽວຊານ

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

ທ່ານມີຍຸດທະສາດໃນການສ້າງຜະລິດຕະພັນດິຈິຕອນບໍ? ຖ້າມີ, ມັນດີແລ້ວ. ນີ້ຫມາຍຄວາມວ່າບໍລິສັດຂອງທ່ານກໍາລັງກ້າວໄປສູ່ DevOps.

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

ບໍລິສັດຂອງທ່ານເປັນຫນຶ່ງໃນຜູ້ນໍາຕະຫຼາດໃນ niche ຜະລິດຕະພັນດິຈິຕອນ? Spotify, Yandex, Uber ແມ່ນບໍລິສັດທີ່ຢູ່ໃນຈຸດສູງສຸດຂອງຄວາມກ້າວຫນ້າທາງດ້ານເຕັກໂນໂລຢີໃນປັດຈຸບັນ.

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

ອົງການຈັດຕັ້ງ

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

ບັນຫາຂອງ "ຂຸມ"

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

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

DevOps ແນະນຳໃຫ້ຜ່ານຄວາມວຸ້ນວາຍນີ້ ແລະທຸກພະແນກເຮັດວຽກຮ່ວມກັນເພື່ອສ້າງແຜນທີ່ການໂຕ້ຕອບແບບທົ່ວໄປ.

ສອງປັດໃຈຂັດຂວາງນີ້.

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

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

— ພວກ​ເຮົາ​ພຽງ​ແຕ່​ຕ້ອງ​ການ​ທີ່​ຈະ​ເປີດ CI​, ແຕ່​ວ່າ​ມັນ​ໄດ້​ກາຍ​ເປັນ​ການ​ຄຸ້ມ​ຄອງ​ບໍ່​ໄດ້​ຕ້ອງ​ການ​ມັນ​.

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

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

ປະຊາຊົນກໍາລັງສູ້ກັນສໍາລັບບາງດາວຫຼືທຸງ, ທຸກຄົນກໍາລັງຂຸດຄົ້ນຄວາມຊໍານານຂອງເຂົາເຈົ້າ.

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

ມັນຄືກັນຢູ່ໃນບໍລິສັດຂອງເຈົ້າບໍ?

ເພື່ອກວດເບິ່ງນີ້, ທ່ານສາມາດຖາມຕົວເອງຄໍາຖາມຕໍ່ໄປນີ້.

ທີມງານໃຊ້ເຄື່ອງມືທົ່ວໄປແລະປະກອບສ່ວນໃນການປ່ຽນແປງເຄື່ອງມືທົ່ວໄປເຫຼົ່ານັ້ນບໍ?

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

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

ມັນມີຄວາມສໍາຄັນແນວໃດສໍາລັບຜູ້ຈັດການທີ່ຈະໄດ້ຮັບຜົນສໍາເລັດສ່ວນບຸກຄົນໂດຍບໍ່ໄດ້ພິຈາລະນາຜົນສໍາເລັດຂອງບໍລິສັດ?

ຖ້າທ່ານຕອບຄໍາຖາມເຫຼົ່ານີ້ສໍາລັບຕົວທ່ານເອງ, ມັນຈະກາຍເປັນທີ່ຊັດເຈນກວ່າວ່າທ່ານມີບັນຫາດັ່ງກ່າວຢູ່ໃນບໍລິສັດຂອງທ່ານ.

ໂຄງສ້າງພື້ນຖານເປັນລະຫັດ

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

ສ່ວນຫຼາຍມັກ, ໂຄງລ່າງພື້ນຖານເປັນລະຫັດຖືກຮັບຮູ້ດັ່ງຕໍ່ໄປນີ້:

— ເຮັດໃຫ້ມັນອັດຕະໂນມັດທຸກຢ່າງເປັນ bash, ກວມເອົາຕົວເຮົາເອງດ້ວຍສະຄິບເພື່ອໃຫ້ຜູ້ບໍລິຫານເຮັດວຽກຄູ່ມືຫນ້ອຍລົງ!

ແຕ່ນັ້ນບໍ່ແມ່ນຄວາມຈິງ.

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

ຮ່ວມກັນກັບທີມງານອື່ນໆ, ທ່ານສ້າງແຜນທີ່ໃນຮູບແບບຂອງລະຫັດທີ່ທຸກຄົນສາມາດເຂົ້າໃຈແລະສາມາດນໍາທາງແລະນໍາທາງໄດ້. ມັນບໍ່ສໍາຄັນສິ່ງທີ່ມັນເຮັດ - Chef, Ansible, Salt, ຫຼືການນໍາໃຊ້ໄຟລ໌ YAML ໃນ Kubernetes - ບໍ່ມີຄວາມແຕກຕ່າງກັນ.

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

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

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

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

ລະຫັດກາຍເປັນພາສາທົ່ວໄປສໍາລັບວິສະວະກອນທັງຫມົດ.

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

ທີ່ສໍາຄັນ: ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ຍັງ​ບໍ່​ທັນ​ໄດ້​ພະ​ຍາ​ຍາມ​ສິ່ງ​ນີ້​, ຈື່​ໄວ້​ວ່າ​ Ansible ບໍ່ແມ່ນ bash! ອ່ານເອກະສານຢ່າງລະມັດລະວັງ, ສຶກສາສິ່ງທີ່ເຂົາເຈົ້າຂຽນກ່ຽວກັບມັນ.

Infrastructure as code ແມ່ນການແຍກລະຫັດພື້ນຖານໂຄງລ່າງອອກເປັນຊັ້ນໆ.

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


ຊັ້ນ​ພື້ນ​ຖານ​ - ນີ້ແມ່ນວິທີການ OS, ການສໍາຮອງຂໍ້ມູນແລະສິ່ງອື່ນໆທີ່ມີລະດັບຕ່ໍາ, ຕົວຢ່າງ, Kubernetes ຖືກນໍາໄປໃຊ້ໃນລະດັບພື້ນຖານ.

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

ຊັ້ນທີ່ແອັບພລິເຄຊັນຖືກສ້າງຂື້ນ ແລະອະທິບາຍວິທີທີ່ພວກມັນຈະຂະຫຍາຍຢູ່ເທິງສຸດຂອງສອງຊັ້ນກ່ອນໜ້າ.

ຄວບຄຸມຄໍາຖາມ

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

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

ການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງ

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

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

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

ການສະຫນອງວິທີການຢ່າງຕໍ່ເນື່ອງ

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

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

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

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

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

"ຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງ" ເບິ່ງຄືວ່ານີ້.

ຂະບວນການຈັດສົ່ງ Dev, CI, ການທົດສອບ, PreProd, Prod ບໍ່ແມ່ນສະພາບແວດລ້ອມແຍກຕ່າງຫາກ, ເຫຼົ່ານີ້ແມ່ນຂັ້ນຕອນຫຼືສະຖານີທີ່ມີຜົນລວມ fireproof ໂດຍຜ່ານທີ່ປອມຂອງທ່ານຜ່ານ.

ຖ້າທ່ານມີລະຫັດພື້ນຖານໂຄງລ່າງທີ່ອະທິບາຍວ່າເປັນ APP ບໍລິການພື້ນຖານ, ມັນຊ່ວຍໄດ້ ຢ່າລືມສະຄຣິບທັງໝົດ, ແລະຂຽນພວກມັນລົງເປັນລະຫັດສໍາລັບສິ່ງປະດິດນີ້, ສົ່ງເສີມສິ່ງປະດິດ ແລະປ່ຽນມັນຕາມທີ່ທ່ານໄປ.

ຄຳຖາມທົດສອບຕົນເອງ

ເວລາຈາກຄໍາອະທິບາຍລັກສະນະທີ່ຈະປ່ອຍອອກມາໃນການຜະລິດໃນ 95% ຂອງກໍລະນີແມ່ນຫນ້ອຍກວ່າຫນຶ່ງອາທິດ? ຄຸນນະພາບຂອງສິ່ງປະດິດປັບປຸງໃນແຕ່ລະຂັ້ນຕອນຂອງທໍ່ບໍ? ມີເລື່ອງທີ່ມັນຜ່ານ? ເຈົ້າໃຊ້ກົນລະຍຸດການຈັດວາງທີ່ແຕກຕ່າງກັນບໍ?

ຖ້າ​ຫາກ​ວ່າ​ຄໍາ​ຕອບ​ທັງ​ຫມົດ​ແມ່ນ​ແມ່ນ​, ຫຼັງ​ຈາກ​ນັ້ນ​ທ່ານ​ແມ່ນ​ເຢັນ incredibly​! ຂຽນຄໍາຕອບຂອງທ່ານໃນຄໍາເຫັນ - ຂ້ອຍຈະດີໃຈ).

ຂໍ້​ສະ​ເຫນີ​ແນະ

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

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

- Guys, ເປັນຫຍັງທ່ານຂົ່ມຂືນເຄື່ອງແມ່ຂ່າຍທີ່ມີບາງສິ່ງບາງຢ່າງທີ່ບໍ່ຊັດເຈນ?

​ແຕ່​ແລ້ວ​ກໍ​ມີ​ເຫດການ​ໜຶ່ງ​ເກີດ​ຂຶ້ນ​ທີ່​ສະ​ແດງ​ໃຫ້​ເຫັນ​ວ່າ​ນີ້​ແມ່ນ​ຍຸດ​ທະ​ສາດ​ທີ່​ດີ​ຫຼາຍ.

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

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

— ຜູ້ຊາຍ, ມີຫຍັງເກີດຂຶ້ນກັບເຈົ້າຫນຶ່ງອາທິດແລະເຄິ່ງຫນຶ່ງກ່ອນຫນ້ານີ້?

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

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

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

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

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

ຄໍາຖາມສໍາລັບການຄວບຄຸມຕົນເອງ

ການຕິດຕາມແລະບັນທຶກຂອງທ່ານເປັນເຄື່ອງມືພັດທະນາສໍາລັບທ່ານບໍ? ເມື່ອຂຽນລະຫັດ, ນັກພັດທະນາຂອງທ່ານ, ລວມທັງທ່ານ, ຄິດກ່ຽວກັບວິທີຕິດຕາມມັນບໍ?

ເຈົ້າໄດ້ຍິນບັນຫາຈາກລູກຄ້າບໍ? ທ່ານເຂົ້າໃຈລູກຄ້າໄດ້ດີຂຶ້ນຈາກການຕິດຕາມແລະການຕັດໄມ້ບໍ? ທ່ານເຂົ້າໃຈລະບົບທີ່ດີກວ່າຈາກການຕິດຕາມແລະບັນທຶກຂໍ້ມູນບໍ? ທ່ານປ່ຽນລະບົບພຽງແຕ່ຍ້ອນວ່າທ່ານເຫັນວ່າທ່າອ່ຽງໃນລະບົບກໍາລັງເຕີບໂຕແລະທ່ານເຂົ້າໃຈວ່າໃນອີກ 3 ອາທິດທຸກສິ່ງທຸກຢ່າງຈະຕາຍບໍ?

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

ເວທີພື້ນຖານໂຄງລ່າງ

ຈຸດບໍ່ແມ່ນວ່າມັນເປັນຊຸດຂອງເຄື່ອງມືທີ່ແຕກຕ່າງກັນທີ່ທຸກໆບໍລິສັດມີ.

ຈຸດຂອງເວທີພື້ນຖານໂຄງລ່າງແມ່ນວ່າທີມງານທັງຫມົດໃຊ້ເຄື່ອງມືເຫຼົ່ານີ້ແລະພັດທະນາຮ່ວມກັນ.

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

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

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

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

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

ໂຄງການ

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

ໃຫ້ເຮົາເບິ່ງວ່າມັນປະກອບດ້ວຍຫຍັງ.

ລະບົບ orchestration ຊັບພະຍາກອນ, ເຊິ່ງສະຫນອງ CPU, ຫນ່ວຍຄວາມຈໍາ, ແຜ່ນກັບຄໍາຮ້ອງສະຫມັກແລະການບໍລິການອື່ນໆ. ເທິງ​ນີ້ - ການບໍລິການລະດັບຕໍ່າ: ການ​ຕິດ​ຕາມ​ກວດ​ກາ​, ການ​ບັນ​ທຶກ​, CI/CD Engine​, ການ​ເກັບ​ຮັກ​ສາ​ປອມ​, ພື້ນ​ຖານ​ໂຄງ​ລ່າງ​ເປັນ​ລະ​ຫັດ​ລະ​ບົບ​.

ການບໍລິການລະດັບສູງ: database as a service, ຄິວເປັນບໍລິການ, Load Balance as a service, image resizing as a service, Big Data factory as a service. ເທິງ​ນີ້ - ທໍ່ສົ່ງລະຫັດດັດແກ້ຢ່າງຕໍ່ເນື່ອງໃຫ້ກັບລູກຄ້າຂອງທ່ານ.

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

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

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

ການສ້າງເວທີ

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

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

ເຈົ້າມີຫຍັງແດ່?

ອີກເທື່ອຫນຶ່ງ, ຄໍາຖາມທີ່ທ່ານສາມາດຖາມຕົວທ່ານເອງ.

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

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

ດັ່ງນັ້ນ, DevOps...

... ນີ້ແມ່ນລະບົບທີ່ສັບສົນ, ມັນຕ້ອງມີ:

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

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

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

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