Chapter 01 Introduction

บทนำ

จินตนาการถึงโลกที่ Dev และ Ops กลายเป็น DevOps

จ ินตนาการถึงโลกที่ product owners, Development, QA, IT Operations และ Infosec ทำงานร่วมกัน ไม่เพียงเพื่อช่วยเหลือซึ่งกันและกัน แต่เพื่อให้แน่ใจว่าองค์กรโดยรวมประสบความสำเร็จ ด้วยการทำงานไปสู่เป้าหมายร่วมกัน พวกเขาทำให้งานที่วางแผนไว้ไหลเข้าสู่ระบบ production ได้อย่างรวดเร็ว (เช่น การ deploy โค้ดวันละสิบ ร้อย หรือพันครั้ง) ในขณะที่รักษาความเสถียร ความน่าเชื่อถือ ความพร้อมใช้งาน และความปลอดภัยระดับโลก

ในโลกนี้ ทีม cross-functional จะทดสอบสมมติฐานของตนอย่างเข้มข้นว่าฟีเจอร์ใดจะทำให้ผู้ใช้พึงพอใจมากที่สุดและขับเคลื่อนเป้าหมายขององค์กร พวกเขาไม่เพียงแค่ใส่ใจในการ implement ฟีเจอร์สำหรับผู้ใช้ แต่ยัง actively ทำให้แน่ใจว่างานของพวกเขาไหลลื่นและสม่ำเสมอผ่าน value stream ทั้งหมด โดยไม่ก่อให้เกิดความโกลาหลและการหยุดชะงักต่อ IT Operations หรือลูกค้าภายในและภายนอกอื่นๆ

ในเวลาเดียวกัน QA, IT Operations และ Infosec ก็ทำงานเพื่อหาวิธีลด friction ให้ทีมอยู่เสมอ โดยสร้างระบบการทำงานที่ช่วยให้นักพัฒนาทำงานได้มีประสิทธิภาพมากขึ้นและได้ผลลัพธ์ที่ดีขึ้น ด้วยการนำความเชี่ยวชาญของ QA, IT Operations และ Infosec ไปไว้ใน delivery teams และเครื่องมือและแพลตฟอร์ม self-service แบบอัตโนมัติ ทีมต่างๆ จึงสามารถใช้ความเชี่ยวชาญนั้นในการทำงานประจำวันได้โดยไม่ต้องพึ่งพาทีมอื่น

สิ่งนี้ช่วยให้องค์กรสร้างระบบการทำงานที่ปลอดภัย ซึ่งทีมเล็กๆ สามารถพัฒนา ทดสอบ และ deploy โค้ดและคุณค่าให้กับลูกค้าได้อย่างรวดเร็ว ปลอดภัย และเชื่อถือได้โดยอิสระ ทำให้องค์กรสามารถ maximize productivity ของนักพัฒนา สร้างการเรียนรู้ขององค์กร สร้างความพึงพอใจของพนักงานในระดับสูง และชนะในตลาด

สิ่งเหล่านี้คือผลลัพธ์ที่เกิดจาก DevOps สำหรับพวกเราส่วนใหญ่ นี่ไม่ใช่โลกที่เราอยู่อาศัย บ่อยครั้งที่ระบบที่เราทำงานอยู่นั้นพังเสียหาย ส่งผลให้ได้ผลลัพธ์ที่ย่ำแย่ซึ่งต่ำกว่าศักยภาพที่แท้จริงของเรามาก ในโลกของเรา Development และ IT Operations เป็นปฏิปักษ์ต่อกัน กิจกรรมการทดสอบและ Infosec เกิดขึ้นเฉพาะช่วงท้ายของโปรเจกต์ ซึ่งสายเกินไปที่จะแก้ไขปัญหาที่พบ และกิจกรรมสำคัญแทบทุกอย่างต้องใช้ความพยายามด้วยมือและ handoffs มากเกินไป ทำให้เราต้องรอคอยอยู่เสมอ ไม่เพียงแต่ทำให้ lead time ยาวนานอย่างมากในการทำสิ่งต่างๆ ให้สำเร็จ แต่อีกทั้งคุณภาพของงาน โดยเฉพาะการ deploy สู่ production ก็ยังมีปัญหาและวุ่นวาย ส่งผลกระทบเชิงลบต่อลูกค้าและธุรกิจของเรา

ผลที่ตามมาก็คือ เราล้มเหลวในการบรรลุเป้าหมายอย่างมาก และทั้งองค์กรไม่พอใจกับประสิทธิภาพของ IT ส่งผลให้งบประมาณลดลง และพนักงานที่หงุดหงิด ไม่มีความสุข ซึ่งรู้สึกไร้พลังที่จะเปลี่ยนแปลงกระบวนการและผลลัพธ์ของมัน * ทางออก? เราจำเป็นต้องเปลี่ยนวิธีทำงาน DevOps คือหนทางที่ดีที่สุดที่จะก้าวไปข้างหน้า

เพื่อให้เข้าใจศักยภาพของการปฏิวัติ DevOps ได้ดียิ่งขึ้น ลองดูการปฏิวัติด้านการผลิตในทศวรรษ 1980 กัน ด้วยการนำหลักการและแนวปฏิบัติแบบ Lean มาใช้ องค์กรด้านการผลิตสามารถปรับปรุง productivity ของโรงงาน lead time ของลูกค้า คุณภาพผลิตภัณฑ์ และความพึงพอใจของลูกค้าได้อย่างมาก ทำให้พวกเขาชนะในตลาด

ก่อนการปฏิวัติ ระยะเวลา lead time เฉลี่ยของคำสั่งซื้อในโรงงานผลิตอยู่ที่หกสัปดาห์ โดยมีคำสั่งซื้อน้อยกว่า 70% ที่จัดส่งตรงเวลา ภายในปี 2005 ด้วยการนำแนวปฏิบัติแบบ Lean ไปใช้อย่างแพร่หลาย ระยะเวลา lead time เฉลี่ยของผลิตภัณฑ์ลดลงเหลือน้อยกว่าสามสัปดาห์ และมากกว่า 95% ของคำสั่งซื้อจัดส่งตรงเวลา 1 องค์กรที่ไม่นำแนวปฏิบัติแบบ Lean มาใช้สูญเสียส่วนแบ่งตลาด และหลายแห่งก็ต้องเลิกกิจการไปในที่สุด

ในทำนองเดียวกัน มาตรฐานสำหรับการส่งมอบผลิตภัณฑ์และบริการด้านเทคโนโลยีก็สูงขึ้น—สิ่งที่เคยดีพอในทศวรรษก่อนๆ นั้นไม่เพียงพออีกต่อไป ในแต่ละสี่ทศวรรษที่ผ่านมา ต้นทุนและเวลาที่ต้องใช้ในการพัฒนาและ deploy ความสามารถและฟีเจอร์ทางธุรกิจเชิงกลยุทธ์ลดลงเป็นลำดับหลายเท่า ในช่วงทศวรรษ 1970 และ 1980 ฟีเจอร์ใหม่ส่วนใหญ่ต้องใช้เวลาหนึ่งถึงห้าปีในการพัฒนาและ deploy ซึ่งมักมีค่าใช้จ่ายหลายสิบล้านดอลลาร์

พอมาถึงช่วงทศวรรษ 2000 ด้วยความก้าวหน้าทางเทคโนโลยีและการนำหลักการและแนวปฏิบัติแบบ Agile มาใช้ เวลาที่ต้องใช้ในการพัฒนาฟังก์ชันการทำงานใหม่ลดลงเหลือเพียงสัปดาห์หรือเดือน แต่การ deploy สู่ production ยังคงต้องใช้เวลาหลายสัปดาห์หรือหลายเดือน ซึ่งมักส่งผลลัพธ์ที่หายนะ

