1. 장애 전파
장애를 탐지하게 되면 장애가 발생한 원인을 파악함과 동시에 관련된 부서로 장애 내용을 전파합니다. 장애 전파는 장애 해결 못지 않게 상당히 중요합니다. 관련된 부서에서 당황하지 않고 같이 대응할 수 있고, 영향을 받는 회사들이 장애 내용을 전달받아 필요한 대응을 할 수 있기 때문입니다. ((그러나 실제로 장애에 부딪히면 자체적으로 해결해 보려고 애쓰느라 장애 대응 상황에 대한 전파가 잘 이루어지지 않는 경우가 종종 있습니다. 장애 전파만 잘 이루어져도 장애 해결에 대해 다른 부서의 도움을 받거나, 장애에 영향을 받는 쪽에서 준비된 대응을 실시해 장애의 영향 범위를 줄이는 효과를 얻을 수도 있기 때문에 해결 만큼이나 중요하게 생각해야 합니다.))
2. 장애 해결
장애 전파와 동시에 장애가 지속되거나 확산되는 것을 막기 위해 노력합니다. 이때 중요한 것 중에 하나가 장애를 전파하는 사람과 장애를 해결하는 사람이 가능하면 나누어져 있어야 한다는 것 입니다. 장애의 원인을 파악하고 분석하는 작업과 장애를 전파하는 작업 모두를 한 사람이 하는 것이 꽤 힘들고 장애 지속 시간을 길어지게 만들기 때문입니다.
3. 장애 보고
장애 대응이 어느 정도 완료되면 장애 보고서를 작성합니다.
요약: 장애 상황에 대해 간략히 설명한다.
장애 탐지 시간: 장애가 최초 탐지된 시간을 명시한다.
영향받은 서비스: 장애에 영향받은 서비스를 명시한다.
장애 원인: 장애가 발생한 원인을 설명한다.
타임라인과 해결 과정: 장애가 최초 발생한 시점부터 주요 진행 과정을 순서대로 설명한다. 어떻게 대응했는지 자세한 설명을 덧붙인다.
해결 과정과 예방책: 장애를 어떻게 해결했는지, 어떤 예방 조치를 취해야 하는지 자세하게 설명한다. Jira 티켓 정보도 포함한다.
관련 문서 및 추가 정보(선택 사항): 필요하면 기타 정보를 추가한다.
4. 장애 회고
장애를 돌아보면서 원인 분석 및 향후 대응책을 논의하는 자리를 갖습니다. 팀 내부적으로 먼저 회고하는 자리를 갖고 어느 정도 정리된 내용을 토대로 관련된 개발자들이 모여서 다시 한 번 회고를 진행합니다
.
출처 -
