ความงามที่แตกหัก: การสร้างระบบที่ยืดหยุ่นผ่านวิศวกรรมความโกลาหล

เนื้อหา

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

ที่มา: pressureUA / iStockphoto

Takeaway:

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

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

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

การเตรียมพร้อมสำหรับความล้มเหลว

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

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

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

ขั้นตอนต่อไป

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

เหตุการณ์ความล้มเหลวที่มีความหมายขึ้นอยู่กับรูปแบบการบริการของคุณเป็นส่วนใหญ่และคุณสามารถกำหนดโดยการถามคำถามเฉพาะที่เกี่ยวข้องกับคุณ ตัวอย่างเช่นอะไรคือผลกระทบสำหรับผู้ใช้ front-end เมื่อฐานข้อมูลไม่สามารถเข้าถึงได้ในช่วงระยะเวลาหนึ่ง ผู้ใช้เหล่านั้นยังคงสามารถท่องเว็บ UI ได้หรือไม่? พวกเขายังคงสามารถออกอัพเดตข้อมูลของพวกเขาและการอัพเดทเหล่านั้นจะถูกประมวลผลอย่างถูกต้องเมื่อฐานข้อมูลสามารถเข้าถึงได้อีกครั้งหรือไม่

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

ไม่มีข้อบกพร่องไม่มีความเครียด - คู่มือแบบเป็นขั้นตอนเพื่อสร้างซอฟต์แวร์ที่เปลี่ยนแปลงชีวิตโดยไม่ทำลายชีวิตของคุณ

คุณไม่สามารถพัฒนาทักษะการเขียนโปรแกรมของคุณเมื่อไม่มีใครใส่ใจคุณภาพของซอฟต์แวร์

เมื่อคุณกำหนดคำถามสำคัญสองสามข้อเกี่ยวกับโครงสร้างพื้นฐานของคุณแล้วคุณสามารถเริ่มรายการวิธีต่างๆในการจำลองความล้มเหลวเหล่านั้น อาจเพียงพอที่จะหยุดบริการเฉพาะหรือเซิร์ฟเวอร์ฐานข้อมูล คุณอาจต้องการบล็อกเธรดหลักของบริการเพื่อจำลองเดดล็อกในขณะที่คอนเทนเนอร์ยังคงตอบสนองและทำงานอยู่ คุณอาจตัดสินใจที่จะแนะนำกฎในเครือข่ายของคุณเพื่อป้องกันการรับส่งข้อมูลระหว่างบริการเฉพาะ ในสภาพแวดล้อม Linux คุณสามารถใช้เครื่องมือเช่น ‘tc’ เพื่อเลียนแบบสถานการณ์เครือข่ายเช่นเวลาแฝงที่สูงแพ็กเก็ตที่เสียหายหรือทำซ้ำ (อาจเป็นสิ่งสำคัญที่จะต้องให้ผู้ใช้มีส่วนร่วมในการทดสอบอ่านเพิ่มเติมใน 4 เหตุผลที่ผู้ใช้ต้องเข้าร่วมในการทดสอบก่อน UAT)

การเรียนรู้และการปรับปรุงผ่านการฝึกซ้อม

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

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