장애 나면 다들 뭐부터 보나— "조사 레이어"라는 개념
장애 대응 얘기 나오면 다들 대시보드나 알림 얘기부터 한다. 근데 실제로 원인을 찾는 시간을 줄이는 건 대시보드가 아니라 다른 부분이라는 게, 최근 공개된 메타(Meta) 사내 사례에서 꽤 명확하게 드러났다. 정리해본다.
메타는 원인 조사를 관찰가능성(observability)과 아예 다른 시스템으로 분리해뒀다
메타는 작년 12월 자사 엔지니어링 블로그에 DrP라는 내부 툴을 공개했다. 하루 5만 건의 장애 원인 분석(RCA)을 자동으로 처리하고, 300개 이상의 팀이 5년 넘게 실제 운영에 쓰고 있는 시스템이다. MTTR(장애 해결까지 걸리는 시간) 개선폭은 팀마다 다른데, 분석 로직(애널라이저)을 10개 이상 갖춘 팀은 50~80% 단축, 아직 5개 미만인 팀도 10~15%는 줄었다고 한다.
여기서 흥미로운 설계 선택 하나: DrP는 대시보드나 트레이싱 같은 관찰가능성 스택과 완전히 분리된 별도 플랫폼이다. "무엇이 잘못됐는지 보여주는 것"과 "왜 잘못됐는지 조사하는 것"을 다른 시스템으로 취급한 것이다. 관찰가능성 스택은 신호(지표, 로그, 트레이스)를 모으고 보여주는 데는 강하지만, "이번 장애에서 뭘 확인했고 뭘 배제했는지"라는 조사의 상태(state) 자체를 저장하는 용도로는 설계돼 있지 않다. 그 상태는 결국 Slack 스레드나 사람 머릿속에만 남고, 장애가 끝나면 증발한다.
근데 이게 5만 건/일 규모에서만 의미 있는 얘기인가
레딧 r/sre에서 이 글에 달린 댓글 중 인상적인 지적이 있었다. "우리는 한 달에 심각한 장애 5건 정도인데, 이 정도 규모에서 패턴 학습(자동으로 과거 사례와 매칭하는 것)이 수렴할 만큼 데이터가 쌓이긴 어렵다"는 것. 맞는 말이다. 메타 수준의 자동 패턴 매칭은 그만한 볼륨이 있어야 값어치를 한다.
하지만 짚어야 할 건, DrP에서 정말 값진 부분은 패턴 학습이 아니라 "조사 레이어를 분리해서 저장한다"는 발상 자체다. 이건 장애가 한 달에 5건이든 50건이든 똑같이 통한다. 왜냐면 여기서 저장되는 건 다음 네 가지이기 때문이다.
- 타임라인: 언제 뭐가 감지됐고 언제 뭘 시도했는지
- 확인한 것: 어떤 가설을 검증해서 맞았는지
- 배제한 것: 어떤 가설을 확인해봤는데 아니었는지 (이게 의외로 제일 중요하다 — 안 그러면 다음 사람이 같은 삽질을 반복한다)
- 직전 변경 이력: 장애 직전에 배포·설정·피처 플래그·인프라 쪽에서 뭐가 바뀌었는지
이 네 가지는 대시보드에 안 나온다. 메트릭과 트레이스는 "무엇이 이상한가"는 보여주지만 "우리가 무엇을 이미 시도해봤는가"는 안 보여준다. 그리고 이 정보가 있어야 postmortem을 쓸 때도, 다음번 비슷한 장애가 났을 때도 시간이 절약된다.
작은 팀이 오늘부터 따라 할 수 있는 것
메타처럼 애널라이저 SDK를 만들 필요는 없다. 핵심만 가져오면 된다.
- 장애 채널(Slack이든 뭐든)에 스레드 대신 별도 문서나 이슈를 하나 파고, 거기에 타임라인/확인한 것/배제한 것을 실시간으로 적는다. 사후에 정리하지 말고 조사하면서 바로 적어야 한다 — 나중에 기억나는 버전은 항상 왜곡돼 있다.
- "직전 변경 이력"을 한 곳에서 조회 가능하게 만든다. 배포 로그, 설정 변경, 피처 플래그, 인프라 변경이 각각 다른 툴에 흩어져 있으면 이 질문에 답하는 데만 20분 걸린다. 이 부분이 실제로 체감상 원인 파악 시간을 가장 많이 줄여준다.
- postmortem을 "형식 갖추기용 문서"가 아니라 "다음에 검색해서 찾을 지식 베이스"로 취급한다. 검색이 안 되면 아무리 잘 써도 소용없다.
- 패턴 매칭·자동화는 이 기반이 갖춰진 다음에 고민해도 늦지 않다. 순서를 바꾸면 자동화할 대상 자체가 없어서 헛수고가 된다.
정리하면, 메타 사례에서 배울 건 "5만 건/일 자동화"가 아니라 "조사의 상태를 별도로, 검색 가능하게 남긴다"는 원칙이다. 이건 팀 규모와 무관하게 바로 적용된다.
참고: Meta 엔지니어링 블로그 - DrP, 레딧 r/sre 스레드(https://www.reddit.com/r/sre/comments/1utg8bx/)에서 정리된 논의 참고.