STPA - บทเรียนวิธีป้องกันเหตุขัดข้องแบบใหม่ของ Google SRE

 (sre.google)
8 คะแนน โดย GN⁺ 2025-03-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • STPA(System Theoretic Process Analysis, การวิเคราะห์กระบวนการเชิงทฤษฎีระบบ) คือวิธีการสร้างแบบจำลอง วงจรควบคุม-ป้อนกลับ ของระบบซับซ้อน โดยอาศัยทฤษฎีระบบและทฤษฎีการควบคุม
    • Google ใช้ STPA เพื่อวิเคราะห์ระบบซอฟต์แวร์และค้นหาความเสี่ยงแฝง
  • STPA มองความปลอดภัยของระบบเป็น ปัญหาการควบคุม และ วิเคราะห์การกระทำควบคุมทั้งหมดที่อาจทำให้ระบบเข้าสู่สถานะอันตราย
  • เป็นแนวทางที่มุ่งหา สาเหตุราก โดยโฟกัสที่สถานะอันตราย มากกว่าผลลัพธ์ของการกระทำแต่ละอย่าง
    • หากเข้าใจการกระทำควบคุมที่นำไปสู่สถานะอันตราย ก็จะสามารถป้องกันหรือกู้คืนอัตโนมัติได้
    • หากกู้คืนอัตโนมัติได้ยาก ก็สามารถแจ้งเตือนผู้ปฏิบัติงานที่เป็นมนุษย์ได้

ทำไม Google จึงปรับแต่งการสอน STPA

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

ความพยายามช่วงแรกในการสอน STPA

  • เริ่มการสอนช่วงแรกตั้งแต่ 2021 (สำหรับวิศวกร Google 40 คน)
  • ใช้กรณีศึกษาของระบบกายภาพ (เช่น เหตุการณ์ตกของ Mars Polar Lander) → วิศวกรซอฟต์แวร์รู้สึกร่วมได้น้อย
  • ตระหนักว่าจำเป็นต้องมีกรณีศึกษาจริงที่นำไปใช้กับระบบของ Google

การสอนแนวคิดเรื่องโครงสร้างการควบคุม

  • โครงสร้างการควบคุม(control structure) ประกอบขึ้นจากวงจรควบคุม-ป้อนกลับพื้นฐาน
    • คอนโทรลเลอร์ ควบคุมการเปลี่ยนแปลงสถานะ → ตรวจสอบสถานะผ่าน feedback แล้วตัดสินใจการกระทำถัดไป
  • ตัวอย่างการประยุกต์ใช้ในสภาพแวดล้อมซอฟต์แวร์
    • ตัวอย่าง: การลบหรือแก้ไขเนื้อหาที่ไม่เหมาะสมในฐานข้อมูลเนื้อหาที่ผู้ใช้สร้างขึ้น
    • หากวงจร feedback ถูกออกแบบไม่ดี ก็อาจเกิดการกระทำควบคุมที่ผิดพลาดได้
  • ความท้าทายด้านการสอน
    • เป็นเรื่องยากที่จะสอนการออกแบบโครงสร้างการควบคุมที่มีประโยชน์ภายในเวลาที่จำกัด
    • เนื่องจากแต่ละระบบซอฟต์แวร์มีโครงสร้างการควบคุมต่างกัน จึงให้ feedback ได้ยาก

กลยุทธ์การปรับปรุงการสอน STPA

  • สอนทุกขั้นตอนของ STPA → สนับสนุนให้วิศวกรสามารถทำ STPA ได้อย่างอิสระ
  • ใช้กรณีศึกษาจริงของ Google → อธิบายทฤษฎีแล้วจึงนำไปใช้กับกรณีจริง
  • เน้นการเสริม เส้นทางป้อนกลับ ของโครงสร้างการควบคุม
    • วิเคราะห์กรณีที่ feedback ผิดพลาด → เกิดการกระทำควบคุมที่ผิดพลาด → นำไปสู่เหตุขัดข้อง
    • การขาด feedback สำหรับผู้ปฏิบัติงานที่เป็นมนุษย์ → ทำให้เกิดสถานะอันตราย

ความสำคัญของ feedback

  • ในระบบหนึ่งของ Google มีการกระทำควบคุมที่ผิดพลาดเกิดขึ้นหลังจากผ่านไป 30 วันเนื่องจาก feedback ที่ผิดพลาด → เกิดเหตุขัดข้อง
  • สาเหตุคือ feedback ที่ผิดพลาดและการขาด feedback ให้กับผู้ปฏิบัติงานที่เป็นมนุษย์
  • หากออกแบบ feedback ได้อย่างเหมาะสม ก็สามารถป้องกันเหตุขัดข้องได้
  • การระเบิดของจรวด Ariane 5 ก็เป็นกรณีตัวอย่างของข้อผิดพลาดด้าน feedback
    • เกิดข้อผิดพลาดระหว่างการแปลงข้อมูล floating-point เป็นจำนวนเต็ม
    • ข้อผิดพลาดของ feedback → รับรู้สถานะผิดพลาด → ทิศทางจรวดผิดพลาดและระเบิด

