9.8 온콜과 운영 준비도

개요와 동기

지금 이 순간 시스템이 호출할지도 모르기 때문에 누군가 깨어 있습니다. 온콜은 자격 있는 사람을 언제든 프로덕션 문제에 닿을 수 있는 거리에 두는 인간적 장치이고, 운영 준비도는 그 사람이 싸울 기회를 갖도록 사전에 하는 일입니다. 이 장은 그 준비도와 그 인간 시스템에 관한 것입니다. 사람들이 여러 해 유지할 수 있는 순환을 어떻게 설계하는지, 누군가를 깨울 가치가 있는 것을 어떻게 결정하는지, 서비스가 실제 트래픽을 나르게 하기 전에 정말 운영될 준비가 되었음을 어떻게 확인하는지입니다.

이를 두 이웃과 구별해 두십시오. 9.3장은 무언가 적극적으로 깨졌을 때의 대응 프로세스인 인시던트 관리를 다룹니다. 지휘 역할, 심각도 수준, 조율, 사후 검토입니다. 9.1장은 서비스 수준 목표와 오류 예산으로 신뢰성을 엔지니어링하는 더 넓은 규율인 사이트 신뢰성 엔지니어링(SRE)을 다룹니다. 이 장은 인시던트의 상류이자 그 규율의 곁에 앉습니다. 더 좁고 더 개인적인 질문을 합니다. 서비스는 운영될 준비가 되었는가, 호출기를 든 사람은 고통받는 대신 성공하도록 준비되었는가? 조직이 훌륭한 인시던트 프로세스를 갖추고도 엔지니어를 소진시킬 수 있습니다. 온콜의 고통은 어떤 인시던트보다 한참 전에, 알림의 품질, 런북의 상태, 일정의 인간성으로 정해지기 때문입니다.

큰 팀에게 온콜은 비공식적 호의이기를 멈추고 인프라가 됩니다. 수백 개 서비스와 수십 개 팀이 있는 플랫폼은 우연히 모든 것의 작동 방식을 아는 한 사람에게 의존할 수 없습니다. 원래 작성자가 떠난 뒤에도 유지되는 순환, 에스컬레이션 경로, 준비도 표준이 필요합니다. 기업과 정부 환경에서는 판돈이 더 오릅니다. 규제 서비스는 가용성 약속과, 그것을 운영하는 직원에 대한 돌봄의 의무를 집니다. 시민 대면 급여나 의료 시스템은 그것을 이해한 유일한 사람이 휴가 중이라는 이유로 밤사이 꺼질 수 없습니다. 운영 준비도는 출시 파티가 끝난 뒤에도 제도가 약속을 지키는 방법이며, 인간적인 온콜은 그 약속을 지키는 사람들을 지키는 방법입니다.

핵심 원칙

긴급하고, 행동 가능하고, 실제인 문제에만 사람을 호출하십시오.
항상 가용한 기계가 아니라 삶이 있는 사람을 위해 순환을 설계하십시오.
서비스가 프로덕션 트래픽을 나르기 전에 운영될 준비가 되었음을 증명하십시오.
모든 내부 원인이 아니라 사용자에게 보이는 증상과 SLO에 알리십시오.
런북과 준비도 리뷰를 보관되는 것이 아니라 쓰이는 살아 있는 문서로 다루십시오.
서비스를 만든 사람은, 인간적이고 지원되는 한계 안에서, 그것을 운영하는 데 도와야 합니다.
온콜의 건강을 측정하고 고역을 줄여 부하가 오르지 않고 내려가게 하십시오.

권장 사항

인간적이고 지속 가능한 순환을 설계한다

일정의 모양으로 시작하십시오. 어떤 도구보다 지속 가능성을 더 많이 정하기 때문입니다. 흔한 패턴은 호출을 먼저 받는 1차 대응자와, 1차가 확인하지 않거나 도움이 필요할 때 백업으로 행동하는 2차가 있는 주간 순환입니다. 어느 엔지니어든 네 주에 한 주 이하로 온콜이 되도록 풀을 충분히 크게, 이상적으로는 여섯 주에 한 번 이상으로 유지하십시오. 네 명 이하의 순환은 경고 신호입니다. 병, 휴가, 이직이 같은 두 명의 지친 영웅으로 무너뜨립니다.

시간대에 걸쳐 운영하는 곳에서는 태양 추종 모델을 선호하십시오. 서로 다른 리전의 팀이 각자 자기 낮 시간을 맡아 누구도 새벽 3시에 일상적으로 호출받지 않습니다. 이는 일주기 리듬, 곧 몸의 내부 수면-각성 주기를 존중하며, 그 교란은 사소한 불편이 아니라 직접적인 건강 비용입니다. 태양 추종이 불가능할 때는 고통을 압축하십시오. 더 짧은 야간 근무 블록, 나쁜 밤 뒤의 보장된 회복 시간, 밤사이 많이 호출받은 엔지니어가 다음 날 아침 온전한 하루치 기능 작업을 빚지지 않는다는 명시적 규칙입니다.

