기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

5단계: 대응 및 학습

애플리케이션이 중단 이벤트에 대응하는 방식은 신뢰성에 영향을 미칩니다. 경험을 통해 학습하고 애플리케이션이 과거에 중단에 대응한 방식도 신뢰성을 개선하는 데 중요합니다. 

대응 및 학습 단계는 애플리케이션의 중단 이벤트에 더 잘 대응하기 위해 구현할 수 있는 사례에 중점을 둡니다. 또한 운영 팀과 엔지니어의 경험에서 최대한 학습하는 데 도움이 되는 사례도 포함되어 있습니다.

인시던트 분석 보고서 생성

인시던트가 발생할 때 첫 번째 조치는 고객과 비즈니스에 대한 추가 피해를 최대한 빨리 방지하는 것입니다. 애플리케이션이 복구된 후 다음 단계는 발생한 일을 이해하고 재발을 방지하기 위한 단계를 식별하는 것입니다. 이 인시던트 후 분석은 일반적으로 애플리케이션 장애로 이어진 일련의 이벤트와 중단이 애플리케이션, 고객 및 비즈니스에 미치는 영향을 문서화하는 보고서로 캡처됩니다. 이러한 보고서는 귀중한 학습 아티팩트가 되며 비즈니스 전반에 걸쳐 널리 공유되어야 합니다.

Amazon COE(오류 수정) 프로세스에 설명된 것과 같은 좋은 인시던트 분석 보고서는 표준화된 형식을 따르며 애플리케이션 장애로 이어진 조건을 최대한 자세히 캡처하려고 합니다. 이 보고서는 타임스탬프가 지정된 일련의 이벤트를 자세히 설명하고 타임라인 동안 애플리케이션의 측정 가능한 상태를 설명하는 정량적 데이터(대개 모니터링 대시보드의 지표 및 스크린샷)를 캡처합니다. 보고서는 조치를 취한 운영자와 엔지니어의 사고 프로세스와 이를 결론에 이르게 한 정보를 캡처해야 합니다. 또한 보고서에는 발생한 경보, 해당 경보가 애플리케이션 상태를 정확하게 반영했는지 여부, 이벤트와 결과 경보 간의 시간 지연, 인시던트 해결 시간 등 다양한 지표의 성능도 자세히 설명되어 있어야 합니다. 타임라인은 시작된 실행서 또는 자동화와 애플리케이션이 유용한 상태를 다시 얻는 데 어떻게 도움이 되었는지도 캡처합니다. 타임라인의 이러한 요소는 팀이 문제를 얼마나 빨리 해결했는지, 중단 완화에 얼마나 효과적인지 등 자동화된 응답과 운영자 응답의 효과를 이해하는 데 도움이 됩니다.

과거 이벤트의이 세부 그림은 강력한 교육 도구입니다. 팀은 다른 사람이 이벤트를 검토하고 배울 수 있도록 전체 비즈니스에서 사용할 수 있는 중앙 리포지토리에 이러한 보고서를 저장해야 합니다. 이렇게 하면 프로덕션에서 발생할 수 있는 문제에 대한 팀의 직관이 향상될 수 있습니다.

상세한 인시던트 보고서의 리포지토리도 운영자를 위한 교육 자료의 출처가 됩니다. 팀은 인시던트 보고서를 사용하여 보고서에 캡처된 타임라인을 재생하는 정보가 팀에 제공되는 테이블탑 또는 라이브 게임 데이에 영감을 줄 수 있습니다. 운영자는 타임라인의 부분 정보가 포함된 시나리오를 살펴보고 어떤 조치를 취할지 설명할 수 있습니다. 그러면 게임 데이의 진행자는 운영자의 작업에 따라 애플리케이션이 어떻게 응답했는지에 대한 지침을 제공할 수 있습니다. 이렇게 하면 운영자의 문제 해결 기술을 개발하여 문제를 보다 쉽게 예측하고 해결할 수 있습니다.

애플리케이션 신뢰성을 담당하는 중앙 집중식 팀은 전체 조직이 액세스할 수 있는 중앙 집중식 라이브러리에 이러한 보고서를 유지해야 합니다. 또한이 팀은 보고서 템플릿을 유지하고 인시던트 분석 보고서를 작성하는 방법에 대해 팀을 교육해야 합니다. 신뢰성 팀은 정기적으로 보고서를 검토하여 소프트웨어 라이브러리, 아키텍처 패턴 또는 팀 프로세스 변경을 통해 해결할 수 있는 비즈니스 전반의 추세를 탐지해야 합니다.

