ໂຄງສ້າງພື້ນຖານເປັນລະຫັດ: ວິທີການເອົາຊະນະບັນຫາໂດຍໃຊ້ XP

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

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

ພວກເຮົາແມ່ນໃຜ, ພວກເຮົາຢູ່ໃສແລະພວກເຮົາມີບັນຫາຫຍັງ

ໃນປັດຈຸບັນພວກເຮົາຢູ່ໃນທີມງານ Sre Onboarding, ເຊິ່ງປະກອບດ້ວຍນັກຂຽນໂປລແກລມຫົກຄົນແລະວິສະວະກອນໂຄງສ້າງພື້ນຖານສາມຄົນ. ພວກເຮົາທຸກຄົນພະຍາຍາມຂຽນ Infrastructure ເປັນລະຫັດ (IaC). ພວກເຮົາເຮັດສິ່ງນີ້ເພາະວ່າໂດຍພື້ນຖານແລ້ວພວກເຮົາຮູ້ວິທີການຂຽນລະຫັດແລະມີປະຫວັດການເປັນນັກພັດທະນາ "ສູງກວ່າຄ່າສະເລ່ຍ".

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

stack ເຕັກໂນໂລຢີທີ່ພວກເຮົາໃຊ້ໃນ IaC ຂອງພວກເຮົາ.

• Terraform ສໍາລັບການສ້າງຊັບພະຍາກອນ.
• Packer ສໍາລັບປະກອບຮູບພາບ. ເຫຼົ່ານີ້ແມ່ນ Windows, CentOS 7 ຮູບພາບ.
• Jsonnet ເພື່ອສ້າງຄວາມເຂັ້ມແຂງໃນ drone.io, ເຊັ່ນດຽວກັນກັບການສ້າງ packer json ແລະໂມດູນ terraform ຂອງພວກເຮົາ.
• ສີຟ້າສົດ.
• Ansible ໃນເວລາທີ່ກະກຽມຮູບພາບ.
• Python ສໍາລັບການບໍລິການຊ່ວຍແລະການສະຫນອງສະຄິບ.
• ແລະທັງຫມົດນີ້ໃນ VSCode ກັບ plugins ແບ່ງປັນລະຫວ່າງສະມາຊິກທີມງານ.

ສະຫຼຸບຈາກຂອງຂ້ອຍ ບົດຄວາມສຸດທ້າຍ ເປັນແບບນີ້: ຂ້ອຍພະຍາຍາມປູກຝັງ (ກ່ອນອື່ນໝົດໃນຕົວຂ້ອຍເອງ) ມອງໃນແງ່ດີ, ຂ້ອຍຢາກບອກວ່າຈະພະຍາຍາມວິທີການ ແລະ ການປະຕິບັດທີ່ຮູ້ຈັກກັບພວກເຮົາເພື່ອຮັບມືກັບຄວາມຫຍຸ້ງຍາກ ແລະ ຄວາມສັບສົນທີ່ມີຢູ່ໃນຂົງເຂດນີ້.

ພວກເຮົາກຳລັງປະສົບກັບບັນຫາ IaC ຕໍ່ໄປນີ້:

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

Extreme Programming (XP) ເພື່ອກູ້ໄພ

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

ກວດເບິ່ງຄວາມສາມາດໃຊ້ໄດ້ຂອງວິທີການ XP ກັບອຸດສາຫະກໍາຂອງທ່ານນີ້ແມ່ນຄໍາອະທິບາຍກ່ຽວກັບສະພາບແວດລ້ອມທີ່ XP ເຫມາະສໍາລັບ, ແລະວ່າມັນກ່ຽວຂ້ອງກັບພວກເຮົາແນວໃດ:

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

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

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

ຂໍໃຫ້ເບິ່ງບາງການປະຕິບັດ XP ແລະວິທີການທີ່ພວກມັນມີຜົນກະທົບຕໍ່ຄວາມໄວແລະຄຸນນະພາບຂອງຄໍາຕິຊົມ.

XP Feedback ຫຼັກການ Loop