에스컬레이션은 순환 아래의 안전망입니다. 1차가 정해진 기간 안에 호출을 확인하지 않을 때 무슨 일이 일어나는지 서면으로 정의하십시오. 2차로, 그다음 팀 리드나 관리자로, 그다음 더 넓은 그룹으로 넘어갑니다. 자동이고 잘 이해된 에스컬레이션 정책은 어떤 호출도 조용히 바닥에 떨어지지 않고, 지친 한 사람이 유일한 방어선이 아니라는 뜻입니다.

호출 정책을 행동 가능하고, 긴급하고, 실제인 문제로 한정한다

온콜 순환을 파괴하는 가장 빠른 방법은 사람들이 행동할 수 없거나 행동할 필요가 없는 것에 호출하는 것입니다. 하나의 규칙을 채택하고 맹렬히 방어하십시오. 호출은 사람이 지금 무언가를 해야 한다는 주장입니다. 알림이 세 가지 시험, 곧 긴급함, 행동 가능함, 실제 사용자에게 보이는 문제를 기술함을 모두 충족하지 않으면 호출할 자격이 없습니다. 대신 티켓, 대시보드, 일일 요약으로 라우팅하십시오.

여기서의 적은 알람 피로로, 잦은 경보에 노출된 사람이 둔감해져 중요한 것을 포함해 무시하기 시작하는 잘 문서화된 현상입니다. 병원의 환자 안전 개념이며 소프트웨어에 정확히 옮겨집니다. 교대마다 스무 번의 호출이 오고 열아홉 번이 잡음이면, 대응자는 반쯤 잠든 채 그것들을 넘기는 법을 배우고, 스무 번째 실제였던 것도 같은 반사적 무시를 받습니다. 용인하는 모든 시끄러운 알림은 다른 모든 알림의 신뢰성에 매기는 작은 세금입니다.

알림 품질을 일급 엔지니어링 산출물로 다루십시오. 확인 대 행동 비율을 추적하십시오. 발동한 호출 중 몇 건이 사람이 중요한 무언가를 하게 만들었습니까? 한 분기 동안 한 번도 행동을 요구하지 않은 알림은 삭제나 격하의 후보입니다. 알림을 정기 주기로 리뷰하고, 어떤 엔지니어든 시끄러운 것에 이의를 제기할 자격을 주십시오. 목표는 호출이 여전히 의미가 있을 만큼 드문 순환입니다.

원인이 아니라 증상과 SLO에 알린다

잡음을 줄이는 가장 효과적인 방법은 알리는 대상을 바꾸는 것입니다. 높은 CPU, 가득 찬 디스크, 재시작된 단일 프로세스 같은 원인에 알리면, 사용자에게 영향을 주지 않을 수 있고 시스템이 흔히 스스로 치유하는 조건에 호출의 홍수가 생깁니다. 대신 증상에 알리십시오. 서비스가 사용자가 필요로 하는 일을 하고 있는가? 호출 알림을 9.1장에서 정의한 숫자 신뢰성 목표인 서비스 수준 목표(SLO)에 묶고, 목표를 놓칠 만큼 빠르게 오류 예산을 소진하고 있을 때, 또는 지연이나 성공률 같은 사용자 대면 지표가 사람들이 실제로 느끼는 선을 넘을 때 호출하십시오.

이 증상 기반, SLO 주도 접근은 9.2장의 관측 가능성과 텔레메트리에 달려 있습니다. 소진율 알림은 지표, 로그, 트레이스가 구조화되고 신뢰할 수 있을 때만 동작하기 때문입니다. 보답은 극적입니다. 소수의 의미 있는 증상 알림이 수백 개의 원인 알림을 대체하고, 호출이 다시 깨울 가치가 있는 문제와 상관됩니다. 원인은 여전히 중요하지만, 호출 경로가 아니라 증상 알림이 발동한 뒤 대응자가 참조하는 진단 대시보드에 속합니다.

출시 전에 운영 준비도를 요구한다

서비스는 프로덕션에 들어갈 자격을 얻어야 합니다. 실제 트래픽을 나르기 전에 프로덕션 준비 리뷰를 거치게 하십시오. 이상적으로는 만드는 팀 밖의 누군가가 서비스가 실제로 운영될 수 있는지 확인하는 구조화된 점검입니다. 리뷰를 팀 전반의 공유 표준이 되는 체크리스트로 코드화하십시오. 강한 목록은 모니터링과 SLO, 호출 정책을 충족하는 알림, 대시보드, 있을 법한 실패에 대한 런북, 정의된 소유권과 온콜 순환, 용량과 부하 기대, 의존성과 실패 모드 분석, 백업과 복구, 보안과 접근 통제, 롤백 계획을 덮습니다.

리뷰는 우회할 관문이 아니라 대화입니다. 그 가치는 만드는 팀이 맥락이 있는 동안 운영 가능성에 맞닥뜨리게 하는 데 있습니다. 여섯 달 뒤 새벽 2시에 아무도 런북을 쓰거나 알림을 설정하지 않았음을 발견하는 대신입니다. 준비도를 9.6장의 복원력 테스트에 묶으십시오. 출시 전에 의존성 실패를 주입한 적 없는 서비스는 어떻게 실패하는지에 대해 테스트되지 않은 약속을 하고 있습니다. 판돈이 큰 기업과 정부 출시에서는 준비도 리뷰를 필수의 문서화된 단계로 만드십시오. 준비되지 않은 시민 대면 서비스가 공개적으로 실패하는 비용은 돈만큼이나 신뢰로 측정되기 때문입니다.

