วิวัฒนาการของ SRE ที่ Google

 (usenix.org)
4 คะแนน โดย GN⁺ 2025-01-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผลิตภัณฑ์ของ Google ถูกใช้งานโดยผู้คนหลายพันล้านคนทั่วโลก และความสำคัญของการให้ผลิตภัณฑ์เหล่านี้ทำงานได้อย่างเสถียรเป็นสิ่งที่สำคัญมากทีเดียว ทีม SRE ของ Google ได้พัฒนาวิธีการต่าง ๆ มาเพื่อยกระดับความน่าเชื่อถือของบริการ
  • เทคนิค SRE แบบดั้งเดิม (เช่น error budget, postmortem) มีส่วนสำคัญอย่างมากต่อการขยายขนาดบริการเว็บของ Google
  • เมื่อมีการใช้งาน AI/ML เพิ่มขึ้น ความซับซ้อนของระบบจึงสูงขึ้นมาก จำเป็นต้องมีแนวทางใหม่
  • ทฤษฎีระบบและทฤษฎีควบคุมมีประโยชน์ในการทำความเข้าใจปฏิสัมพันธ์ที่ซับซ้อนอย่างเป็นระบบ
  • จำเป็นต้องมีแนวทางที่รับประกันความปลอดภัยในระดับการออกแบบของระบบต้นแบบ ไม่ใช่วิธีการที่แก้ปัญหาหลังเกิดเหตุเพียงอย่างเดียว

ภาพรวม STAMP

  • STAMP (System-Theoretic Accident Model and Processes) ที่ศาสตราจารย์ Nancy Leveson แห่ง MIT เสนอ เป็นแนวทางในการวิเคราะห์อุบัติเหตุ (เหตุการณ์) โดยมองจากมุมปฏิสัมพันธ์ของระบบที่ซับซ้อน มากกว่าความผิดพลาดของชิ้นส่วนรายตัว
  • ไม่เน้นสาเหตุเชิงเหตุผลแบบเดิมๆ (เช่น “มีบั๊กจึงเกิดความล้มเหลว”) แต่ให้ความสำคัญกับว่า “ระบบทั้งระบบหลุดเข้าไปในเส้นทางการควบคุมที่ผิดปกติอย่างไร”
  • ใช้ Causal Analysis based on Systems Theory (CAST) เพื่อรื้อฟื้นเหตุการณ์อุบัติเหตุ และใช้ System-Theoretic Process Analysis (STPA) เพื่อระบุปัจจัยเสี่ยงล่วงหน้า

พื้นฐานของทฤษฎีควบคุม – เงื่อนไขทั้งสี่

  • ในทฤษฎีควบคุม จำเป็นต้องมีเงื่อนไข 4 อย่างเพื่อให้การควบคุมมีประสิทธิภาพ
    • เงื่อนไขเป้าหมาย: ต้องมีเป้าหมาย (เช่น การคงค่าตัวชี้วัดบางตัว)
    • เงื่อนไขการกระทำ: ต้องสามารถมีผลต่อสภาพระบบเพื่อให้บรรลุเป้าหมาย
    • เงื่อนไขแบบจำลอง: ต้องมีแบบจำลองเพื่อทำความเข้าใจระบบ (ทั้งภายในและภายนอก)
    • เงื่อนไขความสังเกตได้: ต้องมีระบบการสังเกต เช่น เซนเซอร์ เพื่อรับรู้สถานะปัจจุบันของระบบ

การมองเหตุขัดข้อง (Outage) เป็นปัญหาด้านการควบคุม

  • เดิมทีนิยมอธิบายเหตุขัดข้องในเชิง “ความล้มเหลวซ้อนต่อกัน” อย่างชัดเจน
  • STAMP อธิบายเชิงมุมมอง “การควบคุมและปฏิสัมพันธ์ที่ไม่เหมาะสม” และทำให้ความปลอดภัยได้รับการรับประกันในระดับระบบ
  • ไม่ได้มองหาเฉพาะว่า “การล้มเหลวตัวแรกเริ่มต้นที่ใด” แต่ตรวจสอบอย่างครบวงจรว่ามี “เส้นทางการควบคุม/การตอบกลับใดผิดปกติ”

สร้างเวลาอาศัยสถานะความเสี่ยง (Hazard)

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

ตัวอย่างจริง

  • “Quota Rightsizer” ภายใน Google คอยจัดสรรทรัพยากรใหม่ตามปริมาณการใช้งานของบริการ
  • ในมุม STPA สามารถระบุล่วงหน้าได้ว่า "สถานการณ์ที่รับข้อมูลการใช้งานผิดพลาด และลดทรัพยากรลงต่ำกว่าความต้องการจริง" อาจเกิดขึ้นได้
  • ในขั้นตอนออกแบบเดิมมักจะโฟกัสเฉพาะ “ตรรกะการควบคุมที่ถูกต้อง” แต่เมื่อใช้ STPA แล้วพบประเด็นปัญหาที่เส้นทางการตอบกลับ (เช่น กระบวนการคำนวณการใช้ทรัพยากร)
  • ในปี 2021 ข้อผิดพลาดในการตอบกลับสะสมต่อเนื่องและนำไปสู่ปัญหาใหญ่ พร้อมกับมีข้อมูลว่าได้อยู่ในสถานะ Hazard ติดต่อกันหลายสัปดาห์โดยไม่รู้ตัว

