ໂຄງສ້າງພື້ນຖານເປັນລະຫັດ: ຄົນຮູ້ຈັກທໍາອິດ

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

ການສືບຕໍ່ຊຸດຂອງບົດຄວາມທີ່ຂຽນໂດຍອີງໃສ່ຄໍາເວົ້າຢູ່ໃນເຫດການພາຍໃນຂອງພວກເຮົາ DevForum:

1. cat Schrödinger ບໍ່ມີກ່ອງ: ບັນຫາຂອງການເປັນເອກະສັນກັນໃນລະບົບແຈກຢາຍ.
2. ໂຄງສ້າງພື້ນຖານເປັນລະຫັດ. (ເຈົ້າ​ຢູ່​ທີ່​ນີ້)
3. ການສ້າງສັນຍາ Typescript ໂດຍໃຊ້ຕົວແບບ C#. (ກຳລັງດຳເນີນຢູ່...)
4. ການແນະນຳວິທີການເປັນເອກະສັນຂອງ Raft. (ກຳລັງດຳເນີນຢູ່...)
...

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

ທີມງານມີວຽກງານການຝຶກອົບຮົມດັ່ງຕໍ່ໄປນີ້:

• ອະທິບາຍໂຄງສ້າງພື້ນຖານຂອງພວກເຮົາ, ເຊິ່ງສ່ວນໃຫຍ່ແມ່ນຢູ່ໃນ Microsoft Azure ໃນຮູບແບບຂອງລະຫັດ (Terraform ແລະທຸກສິ່ງທຸກຢ່າງທີ່ອ້ອມຮອບ).
• ສອນນັກພັດທະນາວິທີການເຮັດວຽກກັບໂຄງສ້າງພື້ນຖານ.
• ກະກຽມນັກພັດທະນາສໍາລັບຫນ້າທີ່.

ພວກເຮົາແນະນໍາແນວຄວາມຄິດຂອງໂຄງສ້າງພື້ນຖານເປັນລະຫັດ

ໃນຮູບແບບປົກກະຕິຂອງໂລກ (ການບໍລິຫານແບບຄລາສສິກ), ຄວາມຮູ້ກ່ຽວກັບພື້ນຖານໂຄງລ່າງແມ່ນຕັ້ງຢູ່ສອງບ່ອນ:

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

ໃນທັງສອງກໍລະນີ, ພວກເຮົາພົບວ່າຕົວເຮົາເອງຕິດຢູ່ໃນການເພິ່ງພາອາໄສ:

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

ມັນໄປໂດຍບໍ່ບອກວ່າທຸກຢ່າງຄວນຖືກແປເປັນລະຫັດທີ່ມະນຸດອ່ານໄດ້, ຮັກສາໄດ້, ຂຽນໄດ້ດີ.

ດັ່ງນັ້ນ, ໂຄງສ້າງພື້ນຖານເປັນລະຫັດ (Incfastructure as Code - IaC) ແມ່ນລາຍລະອຽດຂອງໂຄງສ້າງພື້ນຖານທີ່ມີຢູ່ທັງຫມົດໃນຮູບແບບຂອງລະຫັດ, ເຊັ່ນດຽວກັນກັບເຄື່ອງມືທີ່ກ່ຽວຂ້ອງສໍາລັບການເຮັດວຽກກັບມັນແລະການປະຕິບັດໂຄງສ້າງພື້ນຖານທີ່ແທ້ຈິງຈາກມັນ.

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

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

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

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

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

ຕົວຢ່າງລະຫັດຈາກ Terraforma.

ຕົວຢ່າງລະຫັດຈາກ Ansible.

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

1. ບັນຫາທໍາອິດແມ່ນວ່າໃນກໍລະນີຫຼາຍທີ່ສຸດ IaC ແມ່ນບາງປະເພດຂອງ dsl.

ແລະ DSL, ໃນທາງກັບກັນ, ແມ່ນລາຍລະອຽດຂອງໂຄງສ້າງ. ຫຼາຍທີ່ຊັດເຈນ, ສິ່ງທີ່ທ່ານຄວນມີ: Json, Yaml, ການດັດແປງຈາກບາງບໍລິສັດຂະຫນາດໃຫຍ່ທີ່ເກີດຂື້ນກັບ dsl ຂອງຕົນເອງ (HCL ຖືກນໍາໃຊ້ໃນ terraform).

ບັນຫາແມ່ນວ່າມັນອາດຈະບໍ່ມີສິ່ງທີ່ຄຸ້ນເຄີຍເຊັ່ນ:

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

