กระบวนการพัฒนา SRE ที่ Google

• Google SRE ลดเหตุขัดข้องลงได้แม้บริการจะขยายขนาดขึ้น แต่เห็นว่าวิธีเดิมเพียงอย่างเดียวไม่พอสำหรับ ความสูญเสียที่ต้องป้องกันอย่างเด็ดขาด เช่น การละเมิดข้อมูลส่วนบุคคลหรือการสูญหายของข้อมูล จึงนำ STAMP มาใช้
• STAMP มุ่งเน้นที่ ปฏิสัมพันธ์ของระบบและความล้มเหลวของการควบคุม มากกว่าความเสียหายของคอมโพเนนต์แต่ละส่วน โดย CAST ใช้ในการสอบสวนอุบัติเหตุ และ STPA ใช้ในการวิเคราะห์ความเสี่ยง
• โมเดลการไหลของข้อมูลและห่วงโซ่เหตุแบบเชิงเส้นมีข้อจำกัดในการวิเคราะห์มากขึ้น เมื่อต้องเจอกับไดอะแกรม RPC ที่มีโหนดมากกว่า 100 โหนด โมเดลสถาปัตยกรรมที่ล้าสมัย และข้อกำหนดที่ตกหล่น
• ในเหตุการณ์ quota rightsizer ภายในปี 2021 ฟีดแบ็กการใช้งานทรัพยากรที่ผิดพลาดและ pending change ที่ไม่ได้ถูกส่งต่อ ทำให้ระบบอยู่ในสภาวะเสี่ยงเป็นเวลาหลายสัปดาห์ และสุดท้ายก็นำไปสู่เหตุขัดข้อง
• Google ลงแรงในระดับ engineer-weeks สำหรับการวิเคราะห์ STPA เพื่อค้นพบสถานการณ์จำลองหลายร้อยกรณี และกำลังขยายขอบเขต SRE ไปสู่การออกแบบความปลอดภัยของ Google Cloud เครือข่ายภายใน และผลิตภัณฑ์หลายรายการ

---

ข้อจำกัดที่แนวทาง SRE เดิมต้องเผชิญ

• ผลิตภัณฑ์ของ Google มีผู้ใช้หลายพันล้านคนทั่วโลกทุกวัน และแม้ขนาดบริการจะเติบโตขึ้นมากในช่วง 25 ปีที่ผ่านมา เหตุขัดข้องกลับเกิดขึ้นน้อยลง
• ตลอดที่ผ่านมา SRE ขยายความเสถียรด้วย SLO, error budget, กลยุทธ์การแยกส่วน, postmortem ที่เข้มงวด และการ rollout แบบค่อยเป็นค่อยไป
• ตอนนี้โจทย์ไม่ใช่แค่การลดความถี่ของเหตุขัดข้อง แต่คือการรับมือกับความสูญเสียที่ต้องป้องกันไม่ให้เกิดขึ้นตั้งแต่แรก
  • การละเมิดข้อมูลส่วนบุคคล
  • การสูญหายของข้อมูล
  • ความล้มเหลวในการปฏิบัติตามกฎระเบียบ
• error budget แบบเดิมโดยรวมเหมาะกับเว็บเซอร์วิสที่มี state น้อย แต่ยังไม่เพียงพอสำหรับความสูญเสียที่ใกล้เคียงกับ error budget 0
• เมื่อ AI และ ML กลายเป็นแกนหลักของแทบทุกผลิตภัณฑ์ และ automation ทำให้การขยายระบบเป็นไปได้ ต้นทุนและประสิทธิภาพด้านพลังงานจึงสำคัญพอ ๆ กับฟีเจอร์สำหรับผู้ใช้

โครงสร้างของวิธีคิดแบบ SRE เดิม

• การวิเคราะห์ความเสี่ยงแบบดั้งเดิมประกอบด้วยองค์ประกอบหลักสามอย่าง
  • วิธีการสร้างโมเดลของระบบ
  • ทฤษฎีสาเหตุที่อธิบายว่าปัญหาเกิดขึ้นอย่างไร
  • อัลกอริทึมค้นหาความเสี่ยง
• แนวทางเดิมของ Google SRE ไม่ได้ถูกทำให้เป็นทฤษฎีอย่างเป็นทางการ แต่ก็วิเคราะห์ความเสี่ยงโดยยึดสถาปัตยกรรมซอฟต์แวร์และโมเดลการไหลของข้อมูลเป็นศูนย์กลาง
• โมเดลการไหลของข้อมูลแสดงให้เห็นว่า request บนเครือข่ายหรือข้อมูลเคลื่อนที่ระหว่างส่วนต่าง ๆ ของระบบอย่างไร
• โมเดลนี้นำไปสู่ การให้เหตุผลแบบเหตุ-ผลเชิงเส้น โดยธรรมชาติ
  • ดู SLO ของแต่ละคอมโพเนนต์เพื่อทำความเข้าใจการรับประกันด้านความเสถียร
  • ตรวจสอบว่าสามารถตอบสนองหรือเกินข้อกำหนดของ caller ได้หรือไม่