ໃນຄວາມເຂົ້າໃຈຂອງຂ້ອຍ, ຄໍາຄຶດຄໍາເຫັນແມ່ນຄໍາຕອບຂອງຄໍາຖາມ, ຂ້ອຍເຮັດສິ່ງທີ່ຖືກຕ້ອງ, ພວກເຮົາກໍາລັງໄປບ່ອນນັ້ນບໍ? XP ມີ​ໂຄງ​ການ​ອັນ​ສູງ​ສົ່ງ​ສໍາ​ລັບ​ການ​ນີ້​: loop ຄໍາ​ຄຶດ​ຄໍາ​ເຫັນ​ທີ່​ໃຊ້​ເວ​ລາ​. ສິ່ງທີ່ຫນ້າສົນໃຈແມ່ນວ່າພວກເຮົາຕ່ໍາກວ່າ, ພວກເຮົາສາມາດໄດ້ຮັບ OS ເພື່ອຕອບຄໍາຖາມທີ່ຈໍາເປັນ.

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

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

ສິ່ງສໍາຄັນ: ຄວາມຄິດເຫັນສາມາດເປັນການແກ້ໄຂທຸກບັນຫາທີ່ໄດ້ກ່າວມາຂ້າງເທິງ. ສົມທົບກັບການປະຕິບັດ XP, ມັນສາມາດດຶງເຈົ້າອອກຈາກຄວາມສິ້ນຫວັງ.

ວິທີການດຶງຕົວເອງອອກຈາກເຫວເລິກຂອງຄວາມສິ້ນຫວັງ: ສາມການປະຕິບັດ

ການທົດສອບ

ການທົດສອບຖືກກ່າວເຖິງສອງຄັ້ງໃນຮອບການຕອບໂຕ້ XP. ມັນບໍ່ຄືກັນ. ພວກເຂົາມີຄວາມສໍາຄັນທີ່ສຸດສໍາລັບເຕັກນິກການດໍາເນີນໂຄງການທີ່ສຸດທັງຫມົດ.

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

ມີ pyramid ການທົດສອບຄລາສສິກ, ເຊິ່ງສະແດງໃຫ້ເຫັນວ່າຄວນຈະມີການທົດສອບຫຼາຍ.

ກອບນີ້ໃຊ້ກັບພວກເຮົາແນວໃດໃນໂຄງການ IaC? ຕົວຈິງແລ້ວ ... ບໍ່ແມ່ນເລີຍ.

• ການທົດສອບຫນ່ວຍ, ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າຄວນຈະມີຈໍານວນຫຼາຍຂອງພວກເຂົາ, ບໍ່ສາມາດມີຫຼາຍເກີນໄປ. ຫຼືພວກເຂົາກໍາລັງທົດສອບບາງສິ່ງບາງຢ່າງໂດຍທາງອ້ອມຫຼາຍ. ໃນຄວາມເປັນຈິງ, ພວກເຮົາສາມາດເວົ້າວ່າພວກເຮົາບໍ່ໄດ້ຂຽນພວກມັນທັງຫມົດ. ແຕ່ນີ້ແມ່ນບາງຄໍາຮ້ອງສະຫມັກສໍາລັບການທົດສອບດັ່ງກ່າວທີ່ພວກເຮົາສາມາດເຮັດໄດ້:
  1. ການທົດສອບລະຫັດ jsonnet. ຕົວຢ່າງນີ້ແມ່ນທໍ່ປະກອບ drone ຂອງພວກເຮົາ, ເຊິ່ງຂ້ອນຂ້າງສັບສົນ. ລະຫັດ jsonnet ຖືກປົກຄຸມດ້ວຍການທົດສອບ.
     ພວກເຮົາໃຊ້ນີ້ ກອບການທົດສອບຫນ່ວຍງານສໍາລັບ Jsonnet.
  2. ການທົດສອບສໍາລັບ scripts ທີ່ຖືກປະຕິບັດໃນເວລາທີ່ຊັບພະຍາກອນເລີ່ມຕົ້ນ. ສະຄຣິບຖືກຂຽນໃນ Python, ແລະດັ່ງນັ້ນການທົດສອບສາມາດຂຽນໃສ່ພວກມັນໄດ້.