2. ບັນຫາທີສອງກັບລະຫັດດັ່ງກ່າວແມ່ນວ່າສ່ວນຫຼາຍມັກຈະເປັນສະພາບແວດລ້ອມທີ່ຫຼາກຫຼາຍ. ປົກກະຕິແລ້ວເຈົ້ານັ່ງເຮັດວຽກກັບ C#, i.e. ກັບພາສາຫນຶ່ງ, ຫນຶ່ງ stack, ຫນຶ່ງລະບົບນິເວດ. ແລະໃນທີ່ນີ້ທ່ານມີແນວພັນທີ່ໃຫຍ່ຫຼວງຂອງເຕັກໂນໂລຢີ.

ມັນເປັນສະຖານະການທີ່ແທ້ຈິງຫຼາຍເມື່ອ bash ກັບ python ເປີດຕົວຂະບວນການບາງຢ່າງທີ່ Json ຖືກໃສ່. ທ່ານວິເຄາະມັນ, ຫຼັງຈາກນັ້ນບາງເຄື່ອງກໍາເນີດໄຟຟ້າອື່ນໆຜະລິດອີກ 30 ໄຟລ໌. ສໍາລັບສິ່ງທັງຫມົດນີ້, ຕົວແປການປ້ອນຂໍ້ມູນແມ່ນໄດ້ຮັບຈາກ Azure Key Vault, ເຊິ່ງຖືກດຶງເຂົ້າກັນໂດຍ plugin ສໍາລັບ drone.io ທີ່ຂຽນໃນ Go, ແລະຕົວແປເຫຼົ່ານີ້ຜ່ານ yaml, ເຊິ່ງຖືກຜະລິດເປັນຜົນມາຈາກການຜະລິດຈາກເຄື່ອງຈັກແມ່ແບບ jsonnet. ມັນຂ້ອນຂ້າງຍາກທີ່ຈະມີລະຫັດທີ່ອະທິບາຍໄດ້ດີຢ່າງເຂັ້ມງວດໃນເວລາທີ່ທ່ານມີສະພາບແວດລ້ອມທີ່ຫຼາກຫຼາຍດັ່ງກ່າວ.

ການພັດທະນາແບບດັ້ງເດີມພາຍໃນກອບຂອງວຽກງານຫນຶ່ງມາພ້ອມກັບພາສາດຽວ. ໃນທີ່ນີ້ພວກເຮົາເຮັດວຽກກັບພາສາຈໍານວນຫລາຍ.

3. ບັນຫາທີສາມແມ່ນການປັບ. ພວກເຮົາຖືກນໍາໃຊ້ເພື່ອເຮັດໃຫ້ບັນນາທິການເຢັນ (Ms Visual Studio, Jetbrains Rider) ທີ່ເຮັດທຸກສິ່ງທຸກຢ່າງສໍາລັບພວກເຮົາ. ແລະເຖິງແມ່ນວ່າພວກເຮົາໂງ່, ພວກເຂົາເຈົ້າຈະເວົ້າວ່າພວກເຮົາຜິດ. ມັນເບິ່ງຄືວ່າປົກກະຕິແລະທໍາມະຊາດ.

ແຕ່ບາງບ່ອນໃກ້ຄຽງມີ VSCode, ເຊິ່ງມີບາງ plugins ທີ່ຖືກຕິດຕັ້ງ, ສະຫນັບສະຫນູນຫຼືບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນ. ຮຸ່ນໃຫມ່ອອກມາແລະບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນ. ການຫັນປ່ຽນ banal ໄປສູ່ການປະຕິບັດຫນ້າທີ່ (ເຖິງແມ່ນວ່າມັນມີຢູ່) ກາຍເປັນບັນຫາທີ່ສັບສົນແລະບໍ່ແມ່ນເລື່ອງເລັກນ້ອຍ. ການປ່ຽນຊື່ແບບງ່າຍໆຂອງຕົວແປແມ່ນ replay ໃນໂຄງການຂອງໄຟລ໌ອາຍແກັສ. ເຈົ້າຈະໂຊກດີຖ້າລາວວາງສິ່ງທີ່ທ່ານຕ້ອງການ. ແນ່ນອນ, ມີ backlighting ຢູ່ທີ່ນີ້ແລະບ່ອນນັ້ນ, ມີການສໍາເລັດອັດຕະໂນມັດ, ບາງບ່ອນມີການຈັດຮູບແບບ (ເຖິງແມ່ນວ່າມັນບໍ່ເຮັດວຽກສໍາລັບຂ້ອຍໃນ terraform ໃນ Windows).