และเมื่อถึงปี 2010 ด้วยการถือกำเนิดของ DevOps และการทำให้ hardware, software และ cloud กลายเป็นสินค้าทั่วไปที่เกิดขึ้นอย่างต่อเนื่อง ฟีเจอร์ต่างๆ (รวมถึงทั้งบริษัท startup) สามารถถูกสร้างขึ้นได้ในไม่กี่สัปดาห์ และ deploy สู่ production อย่างรวดเร็วในเวลาเพียงชั่วโมงหรือนาที—สำหรับองค์กรเหล่านี้ การ deploy กลายเป็นเรื่องปกติและมีความเสี่ยงต่ำในที่สุด องค์กรเหล่านี้สามารถทำการทดลองเพื่อทดสอบแนวคิดทางธุรกิจ ค้นพบว่าแนวคิดใดสร้างคุณค่าสูงสุดให้กับลูกค้าและองค์กรโดยรวม และแนวคิดใดที่ถูกพัฒนาต่อเป็นฟีเจอร์ที่สามารถ deploy สู่ production ได้อย่างรวดเร็วและปลอดภัย

ตาราง 0.1: แนวโน้มที่เร่งตัวขึ้นเรื่อยๆ สู่การส่งมอบซอฟต์แวร์ที่เร็วขึ้น ถูกขึ้น และมีความเสี่ยงต่ำลง

	ทศวรรษ 1970–1980	ทศวรรษ 1990	ทศวรรษ 2000–ปัจจุบัน
ยุค	Mainframes	Client/Server	Commoditization และ Cloud
เทคโนโลยีตัวแทนของยุค	COBOL, DB2 บน MVS ฯลฯ	C++, Oracle, Solaris ฯลฯ	Java, MySQL, Red Hat, Ruby on Rails, PHP ฯลฯ
ระยะเวลา Cycle time	1–5 ปี	3–12 เดือน	2–12 สัปดาห์
ต้นทุน	$1M–$100M	$100k–$10M	$10k–$1M
ความเสี่ยง	ทั้งบริษัท	กลุ่มผลิตภัณฑ์หรือแผนก	ฟีเจอร์ของผลิตภัณฑ์
ต้นทุนของความล้มเหลว	ล้มละลาย ขายบริษัท เลิกจ้างจำนวนมาก	พลาดรายได้ ตำแหน่ง CIO	เล็กน้อย

ที่มา: Adrian Cockcroft, "Velocity and Volume (or Speed Wins)," การนำเสนอที่ FlowCon, ซานฟรานซิสโก, รัฐแคลิฟอร์เนีย, พฤศจิกายน 2013.

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

ทุกวันนี้ ไม่ว่าเราจะแข่งขันในอุตสาหกรรมใด วิธีการที่เราได้ลูกค้าและส่งมอบคุณค่าให้กับพวกเขาล้วนขึ้นอยู่กับ technology value stream พูดให้สั้นกว่านั้น ดังที่ Jeffrey Immelt ซีอีโอของ General Electric กล่าวไว้ว่า "ทุกอุตสาหกรรมและทุกบริษัทที่ไม่นำซอฟต์แวร์มาเป็นแกนกลางของธุรกิจจะต้องถูก disrupt" 2 หรือดังที่ Jeffrey Snover Technical Fellow ของ Microsoft กล่าวว่า "ในยุคเศรษฐกิจก่อนหน้านี้ ธุรกิจสร้างคุณค่าด้วยการเคลื่อนย้ายอะตอม ตอนนี้พวกเขาสร้างคุณค่าด้วยการเคลื่อนย้ายบิต" 3

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

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

ปัญหา: บางสิ่งในองค์กรของคุณต้องได้รับการปรับปรุง (ไม่อย่างนั้นคุณคงไม่อ่านหนังสือเล่มนี้)

องค์กรส่วนใหญ่ไม่สามารถ deploy การเปลี่ยนแปลงสู่ production ได้ในเวลาไม่กี่นาทีหรือชั่วโมง แต่กลับต้องใช้เวลาหลายสัปดาห์หรือเดือน พวกเขาไม่สามารถ deploy การเปลี่ยนแปลงหลายร้อยหรือพันครั้งสู่ production ต่อวันได้ แต่กลับต้องดิ้นรนเพื่อ deploy เป็นรายเดือนหรือรายไตรมาส การ deploy สู่ production ก็ไม่ใช่เรื่องปกติ แต่กลับมี outage และการแก้ปัญหาหน้างานและการใช้ความพยายามอย่างหนักอย่างเรื้อรัง

ในยุคที่ความได้เปรียบทางการแข่งขันต้องการความเร็วในการออกสู่ตลาด ระดับการให้บริการที่สูง และการทดลองอย่างไม่หยุดยั้ง องค์กรเหล่านี้เสียเปรียบทางการแข่งขันอย่างมาก สาเหตุส่วนใหญ่มาจากความไม่สามารถแก้ไขความขัดแย้งหลักที่เรื้อรังภายในองค์กรเทคโนโลยีของพวกเขา

ความขัดแย้งหลักที่เรื้อรัง

ในองค์กร IT เกือบทุกแห่ง มีความขัดแย้งโดยธรรมชาติระหว่าง Development และ IT Operations ที่สร้างวงจรขาลง ส่งผลให้เวลาในการออกสู่ตลาดสำหรับผลิตภัณฑ์และฟีเจอร์ใหม่ช้าลงเรื่อยๆ คุณภาพลดลง outage เพิ่มขึ้น และที่แย่ที่สุดคือ technical debt ที่เพิ่มขึ้นอย่างไม่หยุดยั้ง

คำว่า "technical debt" ถูกบัญญัติขึ้นครั้งแรกโดย Ward Cunningham คล้ายคลึงกับหนี้สินทางการเงิน technical debt อธิบายว่าการตัดสินใจของเรานำไปสู่ปัญหาที่แก้ไขได้ยากขึ้นเรื่อยๆ เมื่อเวลาผ่านไป ลดทางเลือกที่มีอยู่ของเราในอนาคตอย่างต่อเนื่อง—แม้เมื่อก่อหนี้อย่างรอบคอบ เราก็ยังต้องจ่ายดอกเบี้ย

ปัจจัยหนึ่งที่ส่งผลให้เกิดสิ่งนี้คือเป้าหมายที่มักจะขัดแย้งกันของ Development และ IT Operations องค์กร IT ต้องรับผิดชอบหลายอย่าง ในจำนวนนั้นมีเป้าหมายสองประการต่อไปนี้ที่ต้องดำเนินการพร้อมกัน:

• ตอบสนองต่อภูมิทัศน์ทางการแข่งขันที่เปลี่ยนแปลงอย่างรวดเร็ว

• ให้บริการที่เสถียร เชื่อถือได้ และปลอดภัยแก่ลูกค้า

บ่อยครั้งที่ Development จะรับผิดชอบในการตอบสนองต่อการเปลี่ยนแปลงในตลาดและการ deploy ฟีเจอร์และการเปลี่ยนแปลงต่างๆ สู่ production โดยเร็วที่สุด ในขณะที่ IT Operations จะรับผิดชอบในการให้บริการ IT ที่เสถียร เชื่อถือได้ และปลอดภัยแก่ลูกค้า ทำให้เป็นเรื่องยากหรือเป็นไปไม่ได้เลยที่ใครจะนำการเปลี่ยนแปลงสู่ production ที่อาจเป็นอันตรายต่อระบบ production เมื่อถูกจัดวางแบบนี้ Development และ IT Operations จึงมีเป้าหมายและสิ่งจูงใจที่ตรงกันข้ามกันอย่างสิ้นเชิง

