ການບໍລິການເດັກກຳພ້າ: ການຫຼຸດລົງຂອງສະຖາປັດຕະຍະກຳການບໍລິການ (ຈຸນລະພາກ).

ຜູ້ອໍານວຍການຝ່າຍປະຕິບັດງານຂອງປະຕູ Banki.ru Andrey Nikolsky ກ່າວໃນກອງປະຊຸມປີທີ່ຜ່ານມາ DevOpsDays Moscow ກ່ຽວກັບການບໍລິການເດັກກໍາພ້າ: ວິທີການກໍານົດເດັກກໍາພ້າຢູ່ໃນພື້ນຖານໂຄງລ່າງ, ເປັນຫຍັງການບໍລິການເດັກກໍາພ້າບໍ່ດີ, ຈະເຮັດແນວໃດກັບພວກເຂົາ, ແລະຈະເຮັດແນວໃດຖ້າບໍ່ມີຫຍັງຊ່ວຍ.

ຂ້າງລຸ່ມນີ້ການຕັດແມ່ນສະບັບຂໍ້ຄວາມຂອງບົດລາຍງານ.

ສະບາຍດີເພື່ອນຮ່ວມງານ! ຂ້ອຍຊື່ Andrey, ຂ້ອຍເປັນຫົວຫນ້າການດໍາເນີນງານຢູ່ Banki.ru.

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

ຂໍ້ດີຂອງການບໍລິການ

ຂ້ອຍຈະຂ້າມຂໍ້ໄດ້ປຽບຂອງການບໍລິການຢ່າງໄວວາ.

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

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

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

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

ການບໍລິການເຮັດໃຫ້ມັນສາມາດນໍາໃຊ້ພາສາການຂຽນໂປຼແກຼມທີ່ແຕກຕ່າງກັນທີ່ເຫມາະສົມສໍາລັບວຽກງານທີ່ແຕກຕ່າງກັນ. ການບໍລິການບາງຢ່າງແມ່ນຢູ່ໃນ Go, ບາງຢ່າງຢູ່ໃນ Erlang, ບາງຢ່າງຢູ່ໃນ Ruby, ບາງສິ່ງບາງຢ່າງຢູ່ໃນ PHP, ບາງສິ່ງບາງຢ່າງຢູ່ໃນ Python. ໂດຍທົ່ວໄປ, ທ່ານສາມາດຂະຫຍາຍໄດ້ຢ່າງກວ້າງຂວາງ. ຍັງມີ nuances ຢູ່ທີ່ນີ້.

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

ສໍາລັບຕົວຢ່າງ, ທ່ານມີ 20 ບໍລິການແລະທ່ານຈໍາເປັນຕ້ອງໄດ້ນໍາໃຊ້ດ້ວຍມື, ທ່ານມີ 20 consoles, ແລະພ້ອມໆກັນກົດ "ເຂົ້າ" ຄື ninja. ມັນບໍ່ດີຫຼາຍ.

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

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

ພວກເຮົາໃຊ້ Ansible ເພື່ອເຮັດໃຫ້ການຕິດຕັ້ງອັດຕະໂນມັດ, Puppet ສໍາລັບ convergence, ໄມ້ໄຜ່ເພື່ອອັດຕະໂນມັດການນໍາໃຊ້, ແລະ Confluence ເພື່ອ somehow ອະທິບາຍມັນທັງຫມົດ.

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

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

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

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

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

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

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

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

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

ແຕ່ລະບໍລິການມີທີມງານຂອງຕົນເອງ

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

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

ລັກສະນະໃຫມ່ກໍາລັງຖືກສ້າງຂື້ນຢ່າງໄວວາ, ເພາະວ່າເມື່ອທ່ານມີບໍລິການປະລໍາມະນູຫນຶ່ງ, ທ່ານສາມາດ screw ບາງສິ່ງບາງຢ່າງເຂົ້າໄປໃນມັນ.

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

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

ຖ້າທີມງານລອຍຕົວ (ບາງຄັ້ງພວກເຮົາກໍ່ໃຊ້ວິທີນີ້), ມີວິທີການທີ່ດີທີ່ເອີ້ນວ່າ "ແຜນທີ່ດາວ".

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

