안녕하세요. 우아한형제들 시스템신뢰성개발팀 박주희입니다.
얼마 전에 시스템신뢰성개발팀에 대해서 소개한 적이 있습니다. 그때, 팀 소개에서 시스템신뢰성개발팀에서 가장 중요한 업무 중 하나는 장애 대응이라고 설명했는데, 오늘은 이 장애 대응에 대해서 조금 더 자세하게 설명해보려고 합니다.

우아한형제들에게 장애란?

많은 서비스회사가 장애에 민감하게 반응하고 있습니다.
장애로 인해 금전적 손해가 발생하기 때문이기도 하지만, 그보다 더 큰 이유는 장애로 인한 고객 불편이 장기적으로 서비스의 신뢰를 하락시킬 수 있기 때문입니다. 장애는 서비스의 성장, 서비스의 변화 등 다양한 과정 중에서 발생하는 성장통 중의 하나이기 때문에 장애가 발생하는 것을 원천적으로 차단할 방법은 없습니다. 하지만, 장애에 대응하는 과정을 통해서 서비스의 신뢰는 지킬 수 있습니다. 장애가 발생하더라도 영향 범위를 최소화하고, 빠르게 복구하며, 고객에게 적절한 정보를 제공하고, 같은 불편을 겪지 않도록 조처를 하는 모든 과정이 고객의 신뢰를 지키는 방법입니다.

우아한형제들이 장애 상황에서 고객의 신뢰를 지키기 위해서 어떤 활동을 하는지 지금부터 자세히 살펴보겠습니다.

장애 탐지

장애는 시스템 알람으로 탐지할 수도 있고, 고객 센터로 인입되는 문의를 통해서도 인지할 수 있습니다.

시스템 알람을 통한 탐지

모든 시스템에는 이상 현상을 감지할 수 있는 모니터링 시스템이 구축되어 있으며, 이 모니터링 시스템에서 탐지한 이상 현상을 즉각적으로 인지하기 위해서 Slack(슬랙)으로 알람을 발송하고 있습니다. 그 중에서도 특히 주의를 기울여야 하는 알람의 경우 담당자에게 즉시 연락이 갈 수 있도록 온콜도 운영하고 있습니다.
성격에 맞는 알람 채널을 다양하게 구성해서 운영하고 있는데, 각 시스템 단위의 알람뿐 아니라, 비즈니스 지표를 기준으로 한 알람과 외부 연동 시스템의 이상을 확인할 수 있는 알람 등 다양한 지표를 참고로 서비스 이상 징후를 탐지하고 있습니다.

• 시스템 지표: CPU, Memory, latency, 5xx error count 등
• 비즈니스 지표: 가게 상세 진입률, 주문 추이 등
• 외부 연동 시스템 지표: 연동시스템 주문 전달 실패, 프랜차이즈 시스템 오류 등

고객 센터로 인입되는 문의

대부분 이슈를 시스템 알람을 통해서 인지하고 있지만, 사용 빈도가 극도로 낮은 메뉴에 오류가 발생하거나 사용자 기기 기종 혹은 OS 버전에 따른 제한적인 오류가 발생하는 케이스와 같이 특수한 경우에는 시스템으로 탐지하기 어렵습니다. 이런 오류들은 주로 고객 센터를 통해서 인지하게 됩니다. 고객 센터로 인입되는 이슈 중, 시스템 이상으로 판단되거나 고객 센터에서 자체적으로 처리하지 못하는 문제는 서비스 담당자들이 함께 커뮤니케이션하고 있는 채널로 전달됩니다. 각 팀에서는 고객센터에서 전달된 이슈를 확인하고, 장애로 확인되는 경우 장애 대응을 시작하게 됩니다. (장애가 아닌 경우도 종종 있습니다.)
몇 년 전까지는 monolithic 구조로 인해서 모든 엔지니어가 이 채널의 알람에도 민감하게 반응했지만, 현재는 MSA 구조에 맞게 문제가 있는 도메인을 호출하면 (ex, 주문, 리뷰, 결제 등) 각 담당자에게 온콜이 가도록 분리 운영하고 있습니다.

