on-call 없는 회사는 가능한가

“on-call 없는 팀”이라는 말은 듣기엔 좋다. 주말에 호출되지 않고, 새벽에 알림음에 깨지 않는다. 우리도 그걸 원한다. 그런데 이 목표는 어떻게 달성하는가. 아니면 애초에 달성 가능한가.

두 가지 전략

on-call을 없애는 방법은 크게 두 가지다. 첫 번째는 장애가 나도 즉각 대응하지 않아도 될 만큼 서비스의 중요도나 SLA를 낮추는 것. 두 번째는 장애 자체가 거의 안 나게 시스템을 설계하는 것.

우리는 지금 첫 번째에 가깝다. 운영하는 서비스들은 새벽에 장애가 나도 아침에 고쳐도 되는 것들이 대부분이다. 이 사실을 명확히 인정하고 받아들이는 것이 on-call 로테이션을 만들지 않은 실질적인 이유다.

대신 하는 것들

배포 후 5분 모니터링: 배포하면 화면과 로그를 5분 본다. 이상 없으면 자리를 뜬다.

알림 임계값을 높게 잡는다: 작은 이상에도 알림을 보내면 알림에 둔감해진다. 우리는 “사용자가 에러를 체감할 수 있는 수준”에서만 알린다.

복구가 빠른 구조를 선호한다: 기능을 플래그로 끄거나 직전 배포로 되돌리는 데 5분 이내가 걸리도록 배포 파이프라인을 유지한다. 장애를 막는 것보다 복구를 빠르게 하는 쪽이 우리 팀 규모에 더 현실적인 투자다.

솔직한 한계

지금 방식은 서비스 성격 덕분에 통한다. 만약 우리가 결제나 실시간 통신처럼 다운타임에 직접 손해가 발생하는 서비스를 운영한다면, on-call을 도입하거나 서비스 수를 줄이거나 둘 중 하나를 선택해야 한다. “on-call이 없어도 된다”는 말이 “장애가 나도 괜찮다”는 뜻과 일치할 때만 성립한다.

결론

on-call 없는 팀은 가능하다. 다만 그게 가능하려면 서비스의 가용성 요구 수준을 현실적으로 정의해야 한다. 요구 수준을 모호하게 두고 on-call을 없애면 누군가가 암묵적으로 짊어지게 된다. 그건 없애는 게 아니라 숨기는 것이다.

— by slecs