ຜູ້ພັດທະນາມາຈາກດາວອັງຄານ, ຜູ້ເບິ່ງແຍງແມ່ນມາຈາກ Venus

ຄວາມບັງເອີນເປັນເລື່ອງສຸ່ມ, ແລະແທ້ຈິງແລ້ວ, ມັນແມ່ນຢູ່ໃນດາວອື່ນ ...

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

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

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

— ຄວາມ​ຮັບ​ຜິດ​ຊອບ​ສູງ​.
- ຄວາມ​ສ່ຽງ​ຂອງ​ການ​ຜະ​ລິດ​ແຕກ​.
— ມັນ​ເປັນ​ການ​ຍາກ​ທີ່​ຈະ​ເປັນ​ຜູ້​ຊ່ຽວ​ຊານ​ທີ່​ດີ​ໃນ​ທຸກ​ຂົງ​ເຂດ​.

ບໍ່ສົນໃຈ, ໃຫ້ເຮົາກ້າວຕໍ່ໄປ

ເລື່ອງທີສອງ.
ບໍລິສັດຂະຫນາດໃຫຍ່, ໂຄງການຂະຫນາດໃຫຍ່. ມີພະແນກບໍລິຫານທີ່ມີພະນັກງານ 5-7 ຄົນ ແລະກຸ່ມພັດທະນາຫຼາຍກຸ່ມ. ເມື່ອເຈົ້າມາເຮັດວຽກໃນບໍລິສັດດັ່ງກ່າວ, ທຸກໆ admin ຄິດວ່າເຈົ້າບໍ່ໄດ້ມາທີ່ນີ້ເພື່ອເຮັດວຽກກ່ຽວກັບຜະລິດຕະພັນ, ແຕ່ເພື່ອທໍາລາຍບາງສິ່ງບາງຢ່າງ. ທັງ NDA ທີ່ລົງນາມຫຼືການຄັດເລືອກຢູ່ໃນການສໍາພາດຊີ້ໃຫ້ເຫັນຖ້າບໍ່ດັ່ງນັ້ນ. ບໍ່, ຜູ້ຊາຍຄົນນີ້ມາທີ່ນີ້ດ້ວຍມືນ້ອຍໆທີ່ເປື້ອນຂອງລາວເພື່ອທໍາລາຍການຜະລິດການຈູບຂອງພວກເຮົາ. ດັ່ງນັ້ນ, ກັບບຸກຄົນດັ່ງກ່າວ, ທ່ານຕ້ອງການການສື່ສານຢ່າງຫນ້ອຍ; ຢ່າງຫນ້ອຍ, ທ່ານສາມາດຖິ້ມສະຕິກເກີເພື່ອຕອບສະຫນອງ. ຢ່າຕອບຄໍາຖາມກ່ຽວກັບສະຖາປັດຕະຍະກໍາຂອງໂຄງການ. ແນະນຳບໍ່ໃຫ້ເຂົ້າເຖິງຈົນກວ່າຫົວໜ້າທີມຖາມ. ແລະ​ເມື່ອ​ລາວ​ຂໍ, ລາວ​ຈະ​ໃຫ້​ມັນ​ກັບ​ຄືນ​ມາ​ໂດຍ​ມີ​ສິດທິ​ພິເສດ​ໜ້ອຍ​ກວ່າ​ທີ່​ເຂົາ​ເຈົ້າ​ຂໍ. ເກືອບທັງຫມົດການສື່ສານກັບຜູ້ບໍລິຫານດັ່ງກ່າວຖືກດູດຊຶມໂດຍຂຸມດໍາລະຫວ່າງພະແນກພັດທະນາແລະພະແນກບໍລິຫານ. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະແກ້ໄຂບັນຫາທັນທີທັນໃດ. ແຕ່ທ່ານບໍ່ສາມາດມາດ້ວຍຕົນເອງໄດ້ - ຜູ້ເບິ່ງແຍງລະບົບເຮັດວຽກຫຼາຍ 24/7. (ເຈົ້າເຮັດຫຍັງຢູ່ຕະຫຼອດເວລາ?) ບາງລັກສະນະການປະຕິບັດ:

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

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