운영 검토 수행

4단계: 운영에서 설명한 대로 운영 검토는 최근 기능 릴리스, 인시던트 및 운영 지표를 검토할 수 있는 기회입니다. 운영 검토는 기능 릴리스 및 인시던트의 학습 내용을 조직의 더 광범위한 엔지니어링 커뮤니티와 공유할 수 있는 기회이기도 합니다. 운영 검토 중에 팀은 롤백된 기능 배포, 발생한 인시던트 및 처리 방법을 검토합니다. 이를 통해 조직 전체의 엔지니어는 다른 사람의 경험을 통해 배우고 질문할 수 있습니다.

운영 검토를 회사의 엔지니어링 커뮤니티로 열어 비즈니스를 운영하는 IT 애플리케이션과 발생할 수 있는 문제 유형에 대해 자세히 알아볼 수 있습니다. 이들은 비즈니스를 위한 다른 애플리케이션을 설계, 구현 및 배포할 때 이러한 지식을 함께 전달할 것입니다.

경보 성능 검토

운영 단계에서 설명한 대로 경보로 인해 대시보드 알림, 티켓 생성, 이메일 전송 또는 운영자 페이징이 발생할 수 있습니다.   애플리케이션에는 작업의 다양한 측면을 모니터링하도록 구성된 여러 경보가 있습니다. 시간이 지남에 따라 이러한 경보의 정확성과 효과를 검토하여 경보 정밀도를 높이고 오탐을 줄이며 중복 알림을 통합해야 합니다.

경보 정밀도

경보는 경보를 유발한 특정 중단을 해석하거나 진단하는 데 소요되는 시간을 줄이기 위해 최대한 구체적이어야 합니다. 애플리케이션 장애에 대응하여 경보가 발생하면 경보를 수신하고 이에 대응하는 운영자는 먼저 경보가 전달하는 정보를 해석해야 합니다. 이 정보는 복구 절차와 같은 일련의 작업에 매핑되는 간단한 오류 코드이거나 경보가 발생한 이유를 이해하기 위해 검토해야 하는 애플리케이션 로그의 줄이 포함될 수 있습니다. 팀이 애플리케이션을 보다 효과적으로 운영하는 방법을 배우면 이러한 경보를 최대한 명확하고 간결하게 개선해야 합니다.

애플리케이션에 발생할 수 있는 모든 중단을 예상할 수는 없으므로 운영자가 분석하고 진단해야 하는 일반 경보가 항상 있습니다. 팀은 응답 시간을 개선하고 평균 복구 시간(MTTR)을 줄이기 위해 일반 경보 수를 줄여야 합니다. 이상적으로는 경보와 자동화된 응답 또는 사람이 수행하는 응답 간에 one-to-one 관계가 있어야 합니다.  

거짓 긍정

운영자의 조치가 필요하지 않지만 이메일, 페이지 또는 티켓으로 알림을 생성하는 경보는 시간이 지남에 따라 운영자가 무시합니다.   주기적으로 또는 인시던트 분석의 일부로 경보를 검토하여 종종 무시되거나 운영자의 조치가 필요하지 않은 경보(거짓 긍정)를 식별합니다.   경보를 제거하거나 작업자에게 실행 가능한 알림을 발행하도록 경보를 개선해야 합니다.

거짓 부정

인시던트 중에는 예기치 않은 방식으로 애플리케이션에 영향을 미치는 이벤트로 인해 인시던트 중에 경고하도록 구성된 경보가 실패할 수 있습니다.   인시던트 분석의 일환으로 발생했어야 하지만 발생하지 않은 경보를 검토해야 합니다. 이러한 경보를 개선하여 이벤트에서 발생할 수 있는 조건을 더 잘 반영하도록 해야 합니다. 또는 동일한 중단에 매핑되지만 중단의 다른 증상으로 인해 발생하는 추가 경보를 생성해야 할 수 있습니다.

중복 알림

