장애 보고서의 특징
•
첫째, 장애 보고서는 개발자가 원할 대 쓸 수 없습니다.
•
둘째, 장애의 1차 원인은 대부분 다른 원인의 결과다.
•
셋째, 장애 보고를 받는 윗사람은 대부분 개발자가 아니다.
•
넷째, 장애를 해결했다고 해서 100% 해결한 것은 아니다.
장애 보고서를 쓸 때는 다음의 글쓰기 방법이 필요합니다.
•
질문에 대답하는 신속한 글쓰기
•
원인과 이유를 찾는 분석적 글쓰기
•
상사를 고려하는 비즈니스 관점의 글쓰기
•
원하는 것을 얻는 정치적 글쓰기
질문에 대답하는 신속한 글쓰기#
•
사용자가(주어) 결제를(목적어) 할 수 없다(서술어) 같은 식으로 단순하게 작성합니다.
•
이를 일단 적고, 정리를 합니다.
제목 : 서버 모듈 변경 문제로 사용자 결제 불가(10~11시)
•
장애 내용 : 사용자 결제 불가(10:00 ~ 11:00)
•
장애 영향 : 장애 중 결제 시도 100건 -> 1시간 후 결제 비율 10%
•
장애 원인 : 서버 쪽 결제 모듈변경 시 모듈 인터페이스의 함수를 수정했으나 프런트에서는 기존 함수 호출로 에러 발생
•
조치 상황 : 서버 쪽의 바뀐 함수를 호출하도록 프런트 코드 수정
•
조치 결과 : 결제 기능 정상 작동
•
핵심 원인 : 서버 쪽과 프런트 쪽 커뮤니케이션 단절
•
향후 대책 : 서버, 프런트 팀장이 소통 방법 협의하여 보고
Copy
원인과 이유를 찾는 분석적 글쓰기#
•
문제 해결 기법 중에 5Whys가 있으며 이는 어떤 원인을 찾을 대 근본적인 원인을 찾는 기법입니다.
◦
문제의 원인이 되는 인과 관계를 탐색할 때 다섯 번 반복해서 원인이 무엇인지 질문하는 방식입니다.
•
why는 어떤 일 또는 사람을 의미합니다.
•
대부분의 경우, IT분야에서 장애는 재발합니다.
•
많은 경우, 개발자 사이의 커뮤니케이션 오류가 바로 핵심 원인입니다.
상사를 고려하는 비즈니스 관점의 글쓰기#
•
장애 보고서를 비즈니스 관점으로 쓴다는 것은 매출과 비용 관점으로 설명한다는 것입니다.
•
개발자 관점은 결제 기능이 작동하지 않은 것이지만, 비즈니스 관점은 기대 매출의 손실이 발생한 것입니다.
•
즉, 장애로 인한 손실을 계산하는 것이 곧 비즈니스 관점으로 장애를 보고하는 방법입니다.
원하는 것을 얻는 정치적 글쓰기#
•
상사는 모호한 표현을 싫어합니다.
•
따라서, 이를 퍼센트로 정확하게 말하고 향후 예산 등을 받아내는 방법이 필요합니다.
장애 재발 가능성 | 표현 |
1% | 절대 재발하지 않는다 |
10% | 재발하지 않는다 |
20% | 재발할지도 모른다 |
30% | 재발할 수도 있다 |
40% | 재발한다고 볼 수도 있다 |
50% | 재발할 수 있다 |
60% | 재발하지 않는다고 볼 수 없다 |
70% | 재발한다고 보여진다 |
80% | 재발한다 |
90% | 재발할 것이 틀림없다 |
99% | 반드시 재발한다 |
•
정확한 단어와 문장으로 현상과 사실얼 있는 그대로 표현해야 합니다.
