บันทึก. แปล: บทความนี้ยังคงต่อยอดบทความดีๆ จาก Adrian Hornsby ผู้เผยแพร่เทคโนโลยี AWS ซึ่งตั้งใจจะอธิบายด้วยวิธีที่ง่ายและชัดเจนเกี่ยวกับความสำคัญของการทดลองเพื่อลดผลที่ตามมาจากความล้มเหลวในระบบ IT
“หากคุณล้มเหลวในการเตรียมแผน แสดงว่าคุณวางแผนที่จะล้มเหลว” - เบนจามินแฟรงคลิน
В ในบทความชุดนี้ ฉันได้แนะนำแนวคิดของวิศวกรรมความโกลาหล และอธิบายว่าจะช่วยค้นหาและแก้ไขข้อบกพร่องในระบบก่อนที่จะนำไปสู่ความล้มเหลวในการผลิตได้อย่างไร นอกจากนี้ ยังกล่าวถึงวิธีที่วิศวกรรมความสับสนวุ่นวายส่งเสริมการเปลี่ยนแปลงวัฒนธรรมเชิงบวกภายในองค์กรอย่างไร
ในตอนท้ายของส่วนแรก ฉันสัญญาว่าจะพูดถึง “เครื่องมือและวิธีการในการนำความล้มเหลวเข้าสู่ระบบ” อนิจจาหัวของฉันมีแผนในเรื่องนี้และในบทความนี้ฉันจะพยายามตอบคำถามยอดนิยมที่เกิดขึ้นในหมู่ผู้ที่ต้องการเข้าสู่วิศวกรรมความโกลาหล: จะแตกอะไรก่อน?
คำถามที่ดี! อย่างไรก็ตาม ดูเหมือนเขาจะไม่ได้สนใจแพนด้าตัวนี้มากนัก...
อย่ายุ่งกับแพนด้าวุ่นวาย!
ตอบสั้นๆ: กำหนดเป้าหมายบริการที่สำคัญตามเส้นทางคำขอ
คำตอบที่ยาวกว่าแต่ชัดเจนกว่า: เพื่อทำความเข้าใจว่าจะเริ่มทดลองกับความโกลาหลได้ที่ไหน ให้ใส่ใจกับสามประเด็นต่อไปนี้:
- มองไปที่ ประวัติความผิดพลาด และระบุรูปแบบ
- ตัดสินใจเลือก การพึ่งพาที่สำคัญ;
- ใช้สิ่งที่เรียกว่า ผลกระทบจากความมั่นใจมากเกินไป.
มันตลกดี แต่ส่วนนี้สามารถเรียกได้ง่ายพอๆ กัน “การเดินทางสู่การค้นพบตนเองและการตรัสรู้”. ในนั้นเราจะเริ่ม "เล่น" ด้วยเครื่องดนตรีเจ๋งๆ
1. คำตอบอยู่ในอดีต
หากคุณจำได้ ในส่วนแรก ฉันได้แนะนำแนวคิดการแก้ไขข้อผิดพลาด (COE) ซึ่งเป็นวิธีการที่เราวิเคราะห์ข้อผิดพลาดของเรา - ข้อผิดพลาดในเทคโนโลยี กระบวนการ หรือองค์กร - เพื่อทำความเข้าใจสาเหตุและป้องกัน การเกิดซ้ำในอนาคต โดยทั่วไป นี่คือจุดที่คุณควรเริ่มต้น
“เพื่อที่จะเข้าใจปัจจุบัน คุณต้องรู้อดีต” — คาร์ล เซแกน
ดูประวัติความล้มเหลว ติดแท็กใน COE หรือการชันสูตรพลิกศพ และจำแนกประเภท ระบุรูปแบบทั่วไปที่มักนำไปสู่ปัญหา และสำหรับ COE แต่ละรายการ ให้ถามตัวเองด้วยคำถามต่อไปนี้:
“สิ่งนี้สามารถคาดการณ์ได้และป้องกันด้วยการฉีดข้อผิดพลาดหรือไม่”
ฉันจำความล้มเหลวครั้งหนึ่งในชีวิตการทำงานได้ มันสามารถป้องกันได้ง่ายๆ หากเราทำการทดลองความโกลาหลง่ายๆ สองสามข้อ:
ภายใต้สภาวะปกติ อินสแตนซ์แบ็กเอนด์จะตอบสนองต่อการตรวจสอบประสิทธิภาพการทำงาน ). ELB ใช้การตรวจสอบเหล่านี้เพื่อเปลี่ยนเส้นทางคำขอไปยังอินสแตนซ์ที่มีประสิทธิภาพ เมื่อปรากฎว่าอินสแตนซ์นั้น “ไม่มีประสิทธิภาพ” ELB จะหยุดส่งคำขอไปยังอินสแตนซ์นั้น วันหนึ่ง หลังจากแคมเปญการตลาดประสบความสำเร็จ ปริมาณการเข้าชมเพิ่มขึ้น และแบ็กเอนด์เริ่มตอบสนองต่อการตรวจสุขภาพช้ากว่าปกติ ควรจะบอกว่าการตรวจสุขภาพเหล่านี้ได้ นั่นคือมีการตรวจสอบสถานะของการขึ้นต่อกัน
อย่างไรก็ตาม ทุกอย่างเรียบร้อยดีมาระยะหนึ่งแล้ว
จากนั้น ภายใต้เงื่อนไขที่ค่อนข้างตึงเครียด หนึ่งในอินสแตนซ์เริ่มดำเนินการงาน ETL cron ปกติที่ไม่สำคัญ การรวมกันของการรับส่งข้อมูลที่สูงและ cronjob ทำให้การใช้งาน CPU เกือบ 100% CPU โอเวอร์โหลดยังชะลอการตอบสนองต่อการตรวจสอบสภาพอีกด้วย มากจน ELB ตัดสินใจว่าอินสแตนซ์กำลังประสบปัญหาด้านประสิทธิภาพ ตามที่คาดไว้ ตัวปรับสมดุลหยุดกระจายการรับส่งข้อมูลไปยังตัวดังกล่าว ซึ่งในทางกลับกัน ส่งผลให้มีภาระงานเพิ่มขึ้นในอินสแตนซ์ที่เหลือในกลุ่ม
ทันใดนั้น กรณีอื่นๆ ทั้งหมดก็เริ่มล้มเหลวในการตรวจสุขภาพเช่นกัน
การเริ่มต้นอินสแตนซ์ใหม่จำเป็นต้องดาวน์โหลดและติดตั้งแพ็คเกจ และใช้เวลานานกว่าที่ ELB ใช้ในการปิดใช้งานทีละรายการในกลุ่มการปรับขนาดอัตโนมัติ เป็นที่ชัดเจนว่าในไม่ช้ากระบวนการทั้งหมดก็มาถึงจุดวิกฤติและแอปพลิเคชันขัดข้อง
จากนั้นเราก็เข้าใจประเด็นต่อไปนี้ตลอดไป:
- การติดตั้งซอฟต์แวร์เมื่อสร้างอินสแตนซ์ใหม่ใช้เวลานาน ควรให้ความสำคัญกับแนวทางที่ไม่เปลี่ยนรูปแบบจะดีกว่าและ .
- ในสถานการณ์ที่ยากลำบาก การตอบสนองต่อการตรวจสุขภาพและ ELB ควรให้ความสำคัญ สิ่งสุดท้ายที่คุณต้องการคือทำให้ชีวิตมีความซับซ้อนในกรณีที่เหลือ
- การแคชการตรวจสุขภาพในเครื่องช่วยได้มาก (แม้เพียงไม่กี่วินาที)
- ในสถานการณ์ที่ยากลำบาก อย่ารันงาน cron และกระบวนการที่ไม่สำคัญอื่น ๆ - ประหยัดทรัพยากรสำหรับงานที่สำคัญที่สุด
- เมื่อปรับขนาดอัตโนมัติ ให้ใช้อินสแตนซ์ที่เล็กลง กลุ่มตัวอย่างขนาดเล็ก 10 ชิ้นย่อมดีกว่ากลุ่มตัวอย่างขนาดใหญ่ 4 ชิ้น หากอินสแตนซ์หนึ่งล้มเหลว ในกรณีแรก 10% ของการรับส่งข้อมูลจะถูกกระจายไปมากกว่า 9 จุด ในครั้งที่สอง - 25% ของการรับส่งข้อมูลมากกว่าสามจุด
ดังนั้น สิ่งนี้สามารถคาดการณ์ได้และป้องกันด้วยการแนะนำปัญหาหรือไม่
มีและในหลายๆ ทาง
ขั้นแรกโดยการจำลองการใช้งาน CPU สูงโดยใช้เครื่องมือเช่น หรือ :
❯ stress-ng --matrix 1 -t 60s
ความเครียด ng
ประการที่สองโดยการโอเวอร์โหลดอินสแตนซ์ด้วย และยูทิลิตี้อื่นที่คล้ายคลึงกัน:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
การทดลองนั้นค่อนข้างง่าย แต่สามารถให้อาหารที่ดีสำหรับความคิดโดยไม่ต้องผ่านความเครียดจากความล้มเหลวจริงๆ
แต่ อย่าหยุดเพียงแค่นั้น. ลองสร้างข้อขัดข้องในสภาพแวดล้อมการทดสอบอีกครั้งและตรวจสอบคำตอบสำหรับคำถาม "สิ่งนี้สามารถคาดการณ์ได้และป้องกันโดยการแนะนำข้อผิดพลาดหรือไม่?" นี่คือการทดลองเคออสขนาดเล็กภายในการทดสอบเคออสเพื่อทดสอบสมมติฐาน แต่เริ่มต้นด้วยความล้มเหลว
มันเป็นความฝันหรือมันเกิดขึ้นจริง?
ดังนั้นจงศึกษาประวัติความล้มเหลว วิเคราะห์ ศูนย์ EOCติดแท็กและจำแนกประเภทตาม "รัศมีการเข้าชม" หรือถ้าให้แม่นยำกว่านั้นคือจำนวนลูกค้าที่ได้รับผลกระทบ จากนั้นจึงมองหารูปแบบ ถามตัวเองว่าสิ่งนี้สามารถคาดการณ์และป้องกันได้โดยการแนะนำปัญหาหรือไม่ ตรวจคำตอบของคุณ.
จากนั้นสลับไปใช้รูปแบบทั่วไปที่มีช่วงมากที่สุด
2. สร้างแผนที่การพึ่งพา
ใช้เวลาสักครู่เพื่อคิดถึงการสมัครของคุณ มีแผนที่ชัดเจนของการพึ่งพาหรือไม่? คุณรู้ไหมว่าพวกเขาจะมีผลกระทบอะไรบ้างหากเกิดความล้มเหลว?
หากคุณไม่คุ้นเคยกับโค้ดของแอปพลิเคชันของคุณมากนักหรือมีโค้ดมีขนาดใหญ่มาก อาจเป็นเรื่องยากที่จะเข้าใจว่าโค้ดทำอะไรและการขึ้นต่อกันของโค้ดนั้นคืออะไร การทำความเข้าใจการขึ้นต่อกันเหล่านี้และผลกระทบที่อาจเกิดขึ้นกับแอปพลิเคชันและผู้ใช้เป็นสิ่งสำคัญอย่างยิ่งในการรู้ว่าจะเริ่มต้นอย่างไรกับวิศวกรรมความโกลาหล: จุดเริ่มต้นคือองค์ประกอบที่มีรัศมีการกระแทกที่ใหญ่ที่สุด
การระบุและบันทึกการพึ่งพาเรียกว่า "การสร้างแผนที่การพึ่งพา» (การแมปการพึ่งพา). โดยทั่วไปจะทำกับแอปพลิเคชันที่มีฐานโค้ดขนาดใหญ่โดยใช้เครื่องมือสร้างโปรไฟล์โค้ด (โปรไฟล์รหัส) และเครื่องมือวัด (เครื่องดนตรี). คุณยังสามารถสร้างแผนที่โดยการตรวจสอบการรับส่งข้อมูลเครือข่าย
อย่างไรก็ตาม การขึ้นต่อกันทั้งหมดไม่เหมือนกัน (ซึ่งทำให้กระบวนการซับซ้อนยิ่งขึ้น) บาง วิกฤต, อื่น - รอง (อย่างน้อยก็ในทางทฤษฎี เนื่องจากข้อขัดข้องมักเกิดขึ้นเนื่องจากปัญหาเกี่ยวกับการขึ้นต่อกันที่ถือว่าไม่สำคัญ).
หากไม่มีการพึ่งพาที่สำคัญ บริการจะไม่สามารถทำงานได้ การพึ่งพาที่ไม่สำคัญ "ไม่ควร» เพื่อมีอิทธิพลต่อการให้บริการในกรณีที่เกิดการล้ม เพื่อให้เข้าใจถึงการขึ้นต่อกัน คุณต้องมีความเข้าใจที่ชัดเจนเกี่ยวกับ API ที่แอปพลิเคชันของคุณใช้ นี่อาจเป็นเรื่องยากกว่าที่คิดไว้มาก - อย่างน้อยก็สำหรับการใช้งานขนาดใหญ่
เริ่มต้นด้วยการผ่าน API ทั้งหมด เน้นให้มากที่สุด สำคัญและสำคัญ. เอา ขึ้นอยู่กับ จากที่เก็บโค้ด ให้ลองดู บันทึกการเชื่อมต่อจากนั้นจึงดู เอกสาร (แน่นอนว่าถ้ามีอยู่ - มิฉะนั้นคุณก็ยังมีอยู่оปัญหาที่ใหญ่กว่า) ใช้เครื่องมือในการ การทำโปรไฟล์และการติดตาม, กรองการโทรภายนอกออก
คุณสามารถใช้โปรแกรมเช่น netstat - ยูทิลิตี้บรรทัดคำสั่งที่แสดงรายการการเชื่อมต่อเครือข่ายทั้งหมด (ซ็อกเก็ตที่ใช้งานอยู่) ในระบบ ตัวอย่างเช่น หากต้องการแสดงรายการการเชื่อมต่อปัจจุบันทั้งหมด ให้พิมพ์:
❯ netstat -a | more
ใน AWS คุณสามารถใช้ได้ (บันทึกโฟลว์) VPC เป็นวิธีการที่ช่วยให้คุณรวบรวมข้อมูลเกี่ยวกับการรับส่งข้อมูล IP ที่ไปหรือจากอินเทอร์เฟซเครือข่ายใน VPC บันทึกดังกล่าวสามารถช่วยในงานอื่นๆ ได้ เช่น การค้นหาคำตอบสำหรับคำถามที่ว่าทำไมการรับส่งข้อมูลบางอย่างไปไม่ถึงอินสแตนซ์
คุณสามารถใช้ . X-Ray ช่วยให้คุณได้รับรายละเอียด "ขั้นสูงสุด" (จบสิ้น) ภาพรวมของคำขอขณะที่คำขอเคลื่อนผ่านแอปพลิเคชัน และยังสร้างแผนที่ของส่วนประกอบพื้นฐานของแอปพลิเคชันอีกด้วย สะดวกมากหากคุณต้องการระบุการขึ้นต่อกัน
คอนโซล AWS X-Ray
แผนที่การพึ่งพาเครือข่ายเป็นเพียงโซลูชันบางส่วนเท่านั้น ใช่ มันแสดงว่าแอปพลิเคชันใดสื่อสารกับแอปพลิเคชันใด แต่มีการขึ้นต่อกันอื่น ๆ
แอปพลิเคชันจำนวนมากใช้ DNS เพื่อเชื่อมต่อกับการอ้างอิง ในขณะที่แอปพลิเคชันอื่นๆ อาจใช้การค้นหาบริการ หรือแม้แต่ที่อยู่ IP แบบฮาร์ดโค้ดในไฟล์การกำหนดค่า (เช่น /etc/hosts).
ตัวอย่างเช่น คุณสามารถสร้าง ด้วย iptables และดูว่ามีอะไรแตกหักบ้าง เมื่อต้องการทำเช่นนี้ ให้ป้อนคำสั่งต่อไปนี้:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
หลุมดำ DNS
หากเข้า /etc/hosts หรือไฟล์การกำหนดค่าอื่น ๆ คุณจะพบที่อยู่ IP ที่คุณไม่รู้อะไรเลย (ใช่ แต่น่าเสียดายที่เกิดเหตุการณ์เช่นนี้ด้วย) คุณสามารถกลับมาช่วยเหลือได้อีกครั้ง iptables. สมมติว่าคุณค้นพบ 8.8.8.8 และไม่รู้ว่านี่คือที่อยู่เซิร์ฟเวอร์ DNS สาธารณะของ Google โดยใช้ iptables คุณสามารถบล็อกการรับส่งข้อมูลขาเข้าและขาออกไปยังที่อยู่นี้ได้โดยใช้คำสั่งต่อไปนี้:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
การปิดการเข้าถึง
กฎข้อแรกจะปล่อยแพ็กเก็ตทั้งหมดจาก DNS สาธารณะของ Google: ping ใช้งานได้ แต่แพ็กเก็ตจะไม่ถูกส่งคืน กฎข้อที่สองจะปล่อยแพ็กเก็ตทั้งหมดที่มาจากระบบของคุณไปยัง DNS สาธารณะของ Google เพื่อตอบสนอง ping เราได้รับ การดำเนินงานไม่ได้รับอนุญาต.
หมายเหตุ: ในกรณีนี้ควรใช้จะดีกว่า whois 8.8.8.8แต่นี่เป็นเพียงตัวอย่างเท่านั้น
เรายังเจาะลึกลงไปอีกได้ เพราะทุกอย่างที่ใช้ TCP และ UDP จริงๆ แล้วขึ้นอยู่กับ IP ด้วยเช่นกัน ในกรณีส่วนใหญ่ IP จะเชื่อมโยงกับ ARP อย่าลืมเรื่องไฟร์วอลล์...
ถ้าคุณกินยาเม็ดสีแดง คุณจะอยู่ในแดนมหัศจรรย์ และฉันจะแสดงให้คุณเห็นว่าหลุมกระต่ายนั้นลึกแค่ไหน”
แนวทางที่รุนแรงกว่านี้ก็คือ ตัดการเชื่อมต่อ ทีละคันดูว่ามีอะไรพัง...กลายเป็น "ลิงวุ่นวาย" แน่นอนว่าระบบการผลิตจำนวนมากไม่ได้ออกแบบมาสำหรับการโจมตีด้วยกำลังดุร้าย แต่อย่างน้อยก็สามารถทดลองได้ในสภาพแวดล้อมการทดสอบ
การสร้างแผนที่การพึ่งพามักเป็นการดำเนินการที่มีความยาวมาก เมื่อเร็วๆ นี้ฉันได้พูดคุยกับลูกค้าที่ใช้เวลาเกือบ 2 ปีในการพัฒนาเครื่องมือที่สร้างแผนที่การพึ่งพาแบบกึ่งอัตโนมัติสำหรับไมโครเซอร์วิสและคำสั่งหลายร้อยรายการ
อย่างไรก็ตามผลลัพธ์ที่ได้นั้นน่าสนใจและมีประโยชน์อย่างยิ่ง คุณจะได้เรียนรู้มากมายเกี่ยวกับระบบของคุณ การขึ้นต่อกัน และการทำงานของระบบ ขอย้ำอีกครั้งว่าต้องอดทน: การเดินทางเป็นสิ่งสำคัญที่สุด
3. ระวังความมั่นใจมากเกินไป
“ใครฝันถึงสิ่งใด จงเชื่อในสิ่งนั้น” — เดมอสเธเนส
คุณเคยได้ยินเกี่ยวกับ ผลกระทบจากความมั่นใจมากเกินไป?
ตามวิกิพีเดีย ผลกระทบจากความมั่นใจมากเกินไปคือ “อคติทางความคิด ซึ่งความมั่นใจของบุคคลในการกระทำและการตัดสินใจของตนมีมากกว่าความแม่นยำตามวัตถุประสงค์ของการตัดสินเหล่านั้นอย่างมาก โดยเฉพาะอย่างยิ่งเมื่อระดับความมั่นใจค่อนข้างสูง”
ตามสัญชาตญาณและประสบการณ์...
จากประสบการณ์ของผม การบิดเบือนนี้เป็นสัญญาณที่ดีว่าจะเริ่มจากวิศวกรรมความโกลาหลได้ที่ไหน
ระวังผู้ปฏิบัติงานที่มั่นใจมากเกินไป:
ชาร์ลี: “สิ่งนี้ไม่ได้พังมาห้าปีแล้ว ทุกอย่างเรียบร้อยดี!”
แครช: “เดี๋ยวก่อน... ฉันจะไปที่นั่นเร็วๆ นี้!”
อคติซึ่งเป็นผลมาจากความมั่นใจมากเกินไปถือเป็นสิ่งที่ร้ายกาจและเป็นอันตรายด้วยซ้ำเนื่องจากปัจจัยต่างๆ ที่มีอิทธิพลต่อมัน โดยเฉพาะอย่างยิ่งเมื่อสมาชิกในทีมทุ่มเทให้กับเทคโนโลยีหรือใช้เวลามากมายในการ "แก้ไข" เทคโนโลยีดังกล่าว
สรุป
การค้นหาจุดเริ่มต้นสำหรับวิศวกรรมความโกลาหลมักจะให้ผลลัพธ์มากกว่าที่คาดไว้เสมอ และทีมที่เริ่มทำลายสิ่งต่าง ๆ เร็วเกินไปจะมองข้ามแก่นแท้ที่เป็นสากลและน่าสนใจของ (ความโกลาหล-)วิศวกรรม - การใช้อย่างสร้างสรรค์ วิธีการทางวิทยาศาสตร์ и หลักฐานเชิงประจักษ์ สำหรับการออกแบบ การพัฒนา การดำเนินงาน การบำรุงรักษา และปรับปรุงระบบ (ซอฟต์แวร์)
นี่เป็นการสรุปส่วนที่สอง กรุณาเขียนบทวิจารณ์ แบ่งปันความคิดเห็น หรือเพียงปรบมือของคุณ . ในส่วนต่อไป I จริงๆ ฉันจะพิจารณาเครื่องมือและวิธีการในการแนะนำความล้มเหลวเข้าสู่ระบบ จนกระทั่ง!
ปล.จากผู้แปล
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «";
- «";
- «'
ที่มา: will.com