• ມັນເປັນໄປໄດ້ໃນການກວດສອບການຕັ້ງຄ່າໃນການທົດສອບ, ແຕ່ພວກເຮົາບໍ່ເຮັດແນວນັ້ນ. ມັນຍັງສາມາດຕັ້ງຄ່າການກວດສອບກົດລະບຽບການຕັ້ງຄ່າຊັບພະຍາກອນຜ່ານ tflint. ຢ່າງໃດກໍຕາມ, ການກວດສອບມີພື້ນຖານເກີນໄປສໍາລັບ terraform, ແຕ່ສະຄິບທົດສອບຈໍານວນຫຼາຍແມ່ນຂຽນສໍາລັບ AWS. ແລະພວກເຮົາຢູ່ໃນ Azure, ດັ່ງນັ້ນນີ້ອີກເທື່ອຫນຶ່ງບໍ່ໄດ້ນໍາໃຊ້.
• ການທົດສອບການເຊື່ອມໂຍງອົງປະກອບ: ມັນຂຶ້ນກັບວິທີທີ່ເຈົ້າຈັດປະເພດພວກມັນແລະບ່ອນທີ່ທ່ານເອົາພວກມັນໃສ່. ແຕ່ພວກເຂົາເຮັດວຽກໂດຍພື້ນຖານ.

  ນີ້ແມ່ນສິ່ງທີ່ການທົດສອບການປະສົມປະສານເບິ່ງຄືວ່າ.

  
  
  ນີ້ແມ່ນຕົວຢ່າງເມື່ອສ້າງຮູບພາບໃນ Drone CI. ເພື່ອເຂົ້າຫາພວກມັນ, ທ່ານຕ້ອງລໍຖ້າ 30 ນາທີເພື່ອໃຫ້ຮູບພາບ Packer ປະກອບ, ຫຼັງຈາກນັ້ນລໍຖ້າອີກ 15 ນາທີເພື່ອໃຫ້ພວກມັນຜ່ານ. ແຕ່ພວກມັນມີຢູ່!

  ຂັ້ນຕອນການຢັ້ງຢືນຮູບພາບ

  1. Packer ທໍາອິດຕ້ອງກະກຽມຮູບພາບຢ່າງສົມບູນ.
  2. ຖັດຈາກການທົດສອບມີ terraform ກັບລັດທ້ອງຖິ່ນ, ທີ່ພວກເຮົາໃຊ້ເພື່ອນໍາໃຊ້ຮູບພາບນີ້.
  3. ເມື່ອເປີດເຜີຍ, ໂມດູນຂະຫນາດນ້ອຍທີ່ນອນຢູ່ໃກ້ໆແມ່ນຖືກນໍາໃຊ້ເພື່ອເຮັດໃຫ້ມັນງ່າຍຕໍ່ການເຮັດວຽກກັບຮູບພາບ.
  4. ເມື່ອ VM ຖືກນຳໃຊ້ຈາກຮູບພາບ, ການກວດສອບສາມາດເລີ່ມຕົ້ນໄດ້. ໂດຍພື້ນຖານແລ້ວ, ການກວດສອບແມ່ນດໍາເນີນໂດຍລົດ. ມັນກວດເບິ່ງວ່າສະຄຣິບເຮັດວຽກແນວໃດໃນຕອນເລີ່ມຕົ້ນ ແລະ daemons ເຮັດວຽກແນວໃດ. ເພື່ອເຮັດສິ່ງນີ້, ຜ່ານ ssh ຫຼື winrm ພວກເຮົາເຂົ້າໄປໃນເຄື່ອງທີ່ຍົກຂຶ້ນມາໃຫມ່ແລະກວດເບິ່ງສະຖານະການຕັ້ງຄ່າຫຼືວ່າການບໍລິການແມ່ນຂຶ້ນ.

• ສະຖານະການແມ່ນຄ້າຍຄືກັນກັບການທົດສອບການເຊື່ອມໂຍງໃນໂມດູນສໍາລັບ terraform. ນີ້ແມ່ນຕາຕະລາງສັ້ນທີ່ອະທິບາຍລັກສະນະຂອງການທົດສອບດັ່ງກ່າວ.

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

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

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

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

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

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

ຄູ່ໂຄງການ

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

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

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

ຂ້າງລຸ່ມນີ້ແມ່ນຮູບແບບການຂຽນໂປລແກລມຄູ່ແລະການນໍາໃຊ້ຂອງພວກເຂົາໃນການເຮັດວຽກໃນ IaC:

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

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

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

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

ສະຫຼຸບ: ໃນຮູບແບບທີ່ບໍລິສຸດຂອງມັນບໍ່ເຫມາະສົມກັບພວກເຮົາ.

2. ປິງປອງ. ວິທີການນີ້ກ່ຽວຂ້ອງກັບຄົນຫນຶ່ງຂຽນການທົດສອບແລະອີກຄົນຫນຶ່ງດໍາເນີນການປະຕິບັດສໍາລັບມັນ. ໂດຍຄໍານຶງເຖິງຄວາມຈິງທີ່ວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນສັບສົນກັບ Unit tests, ແລະທ່ານຕ້ອງຂຽນການທົດສອບປະສົມປະສານທີ່ໃຊ້ເວລາຫຼາຍຂອງການຂຽນໂປລແກລມ, ຄວາມງ່າຍຂອງ ping-pong ທັງຫມົດຫາຍໄປ.

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

