DevOpsForum 2019. ທ່ານບໍ່ສາມາດລໍຖ້າເພື່ອປະຕິບັດ DevOps

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

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

ຫຍໍ້ມາຈາກຄຳປາໄສຂອງ Raiffeisenbank, Alfastrakhovanie, ປະສົບການຂອງ Mango Telecom ໃນການປະຕິບັດລະບົບອັດຕະໂນມັດ ແລະລາຍລະອຽດອື່ນໆພາຍໃຕ້ການຕັດ.

ຂ້ອຍຊື່ Yana, ຂ້ອຍເຮັດວຽກເປັນນັກທົດສອບ, ຂ້ອຍເຮັດອັດຕະໂນມັດ, ເຊັ່ນດຽວກັນກັບ DevOps, ແລະຂ້ອຍມັກໄປປະຊຸມແລະການປະຊຸມ. ໃນໄລຍະສອງປີທີ່ຜ່ານມາ, ຂ້າພະເຈົ້າໄດ້ໄປປະຊຸມຂອງ Oleg Bunin (HighLoad++, TeamLead Conf), ເຫດການ Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.

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

ແສງສະຫວ່າງໃນຕອນທ້າຍຂອງທໍ່ຢູ່ Raiffeisenbank

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

Mikhail Bizhan, ຜູ້ອໍານວຍການຝ່າຍອັດຕະໂນມັດຂອງ Raiffeisenbank

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

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

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

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

ອັດຕະໂນມັດຂອງການທົດສອບຢູ່ Mango Telecom

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

ຫຼັງຈາກປ່ຽນເປັນ SCRUM, ຜູ້ທົດສອບເລີ່ມປຶກສາຫາລືກັບນັກພັດທະນາກ່ຽວກັບວິທີການທົດສອບຄຸນສົມບັດຕ່າງໆ. ຄ່ອຍໆ, ປະລິມານການທໍາງານເພີ່ມຂຶ້ນ, ບໍ່ມີເອກະສານ, ແລະພວກເຂົາເລີ່ມຈັບຂໍ້ບົກພ່ອງຫຼາຍຢ່າງໃນຫນ້າທີ່ບໍ່ໄດ້ກວມເອົາໂດຍການທົດສອບແລະໂດຍທົ່ວໄປມັນບໍ່ຊັດເຈນວ່າໃຜທົດສອບມັນແລະເວລາໃດ. ໃນສັ້ນ - ສັບສົນແລະ vacillation. ພວກເຮົາໄດ້ຕັດສິນໃຈປ່ຽນໄປໃຊ້ການທົດສອບອັດຕະໂນມັດ. ແຕ່ເຖິງແມ່ນວ່າຫຼັງຈາກນັ້ນກໍ່ມີຄວາມລົ້ມເຫລວຢ່າງສົມບູນ. ພວກເຂົາເຈົ້າຈ້າງຜູ້ຊ່ຽວຊານດ້ານອັດຕະໂນມັດພາຍນອກທີ່ຂຽນໄວ້ໃນ stack ທີ່ບໍ່ຮູ້ຈັກກັບຜູ້ທົດສອບພາຍໃນ. ກອບສໍາລັບ autotests ໄດ້ເຮັດວຽກ, ແນ່ນອນ, ແຕ່ຫຼັງຈາກ outsourcers ອອກໄປ, ມັນໄດ້ແກ່ຍາວເຖິງສອງອາທິດ. ຕໍ່ໄປແມ່ນຄວາມພະຍາຍາມທີ່ຈະແນະນໍາ autotesting ຈໍານວນສອງ. ມັນເລີ່ມຕົ້ນດ້ວຍຄວາມຈິງທີ່ວ່າທຸກສິ່ງທຸກຢ່າງຕ້ອງຖືກສ້າງຂຶ້ນພາຍໃນບໍລິສັດ, ດ້ວຍຕົວຂອງທ່ານເອງ ( vector ທີ່ຖືກຕ້ອງ: ສ້າງຄວາມຊ່ຽວຊານພາຍໃນ), ພາຍໃນຂອບເຂດຂອງ SCRUM, ແລະສ້າງເອກະສານໃນຂະບວນການ. stack ສໍາລັບອັດຕະໂນມັດຄວນຈະເທົ່າກັບ stack ຂອງຜະລິດຕະພັນ (ໃນທີ່ນີ້ຂ້າພະເຈົ້າເພີ່ມມັນ, ຢ່າທົດສອບໂຄງການ JavaScript ຂອງທ່ານກັບສິ່ງອື່ນ). ໃນຕອນທ້າຍຂອງ sprint, ພວກເຂົາເຈົ້າໄດ້ເຮັດການສາທິດວິທີການ autotest ເຮັດວຽກກັບທີມງານທັງຫມົດ (ເປັນປະໂຫຍດ). ດັ່ງນັ້ນ, ການມີສ່ວນຮ່ວມຂອງສະມາຊິກທີມທັງຫມົດໃນຂະບວນການອັດຕະໂນມັດເພີ່ມຂຶ້ນ, ເຊັ່ນດຽວກັນກັບຄວາມໄວ້ວາງໃຈໃນ autotests ແລະໂອກາດທີ່ autotest ນີ້ຈະຖືກນໍາໄປໃຊ້ຢ່າງແນ່ນອນ (ແລະຈະບໍ່ສະແດງຄວາມຄິດເຫັນໃນເດືອນຫນຶ່ງຍ້ອນຄວາມລົ້ມເຫລວຢ່າງຕໍ່ເນື່ອງ).

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

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

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

ຕາຕະລາງຮອບແລະບັນຫາ DevOps ກັບຜູ້ອໍານວຍການພັດທະນາຢູ່ Alfastrakhovanie

ການໃສ່ເຄ້ກໃນ DevOpsForum 2019 ສໍາລັບຂ້ອຍແມ່ນກອງປະຊຸມເຕັມຊົ່ວໂມງກັບຜູ້ຊ່ຽວຊານ DevOps. ຜູ້ເຂົ້າຮ່ວມກອງປະຊຸມສີ່ຄົນໄດ້ຖືກເຊື້ອເຊີນໃຫ້ເບິ່ງ DevOps ຈາກມຸມທີ່ແຕກຕ່າງກັນ: Anton Isanin (Alfastrakhovanie, ຜູ້ອໍານວຍການພັດທະນາ), Nailya Zamashkina (Fintech Lab, ຜູ້ອໍານວຍການປະຕິບັດງານ), Oleg Egorkin (Rostelecom, Agile coach) ແລະ Anton Martyanov (ຜູ້ຊ່ຽວຊານເອກະລາດ, ເບິ່ງ DevOps. ຈາກທັດສະນະຂອງທຸລະກິດ).

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

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

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

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

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