Hey Habr! ຂ້າ​ພະ​ເຈົ້າ​ນໍາ​ສະ​ເຫນີ​ໃຫ້​ທ່ານ​ສົນ​ໃຈ​ການ​ແປ​ພາ​ສາ​ຂອງ​ບົດ​ຄວາມ​ໄດ້​ "ຕົ້ນກໍາເນີດຂອງ DevOps: ແມ່ນຫຍັງຢູ່ໃນຊື່?" ໂດຍ Steve Mezak.

ອີງຕາມທັດສະນະຂອງທ່ານ, DevOps ຈະສະເຫຼີມສະຫຼອງຄົບຮອບເກົ້າຫຼືສິບຂອງປີນີ້. ໃນປີ 2016, RightScales 'State of the Cloud ລາຍງານສັງເກດເຫັນວ່າ 70 ເປີເຊັນຂອງ SMBs ກໍາລັງປະຕິບັດ DevOps. ທຸກໆຕົວຊີ້ວັດທີ່ເຮັດໃຫ້ຄະແນນນີ້ເພີ່ມຂຶ້ນນັບຕັ້ງແຕ່ນັ້ນມາ. ໃນຂະນະທີ່ DevOps ກຽມຈະເຂົ້າສູ່ທົດສະວັດທີສອງຂອງມັນ, ມັນຈະເປັນການດີທີ່ຈະຍ່າງໄປຕາມທາງຍ່າງແລະກັບຄືນໄປຫາຕົ້ນກໍາເນີດຂອງ DevOps - ແລະແມ້ກະທັ້ງຕົ້ນກໍາເນີດຂອງຊື່ຂອງມັນເອງ.

ກ່ອນປີ 2007: ເປັນລະບົບຕ່ອງໂສ້ເຫດການທີ່ສົມບູນແບບ

ກ່ອນປີ 2007, ສະຖານະການຕ່າງໆໃນທີ່ສຸດກໍ່ໃຫ້ເກີດສິ່ງທີ່ຮູ້ກັນໃນທຸກມື້ນີ້ວ່າ DevOps.

ເນີ້ງ ໄດ້ພິສູດແລ້ວວ່າຕົນເອງເປັນການປະຕິບັດທີ່ດີທີ່ສຸດ. ເອີ້ນກັນວ່າ ລະບົບການຜະລິດໂຕໂຍຕ້າ, Lean Manufacturing ພະຍາຍາມເພີ່ມປະສິດທິພາບຂະບວນການໃນຊັ້ນການຜະລິດ. (ໂດຍວິທີທາງການ, ການຈັດການຂອງໂຕໂຍຕ້າໄດ້ຮັບການດົນໃຈໃນເບື້ອງຕົ້ນໂດຍວິທີການສາຍປະກອບຕົ້ນສະບັບທີ່ແນະນໍາໂດຍບໍລິສັດຟອດມໍເຕີ). ການປັບປຸງຢ່າງຕໍ່ເນື່ອງ ແມ່ນ mantra ສໍາລັບການຜະລິດ lean. ໃນການປະຕິບັດ, ເສັ້ນທາງຕໍ່ໄປນີ້ໄດ້ຖືກປະເມີນຢ່າງຕໍ່ເນື່ອງ:

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

ໃນໂລກ IT, ວິທີການແບບດັ້ງເດີມຂອງຮູບແບບນ້ໍາຕົກຂອງການພັດທະນາຊໍແວໄດ້ໃຫ້ວິທີການຊ້ໍາກັນໄວເຊັ່ນ: ວ່ອງໄວ. ຄວາມ​ໄວ​ແມ່ນ​ການ​ຮ້ອງ​ຂຶ້ນ​ຢ່າງ​ວ່ອງ​ໄວ, ເຖິງ​ແມ່ນ​ວ່າ​ບາງ​ຄັ້ງ​ຄຸນ​ນະ​ພາບ​ໄດ້​ຮັບ​ຄວາມ​ທຸກ​ຍາກ​ໃນ​ການ​ສະ​ແຫວງ​ຫາ​ການ​ພັດ​ທະ​ນາ​ຢ່າງ​ວ່ອງ​ໄວ​ແລະ​ການ​ນໍາ​ໃຊ້. ໃນລັກສະນະດຽວກັນ, ຄອມພິວເຕີ້ຟັງ, ໂດຍສະເພາະ ພື້ນຖານໂຄງລ່າງເປັນການບໍລິການ (IaaS) ແລະ Platform-as-a-Service (PaaS) ໄດ້ພິສູດຕົວເອງວ່າເປັນການແກ້ໄຂຜູ້ໃຫຍ່ໃນຂະບວນການ IT ແລະໂຄງສ້າງພື້ນຖານ.