• ใน postmortem จะใช้ การให้เหตุผลแบบอุปนัย เพื่อสรุปรูปแบบทั่วไปจากเหตุการณ์เฉพาะ
  • ไม่หยุดอยู่แค่การแก้เหตุการณ์หนึ่งครั้ง แต่หาวิธีป้องกันเหตุการณ์ประเภทเดียวกันทั้งหมด
  • พยายามเปลี่ยน alert ที่เกิดซ้ำให้เป็นทางออกด้านวิศวกรรม เพื่อกำจัดสาเหตุของปัญหา

ข้อจำกัดของโมเดลการไหลของข้อมูลและการวิเคราะห์เหตุแบบเชิงเส้น

• เมื่อความซับซ้อนของระบบเพิ่มขึ้นทุกปี โมเดลการไหลของข้อมูลก็รับมือกับความซับซ้อนระดับ Google ได้ยากขึ้น
• ไดอะแกรม RPC และโมเดลสถาปัตยกรรมซอฟต์แวร์จะซับซ้อนเกินไปหากไม่ใช้ abstraction อย่างสม่ำเสมอ และมักคงอยู่ในสภาพที่ไม่สมบูรณ์หรือล้าสมัย
• โมเดลเหล่านี้ไม่สามารถแสดง พลวัต ของระบบได้เพียงพอ
  • RPC ใดสามารถเริ่ม flow ได้
  • error แพร่กระจายอย่างไร
  • คอมโพเนนต์ใดสามารถก่อให้เกิดเหตุขัดข้องรุนแรงได้ และคอมโพเนนต์ใดก่อได้เพียงปัญหาเล็กน้อย
  • ปฏิสัมพันธ์บางอย่างปลอดภัยในบริบทหนึ่ง แต่ไม่ปลอดภัยในอีกบริบทหนึ่งหรือไม่
  • เป้าหมายของระบบโดยรวมคืออะไร
  • แต่ละคอมโพเนนต์มีความรับผิดชอบอย่างไรต่อเป้าหมายโดยรวม
• ไดอะแกรมการไหลของข้อมูลที่มีโหนดมากกว่า 100 โหนดนั้นท่วมท้นตั้งแต่จุดเริ่มต้นของการค้นหาข้อบกพร่อง
• หากข้อกำหนดด้านความปลอดภัยตกหล่นหรือผิดพลาดในขั้นตอนนิยาม requirements แม้การออกแบบจะ implement requirements ได้สมบูรณ์ ความปลอดภัยของระบบก็ยังพังได้
• วิธีเรียนรู้จากข้อมูลเหตุขัดข้องมีข้อจำกัดในการคาดการณ์และป้องกันความสูญเสียที่ยังไม่เคยเกิดขึ้นเลย

STAMP เปลี่ยนวิธีคิดอย่างไร

• Google SRE รับเอาทฤษฎีระบบและทฤษฎีการควบคุมมาใช้ และนำเฟรมเวิร์ก STAMP ที่พัฒนาโดย Nancy Leveson จาก MIT มาใช้
• STAMP มองอุบัติเหตุไม่ใช่ห่วงโซ่ของความเสียหายของคอมโพเนนต์ แต่เป็นผลลัพธ์จากการควบคุมระบบที่ทำงานได้ไม่เพียงพอ
• CAST ใช้สำหรับการสอบสวนหลังเกิดอุบัติเหตุ ส่วน STPA ใช้สำหรับการวิเคราะห์ความเสี่ยง
• STAMP มองความปลอดภัยไม่ใช่คุณสมบัติของคอมโพเนนต์แต่ละตัว แต่เป็น คุณสมบัติเชิงอุบัติระดับระบบ
• คำถามในการวิเคราะห์ก็เปลี่ยนไปด้วย
  • คำถามเดิม: บริการซอฟต์แวร์ใดล้มเหลว
  • คำถามแบบ STAMP: ปฏิสัมพันธ์ใดของแต่ละส่วนในระบบที่ไม่ได้รับการควบคุมอย่างเพียงพอ
• อุบัติเหตุจำนวนมากในระบบซับซ้อนอาจเป็นผลจากการที่แต่ละคอมโพเนนต์ทำงานตามที่ออกแบบไว้ แต่เมื่อทำงานร่วมกันกลับสร้างสภาวะที่ไม่ปลอดภัย

