주니어의 사내 장애 대응 프로세스 도입기

최근에 사내 서비스 장애 대응 가이드를 구축하고 문서화하여 전사 공유한 경험이 있어 이를 공유하고자 합니다.

또한, 다양한 기업들의 프로세스를 접하면서 알게된 장애 대응 프로세스의 핵심적인 요소들과 사후 관리 프로세스에 대해서도 함께 정리해보고자 합니다.

---

🧨 발단

몇달 전, 개발팀 내 실수로 서비스 중인 인스턴스가 종료되는 사고가 발생했습니다.

다행히도 트래픽이 많지 않을 때 발생한 사고였기 때문에 동일한 인스턴스를 빠르게 구축하고 배포하여 해결할 수 있었지만, 기획 및 서비스 운영팀과 소통하면서 동시에 장애를 복구하는 과정이 생각보다 순탄하지만은 않음을 알게 되었습니다.

전사적인 장애인만큼 개발팀 내에서는 사고의 영향도를 파악하는 데 많은 시간과 집중력이 요구되기도 했고, 동시에 운영팀과 커뮤니케이션하면서 사고 발생 경위와 원인, 현재 복구 진행 상황에 대해 지속적으로 공유하여야 했기 때문입니다.

물론 이와 같이 전 서비스에 영향을 미치는 큰 사고는 이번이 처음이라, 개발팀 내에서도 장애 상황을 파악하고 엔지니어링하는 과정에서 예상보다 많은 시간이 소요된 것도 문제의 원인 중 하나였습니다.

하지만 개발팀 내외로 소요되는 커뮤니케이션 비용을 효과적으로 줄이면서도 장애 상황에 대한 공유가 전사에 정확하게 이루어질 수 있었다면, 엔지니어가 복구에 더욱 집중할 수 있어 더욱 빠르게 서비스가 정상화될 수 있었을 것이고 운영팀에서도 장애 상황에 대해 정확하게 인지하여 비즈니스 및 서비스 측면에서의 사후 대응을 충분히 논의할 수 있었을 것입니다.

따라서 사고가 마무리되고 몇주 뒤, 지난 장애에 대해 생각해보던 중에 사내 장애 대응 프로세스를 구축하여 문서화하고, 이를 시스템화하여 앞선 문제들을 해결하기로 결심하게 되었습니다.

---

🚨 파악된 문제들

장애 대응 프로세스 도입을 위해 먼저 그 목적을 명확히 할 필요가 있습니다.

목적이 명확하지 않다는 건 해결해야 할 문제가 명확하지 않다는 것을 의미하고,
해결해야 할 문제가 명확하지 않으면 자칫 문제와 동떨어진 엉뚱한 결론에 도달하게 될 수도 있기 때문입니다.

특히 이번 장애 대응 프로세스와 같이, 전사의 팀원이 인지하고 따르게 될 새로운 업무 프로세스가 정작 근본적인 문제를 해결하지 못한다면, 오히려 작업의 진행 속도가 저하되고 새로운 프로세스에 적응하는 팀원들의 리소스가 낭비되는 또 다른 문제를 발생시킬 우려가 있습니다.

따라서 앞선 서비스 장애 시 겪은 문제들을 아래와 같이 정리하고, 새롭게 도입될 장애 대응 프로세스가 아래 문제들을 실제로 해결할 수 있을지를 최소한의 가이드라인으로 삼아, 단순히 번거로워진 업무 프로세스가 만들어지지 않도록 작업을 진행하였습니다.

1. 상황 공유 및 정보 요청 책임의 부재

첫 번째로 파악한 문제는 상황 공유 및 정보 요청 책임의 부재입니다.

지금까지 사내에는 서비스 장애 발생 시의 어떠한 가이드라인도 존재하지 않았기 때문에 운영팀과 개발팀 간 장애 상황 공유에 있어 많은 불편과 혼란이 있었습니다.

예를 들어 장애가 발생하게 되면, 운영팀에서는 서비스 정상화 이전에 재빠른 공지 혹은 이후 보상 체계와 같은 다양한 비즈니스 문제들에 대해 협의와 결정을 거쳐야 하는데요.
이를 위해서는 장애 발생 영향도와 복구 진행도, 예상되는 서비스 정상화 시각 등 다양한 정보들이 필요합니다.

