안녕하세요. 우아한형제들에서 TPM(Technical Project Manager)을 맡고 있는 임성현 입니다. 이번 글을 통해 이제까지 시도했고 지금도 진행 중인 모의장애훈련을 소개하려 합니다. 일상적으로, 딱딱하게 진행 할 수도 있는 이 작업을 어떻게 회사의 문화를 녹여 진행했는지 설명 드리려 합니다.

이번 글은 모의장애훈련을 어떻게 진행할지 구체적으로 알고 싶은 분도 좋고, 우아한형제들은 어떻게 장애대응과 같은 프로세스를 조직에 스며들게 하는지 사례가 궁금한 분도 보시면 좋겠습니다. 특히 회사의 방향인 쉽고 재미있고 위트 있게 장애대응을 확산하는 과정을 지켜보시는 것도 흥미로우실 것 같습니다.

우아한형제들의 장애대응 프로세스가 궁금하신 분은 여기를 참조하세요.
그리고, 이 글은 2021년 11월 19일 공개된 우아콘의 영상과 같은 내용을 다루고 있습니다.

우아한형제들에서 모의장애훈련은?

우아한형제들에서 진행하는 모의장애훈련을 한 문장으로 요약한다면 임의로 장애를 발생시키고 그 장애대응을 체험하는 훈련을 의미합니다.

임의로 장애를 발생시킨다는 것은 실제 운영과 비슷한 환경에서 설계자가 준비한 장애를 발생시키는 것을 의미합니다. 실제와 유사한 베타환경에서 진행하는 이유는 실제 상황과의 차이를 최소화해서 좀 더 현실감 있는 훈련을 진행하기 위해서입니다.

그리고, 이 훈련에서 가장 중요한 역할자 중 하나인 설계자가 나옵니다. 상세한 역할자 소개는 조금 있다가 말씀드리겠습니다.

장애대응을 체험하는 훈련에 대해서는 좀 더 상세하게 설명드리겠는데요. 일반적으로, 장애가 발생하면 기존에 대응하는 사람들이 계속해서 대응하게 됩니다. 프로세스가 몸에 배어있고, 시스템과 업무에 대한 이해도가 높기 때문에 항상 똑같은 사람이 대응하게 되는데, 이렇게 되면 소수의 사람만 장애를 대응하게 되고, 개인에 대한 의존도가 높아집니다. 즉, 그 사람이 없으면 장애 복구가 어려워지게 됩니다.

또, 대부분의 플랫폼 서비스들과 같이 우아한형제들이 제공하는 서비스도 24시간 쉬지 않고 동작하는데 장애대응의 역할을 소수의 사람이 맡게 되면 담당자의 피로도가 높아지게 됩니다.

그리고, 장애 대응에 직접 참여하지 않은 사람들은 무력감을 느끼게 됩니다. 직접 경험하고 옆에서 관찰해 보니, 수많은 사용자들에게 불편함을 주는 장애 상황에서 자신이 어떠한 대응도 할 수 없었던 경험 한 분들은 팀이나 동료에게 도움을 줄 수 없었다는 무력감을 느끼고 있었습니다.

이 훈련을 통해서 주로 장애를 복구하는 엔지니어 외에도, 의사결정자, 기획자, 운영 담당자 등 모든 팀의 구성원들이 장애가 발생했을 때 어떤 역할을 맡을 수 있는지 체험을 통해 스스로의 자리를 찾아가고자 합니다.

등장인물, 역할 소개

등장인물에 대해 생소할 수 있어, 이 문서에 등장하는 인물과 역할에는 배경색을 입혀서 설명하겠습니다.

[전체 참가자]

먼저 모의장애훈련별로 전체 참여자는 설계자, 관찰자, 참가자, 진행자로 나눠볼 수 있습니다.

설계자는 장애 시나리오를 만들고 훈련이 시작하면 장애를 유발하는 팀의 리드 엔지니어입니다.

관찰자는 훈련의 전체 상황을 관찰하는 팀장이 맡습니다.

실제 장애가 발생하면 주로 대응을 맡는 분들이 설계자와 관찰자의 역할을 맡습니다.

그리고 설계자와 관찰자를 뺀 다른 팀원들이 모의장애훈련의 참가자입니다. 이분들이 베타 환경에서 발생한 장애를 복구하고 유관부서에 전파하는 역할들을 맡게 됩니다.

진행자는 모의장애훈련을 기획하고 실시하고 회고를 진행하며 마무리 짓는 역할을 맡고 있습니다.

[주요 유관부서]

