บันทึก. แปล: เรายินดีที่จะแบ่งปันการแปลเนื้อหาที่ยอดเยี่ยมจากผู้เผยแพร่เทคโนโลยีอาวุโสจาก AWS - Adrian Hornsby พูดง่ายๆ ก็คือ เขาอธิบายถึงความสำคัญของการทดลองเพื่อลดผลกระทบของความล้มเหลวในระบบไอที คุณคงเคยได้ยินเกี่ยวกับ Chaos Monkey แล้ว (หรือแม้แต่ใช้วิธีแก้ไขปัญหาที่คล้ายกัน)? ทุกวันนี้ แนวทางในการสร้างเครื่องมือดังกล่าวและการนำไปใช้ในบริบทที่กว้างขึ้นนั้นดำเนินการภายใต้กรอบของกิจกรรมที่เรียกว่าวิศวกรรมความโกลาหล อ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ในบทความนี้
“แต่เบื้องหลังความงามทั้งหมดนี้ เต็มไปด้วยความสับสนวุ่นวายและความบ้าคลั่ง” —แทนเนอร์ วอลลิง
นักดับเพลิง. ผู้เชี่ยวชาญที่ผ่านการฝึกอบรมมาอย่างดีเหล่านี้เสี่ยงชีวิตทุกวันเพื่อต่อสู้กับไฟ คุณรู้ไหมว่าคุณต้องใช้เวลาอย่างน้อย 600 ชั่วโมงในการฝึกอบรมก่อนที่จะมาเป็นนักดับเพลิง? และนี่เป็นเพียงจุดเริ่มต้น ตามรายงาน นักดับเพลิงจะฝึกอบรมเวลาทำงานมากถึง 80%
ทำไม?
เมื่อนักดับเพลิงกำลังต่อสู้กับไฟจริง เขาต้องการสิ่งที่เหมาะสม ปรีชา. เพื่อพัฒนามัน คุณต้องฝึกฝนชั่วโมงแล้วชั่วโมงเล่า วันแล้ววันเล่า อย่างที่พวกเขาพูดกันว่าการฝึกฝนทำให้เกิดสิ่งมหัศจรรย์
“ดูเหมือนพวกเขาจะเจาะเข้าไปในแก่นแท้ของไฟ เหมือนกับดร.ฟิลเรื่องเปลวไฟ” —
บันทึก. แปล: Phillip Calvin "Phil" McGraw เป็นนักจิตวิทยา นักเขียน และพิธีกรชาวอเมริกันของรายการโทรทัศน์ชื่อดังอย่าง Dr. Phil ซึ่งพิธีกรนำเสนอวิธีแก้ปัญหาแก่ผู้เข้าร่วม
กาลครั้งหนึ่งในซีแอตเทิล
ต้นปี 2000 ซึ่งดำรงตำแหน่งที่ Amazon โดยมีชื่ออย่างเป็นทางการ ปรมาจารย์แห่งภัยพิบัติก่อตั้งและเป็นผู้นำโครงการ GameDay มันขึ้นอยู่กับประสบการณ์ของเขาในฐานะนักดับเพลิง GameDay มีวัตถุประสงค์เพื่อทดสอบ ฝึกอบรม และเตรียมระบบ ซอฟต์แวร์ และบุคลากรต่างๆ ของ Amazon สำหรับสถานการณ์วิกฤตที่อาจเกิดขึ้น
เช่นเดียวกับที่นักดับเพลิงพัฒนาสัญชาตญาณในการต่อสู้กับไฟ เจสซีต้องการช่วยทีมของเขาพัฒนาสัญชาตญาณในการรับมือกับเหตุการณ์ภัยพิบัติขนาดใหญ่
"GameDay: การสร้างความยืดหยุ่นผ่านการทำลายล้าง" - Jesse Robbins
ได้รับการออกแบบมาเพื่อเพิ่มความเสถียรของไซต์ค้าปลีกของ Amazon โดยจงใจนำข้อผิดพลาดเข้าสู่ระบบที่สำคัญ
GameDay เริ่มต้นด้วยการประกาศต่อทั้งบริษัทว่ามีการวางแผนฝึกซ้อม - บางครั้งก็ค่อนข้างใหญ่ เช่น การปิดศูนย์ข้อมูลทั้งหมด มีการให้รายละเอียดเพียงเล็กน้อยเกี่ยวกับการหยุดทำงานตามแผน และทีมงานมีเวลาหลายเดือนในการเตรียมการ วัตถุประสงค์หลักของการฝึกซ้อมคือเพื่อทดสอบว่าพนักงานสามารถรับมือกับวิกฤติในท้องถิ่นและแก้ไขผลที่ตามมาได้อย่างรวดเร็วหรือไม่
ในระหว่างการฝึกหัดเหล่านี้ ได้มีการใช้เครื่องมือและกระบวนการเฉพาะ เช่น การติดตาม การแจ้งเตือน และการโทรด่วน เพื่อวิเคราะห์และระบุข้อผิดพลาดในขั้นตอนการตอบสนองต่อเหตุการณ์ ปรากฎว่า GameDay สามารถระบุปัญหาทางสถาปัตยกรรมคลาสสิกได้อย่างดีเยี่ยม บางครั้งก็เป็นไปได้ที่จะตรวจพบสิ่งที่เรียกว่า “ข้อบกพร่องแฝง” ซึ่งเป็นปัญหาที่แสดงออกเนื่องจากลักษณะเฉพาะของเหตุการณ์ ตัวอย่างเช่น ระบบการจัดการเหตุการณ์ที่สำคัญต่อกระบวนการกู้คืนล้มเหลวเนื่องจากผลข้างเคียงที่ไม่คาดคิดที่เกิดจากปัญหาที่มนุษย์สร้างขึ้น
เมื่อบริษัทเติบโตขึ้น รัศมีการระเบิดตามทฤษฎีของ GameDay ก็ขยายออกไป ท้ายที่สุดแล้ว การฝึกหัดเหล่านี้ก็ถูกยกเลิกไปเพราะความเสียหายที่อาจเกิดขึ้นกับบริษัทหากสิ่งต่างๆ ไม่เป็นไปตามแผนที่วางไว้มีมากเกินไป นับตั้งแต่นั้นเป็นต้นมา โปรแกรมนี้ก็ได้เริ่มลดระดับลงเป็นชุดการทดลองที่แตกต่างกันและไม่ส่งผลกระทบต่อธุรกิจเพื่อฝึกอบรมพนักงานในสถานการณ์วิกฤติ ฉันจะไม่ลงรายละเอียดเกี่ยวกับการทดลองในบทความนี้ แต่ฉันจะทำอย่างนั้นในอนาคต ครั้งนี้ ฉันต้องการพูดคุยเกี่ยวกับแนวคิดสำคัญที่เป็นรากฐานของ GameDay: วิศวกรรมความน่าเชื่อถือ (วิศวกรรมความยืดหยุ่น)หรือที่รู้จักกันในชื่อวิศวกรรมความโกลาหล ().
การเพิ่มขึ้นของลิง
คุณคงเคยได้ยินเกี่ยวกับ Netflix ซึ่งเป็นผู้ให้บริการเนื้อหาวิดีโอออนไลน์ Netflix เริ่มย้ายจากศูนย์ข้อมูลของตนเองไปยัง AWS Cloud ในเดือนสิงหาคม 2008 การย้ายดังกล่าวได้รับแจ้งจากฐานข้อมูลเสียหายร้ายแรงซึ่งทำให้การจัดส่งดีวีดีล่าช้าไปสามวัน (ใช่แล้ว Netflix เริ่มส่งภาพยนตร์ทางไปรษณีย์หอยทาก) การโยกย้ายไปยังระบบคลาวด์ได้รับแรงผลักดันจากความจำเป็นในการจัดการกับโหลดการสตรีมที่สูงขึ้นมาก เช่นเดียวกับความปรารถนาที่จะย้ายออกจากสถาปัตยกรรมขนาดใหญ่และไปสู่ไมโครเซอร์วิสที่สามารถปรับขนาดได้อย่างง่ายดายโดยขึ้นอยู่กับจำนวนผู้ใช้และขนาดของทีมวิศวกร ฝั่งผู้บริโภคของบริการสตรีมมิ่งย้ายไปยัง AWS ก่อน ระหว่างปี 2010 ถึง 2011 ตามด้วยไอทีระดับองค์กรและโครงสร้างอื่นๆ ทั้งหมด ศูนย์ข้อมูลของ Netflix ปิดตัวลงในปี 2016 บริษัทวัดความพร้อมเป็นอัตราส่วนของจำนวนความพยายามที่ประสบความสำเร็จในการเปิดตัวภาพยนตร์ต่อจำนวนทั้งหมด แทนที่จะเป็นการเปรียบเทียบเวลาทำงานและการหยุดทำงานอย่างง่ายๆ และมุ่งมั่นที่จะบรรลุตัวเลข 0,9999 ในแต่ละภูมิภาคเป็นรายไตรมาส ( มักจะประสบความสำเร็จ) สถาปัตยกรรมระดับโลกของ Netflix ครอบคลุมสามภูมิภาค AWS ดังนั้นหากเกิดปัญหาในภูมิภาคใดภูมิภาคหนึ่ง บริษัทก็สามารถเปลี่ยนเส้นทางผู้ใช้ไปยังผู้อื่นได้
ฉันจะพูดคำพูดหนึ่งที่ฉันชื่นชอบอีกครั้ง:
“การหยุดชะงักเป็นสิ่งที่หลีกเลี่ยงไม่ได้ ในที่สุดระบบใดๆ ก็ตามก็จะล่มสลายไปตามกาลเวลา” — แวร์เนอร์ โวเกลส์
ในความเป็นจริง ความล้มเหลวในระบบแบบกระจาย โดยเฉพาะความล้มเหลวในสเกลใหญ่เป็นสิ่งที่หลีกเลี่ยงไม่ได้ แม้แต่ในระบบคลาวด์ก็ตาม อย่างไรก็ตาม AWS cloud และความซ้ำซ้อนดั้งเดิม—โดยเฉพาะอย่างยิ่ง ซึ่งสร้างขึ้นช่วยให้ทุกคนสามารถออกแบบบริการที่มีความน่าเชื่อถือสูงได้
การใช้หลักการซ้ำซ้อน (ความซ้ำซ้อน) และฟังก์ชันการทำงานลดลงอย่างค่อยเป็นค่อยไป (การเสื่อมถอยอย่างสง่างาม),เน็ตฟลิกซ์ โดยไม่ส่งผลกระทบต่อผู้ใช้ปลายทาง
ตั้งแต่เริ่มต้น Netflix ยึดถือหลักสถาปัตยกรรมที่เข้มงวดที่สุด แอปพลิเคชันแรกๆ ที่พวกเขาปรับใช้บน AWS คือแอปพลิเคชันของพวกเขา — เพื่อรองรับไมโครเซอร์วิสไร้สัญชาติที่ปรับขนาดอัตโนมัติ กล่าวอีกนัยหนึ่ง อินสแตนซ์ใดๆ ก็ตามสามารถหยุดและแทนที่ได้โดยอัตโนมัติโดยไม่สูญเสียสถานะ Chaos Monkey ทำให้แน่ใจว่าไม่มีใครละเมิดหลักการนี้
บันทึก. แปล: อย่างไรก็ตามสำหรับ Kubernetes มีอะนาล็อกที่เรียกว่า ซึ่งการพัฒนาดูเหมือนจะหยุดลงในเดือนมีนาคมปีนี้
Netflix มีกฎอีกข้อหนึ่งที่กระจายแต่ละบริการไปยังโซนความพร้อมใช้งานสามโซน ควรทำงานต่อไปหากมีเพียงสองรายการเท่านั้น เพื่อให้แน่ใจว่ากฎนี้เป็นไปตาม ปิดการใช้งานโซนความพร้อมใช้งาน ในระดับโลกมากขึ้น สามารถปิดภูมิภาค AWS ทั้งหมดเพื่อยืนยันว่าผู้ใช้ Netflix ทั้งหมดสามารถให้บริการจากภูมิภาคใดก็ได้ในสามภูมิภาค และทำการทดสอบที่ครอบคลุมเหล่านี้ทุกๆ สองสามสัปดาห์ในการผลิตเพื่อให้แน่ใจว่าไม่มีสิ่งใดหลุดลอดผ่านรอยแตกร้าวไปได้
ในที่สุด Netflix ยังได้พัฒนาเน้นมากขึ้น เพื่อช่วยระบุปัญหาเกี่ยวกับไมโครเซอร์วิสและสถาปัตยกรรมการจัดเก็บข้อมูล คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับเทคนิคเหล่านี้ได้ในหนังสือ Chaos Engineering ซึ่งฉันแนะนำให้ทุกคนที่สนใจในหัวข้อนี้
“ด้วยการดำเนินการทดลองเป็นประจำเพื่อจำลองการหยุดทำงานในระดับภูมิภาค เราจึงสามารถระบุข้อบกพร่องของระบบต่างๆ ได้ตั้งแต่เนิ่นๆ และแก้ไขได้” —
วันนี้หลักการของวิศวกรรมความสับสนวุ่นวาย ; พวกเขาได้รับคำจำกัดความต่อไปนี้:
“วิศวกรรมความโกลาหลเป็นแนวทางที่เกี่ยวข้องกับการทดลองระบบการผลิตเพื่อให้มั่นใจว่าจะสามารถทนต่อการรบกวนต่างๆ ที่เกิดขึ้นระหว่างการปฏิบัติงานได้” —
อย่างไรก็ตามในตัวเขา ทุ่มเทให้กับวิศวกรรมความโกลาหล อดีตผู้สร้างสถาปัตยกรรมระบบคลาวด์ของ Netflix ซึ่งช่วยให้บริษัทเปลี่ยนไปใช้โครงสร้างพื้นฐานแบบคลาวด์ทั้งหมด ได้นำเสนออีกทางเลือกหนึ่งของวิศวกรรมความสับสนวุ่นวาย ในความคิดของฉันมันแม่นยำและเป็นที่ยอมรับมากกว่า:
“วิศวกรรมความโกลาหลเป็นการทดลองที่ออกแบบมาเพื่อบรรเทาผลกระทบของความล้มเหลว”
ที่จริงแล้ว เรารู้ว่าความล้มเหลวเกิดขึ้นตลอดเวลา เมื่อตอบสนองอย่างเหมาะสมแล้ว ก็ไม่ควรส่งผลกระทบต่อผู้ใช้ เป้าหมายหลักของวิศวกรรมความโกลาหลคือการค้นหาปัญหาที่ไม่ได้รับการแก้ไขอย่างเหมาะสม
เงื่อนไขที่จำเป็นในการสร้างความวุ่นวาย
ก่อนที่คุณจะเริ่มวิศวกรรมความสับสนวุ่นวาย ตรวจสอบให้แน่ใจว่าคุณได้ทำงานที่จำเป็นทั้งหมดเพื่อรับรองความยั่งยืนในทุกระดับขององค์กร การสร้างระบบที่ทนทานต่อข้อผิดพลาดไม่ได้เป็นเพียงเกี่ยวกับซอฟต์แวร์เท่านั้น มันเริ่มต้นที่ระดับ โครงสร้างพื้นฐาน, แพร่กระจายต่อไป เครือข่ายและข้อมูล,ส่งผลต่อโครงสร้าง การใช้งานและครอบคลุมในที่สุด ผู้คนและวัฒนธรรม. ฉันเคยเขียนไว้มากมายในอดีตเกี่ยวกับโมเดลความยืดหยุ่นและความล้มเหลว (, , и ) และฉันจะไม่เน้นไปที่เรื่องนี้ในตอนนี้ แต่ก็ทำไม่ได้หากไม่มีการแจ้งเตือนเล็กๆ น้อยๆ
องค์ประกอบที่จำเป็นบางประการก่อนที่จะนำความวุ่นวายเข้าสู่ระบบ (รายการไม่ครบถ้วนสมบูรณ์)
ขั้นตอนของวิศวกรรมความโกลาหล
สิ่งสำคัญคือต้องเข้าใจว่าแก่นแท้ของวิศวกรรมความโกลาหล ไม่ คือการปล่อยลิงเข้าป่าปล่อยให้มันทำลายทุกสิ่งอย่างไร้จุดหมาย จุดประสงค์ของระเบียบวินัยนี้คือการทำลายองค์ประกอบบางอย่างของระบบในสภาพแวดล้อมที่มีการควบคุม ผ่านการทดสอบที่ออกแบบมาอย่างดี เพื่อดูว่าแอปพลิเคชันของคุณสามารถทนต่อสภาวะปั่นป่วนได้หรือไม่
ในการดำเนินการนี้ คุณจะต้องปฏิบัติตามกระบวนการที่กำหนดไว้อย่างชัดเจนและเป็นทางการตามที่ระบุไว้ในรูปด้านล่าง สามารถช่วยให้คุณเปลี่ยนจากการทำความเข้าใจสถานะคงที่ของระบบของคุณไปสู่การกำหนดสมมติฐาน การทดสอบ และสุดท้ายคือการวิเคราะห์ประสบการณ์ที่ได้รับจากการทดลอง และปรับปรุงเสถียรภาพของระบบเอง
ขั้นตอนของวิศวกรรมความโกลาหล
1. สถานะที่มั่นคง
องค์ประกอบที่สำคัญที่สุดอย่างหนึ่งของวิศวกรรมความโกลาหลคือการทำความเข้าใจพฤติกรรมของระบบภายใต้สภาวะปกติ
ทำไม? ง่ายมาก: หลังจากเกิดความล้มเหลวเทียมขึ้น คุณต้องแน่ใจว่าระบบกลับสู่สถานะเสถียรที่ได้รับการศึกษามาเป็นอย่างดี และการทดสอบจะไม่รบกวนการทำงานปกติอีกต่อไป
กุญแจสำคัญในที่นี้คือการไม่มุ่งเน้นไปที่คุณลักษณะของระบบภายใน (โปรเซสเซอร์ หน่วยความจำ ฯลฯ) แต่มุ่งเน้นไปที่ผลลัพธ์ที่วัดได้ซึ่งเชื่อมโยงประสิทธิภาพเข้ากับประสบการณ์ผู้ใช้ เพื่อให้เอาต์พุตเหล่านี้อยู่ในสถานะเสถียร พฤติกรรมที่สังเกตได้ของระบบจะต้องมีรูปแบบที่คาดเดาได้ แต่จะเปลี่ยนแปลงอย่างมีนัยสำคัญเมื่อเกิดความล้มเหลวในระบบ
เก็บไว้ในใจ ตามที่เสนอโดย Adrian Cockcroft ข้างต้น สถานะที่เสถียรนี้จะเปลี่ยนแปลงเมื่อความผิดพลาดที่ไม่สามารถควบคุมได้ทำให้เกิดปัญหาที่ไม่คาดคิด และเป็นสัญญาณว่าการทดลอง Chaos ควรถูกยกเลิก
เพื่อเป็นตัวอย่างของรัฐที่มั่นคง เรามาลองสัมผัสประสบการณ์ของ Amazon กัน บริษัทใช้ปริมาณการสั่งซื้อเป็นหนึ่งในตัวชี้วัดสถานะคงที่และด้วยเหตุผลที่ดี ในปี 2007 Greg Linden ซึ่งเดิมคือ Amazon บรรยายถึงวิธีการทดลองโดยใช้วิธีนี้ ฉันพยายามชะลอเวลาในการโหลดหน้าเว็บไซต์ทีละ 100 มิลลิวินาที และพบว่าความล่าช้าเล็กน้อยอาจทำให้รายได้ลดลงอย่างมาก เมื่อเวลาโหลดเพิ่มขึ้น 100 มิลลิวินาที จำนวนคำสั่งซื้อ (และยอดขาย) จึงลดลง 1% นี่คือสาเหตุที่จำนวนคำสั่งซื้อเป็นตัวเลือกที่ดีเยี่ยมสำหรับการวัดสถานะคงที่
Netflix ใช้ตัวชี้วัดฝั่งเซิร์ฟเวอร์ที่เกี่ยวข้องกับการเริ่มเล่น - จำนวนการคลิกปุ่ม "เล่น" พวกเขาสังเกตเห็นรูปแบบพฤติกรรมของตัวบ่งชี้ SPS (เริ่มต้นต่อวินาที) และความผันผวนที่สำคัญเมื่อระบบเกิดความล้มเหลว ตัวชี้วัดนี้เรียกว่า "ชีพจรของ Netflix" ().
หมายเลขคำสั่งซื้อของ Amazon และ Pulse ของ Netflix เป็นมาตรวัดสถานะคงที่ที่ยอดเยี่ยม เนื่องจากทั้งสองรวมประสบการณ์ผู้ใช้และตัวชี้วัดการปฏิบัติงานเข้าเป็นตัวชี้วัดเดียว วัดได้ และคาดการณ์ได้สูง
วัด วัด และวัดอีกครั้ง
ดำเนินไปโดยไม่ได้บอกว่าหากคุณไม่สามารถบันทึกหน่วยเมตริกของระบบได้อย่างเหมาะสม คุณจะไม่สามารถติดตาม (หรือตรวจจับ) การเปลี่ยนแปลงในสถานะคงที่ได้ ให้ความสนใจเป็นพิเศษกับการอ่านพารามิเตอร์/ตัวบ่งชี้ทั้งหมด ตั้งแต่เครือข่าย ฮาร์ดแวร์ ไปจนถึงแอปพลิเคชัน และผู้คน วาดกราฟของการวัดเหล่านี้ แม้ว่าจะไม่เปลี่ยนแปลงเมื่อเวลาผ่านไปก็ตาม คุณจะประหลาดใจเมื่อค้นพบความสัมพันธ์ที่คุณไม่รู้ว่ามีอยู่จริง
“ทำให้วิศวกรสามารถเข้าถึงข้อมูลที่สามารถคำนวณหรือสร้างกราฟได้ง่ายที่สุดเท่าที่จะเป็นไปได้” —
2. สมมติฐาน
เมื่อจัดการกับสถานะที่มั่นคงแล้ว คุณสามารถดำเนินการตั้งสมมติฐานต่อไปได้
- จะเกิดอะไรขึ้นถ้าเครื่องยนต์แนะนำหยุดทำงาน?
- จะเกิดอะไรขึ้นถ้าโหลดบาลานเซอร์หยุดทำงาน?
- จะเกิดอะไรขึ้นถ้าการแคชล้มเหลว
- จะเกิดอะไรขึ้นถ้าเวลาแฝงเพิ่มขึ้น 300ms?
- จะเกิดอะไรขึ้นถ้าฐานข้อมูลหลักล่ม?
แน่นอนว่าคุณควรเลือกสมมติฐานเพียงข้อเดียวและไม่ควรทำให้ซับซ้อนโดยไม่จำเป็น เริ่มเล็กๆ. ฉันชอบเริ่มต้นด้วยสมมติฐานของพนักงาน คุณเคยได้ยินเกี่ยวกับ ปัจจัยรถบัส ()? ปัจจัยบัสเป็นตัววัดความเสี่ยงที่เกี่ยวข้องกับการกระจายความรู้ที่ไม่สม่ำเสมอระหว่างสมาชิกในทีม ช่วยให้คุณสามารถคำนวณจำนวนผู้เข้าร่วมขั้นต่ำหลังจากการสูญเสียอย่างกะทันหันซึ่งโครงการจะหยุดลงเนื่องจากขาดความรู้หรือประสบการณ์
บริษัทหลายแห่งมีผู้เชี่ยวชาญด้านเทคนิคซึ่งการหายตัวไปอย่างกะทันหัน (“ถูกรถบัสชน”) อาจส่งผลกระทบร้ายแรงต่อทั้งโครงการและทีมงาน ระบุตัวบุคคลเหล่านี้และทำการทดลองความวุ่นวายกับพวกเขา เช่น นำคอมพิวเตอร์ของพวกเขาออกไปแล้วส่งพวกเขากลับบ้านในวันนั้น จากนั้นสังเกตผลลัพธ์ (ซึ่งมักจะวุ่นวาย)
ทำให้ปัญหาเป็นเรื่องธรรมดาสำหรับทุกคน!
ดึงดูด ทั้งทีม เพื่อพัฒนาสมมติฐาน ให้ทุกคนมีส่วนร่วมในการระดมความคิด: เจ้าของผลิตภัณฑ์ ผู้จัดการด้านเทคนิค นักพัฒนาแบ็กเอนด์และส่วนหน้า นักออกแบบ สถาปนิก ฯลฯ ทุกคนที่เชื่อมโยงกับผลิตภัณฑ์ไม่ทางใดก็ทางหนึ่ง
ขั้นแรก ให้ทุกคนเขียนคำตอบของตนเองสำหรับคำถาม “จะเกิดอะไรขึ้นถ้า...?” บนแผ่นกระดาษ คุณจะเห็นว่าในกรณีส่วนใหญ่ ทุกคนจะมีคำตอบที่แตกต่างกัน และคุณจะรู้ว่าทีมงานบางคนไม่ได้คิดถึงปัญหานี้เลยจนกระทั่งบัดนี้
หยุด ณ จุดนี้และอภิปรายว่าทำไมสมาชิกในทีมจึงมีแนวคิดที่แตกต่างกันเกี่ยวกับวิธีการทำงานของผลิตภัณฑ์ในหัวข้อ "จะเกิดอะไรขึ้นถ้า...?" กลับไปที่ข้อกำหนดและตรวจสอบให้แน่ใจว่าทุกคนมีความคิดที่ดีว่าจะเกิดอะไรขึ้นต่อไป
ยกตัวอย่างไซต์ขายปลีกของ Amazon ดังกล่าว จะเกิดอะไรขึ้นหาก Shop by Category หยุดโหลดบนหน้าแรก?
ฉันควรส่งคืนข้อผิดพลาด 404 หรือไม่ คุ้มไหมที่จะโหลดหน้าโดยเว้นพื้นที่ว่างตามภาพหน้าจอด้านล่าง?
คุ้มไหมที่จะสละฟังก์ชันการทำงานบางอย่าง เช่น การอนุญาตให้เพจขยายและซ่อนข้อผิดพลาด
และนั่นเป็นเพียงด้าน UI จะเกิดอะไรขึ้นในแบ็กเอนด์? ควรส่งการแจ้งเตือนหรือไม่? บริการที่ล้มเหลวควรยังคงรับคำขอต่อไปทุกครั้งที่ผู้ใช้โหลดหน้าแรกหรือแบ็กเอนด์ควรตัดออกโดยสิ้นเชิงหรือไม่
และสิ่งสุดท้ายอย่างหนึ่ง โปรดอย่าตั้งสมมติฐานที่คุณรู้ล่วงหน้าว่าจะทำให้เกิดปัญหา! ทดลองกับส่วนต่างๆ ของระบบที่คุณคิดว่าเสถียร เพราะนั่นคือจุดประสงค์หลักของการทดลอง
3. ออกแบบและดำเนินการทดลอง
- เลือกสมมติฐานหนึ่งข้อ
- กำหนดขอบเขตของการทดลอง
- ระบุตัวชี้วัดที่เกี่ยวข้องที่จะวัด
- แจ้งให้องค์กรทราบ
ปัจจุบันนี้หลายคนรวมทั้งเว็บไซต์ ส่งเสริมแนวคิดวิศวกรรมวุ่นวายในการผลิต แม้ว่านี่ควรเป็นเป้าหมายสุดท้าย แต่องค์กรส่วนใหญ่กลับรู้สึกหวาดกลัวกับแนวทางนี้ ดังนั้นจึงไม่ใช่จุดเริ่มต้นที่ดี
สำหรับฉัน วิศวกรรมความโกลาหลไม่ได้เป็นเพียงการทำลายองค์ประกอบต่างๆ ของระบบการผลิตเท่านั้น นี่คือการเดินทาง การเดินทางสู่โลกแห่งความรู้ ซึ่งเชื่อมโยงอย่างแยกไม่ออกกับกิจกรรมต่างๆ เช่น การทำลายระบบในสภาพแวดล้อมที่มีการควบคุม - สภาพแวดล้อมใดๆ ไม่ว่าจะเป็นสภาพแวดล้อมการพัฒนาท้องถิ่น เบต้า การจัดเตรียม หรือผลิตภัณฑ์ ขัดขวางการทดลองที่ออกแบบมาอย่างดีเพื่อสร้างความมั่นใจในความสามารถของแอปพลิเคชันของคุณในการทนต่อสภาวะปั่นป่วน "สร้างความมั่นใจ” เป็นประเด็นสำคัญที่นี่ เนื่องจากเป็นปูชนียบุคคลของการเปลี่ยนแปลงทางวัฒนธรรมที่จำเป็นในการนำแนวทางปฏิบัติทางวิศวกรรมที่วุ่นวายและความน่าเชื่อถือมาใช้ในบริษัทของคุณให้ประสบความสำเร็จ
จริงๆ แล้ว ทีมส่วนใหญ่เรียนรู้มากมายจากการทำลายสิ่งต่าง ๆ แม้แต่ในสภาพแวดล้อมที่ไม่ใช่การผลิตก็ตาม แค่ลองทำ docker stop database ในสภาพแวดล้อมท้องถิ่นของคุณและดูว่าคุณสามารถจัดการกับปัญหานี้โดยไม่มีผลกระทบหรือไม่ มีโอกาสสูงที่จะไม่เป็นเช่นนั้น
การหยุดฐานข้อมูล - ตัวอย่าง
เริ่มต้นจากเล็กๆ และค่อยๆ สร้างความมั่นใจภายในทีมและองค์กรของคุณ ผู้คนจะบอกคุณว่า “ปริมาณการใช้งานจริงเป็นวิธีเดียวที่จะบันทึกพฤติกรรมของระบบได้อย่างน่าเชื่อถือ” ฟัง ยิ้ม และทำสิ่งที่คุณกำลังทำอยู่อย่างช้าๆ สิ่งที่แย่ที่สุดที่คุณสามารถทำได้คือนำวิศวกรรมความโกลาหลมาใช้กับการผลิตและล้มเหลวอย่างน่าสังเวช หลังจากนี้ จะไม่มีใครเชื่อใจคุณ และคุณจะถูกบังคับให้ลืม "ลิงวุ่นวาย" ไปตลอดกาล
ขั้นแรก ได้รับความไว้วางใจ แสดงให้องค์กรและเพื่อนร่วมงานของคุณเห็นว่าคุณรู้ว่าคุณกำลังทำอะไรอยู่ เป็นนักดับเพลิงและเรียนรู้เกี่ยวกับเปลวไฟให้มากที่สุดก่อนที่จะไปฝึกดับเพลิงด้วยชีวิต รับความน่าเชื่อถือของคุณ จดจำ เรื่องราวของเต่ากับกระต่าย? ช้าและอดทนย่อมชนะการแข่งขันเสมอ
จุดที่สำคัญที่สุดประการหนึ่งในระหว่างการทดสอบคือการทำความเข้าใจถึงศักยภาพ รัศมีความเสียหาย จากความล้มเหลวที่คุณแนะนำและการย่อเล็กสุดของมัน ถามตัวเองด้วยคำถามต่อไปนี้:
- มีลูกค้ากี่รายที่จะได้รับผลกระทบจากการทดสอบนี้
- ฟังก์ชันการทำงานใดบ้างที่จะได้รับผลกระทบ?
- สถานที่ใดบ้างที่จะได้รับผลกระทบ?
ลองนึกถึง "ปุ่มฆ่า" หรือวิธีที่จะยกเลิกการทดสอบทันทีและกลับสู่สถานะคงที่โดยเร็วที่สุด ฉันชอบทำการทดลองโดยใช้สิ่งที่เรียกว่า การเปิดตัว "นกขมิ้น" เทคนิคนี้ช่วยลดความเสี่ยงของความล้มเหลวเมื่อเปิดตัวแอปพลิเคชันเวอร์ชันใหม่ในการผลิตโดยค่อยๆ เปิดตัวการเปลี่ยนแปลงไปยังผู้ใช้ชุดย่อยเล็กๆ จากนั้นจึงค่อยเผยแพร่การเปลี่ยนแปลงไปยังโครงสร้างพื้นฐานทั้งหมดและผู้ใช้ทั้งหมด ฉันชอบการเปิดตัวคานารีเพียงเพราะมันเป็นไปตามหลักการ และการทดลองนั้นค่อนข้างง่ายที่จะหยุด
ตัวอย่างการเปิดตัว Canary ที่ใช้ DNS สำหรับการทดสอบ Chaos
ระมัดระวังกับการทดลองที่เปลี่ยนสถานะของแอปพลิเคชัน (แคชหรือฐานข้อมูล) หรือการทดลองที่ไม่สามารถย้อนกลับได้ (อย่างง่ายดายหรือเลย)
ที่น่าสนใจคือ Adrian Cockcroft บอกฉันว่าสาเหตุหนึ่งที่ Netflix เริ่มใช้ฐานข้อมูล NoSQL ก็เพราะพวกเขาไม่มีสคีมาสำหรับการเปลี่ยนแปลงหรือการย้อนกลับ ดังนั้นจึงง่ายกว่ามากในการอัปเดตหรือแก้ไขบันทึกข้อมูลแต่ละรายการทีละน้อย (กล่าวคือ ฐานข้อมูลเหล่านี้เป็นมิตรกับวิศวกรรมวุ่นวายมากกว่า) .
4. สังเกตและเรียนรู้
หากต้องการเรียนรู้สิ่งใหม่ๆ และติดตามความคืบหน้าของการทดสอบ คุณจะต้องสามารถตรวจสอบประสิทธิภาพของระบบได้ ดังที่ได้กล่าวไว้ก่อนหน้านี้ ให้ความสนใจสูงสุดกับตัวชี้วัดและพารามิเตอร์ทุกประเภท! จากนั้นหาปริมาณผลลัพธ์และเสมอ - เสมอ! — จดบันทึกเวลาก่อนที่สัญญาณแรกของปัญหาจะปรากฏขึ้น มันเกิดขึ้นหลายครั้งในประวัติศาสตร์ของฉันที่ระบบแจ้งเตือนล้มเหลวและลูกค้าทวีตเกี่ยวกับปัญหาก่อน... เชื่อฉันเถอะ คุณคงไม่อยากตกอยู่ในสถานการณ์นั้น ดังนั้นใช้การทดลองวุ่นวายเพื่อทดสอบระบบติดตามและแจ้งเตือนของคุณ ดี.
- ถึงเวลาตรวจพบ?
- เวลาก่อนการแจ้งเตือนและการเริ่มดำเนินการ?
- เวลาจนกว่าจะประกาศสาธารณะ?
- เวลาจนกระทั่งสูญเสียฟังก์ชันการทำงานบางส่วน?
- ระยะเวลาการรักษาตนเองจะอยู่ได้นานแค่ไหน?
- เวลาที่จะฟื้นตัวเต็มที่หรือบางส่วน?
- เวลาจะสิ้นสุดวิกฤตและกลับเข้าสู่สภาวะที่มั่นคง?
โปรดจำไว้ว่าไม่มีสาเหตุของความล้มเหลวเพียงอย่างเดียว อุบัติเหตุใหญ่มักเป็นผลมาจากความล้มเหลวเล็กๆ น้อยๆ หลายครั้งที่สะสมและนำไปสู่วิกฤตครั้งใหญ่
ทำการวิเคราะห์หลังชันสูตรโดยละเอียดของการทดลองแต่ละครั้ง!
ที่ AWS เราให้ความสำคัญอย่างยิ่งกับการวิเคราะห์ความล้มเหลวที่ตรวจพบและทำความเข้าใจว่าอะไรเป็นสาเหตุของความล้มเหลว เพื่อให้เราสามารถป้องกันปัญหาที่คล้ายกันได้ในอนาคต ข้อสรุปและผลลัพธ์ทั้งหมดของการทดลองสรุปไว้ในเอกสารชื่อการแก้ไขข้อผิดพลาด (COE) COE ช่วยให้เราเรียนรู้จากความผิดพลาดของเรา ไม่ว่าจะเป็นข้อบกพร่องในด้านเทคโนโลยี กระบวนการ หรือแม้แต่ในองค์กร เราใช้กลไกนี้เพื่อกำจัดสาเหตุที่แท้จริงของการเสียและปรับปรุงอย่างต่อเนื่อง
กุญแจสู่ความสำเร็จในกระบวนการนี้คือการเปิดกว้างและความโปร่งใสเกี่ยวกับสิ่งที่ผิดพลาด หลักการที่สำคัญที่สุดประการหนึ่งในการเขียน COE ที่ดีคือการมีความเป็นกลางและหลีกเลี่ยงการกล่าวถึงบุคคลใดบุคคลหนึ่งโดยเฉพาะ ซึ่งมักจะเป็นเรื่องยากในสภาพแวดล้อมที่ไม่สนับสนุนพฤติกรรมดังกล่าวและไม่อนุญาตให้เกิดความล้มเหลว Amazon ใช้ชุดของ "หลักความเป็นผู้นำ" () เพื่อส่งเสริมพฤติกรรมดังกล่าว - เช่น การวิจารณ์ตนเอง วิธีการวิเคราะห์ ความมุ่งมั่นในมาตรฐานและความรับผิดชอบสูงสุด เป็นองค์ประกอบสำคัญของกระบวนการ COE และความเป็นเลิศในการปฏิบัติงานโดยทั่วไป
รายงาน COE มีห้าส่วนหลัก:
- เกิดอะไรขึ้น (ตามลำดับเวลา)?
- ผลกระทบต่อลูกค้าคืออะไร?
- เหตุใดจึงเกิดข้อผิดพลาด? ()
- เราได้เรียนรู้อะไรบ้าง?
- จะป้องกันสิ่งนี้ในอนาคตได้อย่างไร?
คำถามเหล่านี้ตอบได้ยากกว่าที่เห็นในตอนแรก เนื่องจากคุณต้องแน่ใจว่ามีการศึกษาประเด็นที่ไม่ชัดเจนหรือไม่ทราบอย่างรอบคอบ
เพื่อเปลี่ยนกลไก COE ให้เป็นกระบวนการที่เต็มเปี่ยม เราดำเนินการตรวจสอบอย่างต่อเนื่องในรูปแบบของการประชุมรายสัปดาห์พร้อมการวิเคราะห์ภาคบังคับของตัวชี้วัดการปฏิบัติงาน นอกจากนี้ ลีดด้านเทคนิคยังดำเนินการตรวจสอบตัววัดรายสัปดาห์กับพนักงาน AWS ทั้งหมด
5. แก้ไขและปรับปรุง!
บทเรียนหลักที่นี่คือ แก้ไขปัญหาที่ระบุในระหว่างการทดสอบ Chaos ก่อน โดยให้ความสำคัญกับปัญหาเหล่านั้นมากกว่าการพัฒนาคุณสมบัติใหม่. ให้ผู้บริหารระดับสูงมีส่วนร่วมในกระบวนการนี้ และปลูกฝังแนวคิดที่ว่าการแก้ไขปัญหาในปัจจุบันมีความสำคัญมากกว่าการพัฒนาฟังก์ชันการทำงานใหม่ๆ
ฉันเคยช่วยลูกค้าระบุปัญหาความเสถียรที่สำคัญโดยใช้การทดลองที่วุ่นวาย แต่เนื่องจากแรงกดดันจากทีมขาย การแก้ไขจึงถูกลดความสำคัญลง และความพยายามทั้งหมดมุ่งเน้นไปที่การแนะนำสิ่งใหม่ที่ "สำคัญอย่างยิ่ง" ให้กับลูกค้า สองสัปดาห์ต่อมา การหยุดทำงานเป็นเวลา 16 ชั่วโมงทำให้บริษัทต้องแก้ไขปัญหาเดียวกันกับที่เราพบในระหว่างการทดสอบความวุ่นวาย มีเพียงความสูญเสียเท่านั้นที่สูงกว่ามาก
ประโยชน์ของเคออสเอ็นจิเนียริ่ง
มีข้อดีหลายประการ ในความคิดของฉันฉันจะเน้นสองสิ่งที่สำคัญที่สุด:
ประการแรก วิศวกรรมความโกลาหลช่วยเปิดเผยปัญหาที่ไม่ทราบในระบบและแก้ไขก่อนที่ปัญหาดังกล่าวจะทำให้การผลิตขัดข้อง เช่น เวลาตี 3 ของวันอาทิตย์ นั่นก็คือเขา เพิ่มความต้านทานต่อความล้มเหลวและคุณภาพการนอนหลับจริงๆ.
ประการที่สอง การทดลองความโกลาหลที่ดำเนินการอย่างมีประสิทธิผลมักจะทำให้เกิดการเปลี่ยนแปลงอย่างกว้างขวาง (โดยเฉพาะด้านวัฒนธรรม) มากกว่าที่คาดไว้ บางทีสิ่งที่สำคัญที่สุดคือวิวัฒนาการตามธรรมชาติ "ผู้บริสุทธิ์" (ไม่กล่าวโทษ) วัฒนธรรมเมื่อถูกถามว่า “ทำไมถึงทำแบบนั้น?” กลายเป็น “เราจะหลีกเลี่ยงสิ่งนี้ในอนาคตได้อย่างไร” ผลลัพธ์ที่ได้คือทีมมีความสุขมากขึ้น มีประสิทธิภาพมากขึ้น มีส่วนร่วมมากขึ้น และประสบความสำเร็จมากขึ้น และนั่นเยี่ยมมาก!
นี่เป็นการสรุปส่วนแรก ฉันหวังว่าคุณจะชอบมัน กรุณาเขียนบทวิจารณ์ แบ่งปันความคิดเห็น หรือเพียงปรบมือของคุณ . ในส่วนถัดไป ผมจะดูเครื่องมือและเทคนิคในการแนะนำข้อผิดพลาดเข้าสู่ระบบ จนกระทั่ง!
สำหรับผู้ที่อยากอ่านส่วนที่สอง ฉันขอเสนอสุนทรพจน์ในหัวข้อวิศวกรรมความโกลาหลที่ NDC ในออสโล ในนั้นฉันพูดถึงเครื่องมือที่ฉันชื่นชอบมากมาย:
ปล.จากผู้แปล
ส่วนที่สองของบทความเป็นภาษาอังกฤษ และเราจะแปลด้วยหากเราเห็นความสนใจเพียงพอจากผู้อ่าน Habr ในเนื้อหานี้ - ยินดีต้อนรับความคิดเห็นที่เหมาะสมในบทความนี้!
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «";
- «'
ที่มา: will.com