แนวโน้มในอนาคต

  • Google SRE มุ่งสู่ความปลอดภัยระดับสูงขึ้นและการจัดการความซับซ้อนผ่านแนวทางที่ยึดฐานจากทฤษฎีระบบ เช่น STAMP, STPA และ CAST
  • แม้จะลงทุนด้านวิศวกรรมเพียงเล็กน้อย (ราวไม่กี่สัปดาห์) ก็สามารถค้นพบความเสี่ยงเชิงสถานการณ์ที่เป็นไปได้มากมายในระบบขนาดใหญ่ได้
  • หากนําการวิเคราะห์ตามทฤษฎีควบคุมเข้ามาเพิ่มเติมให้กับวัฒนธรรมความน่าเชื่อถือเดิม ความเป็นไปได้ในการให้บริการที่มีเสถียรภาพในยุค AI/ML จะสูงขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-05
ความคิดเห็นบน Hacker News

  • แนวทางวิศวกรรมของ Google อาจเป็นอันตรายต่อสตาร์ทอัพได้; SRE มักมีแนวโน้มจะแสดงอาการเป็นฮีโร่และพยายามแก้แบบร่างทางเทคนิคของทีมอื่นอีกครั้ง

    • คล้ายกับการที่ฝ่ายกฎหมายพยายามเข้ามาเป็นคนขับเคลื่อนการดำเนินงานของบริษัท

  • มีบางอย่างที่คล้ายกับหนังสือของ Sidney Dekker

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

  • แนวทาง CAST ดูน่าสนใจมาก

    • ต้องใช้การวิเคราะห์ความล้มเหลวและความล้มเหลวที่แทบไม่เกิดจริงจำนวนมาก และคนเป็นส่วนที่ยากที่สุดในการนำไปใช้งาน

  • มีความคล้ายคลึงที่น่าสนใจกับงานเชิงเหตุผลเชิงกล (mechanistic reasoning)

    • มอบกรอบการทำงานในการวิเคราะห์ว่าองค์ประกอบต่างๆ ในระบบปฏิสัมพันธ์กันอย่างไร

  • อยากรู้ว่ามีตัวอย่างการนำกรอบงานวิศวกรรมความปลอดภัยที่เป็นทางการไปใช้กับการวิเคราะห์ neural network หรือไม่

    • วิธีการติดตามความสัมพันธ์เชิงสาเหตุที่ซับซ้อนและพฤติกรรมระดับระบบอาจมีประโยชน์

  • แม้ตัวอย่าง "rightsizer" จะถูกวิเคราะห์ด้วยวิธีเดิม ก็อาจได้ผลลัพธ์เช่นกัน

    • แนวทางใหม่ดูง่ายกว่าและใช้งานได้จริงมากกว่า

  • เหตุผลที่ไม่ชอบการทดสอบซอฟต์แวร์ก็มาจากข้อบกพร่องที่มาจากปัจจัยภายนอก

    • แนวทางนี้อาจช่วยแก้ปัญหานั้นได้

  • CAST คล้ายคลึงกับการวิเคราะห์สาเหตุรากฐานหลายปัจจัย

    • สนับสนุน CAST ของศาสตราจารย์ Nancy Leveson จาก MIT

  • คำถามคือ SRE/DevOps คือส่วนหนึ่งของบทบาทประจำหรือไม่

    • ในหลายกรณี ผมคิดว่านี่อาจเป็นเพียงการปรับฉลากตำแหน่งงานด้านการดำเนินงานเดิม

  • คุณลักษณะเด่นของ Google SRE คือการปล่อยผลิตภัณฑ์ใหม่ต้องการการช่วยเหลือจาก SRE

    • SRE ที่มีจำนวนน้อยช่วยทำให้ไอเดียที่ดีๆ ดีขึ้นกว่าเดิม

  • บทความนี้ยาวเกินไปและยากต่อการจับประเด็นสำคัญ

    • การกล่าวถึง CAST และ STPA เป็นจุดที่สำคัญและมีคุณค่าที่สุด

  • สงสัยว่าแนวทางนี้มีคุณค่ากับองค์กรขนาดไม่ใช่ FAANG หรือไม่

    • มีแนวโน้มที่จะลงทุนกับการหลีกเลี่ยงความเสี่ยงมากเกินไป

  • คล้าย DevOps ความหมายของ SRE กำลังขยายตัว

    • SRE ทำหน้าที่หลากหลาย ตั้งแต่การเขียนซอฟต์แวร์ไปจนถึงการจัดการความล้มเหลวของระบบ