장애가 발생하면 원인을 찾기 시작한다. 분석하는 동안에도 고객 영향은 계속된다.
핫픽스(Hotfix)는 원인을 찾아 수정하고 검증한 뒤 배포해야 한다. 롤백(Rollback)이 가능한 상황이라면 이 시간을 기다리지 않고 고객 영향을 줄일 수 있다.
복구 시간은 고객 영향을 줄이는 조치를 언제 실행했는지에 따라 달라졌다. 장애 중에 원인을 얼마나 많이 알아냈는지는 복구로 바로 이어지지 않았다.
핫픽스를 하려면 먼저 원인을 좁혀야 한다. 코드를 수정한 뒤 검증하고 다시 배포해야 한다. 이 과정에서 새로운 문제가 생길 가능성도 확인해야 한다.
롤백은 문제가 생기기 전 상태로 돌아가는 조치다. 원인을 완전히 설명하지 못해도 실행할 수 있다. 이미 운영했던 상태로 돌아가기 때문에 결과도 비교적 예측하기 쉽다.
고객 영향이 발생한 상황에서는 이 시간 차이가 중요하다. 완전한 설명을 기다리는 동안 실패한 요청과 지연은 계속 쌓인다.
장애 중에도 분석은 필요하다. 다만 분석의 목표를 근본 원인 규명으로 잡으면 복구 결정이 늦어진다.
장애 중 분석은 다음 질문에 답할 수 있을 만큼 진행한다.
지금 고객 영향을 가장 빠르고 안전하게 줄일 수 있는 조치는 무엇인가?
최근 변경이 원인 후보라면 롤백 가능 여부를 먼저 본다. 자원이 포화됐다면 원인을 끝까지 추적하기 전에 스케일 조정으로 시간을 번다. 조치한 뒤에는 실제 고객 영향이 줄었는지 확인한다.
첫 조치 이후에도 고객 영향이 줄지 않으면 다른 조치를 검토한다. 원인을 얼마나 설명했는지보다 실패한 요청과 지연이 줄었는지를 확인한다.
되돌릴 수 없는 데이터 변경이 있거나 이전 버전에도 큰 문제가 있다면 롤백이 더 위험할 수 있다. 외부 의존성에서 시작된 장애라면 되돌릴 변경 자체가 없을 수도 있다.
이때는 트래픽 제한이나 스케일 조정처럼 되돌릴 수 있는 완화 조치를 찾는다. 판단 기준은 조치의 이름이 아니다. 실행까지 걸리는 시간과 실패했을 때 다시 돌아올 수 있는지를 본다.
복구를 먼저 했다고 원인 분석이 끝난 것은 아니다. 장애가 해소된 뒤에는 당시의 타임라인과 지표를 다시 확인한다. 근본 원인을 검증하고 재발 방지 조치를 정한다.
장애 중에 만든 가설은 시간이 부족한 상태에서 내린 판단이다. 복구 이후에는 그 가설이 증거와 맞는지 다시 확인해야 한다. 그렇지 않으면 빠른 복구가 잘못된 원인 분석으로 남을 수 있다.
원인을 끝까지 확인하는 일은 고객 영향이 멈춘 뒤에 이어간다.
팀 내부적으로는 롤백이나 증설처럼 장애 직후 실행할 조치를 No Brain Action이라고 불렀다. 배포 직후 장애가 나면 롤백하고 리소스 부하가 높으면 증설하는 식이다. 장애 중에 다시 고민하지 않고 반사적으로 실행할 수 있도록 행동 요령을 정해 뒀다.
사전 약속이 없으면 온콜 엔지니어는 장애 중에 조치의 필요성을 설명하고 승인을 기다리게 된다. 롤백 절차가 문서에만 있고 검증되지 않아도 실행은 늦어진다. 그만큼 고객 영향도 커진다.
평소에 롤백 방법을 검증하고 정해진 조건에서 바로 실행할 수 있어야 한다.
장애 중에는 어떤 조치가 고객 영향을 줄이는지가 가장 중요하다. 롤백이나 증설을 자동화하려면 어떤 상황에서 실행할지 기준이 정해져 있어야 한다.