Dr. Eliyahu M. Goldratt หนึ่งในผู้ก่อตั้งขบวนการการจัดการด้านการผลิต เรียกการจัดวางรูปแบบนี้ว่า "ความขัดแย้งหลักที่เรื้อรัง"—เมื่อการวัดผลและสิ่งจูงใจขององค์กรใน silo ต่างๆ ขัดขวางการบรรลุเป้าหมายระดับโลกขององค์กร 4 †

ความขัดแย้งนี้สร้างวงจรขาลงที่ทรงพลังจนขัดขวางการบรรลุผลลัพธ์ทางธุรกิจที่ต้องการ ทั้งภายในและภายนอกองค์กร IT ความขัดแย้งที่เรื้อรังเหล่านี้มักทำให้พนักงานเทคโนโลยีตกอยู่ในสถานการณ์ที่นำไปสู่คุณภาพซอฟต์แวร์และบริการที่แย่ ผลลัพธ์ของลูกค้าที่ไม่ดี รวมถึงความจำเป็นในชีวิตประจำวันในการหาทางอ้อม การแก้ปัญหาเฉพาะหน้า และการใช้ความพยายามอย่างหนัก ไม่ว่าจะใน Product Management, Development, QA, IT Operations หรือ Information Security (ดู ภาคผนวก 2 .)

วงจรขาลงในสามองก์

วงจรขาลงใน IT มีสามองก์ที่ผู้ปฏิบัติงาน IT ส่วนใหญ่น่าจะคุ้นเคย องก์แรกเริ่มต้นใน IT Operations ที่เป้าหมายของเราคือการทำให้แอปพลิเคชันและโครงสร้างพื้นฐานทำงานต่อไปได้ เพื่อให้องค์กรของเราสามารถส่งมอบคุณค่าให้กับลูกค้า ในการทำงานประจำวัน ปัญหามากมายของเราเกิดจากแอปพลิเคชันและโครงสร้างพื้นฐานที่ซับซ้อน มีเอกสารไม่ดี และเปราะบางอย่างไม่น่าเชื่อ นี่คือ technical debt และการหาทางอ้อมในชีวิตประจำวันที่เราอยู่ด้วยตลอดเวลา โดยสัญญาเสมอว่าเราจะแก้ไขความยุ่งเหยิงนี้เมื่อเรามีเวลาเพิ่มขึ้นอีกหน่อย แต่เวลานั้นไม่มีวันมาถึง

น่าตกใจว่า artifacts ที่เปราะบางที่สุดของเรามักจะรองรับระบบที่สร้างรายได้สำคัญที่สุดหรือโปรเจกต์ที่สำคัญที่สุดของเรา กล่าวอีกนัยหนึ่ง ระบบที่มีแนวโน้มจะล้มเหลวมากที่สุดก็คือระบบที่สำคัญที่สุดของเรา และเป็นศูนย์กลางของการเปลี่ยนแปลงที่เร่งด่วนที่สุดของเรา เมื่อการเปลี่ยนแปลงเหล่านี้ล้มเหลว พวกมันก็เป็นอันตรายต่อคำมั่นสัญญาที่สำคัญที่สุดขององค์กร เช่น ความพร้อมใช้งานสำหรับลูกค้า เป้าหมายรายได้ ความปลอดภัยของข้อมูลลูกค้า การรายงานทางการเงินที่แม่นยำ และอื่นๆ

องก์ที่สองเริ่มต้นเมื่อมีคนต้องชดเชยกับคำมั่นสัญญาที่ถูกผิดคำสัญญาล่าสุด—อาจเป็น product manager ที่สัญญาฟีเจอร์ที่ใหญ่กว่าและโดดเด่นกว่าเพื่อดึงดูดลูกค้า หรือผู้บริหารธุรกิจที่ตั้งเป้าหมายรายได้ที่ใหญ่ขึ้นไปอีก จากนั้น โดยไม่คำนึงถึงว่าเทคโนโลยีทำอะไรได้หรือไม่ได้ หรือปัจจัยอะไรที่ทำให้เราพลาดคำมั่นสัญญาก่อนหน้านี้ พวกเขาก็ให้คำมั่นกับองค์กรเทคโนโลยีว่าจะส่งมอบตามคำมั่นสัญญาใหม่นี้

ผลก็คือ Development ได้รับมอบหมายโปรเจกต์เร่งด่วนอีกโปรเจกต์ที่ต้องแก้ไขความท้าทายทางเทคนิคใหม่และตัดมุมเพื่อให้ทันกำหนดส่งตามที่สัญญาไว้ ซึ่งเพิ่ม technical debt เข้าไปอีก—แน่นอนว่ามาพร้อมกับคำมั่นสัญญาว่าเราจะแก้ไขปัญหาที่เกิดขึ้นเมื่อเรามีเวลาเพิ่มขึ้นอีกหน่อย

สิ่งนี้ปูทางไปสู่องก์ที่สามและองก์สุดท้าย ที่ทุกอย่างยากขึ้นอีกเล็กน้อย ทีละน้อย—ทุกคนยุ่งมากขึ้นอีกหน่อย งานใช้เวลามากขึ้นอีกหน่อย การสื่อสารช้าลงอีกหน่อย และคิวงานยาวขึ้นอีกหน่อย งานของเราเชื่อมโยงแน่นหนามากขึ้น การกระทำเล็กๆ ก่อให้เกิดความล้มเหลวที่ใหญ่ขึ้น และเรากลายเป็นคนที่หวาดกลัวและอดทนต่อการเปลี่ยนแปลงน้อยลง งานต้องใช้การสื่อสาร การประสานงาน และการอนุมัติมากขึ้น ทีมต้องรอคือนานขึ้นอีกหน่อยให้งานที่ต้องพึ่งพากันเสร็จ และคุณภาพของเราก็แย่ลงเรื่อยๆ วงล้อเริ่มหมุนช้าลงและต้องใช้ความพยายามมากขึ้นเพื่อให้หมุนต่อไปได้ (ดู ภาคผนวก 3 .)

แม้จะมองเห็นได้ยากในขณะนั้น แต่วงจรขาลงจะชัดเจนเมื่อเราก้าวถอยหลังมาดู เราสังเกตว่าการ deploy โค้ดสู่ production ใช้เวลาเสร็จนานขึ้นเรื่อยๆ จากนาทีเป็นชั่วโมง เป็นวัน เป็นสัปดาห์ และที่แย่กว่านั้น ผลลัพธ์ของการ deploy ก็ยิ่งมีปัญหามากขึ้น ส่งผลให้เกิด outage ที่กระทบลูกค้าเพิ่มขึ้นเรื่อยๆ ซึ่งต้องใช้ความพยายามอย่างหนักและการแก้ปัญหาเฉพาะหน้าใน Operations มากขึ้น ทำให้พวกเขายิ่งหมดความสามารถในการลด technical debt

ผลที่ตามมา วงจรการส่งมอบผลิตภัณฑ์ของเรายิ่งช้าลงและช้าลง มีโปรเจกต์ที่ดำเนินการน้อยลง และโปรเจกต์ที่ทำก็มีความทะเยอทะยานน้อยลง ยิ่งไปกว่านั้น feedback เกี่ยวกับงานของทุกคนก็ช้าลงและอ่อนแอลง โดยเฉพาะสัญญาณ feedback จากลูกค้าของเรา และไม่ว่าเราจะลองทำอะไร สิ่งต่างๆ ก็ดูจะแย่ลง—เราไม่สามารถตอบสนองต่อภูมิทัศน์ทางการแข่งขันที่เปลี่ยนแปลงไปได้อย่างรวดเร็วอีกต่อไป และไม่สามารถให้บริการที่เสถียรและเชื่อถือได้แก่ลูกค้าของเรา ท้ายที่สุดเราก็พ่ายแพ้ในตลาด