하지만 이러한 정보를 미리 전사에 공유하는 책임이 개발팀 내에 존재하지 않았고, 따라서 운영팀 입장에서는 누구에게 정보를 요청해야 하는지 명확하지 않아 재빠른 대응이 어려운 상황이었습니다.

결국 이런 상황에서 상황 공유와 정보 제공의 책임이 개발팀 내 모든 엔지니어들에게 부과되면서 장애 대응 과정에서의 혼란과 잦은 커뮤니케이션 오류, 개발팀 내 혹은 각 팀 간의 정보 불균형을 초래하게 되었습니다.

2. 장애 복구 책임의 부재

두 번째는 앞서 소개한 첫 번째 문제와 비슷한 맥락으로, 장애 복구 책임의 부재입니다.

장애 상황에 대한 지속적인 상황 공유 책임과는 별개로, 발생한 장애 원인을 파악하고 빠르게 복구하는 책임 또한 중요합니다.

하지만 암묵적으로 개발팀 전체에 장애 복구에 대한 책임이 주어지다보니, 모든 개발팀원이 장애 복구에 참여하게 되면서 기존의 필수적인 업무들이 마비되고, 이는 결국 비효율적인 복구 작업으로 이어지게 되었습니다.

하나의 장애 상황에 모든 엔지니어들이 투입되면, 이를 위한 내부 커뮤니케이션 비용이 더욱 증가하게 되고, 증가한 커뮤니케이션 비용 대비 복구 작업의 집중도와 효율성은 점점 떨어지게 된 것입니다.

또한 장애가 오래 지속될수록, 타 팀의 장애 상황 정보 요청은 주로 특정 엔지니어에게 집중되기 때문에 해당 엔지니어는 장애 복구 및 상황 공유에 대한 모든 책임을 떠안게 된다는 우려도 있습니다.

3. 기술적 커뮤니케이션 사용

세 번째로는 기술적 커뮤니케이션의 사용입니다.

장애 발생 시에는 어쩔 수 없이 커뮤니케이션 비용이 급증하게 되는데요, 이에 따라 모든 팀원들이 장애 상황에 대해 정확하게 인지하고 추후 남은 문제들에 대해 건설적으로 커뮤니케이션을 이어나갈 수 있어야 합니다.

하지만 이번 장애의 경우, 운영팀과 개발팀이 지속적으로 커뮤니케이션을 이어갔음에도 불구하고 서로 장애 발생 상황을 Align 하는 과정에서 비효율적인 커뮤니케이션이 반복적으로 오갔습니다.

결국 서비스가 정상화된 후, 이번 장애 발생 상황에 대해 운영팀과 다시 커뮤니케이션하는 시간을 가지게 되었고 그때서야 이번 장애와 관련한 여러 의문점들을 서로 정확하게 Align 할 수 있게 되었습니다.

사실 이러한 근본적인 원인은 장애 상황 공유 시 개발팀이 사용한 커뮤니케이션 방식에 있었습니다.

아래 사진은 개발팀이 공유한 장애 상황 요약 예시입니다.

개발 직군이라면 한 번에 읽고도 어떠한 상황인지를 바로 파악할 수 있을 것입니다.

반면 운영팀 입장에서 위 요약은 불필요한 정보들 뿐입니다.
그래서 현재 발생한 장애가 어떤 서비스에까지 영향을 미치는지, 현재 복구는 어디까지 진행되었는지, 예상되는 복구 시간은 언제인지 등 실제로 비즈니스와 서비스 의사결정에 더욱 중요한 정보들은 모두 빠져있습니다.

또한 기술적인 용어들로 작성되어 있어 위 요약문을 통해 비개발 직군의 팀원과 소통하기 위해서는 "도커 컨테이너", "AWS Console", "인스턴스" 등 많은 용어에 대한 부가 설명이 필요할 수도 있는 상황입니다.

만약 개발팀 내부적으로 장애 상황 Align 을 위해 작성된 요약문이라면 효과적이겠지만, 그렇지 않다면 비효율적인 커뮤니케이션이 증가할 수 밖에 없게 만드는 핵심적인 문제 원인입니다.

4. 장애 회고 프로세스 부재