ກົດຫມາຍວ່າດ້ວຍ 1. admin ແມ່ນເບິ່ງບໍ່ເຫັນ.
ມື້ປ່ອຍ, ນັກພັດທະນາແລະ admin ບໍ່ໄດ້ຕິດຕໍ່ສື່ສານ. admin ບໍ່ມີຄໍາຖາມ. ແຕ່ເຈົ້າເຂົ້າໃຈວ່າເປັນຫຍັງຕໍ່ມາ. Admin ເປັນຄົນມີຫຼັກການ, ບໍ່ມີຜູ້ສົ່ງຂ່າວ, ບໍ່ເອົາເບີໂທລະສັບຂອງລາວໃຫ້ໃຜ, ແລະບໍ່ມີໂປຣໄຟລ໌ໃນເຄືອຂ່າຍສັງຄົມ. ບໍ່ມີແມ້ແຕ່ຮູບຂອງລາວຢູ່ບ່ອນໃດ, ເຈົ້າເບິ່ງຄືແນວໃດ? ພວກເຮົານັ່ງຢູ່ກັບຜູ້ຈັດການທີ່ຮັບຜິດຊອບປະມານ 15 ນາທີໃນຄວາມແປກໃຈ, ພະຍາຍາມສ້າງການສື່ສານກັບ Voyager 1 ນີ້, ຫຼັງຈາກນັ້ນຂໍ້ຄວາມຈະປາກົດຢູ່ໃນອີເມວຂອງບໍລິສັດທີ່ລາວໄດ້ສໍາເລັດ. ພວກເຮົາຈະຕິດຕໍ່ທາງໄປສະນີບໍ? ເປັນ​ຫຍັງ​ບໍ່? ສະດວກ, ບໍ່ແມ່ນບໍ? ດີ, ໂອເຄ, ໃຫ້ເຢັນລົງ. ຂະ​ບວນ​ການ​ແມ່ນ​ໄດ້​ດໍາ​ເນີນ​ການ​, ບໍ່​ມີ​ການ​ຫັນ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​. ອ່ານຂໍ້ຄວາມອີກຄັ້ງ. "ຂ້ອຍ​ສໍາ​ເລັດ​ແລ້ວ". ເຈົ້າຈົບອັນໃດ? ຢູ່ໃສ? ຂ້ອຍຄວນຊອກຫາເຈົ້າຢູ່ໃສ? ໃນທີ່ນີ້ທ່ານເຂົ້າໃຈວ່າເປັນຫຍັງ 4 ຊົ່ວໂມງສໍາລັບການປ່ອຍແມ່ນປົກກະຕິ. ພວກເຮົາໄດ້ຮັບການຊ໊ອກການພັດທະນາ, ແຕ່ພວກເຮົາສໍາເລັດການປ່ອຍ. ບໍ່ມີຄວາມປາຖະຫນາທີ່ຈະປ່ອຍຕົວອີກຕໍ່ໄປ.