ສຸດທ້າຍ, ຊຸດເຄື່ອງມືໄດ້ເລີ່ມປະກົດຂຶ້ນເມື່ອບໍ່ດົນມານີ້ ການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ (CI). ແນວຄວາມຄິດຂອງເຄື່ອງມື CI ໄດ້ເກີດມາແລະນໍາສະເຫນີໂດຍ Gradi Booch ກັບຄືນໄປບ່ອນໃນ 1991 ໃນວິທີການ Booch ຂອງລາວ.

2007-2008: ຜິດຫວັງຊາວແບນຊິກ

ທ່ານ Patrick Debois ທີ່ປຶກສາ, ຜູ້ຈັດການໂຄງການ ແລະ ຜູ້ປະຕິບັດ Agile ຊາວເບວຢຽມ ໄດ້ຮັບມອບໝາຍຈາກກະຊວງຂອງລັດຖະບານເບວຢຽມ ເພື່ອຊ່ວຍໃນການເຄື່ອນຍ້າຍສູນຂໍ້ມູນ. ໂດຍສະເພາະ, ລາວຮັບຜິດຊອບໃນການທົດສອບການຮັບຮອງ ແລະ ຄວາມພ້ອມ. ຄວາມຮັບຜິດຊອບຂອງລາວຮຽກຮ້ອງໃຫ້ລາວປະສານງານກິດຈະກຳຕ່າງໆ ແລະ ສ້າງສາຍພົວພັນລະຫວ່າງທີມງານພັດທະນາຊອບແວ ແລະ ທີມງານປະຕິບັດງານ. ເຄື່ອງແມ່ຂ່າຍ, ຖານຂໍ້ມູນ, ແລະ ເຄືອຂ່າຍ. ຄວາມອຸກອັ່ງຂອງລາວກັບການຂາດຄວາມສາມັກຄີ ແລະ ກຳແພງທີ່ແຍກວິທີການພັດທະນາ ແລະ ການດຳເນີນງານອອກຈາກກັນນັ້ນ ໄດ້ເພີ່ມຄວາມບໍ່ພໍໃຈໃຫ້ກັບລາວ. ຄວາມປາຖະໜາຂອງ Desbois ສຳລັບການປັບປຸງໃນໄວໆນີ້ໄດ້ນຳພາລາວໄປສູ່ການປະຕິບັດ.
ທີ່​ກອງ​ປະ​ຊຸມ Agile ປີ 2008 ຢູ່ Toronto, Andrew Schaefer ໄດ້​ສະ​ເໜີ​ດັດ​ແກ້​ກອງ​ປະ​ຊຸມ​ບໍ່​ເປັນ​ທາງ​ການ​ພິ​ເສດ​ເພື່ອ​ປຶກ​ສາ​ຫາ​ລື​ຫົວ​ຂໍ້ “ໂຄງສ້າງພື້ນຖານທີ່ວ່ອງໄວ"ແລະມີພຽງແຕ່ຄົນດຽວທີ່ເຂົ້າມາສົນທະນາໃນຫົວຂໍ້: Patrick DeBois. ການສົນທະນາແລະການແລກປ່ຽນຄວາມຄິດຂອງພວກເຂົາໄດ້ກ້າວຫນ້າແນວຄວາມຄິດຂອງການບໍລິຫານລະບົບ Agile. ໃນປີດຽວກັນ, DeBois ແລະ Schaefer ໄດ້ສ້າງກຸ່ມຜູ້ບໍລິຫານລະບົບ Agile ທີ່ປະສົບຜົນສໍາເລັດປານກາງຢູ່ທີ່ Google.

