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

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

Leon ເວົ້າຫຼາຍສີໃນພາສາລັດເຊຍ, ສະນັ້ນຖ້າຫາກວ່າທ່ານມີ 35-40 ນາທີ, ຂ້າພະເຈົ້າແນະນໍາໃຫ້ເບິ່ງວິດີໂອ. ສະບັບຂໍ້ຄວາມເພື່ອປະຫຍັດເວລາຂ້າງລຸ່ມນີ້.

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

ຫນຶ່ງເດືອນກ່ອນ

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

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

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

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

ແພລະຕະຟອມ, ເຊິ່ງເບິ່ງຄືວ່າມີອາຍຸພຽງແຕ່ 2 ປີ, ມີ stack peculiar: ColdFusion & SQL Server ຈາກ 2008. ColdFusion, ຖ້າທ່ານບໍ່ຮູ້, ແລະສ່ວນຫຼາຍອາດຈະບໍ່ຮູ້, ແມ່ນ PHP ວິສາຫະກິດທີ່ອອກມາໃນກາງຊຸມປີ 90, ແລະຕັ້ງແຕ່ນັ້ນມາຂ້ອຍກໍ່ບໍ່ເຄີຍໄດ້ຍິນມັນ. ນອກຈາກນີ້ຍັງມີ: Ruby, MySQL, PostgreSQL, Java, Go, Python. ແຕ່ monolith ຕົ້ນຕໍແລ່ນຢູ່ໃນ ColdFusion ແລະ SQL Server.

ບັນຫາ

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

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

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

ສອງມື້ກ່ອນ

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

ການຕັດສິນໂດຍເສັ້ນສະແດງ, ບາງສິ່ງບາງຢ່າງເກີດຂຶ້ນຢ່າງຊັດເຈນ, ແລະມັນບໍ່ຊັດເຈນວ່າແມ່ນຫຍັງ. ມັນໄດ້ຫັນອອກວ່າບັນຫາແມ່ນ latency ເຄືອຂ່າຍໃນສູນຂໍ້ມູນ: 5 ms latency ໃນສູນຂໍ້ມູນໄດ້ຫັນເປັນ 2 s ສໍາລັບຜູ້ໃຊ້. ຂ້ອຍບໍ່ຮູ້ວ່າເປັນຫຍັງມັນເກີດຂື້ນ, ແຕ່ໃນກໍລະນີໃດກໍ່ຕາມ, ມັນຮູ້ວ່າບັນຫາແມ່ນຢູ່ໃນສູນຂໍ້ມູນ.

ມື້ທໍາອິດ

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

ສໍາລັບສອງມື້, ຫນ້າຂອງຜູ້ໃຊ້ຖືກໂຫລດໂດຍສະເລ່ຍໃນ 4 ວິນາທີ. ຂ້ອຍຖາມວ່າພວກເຂົາພົບບັນຫາຫຍັງ.

- ແມ່ນແລ້ວ, ພວກເຮົາໄດ້ເປີດປີ້.
- ແລະ?
- ແລ້ວ, ພວກເຂົາຍັງບໍ່ໄດ້ຕອບພວກເຮົາເທື່ອ.

ຈາກ​ນັ້ນ ຂ້ອຍ​ຈຶ່ງ​ຮູ້​ວ່າ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ທີ່​ຂ້ອຍ​ໄດ້​ບອກ​ມາ​ກ່ອນ​ນັ້ນ​ເປັນ​ພຽງ​ປາຍ​ກ້ອນ​ນ້ອຍໆ​ທີ່​ຂ້ອຍ​ຕ້ອງ​ຕໍ່ສູ້.

ມີຄໍາເວົ້າທີ່ດີທີ່ເຫມາະກັບເລື່ອງນີ້ຫຼາຍ:

"ບາງຄັ້ງໃນການປ່ຽນແປງເຕັກໂນໂລຢີ, ທ່ານຕ້ອງປ່ຽນອົງການຈັດຕັ້ງ."

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

ວັນທີສາມ

ດັ່ງນັ້ນ, ການໂຫຼດໃຊ້ເວລາ 4 ວິນາທີ, ແລະຈາກ 13 ຫາ 15 ສູງສຸດທີ່ໃຫຍ່ທີ່ສຸດ.

ໃນ​ມື້​ທີ​ສາມ​ໃນ​ໄລ​ຍະ​ເວ​ລາ​ນີ້​, ຄວາມ​ໄວ​ການ​ດາວ​ໂຫຼດ​ເບິ່ງ​ຄື​ນີ້​:

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

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

