19
ENABLE AND INJECT LEARNING INTO DAILY WORK (เปิดโอกาสให้เกิดการเรียนรู้และสอดแทรกไว้ในงานประจำวัน)
W เมื่อเราทำงานในระบบที่ซับซ้อน เราไม่สามารถคาดการณ์ผลลัพธ์ทั้งหมดของการกระทำของเราได้ สิ่งนี้ก่อให้เกิดอุบัติเหตุที่ไม่คาดคิดและบางครั้งก็รุนแรง แม้ว่าเราจะใช้เครื่องมือป้องกันแบบตายตัว เช่น checklists และ runbooks ซึ่งรวบรวมความเข้าใจในปัจจุบันของเราเกี่ยวกับระบบก็ตาม
เพื่อให้เราสามารถทำงานในระบบที่ซับซ้อนได้อย่างปลอดภัย องค์กรของเราต้องพัฒนาความสามารถในการวินิจฉัยตนเองและปรับปรุงตนเองให้ดีขึ้นเรื่อยๆ และต้องมีทักษะในการตรวจจับปัญหา แก้ปัญหา และขยายผลโดยทำให้แนวทางแก้ไขพร้อมใช้งานทั่วทั้งองค์กร สิ่งนี้สร้างระบบการเรียนรู้แบบพลวัตที่ช่วยให้เราเข้าใจความผิดพลาดของเรา และเปลี่ยนความเข้าใจนั้นไปสู่การปฏิบัติที่ช่วยป้องกันไม่ให้ความผิดพลาดเหล่านั้นเกิดขึ้นซ้ำอีกในอนาคต
ผลลัพธ์ที่ได้คือสิ่งที่ Dr. Steven Spear อธิบายว่าเป็น resilient organizations ที่ "มีทักษะในการตรวจจับปัญหา แก้ปัญหา และขยายผลโดยทำให้แนวทางแก้ไขพร้อมใช้งานทั่วทั้งองค์กร" 1 องค์กรเหล่านี้สามารถรักษาตัวเองได้ "สำหรับองค์กรเช่นนี้ การตอบสนองต่อวิกฤตไม่ใช่เรื่องที่เกิดขึ้นเป็นครั้งคราว แต่เป็นสิ่งที่ทำอยู่ตลอดเวลา การตอบสนองนี้ต่างหากที่เป็นที่มาของความน่าเชื่อถือของพวกเขา" 2
AWS US-East and Netflix (2011) (AWS US-East และ Netflix ปี 2011)
ตัวอย่างที่โดดเด่นของความยืดหยุ่นอันน่าทึ่งที่เกิดจากหลักการและแนวปฏิบัติเหล่านี้คือเหตุการณ์เมื่อวันที่ 21 เมษายน 2011 เมื่อ availability zone ทั้งโซนในภูมิภาค US-East ของ Amazon Web Services (AWS) ล่ม ส่งผลให้องค์กรแทบทุกแห่งที่พึ่งพาบริการนี้ล่มไปด้วย รวมถึง Reddit และ Quora 3 * อย่างไรก็ตาม Netflix เป็นข้อยกเว้นที่น่าประหลาดใจ ดูเหมือนไม่ได้รับผลกระทบจากเหตุการณ์ AWS ล่มครั้งใหญ่นี้เลย
หลังจากเหตุการณ์นั้น มีการคาดเดากันมากมายว่า Netflix รักษาบริการให้ทำงานต่อไปได้อย่างไร ทฤษฎีที่ได้รับความนิยมคือเนื่องจาก Netflix เป็นหนึ่งในลูกค้ารายใหญ่ที่สุดของ Amazon Web Services จึงได้รับการปฏิบัติเป็นพิเศษที่ทำให้พวกเขายังคงให้บริการได้ อย่างไรก็ตาม บล็อกของ Netflix Engineering อธิบายว่าการตัดสินใจด้านสถาปัตยกรรมในปี 2009 ต่างหากที่ทำให้พวกเขามีความยืดหยุ่นเป็นพิเศษ
ย้อนกลับไปในปี 2008 บริการส่งมอบวิดีโอออนไลน์ของ Netflix ทำงานบนแอปพลิเคชัน J2EE แบบ monolithic ที่โฮสต์ใน data center ของตนเอง แต่ตั้งแต่ปี 2009 พวกเขาเริ่มออกแบบสถาปัตยกรรมระบบใหม่ให้เป็นสิ่งที่เรียกว่า cloud native —ออกแบบมาให้ทำงานทั้งหมดบนคลาวด์สาธารณะของ Amazon และมีความยืดหยุ่นเพียงพอที่จะอยู่รอดจากความล้มเหลวครั้งใหญ่ 5
หนึ่งในเป้าหมายการออกแบบเฉพาะของพวกเขาคือการทำให้แน่ใจว่าบริการของ Netflix ยังคงทำงานต่อไปได้ แม้ว่า availability zone ของ AWS ทั้งโซนจะล่ม เช่นที่เกิดขึ้นกับ US-East การทำเช่นนี้ต้องการให้ระบบของพวกเขาเชื่อมต่อกันแบบ loosely coupled โดยแต่ละ component มี timeouts และ circuit breakers † ที่รุนแรงเพียงพอเพื่อให้แน่ใจว่า component ที่ล้มเหลวจะไม่ทำให้ทั้งระบบล่มลงไปด้วย
ในทางกลับกัน แต่ละ feature และ component ถูกออกแบบให้ gracefully degrade ตัวอย่างเช่น ในช่วงที่ปริมาณการใช้งานพุ่งสูงจนทำให้ CPU usage สูงเกินไป แทนที่จะแสดงรายชื่อภาพยนตร์ที่ปรับแต่งเฉพาะสำหรับผู้ใช้ พวกเขาจะแสดงเนื้อหาแบบ static เช่น ผลลัพธ์ที่ถูก cache หรือไม่ได้ปรับแต่งเฉพาะบุคคล ซึ่งใช้การคำนวณน้อยกว่า 6
ยิ่งไปกว่านั้น ตามที่บล็อกโพสต์อธิบาย นอกเหนือจากการนำรูปแบบทางสถาปัตยกรรมเหล่านี้มาใช้แล้ว พวกเขายังสร้างและรันบริการที่น่าประหลาดใจและกล้าหาญที่ชื่อว่า Chaos Monkey ซึ่งจำลองความล้มเหลวของ AWS โดยการฆ่า production servers อย่างต่อเนื่องและสุ่ม พวกเขาทำเช่นนี้เพราะต้องการให้ "ทีมวิศวกรรมทั้งหมดคุ้นเคยกับความล้มเหลวในระดับที่สม่ำเสมอบนคลาวด์" เพื่อให้บริการ "สามารถกู้คืนได้โดยอัตโนมัติโดยไม่ต้องมีการแทรกแซงด้วยตนเอง" 7
กล่าวอีกนัยหนึ่ง ทีม Netflix ใช้ Chaos Monkey เพื่อสร้างความมั่นใจว่าพวกเขาบรรลุเป้าหมายด้านความยืดหยุ่นในการดำเนินงาน โดยการฉีดความล้มเหลวเข้าไปในสภาพแวดล้อม pre-production และ production อย่างต่อเนื่อง
อย่างที่คาดไว้ เมื่อพวกเขาเริ่มรัน Chaos Monkey ในสภาพแวดล้อม production เป็นครั้งแรก บริการก็ล้มเหลวในแบบที่พวกเขาไม่เคยคาดการณ์หรือจินตนาการมาก่อน ด้วยการค้นหาและแก้ไขปัญหาเหล่านี้อย่างต่อเนื่องในช่วงเวลาทำงานปกติ วิศวกรของ Netflix ก็ได้สร้างบริการที่ยืดหยุ่นมากขึ้นอย่างรวดเร็วและเป็น iterative ขณะเดียวกันก็สร้างการเรียนรู้ขององค์กร (ในช่วงเวลาทำงานปกติ!) ที่ช่วยให้พวกเขาพัฒนาระบบของตนให้ก้าวล้ำนำคู่แข่งไปไกล
Chaos Monkey เป็นเพียงตัวอย่างหนึ่งของการบูรณาการการเรียนรู้เข้ากับงานประจำวัน เรื่องราวนี้ยังแสดงให้เห็นว่าองค์กรแห่งการเรียนรู้ (learning organizations) มองความล้มเหลว อุบัติเหตุ และความผิดพลาดอย่างไร—ในฐานะโอกาสในการเรียนรู้ ไม่ใช่สิ่งที่จะต้องถูกลงโทษ บทนี้จะสำรวจวิธีการสร้างระบบการเรียนรู้ และวิธีการสร้าง just culture รวมถึงวิธีการซักซ้อมและสร้างความล้มเหลวอย่างจงใจเป็นประจำเพื่อเร่งการเรียนรู้
Establish a Just, Learning Culture (สร้างวัฒนธรรมแห่งความยุติธรรมและการเรียนรู้)
หนึ่งในข้อกำหนดเบื้องต้นสำหรับวัฒนธรรมแห่งการเรียนรู้คือเมื่อเกิดอุบัติเหตุขึ้น (ซึ่งแน่นอนว่ามันจะเกิดขึ้น) การตอบสนองต่ออุบัติเหตุเหล่านั้นต้องถูกมองว่า "ยุติธรรม" Dr. Sidney Dekker ผู้ซึ่งช่วยกำหนดองค์ประกอบสำคัญของวัฒนธรรมความปลอดภัยและบัญญัติคำว่า just culture เขียนไว้ว่า "เมื่อการตอบสนองต่อเหตุการณ์และอุบัติเหตุถูกมองว่าไม่ยุติธรรม มันสามารถขัดขวางการสอบสวนด้านความปลอดภัย สร้างความกลัวแทนที่จะเป็นความตระหนักรู้ในตัวคนที่ทำงานด้านความปลอดภัยที่สำคัญ ทำให้องค์กรกลายเป็นระบบราชการมากกว่าระมัดระวังมากขึ้น และปลูกฝังความลับทางวิชาชีพ การหลีกเลี่ยง และการปกป้องตนเอง" 8
แนวคิดเรื่องการลงโทษนี้ปรากฏอยู่ ไม่ว่าจะอย่างแยบยลหรืออย่างเด่นชัด ในวิธีการทำงานของผู้จัดการหลายคนตลอดศตวรรษที่ผ่านมา แนวคิดก็คือเพื่อให้บรรลุเป้าหมายขององค์กร ผู้นำต้องสั่งการ ควบคุม กำหนดขั้นตอนเพื่อกำจัดข้อผิดพลาด และบังคับใช้การปฏิบัติตามขั้นตอนเหล่านั้น
Dr. Dekker เรียกแนวคิดในการกำจัดข้อผิดพลาดโดยการกำจัดคนที่ก่อให้เกิดข้อผิดพลาดนี้ว่า bad apple theory เขายืนยันว่าแนวคิดนี้ไม่ถูกต้อง เพราะ "ความผิดพลาดของมนุษย์ไม่ใช่สาเหตุของปัญหาของเรา แต่ความผิดพลาดของมนุษย์เป็นผลมาจากการออกแบบเครื่องมือที่เรามอบให้พวกเขา" 9
หากอุบัติเหตุไม่ได้เกิดจาก "bad apples" แต่เกิดจากปัญหาการออกแบบที่หลีกเลี่ยงไม่ได้ในระบบที่ซับซ้อนที่เราสร้างขึ้น แทนที่จะ "ชี้ตัว กล่าวโทษ และทำให้อับอาย" (naming, blaming, and shaming) คนที่ก่อให้เกิดความล้มเหลว เป้าหมายของเราควรเป็นการเพิ่มโอกาสในการเรียนรู้ขององค์กรให้สูงสุด โดยตอกย้ำอย่างต่อเนื่องว่าเราให้คุณค่ากับการกระทำที่เปิดโปงและแบ่งปันปัญหาในงานประจำวันของเราให้กว้างขวางยิ่งขึ้น นี่คือสิ่งที่ช่วยให้เราปรับปรุงคุณภาพและความปลอดภัยของระบบที่เราทำงานอยู่ และเสริมสร้างความสัมพันธ์ระหว่างทุกคนที่ทำงานในระบบนั้น
ด้วยการเปลี่ยนข้อมูลให้เป็นความรู้และสร้างผลลัพธ์ของการเรียนรู้ลงในระบบของเรา เราจึงเริ่มบรรลุเป้าหมายของ just culture ที่สร้างสมดุลระหว่างความต้องการด้านความปลอดภัยและความรับผิดชอบ ดังที่ John Allspaw, CTO ของ Etsy กล่าวไว้ว่า "เป้าหมายของเราที่ Etsy คือการมองความผิดพลาด ข้อผิดพลาด การพลั้งเผลอ การหลงลืม และอื่นๆ ด้วยมุมมองของการเรียนรู้" 10
เมื่อวิศวกรทำผิดพลาดและรู้สึกปลอดภัยที่จะให้รายละเอียดเกี่ยวกับมัน พวกเขาไม่เพียงแต่ยินดีที่จะรับผิดชอบ แต่ยังกระตือรือร้นที่จะช่วยให้ส่วนอื่นๆ ของบริษัทหลีกเลี่ยงความผิดพลาดเดียวกันในอนาคต นี่คือสิ่งที่สร้างการเรียนรู้ขององค์กร ในทางกลับกัน หากเราลงโทษวิศวกรคนนั้น ทุกคนก็จะไม่มีแรงจูงใจที่จะให้รายละเอียดที่จำเป็นเพื่อทำความเข้าใจกลไก พยาธิสภาพ และการทำงานของความล้มเหลว ซึ่งรับประกันได้ว่าความล้มเหลวนั้นจะเกิดขึ้นอีกครั้ง
แนวปฏิบัติที่มีประสิทธิภาพสองประการที่ช่วยสร้างวัฒนธรรมที่ยุติธรรมและเน้นการเรียนรู้คือ blameless post-mortems (หรือที่เรียกว่า retrospectives หรือ learning reviews) และการนำความล้มเหลวเข้าสู่ production อย่างควบคุมได้ เพื่อสร้างโอกาสในการฝึกฝนรับมือกับปัญหาที่หลีกเลี่ยงไม่ได้ซึ่งเกิดขึ้นในระบบที่ซับซ้อน เราจะมาดู retrospective กันก่อน จากนั้นจึงสำรวจว่าทำไมความล้มเหลวจึงเป็นสิ่งที่ดี
Schedule Retrospective Meetings after Accidents Occur (จัดการประชุม Retrospective หลังจากเกิดอุบัติเหตุ)
เพื่อช่วยส่งเสริม just culture เมื่อเกิดอุบัติเหตุและเหตุการณ์สำคัญ (เช่น deployment ล้มเหลว ปัญหาใน production ที่กระทบต่อลูกค้า) เราควรจัด retrospective หลังจากที่ปัญหาได้รับการแก้ไขแล้ว ‡ Retrospectives ช่วยให้เราตรวจสอบ "ความผิดพลาดในแบบที่เน้นไปที่แง่มุมเชิงสถานการณ์ของกลไกความล้มเหลวและกระบวนการตัดสินใจของบุคคลที่อยู่ใกล้กับความล้มเหลวนั้น" 11
ในการดำเนินการนี้ เราจะจัด retrospective โดยเร็วที่สุดหลังจากเกิดอุบัติเหตุและก่อนที่ความทรงจำและความเชื่อมโยงระหว่างเหตุและผลจะเลือนหายไปหรือสถานการณ์เปลี่ยนไป (แน่นอนว่าเรารอจนกว่าปัญหาจะได้รับการแก้ไขแล้ว เพื่อไม่เป็นการรบกวนคนที่ยังคงทำงานแก้ไขปัญหาอยู่)
In the meeting, we will do the following: (ในการประชุม เราจะดำเนินการดังนี้)
• สร้างไทม์ไลน์และรวบรวมรายละเอียดจากหลายมุมมองเกี่ยวกับความล้มเหลว เพื่อให้แน่ใจว่าเราจะไม่ลงโทษคนที่ทำผิดพลาด
• เสริมพลังให้วิศวกรทุกคนในการปรับปรุงความปลอดภัย โดยเปิดโอกาสให้พวกเขาให้รายละเอียดเกี่ยวกับการมีส่วนร่วมในความล้มเหลว
• เปิดโอกาสและสนับสนุนให้คนที่ทำผิดพลาดเป็นผู้เชี่ยวชาญที่ให้ความรู้แก่ส่วนอื่นๆ ขององค์กรเกี่ยวกับวิธีการหลีกเลี่ยงไม่ให้เกิดข้อผิดพลาดเหล่านั้นในอนาคต
• ยอมรับว่ามักจะมีพื้นที่วินิจฉัย (discretionary space) ที่มนุษย์สามารถตัดสินใจลงมือทำหรือไม่ทำ และการตัดสินใจเหล่านั้นจะถูกประเมินเมื่อมองย้อนกลับไป
• เสนอมาตรการรับมือ (countermeasures) เพื่อป้องกันไม่ให้เกิดอุบัติเหตุคล้ายกันในอนาคต และให้แน่ใจว่ามาตรการเหล่านี้ถูกบันทึกพร้อมวันที่เป้าหมายและผู้รับผิดชอบในการติดตามผล
To enable us to gain this understanding, the following stakeholders need to be present at the meeting: (เพื่อให้เราได้รับความเข้าใจนี้ ผู้มีส่วนได้ส่วนเสียต่อไปนี้ควรเข้าร่วมการประชุม)
• ผู้ที่เกี่ยวข้องกับการตัดสินใจที่อาจมีส่วนทำให้เกิดปัญหา
• ผู้ที่ระบุปัญหา
• ผู้ที่ตอบสนองต่อปัญหา
• ผู้ที่วินิจฉัยปัญหา
• ผู้ที่ได้รับผลกระทบจากปัญหา
• บุคคลอื่นใดที่สนใจเข้าร่วมการประชุม
งานแรกของเราใน retrospective คือการบันทึกความเข้าใจที่ดีที่สุดของเราเกี่ยวกับไทม์ไลน์ของเหตุการณ์ที่เกี่ยวข้องตามที่เกิดขึ้น ซึ่งรวมถึงการดำเนินการทั้งหมดที่เราทำและเวลา (ควรมีหลักฐานจาก chat logs เช่น IRC หรือ Slack) ผลกระทบที่เราสังเกตเห็น (ควรเป็น metrics เฉพาะจาก production telemetry ของเรา แทนที่จะเป็นเพียงคำบอกเล่าเชิงอัตวิสัย) เส้นทางการสอบสวนทั้งหมดที่เราดำเนินการ และแนวทางแก้ไขที่ได้รับการพิจารณา
เพื่อให้เกิดผลลัพธ์เหล่านี้ เราต้องเข้มงวดในการบันทึกรายละเอียดและเสริมสร้างวัฒนธรรมที่สามารถแบ่งปันข้อมูลได้โดยไม่ต้องกลัวการลงโทษหรือการตอบโต้ ด้วยเหตุนี้ โดยเฉพาะสำหรับ retrospectives สองสามครั้งแรก อาจเป็นประโยชน์หากให้ผู้ดำเนินการประชุมที่ได้รับการฝึกอบรมและไม่ได้เกี่ยวข้องกับอุบัติเหตุเป็นผู้นำการประชุม
ระหว่างการประชุมและการแก้ไขปัญหาภายหลัง เราควรห้ามใช้วลี "would have" หรือ "could have" อย่างชัดเจน เนื่องจากเป็น ข้อความเชิงสมมติย้อนหลัง (counterfactual) ที่เกิดจากแนวโน้มของมนุษย์ในการสร้างทางเลือกอื่นๆ ที่เป็นไปได้สำหรับเหตุการณ์ที่เกิดขึ้นแล้ว
ข้อความเชิงสมมติย้อนหลัง เช่น "ฉันคงจะ..." หรือ "ถ้าฉันรู้เรื่องนั้น ฉันน่าจะ..." ทำให้ปัญหาถูกมองในแง่ของ ระบบอย่างที่จินตนาการ (system as imagined) แทนที่จะเป็น ระบบที่มีอยู่จริง (system that actually exists) ซึ่งเป็นบริบทที่เราควรจำกัดตัวเองให้อยู่ภายใน (ดู ภาคผนวก 8 .)
หนึ่งในผลลัพธ์ที่อาจน่าประหลาดใจจากการประชุมเหล่านี้คือผู้คนมักจะโทษตัวเองในสิ่งที่อยู่นอกเหนือการควบคุมของตน หรือตั้งคำถามกับความสามารถของตนเอง Ian Malpass วิศวกรของ Etsy กล่าวไว้ว่า
"ในวินาทีที่เราทำสิ่งที่ทำให้ทั้งเว็บไซต์ล่ม เราจะรู้สึกเหมือน 'น้ำแข็งไหลลงมาตามสันหลัง' และความคิดแรกที่น่าจะผุดขึ้นในหัวก็คือ 'ฉันห่วยแตกและไม่รู้ว่าตัวเองกำลังทำอะไร' เราต้องหยุดตัวเองจากการคิดแบบนั้น เพราะมันเป็นหนทางสู่ความบ้าคลั่ง ความสิ้นหวัง และความรู้สึกว่าเป็นคนปลอม (imposter) ซึ่งเป็นสิ่งที่เราไม่ควรปล่อยให้เกิดขึ้นกับวิศวกรที่ดี คำถามที่ดีกว่าที่ควรมุ่งเน้นคือ 'ทำไมการกระทำนั้นถึงดูสมเหตุสมผลสำหรับฉันในตอนนั้น?'" 12
ในการประชุม เราต้องจัดสรรเวลาให้เพียงพอสำหรับการระดมสมองและตัดสินใจว่ามาตรการรับมือใดควรนำไปปฏิบัติ เมื่อระบุมาตรการรับมือได้แล้ว ต้องจัดลำดับความสำคัญและกำหนดผู้รับผิดชอบและไทม์ไลน์สำหรับการดำเนินการ การทำเช่นนี้แสดงให้เห็นเพิ่มเติมว่าเราให้คุณค่ากับการปรับปรุงงานประจำวันมากกว่างานประจำวันเสียอีก
Dan Milstein วิศวกรหลักของ Hubspot เขียนว่าเขาเริ่ม retrospective ทุกครั้งด้วยการพูดว่า "เรากำลังพยายามเตรียมตัวสำหรับอนาคตที่เรายังโง่เขลาเท่ากับในวันนี้" 13 กล่าวอีกนัยหนึ่ง การมีมาตรการรับมือเพียงแค่ "ระวังให้มากขึ้น" หรือ "อย่าโง่" นั้นไม่เพียงพอ—เราต้องออกแบบมาตรการรับมือที่เป็นรูปธรรมเพื่อป้องกันไม่ให้ข้อผิดพลาดเหล่านี้เกิดขึ้นอีก
ตัวอย่างของมาตรการรับมือดังกล่าวรวมถึงการเพิ่ม automated tests ใหม่เพื่อตรวจจับสภาวะอันตรายใน deployment pipeline การเพิ่ม production telemetry เพิ่มเติม การระบุประเภทของการเปลี่ยนแปลงที่ต้องการ peer review เพิ่มเติม และการซักซ้อมความล้มเหลวประเภทนี้ในฐานะส่วนหนึ่งของการฝึกซ้อม game day ตามปกติ
Publish Our Retrospective Reviews as Widely as Possible (เผยแพร่บทสรุป Retrospective ให้กว้างขวางที่สุดเท่าที่เป็นไปได้)
หลังจากที่เราจัด retrospective แล้ว เราควรประกาศให้ทราบอย่างกว้างขวางถึงความพร้อมของบันทึกการประชุมและสิ่งเกี่ยวเนื่องต่างๆ (เช่น ไทม์ไลน์ บันทึกแชท IRC การสื่อสารภายนอก) ข้อมูลนี้ควร (ตามอุดมคติ) ถูกวางไว้ในตำแหน่งศูนย์กลางที่ทั้งองค์กรสามารถเข้าถึงและเรียนรู้จากเหตุการณ์นั้นได้ การจัด retrospectives มีความสำคัญมากจนเราอาจห้ามปิด incident ใน production จนกว่า retrospective จะเสร็จสมบูรณ์
การทำเช่นนี้ช่วยให้เราเปลี่ยนการเรียนรู้และการปรับปรุงในระดับท้องถิ่นให้เป็นการเรียนรู้และการปรับปรุงในระดับโลก Randy Shoup อดีต engineering director ของ Google App Engine อธิบายว่าการบันทึก retrospective สามารถมีคุณค่ามหาศาลต่อผู้อื่นในองค์กรได้อย่างไร: "อย่างที่คุณคงพอจะนึกออก ที่ Google ทุกอย่างสามารถค้นหาได้ เอกสาร retrospective ทั้งหมดถูกเก็บไว้ในที่ที่ Googlers คนอื่นๆ สามารถเห็นได้ และขอเชื่อฉันเถอะ เมื่อกลุ่มใดมีเหตุการณ์ที่ฟังดูคล้ายกับสิ่งที่เคยเกิดขึ้นมาก่อน เอกสาร retrospective เหล่านี้จะเป็นหนึ่งในเอกสารแรกๆ ที่ถูกอ่านและศึกษา" 14 §
การเผยแพร่ retrospectives อย่างกว้างขวางและสนับสนุนให้ผู้อื่นในองค์กรอ่านเป็นการเพิ่มการเรียนรู้ขององค์กร นอกจากนี้ยังกลายเป็นเรื่องปกติมากขึ้นที่บริษัทบริการออนไลน์จะเผยแพร่ retrospectives สำหรับการหยุดให้บริการที่กระทบต่อลูกค้า ซึ่งมักจะเพิ่มความโปร่งใสที่เรามีต่อลูกค้าทั้งภายในและภายนอกอย่างมีนัยสำคัญ ซึ่งส่งผลให้ความไว้วางใจที่พวกเขามีต่อเราเพิ่มขึ้นตามไปด้วย
ความต้องการที่จะจัด retrospective meetings ให้มากเท่าที่จำเป็นที่ Etsy นำไปสู่ปัญหาบางประการ—ในช่วงสี่ปี Etsy สะสมบันทึกการประชุม post-mortem (retrospectives) จำนวนมากในหน้า wiki ซึ่งค้นหา บันทึก และทำงานร่วมกันได้ยากขึ้นเรื่อยๆ เพื่อช่วยแก้ไขปัญหานี้ พวกเขาจึงพัฒนาเครื่องมือที่ชื่อว่า Morgue เพื่อบันทึกแง่มุมต่างๆ ของแต่ละอุบัติเหตุได้ง่ายขึ้น เช่น MTTR และความรุนแรงของ incident การจัดการกับเขตเวลาที่ดีขึ้น (ซึ่งมีความสำคัญมากขึ้นเมื่อพนักงาน Etsy ทำงานทางไกลมากขึ้น) และข้อมูลอื่นๆ เช่น rich text ในรูปแบบ Markdown, embedded images, tags, และประวัติ 16
Morgue was designed to make it easy for the team to record: (Morgue ถูกออกแบบมาเพื่อให้ทีมบันทึกข้อมูลต่อไปนี้ได้ง่าย)
• ว่าปัญหาเกิดจาก incident ที่มีการวางแผนหรือไม่ได้วางแผน
• เจ้าของ retrospective
• บันทึกแชท IRC ที่เกี่ยวข้อง (สำคัญเป็นพิเศษสำหรับปัญหาที่เกิดตอน 3 AM ซึ่งการจดบันทึกที่แม่นยำอาจไม่เกิดขึ้น)
• JIRA tickets ที่เกี่ยวข้องสำหรับการดำเนินการแก้ไขและวันครบกำหนด (ข้อมูลที่สำคัญเป็นพิเศษสำหรับฝ่ายจัดการ)
• ลิงก์ไปยังโพสต์ในฟอรัมลูกค้า (ที่ลูกค้าบ่นเกี่ยวกับปัญหา)
หลังจากพัฒนาและใช้ Morgue จำนวน retrospectives ที่ถูกบันทึกที่ Etsy เพิ่มขึ้นอย่างมีนัยสำคัญเมื่อเทียบกับตอนที่ใช้หน้า wiki โดยเฉพาะสำหรับ P2, P3 และ P4 (คือปัญหาที่มีความรุนแรงน้อยกว่า) 17 ผลลัพธ์นี้ตอกย้ำสมมติฐานที่ว่าหากทำให้การบันทึก retrospectives ง่ายขึ้นผ่านเครื่องมือเช่น Morgue ผู้คนจะบันทึกและให้รายละเอียดผลลัพธ์ของ retrospectives มากขึ้น ทำให้เกิดการเรียนรู้ขององค์กรมากขึ้น
Continuous Learning (การเรียนรู้อย่างต่อเนื่อง)
การจัด retrospectives ไม่เพียงแค่ช่วยให้เราเรียนรู้จากความล้มเหลว รายงาน 2018 State of DevOps Report ของ DORA พบว่ามันมีส่วนช่วยในวัฒนธรรมของเรา ทำให้ทีมรู้สึกดีขึ้นเกี่ยวกับการแบ่งปันข้อมูล การกล้าเสี่ยงอย่างชาญฉลาด และการเข้าใจคุณค่าของการเรียนรู้ นอกจากนี้ งานวิจัยยังพบว่าผู้ปฏิบัติงานระดับสูง (elite performers) มีแนวโน้มที่จะจัด retrospectives อย่างสม่ำเสมอและใช้มันเพื่อปรับปรุงงานของพวกเขามากถึง 1.5 เท่า—ดังนั้นทีมระดับ elite เหล่านี้จึงยังคงได้รับประโยชน์อย่างต่อเนื่อง 18
Dr. Amy C. Edmondson, Novartis Professor of Leadership and Management ที่ Harvard Business School และผู้ร่วมเขียนหนังสือ Building the Future: Big Teaming for Audacious Innovation เขียนไว้ว่า:
"อีกครั้ง วิธีการแก้ไข—ซึ่งไม่จำเป็นต้องใช้เวลาและค่าใช้จ่ายมากนัก—คือการลดความอัปยศของความล้มเหลว Eli Lilly ได้ทำสิ่งนี้มาตั้งแต่ต้นทศวรรษ 1990 โดยการจัด 'failure parties' เพื่อเป็นเกียรติแก่การทดลองทางวิทยาศาสตร์ที่ชาญฉลาดและมีคุณภาพสูงซึ่งไม่บรรลุผลตามที่ต้องการ งานเลี้ยงเหล่านี้ไม่เสียค่าใช้จ่ายมากนัก และการจัดสรรทรัพยากรที่มีค่า—โดยเฉพาะนักวิทยาศาสตร์—ไปยังโครงการใหม่ตั้งแต่เนิ่นๆ แทนที่จะปล่อยไว้นาน สามารถประหยัดเงินได้หลายแสนดอลลาร์ ไม่ต้องพูดถึงการจุดประกายการค้นพบใหม่ๆ ที่อาจเกิดขึ้น" 19
Decrease Incident Tolerances to Find Ever-Weaker Failure Signals (ลดระดับความทนทานต่อเหตุการณ์เพื่อค้นหาสัญญาณความล้มเหลวที่อ่อนลงเรื่อยๆ)
อย่างหลีกเลี่ยงไม่ได้ เมื่อองค์กรเรียนรู้วิธีมองเห็นและแก้ไขปัญหาอย่างมีประสิทธิภาพ พวกเขาจำเป็นต้องลดเกณฑ์ของสิ่งที่ถือเป็นปัญหาเพื่อที่จะเรียนรู้ต่อไป ในการทำเช่นนี้ เราพยายามขยายสัญญาณความล้มเหลวที่อ่อน (weak failure signals) ตัวอย่างเช่น ตามที่อธิบายไว้ใน บทที่ 4 เมื่อ Alcoa สามารถลดอัตราการเกิดอุบัติเหตุในที่ทำงานจนไม่ใช่เรื่องปกติอีกต่อไป Paul O'Neill ซีอีโอของ Alcoa เริ่มรับการแจ้งเตือนเกี่ยวกับเหตุการณ์เฉียดอุบัติเหตุ (near-misses) นอกเหนือจากอุบัติเหตุจริงในที่ทำงาน 20
Dr. Spear สรุปความสำเร็จของ O'Neill ที่ Alcoa โดยเขียนว่า "แม้ว่าจะเริ่มต้นด้วยการมุ่งเน้นไปที่ปัญหาด้านความปลอดภัยในที่ทำงาน แต่ในไม่ช้าก็พบว่าปัญหาด้านความปลอดภัยสะท้อนให้เห็นถึงความไม่รู้ในกระบวนการ (process ignorance) และความไม่รู้นี้จะแสดงออกในปัญหาอื่นๆ เช่น คุณภาพ ความตรงต่อเวลา และผลผลิตเทียบกับของเสีย" 21
เมื่อเราทำงานในระบบที่ซับซ้อน ความจำเป็นในการขยายสัญญาณความล้มเหลวที่อ่อนเป็นสิ่งสำคัญอย่างยิ่งในการหลีกเลี่ยงความล้มเหลวที่ร้ายแรง วิธีการที่ NASA จัดการกับสัญญาณความล้มเหลวในยุคกระสวยอวกาศเป็นตัวอย่างที่ชัดเจน ในปี 2003 สิบหกวันหลังจากภารกิจกระสวยอวกาศ Columbia เริ่มขึ้น มันก็ระเบิดขณะกลับเข้าสู่ชั้นบรรยากาศของโลก ปัจจุบันเราทราบแล้วว่าชิ้นส่วนของโฟมฉนวนได้หลุดออกจากถังเชื้อเพลิงภายนอกระหว่างการปล่อยยาน
อย่างไรก็ตาม ก่อนที่ Columbia จะกลับเข้าสู่ชั้นบรรยากาศ วิศวกรระดับกลางของ NASA สองสามคนได้รายงานเหตุการณ์นี้ แต่เสียงของพวกเขาไม่ได้รับการรับฟัง พวกเขาสังเกตเห็นแผ่นโฟมกระแทกบนจอวิดีโอระหว่างการประชุมทบทวนหลังการปล่อยยานและแจ้งให้ผู้บริหารของ NASA ทราบทันที แต่พวกเขากลับถูกบอกว่าปัญหาเศษโฟมไม่ใช่เรื่องใหม่ การหลุดร่อนของโฟมเคยสร้างความเสียหายให้กับกระสวยอวกาศในการปล่อยยานครั้งก่อนๆ แต่ไม่เคยทำให้เกิดอุบัติเหตุ มันถูกมองว่าเป็นปัญหาการบำรุงรักษาและไม่ได้ดำเนินการใดๆ จนกระทั่งสายเกินไป 22
Michael Roberto, Richard M. J. Bohmer, และ Amy C. Edmondson เขียนในบทความปี 2006 สำหรับ Harvard Business Review ว่าวัฒนธรรมของ NASA มีส่วนทำให้เกิดปัญหานี้อย่างไร พวกเขาอธิบายว่าโดยทั่วไปแล้วองค์กรถูกจัดโครงสร้างในหนึ่งในสองรูปแบบ: แบบ standardized model ซึ่งกิจวัตรและระบบควบคุมทุกอย่าง รวมถึงการปฏิบัติตามกำหนดเวลาและงบประมาณอย่างเคร่งครัด หรือแบบ experimental model ซึ่งทุกวัน ทุกการฝึกซ้อม และทุกข้อมูลใหม่ๆ ถูกประเมินและถกเถียงกันในวัฒนธรรมที่คล้ายกับห้องปฏิบัติการวิจัยและพัฒนา (R&D) 23
พวกเขาสังเกตว่า "องค์กรประสบปัญหาเมื่อพวกเขาใช้กรอบความคิดที่ผิดกับองค์กร [ซึ่งกำหนดว่าพวกเขาตอบสนองต่อ ภัยคุกคามที่ไม่ชัดเจน (ambiguous threats) หรือในศัพท์ของหนังสือเล่มนี้ สัญญาณความล้มเหลวที่อ่อน (weak failure signals) อย่างไร] ... ในช่วงทศวรรษ 1970 NASA ได้สร้างวัฒนธรรมของการกำหนดมาตรฐานที่แข็งทื่อ โดยนำเสนอต่อรัฐสภาว่ากระสวยอวกาศเป็นยานอวกาศที่ราคาถูกและใช้ซ้ำได้" 24
NASA ให้ความสำคัญกับการปฏิบัติตามกระบวนการที่เข้มงวดแทนที่จะใช้ experimental model ซึ่งข้อมูลทุกชิ้นต้องถูกประเมินตามความเป็นจริงโดยไม่มีอคติ การไม่มีการเรียนรู้อย่างต่อเนื่องและการทดลองส่งผลร้ายแรง ผู้เขียนสรุปว่าวัฒนธรรมและกรอบความคิดต่างหากที่สำคัญ ไม่ใช่แค่ "ความระมัดระวัง"—ดังที่พวกเขาเขียน "ความระมัดระวังเพียงอย่างเดียวไม่สามารถป้องกันภัยคุกคามที่ไม่ชัดเจน [สัญญาณความล้มเหลวที่อ่อน] ไม่ให้กลายเป็นความล้มเหลวที่มีค่าใช้จ่ายสูง (และบางครั้งก็เป็นโศกนาฏกรรม)" 25
งานของเราใน value stream ด้านเทคโนโลยี เช่นเดียวกับการเดินทางในอวกาศ ควรถูกมองว่าเป็นความพยายามเชิงทดลองโดยพื้นฐานและจัดการในลักษณะนั้น งานทั้งหมดที่เราทำคือสมมติฐานที่อาจมีความสำคัญและเป็นแหล่งของข้อมูล ไม่ใช่การประยุกต์ใช้และการตรวจสอบแนวปฏิบัติในอดีตแบบเป็นกิจวัตร แทนที่จะปฏิบัติต่องานด้านเทคโนโลยีเป็นงานที่ได้มาตรฐานทั้งหมด ซึ่งเรามุ่งมั่นเพื่อการปฏิบัติตามกระบวนการ เราต้องค้นหาสัญญาณความล้มเหลวที่อ่อนลงเรื่อยๆ อย่างต่อเนื่อง เพื่อที่เราจะได้เข้าใจและจัดการระบบที่เราทำงานอยู่ได้ดีขึ้น
Redefine Failure and Encourage Calculated Risk-Taking (นิยามความล้มเหลวใหม่และส่งเสริมการกล้าเสี่ยงอย่างมีสติ)
ผู้นำขององค์กร ไม่ว่าจะโดยตั้งใจหรือไม่ตั้งใจ ก็จะตอกย้ำวัฒนธรรมและค่านิยมขององค์กรผ่านการกระทำของพวกเขา ผู้เชี่ยวชาญด้านการตรวจสอบ บัญชี และจริยธรรมสังเกตมานานแล้วว่า "น้ำเสียงจากเบื้องบน" (tone at the top) ทำนายความเป็นไปได้ของการทุจริตและการปฏิบัติที่ผิดจริยธรรมอื่นๆ เพื่อตอกย้ำวัฒนธรรมการเรียนรู้และการกล้าเสี่ยงอย่างมีสติของเรา เราต้องให้ผู้นำเน้นย้ำอย่างต่อเนื่องว่าทุกคนควรรู้สึกทั้งสบายใจและรับผิดชอบในการนำความล้มเหลวขึ้นมาเผยแพร่และเรียนรู้จากมัน
On failures, Roy Rapoport from Netflix observes, (ในเรื่องของความล้มเหลว Roy Rapoport จาก Netflix กล่าวไว้ว่า)
"สิ่งที่ 2014 State of DevOps Report พิสูจน์ให้ฉันเห็นคือองค์กร DevOps ที่มีประสิทธิภาพสูงจะล้มเหลวและทำผิดพลาดบ่อยกว่า ไม่เพียงแค่ว่าเรื่องนี้ไม่เป็นไร แต่มันเป็นสิ่งที่องค์กรต้องการ! คุณสามารถเห็นมันได้ในข้อมูล: ถ้าผู้ปฏิบัติงานที่มีประสิทธิภาพสูง deploy บ่อยกว่าสามสิบเท่าแต่มีอัตราความล้มเหลวในการเปลี่ยนแปลง (change failure rate) เพียงครึ่งเดียว แน่นอนว่าพวกเขามีความล้มเหลวมากกว่า... 26
"ฉันกำลังคุยกับเพื่อนร่วมงานเกี่ยวกับ outage ครั้งใหญ่ที่เพิ่งเกิดขึ้นที่ Netflix—มันเกิดจากความผิดพลาดที่โง่เขลาจริงๆ อันที่จริง มันเกิดจากวิศวกรคนเดียวกับที่ทำให้ Netflix ล่มสองครั้งในสิบแปดเดือนที่ผ่านมา แต่แน่นอนว่านี่คือคนที่เราจะไม่มีวันไล่ออก เพราะในสิบแปดเดือนเดียวกันนั้น วิศวกรคนนี้ได้พัฒนาสถานะการดำเนินงานและระบบอัตโนมัติของเราไม่ใช่แค่ก้าว แต่เป็นอวกาศ (light-years) งานนั้นทำให้เราสามารถทำ deployments ได้อย่างปลอดภัยทุกวัน และเขาก็ได้ดำเนินการ deployment ใน production จำนวนมหาศาลด้วยตัวเอง" 27
เขาสรุปว่า "DevOps ต้องยอมให้มีนวัตกรรมแบบนี้และความเสี่ยงที่ตามมาจากการที่คนทำผิดพลาด ใช่ คุณจะมี failures ใน production มากขึ้น แต่นั่นเป็นสิ่งที่ดีและไม่ควรถูกลงโทษ" 28
Inject Production Failures to Enable Resilience and Learning (ฉีดความล้มเหลวเข้าสู่ Production เพื่อสร้างความยืดหยุ่นและการเรียนรู้)
ดังที่เราเห็นในบทนำ การฉีดข้อบกพร่อง (faults) เข้าสู่สภาพแวดล้อม production (เช่น การใช้ Chaos Monkey) เป็นวิธีหนึ่งที่เราสามารถเพิ่มความยืดหยุ่นได้ ในส่วนนี้ เราจะอธิบายกระบวนการที่เกี่ยวข้องในการซักซ้อมและฉีดความล้มเหลวเข้าสู่ระบบของเราเพื่อยืนยันว่าเราออกแบบและวางสถาปัตยกรรมระบบได้ถูกต้อง เพื่อให้ความล้มเหลวเกิดขึ้นในวิธีที่เฉพาะเจาะจงและควบคุมได้ เราทำสิ่งนี้โดยการทดสอบอย่างสม่ำเสมอ (หรือต่อเนื่อง) เพื่อให้แน่ใจว่าระบบของเราล้มเหลวอย่างสง่างาม (fail gracefully)
ดังที่ Michael Nygard ผู้เขียนหนังสือ Release It! Design and Deploy Production-Ready Software ให้ความเห็นว่า "เช่นเดียวกับการสร้าง crumple zones ในรถยนต์เพื่อดูดซับแรงกระแทกและปกป้องผู้โดยสาร คุณสามารถตัดสินใจได้ว่าฟีเจอร์ใดของระบบที่ขาดไม่ได้ และสร้างโหมดความล้มเหลว (failure modes) ที่ทำให้รอยร้าวไม่ไปถึงฟีเจอร์เหล่านั้น ถ้าคุณไม่ออกแบบโหมดความล้มเหลวของคุณ คุณก็จะได้โหมดที่คาดเดาไม่ได้—และมักจะเป็นอันตราย—ตามที่มันเกิดขึ้น" 29
ความยืดหยุ่นต้องการให้เรากำหนดโหมดความล้มเหลวของเราก่อน จากนั้นจึงทำการทดสอบเพื่อให้แน่ใจว่าโหมดความล้มเหลวเหล่านี้ทำงานตามที่ออกแบบไว้ วิธีหนึ่งที่เราทำคือการฉีดข้อบกพร่องเข้าสู่สภาพแวดล้อม production และซักซ้อมความล้มเหลวขนาดใหญ่เพื่อให้เรามั่นใจว่าสามารถกู้คืนจากอุบัติเหตุได้เมื่อมันเกิดขึ้น โดยที่ไม่กระทบต่อลูกค้าของเราด้วยซ้ำ
เรื่องราวในปี 2012 เกี่ยวกับ Netflix และ Amazon AWS US-East outage ที่นำเสนอในตอนต้นของบทนี้เป็นเพียงตัวอย่างหนึ่ง ตัวอย่างที่น่าสนใจยิ่งกว่าของความยืดหยุ่นที่ Netflix คือระหว่าง "Great Amazon Reboot of 2014" เมื่อเซิร์ฟเวอร์เกือบ 10% ของทั้งฝูงบิน EC2 ของ Amazon ต้องถูกรีบูตเพื่อใช้แพตช์ความปลอดภัย Xen ฉุกเฉิน 30
ดังที่ Christos Kalantzis จาก Netflix Cloud Database Engineering เล่าว่า "เมื่อเราได้รับข่าวเกี่ยวกับการรีบูต EC2 ฉุกเฉิน เราตกใจมาก เมื่อเราได้รับรายชื่อว่ามี Cassandra nodes กี่ตัวที่จะได้รับผลกระทบ ฉันรู้สึกไม่สบายใจ" 31 แต่ Kalantzis กล่าวต่อว่า "แล้วฉันก็นึกถึงการฝึกซ้อม Chaos Monkey ทั้งหมดที่เราผ่านมา ปฏิกิริยาของฉันคือ 'เอาเลย!'" 32
อีกครั้งหนึ่ง ผลลัพธ์นั้นน่าทึ่งมาก จาก Cassandra nodes กว่า 2,700+ โหนดที่ใช้ใน production มี 218 โหนดถูกรีบูต และยี่สิบสองโหนดรีบูตไม่สำเร็จ ดังที่ Kalantzis และ Bruce Wong จาก Netflix Chaos Engineering เขียนไว้ว่า "Netflix ไม่มีการหยุดให้บริการ (downtime) เลยในช่วงสุดสัปดาห์นั้น การทดสอบความล้มเหลวซ้ำๆ และสม่ำเสมอ แม้แต่ในเลเยอร์ persistence [database] ควรเป็นส่วนหนึ่งของการวางแผนความยืดหยุ่นของทุกบริษัท ถ้า Cassandra ไม่ได้มีส่วนร่วมใน Chaos Monkey เรื่องราวนี้คงจบลงแตกต่างไปมาก" 33
ที่น่าประหลาดใจยิ่งกว่าคือ ไม่เพียงแต่ไม่มีใครที่ Netflix ทำงานแก้ไข incident ที่เกิดจาก Cassandra nodes ที่ล้มเหลว แต่ไม่มีใครอยู่ในออฟฟิศด้วยซ้ำ—พวกเขาอยู่ที่ฮอลลีวูดในงานเลี้ยงฉลองความสำเร็จในการซื้อกิจการ 34 นี่เป็นอีกตัวอย่างที่แสดงให้เห็นว่าการมุ่งเน้นความยืดหยุ่นในเชิงรุกมักหมายความว่าบริษัทสามารถจัดการกับเหตุการณ์ที่อาจก่อให้เกิดวิกฤตสำหรับองค์กรส่วนใหญ่ได้ในลักษณะที่เป็นกิจวัตรและธรรมดา ¶ (ดู ภาคผนวก 9 .)
Institute Game Days to Rehearse Failures (จัด Game Days เพื่อซักซ้อมความล้มเหลว)
ในส่วนนี้ เราจะอธิบายการซักซ้อมการกู้คืนจากภัยพิบัติเฉพาะที่เรียกว่า game days ซึ่งเป็นคำที่ได้รับความนิยมโดย Jesse Robbins หนึ่งในผู้ก่อตั้งชุมชน Velocity Conference และผู้ร่วมก่อตั้ง Chef ขณะอยู่ที่ Amazon Robbins รับผิดชอบในการสร้างโปรแกรมเพื่อรับประกันความพร้อมใช้งานของเว็บไซต์ และเป็นที่รู้จักภายในอย่างกว้างขวางในฐานะ "Master of Disaster" 36 แนวคิดของ game days มาจากศาสตร์ของ resilience engineering Robbins นิยาม resilience engineering ว่าเป็น "การออกแบบการฝึกซ้อมเพื่อเพิ่มความยืดหยุ่นผ่านการฉีดข้อบกพร่องขนาดใหญ่ในระบบที่สำคัญ" 37
Robbins สังเกตว่า "เมื่อใดก็ตามที่คุณออกแบบระบบในระดับใหญ่ สิ่งที่ดีที่สุดที่คุณหวังได้คือการสร้างแพลตฟอร์มซอฟต์แวร์ที่เชื่อถือได้บนส่วนประกอบที่เชื่อถือไม่ได้โดยสิ้นเชิง นั่นทำให้คุณอยู่ในสภาพแวดล้อมที่ความล้มเหลวที่ซับซ้อนเป็นทั้งสิ่งที่หลีกเลี่ยงไม่ได้และคาดเดาไม่ได้" 38
ดังนั้น เราต้องทำให้แน่ใจว่าบริการยังคงทำงานต่อไปได้เมื่อเกิดความล้มเหลว ไม่ว่าจะเกิดขึ้นที่ใดในระบบของเรา โดย ideally ไม่ต้องมีการจัดการวิกฤตหรือแม้แต่การแทรกแซงด้วยตนเอง ดังที่ Robbins พูดติดตลกว่า "บริการจะไม่ถูกทดสอบจริงๆ จนกว่าเราจะทำให้มันพังใน production" 39
เป้าหมายของเราสำหรับ game day คือการช่วยให้ทีมจำลองและซักซ้อมอุบัติเหตุเพื่อให้พวกเขามีโอกาสฝึกฝน ขั้นแรก เรากำหนดเหตุการณ์ภัยพิบัติ เช่น การจำลองการทำลาย data center ทั้งหมด ให้เกิดขึ้นในอนาคต จากนั้นเราให้เวลาแก่ทีมในการเตรียมตัว เพื่อกำจัด single points of failure ทั้งหมด และสร้างขั้นตอนการตรวจสอบ (monitoring) การ failover ที่จำเป็น ฯลฯ
ทีม game day ของเรากำหนดและดำเนินการฝึกซ้อม เช่น การทำ database failovers (เช่น จำลองความล้มเหลวของ database และมั่นใจว่า secondary database ทำงานได้) หรือการปิดการเชื่อมต่อเครือข่ายที่สำคัญเพื่อเปิดเผยปัญหาในกระบวนการที่กำหนดไว้ ปัญหาหรือความยากลำบากใดๆ ที่พบจะถูกระบุ แก้ไข และทดสอบอีกครั้ง
เมื่อถึงเวลาที่กำหนด เราจะดำเนินการทำให้เกิด outage ดังที่ Robbins อธิบายว่า ที่ Amazon พวกเขา "จะปิดระบบของ facilities จริงๆ—โดยไม่บอกล่วงหน้า—แล้วปล่อยให้ระบบล้มเหลวตามธรรมชาติ และ[ให้]ผู้คนดำเนินตามกระบวนการของพวกเขาไปตามทางที่มันนำไป" 40
การทำเช่นนี้จะเริ่มเปิดเผย ข้อบกพร่องแฝง (latent defects) ในระบบของเรา ซึ่งเป็นปัญหาที่จะปรากฏขึ้นก็ต่อเมื่อเราฉีดข้อบกพร่องเข้าสู่ระบบเท่านั้น Robbins อธิบายว่า "คุณอาจค้นพบว่าระบบ monitoring หรือ management บางอย่างที่สำคัญต่อกระบวนการกู้คืน ถูกปิดไปโดยอัตโนมัติอันเป็นส่วนหนึ่งของความล้มเหลวที่คุณจัดฉากขึ้น คุณอาจพบ single points of failure ที่คุณไม่รู้มาก่อนด้วยวิธีนั้น" 41 การฝึกซ้อมเหล่านี้จะถูกดำเนินการอย่างเข้มข้นและซับซ้อนมากขึ้นเรื่อยๆ โดยมีเป้าหมายเพื่อให้รู้สึกเหมือนเป็นเพียงส่วนหนึ่งของวันปกติ
การจัด game days ช่วยให้เราสร้างบริการที่ยืดหยุ่นมากขึ้นและมีความมั่นใจในระดับที่สูงขึ้นว่าเราสามารถกลับมาดำเนินงานได้เมื่อเกิดเหตุการณ์ไม่คาดฝัน รวมทั้งสร้างการเรียนรู้ที่มากขึ้นและองค์กรที่ยืดหยุ่นมากขึ้น
ตัวอย่างที่ยอดเยี่ยมของการจำลองภัยพิบัติคือ Disaster Recovery Program (DiRT) ของ Google Kripa Krishnan ซึ่งในขณะนั้นดำรงตำแหน่ง Technical Program Director ที่ Google ได้นำโปรแกรมนี้มากว่าเจ็ดปี ในช่วงเวลานั้น พวกเขาได้จำลองแผ่นดินไหวใน Silicon Valley ซึ่งส่งผลให้ทั้งวิทยาเขต Mountain View ถูกตัดการเชื่อมต่อจาก Google, data centers หลักประสบปัญหาการสูญเสียพลังงานทั้งหมด และแม้กระทั่งมนุษย์ต่างดาวโจมตีเมืองที่วิศวกรอาศัยอยู่ 42
ดังที่ Krishnan เขียนว่า "พื้นที่การทดสอบที่มักถูกมองข้ามคือกระบวนการทางธุรกิจและการสื่อสาร ระบบและกระบวนการเชื่อมโยงกันอย่างสูง และการแยกการทดสอบระบบออกจากการทดสอบกระบวนการทางธุรกิจนั้นไม่สมจริง: ความล้มเหลวของระบบธุรกิจจะส่งผลกระทบต่อกระบวนการทางธุรกิจ และในทางกลับกัน ระบบที่ทำงานได้ก็ไม่มีประโยชน์มากนักหากไม่มีบุคลากรที่เหมาะสม" 43
บทเรียนบางส่วนที่ได้รับระหว่างภัยพิบัติเหล่านี้รวมถึง: 44
• เมื่อการเชื่อมต่อขาดหาย การ failover ไปยังเวิร์กสเตชันของวิศวกรไม่ทำงาน
• วิศวกรไม่ทราบวิธีเข้าถึง conference call bridge หรือ bridge มีความจุเพียงห้าสิบคน หรือพวกเขาต้องการผู้ให้บริการ conference call รายใหม่ที่อนุญาตให้พวกเขาไล่วิศวกรที่เปิดเพลงรอสายให้ผู้เข้าร่วมประชุมทั้งหมดฟังออก
• เมื่อ data centers ใช้น้ำมันดีเซลสำหรับเครื่องกำเนิดไฟฟ้าสำรองหมด ไม่มีใครรู้ขั้นตอนการซื้อฉุกเฉินผ่านซัพพลายเออร์ ส่งผลให้มีคนใช้บัตรเครดิตส่วนตัวซื้อน้ำมันดีเซลมูลค่า 50,000 ดอลลาร์
การสร้างความล้มเหลวในสถานการณ์ที่ควบคุมได้ช่วยให้เราฝึกฝนและสร้าง playbooks ที่เราต้องการ หนึ่งในผลลัพธ์อื่นๆ ของ game days คือผู้คนรู้จริงๆ ว่าจะโทรหาใครและจะพูดคุยกับใคร—การทำเช่นนี้ทำให้พวกเขาพัฒนาความสัมพันธ์กับคนในแผนกอื่นๆ เพื่อให้สามารถทำงานร่วมกันระหว่างเกิดเหตุการณ์ เปลี่ยนการกระทำที่มีสติให้เป็นการกระทำที่ไม่รู้ตัวที่กลายเป็นกิจวัตร
CASE STUDY: NEW TO SECOND EDITION (กรณีศึกษา: เพิ่มเติมในฉบับพิมพ์ครั้งที่สอง)
Turning an Outage into a Powerful Learning Opportunity at CSG (2021) (เปลี่ยน Outage ให้เป็นโอกาสในการเรียนรู้ครั้งสำคัญที่ CSG (2021))
CSG คือผู้ให้บริการระบบดูแลลูกค้าและระบบเรียกเก็บเงิน (customer care and billing) แบบ SaaS ที่ใหญ่ที่สุดในอเมริกาเหนือ โดยมีสมาชิกมากกว่าหกสิบห้าล้านคนและเทคโนโลยีที่ครอบคลุมตั้งแต่ Java ไปจนถึง mainframe ที่ DevOps Enterprise Summit ในปี 2020 Erica Morrison รองประธานฝ่ายวิศวกรรมซอฟต์แวร์ ได้แบ่งปันเรื่องราวของ outage ' ที่เลวร้ายที่สุดของ CSG—ซึ่งเป็นผลมาจากความล้มเหลวของระบบที่ซับซ้อนที่ผลักดัน CSG ให้เกินขีดจำกัดของระบบตอบสนอง กระบวนการ และวัฒนธรรมของพวกเขา 45
แต่เมื่อเผชิญกับความยากลำบากนั้น พวกเขาสามารถพบโอกาสและใช้บทเรียนที่ได้เรียนรู้เพื่อปรับปรุงวิธีที่พวกเขาเข้าใจ ตอบสนอง และป้องกัน incident ต่างๆ ตั้งแต่แรก
เหตุการณ์ 2/4 Outage ตามที่ถูกเรียกในภายหลัง กินเวลานานสิบสามชั่วโมง มันเริ่มต้นอย่างกะทันหันและส่วนใหญ่ของผลิตภัณฑ์ของ CSG ไม่สามารถใช้งานได้ ในการประชุมครั้งแรกเมื่อ outage เริ่มต้นขึ้น ทีมงานกำลังแก้ปัญหาอย่างมืดบอดเพราะพวกเขามีปัญหาในการเข้าถึงเครื่องมือที่พวกเขาใช้ตามปกติ รวมถึงระบบ health monitoring และการเข้าถึงเซิร์ฟเวอร์ ด้วยจำนวนผู้ขาย (vendors) และลูกค้าที่เกี่ยวข้อง การประชุมครั้งแรกจึงวุ่นวายเป็นพิเศษ
ในท้ายที่สุด ต้องใช้เวลาหลายวันกว่าจะรู้ว่าเกิดอะไรขึ้นจริงๆ โดยการจำลอง outage ในห้องแล็บของพวกเขา ปัญหาเริ่มต้นจากการบำรุงรักษาเซิร์ฟเวอร์ตามปกติบน OS ที่แตกต่างจากเซิร์ฟเวอร์ส่วนใหญ่ที่พวกเขาใช้ เมื่อเซิร์ฟเวอร์นั้นรีบูต มันส่งแพ็กเก็ต LLDP ออกไปยังเครือข่าย เนื่องจากบั๊ก ซอฟต์แวร์เครือข่ายของ CSG ' จึงรับข้อมูลนั้นและตีความว่าเป็น spanning tree มันกระจายข้อมูลนั้นออกไปยังเครือข่าย และจากนั้นจึงถูกนำไปใช้โดย load balancer ของพวกเขา เนื่องจากการตั้งค่าที่ผิดพลาดใน load balancer ข้อมูลนี้จึงถูกกระจายซ้ำไปยังเครือข่าย ก่อให้เกิด network loop ทำให้เครือข่ายล่ม
ผลกระทบที่ตามมารุนแรง จำนวนลูกค้าที่โกรธแค้นทำให้ฝ่ายบริหารต้องเปลี่ยนโฟกัสจากงานที่วางแผนไว้ (โครงการเชิงกลยุทธ์ ฯลฯ) ไปที่ outage นี้เพียงอย่างเดียว ทั่วทั้งบริษัท ยังมีความรู้สึกสูญเสียและเสียใจอย่างมากที่ทำให้ลูกค้าผิดหวังอย่างหนัก ขวัญกำลังใจต่ำมาก มีคำพูดที่ทำร้ายจิตใจ เช่น "DevOps ใช้ไม่ได้ผล"
CSG รู้ว่าพวกเขาต้องการตอบสนองต่อความล้มเหลวนี้แตกต่างออกไป พวกเขาจำเป็นต้องเพิ่มการเรียนรู้ให้สูงสุดในขณะเดียวกันก็ลดโอกาสที่ incident แบบนี้จะเกิดขึ้นอีก ขั้นตอนแรกของพวกเขาคือการวิเคราะห์ incident
การวิเคราะห์ incident มาตรฐานของพวกเขาเป็นกระบวนการที่มีโครงสร้างเพื่อช่วยให้พวกเขาเข้าใจสิ่งที่เกิดขึ้นและระบุโอกาสในการปรับปรุง พวกเขาทำสิ่งนี้โดยการทำความเข้าใจไทม์ไลน์ของ incident; การถาม " เกิดอะไรขึ้น? เราจะตรวจจับได้เร็วกว่านี้ได้อย่างไร? เราจะกู้คืนได้เร็วกว่านี้ได้อย่างไร? อะไรที่ดำเนินไปได้ด้วยดี? " การทำความเข้าใจพฤติกรรมของระบบ และการรักษาวัฒนธรรมที่ไม่กล่าวโทษ (blameless culture) และหลีกเลี่ยงการชี้หน้าตำหนิ
เนื่องจาก incident นี้ พวกเขายังรู้ว่าพวกเขาจำเป็นต้องยกระดับเกมของพวกเขา พวกเขาติดต่อ Dr. Richard Cook และ John Allspaw จาก Adaptive Capacity Labs เพื่อวิเคราะห์ incident ผ่านการสัมภาษณ์และการวิจัยอย่างเข้มข้นเป็นเวลาสองสัปดาห์ พวกเขาได้รับความเข้าใจที่ละเอียดถี่ถ้วนมากขึ้นเกี่ยวกับเหตุการณ์ และโดยเฉพาะอย่างยิ่ง ได้เรียนรู้มุมมองที่แตกต่างของคนที่ทำงานเกี่ยวกับ outage ในครั้งนั้น
จากการทบทวนอย่างเข้มข้น (intensive retrospective) นี้ พวกเขาได้สร้างโปรแกรมปรับปรุงการดำเนินงาน (operation improvement program) โดยยึดหลัก Incident Command System พวกเขาแบ่งโปรแกรมออกเป็นสี่หมวดหมู่: การตอบสนองต่อ incident (incident response), ความน่าเชื่อถือของเครื่องมือ (tool reliability), ความยืดหยุ่นของ data center/แพลตฟอร์ม (data center/platform resiliency), และความน่าเชื่อถือของแอปพลิเคชัน (application reliability)
แม้กระทั่งก่อนที่ทั้งองค์กรจะผ่านการฝึกอบรมสำหรับกระบวนการจัดการ incident ใหม่ของพวกเขา ผู้คนเริ่มเห็นการปรับปรุงที่สังเกตได้ในการดำเนินการประชุมเมื่อเกิด outage: ความรกในการประชุมถูกกำจัดออกไป; รายงานสถานะมีจังหวะที่แน่นอนและสม่ำเสมอ; และการมี LNO (liaison officer) ช่วยหลีกเลี่ยงการขัดจังหวะในการประชุม incident
การปรับปรุงครั้งใหญ่ถัดไปคือความรู้สึกในการควบคุมความโกลาหล (sense of control over chaos) เพียงแค่การมีจังหวะและรูปแบบที่คาดเดาได้ช่วยให้ทุกคนรู้สึกมั่นใจและควบคุมสถานการณ์ได้มากขึ้น นอกจากนี้ยังช่วยให้กิจกรรมต่างๆ ดำเนินไปพร้อมกันได้จนกว่าจะถึงเวลาที่กำหนดสำหรับการอัปเดตสถานะ ทำให้กิจกรรมนั้นดำเนินไปโดยไม่ถูกรบกวน
นอกจากนี้ การตัดสินใจยังได้รับการปรับปรุงจากระบบเก่า โดยการให้ผู้บัญชาการ incident (incident commander) มีอำนาจสั่งการและอำนาจที่ชัดเจน เพื่อไม่ให้เกิดข้อสงสัยว่าใครเป็นผู้ตัดสินใจ
ปัจจุบัน CSG มีความสามารถในการจัดการ incident ที่แข็งแกร่งยิ่งขึ้นในระดับองค์กร พวกเขาได้ตอกย้ำและขยายบรรทัดฐานทางวัฒนธรรมในด้านความปลอดภัย และที่สำคัญที่สุด พวกเขาได้นำระบบการจัดการ incident มาใช้ที่เปลี่ยนวิธีการดำเนินการประชุมเมื่อเกิด outage
ในกรณีศึกษา blameless post-mortem (retrospective) ทำให้ CSG ปรับปรุงวิธีการจัดการ incident ของพวกเขาอย่างสิ้นเชิง พวกเขานำสิ่งที่เรียนรู้ไปปรับใช้กับวิธีการทำงานของพวกเขาโดยตรง เปลี่ยนแปลงวัฒนธรรมของพวกเขา และไม่โทษบุคคลหรือทีมใดทีมหนึ่ง
Conclusion (บทสรุป)
เพื่อสร้าง just culture ที่ทำให้เกิดการเรียนรู้ขององค์กร เราต้องเปลี่ยนบริบทของสิ่งที่เรียกว่าความล้มเหลว เมื่อจัดการอย่างถูกต้อง ข้อผิดพลาดที่มีอยู่ในระบบที่ซับซ้อนสามารถสร้างสภาพแวดล้อมการเรียนรู้แบบพลวัตที่ผู้มีส่วนได้ส่วนเสียทุกคนรู้สึกปลอดภัยพอที่จะเสนอความคิดและการสังเกต และที่ซึ่งกลุ่มต่างๆ สามารถฟื้นตัวจากโครงการที่ไม่ได้ผลตามที่คาดหวังได้ง่ายขึ้น
ทั้ง retrospectives และการฉีดความล้มเหลวใน production ต่างก็ตอกย้ำวัฒนธรรมที่ทุกคนควรรู้สึกทั้งสบายใจและรับผิดชอบในการนำความล้มเหลวขึ้นมาเผยแพร่และเรียนรู้จากมัน อันที่จริง เมื่อเราลดจำนวนอุบัติเหตุลงได้มากพอ เราก็ลดระดับความทนทานของเราลงเพื่อที่จะเรียนรู้ต่อไป ดังที่ Peter Senge กล่าวไว้ "ข้อได้เปรียบทางการแข่งขันที่ยั่งยืนเพียงอย่างเดียวคือความสามารถขององค์กรในการเรียนรู้ได้เร็วกว่าคู่แข่ง" 46
ในเดือนมกราคม 2013 ที่งาน re:Invent, James Hamilton, VP และ Distinguished Engineer ของ Amazon Web Services กล่าวว่าภูมิภาค US-East มี data centers มากกว่าสิบแห่งเพียงลำพัง และเสริมว่า data center ทั่วไปมีระหว่างห้าหมื่นถึงแปดหมื่นเซิร์ฟเวอร์ จากการคำนวณนี้ EC2 outage ในปี 2011 ส่งผลกระทบต่อลูกค้าบนเซิร์ฟเวอร์มากกว่าห้าแสนเครื่อง 4 | |
ดูบทความของ Martin Fowler ' เกี่ยวกับ circuit breakers สำหรับข้อมูลเพิ่มเติม: https://martinfowler.com/bliki/CircuitBreaker.html . | |
แนวปฏิบัตินี้ยังถูกเรียกว่า blameless post-incident reviews รวมถึง post-event retrospectives นอกจากนี้ยังมีความคล้ายคลึงกับ retrospectives ทั่วไปที่เป็นส่วนหนึ่งของแนวปฏิบัติการพัฒนาแบบ iterative และ Agile หลายๆ แนวทาง | |
เราอาจเลือกขยายปรัชญาของ transparent uptime ไปยังรายงาน post-mortem ของเรา และนอกเหนือจากการทำ dashboard บริการที่เปิดเผยต่อสาธารณะแล้ว เราอาจเลือกเผยแพร่ (หรืออาจปรับแก้) การประชุม post-mortem สู่สาธารณะด้วย ตัวอย่าง post-mortems สาธารณะที่ได้รับการยกย่องอย่างกว้างขวางรวมถึงโพสต์โดยทีม Google App Engine หลังจาก outage ครั้งใหญ่ในปี 2010 รวมถึง post-mortem ของ Amazon DynamoDB outage ในปี 2015 ที่น่าสนใจคือ Chef เผยแพร่บันทึกการประชุม post-mortem บนบล็อกของพวกเขา รวมถึงวิดีโอที่บันทึกการประชุม post-mortem จริง 15 | |
รูปแบบสถาปัตยกรรมเฉพาะที่พวกเขานำมาใช้รวมถึงการ fail fasts (การตั้ง timeouts ที่รุนแรงเพื่อให้ component ที่ล้มเหลวไม่ทำให้ทั้งระบบชะงัก), fallbacks (การออกแบบให้แต่ละ feature degrade หรือ fall back ไปสู่การแสดงผลที่มีคุณภาพต่ำลง), และ feature removal (การลบ feature ที่ไม่สำคัญเมื่อทำงานช้าจากหน้าใดหน้าที่หนึ่งเพื่อป้องกันไม่ให้กระทบต่อประสบการณ์ของสมาชิก) ตัวอย่างที่น่าทึ่งอีกประการของความยืดหยุ่นที่ทีม Netflix สร้างขึ้นนอกเหนือจากการรักษาความต่อเนื่องทางธุรกิจระหว่าง AWS outage คือ Netflix ใช้เวลานานกว่าหกชั่วโมงใน AWS outage ก่อนที่จะประกาศเป็น Sev 1 incident โดยสันนิษฐานว่าบริการ AWS จะกลับมาในที่สุด หลังจากหกชั่วโมงของ outage พวกเขาจึงเริ่มดำเนินการตามขั้นตอนความต่อเนื่องทางธุรกิจ 35 |