장애 공지

개발 조직에서는 장애를 감지한 순간, 즉각적으로 장애를 공지하고 있습니다.

장애 공지는 장애 발생 시간, 영향 범위, 장애 조치 채널, 내부적으로 정의한 장애 등급, 등 여러 정보를 포함하고 있습니다.
하지만, 최초로 장애 공지를 할 때는 확인된 최소의 정보만 가지고 빠르게 공지하도록 권고하고 있습니다. (초기에 모든 항목을 확인하고 기입 할 수 없고, 파악하는데 최소한 몇 분의 시간은 걸리기 때문입니다) 완벽한 정보가 아니더라도 일단 빠르게 장애 상황이 발생했다는 경보를 울리면 담당자들이 빠르게 대응을 준비할 수 있으므로 장애 공지는 화재경보기와 같은 역할을 한다고 볼 수 있습니다. 건물에서 화재경보기가 울리면 어디에서 불이 났는지 눈에 보이지 않아도 누군가는 119에 신고를 하고, 누군가는 소화기를 찾고, 누군가는 대피를 준비합니다. 이와 비슷하게 장애 공지가 올라오면 사내에서 누군가는 서버 증설을 준비하고, 누군가는 고객 전파를 준비하고, 누군가는 담당 시스템에 영향이 있는지 확인하게 됩니다. 이렇게 울려진 경보를 통해서 각 담당자가 각자의 역할을 확인하고 그 내용을 공유하기 위해서 장애 조치 채널 (논의 채널)로 몰려 들어옵니다. 개발자, 기획자, 인프라 엔지니어, SRE 조직은 물론이고, 대외 커뮤니케이션 담당자 및 주요 의사 결정권자들까지 모두 빠르게 채널에 합류합니다. 장애를 빠르게 해결하기 위한 수단과 방법을 모두 동원하기 위해서 장애 공지를 활용하고 있다고 볼 수 있습니다.

최근 발생한 장애 조치 채널에 합류한 멤버들의 리스트를 확인해보면 정말 다양한 팀에서 합류했다는 사실을 알 수 있습니다.
(이 외에도 100명이 넘는 인원이 참여하고 있습니다.)

장애 전파

장애를 해결하는 것만큼이나 장애 상황과 해결 방안을 잘 전파하는 것도 중요합니다.

배달의민족과 같은 플랫폼 서비스에 장애가 발생하면 다양한 이해관계자들이 영향을 받습니다. 이해관계자는 크게 외부 이해관계자와 내부 이해관계자로 나눌 수 있습니다. 외부 이해관계자는 가게를 운영하시는 사장님, 배달을 수행하는 라이더, 음식을 주문하는 사용자와 같은 고객뿐만 아니라, POS, 배달대행사, 프랜차이즈, PG사 등 다양한 연동 시스템을 담당하는 업체들도 모두 포함합니다. 내부 이해관계자는 장애에 대응하는 개발조직은 물론이고, 고객과의 접점에서 직접 응대하는 CS 조직, 대외 커뮤니케이션 조직, 사업 조직까지 많은 부서를 포괄하고 있습니다. 장애가 발생하면 앞서 나열한 모든 이해관계자에게 작든 크든 어떠한 영향을 주게 됩니다.
그렇기 때문에 (모든 장애에 해당하지는 않지만) 일부 대규모 장애의 경우 여러 채널로 문의가 들어오기도 합니다. 사용에 불편함을 느낀 사용자들과 장사에 영향을 받는 사장님들은 고객센터와 영업부서를 통해서 문의를 해오게 되고, 연동된 여러 시스템에서는 각 담당자에게 문의하게 됩니다. 이때, 정확한 정보가 전달되지 않는다면 여러 담당자가 혼란을 겪게 되고 때로는 외부로 잘못된 정보가 전달될 수도 있습니다. 이런 혼란을 방지하기 위해서 장애를 대응하는 조직에서는 정확한 정보를 전달하기 위해 많은 노력을 기울이고 있습니다.