실제로 쓰이는 런북과 플레이북을 쓴다

런북은 단계별 운영 문서입니다. 이 서비스를 재시작하는 법, 이 자격 증명을 교체하는 법, 이 큐를 비우는 법, 이 알림을 해석하는 법입니다. 플레이북은 한 부류의 상황에 대한 더 넓은 대응 안내입니다. 둘 다 아무도 읽지 않으면 쓸모없으며, 대부분의 런북은 낡았거나, 모호하거나, 새벽 3시에 찾을 수 없어서 읽히지 않습니다. 실패 모드를 직접 고치십시오. 대응자가 호출에서 한 번의 클릭으로 닿도록 알림 자체에서 런북에 링크하십시오. 2.7장의 문서화 실천이 권하듯 런북을 코드 옆 버전 관리에 두어 다른 산출물처럼 리뷰되고 갱신되게 하십시오. 작성자의 맥락을 가정하는 산문이 아니라 구체적인 명령과 기대 출력으로, 스트레스를 받고 졸린 낯선 사람을 위해 쓰십시오.

런북의 시험은 작성자 아닌 누군가가 압박 아래서 성공적으로 따를 수 있는지입니다. 온보딩과 게임 데이에 그것을 검증하고, 인시던트가 틀렸음을 드러내는 순간 런북을 갱신하십시오. 거짓말하는 런북은 없는 것보다 나쁩니다. 지친 대응자를 자신 있게 잘못된 방향으로 보내기 때문입니다.

인간적인 한계 안에서 만든 것을 소유한다

DevOps 운동은 “만든 사람이 운영한다”를 대중화했습니다. 서비스를 쓰는 팀이 그 호출기도 맡습니다. 이득은 실제이며 방어할 가치가 있습니다. 만드는 사람이 자기 호출을 느끼면 신뢰성에 투자하고, 시끄러운 알림을 고치고, 운영 가능성을 위해 설계합니다. 피드백 루프가 근본 원인을 고칠 수 없는 별도의 운영 팀에 떨어지는 대신 그들 개인에게 닿기 때문입니다.

이 모델에는 존중해야 할 한계가 있습니다. 팀이 서비스를 운영할 진정한 준비를 갖추고 있어야 합니다. 1.10장의 엔지니어링 효과성과 1.4장의 일하는 방식이 모두 요구하듯, 운영을 잘할 도구, 플랫폼, 교육, 시간이 주어져야 합니다. 완전한 소유권은 인간적인 순환을 꾸릴 수 없을 만큼 작은 팀에, 또는 온콜을 견딜 만하게 만드는 플랫폼 지원 없이 부과되면 잔인합니다. 일부 조직은 하이브리드를 운영합니다. 중앙 SRE나 플랫폼 팀이 가장 어려운 등급을 공동 소유하거나 높은 신뢰성 기준을 충족하는 서비스에 대해 근무 시간 외 커버리지를 제공해, 제품 팀을 일상적인 야간 호출에서 풀어 줍니다. 지킬 원칙은 피드백 루프입니다. 모양은 팀의 규모, 성숙도, 부하의 인간성에 맞게 유연할 수 있습니다.

온콜 엔지니어를 의도적으로 온보딩하고 게임 데이를 돌린다

누구도 처음 호출기를 혼자서 준비 없이 들어서는 안 됩니다. 온보딩 경로를 만드십시오. 한 순환 동안 숙련된 대응자를 그림자처럼 따르고, 신입이 이끌고 멘토가 지켜보는 역방향 섀도잉을 하고, 대시보드와 런북을 훑고, 누구에게 에스컬레이션할지 분명한 지도를 갖습니다. 온콜에 들어갈 준비를 가정이 아니라 명시적 이정표로 만드십시오.

게임 데이는 온콜을 현실로 만드는 예행연습입니다. 게임 데이에서는 실패를 의도적으로, 이상적으로는 현실적인 환경에서 실행하고, 온콜 엔지니어가 실제 인시던트에서 가질 도구와 런북만으로 대응하게 합니다. 여기서 런북이 낡았고, 대시보드에 신호가 빠졌고, 알림이 발동하지 않음을 발견합니다. 게임 데이는 첫 실제 호출을 공황에서 절차로 바꾸는 근육 기억과 확신을 쌓으며, 9.6장의 카오스 엔지니어링에 자연스럽게 연결됩니다.

깨끗한 인계를 운영하고 온콜 건강을 측정한다

교대 사이의 인계가 맥락이 새는 곳입니다. 짧고 구조화된 인계를 도입하십시오. 현재 저하된 것, 발동하고 억제된 알림, 진행 중인 변경, 지켜볼 것입니다. 이를 기본적인 온콜 위생과 짝지우십시오. 나가는 대응자가 들어오는 대응자에게 난장판을 남기지 않는다는 정책, 반쯤 고쳐진 채 남은 것은 모두 적는다는 정책입니다.

