대기 근무 개선을 위한 매니저 가이드
의사가 의료 응급 상황을 처리하기 위해 응급실에 대기 일정이 필요한 것처럼, DevOps 팀도 성능, 배포 및 가용성에 영향을 미치는 소프트웨어 및 시스템 문제에 효율적으로 대응하기 위해 대기 일정이 필요합니다.
그러나 대기 중 담당자 관행을 개발하기란 말처럼 쉽지 않습니다. 대기 중 근무는 직원들에게 벅차고 방해가 되는 경험이 될 수 있습니다. 팀의 지원 범위, 확장성 및 삶의 질 간의 적절한 균형을 찾는 것은 지속적인 과제입니다.
모범 사례가 바뀌고 회사가 성장함에 따라 가장 애자일하고 속도가 빠른 팀이 새로운 접근 방식을 구현하고 성공을 거두고 있습니다.
직접 구축하고 직접 운영
최근 10년 전까지만 해도 운영 팀의 주요 업무는 IT 인시던트에 대응하는 것이었습니다. 조직에는 일반적으로 계층화된 팀 구조(예: 수준 1, 수준 2, 수준 3, 상위 계층에서 더 높은 기술 수준 및 급여 수준)가 있습니다.
이 구조를 채택하는 것의 목표는 운영 비용을 줄이는 것이었습니다. 일반적으로 수준 1에는 신입 직원이 개입합니다. 수준 1에서 문제를 해결할 수 없으면 더 높은 수준의 선임(따라서 더 비싼) 직원으로 구성된 수준 2로 에스컬레이션합니다. 그리고 문제가 해결될 때까지 이 과정이 계속됩니다.
그러나 상시 가동 서비스가 증가함에 따라, 시스템 간의 상호 의존성과 가동 시간에 대한 고객의 기대치도 모두 높아졌습니다. 요즘에는 대응이 느리면 선임 개발자를 인시던트에 더 일찍 참여시키는 것보다 평판, 고객 만족도 및 수익 손실 측면에서 회사에 더 많은 비용이 들 수 있습니다.
변화하는 기술 환경의 결과로, 대응 팀의 구조가 바뀌어야 했습니다. 바로 여기서 DevOps 운동과 “직접 구축하고 직접 운영”한다는 개념이 나타납니다.
개념은 간단합니다. 가장 짧은 시간 내에 관련 문제를 해결하는 데 가장 적합한 담당자는 바로 그 코드에 가장 익숙한 개발자라는 것입니다. DevOps 덕분에, 이 논리는 이제 개발자가 일반적으로 대기 근무를 하여 코드가 제대로 실행되고 인시던트의 MTTA 및 MTTR을 낮추는 이유가 되었습니다.
이 접근 방식의 추가적인 이점은 배포 전에 더 엄격한 테스트가 가능하다는 것입니다. 이제 코드를 담당하는 개발자는 근무 외 시간에 알림을 받을 수 있으므로 더 깊이 있는 주인 의식과 코드를 두 번, 세 번 확인하려는 의욕을 가지게 됩니다. 그 결과 점점 더 많은 회사에서는 신뢰성과 복원력이 뛰어난 시스템을 갖추게 됩니다.
팀이 만족할 만한 대기 중 담당자 관행 구축
대기 근무는 평판이 좋지 않으며 때로는 그럴만한 이유가 있습니다. 균형이 잡히지 않은 대기 근무 프로그램은 일과 삶의 균형, 건강 및 수면에 부정적인 영향을 줄 수 있습니다. 너무 힘든 대기 근무를 경험했거나 대기 근무 경험이 없는 직원은 일상 생활을 비롯해 일과 삶의 균형이 눈앞에서 사라지는 것처럼 생각할 수 있습니다.
그러나 사실 대기 근무는 삶의 질을 떨어뜨리는 침울한 일이 될 필요는 없습니다. 대기 중 업무의 균형을 맞추고, 팀의 선호 사항을 고려하고, 인시던트 및 대기 중 알림을 최대한 예방하고 줄이기 위한 강력한 시스템을 마련하면 팀 전체의 부담을 최소화하고 함께 나누는 관행을 만들 수 있습니다.
경영진이 이 과정을 성공적으로 해내려면 팀과 투명하게 협력하고, 다양한 교육을 제공하고, 대기 근무 및 개발 업무에 대한 공정한 기대치를 설정하고, 강력한 프로세스를 개발하고, 지속적으로 확인하며, 팀 자체의 입력과 승인을 통해 개선을 이루어야 합니다.
팀과의 투명성 유지
성공적인 커뮤니케이션의 핵심은 투명성입니다. 대기 근무 시스템을 시작하거나 기존 대기 근무 시스템을 변경할 때는 반드시 업무 가능 상태에 대한 기대치를 명확히 해야 합니다. 직원이 할 수 있는 다음과 같은 일반적인 질문에 대해 생각하고, 질문에 대한 명확한 답변을 제공해야 합니다.
- 엔지니어들이 야간 대기 근무를 하게 됩니까?
- 야간 대기 근무를 하면 다음 날 재택 근무를 할 수 있는 유연성이 있습니까? 대기 중 직원이 잠을 자야 하는 경우 다음날 늦게 출근해도 됩니까?
- 개발자는 대기 근무 시간 중에 개발 작업을 수행해야 합니까?
- 개발자가 한 달에 몇 번 대기 근무를 해야 합니까? 한 담당자가 대기 근무를 맡는 최대 횟수는 몇 번입니까?
- 대기 중 직원에 대한 보상은 어떻게 이루어집니까?
적절한 교육 제공
대기 중 팀을 교육하는 모범 사례는 다음과 같습니다.
- 프로세스와 일반적인 문제를 모두 다루는 교육 프로그램 개발
- 최신 런북 제공
- 신규 직원이 경험이 풍부한 대기 중 엔지니어 밑에서 배우기
- 직원에게 과거 인시던트 보고서에 대한 액세스 권한을 부여(처리 중인 것과 비슷한 이전의 인시던트가 성공적으로 해결된 방법 확인 가능)
에스컬레이션 채널을 여러 개 사용하는 것도 좋은 방법입니다. 일반적인 모범 사례는 주요 대기 중 교대 근무에 후임 엔지니어를 배정하고 선임 엔지니어를 백업 또는 보조 교대 근무로 일정을 짜는 것입니다. 그렇게 하면 후임 엔지니어는 자신의 전문 지식을 넘어서는 문제가 발생할 때 당황하지 않고 필요한 대기 근무 기술을 개발할 수 있습니다.
대기 중 업무 및 개발 업무를 별도로 유지
대기 근무 중에 개발 업무를 수행하면 일반적으로 많은 컨텍스트 전환 및 중단이 발생하며, 특히 인시던트와 대기 중 요구 사항이 자주 발생하는 회사의 경우 더욱 그렇습니다.
그러면 일반적으로 개발 효율성이 떨어지고 대기 중 엔지니어가 더 많은 스트레스를 받게 되며 번아웃, 알림 피로 및 업무 불만족으로 이어질 수 있습니다. 또한 대기 중 담당자가 주어진 스프린트에 얼마나 기여할 수 있고 기여할 것인지 추정하기가 어렵기 때문에 개발 스프린트에도 부정적인 영향을 미칠 수 있습니다.
그렇기 때문에, 모범 사례로 대기 중 업무와 개발 업무를 분리하는 것이 좋습니다. 대기 중 직원에게 여유 시간이 있으면 대기 근무 관련 문서 및 자동화를 개선하는 작업을 할 수 있으며, 궁극적으로 시스템 및 서비스의 지속 가능성이 향상됩니다.
대기 중 프로세스 세부 조정
대기 중 담당자 시스템은 프로세스와 시스템을 정밀하게 조정하여 지속적으로 개선하는 경우에만 뛰어난 상태를 유지할 수 있습니다. Jira Service Management와 같은 인시던트 관리 솔루션으로 대기 일정, 라우팅 규칙 및 에스컬레이션 정책을 사용자 지정하여 알림을 효율적으로 처리하세요. 이 목표를 달성하기 위해 다음 사항을 추천합니다.
- 알림의 우선 순위와 긴급도를 평가하고 그에 따라 시스템을 설정합니다. 긴급도가 낮은 알림은 아침까지 보류해도 되므로 대기 중 직원은 필요한 수면을 취할 수 있습니다.
- 근본 원인, 문제가 시작된 시스템, 메시지, 임계값 등과 같은 요소를 기준으로 알림을 분류하여 오탐지를 줄입니다. 이렇게 하면 조치를 취할 수 있는 알림을 나머지 알림과 구분하는 데 도움이 됩니다.
- 알림 피로를 방지하기 위해 중복된 관련 알림을 제거합니다.
- 문제를 명확하게 설명하고 대기 중 엔지니어가 효과적인 의사 결정을 내리고 런북에 기록된 지식을 적용할 수 있도록 권한을 부여하는 풍부한 알림을 설계합니다.
- 시스템의 취약한 부분을 파악하고 개선할 수 있도록 대기 중 팀에 알림 보고서 및 메트릭을 제공합니다. (즉, 대기 중 팀이 똑같은 문제로 인해 반복적으로 방해받지 않도록 합니다.)
대기 중 보고서를 검토하고 필요에 따라 조정
모든 것을 공정하게 유지하고 직원의 번아웃을 방지하기 위해, 매니저는 대기 근무와 관련된 보고서를 검토하여 다음을 확인해야 합니다.
- 각 팀원이 호출을 받거나 잠에서 깨는 빈도
- 각 팀원이 대기 근무에 할애한 시간
- 각 직원에 대한 시간별 및 일별 대기 중 업무 분배
- 필요에 따라 일정을 조정하여 업무를 공정하게 분배
직원의 말에 귀 기울이기
경영진은 대기 중 엔지니어와 정기적으로 전체 회의를 열어 문제, 불만 사항 및 취약점을 논의한 다음 문제 해결을 위한 조치를 취해야 합니다.
대기 근무 시스템, 도구, 프로세스, 직원, 문서 및 교육은 설정하고 잊어버려도 될 만한 정적인 것이 아닙니다. 회사가 성장하고 팀이 학습하고 변화하며 시간이 지남에 따라 인시던트가 바뀌면서, 경영진은 대기 근무 프로그램을 지속적으로 다시 평가하고 개선해야 합니다.
효과가 있는 것과 그렇지 않은 것을 알려주기에 가장 적합한 담당자는 대기 중 엔지니어입니다. 대기 중 엔지니어들의 의견을 듣고 변경 사항을 구현하세요. 그리고 가장 중요한 점은 대기 중 조직 및 프로토콜과 관련하여 경영진이 유일한 의사 결정권자가 아니어야 한다는 것입니다. 팀에게 자체 프로세스와 관행을 개선할 권한을 더 많이 부여할수록 팀은 대기 근무를 더 잘 받아들이게 됩니다.
친근한 대기 중 문화 조성
대기 중 엔지니어는 회사의 성공에 대한 막중한 책임을 지고 있습니다. 따라서 특히 원인을 알 수 없는 주요 문제가 발생했을 때 대기 중 엔지니어가 스트레스와 긴장감을 많이 느끼는 것은 당연합니다.
선임 대기 중 엔지니어 및 관리 팀이 조성한 대기 근무 문화는 직원이 스트레스와 긴장에 어떻게 대처하는지, 그리고 대기 근무에 대해 어떻게 생각하는지를 나타내 줍니다.
대기 중 엔지니어와 회사의 대기 근무 문화 모두를 위해, 경영진은 친근한 대기 근무 문화를 조성하는 데 주의를 기울이고 목표는 항상 시스템의 문제, 위험 및 취약점을 찾아 해결하는 것임을 분명히 해야 합니다.
Atlassian에서 이는 대기 근무 시스템을 지속적으로 개선하는 것뿐만 아니라, 비난의 대상을 찾는 대신 개선에 중점을 둔 비난을 배제한 사후 검토를 하는 것을 의미합니다.
긍정적인 대기 중 담당자 문화를 지원하는 솔루션인 Jira Service Management에 대해 알아보고 향상된 커뮤니케이션 기능, 중앙 집중식 알림, 유연한 자동화, 인시던트 대응에 대한 고급 보고 기능을 갖춘 시스템을 구축하세요.