ส่วนที่ 1: บทนำ

I นส่วนที่ 1 ของ The DevOps Handbook นี้ เราจะสำรวจว่าการบรรจบกันของแนวคิดสำคัญหลายประการในด้านการจัดการและเทคโนโลยีได้ปูทางไปสู่ขบวนการ DevOps อย่างไร เราจะอธิบายเกี่ยวกับ value streams ว่า DevOps เป็นผลลัพธ์ของการประยุกต์ใช้หลักการ Lean กับ technology value stream และ Three Ways ได้แก่ Flow, Feedback, และ Continual Learning and Experimentation

ประเด็นหลักในบทเหล่านี้ได้แก่:

• หลักการของ Flow ซึ่งช่วยเร่งการส่งมอบงานจาก Development ไปยัง Operations และถึงมือลูกค้าของเรา

• หลักการของ Feedback ซึ่งช่วยให้เราสร้างระบบการทำงานที่ปลอดภัยยิ่งขึ้น

• หลักการของ Continual Learning and Experimentation ซึ่งส่งเสริมวัฒนธรรมแห่งความไว้วางใจสูงและแนวทางเชิงวิทยาศาสตร์ในการปรับปรุงองค์กรและการกล้าเสี่ยงในงานประจำวันของเรา

ประวัติโดยย่อ

DevOps และแนวทางปฏิบัติทางเทคนิค สถาปัตยกรรม และวัฒนธรรมที่เป็นผลลัพธ์นั้น ล้วนเป็นตัวแทนของการบรรจบกันของแนวคิดทางปรัชญาและการจัดการหลายกระแส แม้ว่าหลายองค์กรจะพัฒนาหลักการเหล่านี้ขึ้นมาอย่างอิสระ แต่การเข้าใจว่า DevOps เกิดจากแนวคิดที่หลากหลาย — ปรากฏการณ์ที่ John Willis (หนึ่งในผู้ร่วมเขียนหนังสือเล่มนี้) เรียกว่า "การบรรจบกันของ Dev และ Ops" — แสดงให้เห็นถึงวิวัฒนาการทางความคิดที่น่าทึ่งและการเชื่อมโยงที่คาดไม่ถึง มีบทเรียนหลายทศวรรษจากอุตสาหกรรมการผลิต องค์กรที่มีความน่าเชื่อถือสูง แบบจำลองการจัดการแบบมีความไว้วางใจสูง และอื่นๆ อีกมากมายที่นำพาเรามาสู่แนวทางปฏิบัติ DevOps ที่เรารู้จักในทุกวันนี้

DevOps เป็นผลลัพธ์ของการนำหลักการที่น่าเชื่อถือที่สุดจากสายการผลิตทางกายภาพและภาวะผู้นำมาประยุกต์ใช้กับ IT value stream DevOps อาศัยองค์ความรู้จาก Lean, Theory of Constraints, Toyota Production System, resilience engineering, learning organizations, safety culture, human factors และอื่นๆ อีกมากมาย บริบทที่มีคุณค่าอื่นๆ ที่ DevOps ดึงมาใช้ ได้แก่ วัฒนธรรมการจัดการแบบความไว้วางใจสูง ภาวะผู้นำแบบผู้รับใช้ และการจัดการการเปลี่ยนแปลงองค์กร

ผลลัพธ์ที่ได้คือคุณภาพ ความน่าเชื่อถือ เสถียรภาพ และความปลอดภัยระดับโลก ด้วยต้นทุนและความพยายามที่ลดลงอย่างต่อเนื่อง พร้อมทั้งการไหลเวียนและความน่าเชื่อถือที่เร่งขึ้นตลอด technology value stream ทั้งหมด รวมถึง Product Management, Development, QA, IT Operations และ Infosec

แม้ว่ารากฐานของ DevOps จะมองได้ว่ามาจาก Lean, Theory of Constraints และขบวนการ Toyota Kata แต่หลายคนก็มองว่า DevOps เป็นความต่อเนื่องเชิงตรรกะของการเดินทางของซอฟต์แวร์ Agile ที่เริ่มต้นขึ้นในปี 2001

ขบวนการ Lean

เทคนิคต่างๆ เช่น value stream mapping, kanban boards และ total productive maintenance ถูกจัดทำเป็นระบบสำหรับ Toyota Production System ในช่วงทศวรรษ 1980 ในปี 1997 Lean Enterprise Institute เริ่มต้นวิจัยการประยุกต์ใช้ Lean กับ value stream อื่นๆ เช่น อุตสาหกรรมบริการและการดูแลสุขภาพ

หลักการสำคัญสองประการของ Lean ได้แก่ ความเชื่ออย่างลึกซึ้งว่า lead time ในการผลิตที่ใช้ในการเปลี่ยนวัตถุดิบเป็นสินค้าสำเร็จรูปเป็นตัวทำนายที่ดีที่สุดของคุณภาพ ความพึงพอใจของลูกค้า และความสุขของพนักงาน และหนึ่งในตัวทำนายที่ดีที่สุดของ lead time ที่สั้นคือขนาด batch ของงานที่เล็ก

