장애 대응과 모니터링
문제가 생기면 알게 될 거라고 생각합니다. 실제로는 사용자 문의로 알게 되고, 그것도 대개 몇 시간 뒤입니다. 그사이 얼마나 많은 사람이 못 썼는지는 기록조차 남지 않습니다.
한 문장으로
장애 대응은 문제가 생겼을 때 고치는 일이 아니라, 문제가 생겼다는 사실을 사용자보다 먼저 아는 체계를 갖추는 일입니다.
하는 일
- 무엇을 감시하나 — 응답 여부와 속도, 오류율, 디스크, 인증서 만료일
- 알림 경로 — 누구에게 어떤 방법으로, 그리고 못 봤을 때는 누구에게
- 심각도 구분 — 지금 깨울 일과 아침에 볼 일을 나누기
- 복구 절차 — 무엇부터 확인하고 어떤 순서로 되돌리는가
- 사후 기록 — 원인과 조치를 남겨 같은 일이 반복되지 않게
- 정기 점검 — 알림이 실제로 오는지 일부러 확인해 보기
하지 않는 일
- 성능 개선 — 느린 것을 빠르게 만드는 일은 별도 작업입니다
- 보안 사고 대응 — 절차와 법적 의무가 달라 따로 다룹니다
- 사용자 문의 응대 — 장애를 아는 방법이지 대응 체계는 아닙니다
이웃 개념과 헷갈리는 지점
- 백업잃었을 때 되살리는 것
- 감시는 사고를 빨리 알게 하고 백업은 되돌리게 합니다. 감시만 있으면 무슨 일이 났는지는 알아도 되돌릴 수가 없습니다.
- 모니터링 도구지표를 모으고 보여주는 것
- 도구를 켜는 것과 대응 체계는 다릅니다. 알림을 받는 사람이 정해져 있지 않으면 그래프만 예쁘게 쌓입니다.
- SLA가용성을 숫자로 약속하는 것
- 99.9% 는 연간 약 8.7시간을 멈춰도 된다는 뜻입니다. 약속은 목표를 정할 뿐이고, 그 목표를 지키는 일은 감시와 복구가 합니다.
- 온콜돌아가며 대기하는 당번
- 새벽에 알림을 받을 사람이 있느냐가 설계를 크게 바꿉니다. 사람이 없으면 알림을 아침으로 미루는 설계가 오히려 정직합니다.
언제 필요한가
이럴 때 필요합니다
- 서비스가 멈춘 것을 고객 전화로 알았을 때
- 밤이나 주말에 문제가 생기면 아무도 모르는 구조일 때
- 인증서 만료로 사이트에 경고가 떴던 적이 있을 때
- 느리다는 말을 듣는데 실제로 재본 적이 없을 때
아직 아니어도 됩니다
- 내부에서만 쓰고 잠시 멈춰도 되는 시스템이라면 순위가 낮습니다
- 사용자가 곧바로 알려주는 구조이고 그 지연을 감수할 수 있다면 아직입니다
- 감시는 켰는데 아무도 알림을 안 보는 상태라면, 도구를 늘리기 전에 받을 사람을 정하는 것이 먼저입니다
여기서부터는 갈립니다
어디까지 감시하고 누가 언제 받을지는 사업 성격에 따라 갈립니다. 새벽에 깨울 사람이 있느냐가 설계를 크게 좌우하는데 그 답은 조직마다 다릅니다. 그리고 알림을 촘촘히 걸수록 좋아지지도 않습니다. 어느 지점을 넘으면 사람이 알림을 무시하기 시작하고, 그때부터는 감시가 없는 것과 같아집니다. 그 지점이 어디인지는 몇 달 돌려 보기 전에는 알기 어렵습니다.
자주 묻는 질문
사이트가 열리는지, 그리고 인증서와 도메인 만료일입니다. 이 셋만으로도 실제 사고의 상당수가 잡힙니다. 오류율이나 응답 속도는 그다음이고, 처음부터 많이 켜면 알림에 무뎌집니다.
평소에 보는 곳이어야 합니다. 메일함은 대개 늦게 봅니다. 업무 메신저나 문자로 받되, 심각한 것과 참고용을 다른 채널로 나누는 편이 오래갑니다.
받을 사람이 정해져 있으면 그때 대응하고, 없으면 아침에 봅니다. 중요한 것은 둘 중 무엇인지 미리 정하는 것입니다. 정해 두지 않으면 밤에도 못 고치고 아무도 안 잔 상태가 됩니다.
무엇이 고장 났는지에 따라 다릅니다. 다만 복구 시간의 대부분은 고치는 시간이 아니라 원인을 찾는 시간입니다. 그래서 감시 항목과 로그가 갖춰져 있으면 같은 사고라도 복구가 훨씬 빨라집니다.
작은 서비스라면 무료 한도로 시작해도 충분한 경우가 많습니다. 비용이 갈리는 지점은 감시 대상 수가 아니라 로그를 얼마나 오래 보관하느냐입니다. 사고 원인을 찾으려면 지난 로그가 필요하니 거기서 정하시면 됩니다.
범위가 애매해도 괜찮습니다
지금 상황만 알려 주시면 필요한 범위와 대략의 규모를 짚어 드립니다.