애플리케이션을 손상시키는 중단은 여러 증상을 유발할 수 있으며 여러 경보를 초래할 수 있습니다.   정기적으로 또는 인시던트 분석의 일부로 실행된 경보 및 알림을 검토해야 합니다.   운영자가 중복 알림을 수신한 경우 집계 경보를 생성하여 단일 알림 메시지로 통합합니다.

지표 검토 수행

팀은 월별 심각도별 인시던트 수, 인시던트 감지 시간, 원인 식별 시간, 문제 해결 시간, 생성된 티켓 수, 전송된 알림, 발생한 페이지 등 애플리케이션에 대한 운영 지표를 수집해야 합니다. 이러한 지표를 한 달에 한 번 이상 검토하여 운영 직원의 부담, 운영 직원이 처리하는 signal-to-noise 비율(예: 정보 제공 및 실행 가능한 알림), 팀이 제어하에 애플리케이션을 운영하는 능력을 개선하고 있는지 확인합니다. 이 검토를 사용하여 운영 팀의 측정 가능한 측면의 추세를 이해합니다. 이러한 지표를 개선하는 방법에 대해 팀에게 아이디어를 구합니다.  

교육 및 지원 제공

인시던트 또는 예상치 못한 동작으로 이어진 애플리케이션 및 해당 환경에 대한 자세한 설명을 캡처하기는 어렵습니다. 또한 이러한 시나리오를 예측하기 위해 애플리케이션의 복원력을 모델링하는 것이 항상 간단한 것은 아닙니다. 조직은 운영 팀과 개발자가 복원력 모델링, 인시던트 분석, 게임 데이, 카오스 엔지니어링 실험과 같은 활동에 참여할 수 있도록 교육 및 지원 자료에 투자해야 합니다. 이렇게 하면 팀이 생성하는 보고서의 충실도와 팀이 캡처하는 지식이 향상됩니다. 또한 팀은 예정된 검토를 통해 통찰력을 얻어야 하는 더 작고 경험이 풍부한 엔지니어 그룹에 의존하지 않고도 장애를 예상할 수 있는 더 나은 역량을 갖추게 됩니다.

인시던트 지식 기반 생성

인시던트 보고서는 인시던트 분석의 표준 출력입니다. 애플리케이션이 손상되지 않았더라도 이상 애플리케이션 동작을 감지한 시나리오를 문서화하려면 동일하거나 유사한 보고서를 사용해야 합니다. 동일한 표준화된 보고서 구조를 사용하여 카오스 실험 및 게임 데이의 결과를 캡처합니다. 보고서는 인시던트 또는 예상치 못한 동작으로 이어진 애플리케이션 및 환경의 스냅샷을 나타냅니다. 이러한 표준화된 보고서는 비즈니스 내 모든 엔지니어가 액세스할 수 있는 중앙 리포지토리에 저장해야 합니다.  

그런 다음 운영 팀과 개발자는이 지식 기반을 검색하여 과거에 애플리케이션을 방해한 요소, 중단을 일으킬 수 있는 시나리오 유형, 애플리케이션 장애를 방해한 요소를 파악할 수 있습니다. 이 지식 기반은 운영 팀과 개발자의 기술을 개선하기 위한 액셀러레이터가 되어 지식과 경험을 공유할 수 있습니다. 또한 보고서를 게임 데이 또는 카오스 실험을 위한 훈련 자료 또는 시나리오로 사용하여 운영 팀의 직관과 중단 문제를 해결하는 능력을 개선할 수 있습니다.

심층 복원력 구현

앞서 설명한 대로 고급 조직은 경보에 대해 여러 응답을 구현합니다. 응답이 효과적일 것이라는 보장은 없으므로 응답을 계층화하면 애플리케이션이 정상적으로 실패할 수 있습니다. 개별 응답이 DR 시나리오로 이어질 수 있는 단일 장애 지점이 되지 않도록 각 지표에 대해 최소 두 개의 응답을 구현하는 것이 좋습니다.   이러한 계층은 이전 응답이 효과적이지 않은 경우에만 연속 응답이 수행되도록 순차적으로 생성해야 합니다. 단일 경보에 대해 여러 계층화된 응답을 실행해서는 안 됩니다. 대신 응답이 실패했는지 여부를 나타내는 경보를 사용하고 실패할 경우 다음 계층화된 응답을 시작합니다.