마지막으로는 장애 회고 프로세스의 부재입니다.

서비스 장애는 언제, 어디에서, 어떻게 발생할지 누구도 예상할 수 없기 때문에 사전 예방 대책보다도 사후 관리 대책이 더욱 중요하다고 생각합니다.

사후 관리 대책이란 결국, 동일한 장애가 발생하지 않도록 최대한 방지하고, 동일한 장애가 발생했다면 기존 레퍼런스를 참고하여 최소한의 시간으로 복구에 투입되는 리소스를 줄여나가는 것이 그 목적이라고 볼 수 있습니다.

그리고 이를 달성하기 위해서는 장애 복구 이후의 회고 프로세스가 필수적으로 필요합니다.
이 과정에서 장애 원인을 정확하게 파악하고, 이후 기술적으로 시스템 개선 방향을 논의하며, 논의된 내용을 문서로 기록해두기 때문입니다.

하지만 기존에는 발생한 장애에 대한 회고와 개선 방향에 대한 논의가 이루어지지 않고 있었고, 이는 동일한 장애가 반복적으로 발생하거나, 이후 동일한 장애의 복구 시간을 전혀 단축시킬 수 없음을 의미합니다.

결국 장애 회고 프로세스와 같은 사후 관리 대책에 대한 논의가 이루어지지 않는다면, 장애는 해결된 것으로 볼 수 없으며 장애 프로세스 도입은 무의미하다고 볼 수 있습니다.

---

🚀 프로세스 구축

지금까지 기존에 겪고 있던 장애 대응 시의 문제점을 크게 네 가지로 정리하여 보았습니다.

• 상황 공유 및 정보 요청 책임의 부재
• 장애 복구 책임의 부재
• 기술적 커뮤니케이션 사용
• 장애 회고 프로세스 부재

이제부터는 위 문제들을 해결할 수 있는 효과적인 장애 대응 프로세스를 구축하는 일이 남았습니다.

물론 큰 기업들의 장애 대응 프로세스를 경험해본 적이 없고, 직접 장애 대응 프로세스를 구축해본 경험도 없기 때문에 다양한 기업들의 장애 대응 프로세스 관련 기술 블로그 글들을 참고하였고, 현재 서비스와 팀 환경에 따라 적용할 수 있는 부분들을 선택적으로 차용하고 수정하여 적용하였습니다.

아래는 장애 대응 프로세스 구축에 큰 도움이 되었던 기술 블로그 글입니다.

• LINE 플랫폼 서버의 장애 대응 프로세스와 문화
• LINE의 장애 보고와 후속 절차 문화
• 장애 대응 ‘이것’부터 시작하세요
• [우아~한 장애대응] - 우아한 형제들 기술블로그(현재 접근 불가)
  
  

장애 탐지

장애 대응 프로세스는 장애를 탐지하는 단계부터가 시작입니다.

따라서 현재 서비스 장애를 인지하고 탐지할 수 있는 채널이 어떻게 구성되어 있는지를 먼저 파악하여야 합니다.

주로 모니터링 알람, 고객의 CS, 조직 내에서 바로 탐지하게 되는 경로가 대부분일텐데요.
저희 서비스도 크게 다르지 않았습니다.

• 시스템 모니터링 알람
• 조직 내 탐지
• 고객 센터 문의를 통한 탐지

이 중에서는 시스템 모니터링을 통한 슬랙 알람으로 가장 먼저 장애를 탐지하는 것이 좋은 탐지 경로이며, 고객의 CS 를 통한 탐지는 유저보다 늦게 장애에 대해 인지할 수 있었다는 의미이므로 좋지 않은 탐지 경로라 볼 수 있습니다.

특히 시스템 모니터링이나 조직 내 탐지를 통해 유저보다 먼저 장애에 대해 인지할 수 있게 되면, 일명 "잠수함 패치"를 통해 새롭게 수정된 버전을 조용히 배포하는 작업도 가능합니다.

따라서 되도록이면 시스템 상태에 대한 장애 탐지가 빠르게 이루어질수 있도록 탄탄한 모니터링 인프라를 구축해놓는 것이 중요하다고 볼 수 있겠습니다.

장애 전파

장애가 탐지된 후에는 빠르고 정확하게 장애 상황이 팀 내에 전파되어야 합니다.