주요 유관부서에는 문제가 발생하면 고객으로부터 문의를 받아 개발팀에 확인하고 안내하는 고객센터, 중요 장애가 발생하면 모이는 임시기구이자 고객케어와 전사적 대응방안을 결정하는 비상대책위원회가 있습니다. 모의장애훈련시에는 진행자가 대역을 맡아 진행합니다.

왜 모의장애훈련을 진행하나요?

모의장애훈련을 진행하는 첫 번째 이유는 ISMS 인증기준을 위한 활동으로 규정을 준수하기 위해서입니다.

ISMS 인증기준에 따르면 모의훈련계획을 수립하고 이에 따라 연 1회 이상 주기적으로 훈련을 실시하고 기록에 남겨야 합니다.

두 번째 이유는 안정적인 서비스 제공을 위해서 입니다.(순서는 두 번째이지만 더 진지하게 바라보게 되는 이유 입니다.)

우아한형제들에서 서비스 장애가 발생이 되면 고객센터, 비상대책위원회 등 유관부서의 협업을 통해 빠르게 해결합니다. 그래서 장애를 발견한 개발팀에서는 장애를 탐지하면 원인 파악과 복구를 빠르게 진행하면서 동시에 유관부서에 정확하고 빠르게 알려주어야 합니다.

사실 하나만 제대로 하기도 어렵습니다. 하지만 이 모든 것을 동시에 빠르게 진행해야 합니다. 그렇기 때문에 팀 내에서도 역할분담이 필요하고 누구든지 그 역할자가 될 수 있다는 생각으로 모두가 숙달되어야 합니다. 장애가 발생하면 항상 대응하는 소수의 인원이 없더라도 안정적으로 대응해야 합니다. 그래서 모의장애훈련을 통해 장애를 대응하는 방법을 팀 안의 모든 구성원분들이 알아야만 합니다.

왜 이 방식으로 진행하게 되었는지?

처음부터 이런 방식으로 진행한 것은 아닙니다. 2019년까지는 정해진 시나리오를 스크립트로 만들고 참여하는 소수의 인원에게 미리 제공하고 그 절차에 따라 장애대응 훈련을 진행했습니다.

스크립트로 진행하다 보니 기술적인 대응 없이 전파를 중심으로 진행했습니다. 하지만 이 경우 장애를 대응할 때 소수에 의존하는 문제를 해결할 수 없었습니다. ‘이 훈련에 참여한 구성원 이외에는 내가 할 수 있을까?’ 하는 부담을 계속 가지고 있습니다. ‘장애대응 절차가 변경되었을 때에 그 절차에 따라 유관부서 호흡이 척척 맞으면서 진행할 수 있을까?’에도 확신이 없습니다.

결정적으로 2020년 상반기 장애대응 프로세스를 개선하면서 설문한 결과 문서를 보고 이해는 하지만, 실제 장애가 나면 내가 무슨 역할을 맡아 어떻게 대응해야할지 잘 모르겠다 는 의견이 다수 접수되었습니다.

그래서 경험을 통해 학습할 수 있도록 모의장애훈련을 개편 해서 진행 하게 되었습니다.

첫 번째 조직변화에도 안정성을 확보하기 위해서는 조직개편, 새로운 팀 리더가 선발되고 신규입사자가 합류하더라도 안정적으로 장애대응을 할 수 있어야 함을 의미합니다. 또한, 최근 선물하기나 배민쇼핑라이브 등 신규 서비스가 계속 오픈하는데 그때에도 최대한 빠르게 안정적으로 서비스를 제공할 수 있어야 하고 1년에 한 번이 아니라 개발팀에서 원할 때에 바로 진행해서 필요를 채울 수 있도록 방향을 잡았습니다.

두 번째 체험을 통한 체득의 의미는 다음과 같습니다. 장애대응 프로세스 문서를 읽어보는 단순한 학습이나 전체 교육 등 수동적인 방법에서 벗어나 장애를 대응해 보지 못한 팀원에게 실제 발생했던 장애 상황을 다시 만들어서 체험하도록 하고, 가상의 문제를 함께 해결하면서 이런 때에는 내가 어떻게 행동해야 하는지 스스로 적용해 보는 체험을 통해 앞으로 발생할 수 있는 장애 상황에 어떻게 대응해야 할지 프로세스를 습득하는 것입니다.