ครั้งแล้วครั้งเล่า เราเรียนรู้ว่าเมื่อ IT ล้มเหลว ทั้งองค์กรก็ล้มเหลว ดังที่ Steven J. Spear กล่าวไว้ในหนังสือของเขา The High-Velocity Edge ว่าไม่ว่าความเสียหายจะ "ค่อยๆ คลี่คลายช้าๆ เหมือนโรคที่ค่อยๆ รุมเร้า" หรือรวดเร็ว "เหมือนเครื่องบินตก ... การทำลายล้างก็สมบูรณ์ได้ไม่แพ้กัน" 5

ทำไมวงจรขาลงนี้ถึงเกิดขึ้นทุกที่?

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

ดังที่ Christopher Little ผู้บริหารซอฟต์แวร์และหนึ่งในผู้บันทึกเรื่องราวแรกๆ ของ DevOps กล่าวว่า "ทุกบริษัทคือบริษัทเทคโนโลยี ไม่ว่าพวกเขาจะคิดว่าตัวเองทำธุรกิจอะไรก็ตาม ธนาคารก็แค่บริษัท IT ที่มีใบอนุญาตธนาคาร" 6 ‡ เพื่อให้แน่ใจว่าเราเห็นด้วยกับข้อนี้ ลองพิจารณาว่าโปรเจกต์ด้านทุนส่วนใหญ่ล้วนพึ่งพา IT อยู่บ้าง ดังคำกล่าวที่ว่า "แทบจะเป็นไปไม่ได้เลยที่จะตัดสินใจทางธุรกิจใดๆ โดยไม่ส่งผลให้เกิดการเปลี่ยนแปลงทาง IT อย่างน้อยหนึ่งอย่าง"

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

โปรเจกต์มักได้รับเงินทุนผ่านการใช้จ่ายด้านทุน (เช่น โรงงาน อุปกรณ์ และโปรเจกต์ขนาดใหญ่ โดยรายจ่ายจะถูกบันทึกเป็นทุนเมื่อคาดว่าจะได้รับผลตอบแทนในระยะเวลาหลายปี) ซึ่ง 50% ของรายจ่ายนี้เกี่ยวข้องกับเทคโนโลยีในปัจจุบัน สิ่งนี้เป็นจริงแม้แต่ในอุตสาหกรรมแนวตั้ง "low tech" ที่มีประวัติการใช้จ่ายด้านเทคโนโลยีต่ำที่สุด เช่น พลังงาน โลหะ การสกัดทรัพยากร ยานยนต์ และการก่อสร้าง 8 กล่าวอีกนัยหนึ่ง ผู้บริหารธุรกิจต้องพึ่งพาการจัดการ IT ที่มีประสิทธิภาพเพื่อบรรลุเป้าหมายของตนมากกว่าที่พวกเขาคิด ¶

ต้นทุน: ด้านมนุษย์และเศรษฐกิจ

เมื่อผู้คนติดอยู่ในวงจรขาลงนี้เป็นเวลาหลายปี โดยเฉพาะผู้ที่อยู่ downstream จาก Development พวกเขามักรู้สึกติดอยู่ในระบบที่กำหนดความล้มเหลวไว้ล่วงหน้าและปล่อยให้พวกเขาไร้พลังที่จะเปลี่ยนแปลงผลลัพธ์ ความไร้พลังนี้มักตามมาด้วยภาวะหมดไฟ (burnout) พร้อมกับความรู้สึกเหนื่อยล้า ดูถูกเหยียดหยาม และแม้กระทั่งสิ้นหวัง

นักจิตวิทยาหลายคนยืนยันว่าการสร้างระบบที่ทำให้เกิดความรู้สึกไร้พลังเป็นสิ่งที่ทำลายล้างมากที่สุดอย่างหนึ่งที่เราสามารถทำต่อเพื่อนมนุษย์—เราพรากความสามารถของผู้อื่นในการควบคุมผลลัพธ์ของตนเอง และยังสร้างวัฒนธรรมที่ผู้คนกลัวที่จะทำสิ่งที่ถูกต้องเนื่องจากกลัวการลงโทษ ความล้มเหลว หรือการเสี่ยงต่อการทำมาหากินของตน วัฒนธรรมแบบนี้สามารถสร้างเงื่อนไขสำหรับการเรียนรู้ helplessness (learned helplessness) ที่ผู้คนไม่เต็มใจหรือไม่สามารถทำสิ่งที่หลีกเลี่ยงปัญหาเดียวกันในอนาคต

สำหรับพนักงานของเรา มันหมายถึงชั่วโมงทำงานที่ยาวนาน ทำงานในวันหยุดสุดสัปดาห์ และคุณภาพชีวิตที่ลดลง ไม่ใช่แค่สำหรับพนักงานเท่านั้น แต่สำหรับทุกคนที่ต้องพึ่งพาพวกเขา รวมถึงครอบครัวและเพื่อนฝูง ไม่น่าแปลกใจที่เมื่อสิ่งนี้เกิดขึ้น เราจะสูญเสียคนที่ดีที่สุดของเรา (ยกเว้นคนที่รู้สึกว่าตนเองออกไม่ได้เพราะความรู้สึกในหน้าที่หรือพันธะ)

นอกเหนือจากความทุกข์ทรมานของมนุษย์ที่มาพร้อมกับวิธีการทำงานในปัจจุบันแล้ว ต้นทุนค่าเสียโอกาสของคุณค่าที่เราสามารถสร้างได้นั้นมหาศาล—ผู้เขียนเชื่อว่าเรากำลังพลาดโอกาสในการสร้างมูลค่าประมาณ 2.6 ล้านล้านดอลลาร์ต่อปี ซึ่ง ณ เวลาที่เขียนนี้ เทียบเท่ากับผลผลิตทางเศรษฐกิจประจำปีของฝรั่งเศส ซึ่งเป็นเศรษฐกิจที่ใหญ่เป็นอันดับหกของโลก

ลองพิจารณาการคำนวณต่อไปนี้—ทั้ง IDC และ Gartner ประมาณการว่าในปี 2011 ประมาณ 5% ของผลิตภัณฑ์มวลรวมภายในประเทศทั่วโลก (3.1 ล้านล้านดอลลาร์) ถูกใช้จ่ายไปกับ IT (ฮาร์ดแวร์ บริการ และโทรคมนาคม) 10 หากเราประมาณว่า 50% ของ 3.1 ล้านล้านดอลลาร์นั้นถูกใช้ไปกับค่าใช้จ่ายในการดำเนินงานและการบำรุงรักษาระบบที่มีอยู่ และหนึ่งในสามของ 50% นั้นถูกใช้ไปกับงานเร่งด่วนและไม่ได้วางแผนไว้หรืองานที่ต้องทำซ้ำ จะมีมูลค่าประมาณ 520 พันล้านดอลลาร์ที่สูญเปล่า

หากการนำ DevOps มาใช้ช่วยให้เรา—ผ่านการจัดการที่ดีขึ้นและความเป็นเลิศในการดำเนินงานที่เพิ่มขึ้น—ลดความสูญเสียนั้นลงครึ่งหนึ่งและนำศักยภาพของมนุษย์นั้นไปใช้ในสิ่งที่มีมูลค่ามากกว่าถึงห้าเท่า (ข้อเสนอที่ไม่เกินจริง) เราก็จะสามารถสร้างมูลค่า 2.6 ล้านล้านดอลลาร์ต่อปีได้

จริยธรรมของ DevOps: There Is a Better Way (มีหนทางที่ดีกว่า)