장애가 탐지된 즉시 책임부서 및 장애 영향을 받는 유관 부서에게 장애 상황이 전파되는 것이 가장 중요하며, 저희 서비스는 소규모 인원의 운영팀과 개발팀만으로 이루어져 있기 때문에 전사 전파를 기본 원칙으로 하는 것이 더욱 적절할 것으로 판단되었습니다.

장애가 탐지된 직후 빠르게 서비스를 정상화하는 것만큼, 유저의 불편에 대한 보상체계를 논의하고 공지사항을 작성하는 등 서비스 운영팀에서 논의하여야 하는 사항들도 상당히 중요하기 때문입니다.

저희처럼 작은 스타트업의 경우에는 대부분의 팀원이 서비스 장애에 영향을 받고 있기 때문에 전체 팀원이 합류한 장애 관련 슬랙 채널을 개설하여 장애 상황의 전사 전파를 기본 원칙으로 하였습니다.

또한, 장애 탐지와 동시에 즉각적으로 장애를 전파하는 일도 당연해보이지만 쉬운 일은 아닙니다.

만약 탐지된 장애가 개발팀 내에서 충분히 해결가능하다고 판단하여 전사 전파를 미루게 될 경우가 존재할 수 있기 때문입니다.

하지만 현재 장애와 관련된 작업을 진행 중이거나, 장애 영향도를 잘못 파악한 것을 뒤늦게 깨닫게 될 경우 장애 복구에 걸리는 시간과 리소스는 빠르게 불어나게 되고, 손쉽게 장애를 해결하는 데 도움을 줄 수도 있는 팀원이 해당 장애 상황에 대해 인지하지 못하기 때문에 오히려 비효율적인 장애 복구 작업으로 이어질 수도 있습니다.

따라서 장애 탐지와 함께 서비스 영향도가 빠르게 파악되면, 모든 장애에 대해 즉각적으로 전사 전파하는 것이 장애 전파 단계에서의 핵심적인 요소라고 볼 수 있습니다.

장애 복구

탐지된 장애에 대한 전사 전파가 완료되면, 장애의 확산을 방지하고 최대한 빠르게 서비스를 정상화하는데 집중하는 장애 복구 단계로 넘어오게 됩니다.

이 단계에서 핵심적인 요소는 크게 세 가지가 있습니다.

• 장애 상황 공유와 장애 복구 책임 분리 운영
• 장애 원인 파악보다는 서비스 정상화에 집중
• 장애 상황 공유 시 시스템 상태보다는 서비스 상태에 집중

1️⃣ 먼저, 장애 상황 공유와 장애 복구 책임의 분리 운영입니다.

앞서 파악했던 기존 장애 대응 시의 문제점에서도 장애 상황 공유에 대한 책임과 장애 복구 책임이 명확하지 않아 혼란스러웠던 점을 꼽았던만큼, 장애 복구 시에 지속적으로 상황을 공유하는 책임과 직접 장애 복구에 투입되어 서비스를 정상화하는 책임은 명확하게 다루어져야 합니다.

기존에는 개발팀 내 모든 엔지니어가 불분명한 책임을 나눠가지고 장애 상황 공유 및 장애 복구 모두를 한 번에 담당해왔다면, LINE 에서는 이러한 책임 자체를 장애 상황을 공유하는 전파 엔지니어와 장애 복구를 담당하는 복구 엔지니어로 분리 운영하는 것을 권장하고 있습니다.

이는 장애 상황에 대한 공유와 장애 복구에 대한 모든 책임을 모든 엔지니어가 나눠가지거나, 한 명의 엔지니어가 담당하는 것이 비효율적이기 때문입니다.

모든 엔지니어가 장애 복구와 장애 상황 공유 책임을 나눠가지게 된다면, 개발팀 내 모든 엔지니어는 지속적으로 장애 상황에 대해 Align 하는 커뮤니케이션이 필요하게 되며, 커뮤니케이션이 원활하게 진행되지 못했을 경우 운영팀의 장애 정보 요청에 따른 엔지니어 간 답변이 서로 상이하거나 운영팀이 정보를 요청할 대상이 여전히 불분명하기 때문에 지난 장애 상황에 겪었던 문제를 해결할 수 없습니다.