무엇보다 측정하십시오. 보지 못하는 부하는 관리할 수 없습니다. 교대당 호출, 근무 시간 외(저녁, 밤, 주말)에 떨어지는 호출의 비율, 확인까지의 시간, 2차 및 에스컬레이션 단계가 얼마나 자주 촉발되는지를 추적하십시오. 숫자만이 아니라 추세를 지켜보십시오. 근무 시간 외 호출이 분기마다 오르는 순환은 현재 절대 개수와 무관하게 소진을 향해 가고 있습니다. 이 지표를 팀이 어떤 고역을 자동화해 없앨지, 어떤 알림을 죽일지, 준비도가 어디서 부족했는지 결정하는 정기 운영 리뷰에 공급하십시오. 한 번 고쳐지는 것이 아니라 트래픽과 함께 확장되는 반복적 수동 운영 작업인 고역을 줄이는 것이 시스템이 커지는 동안 온콜 부하를 평평하게 유지하는 방법입니다.

장단점

선택	장점	단점
만든 사람이 운영한다	촘촘한 신뢰성 피드백 루프. 소유자가 근본 원인을 고침	자원이 부족하거나 아주 작은 팀에 잔인함. 고르지 않은 야간 부하
중앙 SRE 또는 플랫폼 온콜	제품 팀을 일상적인 야간 호출에서 보호. 깊은 운영 기술	만드는 사람의 피드백 루프를 약화. 쏟아 넣는 곳이 될 수 있음
태양 추종 순환	밤사이 호출 없음. 인간적이고 건강함	여러 리전에 인력 필요. 더 무거운 인계 오버헤드
작은 로컬 순환	단순. 모두가 시스템을 앎	병이나 이직에 무너짐. 빠른 소진
증상 및 SLO 알림	적고 의미 있는 호출. 낮은 피로	성숙한 텔레메트리 필요. 서서히 쌓이는 원인을 놓칠 수 있음
원인 기반 알림	문제를 일찍, 구체적으로 잡음	대응자를 범람시킴. 알람 피로를 부름
엄격한 준비도 리뷰	프로덕션의 불쾌한 놀람이 줄어듦	출시를 늦춤. 우회되면 관료적으로 느껴질 수 있음

중심 긴장은 커버리지 대 인간성입니다. 최대 커버리지를 밀면 큰 순환, 공격적 알림, 어디서나 완전한 소유권을 얻으며, 이는 사람을 갈아 내면서 시스템을 보호합니다. 순전히 대응자의 편안함에 최적화하면 실제 문제가 방치된 채 기다리는 틈의 위험이 있습니다. 차이를 반으로 나누는 것이 아니라 품질을 올려 해결하십시오. 훌륭한 알림, 동작하는 런북, 준비된 서비스가 더 작고 침착한 순환이 더 많은 영역을 안전하게 덮게 합니다. 가장 잘 운영하는 조직은 대응자가 가장 적게 호출받는 조직인 경우가 많습니다. 체력이 아니라 준비도에 투자했기 때문입니다. 시끄러운 알림을 없애거나 런북을 고치는 데 쓴 모든 시간이 여러 시간의 인간 주의를 되사 주고 시스템 전체의 신뢰성을 지킵니다.

팀과 논의할 질문