ກົດຫມາຍວ່າດ້ວຍ 2. ບໍ່ແມ່ນສະບັບນັ້ນ.
ການປ່ອຍຕໍ່ໄປ. ມີປະສົບການ, ພວກເຮົາເລີ່ມຕົ້ນສ້າງລາຍຊື່ຂອງຊອບແວແລະຫ້ອງສະຫມຸດທີ່ຈໍາເປັນສໍາລັບເຄື່ອງແມ່ຂ່າຍສໍາລັບຜູ້ບໍລິຫານ, ຊີ້ໃຫ້ເຫັນສະບັບສໍາລັບບາງຄົນ. ໃນຖານະເປັນສະເຫມີ, ພວກເຮົາໄດ້ຮັບສັນຍານວິທະຍຸທີ່ອ່ອນແອທີ່ admin ໄດ້ສໍາເລັດບາງສິ່ງບາງຢ່າງຢູ່ທີ່ນັ້ນ. ການທົດສອບການຖົດຖອຍເລີ່ມຕົ້ນ, ເຊິ່ງໃຊ້ເວລາປະມານຫນຶ່ງຊົ່ວໂມງ. ທຸກຢ່າງເບິ່ງຄືວ່າເຮັດວຽກໄດ້, ແຕ່ມີຂໍ້ບົກຜ່ອງທີ່ສໍາຄັນອັນຫນຶ່ງ. ຫນ້າທີ່ທີ່ສໍາຄັນບໍ່ເຮັດວຽກ. ສອງສາມຊົ່ວໂມງຕໍ່ໄປແມ່ນການເຕັ້ນລໍາກັບ tambourines, ການບອກໂຊກໃນພື້ນທີ່ກາເຟ, ແລະການທົບທວນຄືນລາຍລະອຽດຂອງແຕ່ລະລະຫັດ. admin ບອກວ່າລາວໄດ້ເຮັດທຸກຢ່າງ. ແອັບພລິເຄຊັນທີ່ຂຽນໂດຍຜູ້ພັດທະນາທີ່ຂີ້ຕົວະບໍ່ເຮັດວຽກ, ແຕ່ເຄື່ອງແມ່ຂ່າຍເຮັດວຽກ. ຄໍາຖາມໃດໆສໍາລັບລາວ? ໃນຕອນທ້າຍຂອງຫນຶ່ງຊົ່ວໂມງ, ພວກເຮົາໃຫ້ຜູ້ເບິ່ງແຍງເພື່ອສົ່ງສະບັບຂອງຫ້ອງສະຫມຸດໃນເຄື່ອງແມ່ຂ່າຍການຜະລິດເຂົ້າໄປໃນການສົນທະນາແລະ bingo - ມັນບໍ່ແມ່ນສິ່ງທີ່ພວກເຮົາຕ້ອງການ. ພວກເຮົາຂໍໃຫ້ຜູ້ເບິ່ງແຍງລະບົບຕິດຕັ້ງເວີຊັນທີ່ຕ້ອງການ, ແຕ່ພວກເຮົາໄດ້ຮັບວ່າລາວບໍ່ສາມາດເຮັດສິ່ງນີ້ໄດ້ເນື່ອງຈາກບໍ່ມີເວີຊັນນີ້ຢູ່ໃນຕົວຈັດການຊຸດ OS. ທີ່ນີ້, ຈາກການພັກຜ່ອນຂອງຄວາມຊົງຈໍາຂອງລາວ, ຜູ້ຈັດການຈື່ຈໍາວ່າ admin ອື່ນໄດ້ແກ້ໄຂບັນຫານີ້ແລ້ວໂດຍພຽງແຕ່ປະກອບສະບັບທີ່ຕ້ອງການດ້ວຍມື. ແຕ່ບໍ່, ຂອງພວກເຮົາຈະບໍ່ເຮັດແນວນີ້. ລະບຽບການຫ້າມ. Karl, ພວກເຮົາໄດ້ນັ່ງຢູ່ທີ່ນີ້ເປັນເວລາຫຼາຍຊົ່ວໂມງ, ກໍານົດເວລາເທົ່າໃດ?! ພວກ​ເຮົາ​ໄດ້​ຮັບ​ການ​ຊ໊ອກ​ອີກ​ຢ່າງ​ໃດ​ຫນຶ່ງ​ແລະ somehow ສໍາ​ເລັດ​ການ​ປ່ອຍ​.

ກົດຫມາຍວ່າດ້ວຍ 3, ສັ້ນ
ປີ້ດ່ວນ, ຫນ້າທີ່ທີ່ສໍາຄັນບໍ່ໄດ້ເຮັດວຽກສໍາລັບຫນຶ່ງໃນຜູ້ໃຊ້ໃນການຜະລິດ. ພວກເຮົາໃຊ້ເວລາສອງສາມຊົ່ວໂມງ poking ແລະກວດເບິ່ງ. ໃນສະພາບແວດລ້ອມການພັດທະນາ, ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ. ມີຄວາມເຂົ້າໃຈຢ່າງຈະແຈ້ງວ່າມັນຈະເປັນຄວາມຄິດທີ່ດີທີ່ຈະເບິ່ງເຂົ້າໄປໃນບັນທຶກ php-fpm. ບໍ່ມີລະບົບບັນທຶກເຊັ່ນ ELK ຫຼື Prometheus ໃນໂຄງການໃນເວລານັ້ນ. ພວກເຮົາເປີດປີ້ໄປຫາພະແນກບໍລິຫານເພື່ອໃຫ້ພວກເຂົາເຂົ້າເຖິງບັນທຶກ php-fpm ໃນເຄື່ອງແມ່ຂ່າຍ. ໃນທີ່ນີ້ທ່ານຕ້ອງເຂົ້າໃຈວ່າພວກເຮົາຮ້ອງຂໍໃຫ້ມີການເຂົ້າເຖິງດ້ວຍເຫດຜົນ, ທ່ານຈື່ບໍ່ກ່ຽວກັບຂຸມດໍາແລະຜູ້ເບິ່ງແຍງກໍາລັງຫວ່າງ 24/7? ຖ້າທ່ານຂໍໃຫ້ພວກເຂົາເບິ່ງໄມ້ທ່ອນດ້ວຍຕົວເອງ, ນີ້ແມ່ນວຽກງານທີ່ມີບູລິມະສິດ "ບໍ່ແມ່ນໃນຊີວິດນີ້". ປີ້ໄດ້ຖືກສ້າງຂື້ນ, ພວກເຮົາໄດ້ຮັບການຕອບຮັບທັນທີຈາກຫົວຫນ້າພະແນກບໍລິຫານ: "ທ່ານບໍ່ຈໍາເປັນຕ້ອງເຂົ້າເຖິງບັນທຶກການຜະລິດ, ຂຽນໂດຍບໍ່ມີຂໍ້ບົກພ່ອງ." ຜ້າມ່ານ.

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

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

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