ในส่วนก่อนหน้านี้ เราได้อธิบายปัญหาและผลเสียของสถานะที่เป็นอยู่เนื่องมาจากความขัดแย้งหลักที่เรื้อรัง ตั้งแต่การไม่สามารถบรรลุเป้าหมายขององค์กรไปจนถึงความเสียหายที่เรากระทำต่อเพื่อนมนุษย์ การแก้ปัญหาเหล่านี้ทำให้ DevOps สามารถปรับปรุงประสิทธิภาพขององค์กร บรรลุเป้าหมายของบทบาทด้านเทคโนโลยีที่หลากหลาย (เช่น Development, QA, IT Operations, Infosec) และปรับปรุงสภาพความเป็นอยู่ของมนุษย์ไปพร้อมๆ กันอย่างน่าอัศจรรย์

การผสมผสานที่น่าตื่นเต้นและหาได้ยากนี้อาจอธิบายได้ว่าทำไม DevOps ถึงสร้างความตื่นเต้นและกระตือรือร้นให้กับคนจำนวนมากในเวลาอันสั้น รวมถึงผู้นำด้านเทคโนโลยี วิศวกร และระบบนิเวศซอฟต์แวร์ส่วนใหญ่ที่เราอยู่อาศัย

Breaking the Downward Spiral with DevOps (ทำลายวงจรขาลงด้วย DevOps)

ในอุดมคติ ทีมนักพัฒนาขนาดเล็ก implement ฟีเจอร์ของตนอย่างอิสระ ตรวจสอบความถูกต้องในสภาพแวดล้อมที่เหมือน production และ deploy โค้ดของตนสู่ production อย่างรวดเร็ว ปลอดภัย และเชื่อถือได้ การ deploy โค้ดเป็นเรื่องปกติและคาดเดาได้ แทนที่จะเริ่ม deploy ในเที่ยงคืนวันศุกร์และใช้เวลาทั้งสุดสัปดาห์ทำงานเพื่อให้เสร็จ การ deploy เกิดขึ้นตลอดเวลาทำงานเมื่อทุกคนอยู่ในออฟฟิศแล้ว และลูกค้าของเราไม่รู้สึกถึงมันเลย—ยกเว้นเมื่อพวกเขาเห็นฟีเจอร์ใหม่และการแก้ไขบั๊กที่ทำให้พวกเขาพึงพอใจ และด้วยการ deploy โค้ดในระหว่างวันทำงาน IT Operations ก็ทำงานในช่วงเวลาทำงานปกติเหมือนคนอื่นๆ เป็นครั้งแรกในรอบหลายทศวรรษ

ด้วยการสร้าง fast feedback loops ในทุกขั้นตอนของกระบวนการ ทุกคนสามารถเห็นผลของการกระทำของตนได้ทันที เมื่อใดที่มีการ commit การเปลี่ยนแปลงเข้าสู่ version control การทดสอบอัตโนมัติแบบเร็วจะถูกเรียกใช้ในสภาพแวดล้อมที่เหมือน production ทำให้มั่นใจได้อย่างต่อเนื่องว่าโค้ดและสภาพแวดล้อมทำงานตามที่ออกแบบ และอยู่ในสถานะที่ปลอดภัยและพร้อม deploy อยู่เสมอ

การทดสอบอัตโนมัติช่วยให้นักพัฒนาค้นพบข้อผิดพลาดของตนเองได้อย่างรวดเร็ว (โดยปกติภายในไม่กี่นาที) ซึ่งช่วยให้แก้ไขได้เร็วขึ้นรวมถึงการเรียนรู้อย่างแท้จริง—การเรียนรู้ที่เป็นไปไม่ได้เมื่อพบข้อผิดพลาดหกเดือนต่อไประหว่างการทดสอบ integration เมื่อความทรงจำและความเชื่อมโยงระหว่างสาเหตุและผลกระทบเลือนหายไปนานแล้ว แทนที่จะสะสม technical debt ปัญหาจะถูกแก้ไขเมื่อพบ ระดมทั้งองค์กรหากจำเป็นเพราะเป้าหมายระดับโลกสำคัญกว่าเป้าหมายท้องถิ่น

telemetry ที่ครอบคลุมในโค้ดและสภาพแวดล้อม production ของเราช่วยให้มั่นใจว่าปัญหาจะถูกตรวจจับและแก้ไขอย่างรวดเร็ว ยืนยันว่าทุกอย่างทำงานตามที่ intended และลูกค้าได้รับคุณค่าจากซอฟต์แวร์ที่เราสร้าง

ในสถานการณ์นี้ ทุกคนรู้สึกมีประสิทธิภาพ—สถาปัตยกรรมช่วยให้ทีมเล็กๆ ทำงานได้อย่างปลอดภัยและแยกออกจากงานของทีมอื่นๆ ในเชิงสถาปัตยกรรม ซึ่งทีมอื่นใช้แพลตฟอร์ม self-service ที่ leverage ประสบการณ์ร่วมของ Operations และ Information Security แทนที่จะให้ทุกคนรอคอยตลอดเวลา กับงานที่ต้องทำซ้ำจำนวนมากที่สายและเร่งด่วน ทีมทำงานอย่างอิสระและมีประสิทธิภาพใน batches เล็กๆ ส่งมอบคุณค่าใหม่ให้ลูกค้าอย่างรวดเร็วและสม่ำเสมอ

แม้แต่การเปิดตัวผลิตภัณฑ์และฟีเจอร์ที่มีชื่อเสียงก็กลายเป็นเรื่องปกติด้วยการใช้เทคนิค dark launch นานก่อนวันเปิดตัว เราใส่โค้ดที่จำเป็นทั้งหมดสำหรับฟีเจอร์นั้นไว้ใน production ซึ่งมองไม่เห็นสำหรับทุกคนยกเว้นพนักงานภายในและกลุ่มผู้ใช้จริงขนาดเล็ก ทำให้เราสามารถทดสอบและพัฒนาฟีเจอร์จนกว่าจะบรรลุเป้าหมายทางธุรกิจที่ต้องการ

และแทนที่จะแก้ปัญหาเฉพาะหน้าเป็นเวลาหลายวันหรือหลายสัปดาห์เพื่อทำให้ฟังก์ชันการทำงานใหม่ใช้งานได้ เราเพียงแค่เปลี่ยน feature toggle หรือการตั้งค่า configuration การเปลี่ยนแปลงเล็กๆ นี้ทำให้ฟีเจอร์ใหม่ปรากฏแก่กลุ่มลูกค้าที่ใหญ่ขึ้นเรื่อยๆ โดยอัตโนมัติ rollback หากมีอะไรผิดพลาด ผลลัพธ์ก็คือการเปิดตัวของเราควบคุมได้ คาดเดาได้ ย้อนกลับได้ และมีความเครียดต่ำ

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

ยิ่งไปกว่านั้น ทุกคนเรียนรู้อย่างต่อเนื่อง ส่งเสริมวัฒนธรรมที่ขับเคลื่อนด้วยสมมติฐาน (hypothesis-driven culture) ที่ใช้วิธีการทางวิทยาศาสตร์เพื่อให้แน่ใจว่าไม่มีอะไรถูกมองข้าม—เราจะไม่ทำอะไรเลยหากไม่มีการวัดผลและถือว่าการพัฒนาผลิตภัณฑ์และการปรับปรุงกระบวนการเป็นการทดลอง

เพราะเราให้คุณค่ากับเวลาของทุกคน เราจึงไม่ใช้เวลาหลายปีสร้างฟีเจอร์ที่ลูกค้าไม่ต้องการ deploy โค้ดที่ใช้งานไม่ได้ หรือแก้ไขสิ่งที่ไม่ได้เป็นสาเหตุของปัญหาจริงๆ