장애 전파 방법에 대해서도 많은 고민과 시행착오를 거쳐 프로세스를 수립했는데, 핵심적인 두 가지를 살펴보겠습니다.

첫째, 장애 복구와 장애 전파를 분리 운영합니다.

앞서 이야기했듯이 장애 전파는 장애 복구만큼이나 중요하기 때문에 둘 다 놓칠 수 없지만, 양쪽 모두를 신경 쓰다 보면 하나도 제대로 되지 않을 때가 있습니다. (극한의 스트레스는 덤….)
그래서 장애 대응 시에 반드시 장애 복구와 장애 전파를 같은 사람이 하지 않도록 가이드하고 있습니다. 될 수 있으면 담당팀의 기획자 혹은 조직장이 전파할 수 있도록 지정하고, 상황이 여의치 않으면 SRE팀이 이를 지원하기도 합니다. 이러한 조치는 두 가지 이점이 있는데 첫 번째 이점은 엔지니어들이 장애 복구에 집중할 수 있다는 점이고, 두 번째 이점은 유관부서에서는 조금 더 서비스에 포커스 된 내용을 전달받을 수 있다는 것입니다.

장애 복구를 진행하고 있는 엔지니어가 장애 전파도 같이하게 되면 서비스의 영향도 보다는 시스템의 상태를 공유하는 경우가 많이 있습니다. 복구에 집중되어 있어서 장애 현상을 전달하기는 쉽지만, 장애 현상으로 인해서 서비스에 어느 정도의 영향이 있는지를 고려하기는 힘들기 때문입니다. 이 경우 정보 전달은 되었지만, 사용자 친화적인 정보가 아니므로 별도의 해석을 하거나, 거꾸로 다시 질문을 해야 하는 상황이 야기됩니다. 질문이 이어지게 되면 혼란은 가중되고 집중력은 떨어지게 되어 결과적으로 장애 복구 시간이 늘어나기도 합니다.

특정 서버의 스펙을 초과하는 트래픽이 들어와서 scale out을 해야 하는 경우로 예를 들어보겠습니다.

• 엔지니어 버전
  

  A 서버에 트래픽이 몰려 레이턴시가 높습니다. 스케일 아웃 진행 중이며 10분 정도 소요될 것으로 예상합니다.

• 기획자 버전
  

  사용자가 급증하여 A 서비스 이용이 원활하지 않습니다. 전체적인 접속 속도가 늦으며 간헐적으로 페이지 접근이 되지 않을 수 있습니다. 서버 증설 진행 중이며 10분 후에 정상화 될 예정입니다.

다소 극단적인 예라고 생각될 수 있지만, 실제 장애 상황에서 나타나는 패턴입니다. 엔지니어는 빠르게 현상에 대해 전달하는데 집중하고, 기획자나 조직장은 서비스 상태를 전달하는 데 집중하고 있습니다. 이런 정보를 전달받는 입장에서도 둘의 차이는 극명하게 나타납니다. 엔지니어 버전의 경우, (물론 엔지니어들은 한 번에 이해하지만) 외부로 커뮤니케이션을 해야 하는 유관부서에서는 어떻게 전달해야 할지 고민하는 시간이 늘어나거나 복구 작업 중인 담당자에게 다시 질문을 해야 하는 난감한 상황에 처하기도 합니다. 장애 담당 부서에서 전달하는 정보는 여러 내외부 관계자들에게 전달되기 때문에 정보를 전달받는 사람이 이해하기 쉽도록 전달해야 혼란을 줄일 수 있습니다.
이런 여러 가지 이유로 인해서 장애 대응과 장애 전파를 분리하게 되었습니다. 이 조치 후에 엔지니어들은 장애 복구에 집중할 수 있는 시간을 확보하여 더 정확하고 빠르게 서비스를 복구할 수 있게 되었고, 유관부서에서는 반복되는 질문 없이 각 부서의 역할에 집중해서 빠르게 대외 커뮤니케이션을 비롯한 여러 조치를 진행할 수 있게 되었습니다.

둘째, 고객이 알고 싶어하는 내용을 전파합니다.