세 번째 누구라도 주저 않고 역할에 따라 행동하는 것에 대한 설명을 드리면 정한 장애대응의 기본 원칙은 장애를 처음 발견한 누구라도 장애를 전파해야 합니다. 이 원칙을 지키려면 누구라도 전파할 수 있어야 하는데 앞에서 말씀드린 설문과 인터뷰를 통해 수집된 점은 실제 장애 상황에서 장애대응 절차에 따라 대응하는 것이 처음에는 다들 부담스럽다는 것 입니다. 그래서 실제와 아주 유사한 장애를 만들고 이분들이 장애를 복구하며 전파를 체험하는 첫 상황을 훈련으로 만들어본 것입니다.

모의장애훈련 진행과정

이제는 모의장애훈련 진행과정을 말씀드리겠습니다.

전체 단계는 준비와 진행, 마무리단계로 나눠 진행했습니다.

각 단계의 목표를 이야기 드리면

준비단계는 모의장애훈련 상황이 실제 장애와 최대한 비슷하도록 구성했습니다.

두 번째 단계인 진행단계에서는 참여자들이 충분히 체험하고 고민하고 장애대응 절차에 따라 진행하는 경험을 제공하도록 준비했습니다.

그리고 마무리단계는 경험한 것이 잊어버리기 전, 궁금한 점을 해소하고 보완할 점을 찾아 개선할 수 있도록 준비했습니다.

각 단계에 대해서 좀 더 상세하게 풀어가보겠습니다.

Step1. 준비단계

1) 안내 및 접수

모의장애훈련의 시작은 안내 및 접수입니다. 모의장애훈련이라는 것이 무엇인지, 관심 있는 팀에서 누구나 신청할 수 있도록 안내메일을 보냅니다.

그런데, 단체메일을 받아보시게 되면, 이 메일에서 이야기하는 대상이 누구인지, 나도 해당이 되는지 알기 어렵지 않나요? 그래서 메일을 보낼 때에 가장 신경 쓴 부분은 우리 팀이 참여해도 될지, 도움이 될지 판단하는 기준이었습니다. 이 고민을 메일을 받는 쪽에서만 고민하는 것이 아니라 진행자 측에서도 그 고민을 덜어주고자 준비해서 제공했습니다.

이 메일을 보시면서 “우리 팀에 도움이 될까?” 아직 망설이는 분이 계실 수 있어, 저희가 생각한 모의장애훈련이 도움 되실 상황을 정리해 보았습니다.

• 우리 팀은 최근에 만들어져서 장애를 직접 체험해 본 경험이 없어요.
• 팀의 절반 이상이 새로 오신 분들이거나 기존 장애대응을 하셨던 분들이 다른 팀으로 옮겨, 우리 팀원들이 장애대응 절차를 경험해 보고 싶어요.
• 팀장/실장님등 조직장이 변경되어 장애상황과 이에 따른 의사결정에 대한 경험이 부족해요.
• 최근 경험한 장애 대응에서 장애를 탐지한 뒤 전파를 좀 더 잘했으면 아쉬움이 있었어요.
• 지난번 모의장애훈련에서 경험한 케이스 이외에도 중요하게 생각하는 시나리오를 추가적으로 검증해 보고 싶어요.

이 메일을 보내면 얼마나 회신이 올까요? 사실 처음에는 잘 오지 않습니다.

다른 팀에서 해보고 좋더라 하는 이야기를 전해 듣거나, 실장님들이 다른 사례를 보고 우리도 진행하면 좋겠다 하고 이야기가 시작되면서 조금씩 참여팀이 늘어났습니다. 어떤 분이 요청하시는지 파악해 보니, 대부분 팀장님 또는 그 팀의 기술리더분이 신청하는 경우가 많았습니다.

스스로 생각하시기에도 팀 내에서 자신 말고 다른 분들도 장애를 대응할 수 있는 준비가 필요하다고 생각하신 것 같습니다. 대부분의 경우 연락을 주시면서 어떤 목적과 방향으로 진행하면 좋을지 함께 말씀해 주십니다. 상세 논의는 다음 과정인 사전미팅 때 이야기하게 됩니다. 접수단계에는 사전미팅의 시간약속과 참여자만 잡고 마무리합니다.

2) 사전미팅

사전미팅은 보통 접수한 그 주간에 진행하게 됩니다. 다들 바쁘시다 보니, 소요시간은 15분 내외로 짧게 진행합니다. 하지만, 그 팀의 모의장애훈련 방향을 잡게 되는 정말 정말 중요한 자리입니다.

사전미팅에는 팀장님과 리드 엔지니어가 꼭 참여하도록 하고, 진행자인 제가 설명을 드립니다. 왜 이런 방향으로 진행하게 되는지, 전체 참여자별로 각기 어떤 역할을 맡는지 설명합니다. 항상 장애상황에 직접 대응하셨던 두 분은 이번 훈련에서는 한 발짝 떨어진 관찰하는 역할을 맡아야 한다고 말씀드립니다.