이 순환을 1년 동안 직접 맡겠습니까? 답이 아니라면 무엇을 바꾸겠습니까? 이 질문은 부하를 개인적으로 만들어 추상을 뚫습니다. 대화에 실제 숫자를 가져오십시오. 지난달 호출이 몇 번 발동했는지, 몇 번이 자정 이후나 주말에 떨어졌는지, 평균 확인이 얼마나 걸렸는지입니다. 순환의 각 사람에게 현재 모양이 온콜 주를 두려워하지 않고 유지할 수 있는 것인지 묻고, 큰 목소리만큼 조용한 답에도 귀 기울이십시오. 정직한 답이 순환이 두어 영웅이 최악을 흡수하기 때문에만 견딜 만하다는 것이라면, 그중 한 명이 떠나는 첫 순간 깨질 취약함을 찾은 것입니다. 원하는 산출물은 더 큰 풀, 태양 추종 분할, 야간 호출 감소, 알림 정리 같은 구체적 변경의 목록이며, 각각에 소유자와 날짜가 붙습니다.
사람을 호출할 수 있는 모든 알림에 대해, 대응자가 취하리라 기대되는 행동의 이름을 댈 수 있습니까? 대부분의 순환은 이를 감사한 적이 없고, 연습은 많은 것을 드러냅니다. 호출 알림의 전체 목록을 뽑아 각각에 대해 발동했을 때 대응자가 무엇을 해야 하는지, 지난 분기에 실제 행동으로 이어지지 않고 발동한 횟수가 얼마인지 물으십시오. 시험에 실패하는 알림, 곧 아무도 행동을 붙일 수 없거나 아무도 건드리기 전에 일관되게 저절로 해결되는 것이 다른 모든 알림에 대한 신뢰를 침식하는 잡음입니다. 있다면 확인 대 행동 데이터를 가져오고 공격적으로 삭제하거나 격하할 준비를 하십시오. 목표는 모든 알림이 사람의 도움에 대한 진짜 요청인 호출 경로이며, 회의는 시작할 때보다 더 짧고 날카로운 알림 목록으로 끝나야 합니다.
새 엔지니어가 이 순환에 합류할 때, 정확히 무엇이 그들을 준비시키며, 그것이 동작하는지 테스트해 봤습니까? 온콜 온보딩은 설계되기보다 가정되는 경우가 많고, 간극은 신입이 한 번도 본 적 없는 실패에 혼자 호출받는 첫 순간 드러납니다. 신규 대응자가 밟는 실제 경로를 훑으십시오. 무엇을 따라가는지, 어떤 런북을 읽는지, 아무도 최근에 그 런북이 여전히 동작함을 확인하려고 따라 해 봤는지, 막혔을 때 누구에게 에스컬레이션하는지입니다. 실제 최근 인시던트 하나를 골라, 현재 런북과 대시보드만 갖춘 신입이 그것을 해결할 수 있었을지 물어보십시오. 정직한 답은 보통 낡은 문서와 빠진 신호를 드러내며, 이것이 바로 게임 데이가 실제 인시던트보다 먼저 드러내려는 것입니다. 온콜을 위한 정의된 준비도 이정표와, 그것을 정직하게 유지할 게임 데이의 일정을 가지고 떠나십시오.
근무 시간 외 호출은 실제로 어디에 떨어지며, 사람들의 수면을 지키려고 인력 배치나 커버리지를 바꿀 의향이 있습니까? 밤과 주말의 호출은 원시 호출 수가 숨기는 건강 비용을 지니므로, 평균으로는 견딜 만해 보이는 순환도 우연히 새벽 3시의 실패를 맡게 되는 몇 사람을 조용히 망가뜨릴 수 있습니다. 평균이 아니라 집중을 찾도록 서비스별, 대응자별로 나눈 시간대와 요일별 호출 분석을 가져오십시오. 경쟁하는 고려는 실제입니다. 태양 추종 커버리지는 한 리전을 넘는 인력과 인계 오버헤드를 더하고, 작은 로컬 순환은 더 단순하지만 누군가 밤을 맡게 둡니다. 수정이 두 번째 리전 순환, 근무 시간 외 등급을 맡는 중앙 플랫폼 팀, 보장된 회복 시간이 있는 더 짧은 야간 블록, 근원에서 밤사이 잡음을 없애는 알림 정리 중 무엇인지 의도적으로 정하십시오. 기업과 정부 운영자에게는 온콜 직원에 대한 돌봄의 의무를 웰빙 구호가 아니라 소유자와 보고되는 지표가 있는 공식 의무로 다루십시오. 규제 기관이나 노동 평의회가 언젠가 그것을 보이라고 요구할 수 있기 때문입니다.
프로덕션 준비 리뷰는 서비스가 어떻게 실패하는지에 대한 진짜 대화입니까, 관문을 통과하려고 우회되는 체크리스트입니까? 준비도 리뷰는 출하되는 것을 바꿀 때만 보답하며, 실패 모드는 아무도 믿지 않는 프로세스를 만족시키려고 출시 전날 오후에 채운 양식입니다. 최근 완료된 몇 개 리뷰를 가져와 각각이 실제로 무엇을 잡았는지 물으십시오. 빠진 런북, 테스트되지 않은 롤백, 발동하지 않은 알림, 아니면 아무것도 아닌지입니다. 긴장은 출시 속도 대 운영 엄밀함이며, 관료적으로 느껴지는 리뷰는 우회되는 반면 진짜 실패 모드를 드러내는 리뷰는 처음으로 누군가의 밤을 구하기 전까지 원망받습니다. 누가 리뷰를 운영하는지, 만드는 팀 밖의 사람인지, 어떤 증거, 곧 주입된 의존성 실패나 낯선 사람이 따라 한 런북이 통과로 치는지 정하십시오. 기업과 정부 출시에서는 완료된 리뷰를 감사 산출물로 보관하고 9.6장의 복원력 테스트에 묶으십시오. 준비되지 않은 시민 대면 서비스가 공개적으로 실패하면 어떤 롤백도 되찾지 못하는 신뢰를 잃기 때문입니다.
“만든 사람이 운영한다”는 어디서 진정으로 우리에게 도움이 되며, 서비스를 운영할 자원을 갖추지 못한 팀에게는 어디서 조용히 잔인합니까? 완전한 소유권은 만드는 사람이 시끄러운 알림을 고치고 운영 가능성을 위해 설계하게 하는 피드백 루프를 만들지만, 인간적인 순환을 꾸리기엔 너무 작은 팀에 부과되면 책무로 위장한 느린 소진 엔진이 됩니다. 어느 팀이 어느 호출기를 소유하는지, 어려운 호출을 받지 않는 사람을 제외하면 각 순환이 실제로 얼마나 큰지, 각 팀이 운영을 잘하기 위한 플랫폼, 도구, 교육을 무엇을 갖췄는지의 지도를 가져오십시오. 경쟁하는 끌림은 보편적 소유권이라는 깔끔한 원칙과, 일부 등급은 가장 어려운 신뢰성 작업을 공동 소유하거나 근무 시간 외 커버리지를 제공하는 중앙 SRE나 플랫폼 팀이 필요하다는 지저분한 현실 사이에 있습니다. 원하는 산출물은 각 서비스를 완전 소유, 공동 소유, 중앙 커버로 정직하게 분류하고, 유지할 수 없는 것을 운영하라고 요구하는 팀에게는 자원의 간극을 명명하는 것입니다. 크거나 공공 조직에서는 인간적인 소유권이 전제하는 플랫폼 지원과 인원의 조달 및 채용 리드 타임을 더하십시오. 해당 기간에 인력을 채울 수 없는 팀은 실패하도록 세워지는 팀이기 때문입니다.