หลักการ Lean มุ่งเน้นที่วิธีสร้างคุณค่าให้กับลูกค้าผ่านการคิดเชิงระบบ โดยการสร้างความสม่ำเสมอของเป้าหมาย การ embrace การคิดเชิงวิทยาศาสตร์ การสร้าง flow และ pull (แทนที่จะเป็น push) การรับประกันคุณภาพที่แหล่งกำเนิด การนำด้วยความถ่อมตน และการเคารพทุกบุคคล

Agile Manifesto

Agile Manifesto ถูกสร้างขึ้นในปี 2001 ในงานแบบ invite-only โดยผู้เชี่ยวชาญ 17 คนในสิ่งที่ในขณะนั้นเรียกว่า "วิธีการแบบ lightweight" ในการพัฒนาซอฟต์แวร์ พวกเขาต้องการสร้างชุดของคุณค่าและหลักการที่รวบรวมข้อได้เปรียบของวิธีการแบบปรับตัวได้เหล่านี้ เมื่อเทียบกับกระบวนการพัฒนาซอฟต์แวร์ที่แพร่หลายในขณะนั้น เช่น waterfall development และ methodology ต่างๆ เช่น Rational Unified Process

หลักการสำคัญข้อหนึ่งคือ "ส่งมอบซอฟต์แวร์ที่ทำงานได้บ่อยครั้ง ตั้งแต่ทุกสองสามสัปดาห์ถึงทุกสองสามเดือน โดยให้ความสำคัญกับระยะเวลาที่สั้นกว่า" 1 ซึ่งเน้นย้ำถึงความต้องการ batch size ที่เล็ก — การ release แบบ incremental แทนที่จะเป็นการ release แบบ big-bang ครั้งใหญ่ หลักการอื่นๆ เน้นย้ำถึงความต้องการทีมเล็กๆ ที่มีแรงจูงใจในตนเองที่ทำงานภายใต้แบบจำลองการจัดการแบบความไว้วางใจสูง

Agile ได้รับการยกย่องว่าช่วยเพิ่ม productivity และความสามารถในการตอบสนองขององค์กรพัฒนาจำนวนมากได้อย่างมาก และที่น่าสนใจคือ เหตุการณ์สำคัญหลายเหตุการณ์ในประวัติศาสตร์ของ DevOps ก็เกิดขึ้นภายในชุมชน Agile หรือในงานประชุม Agile ดังที่ได้อธิบายไว้ด้านล่าง

Agile Infrastructure และขบวนการ Velocity

ในงานประชุม Agile ปี 2008 ที่เมืองโตรอนโต ประเทศแคนาดา Patrick Debois และ Andrew Shafer ได้จัด session แบบ "birds of a feather" เกี่ยวกับการประยุกต์ใช้หลักการ Agile กับ infrastructure แทนที่จะเป็น application code (ในช่วงแรกๆ สิ่งนี้ถูกเรียกว่า "Agile system administration") แม้ว่าพวกเขาจะเป็นเพียงคนสองคนที่มาร่วมงาน แต่พวกเขาก็ได้รับกลุ่มผู้ติดตามที่มีแนวคิดเดียวกันอย่างรวดเร็ว รวมถึง John Willis ผู้ร่วมเขียนหนังสือเล่มนี้ด้วย

การเรียนรู้อย่างต่อเนื่อง

ในช่วงเวลาเดียวกันนั้น นักวิชาการหลายคนเริ่มศึกษาผู้ดูแลระบบ (system administrators) ว่าพวกเขาประยุกต์ใช้หลักการทางวิศวกรรมกับงานของตนอย่างไร และส่งผลต่อประสิทธิภาพการทำงานอย่างไร ผู้เชี่ยวชาญชั้นนำรวมถึงกลุ่มจาก IBM Research ซึ่งมีการศึกษาเชิงชาติพันธุ์วรรณนานำโดย Dr. Eben Haber, Dr. Eser Kandogan และ Dr. Paul Maglio งานวิจัยนี้ถูกขยายไปสู่การศึกษาเชิงปริมาณเชิงพฤติกรรมที่นำโดย Dr. Nicole Forsgren ผู้ร่วมเขียนหนังสือ ในปี 2007–2009 Nicole ดำเนินการวิจัยต่อใน State of DevOps Reports ประจำปี 2014–2019 ซึ่งเป็นงานวิจัยมาตรฐานอุตสาหกรรมเกี่ยวกับแนวทางปฏิบัติและความสามารถที่ขับเคลื่อนการส่งมอบซอฟต์แวร์และประสิทธิภาพ งานวิจัยเหล่านี้ถูกเผยแพร่โดย Puppet และ DORA

