안녕하세요, 저는 데브시스터즈 기술본부 인프라셀에서 DevOps 엔지니어로 일하고 있는 이창원입니다. 이 글에서는 데브시스터즈에서 전사적으로 적용하고 있는 기술적 관점에서의 장애 대응 원칙과 방법 전문을 공개합니다.
문서에 대한 설명은 데브시스터즈 엔지니어링 데이 Infra/SRE 행사 영상에서도 확인하실 수 있습니다.
개요
이 문서는 우리가 운영하는 각종 서비스의 장애에 대한 탐지, 대응, 예방을 위해 가져야 할 자세와 방법론에 대해 서술합니다.
원칙
📌 이 원칙들은 구성원들이 상시 장애 상황을 모니터링하라는 의도에서 만들어진 것이 아니며, 꼭 필요한 순간에만 기민한 대응을 할 수 있도록 원칙과 방법을 설정한 것입니다.
📌 모두가 기본적인 응급 조치를 할 수 있는 역량을 확보해야 합니다. 그래야 담당자가 쉬거나 부재 중이더라도 다른 사람이 대응할 수 있고, 서로를 믿고 편하게 쉴 수 있습니다.
-
[장애 대응의 목표] 장애 대응의 최우선 목표는 서비스가 가능한 정상적으로 동작하게 하는 것입니다.
- 지식이나 경험의 많고 적음에 관계 없이, 서비스 담당자인지 아닌지에 상관 없이 대응이 가능한 사람이라면 그 자리에서 할 수 있는 최선의 노력을 통해 문제 해결에 적극적으로 기여해야 합니다.
- 문제의 원인을 찾아 내려가는 것에만 집중해서는 안됩니다. 개발자라면 문제 발생 시 원인을 파내려가고 싶다는 걸 이해합니다. 그러나 비행 중 문제 발생 시 가장 먼저 할 것은 승객들이 안전하게 대피할 수 있도록 비행기를 잘 착륙시키는 것입니다.
- 스스로 알고 있는 지식으로 문제를 빠르게 해결할 수 있을지 판단해야 하며, 어려울 것 같은 경우 다른 사람에게 부탁해야 합니다.
-
[에스컬레이션과 상황 전파] 필요할 경우 적극적으로 도움을 요청해야 합니다.
- 장애가 발생한 사실을 뒤늦게 깨닫는 것보다는, 오탐이라도 장애 상황을 의심하고 다시 한 번 점검하는 것이 훨씬 더 좋습니다. 장애 인지를 했는데 이게 장애인지 아닌지, 어떻게 해야 할지 판단이 안 서는 경우에는 시간 장소 관계 없이 즉시 다른 사람들을 부르도록 합시다.
- 호출을 받는 사람은 이런 종류의 호출에 기분 나빠하거나 부담스러워하지 말고, 이런 호출이 있을 수 있다는 사실을 인지하고 문제를 같이 파악합니다.
- 같은 사람을 호출하는 상황이 반복된다면 해당 알람 관련 맥락을 다른 사람에게 잘 전파해주고 있는지를 점검해 보아야 합니다.
-
[장애 대응을 위한 환경 준비] 장애에 대응할 수 있도록 적절한 장비와 세팅을 최대한 유지합니다.
- 랩탑을 항상 휴대합니다. (사전에 입사자의 멘토가 랩탑 장비 신청 시 휴대성을 고려하여 신청하는 것을 권장합니다)
- 언제든 대응할 수 있도록 랩탑에도 평소 개발/운영 환경(Wireguard, SSH, AWS Console, kubectl, 간단한 스크립트 등)을 셋업하고, OS 버전업/기기 변경 등 다양한 변화에도 항상 잘 동작하게끔 준비하여야 합니다.
- Wi-Fi가 없는 환경에서도 대응할 수 있도록 사용하는 개인 폰에 테더링 환경(요금제 포함)을 구축하거나, 여의치 않은 경우 회사로부터 LTE 모뎀 / LTE 법인폰 등을 지급받아 준비합니다.
-
[장애 감지의 방법] 장애를 감지할 수 있는 알람 시스템을 구축하고 모두가 받을 수 있도록 항상 준비합니다.
- 장애 슬랙 채널의 알람은 티어에 맞게 Notification 설정을 All new messages 로 설정, 문제를 빠르게 인지할 수 있도록 합니다.
- 장애 문자, 전화 발신자는 Do not Disturb(방해 금지) 예외로 설정해둡니다.
- 적절한 티어링 체계를 갖추면 알람 체계를 잘 유지할 수 있습니다. 문서의 아래 항목에서 그러한 티어링 방안을 제안하고 있으니, 그에 맞춰서 알람 시스템을 정비하길 권장합니다.
-
[알람 건전성] 모든 알람은 약식으로라도 대응을 하여야 합니다.
- Feed 채널과 알람 채널의 목적은 다릅니다. 확인 결과 대응이 필요하지 않은 알람이었을 경우 알람 조건 수정, 티어 재배치 등을 진행합니다.
- 양치기 소년 이야기의 교훈을 인지해야합니다. 알람을 보고 2차적인 판단을 거쳐 대응하지 않는 케이스가 생기게 되면 이후 심각한 문제 발생 시에도 제대로 대응하지 못하는 경우가 있을 수 있으며, 새로운 사람이 맥락을 따라가기도 어렵게 됩니다.
- 알람에 대응하는 방식에는 여러가지가 있을 수 있습니다. 인지하였음을 스레드로 메시지를 남기거나, 관련한 이슈를 생성하거나, 알람 조건을 조정하고자 하는 논의를 시작하는 등 비교적 낮은 적극성의 액션부터 장애 선언을 하는 높은 적극성의 액션까지가 모두 포함됩니다.
-
[기록과 커뮤니케이션] 장애 대응 중 실행된 액션들은 객관적으로 공유되어야 합니다.
- 수행하는 조치가 멱등하지 않을 수 있으므로 시스템에 대한 변경 내역은 장애 대응에 참여하고 있는 사람들에게 반드시 공유되어야 하며, 채팅 메세지 혹은 장애 대응 문서에 판단 근거, 조치 시간과 함께 기록을 남아야 합니다.
- 장애 상황에서 조치 내용은 시스템에 대한 이해를 바탕으로 문제 해결을 위한 가설을 세우고, 이를 시험하기 위해 실행한 작업이 실제 안정화에 도움이 되는지 확인하는 과정을 거치기 때문에, 엔지니어로서의 역량을 빠르게 성장시킬 수 있는 기회이기도 합니다. 기록을 잘 남겨둘수록 장애 대응에 참여하지 않았던 다른 구성원들의 역량 강화에도 도움이 되며, 이는 우리가 더 견고한 팀이 되는 가장 효율적인 방법입니다.
- 장애 대응에 반드시 기술 직군만 개입하는 것이 아니므로, 유관 부서에 커뮤니케이션할 때에는 기술적 배경이 적은 사람들도 이해할 수 있도록 작성하는 것을 권장합니다.
-
[장애 회고의 중요성] 모든 인프라는 다양한 이유로 장애가 날 수 있지만, 같은 이유로 같은 장애를 겪는 것은 우리의 잘못입니다.
- 장애 원인과 조치 내용을 기록으로 남기고 동일한 유형의 장애를 예방할 수 있는 방법을 모색합니다.
- 되짚어볼 필요가 있는 장애라면 업무시간 중 시간을 잡아 포스트모템을 진행합니다. 포스트모템에서의 논의가 건설적일 수 있도록 사전에 논의할 내용은 미리 작성해두도록 합니다.
- 장애 회고 미팅의 참여자들은 비난하지 않는 포스트모템이 될 수 있도록 주의를 기울여야 합니다. 이를 위해서는 장애 대응 과정 중의 모든 조치들이 각자의 상황에서 최선을 다했음을 신뢰하여야 합니다. 만약 결과적으로 잘못된 의사결정 혹은 실수가 있었더라도, 그러한 결과로 이어지게 된 시스템적 원인에 대해 논의할 수 있어야 합니다. 어떠한 실패라도 시스템을 강화할 수 있는 기회로 이어질 수 있습니다.
알람 티어링 권장 체계
알람을 분류할 때 최초 대응 시간(FRT, First Response Time: 문제 상황을 인지하고 파악하는 시작 시점) 을 기준으로 삼을 것을 권장합니다. 대응의 완료를 포함하는 시간이 아닌, 최초 인지 및 파악을 시작하기까지의 시간을 말합니다.
알 람을 설정할 때 가급적 알람이 울린 채널만 보고 바로 대응 조치가 필요한지를 직관적으로 알 수 있도록 설정하는 것이 좋습니다.
아래 장애 유형에 부합하지 않는 알람이 있다면, 팀에서 FRT 기준에 맞게 자율적으로 판단하여 적절한 티어에 추가할 수 있습니다.
[Tier 0] 언제든지 대응해야 하는 최우선순위 알람 (<~ FRT 15min)
-
티어 정의
- 고객이 체감 가능한 문제가 발생하거나, 또는 서비스와 연관된 내부 컴포넌트의 안정성에 위험이 발생하는 경우입니다. 진행 중인 대부분의 일상 업무보다 높은 우선순위를 가지고 최대한 빠르게 대응합니다.
-
장애 인지
- 시스템을 통한 문제별 주요 담당자에게 전화, 문자
- Tier 0 알람 채널으로의 메시지 수신
만일 Tier 0수준의 장애에 대하여 위와 같은 시스템을 통한 선제적 인지를 하지 못하고 사람에 의한 인지나 우연에 기반한 파악을 하였다면, 모니터링 체계의 정비가 필요함을 의미합니다.
-
장애 유형
- 유저가 체감할 수 있는 이상 징후가 발생하는 경우
- e.g., API failure rate N% 증가, Latency XXms 지연 등
- 시스템의 일부가 복구 불가능한 상황을 맞이하여 시스템 자체 안전성에 대한 위험이 예상되는 경우 (당장의 문제가 일어나지 않는 경우를 포함 e.g., HA 구성된 시스템의 일부 장애)
- 유저가 체감할 수 있는 이상 징후가 발생하는 경우
[Tier 1] 최선의 속도로 대응해야 하는 차순위 알람 (FRT 평일 <~ 15m, 밤일 경우 다음날 오전까지인 약 12h)
-
티어 정의
- Tier 0과 같은 직접적인 영향은 감 지하지 않았지만 기술적인 연관성을 통해 Tier 0으로 퍼질 수 있는 경우입니다. 업무 시간 중에는 Tier 0과 같은 수준의 경각심과 우선순위로 빠르게 대응하나, 늦은 밤에 일어날 경우 다음날 오전에 확인하는 것을 목표로 합니다.
-
장애 인지
- Tier 1 알람 채널으로의 메시지 수신
Tier 1도 Tier 0과 마찬가지로, 시스템을 통한 선제적 인지를 하지 못하고 사람에 의한 인지나 우연에 기반한 파악을 하였다면 모니터링 체계의 정비가 필요합니다.
- Tier 1 알람 채널으로의 메시지 수신
-
장애 유형
- Tier 0 문제로 발전할 가능성이 있는 기술적 문제
- e.g., CPU Usage X% 이상 사용, DB latency API XXms 지연, 어플리케이션의 재시작 등
- e.g., Atlantis(인프라 배포 툴), Vault(사용자 인증), 사내 운영툴 장애 등
- Tier 0 문제로 발전할 가능성이 있는 기술적 문제
[Tier 2] 즉각적인 대응이 필요하지는 않지만 개입을 필요로 하는 알람 (FRT 평일 <~ 2~3h, 밤이나 주말일 경우 다음 업무일)
-
티어 정의
- 작업자의 개입이 필요하지만, 작업의 마감이 여유롭게 설정되었거나 또는 서비스 내외부적으로 직접적인 영향을 미치지 않아 시급성은 낮춰 대응해도 되는 경우입니다. 최대 1업무일 이내에 문제 해결계획을 수립하며, 실제 대응 작업을 더 늦게 진행할 경우 진행상황을 파악할 수 있도록 작업 티켓 등으로 기록을 남겨두는 것을 목표로 합니다.
-
장애 인지
- Tier 2 알람 채널으로의 메시지 수신
-
장애 유형
- 충분한 마감기한이 주어지는 작업
- e.g., 인증서 만료, AWS instance retirement, AWS API deprecation
- 주기적으로 문제를 인지하여 대응이 필요한 작업
- e.g., 정책적인 위반사항
- 비용에 대한 알람
- e.g., 데이터독 사용량, cost enforcer
- 충분한 마감기한이 주어지는 작업
효과적인 장애 대응 방법
💡 이 내용은 모든 것을 반드시 지켜야 한다기보다는 일종의 가이드라인입니다.
실제 장애 발생시 큰 틀 (장애 발생 공유 → 팀 구성 → 해결 → 종료 공유) 을 해치지 않는 선에서 융통성 있게 적용하시되, 포스트 모템을 진행할 때 어떤 것들이 어떤 이유로 가이드라인과 달라졌는지 설명해주세요.
아래의 예시를 따라 장애를 대응하면 보다 문제를 효과적, 효율적으로 대응할 수 있습니다.
- 이 내용은 가장 심각도가 높은 장애 상황을 가정하여 작성되었으므로 모든 장애 상황을 아래와 같이 대응하진 않아도 되고, 상황에 따라선 일부 항목을 생략할 수 있습니다.
- 위 티어링 체계 기준으로 Tier 0 및 1의 문제는 아래같이 대응하면 효과적입니다.
-
장애 최초 전파 및 대응 팀 구성
- 장애를 인지한 모든 인원은 즉시 팀 채널에 장애를 인지하였음을 알려야 합니다.
- 이후 장애 대응 팀을 구성합니다. 장애 대응 팀은 최소 2인 이상으로 구성함을 원칙으로 합니다.
- 장애 대응 팀은 지휘자와 기록가 역할 포함하도록 구성합니다.
- 각 역할은 특정 사람에게 명확하게 할당되어야 합니다.
ㅇㅇ님은 장애 기록 해주실 수 있을까요? 장애 문제는 제가 정리할게요
ㅁㅁ님은 서버 증설 준비해주세요
각 역할에 따라 해야 할 일은 다음과 같습니다.
A. 공통
- 장애 발생 원인 및 해결 방안을 탐색합니다.
- 의심이 되는 지점을 발견하면 다른 사람들에게 캡쳐나 링크 등의 근거자료와 함께 공유합니다.
- 장애 대응 과정에서 모든 의사 결정은 논의 하에 함께 수행합니다.
- 장애가 종료된 후, 포스트 모템 문서를 정리하여 공유합니다.
B. 지휘자
- 장애 상황을 주도적으로 파악하고, 대응 팀을 구성하여 역할을 분배합니다.
- 보통은 최초 인지자가 지휘자를 담당하는 경우가 많으며, 상황에 따라서 더 적절한 대상자가 있으면 다른 사람에게 지휘자를 인계할 수 있습니다.
- 추가 인원이 필요한 경우 다른 구성원들에게 적극적으로 연락하여 대응을 요청합니다.
- 특히 문제 해결에 어려움을 겪을 경우, 혼자서 고민하지 말고 최대한 빨리 다른 사람들의 도움을 요청하도록 합시다.
- 상황에 따라선 주 담당자 외에 외부의 인원이 문제를 함께 보는 것이 도움될 수 있습니다. (e.g., 인프라셀, 제품 팀 엔지니어, 동일 직군 다른 부서의 사람들, 그룹장 등)
- 대부분은 공동작업이 가능하나, 논의가 필요한 사항이 있다면 지휘자가 적극적으로 검토하고 결정합니다.
C. 기록가
- 원인, 고려한 해결 방안, 실제로 실행한 해결 방안 등 모든 것을 그 때 그 때 시간 순서로 기록합니다.
- 각자가 의심하는 지점 및 장애 조치 내용은 각자가 직접 공유해주는 것이 원칙이며, 기 록가는 그 내용들을 정리하고 수합하는 것이 주 목적입니다.
- 장애 복구에 성공적인 시도만 기록하는 것보다는 실패했던 시도도 기록하는 것이 나중을 위한 자산이 됩니다.
- 장애 시점의 각종 모니터링 지표, 자료, 그래프, 로그 등을 보이는 대로 모두 모아 가능한 실시간으로 기록합니다. 실시간으로 기록이 정리되면 문제가 복잡해져 여러 사람의 개입이 필요한 경우 정보 전달 속도에 이점이 생깁니다.
- 장애 상황의 공유를 주로 담당합니다. 장애가 길어지는 경우에는 (30분 이상 소요되는 경우) 대응 현황, 예상 복구 시간을 공유합니다. 주기적으로 계속 업데이트합니다. 종료된 후에도 공유합니다.
-
장애 대응 채널 구성
- 지휘자는 Datadog Incident 기능을 사용하여 장애를 선언하고, 별도의 장애 대응 채널을 구성합니다. 장애를 선언하는 방법은 다음과 같습니다.
- https://app.datadoghq.com/incidents/new 를 통해 UI에서 선언
- 슬랙의 장애 인지 채널에서
/datadog incident
명령어를 사용하여 선언
- Incident를 선언하면 해당 incident 전용 채널이 생성됩니다. 장애 대응에 관여하는 모든 인원은 해당 채널에서 커뮤니케이션합니다.
- 화면공유를 위해 Slack huddle 또는 Google Meet 등을 개설해도 되지만, 주 커뮤니케이션은 슬랙 메세지를 이용해 추후 타임라인 분석이 용이하도록 잘 기록합니다.
- 지휘자는 Datadog Incident 기능을 사용하여 장애를 선언하고, 별도의 장애 대응 채널을 구성합니다. 장애를 선언하는 방법은 다음과 같습니다.
-
장애 발생 공유
-
기록가가 장애 상황에 대해 인지한 즉시 슬랙을 통해 공유합니 다. 만일 유관 부서와도 연관되는 내용이라면 메일 등 적절한 수단을 통해 유관부서로도 공유합니다. 공유 시에는 다음 내용이 들어가야 합니다.
- 서비스 명
- 발생 시간
- 장애 규모와 범위
- 장애 대응 채널
- 장애 발생 메시지 예시:
장애@ 쿠키런 킹덤 PVP 부분 장애
조금 전 8월 11일 새벽 2시 35분경 부터 쿠키런 킹덤 PVP 서비스에 장애가 관측되고 있습니다. 약 25% 정도의 접속자가 영향을 받은 것으로 추정되고 있습니다. 용감한 쿠키, 명랑한 쿠키 2인이 #incident-XY 채널에서 대응 중이며, 추후 경과는 다시 공유드리겠습니다.
-
-
장애 원인 파악 및 해결
-
장애 대응은 기본적으로 원인 파악 → 해결 방안 탐색 → 해결 방안 시행 → 해결 여부 확인의 과정으로 진행됩니다.
-
앞서 명시한 장애 대응 원칙에 따라, 사용자들이 서비스 이용에 영향을 받는 상황이라면 근본 원인을 찾는 것보다 서비스를 가능한 빨리 복구하는 것을 우선시하여 대응해야 합니다.
⚠️ 어떠한 변경 작업 진행 시에는 반드시 작업 내용을 공유하여 함께 진행합니다.
시스템에 따라 멱등성이 보장되지 않을 수도 있으므로 일관성을 위해 시스템 변경은 1인이 진행해야 합니다. 그러나, 이 1인이 독단적으로 시스템을 변경해서는 안됩니다.
위급한 상황에서 개인이 단독으로 대응하는 것은 구성원 간 맥락의 전파를 저해할 뿐더러 긴급한 순간에서 빠르게 결정된 사항으로 더 나쁜 결과로 이어질 수 있습니다. 따라서 변경 작업 진행 시에는 커뮤니케이션을 통해 작업 내용을 같이 리뷰해나가며 진행하는 것이 우리의 방침입니다.
-
-
장애 종료 공유
-
장애 종료 메시지를 공유하는 것도 장애 대응의 일부입니다. 장애 대응이 끝나면 명확한 종료 선언을 하여 혼란을 방지합니다.
- Root cause 분석이 끝나지 않았더라도, 일단 당장의 문제가 해결되면 장애 상황은 종료된 것입니다.
-
장애 상황이 종료되면 장애 상황 종료에 대해 슬랙을 통해 공유합니다. 공유 내용으로는 다음 항목을 포함하여 작성해야 합니다.
-
장애 종료 시간
-
장애 발생 (추정) 원인
-
조치 내역 혹은 해결 방안
-
포스트모템 미팅 일시
-
장애 종료 메시지 예시:
장애@ 쿠키런 킹덤 PVP 부분 장애
2시 55분경 안정화되었습니다. PVP 서버 4대 중 1대에 이상이 생겨 해당 서버에 접속한 유저들에게 장애가 있었던 것으로 추정됩니다.
대응 조치로 해당 서버를 서비스에서 제외하고 새 서버 1대를 추가하였습니다.
서버에 왜 갑자기 이상이 생겼는지는 내일 중으로 추가 조사를 진행할 예정입니다.
장애 포스트모템은 내일 오후 3시에 퓨어바닐라왕국 연회장 회의실에서 진행하겠습니다.
-
-
후속 액션을 위해 다양한 직군이 관여되어야 할 수 있으므로 장애 종료 공지를 할 때에는 가급적 프로그래머가 아닌 직군들도 이해할 수 있는 표현을 사용하고, 자세한 기술적인 내용이 궁금하면 포스트모템을 참고하도록 안내합니다.
-
장애 종료가 공유되면 지휘자가 Datadog incident status를 조정합니다.
- 포스트모템 미팅이 예정되어 있을 경우: Active → Stable
- 포스트모템 미팅이 예정되어 있지 않을 경우: Active → Resolved
-
-
포스트모템 준비
- 효율적인 포스트모템을 위해 논의가 필요한 내용, 대응 과정을 미리 갈무리 해둡니다.
- 지휘자는 포스트모템 준비, root cause 분석, root cause 해결 등의 남은 작업을 특정 사람에게 명확하게 할당합니다.
- 포스트모템 템플릿을 참고하여 정보를 수집합니다.
- 포스트모템 문서 작성의 주 담당은 장애 대응 당시 지휘자였던 사람이 맡습니다.
- 지휘자가 작성을 온전히 다 하는 것은 아니고, 다른 사람에게도 도움을 받을 수 있습니다.
- 그러나 작성 진행 상황을 체크하고 잘 작성될 수 있도록 drive하는 것은 지휘자의 역할입니다.
- 기록가의 기록을 잘 참고하고, 슬랙 히스토리와 대조하여 보충할 내용을 추가합니다.
- 당시 시스템의 상황을 잘 알 수 있도록 대시보드도 캡처해옵니다.
- 효율적인 포스트모템을 위해 논의가 필요한 내용, 대응 과정을 미리 갈무리 해둡니다.
-
포스트모템 미팅
- 가까운 업무일에 포스트모템 미팅을 진행합니다. 진행 시에는 아래와 같은 항목들을 고민합니다.
- 장애 대응 팀 뿐 아니라 관련된 구성원이 있다면 모두 소집합니다. 미팅에 초대받지 못하였더라도 관심있는 구성원들이 참여할 수 있도록 미팅 링크를 미팅 시작 시간에 공유합니다.
- 장애 대응 과정에 대해 리뷰하고 놓친 것은 없는지 공유합니다.
- 앞으로 같은 장애를 겪지 않도록 액션 아이템을 정리하고 계획을 수립하여 실행합니다. 근본적인 문제 파악에 대해서는 5 Whys 같은 좋은 방법들이 있으니 참고합니다.
- 미팅이 끝나면 포스트모템 문서 형태로 정리하여 공유합니다.
⚠️ 포스트모텀 미팅은 형식적인 자리여서는 안됩니다. 미팅이 끝나면 아래 질문에 답할 수 있도록 적극적으로 논의되어야 합니다.
오늘 미팅 이후, 같은 문제가 안 생긴다 / 마주했을 때 잘 대처할 수 있다는 자신감이 드나요?
- 가까운 업무일에 포스트모템 미팅을 진행합니다. 진행 시에는 아래와 같은 항목들을 고민합니다.
포스트모템 문서 양식
YYYY/MM/DD AAA로 인한 BBB 장애
[장애 대응의 목표] 장애 대응의 최우선 목표는 문제를 정상화하는 것입니다.
Summary
- 해당 장애를 요약합니다.
Impact
- 해당 장애로 발생한 영향을 기술합니다.
Root Causes
- 해당 장애가 발생한 근본적 원인을 기술합니다.
Trigger
- 해당 장애가 촉발된 직접적 원인을 기술합니다.
Resolution
- 해당 장애를 어떻게 대응하고 해결 하였는지 기술합니다.
Detection
- 해당 장애를 어떻게 감지 하였는지 기술합니다.
Timeline
- "[시간] 사건에 대한 기술"을 시간 순으로 기록합니다.
Discussion
포스트모템 미팅을 진행하며 서로를 비난해서는 안됩니다.
포스트모템 미팅을 마치면 아래 질문에 답할 수 있어야 합니다.
같은 문제가 생기지 않는다 / 마주했을 때 잘 대처할 수 있다는 자신감이 드나요?
- 포스트모템 미팅에서 논의할 만한 주제들을 미리 기록해두고, 미팅 내용을 속기합니다.
Lesson Learned
-
잘 된 일
- 이번 대응에서 잘 된 것을 기술합니다.
-
잘 안된 일
- 이번 대응에서 잘 되지 않은 것을 기술합니다.
-
운이 좋았던 일
- 이번 대응에서 운이 좋았던 것을 기술합니다.
Action Items
- 해당 장애를 위해 앞으로 개선해야 할 것을 구체적으로 기술합니다.
💁 앞으로 같은 문제가 생기지 않는다 / 마주했을 때 잘 대처할 수 있다는 자신감이 드나요?