▲

GN⁺: STPA - Google SRE의 새로운 장애 예방 방법 교육

 (sre.google)
8P by neo 6일전 | ★ favorite | 댓글 1개
  • STPA(System Theoretic Process Analysis, 시스템 이론적 프로세스 분석) 는 시스템 및 제어 이론을 기반으로 복잡한 시스템의 제어-피드백 루프를 모델링하는 방법
    • 구글은 STPA을 사용하여 소프트웨어 시스템을 분석하고 잠재적인 위험을 발견
  • STPA는 시스템 안전성을 제어 문제로 다루며, 시스템이 위험 상태에 빠질 수 있는 모든 제어 동작을 분석함
  • 개별 동작의 결과보다는 위험 상태에 집중해 근본 원인을 찾는 방식
    • 위험 상태로 이어지는 제어 동작을 이해하면, 이를 예방하거나 자동 복구 가능
    • 자동 복구가 어려운 경우에는 인간 오퍼레이터에게 경고 가능

Google이 STPA 교육을 커스텀하는 이유

  • STPA를 통해 미확인된 문제를 사전에 발견하고 장애를 예방한 성공 사례가 늘어남
  • 기존 STPA 교육 자료는 물리 시스템 중심으로 구성돼 있어 소프트웨어 환경에 적용하기 어려움
  • Google의 순수 소프트웨어 시스템에 맞춘 맞춤형 교육이 필요해짐

초기 STPA 교육 시도

  • 2021년부터 초기 교육 시작 (40명의 Google 엔지니어 대상)
  • 물리 시스템 사례 (예: Mars Polar Lander 추락) 사용 → 소프트웨어 엔지니어의 공감 부족
  • Google 시스템에 적용한 실제 사례가 필요하다는 점 인식

제어 구조 개념 교육

  • 제어 구조(control structure) 는 기본 제어-피드백 루프로 구성됨
    • 컨트롤러가 상태 변경 제어 → 피드백으로 상태 확인 후 다음 동작 결정
  • 소프트웨어 환경에서 적용 예시
    • 예: 사용자 생성 콘텐츠 데이터베이스에서 잘못된 콘텐츠 삭제 또는 수정
    • 피드백 루프가 제대로 설계되지 않으면 잘못된 제어 동작 발생 가능
  • 교육 도전 과제
    • 제한된 시간 내에 유용한 제어 구조 설계 교육이 어려움
    • 소프트웨어 시스템마다 제어 구조가 달라 피드백 제공 어려움

STPA 교육 개선 전략

  • 모든 STPA 단계 교육 → 엔지니어가 독립적으로 STPA 수행 가능하도록 지원
  • Google의 실제 사례 활용 → 이론 설명 후 실제 사례 적용
  • 제어 구조의 피드백 경로 강화에 초점
    • 잘못된 피드백 → 잘못된 제어 동작 발생 → 장애 발생 사례 분석
    • 인간 오퍼레이터에 대한 피드백 부족 → 위험 상태 발생

피드백의 중요성

  • 한 Google 시스템에서 잘못된 피드백으로 인해 30일 후 잘못된 제어 동작 발생 → 장애 발생
  • 잘못된 피드백 및 인간 오퍼레이터에게 피드백 부족이 원인
  • 피드백 설계가 제대로 이루어지면 장애 예방 가능
  • Ariane 5 로켓 폭발도 피드백 오류 사례
    • 부동소수점 데이터를 정수로 변환하면서 오류 발생
    • 피드백 오류 → 잘못된 상태 인식 → 로켓 방향 오류 및 폭발

데이터 흐름 다이어그램 vs. 제어 구조

  • 데이터 흐름 다이어그램(Dataflow Diagram)
    • 데이터가 소프트웨어 컴포넌트 간에 어떻게 이동하는지 표시
    • 피드백 및 제어 구조 명확하지 않음
  • 제어 구조(Control Structure)
    • 제어 동작 및 피드백 표시 → 제어 계층 구조 명확
    • 피드백 문제 파악 용이 → 복잡한 시스템 상호작용에서 문제 원인 추적 가능

STPA 적용 효과

  • 복잡한 소프트웨어에서 수백만 줄의 코드 중 문제 발생 가능성이 높은 부분을 수백 줄로 좁힘
  • 위험한 제어 동작을 시나리오화 → 문제 코드 식별 가능
  • 실제 사례에서 제어 구조 구축 후 피드백 부족 식별 및 수정

