1
AGILE, CONTINUOUS DELIVERY, AND THE THREE WAYS (การทำงานแบบ Agile, การส่งมอบอย่างต่อเนื่อง และ Three Ways)
I ในบทนี้ เราจะนำเสนอความรู้เบื้องต้นเกี่ยวกับทฤษฎีพื้นฐานของ Lean Manufacturing รวมถึงหลักการ Three Ways ซึ่งเป็นหลักการที่สามารถใช้อธิบายพฤติกรรมต่างๆ ของ DevOps ที่เราได้สังเกตเห็น
เนื้อหาในบทนี้จะเน้นไปที่ทฤษฎีและหลักการเป็นหลัก โดยจะอธิบายบทเรียนหลายทศวรรษที่สะสมมาจากกระบวนการผลิต (manufacturing) องค์กรที่มีความน่าเชื่อถือสูง (high-reliability organizations) โมเดลการจัดการที่建立在ความไว้วางใจสูง (high-trust management models) และอื่นๆ ซึ่งเป็นที่มาของแนวปฏิบัติ DevOps หลักการและรูปแบบที่เป็นรูปธรรม รวมถึงการประยุกต์ใช้ในทางปฏิบัติกับ value stream ด้านเทคโนโลยี จะถูกนำเสนอในบทต่อๆ ไปของหนังสือเล่มนี้
The Manufacturing Value Stream (Value Stream ด้านการผลิต)
หนึ่งในแนวคิดพื้นฐานของ Lean คือ value stream เราจะนิยามมันในบริบทของการผลิตก่อน จากนั้นจึงขยายไปสู่การประยุกต์ใช้กับ DevOps และ value stream ด้านเทคโนโลยี
Karen Martin และ Mike Osterling ได้นิยาม value stream ไว้ในหนังสือ Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation ว่า "ลำดับของกิจกรรมที่องค์กรดำเนินการเพื่อตอบสนองต่อคำขอของลูกค้า" หรือ "ลำดับของกิจกรรมที่จำเป็นในการออกแบบ ผลิต และส่งมอบสินค้าหรือบริการให้แก่ลูกค้า รวมถึงการไหลของข้อมูลและวัสดุในสองทิศทาง" 1
ในกระบวนการผลิต (manufacturing operations) value stream มักจะมองเห็นและสังเกตได้ง่าย: มันเริ่มต้นเมื่อได้รับคำสั่งซื้อจากลูกค้าและวัตถุดิบถูกปล่อยเข้าสู่พื้นที่การผลิต เพื่อให้สามารถส่งมอบได้รวดเร็วและคาดการณ์ได้ในทุก value stream มักจะมีการให้ความสำคัญอย่างไม่ลดละกับการสร้างการไหลของงานที่ราบรื่นและสม่ำเสมอ โดยใช้เทคนิคต่างๆ เช่น ขนาดแบตช์ที่เล็ก (small batch sizes) การลดงานระหว่างทำ (work in process หรือ WIP) การป้องกันงานซ้ำ (rework) เพื่อไม่ให้ข้อบกพร่องถูกส่งต่อไปยังหน่วยงาน downstream และการปรับปรุงระบบอย่างต่อเนื่องเพื่อให้บรรลุเป้าหมายในภาพรวม
The Technology Value Stream (Value Stream ด้านเทคโนโลยี)
หลักการและรูปแบบต่างๆ มากมายที่ช่วยให้งานไหลได้รวดเร็วในกระบวนการผลิตทางกายภาพนั้น ก็สามารถนำมาประยุกต์ใช้กับงานด้านเทคโนโลยีได้เช่นเดียวกัน (และยังรวมถึงงานทุกประเภทที่ใช้ความรู้เป็นหลัก) ใน DevOps เรามักจะนิยาม value stream ด้านเทคโนโลยีของเราว่าเป็นกระบวนการที่จำเป็นในการเปลี่ยนสมมติฐานทางธุรกิจ (business hypothesis) ให้เป็นบริการหรือฟีเจอร์ที่ขับเคลื่อนด้วยเทคโนโลยี ซึ่งส่งมอบคุณค่าให้แก่ลูกค้า
input ของกระบวนการของเราคือ การกำหนดวัตถุประสงค์ทางธุรกิจ แนวคิด ไอเดีย หรือสมมติฐาน และมันจะเริ่มต้นเมื่อเรารับงานในฝ่าย Development โดยเพิ่มมันเข้าไปใน backlog ของงานที่我们รับผิดชอบ
จากนั้น ทีม Development ที่ทำตามกระบวนการ Agile หรือ iterative โดยทั่วไปจะเปลี่ยนแนวคิดดังกล่าวเป็น user stories และข้อกำหนดฟีเจอร์บางรูปแบบ ซึ่งจากนั้นจะถูก implement เป็นโค้ดในแอปพลิเคชันหรือบริการที่กำลังถูกสร้าง โค้ดจะถูกเช็คเข้าไปยัง version control repository โดยการเปลี่ยนแปลงแต่ละครั้งจะถูก integrate และทดสอบร่วมกับส่วนอื่นๆ ของระบบซอฟต์แวร์
เนื่องจากคุณค่าจะเกิดขึ้นก็ต่อเมื่อบริการของเราทำงานใน production เราจึงต้องมั่นใจว่าเราไม่เพียงแค่ส่งมอบการไหลที่รวดเร็ว แต่การ deploy ของเราจะต้องสามารถทำได้โดยไม่ก่อให้เกิดความโกลาหลและการหยุดชะงัก เช่น การหยุดทำงานของบริการ (service outages) ความบกพร่องของบริการ (service impairments) หรือความล้มเหลวด้านความปลอดภัยหรือการปฏิบัติตามข้อกำหนด (security หรือ compliance failures)
Focus on Deployment Lead Time (การมุ่งเน้นที่ Deployment Lead Time)
สำหรับส่วนที่เหลือของหนังสือเล่มนี้ เราจะให้ความสนใจกับ deployment lead time ซึ่งเป็นส่วนย่อยของ value stream ที่อธิบายไว้ข้างต้น value stream นี้เริ่มต้นเมื่อวิศวกร * คนใดก็ตามใน value stream ของเรา (ซึ่งรวมถึง Development, QA, IT Operations และ Infosec) เช็คการเปลี่ยนแปลงเข้าไปยัง version control และสิ้นสุดเมื่อการเปลี่ยนแปลงนั้นทำงานใน production ได้สำเร็จ ส่งมอบคุณค่าให้แก่ลูกค้า และสร้าง feedback และ telemetry ที่เป็นประโยชน์
ขั้นตอนแรกของงานซึ่งรวมถึงการออกแบบและพัฒนา เปรียบเสมือน Lean Product Development ซึ่งมีความแปรปรวนสูงและมีความไม่แน่นอนสูง มักต้องใช้ความคิดสร้างสรรค์ในระดับสูง และอาจเป็นงานที่ไม่ต้องทำซ้ำอีก ด้วยเหตุนี้ เราจึงคาดหวังความแปรปรวนสูงของระยะเวลาในกระบวนการ (process times) ในทางตรงกันข้าม ขั้นตอนที่สองของงานซึ่งรวมถึงการทดสอบ การ deploy และการดำเนินงาน (operations) เปรียบเสมือน Lean Manufacturing ซึ่งมุ่งหวังให้คาดการณ์ได้และเป็นกลไก (predictable and mechanistic) โดยมีเป้าหมายเพื่อให้ได้ผลลัพธ์ของงานที่มีความแปรปรวนน้อยที่สุด (เช่น ระยะเวลาการส่งมอบที่สั้นและคาดการณ์ได้ ข้อบกพร่องเกือบเป็นศูนย์)
แทนที่จะใช้แบตช์งานขนาดใหญ่ที่ถูกประมวลผลตามลำดับผ่าน value stream การออกแบบ/พัฒนา แล้วจึงผ่าน value stream การทดสอบ/ปฏิบัติการ (เช่นเมื่อเรามีกระบวนการ waterfall แบบแบตช์ใหญ่ หรือ feature branches ที่มีอายุยืนยาว) เป้าหมายของเราคือการให้การทดสอบ การ deploy และการดำเนินงานเกิดขึ้นพร้อมกันกับการออกแบบ/พัฒนา ทำให้เกิดการไหลที่รวดเร็วและคุณภาพสูง วิธีการนี้จะประสบความสำเร็จเมื่อเราทำงานในแบตช์ขนาดเล็กและสร้างคุณภาพในทุกส่วนของ value stream †
Defining Lead Time vs. Processing Time (การนิยาม Lead Time เทียบกับ Processing Time)
ในชุมชน Lean นั้น lead time เป็นหนึ่งในสองตัววัดที่ใช้กันทั่วไปในการวัดประสิทธิภาพของ value streams โดยอีกตัวคือ processing time (บางครั้งเรียกว่า touch time หรือ task time) ‡
ในขณะที่นาฬิกาของ lead time เริ่มเดินเมื่อมีการร้องขอและหยุดเมื่อได้รับการตอบสนอง นาฬิกาของ process time จะเริ่มเดินเมื่อเราเริ่มทำงานกับคำขอนั้น โดยเฉพาะอย่างยิ่ง มันไม่รวมเวลาที่งานรออยู่ในคิว (queue) เพื่อรอการประมวลผล ( รูปที่ 1.1 )
รูปที่ 1.1: Lead Time เทียบกับ Process Time ของการดำเนินการ Deployment
เนื่องจาก lead time คือสิ่งที่ลูกค้าได้รับ เราจึงมักจะมุ่งเน้นการปรับปรุงกระบวนการไปที่ lead time มากกว่า process time อย่างไรก็ตาม สัดส่วนของ process time ต่อ lead time เป็นตัววัดประสิทธิภาพที่สำคัญ การบรรลุการไหลที่รวดเร็วและ lead time ที่สั้นนั้น เกือบจะต้องอาศัยการลดเวลาที่งานของเรารออยู่ในคิวเสมอ
The Common Scenario: Deployment Lead Times Requiring Months (สถานการณ์ทั่วไป: Deployment Lead Times ที่ต้องใช้เวลาเป็นเดือน)
ทีมและองค์กรจำนวนมากพบว่าตัวเองอยู่ในสถานการณ์ที่ deployment lead times ต้องใช้เวลาเป็นเดือน ซึ่งพบได้บ่อยโดยเฉพาะในองค์กรขนาดใหญ่และซับซ้อนที่ทำงานกับระบบ monolithic ที่ coupled กันอย่างแน่นหนา มักจะมีสภาพแวดล้อมการทดสอบ integration ที่ scarce, ระยะเวลารอคอยสภาพแวดล้อมการทดสอบและ production ที่ยาวนาน, การพึ่งพาการทดสอบด้วยตนเองสูง, และกระบวนการอนุมัติที่ต้องผ่านหลายขั้นตอน เมื่อเกิดเหตุการณ์เช่นนี้ value stream ของเราอาจมีลักษณะเหมือน รูปที่ 1.2 :
รูปที่ 1.2: Technology Value Stream ที่มี Deployment Lead Time สามเดือน
ที่มา: Damon Edwards, "DevOps Kaizen," 2015.
เมื่อเรามี deployment lead times ที่ยาวนาน จำเป็นต้องใช้ความพยายามอย่าง heroics ในเกือบทุกขั้นตอนของ value stream เราอาจพบว่าไม่มีอะไรทำงานได้เมื่อสิ้นสุดโปรเจกต์ เมื่อเรารวมการเปลี่ยนแปลงทั้งหมดจากทีม Development เข้าด้วยกัน ส่งผลให้โค้ดไม่สามารถ build ได้อย่างถูกต้องหรือผ่านการทดสอบใดๆ การแก้ไขปัญหาแต่ละอย่างต้องใช้เวลาหลายวันหรือหลายสัปดาห์ในการสืบสวนเพื่อหาว่าใครเป็นคนทำโค้ดเสียและจะแก้ไขอย่างไร และสุดท้ายก็ยังให้ผลลัพธ์ที่แย่ต่อลูกค้า
Our DevOps Ideal: Deployment Lead Times of Minutes (DevOps ในอุดมคติ: Deployment Lead Times ระดับนาที)
ในอุดมคติของ DevOps นักพัฒนาจะได้รับ feedback ที่รวดเร็วและสม่ำเสมอเกี่ยวกับงานของตน ทำให้พวกเขาสามารถ implement, integrate และตรวจสอบโค้ดของตนได้อย่างรวดเร็วและเป็นอิสระ และสามารถ deploy โค้ดเข้าสู่สภาพแวดล้อม production ได้ (ไม่ว่าจะ deploy ด้วยตนเองหรือให้ผู้อื่น deploy)
เราบรรลุสิ่งนี้ได้โดยการเช็คการเปลี่ยนแปลงโค้ดขนาดเล็กเข้าไปยัง version control repository อย่างต่อเนื่อง ทำการทดสอบอัตโนมัติ (automated testing) และ exploratory testing กับมัน และ deploy มันเข้าสู่ production ซึ่งช่วยให้เรามีความมั่นใจในระดับสูงว่าการเปลี่ยนแปลงของเราจะทำงานได้ตามที่ออกแบบไว้ใน production และปัญหาต่างๆ สามารถตรวจพบและแก้ไขได้อย่างรวดเร็ว
สิ่งนี้จะทำได้ง่ายที่สุดเมื่อเรามีสถาปัตยกรรมที่ modular, มีการ encapsulate ที่ดี, และ loosely coupled เพื่อให้ทีมขนาดเล็กสามารถทำงานได้อย่างอิสระในระดับสูง โดยความล้มเหลวมีขนาดเล็กและจำกัดวง และไม่ก่อให้เกิดการหยุดชะงักในวงกว้าง
ในสถานการณ์นี้ deployment lead time ของเราจะวัดเป็นนาที หรือในกรณีที่แย่ที่สุดคือเป็นชั่วโมง แผนที่ value stream ที่ได้ควรมีลักษณะเหมือน รูปที่ 1.3 .
รูปที่ 1.3: Technology Value Stream ที่มี Lead Time ระดับนาที
Observing "%C/A" as a Measure of Rework (การสังเกต "%C/A" ในฐานะตัววัดงานซ้ำ)
นอกจาก lead time และ process time แล้ว ตัววัดสำคัญที่สามใน technology value stream คือ percent complete and accurate (%C/A) ตัววัดนี้สะท้อนถึงคุณภาพของ output ในแต่ละขั้นตอนของ value stream
Karen Martin และ Mike Osterling กล่าวว่า "%C/A สามารถหาได้โดยการถาม downstream customers ว่าร้อยละเท่าใดของเวลาที่พวกเขาได้รับงานที่ 'ใช้งานได้ตามสภาพ (usable as is)' หมายความว่าพวกเขาสามารถทำงานได้โดยไม่ต้องแก้ไขข้อมูลที่ได้รับ เพิ่มข้อมูลที่ขาดหายไปซึ่งควรจะถูกส่งมาให้ หรือขอคำชี้แจงข้อมูลที่ควรจะชัดเจนอยู่แล้ว" 3
Continuous Learning (การเรียนรู้อย่างต่อเนื่อง)
Flow Metrics ในการวัดการส่งมอบคุณค่าทางธุรกิจ
เมื่อวัด value แบบ end-to-end ของ value stream ใดๆ สิ่งสำคัญคือต้องหลีกเลี่ยง proxy metrics (การนับจำนวนบรรทัดของโค้ดที่ commit หรือแค่ความถี่ในการ deploy เพียงอย่างเดียว) แม้ว่าตัววัดเหล่านี้อาจเผยให้เห็นการปรับปรุงเฉพาะจุด (local optimizations) แต่ก็ไม่ได้เชื่อมโยงโดยตรงกับผลลัพธ์ทางธุรกิจ เช่น รายได้
การใช้ flow metrics ช่วยให้เรามองเห็น value แบบ end-to-end ของการส่งมอบซอฟต์แวร์ ทำให้ผลิตภัณฑ์ซอฟต์แวร์และ value streams มองเห็นได้ชัดเจนเทียบเท่ากับชิ้นงานบนสายการผลิต ในหนังสือ Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework ของเขา Dr. Mik Kersten ได้อธิบาย flow metrics ไว้ดังนี้: flow velocity, flow efficiency, flow time, flow load และ flow distribution: 4
• Flow velocity : จำนวน flow items (เช่น work items) ที่เสร็จสมบูรณ์ในช่วงเวลาที่กำหนด ช่วยตอบคำถามว่าการส่งมอบคุณค่ากำลังเร่งขึ้นหรือไม่
• Flow efficiency : สัดส่วนของ flow items ที่ถูกทำงานจริง เทียบกับเวลาทั้งหมดที่ผ่านไป ช่วยระบุความไม่มีประสิทธิภาพ เช่น การรอคอยที่นาน และช่วยให้ทีมเห็นว่างาน upstream อยู่ในสถานะรอหรือไม่
• Flow time : หน่วยของคุณค่าทางธุรกิจที่ถูกดึงโดยผู้มีส่วนได้ส่วนเสียผ่าน value stream ของผลิตภัณฑ์ (เช่น ฟีเจอร์ ข้อบกพร่อง ความเสี่ยง และหนี้ทางเทคนิค) ช่วยให้ทีมเห็นว่าระยะเวลาในการส่งมอบคุณค่าสั้นลงหรือไม่
• Flow load : จำนวน flow items ที่กำลังทำงานหรือรออยู่ใน value stream ซึ่งคล้ายกับการวัดงานระหว่างทำ (WIP) ที่อิงตาม flow items flow load ที่สูงนำไปสู่ความไม่มีประสิทธิภาพ และลด flow velocity หรือเพิ่ม flow time ช่วยให้ทีมเห็นว่าความต้องการ (demand) มากกว่าขีดความสามารถ (capacity) หรือไม่
• Flow distribution : สัดส่วนของ flow item แต่ละประเภทใน value stream แต่ละ value stream สามารถติดตามและปรับเปลี่ยนสิ่งเหล่านี้ตามความจำเป็นเพื่อเพิ่มมูลค่าทางธุรกิจที่ส่งมอบให้สูงสุด
The Three Ways: The Principles Underpinning DevOps (Three Ways: หลักการที่อยู่เบื้องหลัง DevOps)
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win นำเสนอ Three Ways ในฐานะชุดของหลักการพื้นฐานที่ใช้อธิบายพฤติกรรมและรูปแบบต่างๆ ของ DevOps ที่เราได้สังเกตเห็น ( รูปที่ 1.4 )
รูปที่ 1.4: Three Ways
ที่มา: Gene Kim, "The Three Ways: The Principles Underpinning DevOps," ITRevolution.com (บล็อก), 22 สิงหาคม 2012, http://itrevolution.com/the-three-ways-principles-underpinning-devops/ .
First Way ช่วยให้เกิดการไหลของงานจากซ้ายไปขวาอย่างรวดเร็ว จาก Development ไปยัง Operations และไปสู่ลูกค้า เพื่อให้การไหลมีประสิทธิภาพสูงสุด เราจำเป็นต้องทำให้งานมองเห็นได้ ลดขนาดแบตช์และช่วงเวลาของงาน สร้างคุณภาพในกระบวนการโดยป้องกันไม่ให้ข้อบกพร่องถูกส่งต่อไปยัง downstream work centers และปรับปรุงอย่างต่อเนื่องเพื่อเป้าหมายในภาพรวม
ด้วยการเร่งการไหลผ่าน technology value stream เราจะลด lead time ที่จำเป็นในการตอบสนองคำร้องขอภายในหรือของลูกค้า โดยเฉพาะเวลาที่ต้องใช้ในการ deploy โค้ดเข้าสู่สภาพแวดล้อม production การทำเช่นนี้จะช่วยเพิ่มคุณภาพของงาน รวมถึง throughput และเพิ่มความสามารถในการสร้างนวัตกรรมและทำการทดลองได้เหนือกว่าคู่แข่ง
แนวปฏิบัติที่เกิดขึ้น ได้แก่ กระบวนการ continuous build, integration, test และ deployment การสร้างสภาพแวดล้อมตามต้องการ (on demand) การจำกัดงานระหว่างทำ (WIP) และการสร้างระบบและองค์กรที่ปลอดภัยต่อการเปลี่ยนแปลง (safe to change)
Second Way ช่วยให้เกิดการไหลของ feedback ที่รวดเร็วและสม่ำเสมอจากขวาไปซ้ายในทุกขั้นตอนของ value stream ของเรา โดยต้องขยาย feedback (amplify feedback) เพื่อป้องกันไม่ให้ปัญหาเกิดขึ้นซ้ำ หรือช่วยให้ตรวจพบและกู้คืนได้เร็วขึ้น การทำเช่นนี้จะช่วยสร้างคุณภาพที่ต้นทาง (quality at the source) และสร้างหรือฝังความรู้ไว้ในที่ที่จำเป็น ซึ่งช่วยให้เราสร้างระบบการทำงานที่ปลอดภัยยิ่งขึ้น โดยปัญหาจะถูกค้นพบและแก้ไขก่อนที่จะเกิดความล้มเหลวร้ายแรง
ด้วยการมองเห็นปัญหาเมื่อมันเกิดขึ้นและรวมพลังกันแก้ไขจนกว่าจะมีมาตรการรับมือที่มีประสิทธิภาพ เราจะทำให้ feedback loops สั้นลงและเข้มข้นขึ้นอย่างต่อเนื่อง ซึ่งเป็นหลักการสำคัญของแทบทุกวิธีการปรับปรุงกระบวนการสมัยใหม่ สิ่งนี้ช่วยเพิ่มโอกาสในการเรียนรู้และปรับปรุงขององค์กรของเราให้สูงสุด
Third Way ช่วยสร้างวัฒนธรรมแบบ generative ที่มีความไว้วางใจสูง ซึ่งสนับสนุนแนวทางการทดลองและการเสี่ยงที่ dynamic, มีระเบียบวินัย และเป็นวิทยาศาสตร์ อำนวยความสะดวกในการสร้างการเรียนรู้ขององค์กร ทั้งจากความสำเร็จและความล้มเหลวของเรา นอกจากนี้ การทำให้ feedback loops สั้นลงและเข้มข้นขึ้นอย่างต่อเนื่อง จะช่วยสร้างระบบการทำงานที่ปลอดภัยยิ่งขึ้น และทำให้เราสามารถเสี่ยงและทำการทดลองที่ช่วยให้เราเรียนรู้ได้เร็วกว่าคู่แข่งและชนะในตลาด
ในส่วนของ Third Way เรายังออกแบบระบบการทำงานของเราเพื่อให้สามารถทวีคูณผลกระทบของความรู้ใหม่ เปลี่ยนการค้นพบเฉพาะจุด (local discoveries) ให้เป็นการปรับปรุงในภาพรวม (global improvements) ไม่ว่าบุคคลจะทำงานที่ไหน ก็จะทำงานด้วยประสบการณ์สะสมและร่วมกันของทุกคนในองค์กรและตลอดประวัติศาสตร์ขององค์กร
Continuous Learning (การเรียนรู้อย่างต่อเนื่อง)
งานวิจัยสนับสนุน: Three Ways
Three Ways ไม่ใช่แค่แนวคิดที่ดี: งานวิจัยได้แสดงให้เห็นว่าการนำกลยุทธ์เหล่านี้ไปใช้ส่งผลให้เกิดผลลัพธ์ที่เหนือกว่าทั้งต่อองค์กรและบุคคล
ในการศึกษาระยะเวลาหกปีที่นำโดยผู้เขียนร่วม Dr. Nicole Forsgren ใน State of DevOps Reports ปี 2014–2019 ร่วมกับ Puppet และต่อมาคือ DORA และตีพิมพ์ในหนังสือ Accelerate: The Science of Lean and DevOps ข้อมูลแสดงให้เห็นว่ามีผลลัพธ์ที่ดีกว่าเมื่อรวมความสามารถและแนวปฏิบัติต่างๆ เช่น continuous integration, test, deployment และการทำงานในแบตช์ขนาดเล็ก (First Way), fast feedback และการตรวจสอบ (Second Way) และวัฒนธรรมแบบ generative (Third Way) 5
Three Ways ช่วยให้ทีมกลายเป็นผู้ปฏิบัติงานระดับ elite (elite performers) โดยการส่งมอบซอฟต์แวร์ได้เร็วและน่าเชื่อถือมากขึ้น ช่วยส่งเสริมรายได้ ส่วนแบ่งการตลาด และความพึงพอใจของลูกค้าขององค์กร ผู้ปฏิบัติงานระดับ elite มีแนวโน้มที่จะบรรลุหรือเกินเป้าหมายประสิทธิภาพขององค์กรเป็นสองเท่า Three Ways ยังช่วยปรับปรุงความเป็นอยู่ที่ดีของผู้ที่ทำงานอีกด้วย จากการวิจัยใน State of DevOps Reports พบว่าการนำแนวปฏิบัติเหล่านี้ไปใช้ช่วยลด burnout และ deployment pain 6
CASE STUDY: ใหม่ในฉบับพิมพ์ครั้งที่สอง
Approaching Cruising Altitude: การเดินทาง DevOps ของ American Airlines (ตอนที่ 1) (2020)
การเดินทาง DevOps ของ American Airlines เริ่มต้นจากชุดคำถาม โดยคำถามแรกก็คือ "DevOps คืออะไร?"
"เราเริ่มต้นจากจุดต่ำสุดจริงๆ จากจุดเริ่มต้นจริงๆ" Maya Leibman รองประธานบริหารและประธานเจ้าหน้าที่สารสนเทศของ American Airlines กล่าวในงาน DevOps Enterprise Summit-London 2020 7
ในการเริ่มต้น ทีมงานได้ทำการวิจัย แต่ที่สำคัญที่สุดคือพวกเขาหยุดหาข้อแก้ตัว ในช่วงแรกของ DevOps ตัวอย่างส่วนใหญ่มาจากบริษัทที่เกิดในยุคดิจิทัลอย่าง Netflix และ Spotify ทำให้ทีมงานมักจะมองข้ามความสำเร็จของตนเอง เพราะบริษัทเหล่านั้นเกิดมาบนคลาวด์แล้ว แต่เมื่อองค์กรดั้งเดิมอื่นๆ อย่าง Target, Nordstrom และ Starbucks หันมาใช้ DevOps มากขึ้น American Airlines ก็รู้ว่าพวกเขาไม่มีข้อแก้ตัวอีกต่อไป
ทีมงานเริ่มต้นโดย
1. กำหนดเป้าหมายที่เป็นรูปธรรม
2. จัดรูปแบบ toolchain ให้เป็นมาตรฐาน
3. นำโค้ชและที่ปรึกษาจากภายนอกเข้ามา
4. ทดลองและทำ automation
5. จัดการฝึกอบรมเชิงปฏิบัติการแบบ immersive (เรียนรู้ไปพร้อมกับการทำงาน)
ทั้งหมดนี้เชื่อมโยงกับเป้าหมายสูงสุดของพวกเขา นั่นคือการส่งมอบคุณค่าได้รวดเร็วขึ้น
ดังที่ Leibman กล่าวว่า:
มีหลายครั้งที่คู่ค้าทางธุรกิจนำเสนอไอเดียใหม่ๆ และพวกเขาก็บอกว่า "โอ้ นี่คือสิ่งที่เราอยากทำ แต่ IT จะใช้เวลาหกเดือนหรือหนึ่งปีกว่าจะทำเสร็จ" และประสบการณ์เหล่านั้นมันทำให้ผมเจ็บปวดมาก ดังนั้นแรงผลักดันเบื้องหลังนี้ก็คือ "เราจะไม่เป็นจุดคอขวดที่ยาวนานได้อย่างไร" เรารู้ว่ามันมีวิธีการทำงานที่ดีกว่าที่จะช่วยให้เราบรรลุเป้าหมายนั้น 8
จากนั้นพวกเขาก็ตัดสินใจว่าจะวัด output อะไรบ้าง: 9
• deployment frequency (ความถี่ในการ deploy)
• deployment cycle time (รอบเวลาในการ deploy)
• change failure rate (อัตราความล้มเหลวของการเปลี่ยนแปลง)
• development cycle time (รอบเวลาในการพัฒนา)
• number of incidents (จำนวนเหตุการณ์ที่เกิดขึ้น)
• mean time to recover หรือ MTTR (เวลาเฉลี่ยในการกู้คืน)
ความสำเร็จในช่วงต้นในการทำ value stream mapping ช่วยให้สมาชิกทีมเข้าใจกระบวนการ end-to-end ของระบบได้ดีขึ้นและสร้างแรงบันดาลใจ จากความสำเร็จเหล่านี้ พวกเขาสร้างพลังในการจัดการกับปัญหาและปรับปรุงแก้ไข พวกเขายังจัดโอกาสการเรียนรู้แบบ immersive ทั่วทั้งแผนก IT
ความสำเร็จในช่วงแรกเหล่านี้ การเรียนรู้เกี่ยวกับ DevOps และการเริ่มลงมือปฏิบัติจริง นำพวกเขาไปสู่คำถามสำคัญข้อที่สองในการเดินทาง DevOps: ฝ่ายการเงิน (Finance) เพื่อนหรือศัตรู?
กระบวนการอนุมัติทางการเงินในปัจจุบันนั้นยุ่งยากและใช้เวลานาน โดยมีรอบการอนุมัติที่กินเวลาหลายเดือน "ผมเคยอธิบายว่ามันเป็นกระบวนการที่ออกแบบมาเพื่อให้คุณยอมแพ้" Leibman กล่าว 10
กระบวนการมีลักษณะดังนี้: 11
• ไม่มีโปรเจกต์ใดได้รับการอนุมัติหากไม่มีการเกี่ยวข้องกับฝ่ายการเงิน
• โปรเจกต์ได้รับการอนุมัติ แต่ไม่มีการเพิ่มอัตรากำลังคนเพื่อดำเนินการ (และไม่มีการหยุดลำดับความสำคัญอื่นๆ)
• คำขอทั้งหมดได้รับการตรวจสอบอย่างเท่าเทียมกันโดยไม่คำนึงถึงขนาดหรือความเสี่ยง
• คำขอทั้งหมดได้รับการตรวจสอบอย่างเท่าเทียมกัน แม้ว่าคำขอนั้นจะเป็นลำดับความสำคัญสูงสุดของบริษัทและไม่ต้องสงสัยเลยว่าจะต้องดำเนินการ
• โปรเจกต์มักจะเสร็จสิ้นก่อนที่จะได้รับการอนุมัติ
แม้แต่ฝ่ายการเงินก็รู้ว่ากระบวนการต้องเปลี่ยนแปลง แต่การขาดความไว้วางใจระหว่างฝ่ายการเงินและ IT ก็เป็นอุปสรรค เพื่อช่วยให้เห็นว่าเงินถูกใช้ไปที่ใดและสร้างความไว้วางใจกับฝ่ายการเงิน ทีมงานได้ทำแบบฝึกหัดการจัดทำแผนผังต้นทุน (cost mapping) และกำหนดต้นทุนทั้งหมดให้กับผลิตภัณฑ์ของตน รวมถึงต้นทุนในการดำเนินการ
หลังจากแบบฝึกหัดนี้ ทีม IT สามารถเห็นได้ชัดเจนขึ้นว่าเงินถูกนำไปลงทุนที่ใดจริงๆ และสามารถตั้งคำถามว่านั่นเป็นการใช้เงินที่ดีที่สุดหรือไม่ และฝ่ายการเงินก็สามารถมองเห็นสิ่งที่ต้องการเพื่อวางใจได้ว่าไม่มีของเสียจำนวนมาก
การมองเห็นนี้สร้างความไว้วางใจที่จำเป็นสำหรับการทดลอง ฝ่ายการเงินเลือกทีมผลิตภัณฑ์สี่ทีมและให้งบประมาณประจำปีที่กำหนดไว้แก่พวกเขา ทีมงานกำหนด OKRs และใช้งบประมาณกับลำดับความสำคัญสูงสุดที่พวกเขาเห็นว่าสอดคล้องกับ OKRs เหล่านั้น สิ่งนี้ทำให้ทีมสามารถทดสอบก่อนที่จะขยายผล และมุ่งเน้นไปที่ความรับผิดชอบ (accountability) และผลลัพธ์ (outcomes) และฝ่ายการเงินก็สามารถมองเห็นได้มากขึ้นอีก
รูปที่ 1.5: เส้นทางการเปลี่ยนแปลง DevOps ของ American Airlines
ที่มา: ได้รับอนุญาตจาก Ross Clanton
ความสำเร็จนี้ทำให้พวกเขาสามารถขยายโมเดลใหม่ไปยังผลิตภัณฑ์ทั้งหมดของตนและกำหนดกระบวนการจัดหาเงินทุนแบบใหม่ "นี่เป็นตัวเร่งที่ยิ่งใหญ่ในการเดินทางของเรา" Leibman กล่าว 12
เมื่อมีฝ่ายการเงินสนับสนุนและมีกระบวนการใหม่ๆ อยู่ในสถานที่ American Airlines ก็ค้นพบคำถามที่สามในการเดินทาง DevOps: เราจะรู้ได้อย่างไรว่าคะแนนของเราคืออะไร? กับความสำเร็จเล็กๆ แต่ละครั้ง ทีมงานต้องการเข้าใจมากขึ้นว่าพวกเขาทำงานโดยรวมเป็นอย่างไร กล่าวอีกนัยหนึ่ง พวกเขาต้องการรู้ว่าคะแนนของพวกเขาคืออะไร
สำหรับทีม American Airlines ปีแรกของการเดินทาง DevOps มุ่งเน้นไปที่ inputs เป็นหลัก: การเรียนรู้เกี่ยวกับ Agile/DevOps การมุ่งเน้นที่ผลิตภัณฑ์ คลาวด์ ความปลอดภัย ฯลฯ ปีที่สองของการเดินทางมุ่งเน้นไปที่ outputs มากขึ้น รวมถึง metrics ที่พวกเขาเริ่มวัด เช่น deployment frequency และ mean time to recover สุดท้ายในปีที่สาม พวกเขาเริ่มมุ่งเน้นไม่เพียงแค่ inputs และ outputs แต่รวมถึง outcomes "ในท้ายที่สุด เราอยากทำอะไรจริงๆ?" Leibman กล่าว
พวกเขากำหนด outcomes ดังนี้: ทำเงิน, ปรับปรุงการดำเนินงาน (Ops), เพิ่ม LTR และลดต้นทุน 13
ในปีแรก หนึ่งในวัตถุประสงค์ของเราคือคน X% จะไปเข้ารับการฝึกอบรม Agile ซึ่งนั่นคือ input ในปีที่สอง เมื่อเราเริ่มมุ่งเน้นไปที่ outputs มากขึ้น วัตถุประสงค์ก็เปลี่ยนไปเป็นทีม X% จะยกระดับวุฒิภาวะด้าน Agile จากระดับนี้ไปสู่ระดับนี้ และพอถึงปีที่สาม Agile ก็ไม่ใช่วัตถุประสงค์อีกต่อไป เราตระหนักว่า inputs และ outputs นั้นดี เราต้องวัดมัน แต่สุดท้ายแล้วเราต้องมุ่งเน้นที่ outcome 14
สุดท้ายนี้นำไปสู่คำถามที่สี่ในการเดินทาง DevOps: ผลิตภัณฑ์ (product) คืออะไร? ชัดเจนว่าถึงเวลาที่ต้องกำหนด taxonomy ของพวกเขาให้ชัดเจน ซึ่งกลายเป็นหนึ่งในช่วงเวลาที่ท้าทายที่สุดในการเดินทางของพวกเขา มีความคิดเห็นมากมายและไม่มีคำตอบที่ถูกต้องเพียงคำตอบเดียว ในที่สุดพวกเขาก็ตัดสินใจแค่เริ่มต้น วางอะไรบางอย่างลงบนกระดาษ จัดระเบียบรอบๆ สิ่งนั้น และแก้ไขไปพร้อมๆ กับการเรียนรู้ และสุดท้าย ทั้งหมดนี้นำไปสู่คำถามที่ห้าของพวกเขา: นี่มันใหญ่กว่า DevOps มากใช่ไหม? เพื่อตอบคำถามนั้นและแสดงตัวอย่างความสำเร็จของผลิตภัณฑ์ที่เฉพาะเจาะจง เราจะมาติดตามการเดินทางของ American Airlines ต่อในหนังสือเล่มนี้
กรณีศึกษานี้แสดงให้เห็นการประยุกต์ใช้ Three Ways โดยการใช้ value stream mapping เพื่อช่วยปรับปรุงการไหล (optimize flow) การเลือก outcomes เพื่อวัดเพื่อสร้าง feedback ที่รวดเร็ว และการสร้างประสบการณ์การเรียนรู้แบบ immersive เพื่อสร้างวัฒนธรรมของการเรียนรู้อย่างต่อเนื่องและการทดลอง
Conclusion (บทสรุป)
ในบทนี้ เราได้อธิบายแนวคิดของ value streams, lead time ในฐานะหนึ่งในตัววัดประสิทธิภาพที่สำคัญสำหรับทั้ง value stream ด้านการผลิตและเทคโนโลยี และแนวคิดระดับสูงเบื้องหลัง Three Ways แต่ละข้อ ซึ่งเป็นหลักการที่รองรับ DevOps
ในบทต่อๆ ไป หลักการสำหรับ Three Ways แต่ละข้อจะถูกอธิบายในรายละเอียดมากขึ้น หลักการแรกคือ Flow ซึ่งมุ่งเน้นไปที่วิธีสร้างการไหลของงานอย่างรวดเร็วใน value stream ใดๆ ไม่ว่าจะเป็นงานด้านการผลิตหรือเทคโนโลยี แนวปฏิบัติที่ช่วยให้เกิดการไหลที่รวดเร็วจะอธิบายใน ส่วนที่ III .
ต่อจากนี้ไป วิศวกร (engineer) หมายถึงใครก็ตามที่ทำงานใน value stream ของเรา ไม่ใช่แค่นักพัฒนา (developers) | |
ที่จริงแล้ว ด้วยเทคนิคอย่าง test-driven development การทดสอบเกิดขึ้นก่อนที่จะเขียนโค้ดแม้แต่บรรทัดแรกด้วยซ้ำ | |
ในหนังสือเล่มนี้ คำว่า process time จะถูกใช้ด้วยเหตุผลเดียวกับที่ Karen Martin และ Mike Osterling อ้างถึง: "เพื่อลดความสับสน เราหลีกเลี่ยงการใช้คำว่า cycle time เพราะมันมีคำจำกัดความหลายอย่างที่ synonym กับ processing time และ pace หรือความถี่ของ output เป็นต้น" 2 |