ການບໍລິການເດັກກຳພ້າປາກົດແນວໃດ?

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

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

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

ວິທີການກໍານົດເດັກກໍາພ້າ?

ບັນຊີລາຍຊື່ນີ້ອະທິບາຍສະຖານະການໄດ້ດີ. ໃຜຮຽນຫຍັງກ່ຽວກັບໂຄງສ້າງພື້ນຖານຂອງເຂົາເຈົ້າ?

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

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

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

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

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

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

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

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

ການບໍລິການຕ້ອງໄດ້ຮັບການກວດສອບ, ການບໍລິການຕ້ອງໄດ້ຮັບການທົບທວນຄືນ, ລະຫັດຜ່ານຕ້ອງໄດ້ຮັບການປ່ຽນແປງ. ພວກເຮົາມີກໍລະນີເມື່ອພວກເຂົາໃຫ້ບໍລິການໃຫ້ພວກເຮົາ, ມີກະດານ admin "ຖ້າເຂົ້າສູ່ລະບົບ == 'admin' && password == 'admin' ... ", ມັນຂຽນຖືກຕ້ອງໃນລະຫັດ. ພວກເຮົານັ່ງຄິດ, ແລະຄົນຂຽນນີ້ໃນປີ 2018?

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

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

ພວກເຮົາມີກໍລະນີເມື່ອພວກເຮົາຕັດສິນໃຈ outsource ໂຄງການທົດລອງ.

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

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

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

ເດັກກຳພ້າມີບັນຫາຫຍັງ?

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

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

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

ເປັນຫຍັງການບໍລິການເດັກກຳພ້າຈຶ່ງເປັນອັນຕະລາຍ:

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

ຈະເຮັດແນວໃດກັບການບໍລິການເດັກກໍາພ້າ?

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

ອັນທີສອງ, ມັນຈໍາເປັນຕ້ອງຂຽນແຜນວາດການໂຕ້ຕອບ, ເພາະວ່າມັນເກີດຂື້ນວ່າການບໍລິການທີ່ບໍ່ໄດ້ຮັບການຍອມຮັບຫຼາຍປະກອບດ້ວຍການເພິ່ງພາອາໄສທີ່ບໍ່ມີໃຜເວົ້າກ່ຽວກັບ. ຕົວຢ່າງ, ຜູ້ພັດທະນາໄດ້ຕິດຕັ້ງບໍລິການໃສ່ກະແຈຂອງພວກເຂົາໃສ່ບາງ Yandex.Maps ຫຼື Dadata. ທ່ານໝົດຂີດຈຳກັດຟຣີ, ທຸກຢ່າງແຕກຫັກ, ແລະທ່ານບໍ່ຮູ້ວ່າເກີດຫຍັງຂຶ້ນ. rakes ດັ່ງກ່າວທັງຫມົດຕ້ອງໄດ້ຮັບການອະທິບາຍ: ການບໍລິການໃຊ້ Datadata, SMS, ບາງສິ່ງບາງຢ່າງອື່ນ.

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

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

ວາງແຜນການເຮັດວຽກກັບບໍລິການເດັກກຳພ້າ

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

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

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

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

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

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

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

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