เงื่อนไขสี่ข้อของทฤษฎีการควบคุม

• เงื่อนไขการควบคุมจากหนังสือ 『An Introduction to Cybernetics』 ของ W.R. Ashby ถูกผนวกเข้าในระเบียบวิธี STAMP ของ Leveson
• การควบคุม process ต้องมีเงื่อนไขสี่ข้อ
  • เงื่อนไขด้านเป้าหมาย: controller ต้องมีเป้าหมาย
  • เงื่อนไขด้านการกระทำ: controller ต้องสามารถส่งผลต่อสถานะของระบบได้
  • เงื่อนไขด้านโมเดล: controller ต้องมีโมเดลของระบบ
  • เงื่อนไขด้านความสามารถในการสังเกต: controller ต้องสามารถรับรู้สถานะของระบบได้
• ในงาน SRE เงื่อนไขเหล่านี้สามารถใช้เป็นเกณฑ์ตรวจสอบองค์ประกอบที่จำเป็นต่อการควบคุมระบบซับซ้อนได้อย่างมีประสิทธิภาพ

ช่องว่างสำหรับการตอบสนองที่สภาวะเสี่ยงสร้างขึ้น

• โมเดลห่วงโซ่เหตุแบบเชิงเส้นมักแสดงเพียงสองสถานะ คือการดำเนินงานปกติและการดำเนินงานที่เกิดความสูญเสีย
• การเปลี่ยนผ่านจากการดำเนินงานปกติไปสู่การดำเนินงานที่เกิดความสูญเสียมักเกิดขึ้นฉับพลัน และแทบไม่มีเวลาตอบสนองเพื่อป้องกันความสูญเสีย
• เหตุผลที่ SRE ใช้ทั้ง fast-burn และ slow-burn SLO ก็เพื่อจับปัญหาก่อนเกิดความเสียหายจริง แต่ SLO เหล่านี้มักเป็นคุณสมบัติของคอมโพเนนต์แต่ละตัว
• STAMP ทำให้สิ่งนี้เป็นรูปแบบอย่างเป็นทางการในฐานะ สภาวะเสี่ยง ระดับระบบ
  • สภาวะเสี่ยงคือสถานะของระบบหรือชุดเงื่อนไขที่เมื่อรวมกับเงื่อนไขแวดล้อมที่เลวร้ายที่สุดบางอย่างแล้ว จะสร้างความสูญเสียให้แก่ผู้มีส่วนได้ส่วนเสียหนึ่งรายหรือมากกว่า
• สภาวะเสี่ยงไม่ใช่ปรากฏการณ์ระดับ event เดี่ยวหรือคอมโพเนนต์เดี่ยว
• ระบบอาจอยู่ในสภาวะเสี่ยงเป็นเวลานานก่อนเกิดอุบัติเหตุ
  • มี bug เข้าไปแล้วแต่ยังไม่ถูก trigger
  • มี alert เกิดขึ้นแล้วแต่ไม่มีใครได้รับ
  • server ถูก provision ไว้น้อยเกินไป แต่จู่ ๆ ได้รับ traffic จากฟีเจอร์ยอดนิยม
• เป้าหมายทางวิศวกรรมไม่ใช่การกำจัด failure เดี่ยวทุกกรณี แต่คือการไม่ให้ระบบเข้าสู่สภาวะเสี่ยง หรือทำให้ระบบกลับจากสภาวะเสี่ยงสู่การดำเนินงานปกติ

กรณี quota rightsizer ปี 2021

• Google ตั้งค่าและบังคับใช้ resource quota ของซอฟต์แวร์บางส่วนในโครงสร้างพื้นฐานภายใน
• เพื่อเพิ่มประสิทธิภาพ จะ monitor ว่าแต่ละบริการใช้ quota ไปเท่าไร และหากใช้น้อยอย่างต่อเนื่องก็จะลด quota ลงโดยอัตโนมัติ
• จากมุมมอง STPA quota rightsizer มี การกระทำควบคุม คือการลด quota ของบริการ
• กรณีที่การกระทำนี้ไม่ปลอดภัย คือเมื่อ rightsizer ลด quota ลงต่ำกว่าปริมาณที่บริการต้องการจริง
  • บริการจะเข้าสู่สภาวะขาดแคลนทรัพยากร
  • ใน STPA เรียกสิ่งนี้ว่า unsafe control action หรือ UCA
• UCA มีสี่ประเภท
  • ไม่ได้ให้การกระทำควบคุมที่จำเป็น
  • ให้การกระทำควบคุมที่ไม่ถูกต้องหรือไม่เพียงพอ
  • ให้การกระทำควบคุมในเวลาหรือลำดับที่ผิด
  • หยุดการกระทำควบคุมเร็วเกินไปหรือใช้นานเกินไป