เพราะเราใส่ใจในการบรรลุเป้าหมาย เราจึงสร้างทีมระยะยาวที่รับผิดชอบในการบรรลุเป้าหมายเหล่านั้น แทนที่จะเป็นทีมโปรเจกต์ที่นักพัฒนาถูกย้ายและสับเปลี่ยนหลังจากการเปิดตัวแต่ละครั้ง โดยไม่ได้รับ feedback เกี่ยวกับงานของพวกเขาเลย เรารักษาทีมให้อยู่ด้วยกันเพื่อที่พวกเขาจะได้วนซ้ำและปรับปรุงอย่างต่อเนื่อง ใช้การเรียนรู้เหล่านั้นเพื่อบรรลุเป้าหมายได้ดียิ่งขึ้น สิ่งนี้เป็นจริงทั้งสำหรับทีมผลิตภัณฑ์ที่แก้ปัญหาให้ลูกค้าภายนอกของเรา และทีมแพลตฟอร์มภายในที่ช่วยให้ทีมอื่นทำงานได้มีประสิทธิภาพ ปลอดภัย และมั่นคงยิ่งขึ้น

แทนที่จะเป็นวัฒนธรรมแห่งความกลัว เรามีวัฒนธรรมที่มีความไว้วางใจสูงและการทำงานร่วมกัน ที่ผู้คนได้รับรางวัลจากการกล้าเสี่ยง พวกเขาสามารถพูดถึงปัญหาได้อย่างไม่เกรงกลัว แทนที่จะซ่อนมันหรือเก็บไว้ทีหลัง—เพราะท้ายที่สุดแล้ว เราต้องเห็นปัญหาเพื่อที่จะแก้ไขมัน

และเนื่องจากทุกคนเป็นเจ้าของคุณภาพของงานตนเองอย่างเต็มที่ ทุกคนจึงสร้าง automated testing ในการทำงานประจำวันและใช้ peer reviews เพื่อเพิ่มความมั่นใจว่าปัญหาจะถูกจัดการก่อนที่จะส่งผลกระทบต่อลูกค้า กระบวนการเหล่านี้ช่วยลดความเสี่ยง แทนที่จะต้องรอการอนุมัติจากผู้มีอำนาจที่ห่างไกล ทำให้เราสามารถส่งมอบคุณค่าได้อย่างรวดเร็ว เชื่อถือได้ และปลอดภัย—แม้กระทั่งพิสูจน์ให้ผู้ตรวจสอบที่ขี้สงสัยเห็นว่าเรามีระบบการควบคุมภายในที่มีประสิทธิภาพ

เมื่อมีอะไรผิดพลาด เราจะดำเนินการ blameless post-mortems ไม่ใช่เพื่อลงโทษใคร แต่เพื่อทำความเข้าใจให้ดีขึ้นว่าอะไรทำให้เกิดอุบัติเหตุและจะป้องกันอย่างไร พิธีกรรมนี้ช่วยเสริมสร้างวัฒนธรรมการเรียนรู้ของเรา เรายังจัดประชุมเทคโนโลยีภายในองค์กรเพื่อยกระดับทักษะของเราและให้แน่ใจว่าทุกคนได้สอนและเรียนรู้อยู่เสมอ

เพราะเราใส่ใจในคุณภาพ เรายัง inject ข้อบกพร่องเข้าไปในสภาพแวดล้อม production ของเราเพื่อเรียนรู้ว่าระบบของเราล้มเหลวอย่างไรในลักษณะที่มีการวางแผน เราจัดการฝึกซ้อมตามแผนเพื่อรับมือกับความล้มเหลวขนาดใหญ่ ฆ่า process และ compute server ใน production แบบสุ่ม และ inject network latencies รวมถึงการกระทำร้ายอื่นๆ เพื่อให้แน่ใจว่าเราเติบโตแข็งแกร่งยิ่งขึ้น การทำเช่นนี้ช่วยให้เรามี resilience ที่ดีขึ้น รวมถึงการเรียนรู้และการปรับปรุงขององค์กร

ในโลกนี้ ทุกคนมีความเป็นเจ้าของในงานของตน ไม่ว่าบทบาทในองค์กรเทคโนโลยีจะเป็นอย่างไร พวกเขามั่นใจว่างานของพวกเขามีความสำคัญและมีส่วนช่วยให้บรรลุเป้าหมายขององค์กรอย่างมีความหมาย โดยพิสูจน์ได้จากสภาพแวดล้อมการทำงานที่เครียดต่ำและความสำเร็จขององค์กรในตลาด หลักฐานของพวกเขาคือองค์กรชนะในตลาดจริง

The Business Value of DevOps (คุณค่าทางธุรกิจของ DevOps)

เรามีหลักฐานที่ชัดเจนเกี่ยวกับคุณค่าทางธุรกิจของ DevOps ตั้งแต่ปี 2013 ถึง 2016 ซึ่งเป็นส่วนหนึ่งของ State Of DevOps Report ของ Puppet Labs ซึ่งผู้เขียน Nicole Forsgren, Jez Humble และ Gene Kim มีส่วนร่วม เราเก็บข้อมูลจากผู้เชี่ยวชาญด้านเทคโนโลยีกว่าสองหมื่นห้าพันคน โดยมีเป้าหมายเพื่อทำความเข้าใจสุขภาพและนิสัยขององค์กรในทุกขั้นตอนของการนำ DevOps ไปใช้ **

ความประหลาดใจแรกที่ข้อมูลนี้เปิดเผยคือองค์กรที่ทำงานมีประสิทธิภาพสูงซึ่งใช้แนวปฏิบัติ DevOps มีผลงานเหนือกว่าองค์กรที่ไม่ใช่ระดับสูงในด้านต่อไปนี้มากเพียงใด: 11

• เมตริกด้าน Throughput

∘ การ deploy โค้ดและการเปลี่ยนแปลง (บ่อยกว่าสามสิบเท่า)

∘ ระยะเวลา lead time ของการ deploy โค้ดและการเปลี่ยนแปลง (เร็วกว่าสองร้อยเท่า)

• เมตริกด้านความน่าเชื่อถือ

∘ การ deploy สู่ production (มีอัตราความสำเร็จในการเปลี่ยนแปลงสูงกว่าหกสิบเท่า)

∘ เวลาเฉลี่ยในการกู้คืนบริการ (เร็วขึ้น 168 เท่า)

เมตริกด้านประสิทธิภาพขององค์กร

∘ เป้าหมายด้าน productivity ส่วนแบ่งตลาด และความสามารถในการทำกำไร (มีแนวโน้มที่จะเกินเป้าหมายมากกว่าสองเท่า)

∘ การเติบโตของมูลค่าตลาด (สูงกว่า 50% ในระยะเวลาสามปี)

กล่าวอีกนัยหนึ่ง องค์กรที่มีประสิทธิภาพสูงนั้นทั้งคล่องตัวกว่าและเชื่อถือได้มากกว่า ซึ่งเป็นหลักฐานเชิงประจักษ์ว่า DevOps ช่วยให้เราทลายความขัดแย้งหลักที่เรื้อรังได้ องค์กรประสิทธิภาพสูง deploy โค้ดบ่อยกว่าสามสิบเท่า และเวลาที่ใช้ตั้งแต่ "โค้ดถูก commit" ไปจนถึง "รันใน production ได้สำเร็จ" นั้นเร็วกว่าสองร้อยเท่า—องค์กรประสิทธิภาพสูงมี lead time วัดเป็นนาทีหรือชั่วโมง ในขณะที่องค์กรประสิทธิภาพต่ำมี lead time วัดเป็นสัปดาห์ เดือน หรือไตรมาส