교육 전략의 변화

  • 긴 교육 시간 → 짧은 교육 세션으로 전환
    • 30분~60분 튜토리얼 → 관심 있는 엔지니어가 워크숍 참여 유도
  • 자기 주도형 학습 모델 도입
    • 짧은 동영상 + 과제 → 실제 시스템에 STPA 적용 유도
    • 전문가의 개입 없이 초기 STPA 수행 가능하도록 교육 강화

Google에서 STPA 확산 전략

  • STPA 전문가 양성 → 팀 내부에서 STPA 전파 가능
  • 초기 성공 → 다른 팀으로 확산 → 조직 전반에 STPA 적용
  • STPA 훈련 후 설계 단계에서 위험 요소 미리 제거 가능

다른 기업에서도 적용 가능

  • STPA는 복잡한 소프트웨어 시스템에서 "미확인된 위험 요소"를 찾는 강력한 도구
  • 소규모 팀에서 시작해 STPA 전문가 주도로 확산 가능
  • 기업에 맞는 맞춤형 STPA 교육 개발이 핵심
  • 초기 시행착오 후 방향 수정 가능 → 궁극적으로 시스템 안정성과 신뢰성 향상
▲
neo 6일전  [-]
Hacker News 의견

  • Google에서 소프트웨어 컨트롤러가 잘못된 피드백을 받아 위험한 제어 동작을 실행한 사례가 있음

    • 이 동작은 30일 후에 실행되도록 예약되었음
    • 위험한 동작이 발생할 것이라는 지표가 있었지만, 이를 모니터링하는 엔지니어가 없었음
    • 결국 30일 후에 위험한 제어 동작이 발생하여 서비스 중단이 일어났음
    • 이 사건이 정부 데이터베이스 삭제 사건인지 궁금해하는 의견이 있음
    • 비난 없는 일반화 시도가 좋지만, 너무 과장된 스타일로 쓰여져 배울 것이 없었음

  • STPA 수업이 잘 구조화되어 있으며, 구글 예시가 도움이 되었음

    • 그러나 기사 자체에는 구체적인 예시가 없었음

  • STPA는 덜 명확한 실패 모드를 찾기 위한 디자인 리뷰 프레임워크임

    • FMEA는 더 인기 있지만, 이미 알고 있는 실패 모드만 목록화함
    • STPA는 생각하지 못한 실패 모드를 채워줌

  • 이해하기 어렵지만 알고 싶다는 의견이 있음

    • 구글에서 특정 서비스에 대해 어떻게 적용되는지 구체적인 설명이 필요함
    • "B가 C로부터 피드백이 부족하다"는 것이 왜 나쁜지 설명이 부족함

  • STPA가 구글에서 신뢰성 문제를 해결한 실제 사례가 있었다면 더 설득력 있었을 것임

  • STAMP/STPA는 복잡한 시스템에 대한 모델과 방법론으로 잘 작동함

    • 사이버 리스크 정량화에 관심이 있었음
    • 다른 접근법에서는 위험한 제어 동작을 쉽게 이해할 수 있는 모델이 주어지지 않음
    • 더 많은 회사들이 이를 채택했으면 좋겠음

  • 시스템 전문가들과 협력하여 제어 구조를 구축한 후, 컨트롤러 C에서 B로의 피드백이 부족하다는 것을 즉시 알게 되었음

    • D를 통한 피드백 루프가 있음
    • B에서 D로의 직접적인 연결이 없는 문제는 왜 적용되지 않는지 궁금해함
    • 다시 읽어보니 수직 방향이 제어와 피드백을 나타내는 데 중요함을 알게 되었음

  • 기업의 과장된 이야기, 유행어, 오래된 아이디어를 혁신적으로 보이게 하려는 시도임

    • 어린 시절 라디오 수리 이야기를 STPA와 연결하려는 어색한 시도가 있음
    • 구글이 STPA를 소프트웨어에 적용한 것이 혁신이라고 주장하지만, 이는 오래된 방법임
    • 대부분의 내용은 피드백 루프와 제어 구조에 대한 기본적인 엔지니어링 개념임
    • 실제 메시지는 구글이 내부 교육 프로그램을 만들었다는 것임
    • 끝부분은 STPA를 사용하지 않으면 안 된다는 식의 전형적인 기업 전략임

  • 구글이 1년 동안 진공 청소기 소리를 내며 조용히 있었으면 좋겠다는 의견이 있음

답변달기