2009: ກໍລະນີຂອງການຮ່ວມມືລະຫວ່າງ Dev ແລະ Ops

ໃນກອງປະຊຸມ O'Reilly Velocity, ສອງພະນັກງານ Flickr, ຮອງປະທານອາວຸໂສຂອງການດໍາເນີນງານດ້ານວິຊາການ John Allspaw ແລະ CTO Paul Hammond, ໃຫ້ການນໍາສະເຫນີທີ່ມີຊື່ສຽງໃນປັດຈຸບັນ. "10 ການນຳໃຊ້ຕໍ່ມື້: Dev ແລະ Ops ຮ່ວມມືຢູ່ Flickr".

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

2010: DevOps ໃນສະຫະລັດອາເມຣິກາ

ມີການຂະຫຍາຍຕົວດັ່ງຕໍ່ໄປນີ້, ກອງປະຊຸມ DevOpsDays ໄດ້ຈັດຂຶ້ນເປັນຄັ້ງທໍາອິດໃນສະຫະລັດໃນ Mountain View, California, ທັນທີຫຼັງຈາກກອງປະຊຸມ Velocity ປະຈໍາປີ. ກ້າວໄປສູ່ປີ 2018, ແລະມີຫຼາຍກວ່າ 30 ກອງປະຊຸມ DevOpsDays ໄດ້ກໍານົດ, ລວມທັງຫຼາຍສິບຄົນໃນສະຫະລັດ.

2013: ໂຄງການ "ຟີນິກ"

ສໍາລັບພວກເຮົາຈໍານວນຫຼາຍ, ອີກຈຸດຫນຶ່ງທີ່ຫນ້າສັງເກດໃນປະຫວັດສາດຂອງ DevOps ແມ່ນການພິມເຜີຍແຜ່ຫນັງສື "The Phoenix Project" ໂດຍ Gene Kim, Kevin Behr ແລະ George Safford. ນະວະນິຍາຍນີ້ເລົ່າເລື່ອງຂອງຜູ້ຈັດການ IT ທີ່ພົບວ່າຕົນເອງຕົກຢູ່ໃນສະພາບທີ່ໝົດຫວັງ: ລາວໄດ້ຮັບມອບໝາຍໃຫ້ຊ່ວຍກູ້ໂຄງການອີຄອມເມີຊທີ່ສຳຄັນທີ່ຜິດພາດໄປ. ຜູ້ໃຫ້ຄໍາປຶກສາທີ່ລຶກລັບຂອງຜູ້ຈັດການ - ສະມາຊິກຂອງຄະນະກໍາມະການບໍລິຫານທີ່ມີຄວາມກະຕືລືລົ້ນໃນວິທີການຜະລິດແບບ lean - ແນະນໍາວິທີການໃຫມ່ໃຫ້ກັບຕົວລະຄອນຕົ້ນຕໍທີ່ຈະຄິດກ່ຽວກັບ IT ແລະການພັດທະນາແອັບພລິເຄຊັນ, ຄາດຄະເນແນວຄວາມຄິດຂອງ DevOps. ໂດຍວິທີທາງການ, "ໂຄງການ Phoenix" ໄດ້ດົນໃຈໃຫ້ພວກເຮົາຂຽນຫນັງສື "Outsource ຫຼືອື່ນໆ ... " ກ່ຽວກັບເລື່ອງທຸລະກິດທີ່ຄ້າຍຄືກັນທີ່ VP ຂອງຊອບແວໃຊ້ DevOps ໃນລະຫວ່າງການພັດທະນາຜະລິດຕະພັນພາຍນອກທີ່ສໍາຄັນໃຫມ່.

DevOps ສໍາລັບອະນາຄົດ

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

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

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