사용자들이 알고 싶은 건 장애 현상이 나에게만 발생하는 것인지 아닌지, 언제 해소되는지, 잘못 결제된 내역이 있다면 그 내역이 언제 취소되는지와 같은 정보이며, 사장님들과 라이더들이 알고 싶은 것도 배달하지 못한 음식은 어떻게 하면 되는지, 언제쯤 서비스가 복구 되는지, 폐기해야 하는 음식에 대한 보상은 어떻게 받을 수 있는지 등과 같은 정보입니다.
즉, 현재 상태, 조치 예정 시간, 후속 대응 세 가지가 주요 이슈가 됩니다. 이를 위해서 담당 부서에서 전달해준 내용을 바탕으로 여러 커뮤니케이션 담당자들이 상황과 전달 대상에게 맞는 공지를 여러 수단을 통해서 제공하고 있습니다. 어떠한 현상으로 인해서 서비스에 문제가 있으며, 언제까지 복구할 예정이고, 후속조치는 어떻게 진행될지 이 3가지 핵심적인 정보를 전달함으로 인해서 고객의 혼란을 줄이고, 고객센터나 영업부서에 쏟아지는 문의도 줄일 수 있습니다. 앞서 이야기했듯이 장애 발생을 원천적으로 막을 수는 없지만, 고객에게 적절한 정보를 제공함으로써 서비스의 신뢰는 지킬 수 있습니다.

장애 복구

장애 공지 후에 장애 전파와 장애 복구가 동시에 진행됩니다.

장애 복구에서 중요한 것은 서비스 정상화이며, 대부분의 케이스에서 서비스 정상화는 원인 파악보다 우선됩니다. 원인을 찾는 것도 물론 중요하지만, 장애를 빠르게 복구하고 사용자의 불편을 최소화하기 위해서 원인 파악보다는 장애 해소에 더욱 집중합니다. 일반적으로 많이 사용하는 장애 복구 방법을 살펴보겠습니다.

장비 증설

트래픽이 과도하게 몰리거나 변경된 코드가 시스템에 부하를 주는 경우 가장 먼저 장비를 증설합니다. 클라우드 환경의 가장 큰 장점이 손쉽고 빠르게 장비 증설이 가능하다는 점이기 때문에 이를 십분 활용하여 장비 증설을 통해 서비스를 안정화합니다.배달의민족 서비스의 경우 피크 시간의 트래픽이 다른 시간과 비교해서 극단적으로 높은 편입니다. 사전에 이를 충분히 고려해서 장비를 운영하고 있지만, 피크 시간에 예상하지 못한 트래픽이 급격하게 증가하게 되면 시스템이 매우 취약해질 수 있습니다. 이때 장비를 증설하면 빠르게 서비스를 안정화할 수 있고, 실제 병목을 일으키는 지점을 찾아서 근본적인 조처를 할 수 있는 시간을 벌 수 있습니다.

[배달의민족 트래픽 추이]

롤백

급증한 트래픽이 문제가 아닌 경우 가장 먼저 장애 발생 직전 시점에 변경된 내용이 있는지 확인합니다. 트래픽이 증가하지 않았다면 시스템의 어떤 변경으로 인해서 장애가 발생할 수 있기 때문입니다. 만약 시스템 변경으로 인해서 문제가 발생했다면, 즉시 변경사항을 롤백합니다. 이때 롤백은 코드 롤백뿐만 아니라 인프라 단의 설정과 같은 다른 변경도 모두 포함합니다. 일반적으로 장애 시점 이전 24시간 내의 변경 내역을 전부 확인하는데, 변경 직후에 장애가 발생하는 경우보다는 이슈가 누적되어서 몇 시간 뒤에 장애로 확산되거나 특정 작업 (ex, 배치)와 충돌이 나는 경우가 많기 때문입니다. 원인이 명확하지 않으면 코드나 설정을 변경하는 것보다 정상 동작하던 상태로 롤백하는 것이 훨씬 안전하므로 롤백을 가장 우선하여 고려합니다.

핫픽스

