SRE 팀 리더를 맡은 뒤 상위 리더십에게 같은 요구를 계속 받았다. 처음 보는 서비스라도 장애 채널에 들어가 영향도를 확인하고 지금 무엇을 해야 하는지 답해야 했다.
서비스 코드나 최근 변경 내용을 모르는 상태에서 다음 조치를 제안하기는 어려웠다. 하지만 그런 상황에서도 SRE는 장애 대응의 방향을 짚어줄 것을 기대받았다.
더 많은 장애 채널에 들어가도 서비스 맥락을 모으는 데 시간이 걸렸다. 참여 횟수만 늘려서는 지원 범위를 넓힐 수 없었다.
서비스 팀은 코드와 비즈니스 흐름을 가장 잘 안다. 어떤 변경이 있었고 어떤 기능이 고객에게 영향을 주는지도 알고 있다.
SRE 팀은 다른 정보를 가지고 있다. 공통 인프라의 상태를 볼 수 있고 여러 서비스에 나타나는 신호를 연결할 수 있다. 평소에는 보이지 않던 의존 관계나 플랫폼 병목을 찾는 데도 유리하다.
SRE가 장애 채널에 들어가면 서비스 구조와 최근 변경부터 확인해야 했다. 초기에는 공통 인프라 상태를 보고 로그나 트레이스로 이상 구간을 좁히는 정도를 지원할 수 있었다. 서비스 맥락을 모르는 상태에서 다음 조치를 제안하는 데는 한계가 있었다.
참여 범위는 넓었지만 지원의 깊이는 서비스 맥락에 따라 달라질 수밖에 없었다.
장애 중에는 기술 분석만 필요한 것이 아니다. 어떤 고객이 영향을 받는지 확인해야 한다. 기능을 중단할지 이전 버전으로 되돌릴지도 결정해야 한다.
이 판단은 서비스를 운영하는 팀이 내려야 한다. SRE가 로그와 트레이스를 대신 볼 수는 있어도 비즈니스 영향과 변경 위험까지 대신 책임질 수는 없다.
대신 서비스 팀에 모든 대응을 맡기고 SRE가 빠지는 것도 답은 아니었다. 장애가 여러 서비스로 번지면 개별 팀은 자신의 시스템 밖에서 일어나는 일을 보기 어렵다. 공통 인프라나 네트워크가 원인이라면 서비스 코드만 확인해서는 방향을 잡을 수 없다.
그래서 책임을 다음 기준으로 나눴다.
- 서비스 팀은 고객 영향과 서비스 복구 결정을 책임진다.
- SRE는 공통 신호와 의존 관계를 확인하고 판단에 필요한 근거를 제공한다.
- Incident Commander는 진행 상태와 의사결정을 관리한다.
장애 대응은 특정 사람의 경험과 주의력에 의존해서는 안 된다고 판단했다. 누가 장애를 알아채고 대응에 참여하느냐에 따라 결과가 달라지지 않도록 시스템과 프로세스를 통해 해결해야 한다고 생각했다.
한 번에 모든 이상 상태를 다룰 수는 없었다. 비즈니스 영향도를 확인하고 영향이 큰 문제부터 우선순위를 정했다.
그 우선순위에 따라 경보를 구성했다. 누군가 문제를 발견하기를 기다리지 않고 경보를 받아 대응을 시작하게 했다.
누가 온콜을 맡았는지에 따라 장애 대응 결과가 달라져서는 안 됐다.
비즈니스 영향에 따라 우선순위를 정하고 경보로 빠르게 인지할 수 있어야 한다. 장애가 발생했을 때 누가 복구를 맡고 누가 대응 진행을 관리할지도 미리 정해져 있어야 한다.
그래서 개별 장애만 지원하지 않았다. 서비스 팀이 먼저 대응할 수 있도록 경보를 구성하고 프로세스와 정책을 만드는 데도 많은 리소스를 썼다.