ໃນຄວາມເປັນຈິງ, ມັນເປັນທາງເລືອກ, ເຊັ່ນດຽວກັນກັບການປະຕິບັດທັງຫມົດ. ບາງທີ, ໃນບາງກໍລະນີ, ມັນກໍ່ເປັນສິ່ງທີ່ບໍ່ຕ້ອງການ. ແຕ່ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈວ່າຖ້າທ່ານມີພະແນກວິຊາການຢູ່ໃນບໍລິສັດທີ່ມີ 50 ຄົນ, 45 ຄົນແມ່ນຜູ້ຊ່ຽວຊານ PHP, ອີກ 3 ຄົນແມ່ນ devops ທີ່ຮູ້ຈັກ Python, Ansible, Puppet ແລະບາງສິ່ງບາງຢ່າງເຊັ່ນນັ້ນ, ແລະພຽງແຕ່ຫນຶ່ງໃນນັ້ນຂຽນໃນບາງ. ປະເພດຂອງພາສາບາງ Go ການບໍລິການປັບຂະຫນາດ, ຫຼັງຈາກນັ້ນໃນເວລາທີ່ມັນອອກ, ຄວາມຊໍານານໄປກັບມັນ. ແລະໃນເວລາດຽວກັນ, ທ່ານຈະຕ້ອງຊອກຫາຜູ້ພັດທະນາຕະຫຼາດສະເພາະຜູ້ທີ່ຮູ້ພາສານີ້, ໂດຍສະເພາະຖ້າມັນຫາຍາກ. ນັ້ນແມ່ນ, ຈາກທັດສະນະຂອງອົງການຈັດຕັ້ງ, ນີ້ແມ່ນບັນຫາ. ຈາກທັດສະນະຂອງ devops, ທ່ານຈະບໍ່ພຽງແຕ່ຕ້ອງການ clone ບາງຊຸດຂອງ playbooks ພ້ອມທີ່ຈະເຮັດແລ້ວທີ່ທ່ານໃຊ້ໃນການໃຫ້ບໍລິການ, ແຕ່ວ່າທ່ານຈະຕ້ອງຂຽນໃຫ້ເຂົາເຈົ້າທັງຫມົດອີກເທື່ອຫນຶ່ງ.

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

ເຈົ້າຕິດຕາມການບໍລິການຂອງເຈົ້າແນວໃດ? ເຈົ້າເກັບກຳ ແລະ ຕິດຕາມບັນທຶກແນວໃດ?

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

ວິທີການດໍາລົງຊີວິດກັບ Puppet ແລະ Ansible ໃນສະພາບແວດລ້ອມດຽວກັນ?

ໃນຄວາມເປັນຈິງ, ພວກເຮົາມີສອງສະພາບແວດລ້ອມ, ຫນຶ່ງແມ່ນ Puppet, ອີກອັນຫນຶ່ງແມ່ນ Ansible. ພວກເຮົາເຮັດວຽກເພື່ອປະສົມພວກມັນ. Ansible ເປັນກອບທີ່ດີສໍາລັບການຕິດຕັ້ງເບື້ອງຕົ້ນ, Puppet ເປັນກອບທີ່ບໍ່ດີສໍາລັບການຕິດຕັ້ງເບື້ອງຕົ້ນເນື່ອງຈາກວ່າມັນຮຽກຮ້ອງໃຫ້ມີການເຮັດວຽກດ້ວຍມືໂດຍກົງໃນເວທີ, ແລະ Puppet ຮັບປະກັນການ convergence ການຕັ້ງຄ່າ. ນີ້ຫມາຍຄວາມວ່າແພລະຕະຟອມຮັກສາຕົວມັນເອງຢູ່ໃນສະພາບທີ່ທັນສະໄຫມ, ແລະເພື່ອໃຫ້ເຄື່ອງ ansibilized ມີຄວາມທັນສະໄຫມ, ທ່ານຈໍາເປັນຕ້ອງດໍາເນີນການ playbooks ໃນມັນຕະຫຼອດເວລາດ້ວຍຄວາມຖີ່ບາງຢ່າງ. ນັ້ນແມ່ນຄວາມແຕກຕ່າງ.

ເຈົ້າຮັກສາຄວາມເຂົ້າກັນໄດ້ແນວໃດ? ທ່ານມີ configs ໃນ Ansible ແລະ Puppet ບໍ?

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

ການນໍາສະເຫນີແມ່ນກ່ຽວກັບສະບັບທີ່ແຕກຕ່າງກັນຂອງ Ruby. ວິທີແກ້ໄຂແມ່ນຫຍັງ?

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

ກອງປະຊຸມປີນີ້ DevOpsDays Moscow ຈະຈັດຂຶ້ນໃນວັນທີ 7 ເດືອນທັນວາທີ່ Technopolis. ພວກ​ເຮົາ​ໄດ້​ຮັບ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ສໍາ​ລັບ​ການ​ລາຍ​ງານ​ເຖິງ​ວັນ​ທີ 11 ເດືອນ​ພະ​ຈິກ​. ຂຽນ ພວກເຮົາຖ້າທ່ານຕ້ອງການເວົ້າ.

ເປີດລົງທະບຽນແລ້ວ, ເຂົ້າຮ່ວມກັບພວກເຮົາ!

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