대부분의 경우 두 분 다 모두 즐거워하십니다.

이 미팅에서 모두 확정하기 어려운 경우도 많은데, 대략의 목표일에 적어도 3일 전, 가급적 1주 전에 구체적 시나리오와 함께 정리를 부탁드립니다. 이때에 별도로 위키 페이지를 비공개로 만들어서 논의한 내용부터 차근차근 작성해놓습니다. 이 문서는 마무리 단계인 회고 때에 공개해서 참여했던 모든 분들이 볼 수 있도록 합니다.

3) 시나리오 설계

진행하다 보니 여러 개의 시나리오 후보를 만들고 그중에서 선별해서 진행하는 방향으로 발전했습니다.

이 시나리오 예시는 장애 시나리오가 되는 후보군 목록을 세 개 잡고, 그중에서 첫 번째와 세 번째가 복합적으로 발생하는 장애로 준비한 것입니다. 인프라 문제를 해결한다 하더라도 사용자의 실수에 따라 남아있는 문제를 업무적으로도 해결해야만 모든 장애를 복구할 수 있습니다.

또 하나의 예시는 연쇄 장애입니다. 1차 운영이슈는 참가자와 그날의 상황에 따라 상/중/하를 준비했고, 이 문제를 만약 해결했다 하더라도 모니터링 단계에서 다시 2차의 장애가 발생하게 만든 것입니다.

현실에서도 장애가 발생하고 안정화 단계에서의 작은 문제가 다시 장애 상황으로 만드는 경우가 있어, 끝까지 긴장을 늦추지 않으면 좋겠다는 의도를 함께 담았습니다.

4) 환경준비

다음은 환경 준비입니다. 이때에는 설계자가 신나게 장애를 숨깁니다. 쉽게 찾을 수 없도록 기록에 남기지 않고 인프라 세팅을 변경할 준비를 하거나 코드상의 이슈라면 몇 주 전에 베타환경을 위한 버그를 심어 놓습니다. 진행자는 실제 환경과 유사한 커뮤니케이션과 모니터링, 알람 채널들을 만듭니다. 마지막으로 이 작업의 마무리는 이런 장애가 발생하면 어떤 절차로 진행하면 좋을지 설계자의 의도와 방향을 위키 문서에 기록해둡니다.

5) 참여자 사전안내

준비단계의 마지막입니다. 앞에서 결정이 된 모든 참여자분들께 하루 전 메일로 안내드립니다. 이 메일을 통해 목적과 방향, 규칙을 안내드립니다.

참가자분들이 문서상으로 진행하는 것인지 실제로 얼마나 하는지 혼란스러워하셔서, 이 장애를 실제로 완전히 복구하면서 전파하는 훈련이라는 것을 이야기해 줍니다. 또한 이 과정에서 평가하는 것이 아니라 개선할 점을 함께 찾는 것이라는 것을 강조합니다. 그리고, 장애대응하는 절차를 설명하는 문서를 제공합니다. 이때에도 팀 내부에는 언제 진행하는지 구체적 시간과 시나리오는 비밀로 합니다.

물론 권고하지는 않았지만, 어떤 팀에서는 새로 합류한 분들이 너무 많아 대 혼란이 발생할 수도 있다고 하셔서, 전날에 시험문제를 예습하기도 했습니다. 사실, 이렇게 준비하셨는데도 모의훈련시 당황하는 것은 동일합니다.

여기까지가 준비단계입니다.

다시 요약 드리면, 각 팀의 상황에 따라 참여하는데, 준비기간 동안에 진행자와 설계자는 가장 현실감 높은 시나리오와 환경을 만듭니다. 모의장애훈련 하루 전날에는 전체 참여자에게 장애훈련을 진행한다는 안내와 참조할 자료를 제공합니다.

Step 2. 진행단계

자, 드디어 모의장애훈련 당일 입니다.

1) 훈련시작

훈련의 시작은 베타 환경에 장애를 발생시키는 것으로부터 시작됩니다. 그전에 설계자와 관찰자, 진행자가 함께 별도의 화상채팅방을 만듭니다. 모두가 이번 모의장애훈련의 대응에 한 발짝 떨어져 있게 됩니다. 모든 준비가 다 끝났는지 다시 한번 확인하고 설계자가 장애를 발생시킵니다.