앞서 언급했던 롤백이 가장 빠른 복구 방법이긴 하지만, 코드 롤백이 불가능할 경우 (ex, DB 스키마 변경)나 문제의 원인이 명확하여 롤백보다 핫픽스가 더 빠르다고 판단되는 경우에는 문제 되는 부분을 빠르게 수정해서 핫픽스를 진행합니다. 핫픽스를 진행할 때는 원인을 명확하게 알고 100% 확률로 해소 될 수 있는 핫픽스라고 하더라도 반드시 페어로 확인하고, 베타에서 검증한 후에 진행하고 있습니다. 물론, 검증에 시간이 더 걸리지만, 장애 확산이나 side effect를 줄이기 위해서 안전하게 해결하는 것을 최우선으로 하고 있습니다.

장비 교체

간혹 특정 장비에 문제가 생기거나 위의 조치들로 해결되지 않을 때는 장비를 교체합니다. (클라우드 환경에서도 장비에 문제가 생기는 경우가 종종 있습니다.) 특정 장비에서만 문제가 발생하면 해당 장비만 교체하고, 전체적으로 문제가 발생하면 운영 중인 장비 구성과 동일한 세트를 준비한 후에 전체를 교체하기도 합니다. 서비스 중단 시간을 최소화하기 위해서 재기동을 하기보다는 장비를 교체하는 방향으로 진행하고 있으며 DB도 failover를 통해서 장비를 교체합니다. 물론, 불가피한 경우에는 재기동을 하기도 합니다. (말 안 들을 때 껐다 켜는 건 국룰 아닌가요?)

급박한 순간에도 항상 가장 빠르게 복구 할 수 있는 방법을 찾기 때문에, 서비스가 정상화 된 후 원인 파악을 진행해보면 처음 시도한 복구 방법이 잘못되었던 경우도 있습니다. 하지만 그 방법이 틀렸다고 생각하지는 않습니다. 엔지니어들은 항상 서비스 정상화를 위해 할 수 있는 가장 빠른 방법을 선택하고 있고 그런 시행착오를 거쳐 가면서 우리는 좀 더 나은 방향으로 나아가고 있다고 믿기 때문입니다.

장애 후속 조치

장애 복구가 완료되고, 서비스가 정상화되면 원인 파악과 재발 방지 대책 수립을 위해서 장애 리뷰를 진행합니다.

가장 먼저 장애 대응 조직에서는 장애보고서를 작성하게 되는데, 이 장애보고서에는 장애 발생 시각, 탐지 시각, 종료 시각, 장애 탐지 방법, 장애 발생 지점, 장애 복구 방법, 대응 과정 중의 시간별 action, 장애 원인, 재발 방지 대책 등이 포함됩니다. (내용이 꽤 많습니다)
이 중에서도 가장 중요한 항목은 장애 원인 분석과 재발 방지 대책 수립입니다.

장애 원인 분석

우리는 장애 원인을 정확하게 찾기 위해서 5whys라는 기법을 사용합니다.

5whys는 도요타의 Taiichi Ohno가 체계적인 문제 해결을 위해 개발한 도구로, 어떠한 문제 상황에 대해 그러한 상황이 발생하게 된 원인을 ‘왜 그러한 상황이 발생하였는가?’ 라는 질문을 여러 번 반복해나가면 문제의 근본 원인에 도달할 수 있다는 방법론입니다.

미국 제퍼슨 독립 기념관의 기둥 대리석이 지속적으로 부식되어 해마다 많은 보수비용이 발생하고 기념관의 이미지가 훼손되는 문제가 있었는데, 5whys를 통해서 해결한 이 사례를 예로 들어보겠습니다. .

• why 1. 왜 대리석들이 그렇게 빨리 부식되는가?
  — 비누 청소를 자주하기 때문이다.
• why 2. 왜 비누 청소를 자주하는가?
  — 비둘기 배설물이 많이 묻기 때문이다.
• why 3. 왜 비둘기 배설물이 많은가?
  — 비둘기의 먹잇감인 거미가 많이 있기 때문이다.