반대로 한 명의 엔지니어가 장애 복구와 동시에 실시간으로 장애 상황을 공유하는 것은 장애 복구에 전념하는 엔지니어의 집중력을 저하시키고 결국 장애 복구 시간을 지연시키는 결과를 초래할 수 있습니다.

따라서 장애 발생 시에는 개발팀 내에서 장애 복구 엔지니어와 장애 전파 엔지니어를 분리 운영하고 모든 장애 상황에 대한 정보 요청은 전파 엔지니어를 통하도록 하여 책임을 분리하는 것이 효과적인 방법일 것으로 판단되었습니다.

이렇게 각각의 책임을 분리하여 운영하게 되면, 개발팀 내에서는 복구 엔지니어와 전파 엔지니어의 최소한의 장애 상황 Align 만 필요하게 되고, 외부로부터의 장애 관련 정보 요청 책임은 전파 엔지니어에게 있기 때문에 운영팀과 개발팀 간 커뮤니케이션도 효율적으로 개선할 수 있을 것이라고 생각했습니다.

2️⃣ 두 번째로는 장애 원인 파악보다는 서비스 정상화에 집중하는 것입니다.

실제로 발생하는 장애는 간단한 작업만으로 해결할 수 있는 상황이 대부분이라고 합니다.

예를 들어, 대부분의 장애는 배포 직후에 발생할 확률이 높다고 합니다.
거대하고 복잡한 아키텍처의 서비스에서 잘못 짠 코드가 배포되어 장애를 발생시키는 경우가 상당히 잦기 때문입니다.

이 때, 서비스 정상화를 뒤로 미루어두고 새롭게 배포된 코드를 직접 뜯어보며 장애가 발생한 원인을 찾아내는 것보다는 이전 배포로 빠르게 롤백(Rollback)하여 우선적으로 정상화된 서비스를 제공하는 방향이 올바른 장애 복구 프로세스의 방향이라고 볼 수 있습니다.

장애 원인 파악에는 얼마나 많은 시간이 소요될지 아무도 알 수 없고, 서비스가 거대하고 복잡할수록 근원적인 원인 파악에는 더욱 신중하게 접근하여야 하기 때문에 장애 복구 프로세스에서 서비스 정상화는 장애 원인 파악보다 기본적으로 우선하게 됩니다.

3️⃣ 마지막으로는 장애 상황 공유 시 시스템 상태보다는 서비스 상태에 집중하는 것입니다.

이는 앞서 파악한 문제점들 중 세 번째, 기술적 커뮤니케이션 사용 문제를 해결하기 위한 원칙입니다.

장애 탐지 후 최초 전파와 함께, 장애 복구 과정에서도 동일하게 장애 상황 공유는 지속적으로 이루어져야 합니다.
장애 상황과 관련하여 새롭게 파악된 원인이나 서비스 영향도, 예상 정상화 시간 등 다양한 정보들이 지속적으로 업데이트되면서 전사에 공유되어야 하기 때문입니다.

다만 이렇게 업데이트된 장애 상황 정보를 작성하는 과정에서 앞서 보았던 문제점들처럼 과도하게 기술적 용어를 사용한다거나, 정작 운영팀에서 필요로 하는 정보가 포함되지 않은채로 작성하게 되면, 결국 반복적인 커뮤니케이션이 증가하게 되고 장애와 관련한 여러 비즈니스 의사결정들에 지장을 줄 수 있습니다.

따라서 전파 엔지니어는 본인이 익숙한 시스템 상태의 서술에 집중하기 보다는, 모든 팀원이 쉽게 이해할 수 있도록 서비스 상태의 서술에 집중하여 장애 상황 정보를 작성 및 공유하여야 합니다.

아래는 시스템 상태에 집중한 방식과 서비스 상태에 집중한 방식의 차이를 보여주는 예시입니다.

• 시스템 상태에 집중한 작성 예시

(1)
- 주식 거래 API 의 Transaction Isolation Level 이 잘못 설정되어 DeadLock 발생.
- 특정 Connection 종료하고 데이터 무결성 확인한 뒤 서비스 정상화 예정.

(2)
- A 서버에 트래픽이 몰려 레이턴시가 높음.
- 스케일 아웃 진행 중이며 10분 정도 소요될 것으로 예상됨.