베타 시스템에서 알람을 받고 아는 경우도 있지만, 이게 힘든 경우에는 상담센터를 통해 문의를 접수하게 됩니다. 진행자가 고객센터의 상담원 대역으로 참여해서 훈련을 위한 채널을 통해 장애 문의가 접수되었다고 알립니다.

필요하다면 CTO로 변장하여 놓친 부분이나 현실감을 높일 질문을 물어봅니다.

2) 대응과 전파

이제 장애상황이 본격화됩니다. 모의훈련이지만 이때에는 참가자가 실제 상황과 차이가 거의 없도록 지금까지 준비한 모든 장치를 동원합니다. 알람과 고객센터 문의에 따라 장애가 발생된 것을 파악하고 현상을 물어보고 모니터링하면서 원인과 해소 방안을 찾습니다. 그런데, 이 훈련이 장애를 대응하는 모든 방면의 훈련이라는 것을 다시 한번 기억하시면 좋겠습니다. 기술적인 문제를 실제로 해결하는 동시에 유관부서에 전파해야 합니다.

이때에는 최초 발견한 누구라도 장애공지를 할 수 있습니다. 장애를 분석하는 엔지니어 말고 팀의 기획자 또는 입사한지 얼마 안 되는 분도 역할을 맡게 됩니다. 그리고 고객센터에서 들어오는 문의를 받아서 복구하는 팀 내에서도 협업을 해야 합니다. 내부적으로는 장애를 대응하면서 팀원 간 원활하게 소통할 수 있어야 하고, 외부와는 계속 현상을 파악하고 상황을 공유하고 들어오는 문의사항을 대응해야 합니다.

이 훈련의 모든 준비는 이때에 얼마나 현실감 있게 진행하고 그 과정을 통해 참가자들이 몰입감 있게 체험을 잘 하는 것에 집중되어 있습니다.

설계자와 관찰자는 이때 직접 개입하지 않도록 요청합니다. 사실 많이 답답해합니다. 하지만, 진행자와 함께 별도의 채널에서 계속 이야기하고 있습니다. 이렇게 해서 기존 경험이 거의 없는 팀원들이 스스로의 힘으로 문제를 해결할 수 있게 합니다.

하나 더 이야기 드릴 것은 이때에 유관부서가 어떤 관점에서 장애를 바라보는지 좀 더 알 수 있도록 합니다. 고객센터는 장애가 언제 끝나는지와 고객의 불만 해소에 더 많이 관심을 가지고, 비상대책위원회에서는 장애의 범위와 영향받는 고객의 규모를 알고 싶어 합니다.

그래서 이런 질문을 받는구나, 동시에 전파할 때에 꼭 필요한 요소는 이런 것이구나 하고 체험을 통해 체득할 수 있도록 합니다.

3) 해소공지

실제 장애와 똑같이 손에 땀이 나고 긴장이 됩니다. 장애가 해소되면 안정화 모니터링을 진행합니다. 이때 1시간 30분 제한을 만든 이유는 그 이상이 되면 전체 참여자들의 집중력이 급히 떨어지고 지치기 때문입니다. 장애를 탐지하는 것 만큼이나 지금 정상인지 아닌지를 알 수 있는 것도 중요하기 때문에 이 과정에서도 스스로 잘 해결하고 있는지 관찰합니다.

특히 비즈니스적인 장애가 복구될 때 필요한 업무적 절차가 있기 때문에 이를 잘 지키고 유관부서에 전파하고 필요한 의사결정을 받는 훈련을 포함해서 진행하게 됩니다. 장애가 모두 해소되어 정상화되었다고 판단하면 장애 해소공지를 포맷에 맞춰 공지하도록 합니다. 그리고 장애 해소 이후에 영향받은 고객을 추출해서 사후 케어를 준비합니다.

하지만, 1시간 30분보다 너무 오래 걸릴 것 같다는 경우나 너무 짧게 끝날 것 같은 경우는 어떻게 해야 할까요?

그래서 준비했습니다.

3-1) 전지적 시점의 지원

너무 오래 진행하게 되면 훈련의 목적이 흐려지고 지치게 되는 경우를 보게 되었습니다. 그래서 한 시간 십분이 지나면 모의장애를 총괄하는 채널에서 이야기하고 필요에 따라 살짝씩 개입하게 됩니다.

한 번은 DB연결정보를 수정해야 하는 상황에서 잘못된 판단으로 모든 DB가 재부팅한 경우도 있는데, 실제 장애상황이라면 정말 생각하고 싶지 않은 상황이죠. 이런 때에 맥락을 끊지 않으며 유관부서 대역을 맡아서 힌트를 제공합니다.