ยิ่งไปกว่านั้น องค์กรประสิทธิภาพสูงมีแนวโน้มที่จะเกินเป้าหมายด้านความสามารถในการทำกำไร ส่วนแบ่งตลาด และ productivity มากเป็นสองเท่า และสำหรับองค์กรที่ให้สัญลักษณ์หุ้น เราพบว่าองค์กรประสิทธิภาพสูงมีการเติบโตของมูลค่าตลาดสูงกว่า 50% ในระยะเวลาสามปี พวกเขายังมีความพึงพอใจในงานของพนักงานที่สูงกว่า อัตราการหมดไฟ (burnout) ที่ต่ำกว่า และพนักงานมีแนวโน้มที่จะแนะนำองค์กรของตนให้เพื่อนเป็นที่ทำงานที่ดีมากกว่า 2.2 เท่า †† องค์กรประสิทธิภาพสูงยังมีผลลัพธ์ด้านความปลอดภัยของข้อมูลที่ดีกว่าด้วย โดยการบูรณาการวัตถุประสงค์ด้านความปลอดภัยในทุกขั้นตอนของกระบวนการพัฒนาและปฏิบัติการ พวกเขาใช้เวลาในการแก้ไขปัญหาด้านความปลอดภัยน้อยลง 50%

DevOps Helps Scale Developer Productivity (DevOps ช่วย Scale Productivity ของนักพัฒนา)

เมื่อเราเพิ่มจำนวนนักพัฒนา productivity ของนักพัฒนาแต่ละคนมักจะลดลงอย่างมากเนื่องจาก overhead ด้านการสื่อสาร การ integration และการทดสอบ

สิ่งนี้ถูกเน้นย้ำในหนังสือชื่อดังของ Frederick Brook The Mythical Man-Month ที่อธิบายว่าเมื่อโปรเจกต์ล่าช้า การเพิ่มนักพัฒนาเพิ่มขึ้นไม่เพียงลด productivity ของนักพัฒนาแต่ละคนเท่านั้น แต่ยังลด productivity โดยรวมอีกด้วย 13

ในทางกลับกัน DevOps แสดงให้เราเห็นว่าเมื่อเรามีสถาปัตยกรรมที่ถูกต้อง แนวปฏิบัติทางเทคนิคที่ถูกต้อง และบรรทัดฐานทางวัฒนธรรมที่ถูกต้อง ทีมนักพัฒนาขนาดเล็กก็สามารถพัฒนา integrat ทดสอบ และ deploy การเปลี่ยนแปลงสู่ production ได้อย่างรวดเร็ว ปลอดภัย และเป็นอิสระ

ดังที่ Randy Shoup อดีตผู้อำนวยการฝ่ายวิศวกรรมที่ Google และปัจจุบันเป็น VP Engineering ที่ eBay กล่าวไว้ว่า องค์กรขนาดใหญ่ที่ใช้ DevOps "มีนักพัฒนาหลายพันคน แต่สถาปัตยกรรมและแนวปฏิบัติของพวกเขาช่วยให้ทีมเล็กๆ ยังคงมีประสิทธิภาพอย่างเหลือเชื่อ ราวกับว่าพวกเขาเป็น startup" 14

2015 State of DevOps Report ไม่เพียงแต่ตรวจสอบ "จำนวน deploys ต่อวัน" แต่ยังรวมถึง "จำนวน deploys ต่อวันต่อนักพัฒนา" ด้วย พวกเขาตั้งสมมติฐานว่าองค์กรประสิทธิภาพสูงจะสามารถ scale จำนวนการ deploy ได้เมื่อทีมมีขนาดใหญ่ขึ้น 15

และนั่นคือสิ่งที่พวกเขาพบ รูป 0.1 แสดงให้เห็นว่าในองค์กรประสิทธิภาพต่ำ จำนวน deploys ต่อวันต่อนักพัฒนาลดลงเมื่อทีมใหญ่ขึ้น คงที่สำหรับองค์กรประสิทธิภาพปานกลาง และเพิ่มขึ้นเป็นเส้นตรงสำหรับองค์กรประสิทธิภาพสูง กล่าวอีกนัยหนึ่ง องค์กรที่นำ DevOps มาใช้สามารถเพิ่มจำนวน deploys ต่อวันได้เป็นเส้นตรงเมื่อเพิ่มจำนวนนักพัฒนา เช่นเดียวกับที่ Google, Amazon และ Netflix ได้ทำ ‡‡

รูป 0.1: จำนวน Deployments ต่อวัน เทียบกับ จำนวนนักพัฒนา

เฉพาะองค์กรที่ deploy อย่างน้อยวันละครั้งเท่านั้นที่แสดงในรูป
ที่มา: Puppet Labs, 2015 State Of DevOps Report .

The Universality of the Solution (ความเป็นสากลของแนวทางแก้ไข)

หนังสือที่มีอิทธิพลมากที่สุดเล่มหนึ่งในขบวนการ Lean manufacturing คือ The Goal: A Process of Ongoing Improvement ซึ่งเขียนโดย Dr. Eliyahu M. Goldratt ในปี 1984 หนังสือเล่มนี้มีอิทธิพลต่อผู้จัดการโรงงานมืออาชีพทั้งรุ่นทั่วโลก มันเป็นนิยายเกี่ยวกับผู้จัดการโรงงานที่ต้องแก้ปัญหาด้านต้นทุนและกำหนดส่งสินค้าภายในเก้าสิบวัน มิฉะนั้นโรงงานของเขาจะถูกปิด

ต่อมาในอาชีพการงานของเขา Dr. Goldratt อธิบายถึงจดหมายที่เขาได้รับตอบกลับ The Goal โดยจดหมายเหล่านี้มักจะอ่านว่า "คุณแอบซ่อนอยู่ในโรงงานของเราแน่ๆ เพราะคุณบรรยายชีวิตของผม [ในฐานะผู้จัดการโรงงาน] ได้ตรงเป๊ะ ..." 17 ที่สำคัญที่สุด จดหมายเหล่านี้แสดงให้เห็นว่าผู้คนสามารถทำซ้ำความก้าวหน้าด้านประสิทธิภาพที่อธิบายไว้ในหนังสือในสภาพแวดล้อมการทำงานของตนเองได้

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win ซึ่งเขียนโดย Gene Kim, Kevin Behr และ George Spafford ในปี 2013 มีรูปแบบที่ใกล้เคียงกับ The Goal อย่างมาก มันเป็นนิยายที่ติดตามผู้นำ IT ที่เผชิญกับปัญหาทั่วไปทั้งหมดที่พบในองค์กร IT: โปรเจกต์ที่เกินงบประมาณ ล่าช้า ซึ่งต้องออกสู่ตลาดเพื่อให้บริษัทอยู่รอด เขาประสบกับการ deploy ที่หายนะ ปัญหาด้านความพร้อมใช้งาน ความปลอดภัย และการปฏิบัติตามข้อกําหนด และอื่นๆ

ท้ายที่สุด เขาและทีมใช้หลักการและแนวปฏิบัติของ DevOps เพื่อเอาชนะความท้าทายเหล่านั้น ช่วยให้องค์กรของตนชนะในตลาด นอกจากนี้ นิยายยังแสดงให้เห็นว่าแนวปฏิบัติของ DevOps ปรับปรุงสภาพแวดล้อมในที่ทํางานของทีมอย่างไร สร้างความเครียดที่ลดลงและความพึงพอใจที่สูงขึ้นจากการมีส่วนร่วมของผู้ปฏิบัติงานมากขึ้นตลอดทั้งกระบวนการ

