SRE

개발과 운영이 나뉘어 있던 시절에는 두 쪽의 목표가 서로 부딪혔습니다. 개발은 기능을 빨리 내보내야 평가를 받고, 운영은 아무 일도 일어나지 않아야 평가를 받습니다. 배포는 변화를 뜻하고 변화는 사고의 재료라서, 운영은 배포를 늦추는 쪽으로 움직이고 개발은 밀어붙이는 쪽으로 움직였습니다.

페이지덱에서도 같은 모양이 생겼습니다. 장애가 몇 번 나자 배포를 주 1회로 줄였고, 한 번 나갈 때 담기는 변경이 커졌습니다. 변경이 커지자 원인을 찾기 어려워졌고, 배포가 더 무서워졌습니다.

장애 뒤에 남는 것도 문제였습니다. 새벽에 태오가 혼자 복구한 다음 회고는 조심하자는 말로 끝났고, 다음 달에 비슷한 일이 다시 났습니다. 조심은 사람이 바뀌거나 잊으면 사라집니다.

이 자리가 뒤집은 것은 안정성을 태도가 아니라 숫자로 다룬다는 점입니다. 어느 수준까지 안 멈추기로 할지 목표치를 정하고, 그 목표를 지키면서 허용되는 실패의 양을 계산해 둡니다. 그 양이 남아 있는 동안에는 배포를 막지 않습니다. 두 쪽이 다투는 대신 같은 표를 보게 만드는 것이 이 역할의 출발점입니다.

정해진 하루가 있는 자리는 아니지만, 시간이 가는 곳은 대개 여섯 군데입니다.

1. 지표를 확인합니다. 서비스 품질을 재는 실제 값인 SLI를 보고, 지키기로 정한 목표치인 SLO에 얼마나 여유가 있는지 봅니다. 여유분을 뜻하는 에러 버짓이 이번 달에 얼마 남았는지가 그날의 판단 기준이 됩니다. 남아 있으면 새 기능을 내보내고, 다 썼으면 안정성을 고치는 일에 사람을 붙입니다.
2. 당번을 섭니다. 정해진 시간에 장애 연락을 받기로 한 온콜 차례가 돌아오면 알림을 받고 정해진 시간 안에 붙습니다. 이 자리에서 중요한 것은 빠른 복구이고, 원인 규명은 복구 뒤로 미룹니다.
3. 사고를 기록합니다. 복구가 끝나면 포스트모템을 씁니다. 무슨 일이 언제 어떤 순서로 벌어졌는지, 왜 더 빨리 알아채지 못했는지, 무엇을 고치면 같은 일이 안 생기는지를 적습니다. 사람을 탓하지 않는 것이 규칙입니다. 탓하기 시작하면 다음 사고에서 사실이 적히지 않습니다.
4. 손으로 하던 일을 코드로 옮깁니다. 계정 권한을 손으로 열어 주는 일, 서버를 손으로 늘리는 일이 대상입니다. 이런 일에 쓰는 시간의 상한을 절반쯤으로 정해 두고, 넘으면 자동화에 시간을 씁니다.
5. 볼 수 있게 만듭니다. 지금 시스템에서 무슨 일이 벌어지는지 밖에서 알 수 있는 정도를 뜻하는 관측성을 높이는 일입니다. 기록과 지표와 추적을 심어 두지 않으면 장애가 났을 때 화면이 안 열린다는 사실 말고는 아무것도 알 수 없습니다.
6. 배포 안전장치를 깝니다. 한 번에 전부 열지 않고 범위를 넓혀 가는 점진적 출시와 되돌릴 경로를 미리 준비해 둡니다. 되돌릴 방법이 없는 배포에서는 문제를 발견해도 할 수 있는 일이 없습니다.

가장 자주 붙는 쪽은 서버를 만드는 사람들입니다. 태오와는 기능을 설계하는 자리에서 만나, 이 기능이 실패할 때 무엇이 어떻게 동작해야 하는지와 외부 서비스가 답하지 않으면 어디까지 기다릴지를 정합니다. 만든 뒤에 붙으면 구조를 바꿔야 하는 일이 됩니다.

나머지 넷은 목적이 다릅니다.

1. 배포와 운영 자동화를 맡는 데브옵스 엔지니어 — 하는 일이 가장 많이 겹칩니다. 작은 조직에서는 한 사람이 둘을 겸합니다.
2. 지현 — 기능과 안정성을 맞바꾸는 대화를 합니다. 에러 버짓이 남지 않은 달에 새 기능을 미루는 결정이 여기서 나오고, 그 결정이 숫자에 근거하기 때문에 취향 다툼이 되지 않습니다.
3. 규원 — 고객과 계약으로 약속한 서비스 수준인 SLA를 쓸 때 함께 봅니다. 계약에 적는 숫자가 내부 목표치보다 느슨해야 하는데, 이 관계가 뒤집힌 계약은 지킬 수 없는 약속이 됩니다.
4. 수아 — 장애가 났을 때 고객에게 무엇을 언제 알릴지 맞춥니다. 복구보다 알림이 늦으면 고객은 우리가 모르고 있었다고 받아들입니다.

"이번 달 에러 버짓 다 썼습니다. 새 기능 배포는 다음 주로 미루죠."

숫자를 근거로 배포 속도를 조절하는 말입니다.

"복구부터 하고 원인은 포스트모템에서 봅시다."

장애 중에는 규명보다 복구가 먼저라는 뜻입니다.

"이건 온콜 알림으로 걸 만한 일이 아니에요. 아침에 봐도 됩니다."

새벽에 사람을 깨울 기준을 좁게 두자는 지적입니다.

페이지덱에서는 45명 규모라 전담이 한 명입니다. 그 한 명이 한 일 가운데 값을 가장 많이 한 것은 알림 정리였습니다. 처음에는 조건을 넉넉히 걸어 새벽 알림이 주에 열 번씩 왔고 그중 손댈 일은 한 번이었습니다. 아홉 번을 헛되게 겪은 사람은 열한 번째 알림도 무시합니다.

지금은 사용자가 실제로 못 쓰는 상황만 사람을 깨우고, 나머지는 아침 목록으로 모입니다. 알림 수가 줄어든 뒤에 복구 시간이 함께 짧아졌습니다.

장애를 끄는 사람으로 여기는 경우가 가장 많습니다. 실제로 장애가 나면 이 자리가 가장 먼저 움직이니 그렇게 보입니다. 하지만 불을 끄는 일은 결과이고, 이 역할의 일은 같은 불이 다시 나지 않게 구조를 바꾸는 쪽입니다. 끄는 일만 맡기면 사람은 계속 바쁘고 사고 건수는 줄지 않습니다. 반복 작업에 쓰는 시간에 상한을 두는 규칙이 있는 이유입니다.

안정성을 100퍼센트로 만드는 것이 목표라고 보는 것도 흔합니다. 멈추지 않는 것이 좋은 일이니 자연스럽게 들립니다. 그런데 마지막 몇 자리를 올리는 비용은 급격히 커집니다. 가동률을 99.9에서 99.99로 올리려면 서버를 여러 지역에 두고 사람을 더 세워야 하고, 그 돈과 시간은 새 기능에서 빼 옵니다. 게다가 목표를 100으로 잡으면 배포를 막는 것이 항상 옳은 선택이 되어 제품이 멈춥니다. 그래서 목표치를 100보다 낮게 정하고, 그 차이만큼을 쓸 수 있는 여유분으로 다룹니다.