• why 4. 왜 거미가 많은가?
  — 거미의 먹잇감인 불나방이 많이 있기 때문이다.
• why 5. 왜 불나방이 많은가?
  — 실내 전등을 주변보다 일찍 켜기 때문이다.

  5whys를 통해 도출된 root cause를 해결하기 위해서 제퍼슨 독립 기념관은 주변 건물보다 2시간 늦게 조명을 밝히는 것으로 문제를 해결했습니다.

우리는 장애 리뷰에 이 방법론을 적용해서 조금 더 근본적인 원인을 찾고자 합니다. 근본 원인에 도달하는 과정은 어렵고 정답이 정해져있는 것도 아니지만 이 방법을 이용해서 많은 인사이트를 얻고 있습니다. 장애 리뷰에 이 방법을 적용하면서 아래 세 가지 포인트를 항상 고려하고 있습니다.

• 첫 번째 질문은 항상 장애에 영향을 받은 고객의 관점에서 시작해야 합니다.
• 검증이 가능한, 혹은 검증된 사실에 기반해서 답변을 해야 합니다.
• 5번의 숫자는 상징적인 숫자로 꼭 질문이 5개일 필요는 없고, 더 적거나 더 많아도 됩니다.

재발 방지 대책 수립

앞선 과정을 통해서 근본 원인을 찾았다면, 그 문제가 다시 발생하지 않도록 재발 방지 대책을 수립합니다. 이때 재발 방지 대책은 근본 원인을 제거하는 데서 그치지 않고 더 빠른 탐지와 더 빠른 복구에 도움이 되는 모든 조치를 포함합니다. 모니터링 지표 추가, 설정값 변경, 코드 리뷰 절차 개선, 배포 프로세스 수정 등 여러모로 고민하고 조치하며 단기, 중기, 장기적으로 개선할 방안들을 도출합니다. 단기적으로는 부하가 발생하는 로직 개선, 이슈 발생 시 빠른 탐지를 위한 알람 강화와 같은 항목들이 도출되며, 이 작업들은 대부분 하루 이틀 내에 마무리됩니다. 중, 장기적 대책은 아키텍처를 개선하거나 레거시를 제거하는 것과 같은 대규모 작업으로, 필요에 따라 TF를 구성하기도 하고 전사 프로세스 변경이 진행되는 때도 있습니다. 빠르게 개선할 수 없는 경우는 임시방편을 도입하기도 하지만 그 후에 반드시 근본 원인을 해결해야만 잠재적인 위험을 막아낼 수 있습니다.

장애 대응을 하면서 가장 뼈아픈 장애는 재발한 장애라고 생각합니다. 알면서도 막지 못했거나, 조치가 미흡해서 같은 장애가 재발하면, 원인을 모르는 장애보다 더 속상합니다. 그렇기 때문에 가능한 많은 사람이 여러모로 고민해서 재발방지 대책을 마련하고, 적절히 조치하기 위한 액션을 하고 있습니다.

장애 리뷰

장애보고서 작성이 완료되면 장애보고서 내용을 바탕으로 장애 리뷰를 진행하게 됩니다. 내부에서 정해진 장애 등급에 따라, 일부 장애는 팀/실 단위의 리뷰를 진행하고 대규모 장애의 경우 담당팀, SRE팀뿐만 아니라 각 조직의 조직장과 CTO까지 모두 리뷰에 참여하게 됩니다. 바쁘게 일정이 돌아가는 와중에도 이렇게 많은 인원이 모여서 리뷰를 하는 이유는 조금 더 넓은 범위를 살펴보기 위함입니다. 팀/실 단위로 리뷰한 내용 중 추가로 고려해봐야 할 이슈가 있을 수도 있고, 전사로 전파하여 주의를 기울여야 하는 케이스도 있기 때문입니다.