이 훈련의 목적이 다시 한번 말씀드리지만 팀 안에서와 팀 바깥과의 유기적인 장애 대응이고 부족한 점은 항상 발생할 수 있으니 그 부분은 회고를 위해 기록하고 추후 개선할 점으로 남깁니다.

3-2) 연쇄 장애로 시간 연장

만약 너무 빨리 끝나면, 좋은 것 아닌가요? 그런데 준비한 경험을 충분한 시간 동안 겪지 않으면 체험을 통한 학습의 효과가 떨어질 수 있어, 시간을 조절합니다.

예를 들어, 장애가 발생하고 바로 해소가 되면 영향받은 고객이 없고 유관부서의 질문을 충분히 받을 수 없게 되는데 실제 상황이라면 정말 다행이겠지만, 훈련 때에는 다 충분히 체험하는 것이 좋겠죠. 그래서 빨리 끝나면 장애해소 이후에 다시 장애를 발생시킵니다.

너무 가혹해 보이기도 합니다만. 장애에 취약한 때 중 하나는 장애복구가 완료되어 해소된 직후입니다. 실제 상황에서도 불씨가 다시 살아나 장애가 연쇄적으로 진행되는 경우도 있으니, 이를 감안해서 두세 개의 장애를 이어 진행하게 됩니다. 마찬가지로 너무 오래 진행되지 않도록 난이도를 조절하며 진행합니다.

Step 3. 마무리단계

모든 장애가 해소되는 것으로 훈련이 끝나지 않습니다. 부족한 것이 무엇인지 함께 논의하고 개선하는 마무리단계가 있습니다.

1) 회고

회고는 모의장애를 해소 공지하고 진행자가 훈련 종료를 선언하면 바로 그 즉시 진행합니다. 회고의 전체 소요시간은 30분 내외로 진행합니다.

보통의 경우 모의장애를 지휘하던 화상채팅방에 초대장을 보내서 참여하게 하고, 비공개였던 위키 페이지를 오픈합니다. 그리고 위키페이지 하단에 있는 모의장애 진행회고에 전체 참여자별로 충분한 시간을 드리면서 기록하게 합니다. 사실, 설계자와 관찰자분께는 훈련 도중에 회고를 미리 작성해 주시길 권고 드립니다. 워낙 바쁘기도 하고, 전체적으로 어떤 일이 있었는지 가장 잘 기록하실 분이라 나중에 공유할 때 내용을 풍성하게 해줍니다.

이때 좋았던 점, 아쉬운 점과 개선사항, 그리고 앞으로 우리가 어떻게 하면 더 잘할 수 있을지 각자 생각을 기록하도록 안내합니다. 마지막으로 이 훈련 전과 후의 대응수준을 각자 5점 척도로 기록하도록 요청합니다.

모두 작성을 끝내면 진행자가 다시 한번 이 훈련의 목적을 이야기합니다. 물론 하루 전날 메일에 남겨놓은 이야기이지만, 다시 한번 이 훈련은 잘 하는지를 평가하기보다는 어떤 부분이 부족한지 팀 안에서 같이 이야기하고 보완하는 목적을 가진다고 다시한번 이야기하고 시작합니다.

그리고 설계자가 이번 모의장애 시나리오와 자신이 생각한 최선의 해결방법을 설명하고 참여한 모두가 각자 작성한 내용을 발표합니다. 이때에 궁금한 점은 따로 모아 진행자가 설명해 줍니다. 대부분 이런 경우 어떻게 해야 하는지 경험한 상황에 따라 물어보는 경우가 많습니다.

참가자가 먼저 이야기하고 그 뒤에 미리 준비하셨던 설계자와 관찰자, 진행자의 순서로 진행해서 모두의 이야기가 묻히지 않도록 배려합니다. 그 뒤에 별도의 설문 링크를 드려, 장애대응 프로세스와 훈련의 피드백을 받습니다.

2) 후속조치

모든 훈련은 끝났지만, 여기에서 발견한 이슈는 별도의 티켓으로 관리하고 진행합니다. 예를 들어 팀 내의 가이드 문서를 업데이트하거나 장애가 발생하면 알려야 할 담당자가 업데이트되어야 한다면 그 작업도 함께 진행했습니다. 또 알람이 부족해서 추가되어야 하는 곳, 알람의 주기 변경, 고객에게 보이는 오류 메시지를 좀 더 다듬는 작업, 시스템 설정 표준값 변경도 모의장애훈련에서 발견한 조치사항으로 이것도 진행했습니다.

