เฮ้ ฮับ! ฉันขอเสนอการแปลบทความให้คุณทราบ โดย สตีฟ เมซัค.
DevOps จะฉลองครบรอบเก้าหรือสิบปีในปีนี้ ขึ้นอยู่กับมุมมองของคุณ ในปี 2016 รายงาน State of the Cloud ของ RightScales ระบุว่า 70 เปอร์เซ็นต์ของ SMB กำลังนำแนวปฏิบัติ DevOps มาใช้ ตัวบ่งชี้ทุกตัวที่ประกอบเป็นคะแนนนี้เพิ่มขึ้นตั้งแต่นั้นมา ในขณะที่ DevOps เตรียมเข้าสู่ทศวรรษที่สอง คงจะดีไม่น้อยหากได้ย้อนเวลากลับไปในอดีตและกลับไปสู่ต้นกำเนิดของ DevOps หรือแม้แต่ต้นกำเนิดของชื่อนั้นเอง
ก่อนปี 2007: เหตุการณ์ต่อเนื่องที่สมบูรณ์แบบ
ก่อนปี 2007 สถานการณ์ต่างๆ ทำให้เกิดสิ่งที่เรียกว่า DevOps ในปัจจุบัน
เอียง ได้พิสูจน์ตัวเองแล้วว่าเป็นแนวปฏิบัติที่ดีที่สุด หรือเรียกอีกอย่างว่า ระบบการผลิตของโตโยต้า, Lean Manufacturing มุ่งมั่นที่จะเพิ่มประสิทธิภาพกระบวนการในพื้นที่การผลิต (อย่างไรก็ตาม ในตอนแรกฝ่ายบริหารของ Toyota ได้รับแรงบันดาลใจจากวิธีการประกอบแบบเดิมที่บริษัท Ford Motor นำมาใช้) พัฒนาอย่างต่อเนื่อง คือมนต์เสน่ห์สำหรับการผลิตแบบลีน ในทางปฏิบัติ เส้นทางต่อไปนี้ได้รับการประเมินอย่างต่อเนื่อง:
- รักษาระดับสินค้าคงคลังของวัตถุดิบและผลิตภัณฑ์สำเร็จรูปให้น้อยที่สุด. การผลิตแบบ Lean หมายถึงจำนวนสินค้าคงคลังขั้นต่ำของวัตถุดิบในการผลิตสินค้าและจำนวนขั้นต่ำของผลิตภัณฑ์สำเร็จรูปที่รอการสั่งซื้อหรือจัดส่ง
- การลดคิวการสั่งซื้อ. ตามหลักการแล้ว คำสั่งซื้อที่ได้รับจะย้ายไปยังสถานะเสร็จสมบูรณ์ทันที ตัวชี้วัดหลักสำหรับการผลิตแบบลีนจะเป็นเวลาตั้งแต่การรับคำสั่งซื้อจนถึงการส่งมอบเสมอ
- เพิ่มประสิทธิภาพกระบวนการผลิตให้สูงสุด. การปรับวิศวกรรมกระบวนการและระบบอัตโนมัติที่ได้รับการปรับปรุงกำลังรวมเข้าด้วยกันเพื่อผลิตสินค้าโดยเร็วที่สุด ทุกพื้นที่การผลิตตลอดเส้นทาง (การตัด การเชื่อม การประกอบ การทดสอบ ฯลฯ) ได้รับการประเมินความไร้ประสิทธิภาพ
ในโลกไอที วิธีการแบบดั้งเดิมของการพัฒนาซอฟต์แวร์แบบจำลองน้ำตกได้ให้วิธีการทำซ้ำที่รวดเร็ว เช่น คล่องแคล่ว. ความเร็วคือเสียงเรียกร้องของการชุมนุม แม้ว่าบางครั้งคุณภาพจะลดลงจากการแสวงหาการพัฒนาและการใช้งานที่รวดเร็วก็ตาม ในทำนองเดียวกัน โดยเฉพาะการประมวลผลแบบคลาวด์ โครงสร้างพื้นฐาน-as-a-Service (IaaS) และ แพลตฟอร์ม as-a-Service (PaaS) ได้พิสูจน์ตัวเองว่าเป็นโซลูชั่นที่สมบูรณ์ในกระบวนการไอทีและโครงสร้างพื้นฐาน
ในที่สุดชุดเครื่องมือก็เริ่มปรากฏให้เห็นแล้ว การบูรณาการอย่างต่อเนื่อง (ซีไอ) แนวคิดเกี่ยวกับเครื่องมือ CI เกิดและนำเสนอโดย Gradi Booch ย้อนกลับไปในปี 1991 ใน Booch Method ของเขา
2007-2008: เบลเยียมผิดหวัง
ที่ปรึกษาชาวเบลเยียม โครงการ Agile และผู้จัดการฝ่ายปฏิบัติการ Patrick Debois ยอมรับการแต่งตั้งจากกระทรวงรัฐบาลเบลเยียมให้ช่วยเรื่องการโยกย้ายศูนย์ข้อมูล โดยเฉพาะอย่างยิ่งเขามีส่วนร่วมในการทดสอบการรับรองและความพร้อม ความรับผิดชอบของเขาทำให้เขาต้องประสานงานและสร้างความสัมพันธ์ระหว่างทีมพัฒนาซอฟต์แวร์กับทีมเซิร์ฟเวอร์ ฐานข้อมูล และเครือข่าย ความหงุดหงิดกับการขาดการทำงานร่วมกันและกำแพงที่แยกวิธีการพัฒนาและการดำเนินการออกจากกันทำให้เขาขมขื่น ความปรารถนาที่จะปรับปรุงของ Desbois ทำให้เขาลงมือปฏิบัติในไม่ช้า
ในการประชุม Agile ประจำปี 2008 ที่โตรอนโต Andrew Schaefer เสนอให้มีการประชุมแบบไม่เป็นทางการที่จัดขึ้นเป็นพิเศษเพื่อหารือในหัวข้อ "โครงสร้างพื้นฐานที่คล่องตัว"และมีเพียงคนเดียวเท่านั้นที่มาเพื่อหารือในหัวข้อ: Patrick DeBois การสนทนาและแลกเปลี่ยนความคิดเห็นของพวกเขาทำให้แนวคิดการบริหารระบบ Agile ก้าวหน้าขึ้น ในปีเดียวกันนั้น DeBois และ Schaefer ได้สร้างกลุ่มผู้ดูแลระบบ Agile Systems ที่ประสบความสำเร็จปานกลางที่ Google
พ.ศ. 2009: กรณีความร่วมมือระหว่าง Dev และ Ops
ในการประชุม O'Reilly Velocity พนักงาน Flickr สองคน รองประธานอาวุโสฝ่ายปฏิบัติการด้านเทคนิค John Allspaw และ CTO Paul Hammond ได้นำเสนอการนำเสนอที่มีชื่อเสียงในขณะนี้ "การปรับใช้ 10 ครั้งต่อวัน: การทำงานร่วมกันของ Dev และ Ops ที่ Flickr".
การนำเสนอนี้ถือเป็นละคร โดย Allspaw และ Hammond จำลองการโต้ตอบที่ซับซ้อนระหว่างตัวแทนฝ่ายพัฒนาและฝ่ายปฏิบัติการในระหว่างกระบวนการปรับใช้ซอฟต์แวร์ พร้อมด้วยการชี้นิ้วและการกล่าวโทษตามบรรทัดที่ว่า “มันไม่ใช่รหัสของฉัน แต่เป็นคอมพิวเตอร์ทั้งหมดของคุณ!” การนำเสนอของพวกเขายืนยันว่าทางเลือกที่เหมาะสมเพียงอย่างเดียวคือการพัฒนาซอฟต์แวร์และกิจกรรมการใช้งานให้ราบรื่น โปร่งใส และบูรณาการอย่างสมบูรณ์ เมื่อเวลาผ่านไป การนำเสนอนี้กลายเป็นตำนานและปัจจุบันถูกมองว่าเป็นเหตุการณ์สำคัญที่สำคัญเมื่ออุตสาหกรรมไอทีเริ่มเรียกร้องให้มีวิธีการที่รู้จักกันในชื่อ DevOps ในปัจจุบัน
2010: DevOps ในสหรัฐอเมริกา
ด้วยจำนวนผู้ติดตามที่เพิ่มมากขึ้น การประชุม DevOpsDays จึงถูกจัดขึ้นเป็นครั้งแรกในสหรัฐอเมริกาในเมืองเมาน์เทนวิว รัฐแคลิฟอร์เนีย ภายหลังจากการประชุม Velocity ประจำปีทันที ก้าวไปข้างหน้าอย่างรวดเร็วสู่ปี 2018 และมีการประชุม DevOpsDays มากกว่า 30 รายการที่กำหนดไว้ รวมถึงหลายสิบรายการในสหรัฐอเมริกา
2013: โครงการ "ฟีนิกซ์"
สำหรับพวกเราหลายคน อีกช่วงเวลาสำคัญในประวัติศาสตร์ของ DevOps คือการตีพิมพ์หนังสือ “The Phoenix Project” โดย Gene Kim, Kevin Behr และ George Safford นวนิยายเรื่องนี้บอกเล่าเรื่องราวของผู้จัดการฝ่ายไอทีที่พบว่าตัวเองตกอยู่ในสถานการณ์ที่สิ้นหวัง เขาได้รับมอบหมายให้ช่วยเหลือโครงการอีคอมเมิร์ซที่สำคัญซึ่งเกิดข้อผิดพลาด ผู้ให้คำปรึกษาลึกลับของผู้จัดการ - สมาชิกของคณะกรรมการบริหารที่มีความหลงใหลเกี่ยวกับวิธีการผลิตแบบลีน - แนะนำวิธีการใหม่ ๆ ให้กับตัวละครหลักในการคิดเกี่ยวกับไอทีและการพัฒนาแอปพลิเคชัน โดยคาดหวังแนวคิดของ DevOps อย่างไรก็ตาม “The Phoenix Project” เป็นแรงบันดาลใจให้เราเขียนหนังสือ “Outsource or else...” เกี่ยวกับเรื่องราวทางธุรกิจที่คล้ายกันซึ่งรองประธานฝ่ายซอฟต์แวร์ใช้ DevOps ในระหว่างการพัฒนาผลิตภัณฑ์ภายนอกที่สำคัญตัวใหม่
DevOps สำหรับอนาคต
คุ้มค่าที่จะอธิบายว่า DevOps เป็นการเดินทางหรืออาจเป็นความทะเยอทะยานมากกว่าจุดหมายปลายทางสุดท้าย DevOps ก็เหมือนกับการผลิตแบบลดขั้นตอนที่มุ่งมั่นในการปรับปรุงอย่างต่อเนื่อง เพิ่มผลผลิตและประสิทธิภาพ และแม้กระทั่งการใช้งานอย่างต่อเนื่อง เครื่องมืออัตโนมัติเพื่อรองรับ DevOps มีการพัฒนาอย่างต่อเนื่อง
ประสบความสำเร็จมากมายนับตั้งแต่ก่อตั้ง DevOps ในทศวรรษที่ผ่านมา และเราคาดว่าจะเห็นมากขึ้นอีกในปี 2018 และต่อๆ ไป
ที่มา: will.com