Dataflow Diagram vs. โครงสร้างการควบคุม

  • Dataflow Diagram
    • แสดงว่าข้อมูลเคลื่อนที่ระหว่างคอมโพเนนต์ซอฟต์แวร์อย่างไร
    • ไม่ได้แสดง feedback และโครงสร้างการควบคุมอย่างชัดเจน
  • โครงสร้างการควบคุม(Control Structure)
    • แสดงการกระทำควบคุมและ feedback → ทำให้ลำดับชั้นการควบคุมชัดเจน
    • ระบุปัญหา feedback ได้ง่าย → ติดตามสาเหตุของปัญหาในปฏิสัมพันธ์ของระบบที่ซับซ้อนได้

ผลของการนำ STPA ไปใช้

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

การเปลี่ยนแปลงของกลยุทธ์การสอน

  • จากการสอนที่ใช้เวลานาน → เปลี่ยนเป็นเซสชันสั้น
    • ทิวทอเรียล 30–60 นาที → ช่วยกระตุ้นให้วิศวกรที่สนใจเข้าร่วมเวิร์กช็อป
  • นำโมเดลการเรียนรู้แบบขับเคลื่อนตนเองมาใช้
    • วิดีโอสั้น + แบบฝึกหัด → กระตุ้นให้ลองใช้ STPA กับระบบจริง
    • เสริมการสอนเพื่อให้สามารถทำ STPA ขั้นต้นได้โดยไม่ต้องพึ่งผู้เชี่ยวชาญ

กลยุทธ์การขยาย STPA ภายใน Google

  • สร้างผู้เชี่ยวชาญด้าน STPA → ทำให้สามารถเผยแพร่ STPA ภายในทีมได้
  • ความสำเร็จในช่วงแรก → ขยายไปยังทีมอื่น → นำ STPA ไปใช้ทั่วทั้งองค์กร
  • หลังผ่านการฝึก STPA แล้ว สามารถกำจัดปัจจัยเสี่ยงได้ล่วงหน้าตั้งแต่ขั้นตอนการออกแบบ

ยังนำไปใช้ในบริษัทอื่นได้

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

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

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

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

  • มีกรณีที่ Google ได้รับฟีดแบ็กผิดพลาดจาก software controller จนทำให้เกิดการสั่งการควบคุมที่เป็นอันตราย

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

  • บทเรียน STPA มีโครงสร้างที่ดี และตัวอย่างของ Google ก็ช่วยได้มาก

    • แต่ในบทความเองกลับไม่มีตัวอย่างที่เป็นรูปธรรม

  • STPA เป็นเฟรมเวิร์กสำหรับรีวิวการออกแบบเพื่อค้นหา failure mode ที่ไม่ชัดเจนกว่าเดิม

    • FMEA ได้รับความนิยมมากกว่า แต่จะลิสต์ได้เฉพาะ failure mode ที่รู้อยู่แล้ว
    • STPA ช่วยเติมเต็ม failure mode ที่เราไม่ได้นึกถึง

  • มีความเห็นว่าเข้าใจยาก แต่ก็อยากรู้

    • ต้องการคำอธิบายที่เป็นรูปธรรมว่ามันถูกนำไปใช้กับบริการใดบริการหนึ่งของ Google อย่างไร
    • คำว่า "B ได้รับฟีดแบ็กจาก C ไม่เพียงพอ" ว่าทำไมมันถึงแย่ ยังอธิบายไม่พอ

  • ถ้า STPA มีกรณีจริงที่ Google ใช้แก้ปัญหาความน่าเชื่อถือได้สำเร็จ ก็น่าจะน่าเชื่อถือมากกว่านี้

  • STAMP/STPA ทำงานได้ดีในฐานะโมเดลและวิธีวิทยาสำหรับระบบที่ซับซ้อน

    • เคยสนใจเรื่องการทำ cyber risk quantification
    • ในแนวทางอื่น ๆ ไม่มีโมเดลที่ทำให้เข้าใจการสั่งการควบคุมที่เป็นอันตรายได้ง่าย
    • อยากให้มีบริษัทนำไปใช้มากกว่านี้

  • หลังจากร่วมมือกับผู้เชี่ยวชาญระบบเพื่อสร้าง control structure ก็สังเกตได้ทันทีว่าฟีดแบ็กจาก controller C ไปยัง B ไม่เพียงพอ

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

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

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

  • มีความเห็นว่าอยากให้ Google เงียบ ๆ ไปสัก 1 ปี พร้อมส่งเสียงเหมือนเครื่องดูดฝุ่น