장애대응 프로세스에서도 개선할 점이 보이면 이를 백로그에 남기고 개선합니다. 예를 들어, 장애가 발생할 때 전파할 대상 채널의 개수를 줄인 것도 이 훈련에서 받은 피드백이 시작점이었습니다.

모의장애훈련 평가

1) 훈련소감 – 참가자

첫째는 참가자분들이 쓴 내용입니다.

이보다 훨씬 더 많은 의견이 있지만 대표되는 몇 개를 정리해 본다면 다음과 같습니다.

2) 훈련소감 – 설계자와 관찰자

이번엔 설계자와 관찰자의 피드백도 일부 모아봤습니다.

그중에 흥미로운 부분은

등이 있었습니다.

3) 훈련소감 – 리더

2020년도의 모의장애훈련을 끝내고 전사 대상으로 진행 결과를 공유하는 메일을 보냈습니다.

그때 대표이신 범준님이 전체 회신하며 보내신 내용입니다.

올해 초에는 좀 더 확대해서 장애가 났을 때 의사결정 체계인 비상대책위원회의 고객 대응을 중심으로 모의장애훈련을 진행했습니다.

기존 모의장애훈련의 틀은 그대로 가져가서 진행했고, 이후에 그 시나리오와 유사한 장애가 발생했을 때에 COO이신 국환님이 장애조치 후 주신 의견입니다.

모의장애훈련 수확

긴 호흡을 따라오시느라 고생하셨습니다. 모의장애훈련을 통해 어떤 수확을 얻었는지 정리해 보겠습니다.

1) 장애대응 프로세스 이해도 상승

먼저 장애대응 프로세스의 이해도가 상승했습니다. 전체 참여자들을 대상으로 설문한 결과 5점 기준으로 2.0에서 3.7로 85% 상승했습니다.

2) 장애대응 인원 확대

그다음 장애가 발생할 때 대응할 수 있는 인원이 확대되었습니다. 작년에는 23차수 166명이 참여했으며 이는 배달의민족과 B마트 서비스부문의 모든 개발팀이 적어도 1회 진행한 것입니다. 올해는 13차수 165명이 모의장애훈련에 참여했고 계속 진행 중입니다.

3) 시스템의 취약점 발굴

그다음으로는 시스템의 취약점을 발굴한 점입니다. 훈련을 통해 특정 상황에서 발생하는 문제를 발견하는 경우도 있었고, 알람과 모니터링을 개선할 부분, 만화경의 경우 장애가 발생하면 담당 PD에게도 알려주어야 하는 절차가 개선할 점으로 발굴되어 조치가 되었습니다.

4) 장애대응 문화 전파

마지막으로 회사의 개발 문화인 개인이나 팀을 비난하지 않고 개선점을 함께 논의하는 문화를 전파할 수 있었습니다. 회고 때에도 개인이나 팀을 비난하지 않고 함께 개선할 점을 이야기합니다.

모의장애훈련 계속되는 고민

하지만 우리가 진행하는 방법에 보완할 점이 없다고 생각하지 않습니다.

물론 처음 시작은 체험을 통해 학습하는 것이지만, 정말 이 훈련을 통해 고객서비스가 개선되었는가? 하는 질문을 던져보면 이는 계속되는 고민입니다.

그래서 서비스 안전성 지표와 연계해서 활용하는 방안 등을 계속 보완 중입니다.

나도 해보고싶다! 하시는 분들을 위한 소소한 팁

드린 이야기가 참 많았죠? 이제는 지금까지 읽어주신 분들을 위한 소소한 팁입니다. 이런 모의장애훈련을 해보고 싶은 분들을 위한 경험에서 우러난 팁입니다.

1) 시작 전에 이 훈련의 목표와 성과를 정하고 진행하시면 좋습니다.

처음에는 작게 시작하지만, 여러 번 더 많은 분들이 참가하다 보면 본질이 흐려질 수 있습니다. 그래서 이 훈련의 목표와 성과를 결정하고 진행하시면 더 좋겠습니다.

2) 역할분담과 협업에 집중하신다면 좋을 것 같습니다.

참가자들이 복구 작업에 매몰되어 전파가 안되거나 전파만 신경 쓰다가 원인 파악과 복구가 지연되지 않도록 집중하시는 것이 좋겠습니다. 모든 준비와 장치들은 이 두 가지. 역할분담과 협업을 좀 더 현실감이 있게 진행하는 데 도움이 되도록 살피시면 좋을 것 같습니다.

3) 훈련 범위를 제한하시면 좋겠습니다.

참가자들이 집중할 수 있고, 방관자가 되지 않도록 하는 효과를 가져옵니다. 적정 인원은 대여섯 명이고 그 이상은 두 번으로 나눠서 진행하거나 관찰자로 참여하는 것도 좋습니다.