ພວກເຮົາໄດ້ເຮັດຫຍັງແລ້ວ?
ສໍາລັບແຕ່ລະການປ່ອຍ, ບັນຊີລາຍຊື່ຂອງ Release Notes ໄດ້ຖືກສ້າງຂື້ນ, ເຊິ່ງລວມມີບັນຊີລາຍຊື່ຂອງການເຮັດວຽກທີ່ຕ້ອງເຮັດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍສໍາລັບການປ່ອຍຕໍ່ໄປເພື່ອເຮັດວຽກ. ບັນຊີລາຍຊື່ປະກອບດ້ວຍຫຼາຍພາກສ່ວນ, ວຽກງານທີ່ຄວນຈະຖືກປະຕິບັດໂດຍຜູ້ບໍລິຫານ, ຜູ້ຮັບຜິດຊອບສໍາລັບການປ່ອຍຕົວ, ແລະນັກພັດທະນາ. ນັກພັດທະນາໄດ້ຮັບການເຂົ້າເຖິງທີ່ບໍ່ແມ່ນຮາກກັບເຄື່ອງແມ່ຂ່າຍການຜະລິດທັງຫມົດ, ເຊິ່ງເລັ່ງການພັດທະນາໂດຍທົ່ວໄປແລະການແກ້ໄຂບັນຫາໂດຍສະເພາະ. ນັກພັດທະນາຍັງມີຄວາມເຂົ້າໃຈກ່ຽວກັບວິທີການຜະລິດເຮັດວຽກ, ການບໍລິການໃດທີ່ມັນຖືກແບ່ງອອກເປັນ, ບ່ອນທີ່ແລະລາຄາ replicas ຫຼາຍປານໃດ. ບາງສ່ວນຂອງການໂຫຼດການຕໍ່ສູ້ໄດ້ກາຍເປັນທີ່ຊັດເຈນ, ເຊິ່ງແນ່ນອນຜົນກະທົບຕໍ່ຄຸນນະພາບຂອງລະຫັດ. ການສື່ສານໃນລະຫວ່າງຂະບວນການປ່ອຍຕົວໄດ້ຈັດຂຶ້ນໃນການສົນທະນາຂອງຫນຶ່ງໃນຜູ້ສົ່ງຂ່າວທັນທີ. ກ່ອນອື່ນ ໝົດ, ພວກເຮົາມີບັນທຶກການກະ ທຳ ທຸກຢ່າງ, ແລະອັນທີສອງ, ການສື່ສານໄດ້ເກີດຂື້ນໃນສະພາບແວດລ້ອມທີ່ໃກ້ຊິດ. ການມີປະຫວັດຂອງການປະຕິບັດມີຫຼາຍກວ່າຫນຶ່ງຄັ້ງອະນຸຍາດໃຫ້ພະນັກງານໃຫມ່ແກ້ໄຂບັນຫາໄດ້ໄວຂຶ້ນ. ມັນເປັນຄວາມຜິດຖຽງກັນ, ແຕ່ນີ້ມັກຈະຊ່ວຍຜູ້ເບິ່ງແຍງຕົວເອງ. ຂ້ອຍຈະບໍ່ເວົ້າຢ່າງແນ່ນອນ, ແຕ່ມັນເບິ່ງຄືວ່າຂ້ອຍຜູ້ເບິ່ງແຍງໄດ້ເລີ່ມເຂົ້າໃຈວິທີການເຮັດວຽກຂອງໂຄງການແລະວິທີການຂຽນ. ບາງ​ເທື່ອ​ພວກ​ເຮົາ​ຍັງ​ໄດ້​ແບ່ງ​ປັນ​ລາຍ​ລະ​ອຽດ​ບາງ​ຢ່າງ​ໃຫ້​ກັນ​ແລະ​ກັນ. ເວລາປ່ອຍສະເລ່ຍໄດ້ຖືກຫຼຸດລົງເປັນຫນຶ່ງຊົ່ວໂມງ. ບາງຄັ້ງພວກເຮົາໄດ້ເຮັດໃນ 30-40 ນາທີ. ຈໍານວນຂອງແມງໄມ້ໄດ້ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ, ຖ້າບໍ່ແມ່ນສິບເທົ່າ. ແນ່ນອນ, ປັດໃຈອື່ນໆຍັງມີອິດທິພົນຕໍ່ການຫຼຸດຜ່ອນເວລາປ່ອຍ, ເຊັ່ນ autotests. ຫຼັງ​ຈາກ​ການ​ປ່ອຍ​ອອກ​ແຕ່​ລະ​ຄົນ​, ພວກ​ເຮົາ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ທີ່​ຈະ​ດໍາ​ເນີນ​ການ retrospective​. ເພື່ອໃຫ້ທີມງານທັງຫມົດມີຄວາມຄິດກ່ຽວກັບສິ່ງໃຫມ່, ສິ່ງທີ່ປ່ຽນແປງ, ແລະສິ່ງທີ່ຖືກລົບອອກ. ແຕ່ຫນ້າເສຍດາຍ, admin ບໍ່ໄດ້ມາຫາພວກເຂົາສະເຫມີ, ດີ, admin ກໍາລັງຫຍຸ້ງຢູ່ ... ຄວາມພໍໃຈໃນການເຮັດວຽກຂອງຂ້ອຍເປັນນັກພັດທະນາໄດ້ເພີ່ມຂຶ້ນຢ່າງບໍ່ຕ້ອງສົງໃສ. ເມື່ອເຈົ້າສາມາດແກ້ໄຂໄດ້ໄວເກືອບທຸກບັນຫາທີ່ຢູ່ໃນພື້ນທີ່ຄວາມສາມາດຂອງເຈົ້າ, ເຈົ້າຮູ້ສຶກວ່າຢູ່ເທິງສຸດ. ຕໍ່ມາ, ຂ້າພະເຈົ້າຈະເຂົ້າໃຈວ່າໃນບາງຂອບເຂດທີ່ພວກເຮົາໄດ້ນໍາສະເຫນີວັດທະນະທໍາ devops, ແນ່ນອນ, ບໍ່ແມ່ນທັງຫມົດ, ແຕ່ເຖິງແມ່ນວ່າການເລີ່ມຕົ້ນຂອງການຫັນເປັນທີ່ຫນ້າປະທັບໃຈ.

