GitHub이 구축한 온콜 문화
(github.blog)GitHub은 Ruby on Rails로 구성된 커다란 모노리스 시스템이었다.
# 모노리스 온콜 구조에서 가장 어려웟던 부분
- 크고 많은 제품과 기능이 포함되어 있었기에 대부분의 엔지니어가 코드베이스를 충분히 이해하지 못하고 온콜때 장애에 대응할 수 있다고 자신하지 못함. 호출받았을때 다른 팀에 에스컬레이팅하면서 엔지니어 보다는 연결 운영자처럼 느껴지게 되었다.
- 온콜간의 간격이 길었고 한번 온콜은 24시간 이었다. 엔지니어는 1년에 4번이내로 온콜을 했고 온콜 중 충분한 컨텍스트를 얻지 못했다.
- 모니터링과 경고시스템이 여러 팀에 분산되었고 온콜을 24시간만 경험하므로 온콜 모니터링과 문서가 잘 유지되지 않았다.
- 대부분의 엔지니어가 모노리스 온콜에 자신이 없었기 때문에 전체 시스템을 잘 아는 5~10명이 모든 프로덕션 장애에 참여하게 되고 온콜 책임의 불균형이 발생했다.
# 새로운 온콜 문화
## 업무 조직상의 장애물
- 파일오너쉽을 명확히 하도록 서비스 카탈로그를 만들어서 파일을 서비스에 매핑하고 서비스를 다시 팀에 매핑했다.
- 모니터링과 알림이 모노리스 전체에 설정되어 있어서 각 팀이 책입지는 영역의 모니터링을 만들도록 했다.
- 이 작업을 할 팀이 많아서 팀마다 GitHub에 이슈를 만들고 체크리스트를 제공했다.
## 문화적 교육적 장애물
- 판데믹이 사람들에게 부정적인 영향을 끼쳐서 기존에 생각한 것보다 더 공감우선 접근을 해야했다.
- 대부분의 엔지니어가 온콜 경험도 없고 운영 경헙도 많아서 교육을 만들어서 제공했다. 온콜 전문가와 근무시간을 설정하고 충분한 도구와 문서를 만들고 도움받을 수 있는 Slack 채널을 만들었다.
- 많은 엔지니어가 온콜이 삶에 얼마나 영향을 줄지 걱정했다. 경험이 많지 않으면 온콜 중 일상 생활의 시간을 조정하는 것이 어려울 수 있다. 이를 위해 온콜 전문가들의 팁/트릭을 정리하고 호출을 놓쳤을 때 다른 사람이 백업할 수 있게 하는 등의 조치를 취했다. 이건 익숙치 않음의 문제라서 훈련보다는 온콜을 여러번하면서 시간이 지나야 편안함을 느끼게 될 것이다.
- 온콜에 잘 대응하지 못할까봐 걱정이 많았기 때문에 실수를 저질러고 괜찮고 아무리 잘해도 장애는 발생할 수 밖에 없다는 안정감을 주려고 하고 있다.
- 제품마다 심각도 수준이 다르므로 어떤 팀은 5분내에 응답해야 하지만 어떤 팀은 다음날 처리해도 된다. 어떤 사람들은 이것이 불공평하다고 얘기하지만 엔지니어마다 관심사가 다른 것일 뿐이다.
- 변경사항을 적용하면서 각 팀이 온콜 경험을 개선시키는데 많은 시간을 쓸 수 없다. 온콜이 제대로 이루어지지 않을때 온콜 프로세스를 개선해야 한다. 팀에게 ~20%를 기술 부채를 갚는데 사용하고 ~20%를 온콜 경험을 개선하는데 써야 한다고 전달했고 리더쉽의 장기적인 관점이 필요하다.
저희 회사의 경우 보통 두달에 일주일 정도 업무외 시간 시스템 장애에 실시간으로 대응하는 걸 on-call이라고 합니다. PagerDuty 라는 앱을 많이 쓰는데, severity가 high인 장애가 발생하면, - dead letter가 생긴다든디, api failure rate가 어느 정도를 넘어간다든지 ... - 하면 휴대폰으로 즉시 alarm이 오고 회사 랩톱으로 접속해서 로그확인하면서 필요한 조치를 취합니다.