Runbook

서비스 개발을 하다보면 운영이관을 위하여 시스템 설계 내역과 문제상황에 대한 대처법 등을 자세하게 기록한 문서를 만들어서 운영 담당 부서에 전달해야 하던 때가 있었다. 모든 상황을 가정하여 방대한 지침서를 만들어야 했기 때문에 이러한 운영매뉴얼을 만드는 것은 힘들고 까다로운 작업이었다.

그러던 중 서비스를 직접 개발하고 운영까지 하게된 적이 있었는데 이때는 기존과 다른 형식의 운영매뉴얼을 위키페이지로 만들었다. 처음 접하는 사람이라도 시스템을 이해하고 대응할 수 있도록 실용적이고 간결한 문서를 만들려고 했다. 기존의 다른 운영매뉴얼과 달리^[각주:1] 핵심만 뽑아서 문서를 만들었다. 제일 먼저 시스템의 목적을 간단하게 작성하고, 아키텍처를 그림과 함께 간단하게 설명했다. 그리고 API 목록을 작성하고 모니터링 지표를 설명했다. 모니터링 부분에서는 각 지표의 의미, 경고와 알림을 발생하는 특정 값, 그리고 취해야할 행동을 명세하였다. 그리고 각 지표의 위험 등급을 구분하여 문제상황을 전파하는 절차도 덧붙였다. 마지막으로 알려진 문제들 혹은 문제해결법(Troubleshooting)을 기록했다. 이 문서를 작성하기 시작한 목적은 스스로 편하기 위해서 였고, 다른 운영자로 교체되더라도 쉽게 적절한 대응을 할 수 있도록 돕기 위해서였다. 비유를 들자면 이런 것이다. 화재 경보가 울리면 소화기를 들고 불을 끈다와 같은 대응 방안을 미리 만들어 두고 실제 서비스에 문제가 생겼을 때 적절한 행동을 바로 취할 수 있도록 하는 것이다. 이렇게 초동 대응을 잘 하면 큰 불로 번지기 전에 문제를 수습할 수 있다. 어느 날 미국의 스타트업과 협업할 일이 있었는데, 그 들은 내가 그 동안 경험적으로 만들어온 문서와 똑같은 문서를 만들고 있었고 런북(Runbook)이라고 불렀다.

이런 이야기를 꺼내는 이유는 예전에 겪었던 웃픈 런북 때문이다. 런북을 어떤 방식으로 오해하고 잘못 작성할 수 있는 지에 대한 예를 들어보기 위함이다. 성장하고 있는 스타트업이었는데, 내부에서 개발자들은 바쁜 나날을 보내고 있었다. 전세계를 상대로 서비스를 만들다보니 하루 하루 문제가 터졌고 잠을 못잘 정도로 문제대응하느라 정신없었다. 그러다 어느 날 ‘Runbook’이라는 문서가 생겼다. 그나마 다행이라는 생각이 들었으나 곧 실망으로 바뀌었다. 처음엔 런북에 장애 발생 상황과 조치 사항을 기록했다. 그러나 시간이 지날수록 런북은 개발자 개인들의 장애 대응 일지로 변모하고 있었는데, 마치 자신이 실행한 명령어와 로그를 담은 시시콜콜한 장애 대응 일기를 다른 사람에게 공유하는 것이 런북이라고 생각하는 것 같았다. 시간이 흐르자 온콜(On-call) 순번이 된 사람은 깨알같이 작성된 어마어마한 양의 대하역사극 대본^[각주:2]을 읽어보고 문제 대응을 해야하는 상황이 되었다. 런북이 긴급상황에서 자신감이 되어주어야 하는데,^[각주:3] 반대의 상황이 되어버린 것이다. 경악할 만한 길이의 문서를 읽고 상황에 대응해야한다는 부담감때문에 On-call 입장에서는 자신의 순번에서 런북 읽을 일 없기만 기도할 뿐이었다.^[각주:4]

개인적인 생각으로는, 조금 무리하게 들리겠지만, 런북은 시간이 지남에 따라 점점 줄어야 한다. 운영 초반에는 런북의 대응 절차가 늘어날 수 있다. 그러나 문제가 될만한 것을 미리 예방하도록 시스템을 개선해간다면 긴급대응책은 점점 줄어들 것이다. 즉, 런북에 기록된 긴급대응책은 사후 부검(Postmertem)과 회고(Retrospective)과정을 통해 앞으로 해야할 일(Backlog)에 넣어서 개선해야한다.^[각주:5] 결론적으로 런북을 줄여나가는 좋은 접근방법은 다음과 같다. 먼저 긴급 대응법을 자동화 한다. 그리고 되도록 예방법을 만들어 미리 설계에 반영되도록 개선한다. 이러한 과정을 비유로 설명하면서, ‘건강해지기 위해 운동을 합시다’라고 개발자들에게 제안을 했었다. 그러나 ‘일단 죽지않고 살고나면 그 때 운동할 수 있지 않겠냐’는 반문을 들었다. 상황에 대한 각자의 해석과 시각은 다르기 때문에 그들은 그렇게 느낄 수 있다고 생각한다. 하지만, 그 굴레를 벗어날 가장 빠르고 확실한 동아줄을 잡길 권한다. 썩은 동아줄은 결국 끊어지고 말 것이다.

---

 

1. 보통의 운영 매뉴얼은 누가 언제 이걸 읽어볼까하는 의심이 들 정도로 문서 양이 많다. 운영을 하기 위해서 많은 정보를 미리 알아야하는 이유도 있겠지만, 개발 후 운영을 이관하는 과정에서 문서의 양을 기준으로 업무 성과를 평가하는 문화가 영향을 끼친 것도 있다고 생각한다. [본문으로]
2. 런북을 쓰기 시작한 지 몇 주 지나지 않았는데 읽어야할 문장이 200줄 넘게 있었다. 장애가 나면 그 원인과 상황 그리고 각자가 조치한 방법을 다 기록해 두었기 때문이었다. 당시 추세대로라면 50부작 대서사시 극본같은 런북이 금방 완성될 것처럼 보였다. [본문으로]
3. 긴급 상황에 대한 대응절차는 최대한 간결하고 명확하고 쉬워야 한다. [본문으로]
4. 당시 슬랙에서 제일 많이 본 밈이자 이모티콘은 두 손 모아 기도하는 모양(🙏)이었다. [본문으로]
5. https://youngookkim.tistory.com/106 [본문으로]