한가지 예를 들어보면, 특정 장비에 이슈가 있어서 해당 장비를 terminate하고 신규 장비를 투입한 적이 있습니다. 하지만 장비를 terminate 시켜버렸기 때문에 해당 장비에 어떤 문제가 있었는지 원인분석을 하기 위한 충분한 자료를 확보하지 못하였습니다. 장애 리뷰를 통해서 이러한 내용을 알게 되었고, 이 문제를 해결하기 위해서 장비 교체 시에 장비를 terminate 하기보다는 비정상적인 장비만 일시적으로 서비스에서 분리할 수 있도록 전사에 공유하여 장애 원인분석에 도움이 될 수 있도록 개선하였습니다.

이런 일련의 리뷰 절차가 완료되면 장애보고서를 전사 개발조직에도 공유하고 있습니다. 장애란 비단 한 조직 혹은 개인의 문제가 아니며 누구든 비슷한 장애를 겪을 수 있습니다. 직접적인 경험을 해보지 못하더라도 동료들이 충분히 경험하고 고민한 내용을 통해서 간접적으로 경험할 수 있고, 이 간접적인 경험을 통해 인사이트를 얻는다면 시스템을 한 단계 더 탄탄하게 만들 수 있습니다.

장애 지표 활용

앞서 언급했듯이 장애보고서를 통해서 생각보다 많은 항목이 수집되고 있습니다.

장애보고서에서 장애 발생 시각, 탐지 시각, 종료 시각, 장애 탐지 방법, 장애 발생 지점, 장애 복구 방법, 대응 과정 중의 시간별 action, 장애 원인, 재발 방지 대책, 장애 등급, 장애 후속 조치 방안과 같은 항목들이 수집되고 있으며, 이 데이터들을 모아서 uptime을 높이거나 전체적인 장애 대응 프로세스를 개선하는 데 참고하고 있습니다. 장애가 자주 발생하는 지점을 확인해서 우리 시스템의 취약점을 알 수 있게 되고, 장애 유형에 따라 전파 범위를 조절할 수 있으며, 외부시스템의 장애 빈도나 유형을 파악해서 연동 전략을 고민할 수 있습니다. 장애 발생 시각과 탐지 시각 사이의 간격이 크면 장애 탐지가 빠르게 되고 있지 않다는 뜻이기 때문에 모니터링과 알람을 강화하여 더 빠르게 탐지할 방안을 고민할 수도 있습니다. 개별 장애보고서의 내용도 모두 중요하고 도움이 되지만 모여진 데이터를 기반으로 인사이트를 얻어서 개선 방안을 찾아 나가는 것도 중요합니다.

마무리

장애는 항상 다루기 어렵고 까다로운 주제입니다.

사실, 장애에 대해서 터놓고 이야기하는 것이 쉽지는 않습니다. 장애가 발생한 도메인 담당자의 입장에서는 미안한 마음이 들어서, 리뷰를 진행하면서 물어보는 입장에서는 혹시 불편해하지 않을까 고민이 되기 때문입니다.

하지만 우리가 이렇게 터놓고 이야기할 수 있는 것은 장애에 대해 특정 개인이나 팀을 탓하지 않는다는 것을 모두가 알고 있기 때문입니다. 오늘 내가 한 실수는 내일 내 옆자리 동료도 할 수 있는 실수이고, 수백명의 개발자가 잠재적인 위험을 안고 있다는 뜻일 수 있습니다. 작은 불씨 일때는 몇 명의 입김으로 불을 끌 수 있지만, 덮거나 숨기면 그 불씨는 더 커져서 산 하나를 홀랑 태워먹을 수도 있습니다. 감추고 숨기기보다는 함께 해결하고 함께 고민하는 것이 장애 대응의 가장 중요한 핵심이며, 그렇게 할 수 있는 조직이 건강한 조직이라고 생각합니다.

지난번에 썼던 내용이지만, 다시 한 번 더 강조해봅니다.

사람은 누구나 실수 할 수 있기 때문에
같은 실수를 반복하지 않는 것이 중요하고,
실수를 통해서 배우는 것이 중요하며,
내가 한 실수는 다른 사람도 할 수 있기 때문에
실수를 방지할 수 있도록 시스템이 막아줄 수 있어야 한다.

장애는 결코 어느 한 사람, 한 조직의 잘못이 아닙니다.

감사합니다.