ສະຫຼຸບ: ອະນິຈາ, ຈັງຫວະການເຮັດວຽກບໍ່ອະນຸຍາດໃຫ້ໃຊ້ ping-pong ເປັນການປະຕິບັດການຂຽນໂປຼແກຼມຄູ່ໃນ IaC.

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

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

ສະ​ຫຼຸບ​: ມັນ​ສາ​ມາດ​ນໍາ​ໃຊ້​ໄດ້​, ພວກ​ເຮົາ​ບໍ່​ໄດ້​ປະ​ຖິ້ມ​ຄວາມ​ພະ​ຍາ​ຍາມ​.

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

ຜົນ​ໄດ້​ຮັບ​ທົ່ວ​ໄປ​ກ່ຽວ​ກັບ​ການ​ນໍາ​ໃຊ້​ໂຄງ​ການ​ຄູ່​:

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

5. ເຖິງວ່າຈະມີນີ້, ມີຜົນສໍາເລັດ. ພວກເຮົາມາກັບວິທີການຂອງພວກເຮົາເອງ "Convergence - Divergence". ຂ້ອຍຈະອະທິບາຍສັ້ນໆວ່າມັນເຮັດວຽກແນວໃດ.

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

ການວາງແຜນແລະການສື່ສານ

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

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

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

ຂໍ້ໄດ້ປຽບຂອງການເບິ່ງເຫັນພາບຂອງວຽກງານ:

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

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

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

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

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

ໃນລະຫວ່າງການສາທິດ, ມັນຈໍາເປັນຕ້ອງເປີດເຜີຍລາຍລະອຽດຂອງວຽກງານແລະໃຫ້ແນ່ໃຈວ່າຈະສະແດງໃຫ້ເຫັນເຖິງການດໍາເນີນງານຂອງມັນ.

ບົດລາຍງານສາມາດດໍາເນີນການໄດ້ໂດຍໃຊ້ບັນຊີລາຍການກວດສອບ.1. ໃສ່ໃນບໍລິບົດ. ວຽກງານມາຈາກໃສ, ເປັນຫຍັງມັນຈຶ່ງຈໍາເປັນ?

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

3. ພວກເຮົາປັບປຸງມັນແນວໃດ. ຕົວຢ່າງ: "ເບິ່ງ, ດຽວນີ້ມີ scriptosik, ນີ້ແມ່ນ readme."

4. ສະແດງໃຫ້ເຫັນວິທີການເຮັດວຽກ. ຄວນປະຕິບັດໂດຍກົງບາງສະຖານະການຂອງຜູ້ໃຊ້. ຂ້ອຍຕ້ອງການ X, ຂ້ອຍເຮັດ Y, ຂ້ອຍເຫັນ Y (ຫຼື Z). ຕົວຢ່າງ, ຂ້ອຍໃຊ້ NGINX, ສູບຢາ url, ແລະໄດ້ຮັບ 200 OK. ຖ້າການປະຕິບັດແມ່ນຍາວ, ກະກຽມມັນລ່ວງຫນ້າເພື່ອໃຫ້ທ່ານສາມາດສະແດງໃນພາຍຫຼັງ. ມັນແນະນໍາໃຫ້ບໍ່ທໍາລາຍມັນຫຼາຍເກີນໄປຫນຶ່ງຊົ່ວໂມງກ່ອນການສາທິດ, ຖ້າມັນອ່ອນແອ.

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

ມັນແມ່ນແນະນໍາໃຫ້ສໍາລັບລໍາໂພງແຕ່ລະຄົນຮັກສາມັນໄວ້ 5-10 ນາທີ. ຖ້າຄໍາເວົ້າຂອງເຈົ້າມີຄວາມສໍາຄັນຢ່າງແນ່ນອນແລະຈະໃຊ້ເວລາດົນກວ່ານັ້ນ, ປະສານງານເລື່ອງນີ້ລ່ວງຫນ້າໃນຊ່ອງທາງ sre-takeover.

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

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

ບົດສະຫຼຸບຍາວແລະສິ່ງທີ່ຕໍ່ໄປ

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

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

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

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

ບົດສະຫຼຸບສັ້ນໃນແຖວດຽວ

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

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