첫 15분에 할 일

장애 연락을 받으면 반사적으로 로그부터 열게 됩니다. 자연스러운 반응이지만 순서가 틀렸습니다.

장애 대응의 첫 목표는 원인 규명이 아니라 영향 최소화입니다. 원인은 몇 시간이 걸릴 수도 있지만 영향 범위는 몇 분이면 파악됩니다. 그리고 그동안 할 수 있는 조치가 있는지는 영향 범위를 알아야 판단됩니다.

현실적인 이유도 있습니다. 상사나 고객사가 처음 묻는 것은 원인이 아니라 "지금 얼마나 심각한가"입니다. 로그를 뒤지느라 이 질문에 답하지 못하면, 대응은 하고 있는데 아무것도 안 하는 것처럼 보입니다.

신고를 받으면 정보가 파편적으로 옵니다. "시스템이 안 돼요"라는 한 문장으로 시작하는 일이 대부분입니다. 이걸 대응 가능한 형태로 바꾸는 질문이 네 개 있습니다.

• 특정 사용자만이면 데이터 문제일 가능성이 높습니다. 그 사용자의 데이터로 재현해 봅니다.
• 특정 지점이나 부서만이면 네트워크 경로나 권한 설정을 먼저 봅니다.
• 전 사용자면 공통 구간입니다. 서버, DB, 외부 연동, 인증 중 하나입니다.
• 간헐적이라면 여러 인스턴스 중 일부만 문제일 수 있습니다. 어느 서버로 붙었는지 확인이 필요합니다.

아무것도 바뀌지 않았는데 갑자기 장애가 나는 경우는 생각보다 드뭅니다. 대부분 무언가 바뀌었고, 그 변경을 찾으면 원인의 절반은 나온 것입니다.

주의할 점은 "아무도 안 바꿨다"는 답을 그대로 믿으면 안 된다는 것입니다. 배포만 변경이 아닙니다. 데이터가 늘어난 것도, 인증서가 만료된 것도, 디스크가 찬 것도 변경입니다.

고객사 시스템을 다루면 서버에 직접 붙지 못하는 경우가 많습니다. 원격 접속 신청에 시간이 걸리거나, 아예 안 되고 담당자를 통해 자료를 받아야 합니다.

이때는 무엇을 요청할지 정확히 아는 것이 실력입니다. 한 번에 필요한 것을 다 요청하지 못하면 왕복하며 시간을 버립니다. 그동안 장애는 계속됩니다.

• 명령은 결과를 파일로 남기게 작성합니다. 화면을 캡처해 보내면 검색도 안 되고 잘립니다.
• 시간 범위를 명시합니다. 전체 로그를 달라고 하면 수 기가바이트가 오거나 거절당합니다.
• 전화로 대응할 때는 상대가 입력할 명령을 미리 준비해 두고 불러 줍니다. 즉석에서 만들면 오타가 납니다.
• 폐쇄망이라 파일 반출이 안 되면 화면 공유나 원격 지원을 요청합니다. 터미널·서버 코스의 오프라인 대응이 여기서 쓰입니다.

원인을 모르는 상태에서 보고하는 것이 어색하게 느껴질 수 있습니다. 하지만 침묵이 더 나쁩니다. 연락이 없으면 상대는 상황을 모른 채 불안해하고, 결국 재촉 연락이 오면서 대응 시간을 잡아먹습니다.

첫 보고에는 원인이 없어도 됩니다. 네 가지만 있으면 충분합니다.