본문으로 건너뛰기

6.4 Linux incident workflow

Incident 중에는 원인 규명보다 사용자 영향 제한이 먼저일 수 있습니다. 관측, 완화, 진단, 복구, 회고를 구분하면 변경과 증거가 뒤섞이지 않습니다.

첫 10분​

  1. 영향 범위와 시작 시각을 확인합니다.
  2. error, latency, traffic을 비교합니다.
  3. CPU, memory, I/O, network 중 포화 자원을 고릅니다.
  4. 최근 배포, 설정, backup, failover를 timeline에 놓습니다.
  5. rollback, traffic 제한, read-only 전환 등 완화책을 평가합니다.

증거 보존​

date --iso-8601=seconds
uptime
vmstat 1 5
iostat -xz 1 5
cat /proc/pressure/{cpu,memory,io}
ss -s

출력을 incident 문서에 첨부하고 timezone을 명시합니다. 진단 중 service를 재시작하면 queue, process state, /proc 증거가 사라집니다. 재시작이 필요한 경우 먼저 최소 snapshot을 남깁니다.

완화 후​

  • 지표가 정상 범위로 돌아왔는지 확인합니다.
  • backlog와 retry가 다시 포화를 만들지 관찰합니다.
  • 임시 변경의 owner와 만료 시각을 기록합니다.
  • 재현 가능한 가설과 반증된 가설을 분리합니다.

Alert, dashboard, capacity, runbook 개선은 후속 작업으로 만듭니다.

“CPU가 높았다”가 아니라 어떤 workload가 어떤 제한에서 기다렸고 왜 사용자 영향으로 이어졌는지를 서술해야 재발 방지로 연결됩니다.