• การลด quota ให้ต่ำกว่าปริมาณที่ต้องการจริงคือ UCA ประเภทที่สอง

จุดเปราะบางที่เผยให้เห็นในเส้นทางฟีดแบ็ก

• ข้อกำหนดด้านความปลอดภัยสามารถสรุปได้ว่า “quota rightsizer ต้องไม่ลด quota ให้ต่ำกว่าความต้องการปัจจุบันของบริการ”
• ข้อกำหนดนี้มีประโยชน์ต่อการออกแบบในอนาคต แผนการทดสอบ และความเข้าใจระบบ
• STPA วางโครงสร้างการวิเคราะห์เพื่อค้นหาสถานการณ์จำลองที่เป็นรูปธรรมซึ่งทำให้ละเมิดข้อกำหนดด้านความปลอดภัยนี้
• ในกรณี rightsizer สามารถตรวจสอบสถานการณ์ตัวอย่างหลักได้สี่แบบ
  • rightsizer เองทำงานผิดพลาด
  • rightsizer ได้รับฟีดแบ็กผิดพลาดหรือไม่ได้รับฟีดแบ็กเลย
  • rightsizer พยายามส่ง action แล้ว แต่ระบบ quota ไม่ได้รับ
  • ระบบ quota เองทำงานผิดพลาด
• สถานการณ์ที่เด่นชัดในเหตุการณ์จริงคือกรณีที่ ฟีดแบ็กการใช้งานทรัพยากรปัจจุบัน ถูกคำนวณต่ำเกินไป
  • การคำนวณการใช้งานทรัพยากรมี data collector หลายตัวและ logic การ aggregate ที่ซับซ้อน
  • หากผลคำนวณต่ำกว่าความเป็นจริง rightsizer จะทำงานตามที่ออกแบบไว้ แต่กลับลด quota ผิดพลาด
• เดิมทีมีการให้ความสนใจมากกับอัลกอริทึมปรับ quota และความถูกต้องของ output แต่เส้นทางฟีดแบ็กถูกทำความเข้าใจน้อยกว่า
• STPA ช่วยให้ค้นหาปัญหาได้ทั้งในเส้นทางควบคุมและเส้นทางฟีดแบ็ก และในการวิเคราะห์ระบบหลายแห่งของ Google ก็พบอยู่บ่อยครั้งว่าเส้นทางฟีดแบ็กถูกทำความเข้าใจน้อยกว่า

ลำดับเหตุการณ์ที่อุบัติเหตุนำไปสู่ความสูญเสีย

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

ทิศทางที่ Google SRE กำลังมุ่งไป

• Google SRE ไม่มองความซับซ้อนว่าเป็น bug แต่กำลังเปลี่ยนไปสู่แนวทางด้านความเสถียรที่ครอบคลุมและเชิงรุกมากขึ้น โดยใช้ทฤษฎีการควบคุม, STPA และ CAST
• เป้าหมายไม่ใช่แค่การตอบสนองต่อเหตุขัดข้อง แต่คือการออกแบบระบบที่ปลอดภัยยิ่งขึ้นตั้งแต่แรก
• Google วิเคราะห์ระบบที่ซับซ้อนที่สุดบางส่วนด้วย STPA และค้นพบสถานการณ์จำลองหลายร้อยกรณีที่มีขอบเขตผลกระทบหลากหลาย โดยใช้แรงงานระดับ engineer-weeks ต่อการวิเคราะห์หนึ่งครั้ง
• สถานการณ์ที่ค้นพบถูกบรรเทาก่อนที่จะนำไปสู่เหตุขัดข้อง
  • การแก้ไขชั่วคราวอย่างรวดเร็ว
  • งานวิศวกรรมซอฟต์แวร์ที่วางแผนอย่างรอบคอบมากขึ้น
  • การใช้กระบวนการวางแผนประจำของ Google เพื่อลดต้นทุนและการหยุดชะงัก
• งานปัจจุบันมุ่งเน้นไปที่ระบบ Google Cloud ที่ซับซ้อนมาก ระบบเครือข่ายภายในขนาดใหญ่ และผลิตภัณฑ์ Google หลายรายการ
• การเปลี่ยนผ่านของ SRE ไปสู่ระเบียบวิธีด้านความปลอดภัยของระบบ มอบวิธีใหม่ให้นักวิศวกรรมทำความเข้าใจระบบที่ตนสร้าง และมุ่งไปสู่การให้การรับประกันที่แข็งแกร่งขึ้นเกี่ยวกับวิธีที่ระบบทำงาน