ຫ້າບັນຫາໃນຂະບວນການປະຕິບັດງານແລະການສະຫນັບສະຫນູນລະບົບ IT ສູງ

ສະບາຍດີ, Habr! ຂ້ອຍໄດ້ສະຫນັບສະຫນູນລະບົບ IT Highload ສໍາລັບສິບປີ. ຂ້ອຍຈະບໍ່ຂຽນໃນບົດຄວາມນີ້ກ່ຽວກັບບັນຫາຂອງການຕັ້ງຄ່າ nginx ເພື່ອເຮັດວຽກໃນໂຫມດ 1000+ RPS ຫຼືສິ່ງດ້ານວິຊາການອື່ນໆ. ຂ້ອຍຈະແບ່ງປັນຂໍ້ສັງເກດຂອງຂ້ອຍກ່ຽວກັບບັນຫາໃນຂະບວນການທີ່ເກີດຂື້ນໃນການສະຫນັບສະຫນູນແລະການດໍາເນີນງານຂອງລະບົບດັ່ງກ່າວ.

ການຕິດຕາມ

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

ຈະເຮັດແນວໃດກັບສະຖານະການໃນເວລາທີ່ສິນຄ້າທີ່ຍັງເຫຼືອຂອງຮ້ານອອນໄລນ໌ບໍ່ໄດ້ມາຮອດຈາກລະບົບ ERP? ຫຼືມີລະບົບ CRM ທີ່ຄິດໄລ່ສ່ວນຫຼຸດສໍາລັບລູກຄ້າຢຸດເຊົາການຕອບສະຫນອງ? ເວັບໄຊດັ່ງກ່າວເບິ່ງຄືວ່າເຮັດວຽກ. ເງື່ອນໄຂ Zabbix ໄດ້ຮັບການຕອບສະຫນອງ 200 ຂອງຕົນ. ການປ່ຽນໜ້າທີ່ບໍ່ໄດ້ຮັບການແຈ້ງເຕືອນໃດໆຈາກການຕິດຕາມ ແລະກຳລັງເບິ່ງຕອນທຳອິດຂອງລະດູການໃໝ່ຂອງ Game of Thrones ຢ່າງມີຄວາມສຸກ.

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

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

ການພົວພັນກັບລະບົບພາຍນອກ

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

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

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

ທຸກໆລະບົບທີ່ທ່ານພົວພັນກັບຄວນສະຫນອງການສະຫນັບສະຫນູນເປັນການບໍລິການທີ່ມີ SLA ທີ່ຊັດເຈນເພື່ອແກ້ໄຂບັນຫາໂດຍບູລິມະສິດ. ແລະບໍ່ແມ່ນເວລາທີ່ admin ເງື່ອນໄຂ Andrey ມີນາທີສໍາລັບທ່ານ.

ຜູ້ຊາຍຄໍຕຸກ

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

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

ຄວາມສາມາດແລະຄວາມຮັບຜິດຊອບຂອງພະນັກງານສະຫນັບສະຫນູນ

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

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

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

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

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

ການໂຕ້ຕອບກັບທີມງານພັດທະນາ

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

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

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

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

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

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

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