• 서비스 상태에 집중한 작성 예시

(1)
- 짧은 시간에 주식 거래 사용량이 급증하여 주식 거래 서비스 오류 발생.
- 현재 주식 거래 서비스, 보유 평가액 조회/비교 서비스 사용 불가.
- 거래 데이터 확인 후 이상없으면 두 서비스 모두 정상화 예정.

(2)
- 사용자 급증하여 A 서비스 이용이 원활하지 않음.
- 전체적인 접속 속도가 느리며 간헐적으로 페이지 접근이 되지 않을 수 있음.
- 서버 증설 진행 중이며 10분 후에 정상화 될 예정임.

시스템 상태에 집중한 작성 예시에서는 과도한 기술적 커뮤니케이션이 사용되었으며, 해당 장애로 인해 어떤 서비스가 영향을 받았는지에 대한 정보는 포함되어 있지 않습니다.

반면, 서비스 상태에 집중한 작성 예시는 기술적 커뮤니케이션을 최대한 지양하고, 장애로 인해 영향을 받은 서비스들의 상태에 대해 명확하게 정보를 제공하고 있음을 알 수 있습니다.

장애 상황 공유의 목적은 전사 팀원의 장애 상황 Align 과 장애 대응을 위한 재빠른 비즈니스/서비스 의사결정에 있기 때문에 서비스 상태에 집중하여 작성하는 방법이 가장 적합하다고 판단하였습니다.

또한, 추가적으로 아래 사진과 같은 장애 상황 공유 양식을 제작하여 전파 엔지니어가 손쉽게 장애 상황을 작성하고 지속적으로 공유할 수 있도록 하였습니다.

아래 양식 제작의 목적은, 전파 엔지니어의 장애 상황 공유에 대한 부담을 최대한 덜어내고 동시에 운영팀이 필요로 하는 장애 관련 정보들의 기입을 강제함으로서 서비스 상태에 집중한 장애 상황 공유를 자연스럽게 유도하기 위함입니다.

양식의 각 항목에 대한 설명은 본 포스팅의 가장 마지막에 설명드리도록 하겠습니다.

장애 보고

지속적인 실시간 장애 상황 공유와 함께 장애 복구가 완료되어 서비스가 정상화되었다면, 장애 보고서를 작성하여 레퍼런스로 남겨야 합니다.

장애 보고서에는 아래와 같은 항목들을 기입하게 됩니다.

• 장애 요약
• 장애 탐지
• 영향받은 서비스
• 장애 발생 원인
• 장애 대응
• 타임라인
• 향후 대책

장애 보고서가 실시간 장애 상황 공유와 다른 점은 시스템 상태에 집중하여 작성하게 되기 때문에 이를 통한 기술적 커뮤니케이션이 가능하다는 점일 것입니다.

장애 보고서는 서비스 정상화 후에 장애가 발생한 원인과 추후 대책에 대해 깊게 분석하고 논의하면서 완성해나가게 되고, 추후 유사한 장애가 발생할 때 참고하여 복구 시간을 효과적으로 단축시키는 레퍼런스로서 작동합니다.

따라서, 다양한 장애 상황에서의 복구 방법을 최대한 자세하게 작성하여야 하기 때문에 기술적인 내용을 기반으로 작성하게 될 수밖에 없고, 장애 보고 단계부터 이후 장애 회고 단계를 거치며 단계적으로 작성됩니다.

아래는 직접 작성한 장애 보고서의 양식입니다.

타임라인에서는 장애 최초 전파 이후부터 서비스 정상화까지 시도했던 모든 해결 과정을 시간대 별로 작성합니다.
이 때 전파 엔지니어가 성실히 공유해준 슬랙의 장애 상황 공유 스레드를 참고하면, 손쉽게 타임라인을 작성할 수 있습니다.

장애 회고

마지막으로 장애 대응 프로세스에서 가장 핵심적인 단계인 장애 회고 단계입니다.

장애 회고는 개발팀이 모여 함께 진행하며, 장애가 발생한 원인을 분석하여 이후 장애 재발 방지를 위한 실효성있는 대책과 시스템을 논의합니다.