분야별 관점

스타트업. 엔지니어가 소수이면 모두가 온콜이고 영웅 순환이 숨을 곳이 없습니다. 가장 빨리 보답하는 두 변경에 부족한 시간을 쓰십시오. 원인 기반 알림을 삭제하고 핵심 흐름을 추적하는 두어 SLO에만 호출하고, 남은 알림마다 한 페이지짜리 런북을 링크하십시오. 정교한 도구와 태양 추종은 건너뛰십시오. 공유 스프레드시트, 1차에서 2차로의 자동 에스컬레이션, 나쁜 밤이 다음 날 아침 휴식을 산다는 엄격한 규칙이 어떤 플랫폼 구매보다 더 멀리 데려갑니다.

소기업. 전담 SRE도 없고 야간 순환에 인력을 둘 수도 없을 테니, 만드는 것보다 사는 것에 기대십시오. 깊은 인프라 호출을 제공자가 맡는 관리형 서비스와 호스팅을 선호하고, 에스컬레이션을 직접 굴리는 대신 호스팅 호출 도구를 쓰십시오. 준비도를 짧은 체크리스트와 고객이 알아챌 것에 묶인 소수의 의미 있는 알림으로 구성하고, 아침 티켓이면 될 때 일부 서비스는 밤사이 사람을 호출해서는 안 된다는 점에 정직하십시오.

대기업. 문제는 많은 팀에 걸친 일관성입니다. 공유 프로덕션 준비 리뷰, 공통 호출 정책, 팀 사이를 옮겨 다니는 엔지니어가 온콜 시스템을 즉시 이해하도록 버전 관리되는 런북 저장소입니다. 온콜 건강을 근무 시간 외 호출 임계값이 리뷰를 촉발하는 다스려지는 지표로 만들고, 어떤 호출도 조용히 떨어지지 않도록 에스컬레이션과 인계를 표준화하고, 중앙 플랫폼 팀이 가장 어려운 등급을 공동 소유하게 하십시오. 순환의 포트폴리오를 서비스의 포트폴리오를 관리하듯 관리해, 고역, 호출 부하, 소진 위험에 대한 데이터가 정기 운영 리뷰에 공급되게 하십시오.

정부. 조달 규칙, 투명성, 돌봄의 의무가 장치를 형성합니다. 온콜 직원의 건강을 공식적이고 감사 가능한 요건으로 다루고, 야간 인력이 제한된 곳에서는 어떤 공무원도 새벽 3시에 일상적으로 호출받지 않도록 태양 추종 운영 파트너와 계약하십시오. 완료된 각 준비도 리뷰를 감사 산출물로 보관하고, 5년 뒤 운영하는 사람들은 작성자가 아닐 것이므로 시스템을 만들지 않은 대응자가 실행하도록 런북을 쓰고, 시민이 실제로 만나기 전에 계절성 피크를 게임 데이로 예행연습하십시오.

사례

스타트업. 열두 명의 스타트업이 첫 유료 제품을 출시하며 여섯 엔지니어 모두를 1차와 2차가 있는 주간 순환에 올립니다. 첫 달에 호출기가 밤마다 발동하는데, 대부분 저절로 해결되는 CPU와 디스크 알림이고, 두 엔지니어가 조용히 구직을 시작합니다. 팀은 멈추고 다시 만듭니다. 모든 원인 기반 알림을 삭제하고, 결제와 검색에 두 SLO를 정의하고, 오류 예산 소진에만 호출합니다. 호출이 주당 약 마흔 번에서 세 번으로 떨어집니다. 모든 새 서비스가 통과해야 하는 한 페이지짜리 준비도 체크리스트를 더하고 각 런북을 알림에서 직접 링크합니다. 온콜은 사람들이 떠나는 이유에서 관리할 만한 일의 일부가 되었고, 비싼 도구가 아니라 스프레드시트와 규율로 해냈습니다.

