장애 발생과 대처에 관하여

장애 심각성 판단

엔지니어는 본질적으로 장애 발생시 발생 원인을 먼저 찾게 된다. 하지만 장애 발생 시 발생 원인을 파악하는 것 보다 장애의 심각성의 정도, 장애의 범위와 수준등의 장애의 성질에 대해서 먼저 파악하는 것이 중요하다.

본 강의에서 심각도는 아래의 기준으로 나누었다. | 심각도 | 설명 | | —— | ————————————————————————————————- | | S0 | 매우 치명적이고 심각한 상태로 대다수 사용자에게 주요 기능이 동작하지 않는 나쁜 사용경험 제공 | | S1 | 심각한 주요 기능 이외 기능이 기대와 다르게 동작하거나 기능이 제대로 동작하지 않는 경우 | | S2 | 특정 기준을 충족하지 못하거나 전체에 영향을 주지 않지만 일부 기능에 부자연스러운 사용 경험을 제공 | | S3 | 사소한 결함으로 주요 기능과 사용경험에 큰 영향은 없지만 여전히 수정될 필요가 있는 경우 |

예를 들어 아래의 그림에서 2번 장애는 main 흐름에 장애가 발생하고 있으므로 S0의 장애 등급을 받을 수 있지만 1번 장애(재로그인이나 재가입 등의 케이스가 되겠다.)의 경우 S1의 등급을 받을 수 있다.

근본 원인 분석 방법론

Fishbone Diagram

구조

• 머리(Head): 문제/결과(예: “릴리즈 빌드 실패율 15%”)
• 큰 뼈(Major bones): 원인 카테고리
  • 소프트웨어/서비스: People, Process, Tools, Requirements, Code, Environment 등으로 커스터마이즈
• 작은 뼈(Minor bones): 구체 원인(사실/데이터 기반)

장단점

• 장점
  • 시각적, 소통에 적합한 구조
• 단점
  • 예쁜 잡담’으로 전락
  • 카테고리 의존 편향.

5 Ways

구조

단순히 왜라는 질문을 반복적으로 진행하며 원인을 파악

문제: [측정 가능한 현상 / 기간]

왜1: [직접 원인]  (증거: …)
왜2: [그 원인의 원인]  (증거: …)
왜3: …
왜4: …
왜5: [루트 원인 후보]  (확증 계획: 실험/롤백/AB/로그)

대책:
- [조치1] (오너, 마감, 기대효과, 위험)
- [조치2] (…)
검증:
- 성공/실패 기준, 모니터링 지표, 관찰 기간

재발 장지

건강한 코드리뷰와 온콜 문화

실제로 코드 리뷰와 온콜 문화가 적적한 시기에 정착되지 않은 조직에서는 흔히들 말하는 가면 증후군의 증상이 나타났다. 즉 스스로가 계속해서 자신의 성과에 대해서 의심하게 된다.

Resiliance, Tolerance

단단한 시스템을 만들기 위해서는 아래의 조건을 만족하는 시스템을 만들기 위해 노력해야한다.

• System Level
  • 고가용성 아키텍쳐
  • 자동화된 장애 복구
• Software Level
  • 회복 가능한 코드 디자인 패턴
  • 회복 가능한 데이터 구조
• Team Level
  • 지식 공유와 문서화
  • 사후 리뷰 및 회고 문화

이러한 시스템을 만들기 위해서 우리는 그럼 구체적으로 어떤 노력을 해야할까

1. 리뷰 : 와성된 작업물에 대한 평가
   1. 주로 프로젝트나 작업물의 와성도와 품질을 검토하고 피드백 하는 것에 중점
2. 회고 : 개인이나 팀의 개선점 도출
   1. 주로 개인이나 팀의 프로세스와 협업 방식을 돌아보고 개선점을 찾는 것에 중점