이 때, 회고에서 논의된 모든 향후 대책을 명확한 액션으로 추출하여 장애 보고서의 향후 대책 항목에 기입하고, 곧바로 Jira 백로그에 추가합니다.

장애 발생 원인으로부터 향후 대책을 도출해낼 때 중요한 점은 도출된 대책이 명확한 액션이어야 한다는 점입니다.

예를 들어, 아래와 같이 불명확한 대책이 도출되었을 경우, 장애 회고는 무의미해지고 동일한 장애가 재발하게 될 가능성이 높습니다.
또한 인재 사고의 경우에는, 장애 발생 원인이 단순히 특정 엔지니어의 잘못으로 귀결되는 잘못된 상황이 발생할 수도 있습니다.

- 인스턴스 중지/재시작 시에는 신중을 기할 것.

따라서 명확한 액션으로 도출된 향후 대책이란, 아래와 같이 실행가능하고 측정가능한 형식이어야 합니다.

 - 인스턴스 종료/중지 방지 기능 활성화
 - 인스턴스 종료 시 볼륨 제거 비활성화
 - 인스턴스 내부 DB 환경 분리 및 주기적 백업 활성화

이제 명확하게 도출된 액션을 백로그에 추가하고 이후 스프린트에서 순차적으로 적용하여 동일한 장애가 재발하지 않도록 환경과 시스템을 변경할 수 있게 되었습니다.

---

🍺 완성된 사내 장애 대응 프로세스

1️⃣ 이렇게 5단계에 이르는 사내 장애 대응 프로세스가 완성되었습니다.

• 장애 탐지
• 장애 전파
• 장애 복구
• 장애 보고
• 장애 회고

추가적으로, 사내 장애 대응 원칙과 장애 상황 공유 양식 / 장애 보고서 양식도 함께 작성되었습니다.

2️⃣ 완성된 사내 장애 대응 원칙은 총 다섯 가지이며, 아래와 같습니다.
모두 장애 대응 프로세스의 각 단계에서 살펴본 내용이기 때문에 부가적인 설명은 생략하도록 하겠습니다.

3️⃣ 슬랙에 실시간으로 공유되는 장애 상황 공유 양식은 아래와 같습니다.

장애 등급은 아래와 같이 정의하여 그 심각도와 우선순위를 한 눈에 파악할 수 있도록 정리해놓았습니다.

발생 시각과 탐지 시각은 다른 개념입니다.
발생 시각은 장애가 발생하기 시작했을 것으로 추정되는 시각을 의미하고,
탐지 시각은 발생한 장애를 팀 내에서 인지한 시각을 의미합니다.

만약 장애가 발생한지 한참 후에 장애를 탐지할 수 있었다면, 이는 모니터링 시스템이 미흡하게 구축되어 있었다는 의미이기 때문에 장애 회고 단계에서 이러한 부분까지 함께 논의되어 향후 대책이 도출됩니다.

추가적으로, 발생 시각이나 서비스 영향, 발생 원인과 같은 항목은 장애 탐지 후 최초 전파 시에는 아직 정확하게 파악되지 못했을 가능성이 높습니다.

따라서 이러한 경우, TBD(To Be Determined) 로 기입해두고, 파악되는대로 업데이트하여 스레드에 올라가게 됩니다.

4️⃣ 장애 보고부터 장애 회고를 거쳐 작성되는 장애 보고서 양식은 아래와 같습니다.

---

🎁 마무리하며

이번 장애 대응 프로세스를 구축하기 위해 수많은 아티클들을 읽어보면서 재직 이후로 가장 많은 문서를 작성해본 프로젝트가 아닐까 싶습니다.

하지만 개인적으로 필요성을 느끼고 주도적으로 시작한 작업인만큼 즐겁게 임했고, 또 그만큼 서비스 장애를 바라보는 관점에 있어 배운 점도 많았습니다.

이렇게 구축된 장애 대응 프로세스는 이미 전사에 적용되었고, 이후 발생하는 서비스 장애부터는 위 프로세스에 따라 장애 대응이 이루어지게 됩니다.
따라서 새로운 장애 대응 프로세스가 앞서 정의한 네 가지 문제들을 효과적으로 해결해내는지를 중점적으로 피드백하며 수정을 거듭해갈 계획입니다.

감사합니다:)