기업. 한 글로벌 결제 회사가 “만든 사람이 운영한다” 모델로 수백 개 서비스를 운영하며, 호출 시스템, 준비도 리뷰 프로세스, 버전 관리되는 공유 런북 저장소를 제공하는 중앙 플랫폼 팀이 뒷받침합니다. 모든 서비스가 출시 전에 SLO, 알림, 런북, 용량, 롤백을 덮는 문서화된 프로덕션 준비 리뷰를 통과합니다. 온콜 건강은 추적되는 지표입니다. 근무 시간 외 호출이 임계값을 넘는 팀은 자동 리뷰를 촉발하고, 플랫폼 팀은 부하가 내려올 때까지 신뢰성 작업을 공동 소유하겠다고 제안합니다. 게임 데이는 현실적인 결함 주입에 대해 분기마다 돕니다. 표준이 균일하고 도구가 공유되므로 엔지니어는 팀 사이를 옮겨 다니며 온콜 시스템을 즉시 이해할 수 있고, 리더십은 팀별로 인간의 부하가 지속 가능한지 볼 수 있습니다.

정부. 한 국세청이 뚜렷한 계절성 피크와 시민에게 가용 상태를 유지해야 하는 법적 의무가 있는 신고 시스템을 운영합니다. 인력이 한 시간대에 집중되어 있고 야간 인력이 제한되므로, 기관은 운영 파트너와 태양 추종 협약을 맺어 어떤 공무원도 한밤중에 일상적으로 호출받지 않게 하고, 온콜 직원의 건강과 돌봄의 의무를 공식 요건으로 다룹니다. 모든 서비스 변경이 배포 전에 운영 준비도 리뷰를 통과하며, 체크리스트는 감사를 위해 보관됩니다. 5년 뒤 운영하는 사람들은 그것을 쓴 사람들이 아닐 것이므로, 런북은 시스템을 만들지 않은 대응자가 실행하도록 쓰입니다. 신고 시즌 동안 기관은 피크 부하 시나리오에 대해 게임 데이를 돌려, 대응자가 급증을 실제로 만나기 전에 예행연습에서 만납니다.

비즈니스 사례: 동기, ROI, TCO

운영 준비도와 인간적인 온콜의 수익은 두 장부에 나타납니다. 시스템의 신뢰성과 팀의 유지입니다. 신뢰성 측면에서 준비도 리뷰를 통과하고 증상 기반 알림을 갖춘 서비스는 런북이 있고, 알림이 의미 있고, 대응자가 예행연습했기 때문에 덜 자주 실패하고 더 빨리 복구합니다. 호출이 맥락을 찾아 헤매는 혼란스러운 사람이 아니라 링크된 런북이 있는 준비된 사람에게 닿으면 평균 확인 시간과 평균 복구 시간이 모두 떨어집니다. 인간 측면에서 온콜은 엔지니어 이직의 주된 원인이며, 시니어 엔지니어를 교체하는 비용은 순환을 고치는 데 들었을 투자의 몇 배입니다. 세계보건기구가 직업 현상으로 인정하는 만성적 직장 탈진 상태인 직업적 소진은 시스템을 이해하는 가장 경험 많은 사람들을 데려가 내몰기 때문에 비쌉니다.

도입 비용은 대부분 일회성이고 소박합니다. 준비도 체크리스트를 쓰고, 알림을 원인에서 증상으로 옮기고, 런북을 버전 관리에 두고, 온콜 건강 지표를 설정합니다. 반복 비용은 알림을 리뷰하고, 게임 데이를 돌리고, 인간적인 일정을 지키는 규율입니다. 방치의 비용은 조용히 복리로 쌓입니다. 시끄러운 알림은 피로를 낳고, 피로는 놓친 실제 인시던트와 이직을 낳고, 모든 이직은 운영 지식을 가져가 남은 이들의 부하를 올립니다. 리더십을 설득하려면 온콜 건강을 이미 지켜보는 지표에 연결하십시오. 인시던트 빈도와 지속 시간, 확인까지의 시간, 계획되지 않은 이직, 근무 시간 외 호출 추세입니다. 시스템이 커지는 동안 근무 시간 외 호출이 줄어드는 순환은 신뢰성 투자가 동작하고 있고 엔지니어가 내년에도 여기 있을 것이라는 직접적 증거입니다.

안티패턴과 함정

영웅 순환: 두세 사람이 모든 어려운 호출을 조용히 흡수해, 일정은 서류상 괜찮아 보이지만 그중 한 명이 떠나는 순간 무너집니다.
원인에 호출: 사용자에게 보이는 증상이 아니라 CPU, 메모리, 디스크에 알려, 사람이 필요 없던 호출로 대응자를 범람시킵니다.
용인된 알림 피로: 삭제가 위험하게 느껴져서 시끄러운 것으로 알려진 알림이 몇 달 동안 호출 경로에 남아, 대응자가 모든 것을 무시하게 됩니다.
런북의 부패: 출시 때 한 번 쓰이고 갱신되지 않아, 지친 대응자가 새벽 3시에 따르면 자신 있게 틀린 문서.
지원 없는 소유권: 순환을 꾸릴 수 없을 만큼 작거나 인간적으로 운영할 플랫폼과 도구가 없는 팀에 “만든 사람이 운영한다”를 부과하는 것.
준비도 연극: 서비스가 어떻게 실패하는지에 진짜로 맞닥뜨리는 대신 관문을 통과하려고 채운 리뷰 체크리스트.
출시하고 방치: 순환도, 알림도, 런북도 없이 서비스를 출하한 뒤 첫 장애 중에 간극을 발견하는 것.
측정되지 않은 부하: 교대당 호출이나 근무 시간 외 호출에 대한 데이터가 없어 사람들이 그만둘 때까지 소진이 보이지 않는 것.
첫 호출, 예행연습 없음: 섀도잉도 게임 데이도 없이 신입을 온콜에 올린 뒤 그들이 얼어붙는 것에 놀라는 것.