ເລື່ອງສາມ
ເລີ່ມ​ຕົ້ນ. ຫນຶ່ງ admin, ພະແນກພັດທະນາຂະຫນາດນ້ອຍ. ເມື່ອມາຮອດຂ້ອຍເປັນສູນທີ່ສົມບູນ, ເພາະວ່າ ... ຂ້ອຍບໍ່ສາມາດເຂົ້າເຖິງໄດ້ຈາກທາງໄປສະນີ. ພວກເຮົາຂຽນໄປຫາຜູ້ເບິ່ງແຍງແລະຂໍໃຫ້ເຂົ້າເຖິງ. ນອກຈາກນັ້ນ, ມີຂໍ້ມູນທີ່ລາວຮູ້ເຖິງພະນັກງານໃຫມ່ແລະຄວາມຕ້ອງການທີ່ຈະອອກການເຂົ້າສູ່ລະບົບ / ລະຫັດຜ່ານ. ພວກເຂົາເຈົ້າໃຫ້ການເຂົ້າເຖິງຈາກ repository ແລະ VPN. ເປັນຫຍັງຈຶ່ງໃຫ້ການເຂົ້າເຖິງ wiki, teamcity, rundesk? ສິ່ງທີ່ບໍ່ມີປະໂຫຍດສໍາລັບບຸກຄົນທີ່ຖືກເອີ້ນໃຫ້ຂຽນສ່ວນ backend ທັງຫມົດ. ພຽງແຕ່ເມື່ອເວລາຜ່ານໄປພວກເຮົາສາມາດເຂົ້າເຖິງບາງເຄື່ອງມື. ການມາຮອດ, ແນ່ນອນ, ໄດ້ພົບກັບຄວາມບໍ່ໄວ້ວາງໃຈ. ຂ້ອຍພະຍາຍາມຄ່ອຍໆຮູ້ສຶກວ່າໂຄງສ້າງພື້ນຖານຂອງໂຄງການເຮັດວຽກແນວໃດຜ່ານການສົນທະນາແລະຄໍາຖາມນໍາ. ໂດຍພື້ນຖານແລ້ວຂ້ອຍບໍ່ຮັບຮູ້ຫຍັງເລີຍ. ການຜະລິດເປັນກ່ອງດໍາດຽວກັນກັບທີ່ຜ່ານມາ. ແຕ່ຫຼາຍກວ່ານັ້ນ, ເຖິງແມ່ນວ່າເຄື່ອງແມ່ຂ່າຍເວທີທີ່ໃຊ້ສໍາລັບການທົດສອບແມ່ນກ່ອງສີດໍາ. ພວກເຮົາບໍ່ສາມາດເຮັດຫຍັງໄດ້ນອກເໜືອໄປຈາກການນຳໃຊ້ສາຂາຈາກ Git ຢູ່ທີ່ນັ້ນ. ພວກເຮົາຍັງບໍ່ສາມາດຕັ້ງຄ່າແອັບພລິເຄຊັນຂອງພວກເຮົາເຊັ່ນໄຟລ໌ .env. ການເຂົ້າເຖິງສໍາລັບການປະຕິບັດງານດັ່ງກ່າວແມ່ນບໍ່ໄດ້ຮັບອະນຸຍາດ. ທ່ານຕ້ອງຂໍຮ້ອງເພື່ອປ່ຽນເສັ້ນໃນ config ຂອງຄໍາຮ້ອງສະຫມັກຂອງທ່ານໃນເຄື່ອງແມ່ຂ່າຍການທົດສອບ. (ມີທິດສະດີວ່າມັນເປັນສິ່ງສໍາຄັນສໍາລັບຜູ້ບໍລິຫານທີ່ຈະຮູ້ສຶກວ່າຕົນເອງມີຄວາມສໍາຄັນໃນໂຄງການ; ຖ້າພວກເຂົາບໍ່ໄດ້ຖືກຮ້ອງຂໍໃຫ້ປ່ຽນສາຍໃນການຕັ້ງຄ່າ, ພວກມັນຈະບໍ່ຈໍາເປັນ). ແລ້ວ, ເຊັ່ນດຽວກັບ, ມັນບໍ່ສະດວກບໍ? ນີ້ເຮັດໃຫ້ຫນ້າເບື່ອຢ່າງໄວວາ, ຫຼັງຈາກການສົນທະນາໂດຍກົງກັບ admin ພວກເຮົາພົບວ່ານັກພັດທະນາໄດ້ເກີດມາເພື່ອຂຽນລະຫັດທີ່ບໍ່ດີ, ໂດຍທໍາມະຊາດແມ່ນບຸກຄົນທີ່ບໍ່ມີຄວາມສາມາດແລະມັນດີກວ່າທີ່ຈະໃຫ້ພວກເຂົາຢູ່ຫ່າງຈາກການຜະລິດ. ແຕ່ໃນທີ່ນີ້ຍັງມາຈາກເຄື່ອງແມ່ຂ່າຍການທົດສອບ, ພຽງແຕ່ໃນກໍລະນີ. ຄວາມຂັດແຍ້ງແມ່ນເພີ່ມຂຶ້ນຢ່າງໄວວາ. ບໍ່ມີການສື່ສານກັບ admin. ສະຖານະການແມ່ນຮ້າຍແຮງຂຶ້ນໂດຍຄວາມຈິງທີ່ວ່າລາວຢູ່ຄົນດຽວ. ຕໍ່ໄປນີ້ແມ່ນຮູບພາບທົ່ວໄປ. ປ່ອຍ. ການທໍາງານທີ່ແນ່ນອນບໍ່ເຮັດວຽກ. ມັນໃຊ້ເວລາດົນທີ່ຈະຄິດເຖິງສິ່ງທີ່ເກີດຂຶ້ນ, ແນວຄວາມຄິດຕ່າງໆຈາກນັກພັດທະນາໄດ້ຖືກຖິ້ມເຂົ້າໄປໃນການສົນທະນາ, ແຕ່ຜູ້ເບິ່ງແຍງໃນສະຖານະການດັ່ງກ່າວມັກຈະຖືວ່ານັກພັດທະນາຕ້ອງຕໍານິ. ຫຼັງຈາກນັ້ນ, ລາວຂຽນໃນການສົນທະນາ, ລໍຖ້າ, ຂ້ອຍແກ້ໄຂລາວ. ເມື່ອຖືກຖາມໃຫ້ປະເລື່ອງລາວໄວ້ເບື້ອງຫຼັງດ້ວຍຂໍ້ມູນກ່ຽວກັບວ່າບັນຫາແມ່ນຫຍັງ, ພວກເຮົາໄດ້ຮັບຂໍ້ແກ້ຕົວທີ່ເປັນພິດ. ເຊັ່ນດຽວກັນກັບ, ຢ່າຕິດດັງຂອງເຈົ້າບ່ອນທີ່ມັນບໍ່ເປັນ. ນັກພັດທະນາຕ້ອງຂຽນລະຫັດ. ສະຖານະການໃນເວລາທີ່ການເຄື່ອນໄຫວຂອງຮ່າງກາຍຫຼາຍໃນໂຄງການຜ່ານຫນຶ່ງຄົນດຽວແລະພຽງແຕ່ລາວສາມາດເຂົ້າເຖິງການດໍາເນີນງານທີ່ທຸກຄົນຕ້ອງການແມ່ນຫນ້າເສົ້າໃຈທີ່ສຸດ. ຄົນດັ່ງກ່າວເປັນຄໍຂວດຂີ້ຮ້າຍ. ຖ້າແນວຄວາມຄິດຂອງ Devops ພະຍາຍາມຫຼຸດຜ່ອນເວລາຕໍ່ຕະຫຼາດ, ຄົນດັ່ງກ່າວເປັນສັດຕູທີ່ຮ້າຍແຮງທີ່ສຸດຂອງແນວຄວາມຄິດຂອງ Devops. ແຕ່ຫນ້າເສຍດາຍ, ຜ້າມ່ານປິດຢູ່ທີ່ນີ້.