ໃນເວລາຂຽນນີ້ vscode-terraform plugin ຍັງບໍ່ທັນໄດ້ຮັບການປ່ອຍອອກມາເພື່ອສະຫນັບສະຫນູນສະບັບ 0.12, ເຖິງແມ່ນວ່າມັນໄດ້ປ່ອຍອອກມາເມື່ອ 3 ເດືອນ.

ມັນເຖິງເວລາທີ່ຈະລືມກ່ຽວກັບ ...

1. ດີບັກ.
2. ເຄື່ອງ​ມື reactoring.
3. ສໍາເລັດອັດຕະໂນມັດ.
4. ກວດພົບຄວາມຜິດພາດໃນລະຫວ່າງການລວບລວມ.

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

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

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

ຈະເປັນແນວໃດກ່ຽວກັບການທົດສອບ?

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

ພວກເຂົາເຈົ້າມີເອກະສານທີ່ດີ. ຂ້າ​ພະ​ເຈົ້າ​ມັກ Microsoft ສະ​ເຫມີ​ສໍາ​ລັບ​ວິ​ທີ​ການ​ຂອງ​ຕົນ​ເພື່ອ​ເອ​ກະ​ສານ​ແລະ​ການ​ຝຶກ​ອົບ​ຮົມ​. ແຕ່ທ່ານບໍ່ຈໍາເປັນຕ້ອງເປັນລຸງ Bob ເພື່ອເຂົ້າໃຈວ່ານີ້ບໍ່ແມ່ນລະຫັດທີ່ສົມບູນແບບ. ຫມາຍເຫດການກວດສອບທີ່ຖືກຕ້ອງ.

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

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

Microsoft ເອງຂຽນໂມດູນຂອງມັນ, ທົດສອບພວກມັນດ້ວຍວິທີນີ້. ແນ່ນອນວ່າມັນເປັນແຫຼ່ງເປີດ. ທຸກຢ່າງທີ່ຂ້ອຍເວົ້າກ່ຽວກັບເຈົ້າສາມາດມາແກ້ໄຂໄດ້. ຂ້ອຍສາມາດນັ່ງລົງແລະແກ້ໄຂທຸກສິ່ງທຸກຢ່າງໃນຫນຶ່ງອາທິດ, open source VS code plugins, terraforms, make a plugin for the rider. ບາງທີຂຽນສອງສາມຕົວວິເຄາະ, ເພີ່ມ linters, ປະກອບສ່ວນຫ້ອງສະຫມຸດສໍາລັບການທົດສອບ. ຂ້ອຍສາມາດເຮັດໄດ້ທຸກຢ່າງ. ແຕ່ນັ້ນບໍ່ແມ່ນສິ່ງທີ່ຂ້ອຍຄວນເຮັດ.

ການປະຕິບັດທີ່ດີທີ່ສຸດໂຄງສ້າງພື້ນຖານເປັນລະຫັດ

ໃຫ້ກ້າວຕໍ່ໄປ. ຖ້າບໍ່ມີການທົດສອບໃນ IaC, IDE ແລະ tuning ແມ່ນບໍ່ດີ, ຫຼັງຈາກນັ້ນຢ່າງຫນ້ອຍຄວນມີການປະຕິບັດທີ່ດີທີ່ສຸດ. ຂ້ອຍພຽງແຕ່ໄປຫາ Google Analytics ແລະປຽບທຽບສອງຄໍາຖາມຄົ້ນຫາ: ການປະຕິບັດທີ່ດີທີ່ສຸດຂອງ Terraform ແລະ c# ການປະຕິບັດທີ່ດີທີ່ສຸດ.

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

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

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

ທັງໝົດນີ້ໄປໃສ ແລະຈະເຮັດຫຍັງ

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

ສ່ວນບຸກຄົນ, ຂ້ອຍກໍາລັງພະນັນບາງສິ່ງທີ່:

1. ການພັດທະນາໃນຂົງເຂດນີ້ແມ່ນເກີດຂຶ້ນຢ່າງໄວວາ. ນີ້ແມ່ນຕາຕະລາງການຮ້ອງຂໍສໍາລັບ DevOps.

   
   
   ຫົວຂໍ້ອາດຈະເປັນ hype, ແຕ່ຄວາມຈິງທີ່ວ່າຜ່ານການຂະຫຍາຍຕົວເຮັດໃຫ້ຄວາມຫວັງບາງຢ່າງ.

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

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

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

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

ສະຫລຸບ

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

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

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