성숙도 모델

1단계, 시작: 온콜이 비공식적이고 반응적입니다. 소수의 사람이 무언가 깨지면 전화를 받고, 알림은 원인에 발동하고 대부분 잡음이며, 런북은 없거나 낡았고, 서비스는 준비도 점검 없이 출시되고, 누군가 소진되거나 그만둘 때까지 아무도 인간의 부하를 측정하지 않습니다.
2단계, 발전: 기본 실천이 나타나지만 팀마다 다릅니다. 일부 순환에 정의된 1차, 2차, 에스컬레이션이 있고, 일부 알림이 튜닝되고 일부 런북이 쓰였으며, 준비도 체크리스트가 있지만 일관되지 않게 적용됩니다. 신경 쓰는 팀에서는 호출이 집계될 수 있고, 야간 호출이 흔하며, 온콜 온보딩은 설계되기보다 즉흥적입니다.
3단계, 표준화: 준비도 리뷰가 팀 전반에 시행되는 출시 전 문서화된 단계입니다. 호출은 공통 정책에 따라 증상과 SLO에 기반하고, 런북은 버전 관리에 살며 알림에서 링크되고, 온보딩에는 섀도잉과 게임 데이가 포함되고, 인계는 구조화된 형식을 따르며, 에스컬레이션은 팀 사이를 옮겨 다니는 엔지니어가 시스템을 즉시 알아볼 만큼 균일합니다.
4단계, 관리: 온콜이 기준선에 대해 측정되고 통제됩니다. 교대당 호출, 근무 시간 외 비율, 확인까지의 시간, 에스컬레이션 빈도, 확인 대 행동 비율이 팀별로 추적되어 목표와 비교되므로, 소진을 향해 표류하는 순환이 사람들이 그만둔 뒤가 아니라 그 전에 보입니다. 임계값이 리뷰를 촉발하고, 알림 품질은 어느 호출이 실제 행동으로 이어졌는지의 증거로 감사되며, 인력 배치와 소유권 결정은 일화가 아니라 데이터로 이끌립니다.
5단계, 오케스트레이션: 온콜 건강이 조직 전체에 통합된 지속적으로 개선되는 성과입니다. 시스템이 커지는 동안 호출과 근무 시간 외 추세가 내려가고, 고역은 체계적으로 자동화되어 없어지고, 태양 추종이나 그에 상당하는 것이 수면을 지키고, 게임 데이와 결함 주입이 일상이며, 조직은 위험 상황이 이동함에 따라 팀과 리전 사이에서 부하를 재균형하며 모든 교대에서 배운 것으로 소유권, 커버리지, 준비도 표준을 적응시킵니다.

논의를 위한 아이디어

실제 행동으로 이어진 호출 대 저절로 해결된 호출의 현재 비율은 얼마이며, 측정하려면 무엇이 필요합니까?
가장 지식이 많은 대응자가 내일 떠난다면 어떤 서비스가 운영하기에 안전하지 않게 되며, 왜입니까?
“만든 사람이 운영한다”는 어디서 도움이 되고, 어디서 자원이 부족한 팀에게 조용히 잔인합니까?
마지막으로 신입 엔지니어가 현실적 조건에서 런북을 따라 하는 것을 본 것은 언제이며, 무엇이 깨졌습니까?
지난 네 분기 동안 근무 시간 외 호출이 오르고 있습니까, 내리고 있습니까? 그 숫자를 누가 소유합니까?
엄격하게 시행했다면 가장 최근의 나쁜 출시를 막았을 준비도 리뷰 항목은 무엇입니까?

핵심 요점

온콜 준비도는 인시던트 전에, 영웅적 행위가 아니라 알림, 런북, 순환의 품질로 정해집니다.
긴급하고, 행동 가능하고, 사용자에게 보이는 문제에만 사람을 호출하십시오. 증상과 SLO에 알리고 나머지는 티켓과 대시보드로 라우팅하십시오.
삶이 있는 사람을 위해 순환을 설계하십시오. 충분히 큰 풀, 가능한 곳에서의 태양 추종, 자동 에스컬레이션, 존중되는 회복 시간입니다.
프로덕션 준비 리뷰로 출시 전에 서비스의 준비를 증명하고, 런북을 버전 관리에 두고 알림에서 링크하고, 게임 데이로 예행연습하십시오.
온콜 건강, 특히 근무 시간 외 호출과 확인까지의 시간을 측정하고, 사람들에게 더 견디라고 요청하는 대신 고역과 잡음을 줄여 부하를 내리십시오.

참고 문헌과 더 읽을거리

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
Rob Ewaschuk, “My Philosophy on Alerting,” in Site Reliability Engineering appendix
John Allspaw and Jesse Robbins (eds.), Web Operations: Keeping the Data on Time
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook
Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
World Health Organisation, ICD-11, entry on burn-out as an occupational phenomenon