ແຕ່ພວກເຮົາບໍ່ຄວນລືມວ່າກ່ອນທີ່ທ່ານຈະໄດ້ຮັບຄໍາຕອບທີ່ຖືກຕ້ອງ, ທ່ານຈໍາເປັນຕ້ອງຖາມຄໍາຖາມທີ່ຖືກຕ້ອງ. ຄໍາຖາມຕໍ່ໄປຂອງຂ້ອຍແມ່ນ: ພວກເຮົາມີເຄື່ອງແມ່ຂ່າຍ frontend ເທົ່າໃດ? ຄໍາຕອບ "ເຮັດໃຫ້ຂ້ອຍຕົກໃຈເລັກນ້ອຍ" - ພວກເຮົາມີ 17 ເຄື່ອງແມ່ຂ່າຍຫນ້າ!

— ຂ້ອຍອາຍທີ່ຈະຖາມ, ແຕ່ 150 ຄູນ 17 ໃຫ້ປະມານ 8? ທ່ານເວົ້າວ່າແຕ່ລະເຄື່ອງແມ່ຂ່າຍອະນຸຍາດໃຫ້ 8 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ, ແລະຖ້າມື້ອື່ນມີ 160 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ, ພວກເຮົາຈະຕ້ອງການ 2 ເຄື່ອງແມ່ຂ່າຍອີກບໍ?

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

var currentClass = classes.getCurrentClass();
return currentClass;

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

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

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

ຂ້ອຍ​ດີ​ໃຈ​ຫຼາຍ​ເພາະ​ຂ້ອຍ​ໄດ້​ຕັດສິນ​ໃຈ​ວ່າ​ໃນ​ມື້​ທີ 3 ຂ້ອຍ​ໄດ້​ພົບ​ບັນຫາ​ຫຼັກ. Naive ຄືກັບຂ້ອຍ, ນີ້ແມ່ນພຽງແຕ່ຫນຶ່ງໃນຫຼາຍບັນຫາ.

ແຕ່ການແກ້ໄຂບັນຫາທໍາອິດນີ້ຫຼຸດລົງເສັ້ນສະແດງຕ່ໍາຫຼາຍ.

ໃນເວລາດຽວກັນ, ພວກເຮົາໄດ້ດໍາເນີນການເພີ່ມປະສິດທິພາບອື່ນໆ. ມີຫຼາຍສິ່ງທີ່ຢູ່ໃນສາຍຕາທີ່ສາມາດແກ້ໄຂໄດ້. ຕົວຢ່າງ, ໃນມື້ທີສາມດຽວກັນຂ້າພະເຈົ້າໄດ້ຄົ້ນພົບວ່າມີ cache ໃນລະບົບຫຼັງຈາກທັງຫມົດ (ໃນທໍາອິດຂ້າພະເຈົ້າຄິດວ່າການຮ້ອງຂໍທັງຫມົດແມ່ນມາຈາກຖານຂໍ້ມູນໂດຍກົງ). ເມື່ອຂ້ອຍຄິດເຖິງແຄດ, ຂ້ອຍຄິດເຖິງມາດຕະຖານ Redis ຫຼື Memcached. ແຕ່ຂ້ອຍເປັນຄົນດຽວທີ່ຄິດແນວນັ້ນ, ເພາະວ່າລະບົບນັ້ນໃຊ້ MongoDB ແລະ SQL Server ສໍາລັບຖານຄວາມຈໍາ - ອັນດຽວກັນທີ່ຂໍ້ມູນພຽງແຕ່ອ່ານ.

ມື້ສິບ

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

ບາງສິ່ງບາງຢ່າງທີ່ຫນ້າສົນໃຈໄດ້ຖືກຄົ້ນພົບອີກເທື່ອຫນຶ່ງ. ທີມງານປະກອບມີ: ນັກພັດທະນາ 18 ຄົນ; 8 ນັກທົດສອບ; ຜູ້ຈັດການ 3 ທ່ານ; ສະຖາປະນິກ 2 ທ່ານ. ແລະພວກເຂົາທັງຫມົດໄດ້ເຂົ້າຮ່ວມໃນພິທີກໍາທົ່ວໄປ, ນັ້ນແມ່ນ, ຫຼາຍກວ່າ 30 ຄົນມາຢືນຢູ່ໃນທຸກໆເຊົ້າແລະບອກສິ່ງທີ່ພວກເຂົາເຮັດ. ມັນເປັນທີ່ຊັດເຈນວ່າກອງປະຊຸມບໍ່ໄດ້ໃຊ້ເວລາ 5 ຫຼື 15 ນາທີ. ບໍ່ມີໃຜຟັງໃຜເພາະວ່າທຸກຄົນເຮັດວຽກຢູ່ໃນລະບົບທີ່ແຕກຕ່າງກັນ. ໃນຮູບແບບນີ້, 2-3 ປີ້ຕໍ່ຊົ່ວໂມງສໍາລັບກອງປະຊຸມ grooming ແມ່ນແລ້ວຜົນໄດ້ຮັບທີ່ດີ.

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

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບ:

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

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