P.S. ຫຼັງຈາກເວົ້າເລັກນ້ອຍກ່ຽວກັບນັກພັດທະນາ vs admins ໃນການສົນທະນາກັບຄົນ, ຂ້າພະເຈົ້າໄດ້ພົບກັບຄົນທີ່ແບ່ງປັນຄວາມເຈັບປວດຂອງຂ້ອຍ. ​ແຕ່​ກໍ​ຍັງ​ມີ​ຜູ້​ເວົ້າ​ວ່າ​ເຂົາ​ເຈົ້າ​ບໍ່​ເຄີຍ​ໄດ້​ພົບ​ເຫັນ​ຫຍັງ​ຄື​ແນວ​ນີ້. ໃນກອງປະຊຸມ devops ຫນຶ່ງ, ຂ້າພະເຈົ້າໄດ້ຖາມ Anton Isanin (Alfa Bank) ວິທີທີ່ພວກເຂົາຈັດການກັບບັນຫາຂອງຄໍຂວດໃນຮູບແບບຂອງຜູ້ເບິ່ງແຍງ, ເຊິ່ງລາວເວົ້າວ່າ: "ພວກເຮົາໄດ້ປ່ຽນປຸ່ມຕ່າງໆ." ໂດຍວິທີທາງການ ພອດແຄສ ດ້ວຍການເຂົ້າຮ່ວມຂອງລາວ. ຂ້າພະເຈົ້າຢາກເຊື່ອວ່າມີຜູ້ບໍລິຫານທີ່ດີຫຼາຍກ່ວາສັດຕູ. ແລະແມ່ນແລ້ວ, ຮູບພາບໃນຕອນຕົ້ນແມ່ນການຕອບທີ່ແທ້ຈິງ.

ທີ່ມາ: www.habr.com