เช่นเดียวกับ The Goal มีหลักฐานมากมายเกี่ยวกับความเป็นสากลของปัญหาและแนวทางแก้ไขที่อธิบายไว้ใน The Phoenix Project ลองพิจารณาข้อความบางส่วนจากรีวิวบน Amazon: "ฉันพบว่าตัวเองเกี่ยวข้องกับตัวละครใน The Phoenix Project ... ฉันคงเคยเจอพวกเขาส่วนใหญ่ตลอดอาชีพการทํางานของฉัน" "ถ้าคุณเคยทำงานในด้านใดๆ ของ IT, DevOps หรือ Infosec คุณจะสามารถเกี่ยวข้องกับหนังสือเล่มนี้ได้อย่างแน่นอน" หรือ "ไม่มีตัวละครใน The Phoenix Project เลยที่ฉันไม่สามารถระบุตัวตนด้วยตัวเองหรือคนที่ฉันรู้จักในชีวิตจริง ... ไม่ต้องพูดถึงปัญหาที่ตัวละครเหล่านั้นเผชิญและเอาชนะ" 18

The DevOps Handbook: An Essential Guide (คู่มือสำคัญ)

ในส่วนที่เหลือของหนังสือเล่มนี้ เราจะอธิบายวิธีทำซ้ำการเปลี่ยนแปลงที่อธิบายไว้ใน The Phoenix Project รวมถึงให้กรณีศึกษามากมายว่าองค์กรอื่นๆ ใช้หลักการและแนวปฏิบัติของ DevOps เพื่อทำซ้ำผลลัพธ์เหล่านั้นอย่างไร

จุดประสงค์ของ The DevOps Handbook คือการให้ทฤษฎี หลักการ และแนวปฏิบัติที่คุณจำเป็นต้องใช้เพื่อเริ่มต้น initiative ด้าน DevOps และบรรลุผลลัพธ์ที่ต้องการได้สำเร็จ คำแนะนำนี้มีพื้นฐานมาจากทฤษฎีการจัดการที่แข็งแกร่งหลายทศวรรษ การศึกษาองค์กรเทคโนโลยีที่ทำงานมีประสิทธิภาพสูง งานที่เราทำในการช่วยเหลือองค์กรในการเปลี่ยนแปลง และงานวิจัยที่ยืนยันประสิทธิภาพของแนวปฏิบัติ DevOps ที่กำหนด รวมถึงการสัมภาษณ์ผู้เชี่ยวชาญเฉพาะด้านและการวิเคราะห์กรณีศึกษาเกือบหนึ่งร้อยกรณีที่นำเสนอใน DevOps Enterprise Summit

หนังสือเล่มนี้แบ่งออกเป็นหกส่วน ครอบคลุมทฤษฎีและหลักการของ DevOps โดยใช้ Three Ways ซึ่งเป็นมุมมองเฉพาะเกี่ยวกับทฤษฎีพื้นฐานที่เดิมนำเสนอใน The Phoenix Project . The DevOps Handbook มีไว้สำหรับทุกคนที่ปฏิบัติงานหรือมีอิทธิพลต่องานใน technology value stream (ซึ่งโดยทั่วไปรวมถึง Product Management, Development, QA, IT Operations และ Information Security) รวมถึงผู้นำทางธุรกิจและการตลาด ซึ่งเป็นที่มาของ initiative ด้านเทคโนโลยีส่วนใหญ่

ผู้อ่านไม่จำเป็นต้องมีความรู้กว้างขวางในโดเมนเหล่านี้ หรือเกี่ยวกับ DevOps, Agile, ITIL, Lean หรือการปรับปรุงกระบวนการ หัวข้อเหล่านี้จะถูกนำเสนอและอธิบายในหนังสือเมื่อจำเป็น

ความตั้งใจของเราคือการสร้างความรู้ในการทำงานเกี่ยวกับแนวคิดสำคัญในแต่ละโดเมนเหล่านี้ เพื่อเป็น primer และแนะนำภาษาที่จำเป็นในการช่วยให้ผู้ปฏิบัติงานทำงานร่วมกับเพื่อนร่วมงานทุกคนทั่วทั้ง IT value stream และกำหนดกรอบเป้าหมายร่วมกัน

หนังสือเล่มนี้จะมีคุณค่าสำหรับผู้นำธุรกิจและผู้มีส่วนได้ส่วนเสียที่ต้องพึ่งพาองค์กรเทคโนโลยีมากขึ้นเพื่อบรรลุเป้าหมายของตน

ยิ่งไปกว่านั้น หนังสือเล่มนี้มีไว้สำหรับผู้อ่านที่องค์กรอาจไม่ได้ประสบปัญหาทั้งหมดที่อธิบายไว้ในหนังสือ (เช่น lead time การ deploy ที่ยาวนานหรือการ deploy ที่เจ็บปวด) แม้แต่ผู้อ่านที่อยู่ในตำแหน่งที่โชคดีนี้ก็จะได้รับประโยชน์จากการทำความเข้าใจหลักการของ DevOps โดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับเป้าหมายร่วมกัน feedback และการเรียนรู้อย่างต่อเนื่อง

ใน Part I เรานำเสนอประวัติโดยย่อของ DevOps และแนะนำทฤษฎีพื้นฐานและประเด็นสำคัญจากองค์ความรู้ที่เกี่ยวข้องที่ครอบคลุมหลายทศวรรษ จากนั้นเรานำเสนอหลักการระดับสูงของ Three Ways: Flow, Feedback และ Continual Learning and Experimentation

Part II อธิบายวิธีการและจุดเริ่มต้น และนำเสนอแนวคิดเช่น value streams, หลักการและรูปแบบการออกแบบองค์กร รูปแบบการนำไปใช้ในองค์กร และกรณีศึกษา

Part III อธิบายวิธีเร่ง flow โดยการสร้างรากฐานของ deployment pipeline ของเรา: ทำให้การทดสอบอัตโนมัติที่รวดเร็วและมีประสิทธิภาพ continuous integration, continuous delivery และการออกแบบสถาปัตยกรรมสำหรับการปล่อยที่มีความเสี่ยงต่ำเป็นไปได้

Part IV อภิปรายวิธีเร่งและขยาย feedback โดยการสร้าง production telemetry ที่มีประสิทธิภาพเพื่อเห็นและแก้ไขปัญหา คาดการณ์ปัญหาได้ดีขึ้นและบรรลุเป้าหมาย เปิดใช้งาน feedback เพื่อให้ Development และ Operations สามารถ deploy การเปลี่ยนแปลงได้อย่างปลอดภัย บูรณาการ A/B testing ในการทำงานประจำวัน และสร้างกระบวนการตรวจสอบและประสานงานเพื่อเพิ่มคุณภาพของงาน

Part V อธิบายวิธีเร่งการเรียนรู้อย่างต่อเนื่องและการทดลองโดยการสร้าง just culture แปลงการค้นพบในท้องถิ่นให้เป็นการปรับปรุงระดับโลก และจัดสรรเวลาอย่างเหมาะสมเพื่อสร้างการเรียนรู้และการปรับปรุงขององค์กร

สุดท้ายใน Part VI เราอธิบายวิธีบูรณาการความปลอดภัยและการปฏิบัติตามข้อกำหนดในการทำงานประจำวันอย่างถูกต้อง โดยการรวมการควบคุมความปลอดภัยเชิงป้องกันเข้าไปใน repositories และ services โค้ดที่ใช้ร่วมกัน บูรณาการความปลอดภัยเข้าไปใน deployment pipeline ของเรา เพิ่ม telemetry เพื่อให้สามารถตรวจจับและกู้คืนได้ดีขึ้น ป้องกัน deployment pipeline และบรรลุวัตถุประสงค์การจัดการการเปลี่ยนแปลง

โดยการกำหนดแนวปฏิบัติเหล่านี้เป็นลายลักษณ์อักษร เราหวังว่าจะเร่งการนำแนวปฏิบัติ DevOps มาใช้ เพิ่มความสำเร็จของ initiative DevOps และลดพลังงานกระตุ้น (activation energy) ที่จำเป็นสำหรับการเปลี่ยนแปลงสู่ DevOps