4) 설계자의 역할이 중요합니다.

무엇보다도 꼭 강조해드리고 싶은 부분은 설계자의 역할입니다. 설계자는 시스템을 가장 잘 이해하고 장애를 가장 많이 대응해 본 리드 엔지니어가 맡습니다. 이 분이 집중해서 더 리얼한 환경을 만들 수 있도록, 그리고 이 훈련의 특징과 목적을 잘 이해하고 준비하도록 진행자가 계속 도움을 주는 것이 좋습니다.

5) 진행을 맡으시는 분은 평소에 실제 장애를 꾸준히 참여하고 관찰하시기 바랍니다.

그러면서 앞으로 어떤 방향으로 모의장애훈련을 진행하면 좋을지 힌트를 얻고, 고객센터나 마케팅의 대역을 맡을 때에 어떤 말투로 질문을 하는지 등을 잘 살펴보시면 도움이 됩니다. 우리가 자주 놓치는 부분도 준비해놓으면 효과적인 훈련에 도움이 됩니다.

6) 설계자, 관찰자가 피드백할 때 주의할 점이 있습니다.

고참 개발자, 팀장님이다 보니 잔소리가 많아집니다. 그래서 훈련 도중에는 제3자 관점에서 참여하고 중간중간에 계속 장/단점을 기록하시도록 안내하세요. 단, 장점과 단점을 1:1의 비율로 작성하시도록 안내하면 좋습니다.

7) 모의장애훈련에 이어서 바로 회고를 진행합니다.

나중에 다시 만나기 힘들고 잊어버립니다. 참여자가 궁금한 점을 남기지 않고 바로 해소해 주기 위해서도 좋고, 실수한 점과 개선할 점의 관심 집중을 위해서도 바로 진행하시길 권고합니다.

8) 참여팀 확산 방안은

이렇게 준비를 다 했는데, 참여팀이 적으면, 흥행이 안되면 참 아쉽잖아요. 그래도 꾸준하게 체험한 팀에서 좋았다고 이야기할 수 있도록, 그리고 부담을 줄이도록 예제와 템플릿을 확보해주시면 좋습니다. 체험한 팀이 “좋았다” 할 수 있도록 환경을 잘 준비합니다.

9) 우리 조직에 적용해볼까 고려 중이라면

이런 팁을 다 적용해서 진행하기 전, 다시 한번 우리 조직에 적용해 볼까? 하시는 분은 정말 우리 조직에 이 훈련이 필요한가? 하는 질문을 해보고 그 확신을 가지고 진행하시면 좋겠습니다.

10) 모의장애훈련을 진행하기로 했다면 첫 단계는

훈련을 진행하기로 결정했으면 훌륭한 첫 번째 팀을 만나시기 바랍니다. 템플릿을 만들고 방향을 잡을 때 큰 도움이 됩니다. 이 자리를 통해 저의 첫 번째 참여 팀이었던 공통시스템개발팀에 깊이 감사를 드립니다.

11) 모의장애훈련을 계속 잘 진행하려면

일회성에서 벗어나 계속 잘 진행하기 위해서 드리는 팁은 시상과 감사입니다. 우리는

• 훈련전 숙지도와 훈련 후 숙지도 차이가 큰 팀
• 많은 사람들이 효율적으로 참여한 팀
• 복잡/현장감 높은 시나리오로“모의훈련이라 다행”이란 팀
• 그리고 시즌마다 모든 설계자들에게

선물하기로 감사를 표현했습니다.

향후 우리는

앞으로 신규 서비스, 새로운 고객 케어 프로세스, 새로운 형태의 장애를 만날 때마다 마지막 단계에 필수적으로 진행해서 확인해 볼 계획입니다 그리고 이 훈련이 어떤 것에 도움을 주는지 파악하는 지표와 장애대응 훈련과 장애대응 프로세스를 간소화할 수 있도록 자동화를 준비 중입니다.

그리고, 입사를 권합니다. 도전할 멋진 일들이 아직 많이 있습니다. 함께 도전해서 해결해가고 싶습니다.

마지막 인사드리기 전, 이 글의 제목을 보셨나요? 우리는 모의장애훈련에 진심입니다. – part 1입니다. 향후 방안과 지표와 연계하는 도전을 진행하고, 또 지금보다 더 나은 방법을 찾아서 계속 노력하고 그 뒤에 후속 글로 다시 이야기 드리도록 노력하겠습니다.

저는 우아한형제들의 TPM인 임성현이었습니다.