ມື້ສິບເອັດ

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

ຂ້ອຍຄົ້ນພົບສິ່ງນີ້ໄດ້ແນວໃດ?

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

ຫຼັງ​ຈາກ​ນີ້​ພວກ​ເຮົາ​:

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

ວັນທີຊາວ

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

ເປົ້າໝາຍໄລຍະຍາວ:

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

ໃນອະດີດ, ມັນມັກຈະເວົ້າວ່າ: "ຂໍໃຫ້ຂຽນຄືນທຸກຢ່າງໃນ [ພາສາ/ກອບ], ທຸກຢ່າງຈະເຮັດວຽກດີຂຶ້ນ!"

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

• ສະທ້ອນໃຫ້ເຫັນເຖິງພາລະກິດ ແລະເປົ້າໝາຍຂອງໂຄງການ;
• ບຸລິມະສິດເປົ້າໝາຍຕົ້ນຕໍ;
• ປະກອບມີຕາຕະລາງສໍາລັບການບັນລຸໃຫ້ເຂົາເຈົ້າ.

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

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

ຕົວຢ່າງ, ຫນຶ່ງໃນ KPIs ອົງການຈັດຕັ້ງແມ່ນການເພີ່ມສ່ວນແບ່ງຕະຫຼາດໂດຍຜ່ານຜະລິດຕະພັນໃຫມ່.

ທ່ານສາມາດສະຫນັບສະຫນູນເປົ້າຫມາຍຂອງການມີຜະລິດຕະພັນໃຫມ່ຫຼາຍຂຶ້ນໄດ້ແນວໃດ?

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

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

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

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

ມື້ສາມສິບ

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

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

nuance ທີ່ຫນ້າສົນໃຈອີກອັນຫນຶ່ງແມ່ນວ່າສັນຍາກັບຫນຶ່ງໃນລູກຄ້າທີ່ໃຫຍ່ທີ່ສຸດລະບຸວ່າທຸກສະບັບຊອບແວທີ່ສະຫນັບສະຫນູນໂດຍເວທີຈະຕ້ອງເປັນ n-1, ນັ້ນແມ່ນ, ບໍ່ແມ່ນສະບັບຫລ້າສຸດ, ແຕ່ເປັນອັນສຸດທ້າຍ.

ມັນເປັນທີ່ຊັດເຈນວ່າພວກເຮົາຢູ່ໄກຈາກ n-1 ເທົ່າໃດຖ້າເວທີແມ່ນອີງໃສ່ ColdFusion ແລະ SQL Server 2008, ເຊິ່ງບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນທັງຫມົດໃນເດືອນກໍລະກົດ.

ມື້ສີ່ສິບຫ້າ

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

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

ເມື່ອ​ຂ້ອຍ​ເຮັດ​ສິ່ງ​ນີ້, ສອງ​ສິ່ງ​ທີ່​ຕິດ​ຕາ​ຂ້ອຍ:

• ອັດຕາສ່ວນສູງຂອງປີ້ກັບຄືນຈາກ QA ກັບຄືນໄປຫານັກພັດທະນາ;
• ດຶງ​ຄໍາ​ຮ້ອງ​ຂໍ​ການ​ທົບ​ທວນ​ຄືນ​ໃຊ້​ເວ​ລາ​ຫຼາຍ​ເກີນ​ໄປ​.

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

"ທ່ານບໍ່ສາມາດປັບປຸງສິ່ງທີ່ທ່ານບໍ່ສາມາດວັດແທກໄດ້."

ວິທີການພິສູດວ່າບັນຫາຮ້າຍແຮງເທົ່າໃດ? ມັນເສຍມື້ຫຼືຊົ່ວໂມງບໍ?

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

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

• ປະສິດທິພາບຂະບວນການ: ການປະຕິບັດແລະແຜນການ / ສົ່ງ.
• ຄຸນນະພາບຂະບວນການ: ຈໍານວນຂໍ້ບົກພ່ອງ, ຂໍ້ບົກພ່ອງຈາກ QA.

ມັນກໍ່ຊ່ວຍໃຫ້ເຂົ້າໃຈສິ່ງທີ່ດີແລະສິ່ງທີ່ບໍ່ດີ.

