# 건강한 On-Call 문화 만들기 > Clean Markdown view of GeekNews topic #4405. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=4405](https://news.hada.io/topic?id=4405) - GeekNews Markdown: [https://news.hada.io/topic/4405.md](https://news.hada.io/topic/4405.md) - Type: news - Author: [xguru](https://news.hada.io/@xguru) - Published: 2021-06-07T11:05:46+09:00 - Updated: 2021-06-07T11:05:46+09:00 - Original source: [developers.soundcloud.com](https://developers.soundcloud.com/blog/building-a-healthy-on-call-culture) - Points: 25 - Comments: 1 ## Topic Body - 업무시간 외에 문제 발생시 호출(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시간 또는 그 안에라도 남에게 인계하는게 좋음 - 가장 중요한건, "비난 문화가 아닌 학습 문화를 육성하는 것". 아무리 강조해도 지나치지 않음 ㅤ→ 실수는 사고 대응에서 불가피한 부분이고, 실수로 부터 배우면 더 강력하고 기술적으로 능숙한 엔지니어링 조직이 구축 됨 ㅤ→ 실수로 사람들을 처벌하면 엔지니어는 새로운 상황 발생시 행동하는 것을 두려워하고, 도움요청하는 걸 두려워하게 되고, 투명성을 두려워 하게 됨 ㅤ→ 결국 비난의 문화에서는 온콜 로테이션을 그만두거나 회사를 떠나게 됨 큰 사고가 일어났을 때 - 전체 사이트 중단 또는 심각한 사고에 대응하는 것은 모두에게 스트레스 - 이건 또한 회사의 온콜 문화에 대한 스트레스 테스트 이기도 함 - 엔지니어가 함께 일하고 서로를 신뢰하는 것이 그 어떤것보다 중요 - 모르는 것을 인정하고, 다른 사람에게 도움을 요청하고, 실수를 한 것에 대해 정직하게 말하고, 너무 피곤해서 계속 진행하기 어렵다고 말할수 있게 되면 문제를 더 빨리 해결할 수 있음 - 이런 행동을 육성하는 건 큰 사고가 발생하기 전에 해야 함. 엔지니어는 작은 사고들에 대응하고 동료와 협력하면서 경험으로 배우게 됨. ㅤ→ 작은 사고 들은 큰 사고에 대한 연습임 ## Comments ### Comment 5393 - Author: xguru - Created: 2021-06-07T11:06:04+09:00 - Points: 5 - GitHub이 구축한 온콜 문화 https://news.hada.io/topic?id=3551 - GitLab On-Call Runbooks https://news.hada.io/topic?id=966 스타트업은 사람이 없으니, 항상 온콜해야 하는 느낌이긴 합니다만.. 조직이 조금 커지기 시작하면 일부 인원만 게속 온콜하게 되고, 저녁과 주말에도 문제를 해결하면서 번아웃 되는 걸 볼 수 있습니다. 기본적으로 문화 형성을 잘 해야 할 것 같아요 (정작 저도 잘 못했던 것 같아서 반성 중입니다..)