ต่อมาในงานประชุม Velocity ปี 2009 John Allspaw และ Paul Hammond ได้นำเสนอครั้งสำคัญเรื่อง "10 Deploys per Day: Dev and Ops Cooperation at Flickr" ซึ่งพวกเขาอธิบายว่าพวกเขาสร้างเป้าหมายร่วมกันระหว่าง Dev และ Ops และใช้แนวทางปฏิบัติ continuous integration เพื่อทำให้การ deployment เป็นส่วนหนึ่งของงานประจำวันของทุกคนอย่างไร ตามคำบอกเล่าของผู้ที่เข้าร่วมฟังโดยตรง ทุกคนที่เข้าร่วมการนำเสนอต่างรู้ได้ทันทีว่าพวกเขากำลังอยู่ในเหตุการณ์ที่ลึกซึ้งและมีความสำคัญทางประวัติศาสตร์

Patrick Debois ตื่นเต้นกับแนวคิดของ Allspaw และ Hammond มากจนเขาจัดงาน DevOpsDays ครั้งแรกขึ้นที่เมือง Ghent ประเทศเบลเยียม ในปี 2009 ซึ่งเป็นที่มาของการบัญญัติคำว่า "DevOps"

ขบวนการ Continuous Delivery

ต่อยอดจากวินัยด้านการพัฒนาที่เกี่ยวกับ continuous build, test และ integration นั้น Jez Humble และ David Farley ได้ขยายแนวคิดไปสู่ continuous delivery ซึ่งกำหนดบทบาทของ "deployment pipeline" เพื่อให้แน่ใจว่าโค้ดและ infrastructure อยู่ในสถานะที่พร้อม deploy ได้ตลอดเวลา และโค้ดทั้งหมดที่ถูก check เข้า trunk สามารถ deploy สู่ production ได้อย่างปลอดภัย แนวคิดนี้ถูกนำเสนอครั้งแรกในงานประชุม Agile ปี 2006 และยังได้รับการพัฒนาอย่างอิสระในปี 2009 โดย Tim Fitz ในบล็อกโพสต์บนเว็บไซต์ของเขาที่ชื่อ "Continuous Deployment" *

Toyota Kata

ในปี 2009 Mike Rother เขียน Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results ซึ่งถ่ายทอดการเดินทางยี่สิบปีของเขาในการทำความเข้าใจและจัดระบบ Toyota Production System เขาเป็นหนึ่งในนักศึกษาปริญญาโทที่เดินทางไปกับผู้บริหารของ GM เพื่อเยี่ยมชมโรงงานของ Toyota และช่วยพัฒนา Lean toolkit แต่เขากลับงุนงงเมื่อไม่มีบริษัทใดที่นำแนวทางปฏิบัติเหล่านี้ไปใช้แล้วสามารถทำซ้ำระดับประสิทธิภาพที่สังเกตเห็นในโรงงานของ Toyota ได้

เขาสรุปว่าชุมชน Lean พลาดแนวทางปฏิบัติที่สำคัญที่สุดไป ซึ่งเขาเรียกว่า improvement kata . 2 เขาอธิบายว่าทุกองค์กรมีรูปแบบการทำงานประจำ และ improvement kata ต้องการการสร้างโครงสร้างสำหรับการปฏิบัติงานปรับปรุงอย่างเป็นกิจวัตรประจำวัน เพราะการปฏิบัติประจำวันคือสิ่งที่ช่วยปรับปรุงผลลัพธ์ วงจรของการกำหนดสถานะในอนาคตที่ต้องการ การตั้ง target outcomes อย่างสม่ำเสมอ และการปรับปรุงงานประจำวันอย่างต่อเนื่องคือสิ่งที่นำทางการปรับปรุงที่ Toyota

ตลอดส่วนที่เหลือของ Part I เราจะดู value streams ว่าหลักการ Lean สามารถประยุกต์ใช้กับ technology value stream ได้อย่างไร และ Three Ways ได้แก่ Flow, Feedback และ Continual Learning and Experimentation

*

DevOps ยังขยายและต่อยอดจากแนวทางปฏิบัติของ infrastructure as code ซึ่งบุกเบิกโดย Dr. Mark Burgess, Luke Kanies และ Adam Jacob ใน infrastructure as code งานของ Operations จะถูกทำให้เป็นอัตโนมัติและปฏิบัติเสมือนเป็น application code เพื่อให้แนวทางปฏิบัติการพัฒนาสมัยใหม่สามารถนำไปใช้กับทั้ง development stream ได้ สิ่งนี้ยิ่งช่วยให้เกิดการ deploy ที่รวดเร็ว รวมถึง continuous integration (บุกเบิกโดย Grady Booch และถูกผนวกเป็นหนึ่งใน 12 แนวทางปฏิบัติสำคัญของ Extreme Programming), continuous delivery (บุกเบิกโดย Jez Humble และ David Farley) และ continuous deployment (บุกเบิกโดย Etsy, Wealthfront และงานของ Eric Ries ที่ IMVU)