건강한 On-Call 문화 만들기

- 업무시간 외에 문제 발생시 호출(Paging)받아서 해결할 엔지니어를 지정하는 "온콜"에 대한 SoundCloud의 팁
1. 온콜 업무는 선택 사항임(Optional, 신청자만)
2. 정규 근무시간 외 근무이므로 시간당 수당으로 지급되고, 페이징에 응답시 시간당 추가 지불
3. 온콜 엔지니어는 여러 로테이션들로 구성
4. 각 로테이션은
ㅤ→ 한개 또는 여러 팀을 대표하는 엔지니어들의 그룹으로 구성
ㅤ→ 로테이션내의 모든 팀의 문제에 대해 1차 지원을 담당할 1명의 엔지니어가 항상 대기
ㅤ→ 그외의 엔지니어들은 자기 팀들의 서비스에 대한 문제를 담당하는 2차 지원을 제공하기 위해 대기
ㅤ→ 2차 지원은 최선 노력(best-efforts) 기반 : 언제든 페이징 받아서 가능하면 최선을 다해서 처리하지만, 자신이 불가능할 때는 꼭 응답할 필요 없음

왜 온콜 업무가 엔지니어들한테 좋을까?
- DevOps 및 SRE(Site Reliability Engineers) 외에 다양한 엔지니어들을 온콜 업무에 넣는 것은 회사와 엔지니어 본인들에게도 좋음
- 항상 시간외 근무가 많은 운영팀 엔지니어 들의 부담을 줄여줌
- 엔지니어들이 안정적이고 잘 문서화된 시스템을 구축하도록 동기를 부여
ㅤ→ 문제발생시 직접 보는 것은 시스템을 어떻게 개선하고 탄탄하게 만들지에 대한 인사이트를 얻게 됨
- 자신들의 시스템과 남의 시스템을 함께 지원하는 것은 엔지니어들한테 배울 수 있는 좋은 기회

절차적 모범사례 : 모든 조직은 다르지만 SoundCloud가 찾은 최적의 프로세스
- 각 로테이션마다 교대 주기가 다르지만, 대부분 1일에서 2일단위로 교대
- 한달에 3일정도 온콜에 들어가는게 최적. 그것 보다 많으면 번아웃 되고, 적으면 효율적이지 못함.
ㅤ→ 즉 로테이션의 최적 인원은 8~12명. 10명이면 완벽.
- 로테이션내에서 공식/비공식 관리자를 뽑아서, 교대 근무 일정 관리 및 인원 변경 등 로테이션을 관리
ㅤ→ 예) 연휴 기간의 교대 일정에 대한 조정

로테이션 팀과 조직들
- SoundCloud 조직은 시간에 따라 발전하고, 병합/분할/새로운 팀 생성/팀의 부서간 이동등이 일어났음
- 그러나 온콜 로테이션팀은 엔지니어링 조직과 같은 속도로는 발전하지 않았음
- 현재는 많은 로테이션들이 전혀 관련없는 팀의 무작위 그룹처럼 보이기도 함
- 하지만 문제가 되지 않고, 이걸 변경하려는 시도에 엔지니어들이 이의를 재기해서 중단됨

문화적 모범사례 : 온콜 엔지니어와 회사 전체의 이익을 위해 다음과 같은 규범 및 태도를 육성
- 온콜인 사람들은 온콜에 있기를 원함. 자의로 책임을 부담하고 (보상을 받는) 엔지니어는 사고에 대응할 때 더 많은 동기를 부여받음
- 교대 주기 같은 문제는 각 로테이션의 엔지니어들이 협의 하여 결정. 회사는 교대 패턴/교대 시각/개인간 교대 이관 등에 대해서 표준 절차를 제공하지 않음
- 온콜 엔지니어들은 정규 근무시간 내에 이런 문제들이 악화되거나 다른 사람을 비근무시간에 페이징하지 않도록 조사하는데 시간을 쓰는 경우가 많음
- 사고 대응시, 엔지니어들은 다른 엔지니어를 호출해서 도움 요청 가능. 누구도 한밤중에 2차지원 호출을 받는걸 좋아하지 않지만, 가능하다면 응답해서 도와줌으로써, 차후에 같은 상황을 혼자 처리 가능하게 교육해줄 수 있게 됨
- 합리적인 시간이 지난후, 다른사람에게 자유롭게 작업을 넘겨 줄 수 있음. 중대 또는 장기지속 되는 사고의 경우 엔지니어들이 피곤해져서 효율적으로 작업이 불가능하다면, 4시간 또는 그 안에라도 남에게 인계하는게 좋음
- 가장 중요한건, "비난 문화가 아닌 학습 문화를 육성하는 것". 아무리 강조해도 지나치지 않음
ㅤ→ 실수는 사고 대응에서 불가피한 부분이고, 실수로 부터 배우면 더 강력하고 기술적으로 능숙한 엔지니어링 조직이 구축 됨
ㅤ→ 실수로 사람들을 처벌하면 엔지니어는 새로운 상황 발생시 행동하는 것을 두려워하고, 도움요청하는 걸 두려워하게 되고, 투명성을 두려워 하게 됨
ㅤ→ 결국 비난의 문화에서는 온콜 로테이션을 그만두거나 회사를 떠나게 됨

큰 사고가 일어났을 때
- 전체 사이트 중단 또는 심각한 사고에 대응하는 것은 모두에게 스트레스
- 이건 또한 회사의 온콜 문화에 대한 스트레스 테스트 이기도 함
- 엔지니어가 함께 일하고 서로를 신뢰하는 것이 그 어떤것보다 중요
- 모르는 것을 인정하고, 다른 사람에게 도움을 요청하고, 실수를 한 것에 대해 정직하게 말하고, 너무 피곤해서 계속 진행하기 어렵다고 말할수 있게 되면 문제를 더 빨리 해결할 수 있음
- 이런 행동을 육성하는 건 큰 사고가 발생하기 전에 해야 함. 엔지니어는 작은 사고들에 대응하고 동료와 협력하면서 경험으로 배우게 됨.
ㅤ→ 작은 사고 들은 큰 사고에 대한 연습임

[xguru]

- GitHub이 구축한 온콜 문화 https://news.hada.io/topic?id=3551
- GitLab On-Call Runbooks https://news.hada.io/topic?id=966

스타트업은 사람이 없으니, 항상 온콜해야 하는 느낌이긴 합니다만..
조직이 조금 커지기 시작하면 일부 인원만 게속 온콜하게 되고, 저녁과 주말에도 문제를 해결하면서 번아웃 되는 걸 볼 수 있습니다.
기본적으로 문화 형성을 잘 해야 할 것 같아요 (정작 저도 잘 못했던 것 같아서 반성 중입니다..)