ມື້ທີຫ້າສິບ

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

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

ໃນທາງທິດສະດີ, ນີ້ແມ່ນດີ: ຄົນໃຫມ່ເຂົ້າມາໃນຜູ້ທີ່ມີ carte blanche ຄົບຖ້ວນ, ຜູ້ທີ່ສາມາດປະເມີນທັກສະຂອງທີມງານແລະທົດແທນບຸກຄະລາກອນ. ໃນຄວາມເປັນຈິງ, ທ່ານບໍ່ສາມາດເອົາຄົນໃຫມ່ມາສໍາລັບເຫດຜົນຫຼາຍຢ່າງ. ການດຸ່ນດ່ຽງແມ່ນຈໍາເປັນສະເຫມີ.

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

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

ມື້ຫ້າສິບຫນຶ່ງ

ຂ້ອຍເລີ່ມເບິ່ງທີມຢ່າງໃກ້ຊິດເພື່ອເຂົ້າໃຈວ່າຂ້ອຍມີໃຜ, ແລະອີກເທື່ອໜຶ່ງຂ້ອຍຈື່ໄດ້ວ່າ:

"ບັນຫາສ່ວນໃຫຍ່ແມ່ນບັນຫາປະຊາຊົນ."

ຂ້າພະເຈົ້າໄດ້ພົບເຫັນວ່າທີມງານດັ່ງກ່າວ - ທັງ Dev ແລະ Ops - ມີສາມບັນຫາໃຫຍ່:

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

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

ແຕ່ທ່ານບໍ່ສາມາດດີຂື້ນໄດ້ໂດຍບໍ່ມີການປ່ຽນແປງຫຍັງ.

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

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

• 12 ວິນາທີໂຫຼດ;
• 5-10 ນາທີ downtime ແຕ່ລະການປ່ອຍ;
• ການແກ້ໄຂບັນຫາທີ່ສໍາຄັນໃຊ້ເວລາຫຼາຍມື້ແລະອາທິດ;
• ຂາດພະນັກງານ 24x7 / on-call.

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

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

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

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

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

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

ໃນການຕອບສະຫນອງ, ຂ້າພະເຈົ້າໄດ້ແນະນໍາການປະຕິບັດດັ່ງຕໍ່ໄປນີ້:

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

ມື້ຫົກສິບ

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

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

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

ຜົນໄດ້ຮັບຂອງສິນຄ້າຄົງຄັງ:

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

ມື້ເຈັດສິບຫ້າ

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

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

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

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

ນັ້ນແມ່ນ, ColdFusion ໄປຜ່ານ Jetty ແລະ nginx ແລະເປີດຕົວຫນ້າເວັບຕ່າງໆ. ແລະຮູບພາບ, JS ແລະ CSS ໄປໂດຍຜ່ານ nginx ແຍກຕ່າງຫາກທີ່ມີການຕັ້ງຄ່າຂອງຕົນເອງ. ນີ້ແມ່ນການປະຕິບັດມາດຕະຖານທີ່ຂ້ອນຂ້າງທີ່ຂ້ອຍເວົ້າກ່ຽວກັບ wrote ສອງສາມປີກ່ອນ. ດັ່ງນັ້ນ, ຮູບພາບທີ່ໂຫລດໄວຂຶ້ນຫຼາຍ, ແລະ... ຄວາມໄວດາວໂຫຼດສະເລ່ຍເພີ່ມຂຶ້ນ 200 ms.

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

ມື້ແປດສິບຫ້າ

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

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

ສະຫລຸບ

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

ມີອີກລ້ານສິ່ງທີ່ຄ້າຍຄືກັນທີ່ພວກເຮົາສາມາດເວົ້າກ່ຽວກັບເປັນເວລາດົນນານ. ແຕ່ສິ່ງທີ່ສໍາຄັນທີ່ສຸດທີ່ຍັງຕ້ອງເວົ້າແມ່ນວັດທະນະທໍາ.

ມັນແມ່ນວັດທະນະທໍາຫຼືການຂາດຂອງມັນທີ່ນໍາໄປສູ່ບັນຫາອື່ນໆທັງຫມົດ. ພວກເຮົາພະຍາຍາມສ້າງວັດທະນະທໍາທີ່ປະຊາຊົນ:

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

ດ້ວຍນີ້, ທຸກສິ່ງທຸກຢ່າງຈະມາ.

ໄຟ Leon ໃນ twitter, ເຟສບຸກ ແລະສຸດ ຂະຫນາດກາງ.

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

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