긴급 대응 전략 설계를 위한 권장 사항

이 Azure 잘 설계된 프레임워크 운영 우수성 검사 목록 권장 사항에 적용됩니다.

이 가이드에서는 비상 대응 전략을 설계하기 위한 권장 사항을 설명합니다. 워크로드의 수명 주기 동안 발생하는 일부 문제는 비상 사태를 선언할 수 있을 만큼 중요합니다. 팀이 따라갈 수 있는 엄격하게 제어되고 집중된 프로세스 및 절차를 구현하여 문제가 차분하고 질서 정연하게 처리되도록 할 수 있습니다. 비상 사태는 자연스럽게 모든 사람의 스트레스 수준을 높이고 팀이 잘 준비되지 않은 경우 혼란스러운 환경으로 이어질 수 있습니다. 스트레스와 혼란을 최소화하려면 대응 전략을 설계하고, 대응 전략을 조직과 공유하고, 정기적인 응급 대응 교육을 수행합니다.

주요 디자인 전략

비상 대응 전략은 질서 정연하고 잘 정의된 프로세스 및 절차 집합이어야 합니다. 각 프로세스 및 프로시저에는 각 단계가 빠르고 안전하게 문제를 해결하는 방향으로 진행되도록 하는 스크립트가 있어야 합니다. 긴급 대응 전략을 개발하려면 다음 개요를 고려하세요.

• 필수 조건
  • 관찰성 플랫폼 개발
  • 인시던트 대응 계획 만들기
• 인시던트 단계
  • 감지
  • 억제
  • 심사
• 인시던트 후 단계
  • RCA(근본 원인 분석)
  • 사후 분석
• 진행 중인 활동
  • 비상 대응 훈련

다음 섹션에서는 이러한 각 단계에 대한 권장 사항을 제공합니다.

강력한 비상 대응 전략을 갖기 위해서는 강력한 관찰성 플랫폼이 있어야 합니다. 관찰성 플랫폼에는 다음과 같은 특성이 있어야 합니다.

• 전체적인 모니터링: 인프라 및 애플리케이션 관점에서 워크로드를 철저히 모니터링해야 합니다.

• 자세한 정보 로깅: 문제를 심사할 때 조사에 도움이 되도록 구성 요소에 대한 자세한 정보 로깅을 사용하도록 설정합니다. 쉽게 관리할 수 있도록 로그를 구성합니다. 분석을 위해 준비할 데이터 싱크에 로그를 자동으로 보냅니다.

• 유용한 대시보드: 조직 전체의 각 팀에 맞게 조정된 상태 모델 기반 대시보드를 만듭니다. 각 팀은 워크로드 상태의 다양한 측면을 담당합니다.

• 실행 가능한 경고: 워크로드 팀에 유용한 경고를 만듭니다. 팀의 조치가 필요하지 않은 경고를 방지합니다. 이러한 종류의 경고가 너무 많을 경우 사용자가 경고 알림을 무시하거나 차단할 수 있습니다.

• 자동 알림: 적절한 팀이 해당 팀의 조치가 필요한 경고를 자동으로 수신하는지 확인합니다. 예를 들어 계층 1 지원 팀은 모든 경고에 대한 알림을 받아야 하는 반면 보안 엔지니어는 보안 이벤트에 대한 경고만 받아야 합니다.

자세한 내용은 관찰성 프레임워크를 디자인하고 만들기 위한 권장 사항을 참조 하세요.

인시던트 대응 계획 만들기

비상 대응 전략의 기초는 인시던트 대응 계획입니다. 재해 복구 계획과 마찬가지로 인시던트 대응 계획에 대한 역할, 책임 및 절차를 명확하고 철저하게 정의합니다. 계획은 최신 상태인지 확인하는 정기적인 검토가 적용되는 버전 제어 문서여야 합니다.

계획에서 다음 구성 요소를 명확하게 정의합니다.

Roles

인시던트 응답 관리자를 식별합니다. 이 사용자는 인시던트 시작부터 수정, 근본 원인 분석까지 인시던트 소유입니다. 인시던트 응답 관리자는 프로세스를 따르고 대응 팀이 작업을 수행할 때 적절한 당사자에게 알릴 수 있도록 합니다.

사후 관리 리더를 식별합니다. 이 개인은 인시던트가 해결된 직후 사후 관리가 수행되도록 합니다. 인시던트에서 나오는 결과를 적용하는 데 도움이 되는 보고서를 생성합니다.

프로세스 및 프로시저

워크로드 팀은 긴급 조건을 정의하고 이해해야 합니다. 팀에서 사례가 심각하다는 것을 확인하면 재해를 선언하고 재해 복구 계획을 시작할 수 있습니다. 심각하지 않은 경우 문제가 재해의 기준을 충족하지 못할 수 있습니다. 그러나 여전히 이 문제를 비상 사태로 간주해야 하며, 비상 대응 계획을 시작해야 합니다. 비상 사태는 워크로드 내부 문제일 수도 있고 워크로드의 종속성 문제로 인해 발생할 수도 있습니다. 지원 팀은 외부 사용자가 보고한 문제가 기본 문제에 대한 가시성이 없는 경우에도 비상 조건을 충족하는지 여부를 확인할 수 있어야 합니다.

통신 및 에스컬레이션 계획을 정확하게 정의합니다. 수신하는 경고 알림 유형에 따라 계층 1 지원이 적절한 팀에 쉽게 연락하여 문제를 에스컬레이션할 수 있는지 확인합니다. 내부 및 외부 당사자에게 적합한 통신 유형을 알고 있는지 확인합니다. 통신 및 에스컬레이션 계획에는 통화 일정 및 직원 목록을 포함합니다.

전체 계획에서 포함 및 심사 스크립트를 포함합니다. Teams는 포함 및 심사 기능을 수행할 때 이러한 단계별 절차를 따릅니다. 인시던트 폐쇄를 정의하는 항목에 대한 설명을 포함합니다.

포함할 기타 항목

Microsoft Teams와 같은 내부 통신 및 티켓팅 도구 또는 백로그 계획 도구와 같은 인시던트 과정에서 활동을 추적하기 위해 인시던트 중에 사용되는 모든 표준 도구를 문서화합니다.

비상 자격 증명(비상 계정이라고 도 함)을 문서화합니다. 사용 방법을 설명하는 단계별 가이드를 포함합니다.

비상 대응 드릴 지침을 만들고 드릴이 수행된 시기를 기록해 줍니다.

필요한 법률 또는 규제 조치(예: 데이터 위반 전달)를 문서화합니다.

관찰성 트리거에 대한 작업

변칙을 모니터링하고 자동으로 경고하는 잘 설계된 관찰성 플랫폼이 있는 경우 신속하게 문제를 감지하고 심각도를 확인할 수 있습니다. 문제가 비상사태로 간주되는 경우 계획을 시작할 수 있습니다. 경우에 따라 지원 팀은 관찰성 플랫폼을 통해 알림을 받지 않습니다. 고객은 지원 팀 커뮤니케이션 방법을 사용하여 지원 문제를 보고할 수 있습니다. 또는 계정 임원이나 부사장과 같이 정기적으로 함께 일하는 사람들에게 연락할 수도 있습니다. 지원 팀에 알림이 표시되더라도 항상 동일한 단계에 따라 문제의 유효성을 검사하고 심각도를 확인해야 합니다. 응답 계획에서의 편차는 스트레스와 혼란을 더할 수 있습니다.

포함 프로시저 정의

문제 수정의 첫 번째 단계는 나머지 워크로드를 보호하는 문제를 포함하는 것입니다. 포함 전략은 문제 유형에 따라 달라지지만 일반적으로 워크로드 흐름 경로에서 영향을 받는 구성 요소를 제거하는 작업이 포함됩니다. 예를 들어 리소스를 종료하거나 네트워크 라우팅 경로에서 제거할 수 있습니다. 시스템 관리자, 엔지니어 및 선임 개발자는 함께 작업하여 포함 전략을 설계해야 합니다. 포함은 문제의 폭발 반경을 제한하고 문제가 해결될 때까지 워크로드 기능을 저하된 상태로 유지해야 합니다. 심사를 수행하기 위해 영향을 받는 구성 요소에 액세스할 수 있어야 하는 경우 나머지 워크로드에 대한 액세스가 차단되어야 합니다. 가능한 한 워크로드 및 나머지 시스템과 분리된 경로를 통해서만 구성 요소에 액세스해야 합니다.

심사 프로시저 정의

문제를 성공적으로 포함하면 심사 작업을 시작할 수 있습니다. 심사 중에 수행하는 단계는 문제 유형에 따라 달라집니다. 워크로드 지원의 특정 영역에 대한 팀은 팀과 관련된 인시던트에 대한 절차를 만들어야 합니다. 예를 들어 보안 팀은 보안 문제를 심사해야 하며 개발한 스크립트를 따라야 합니다. 팀이 심사 작업을 수행할 때 잘 정의된 스크립트를 따르는 것이 중요합니다. 이러한 스크립트는 비효율적이거나 다른 문제를 일으킬 수 있는 변경 내용을 실행 취소하는 롤백 프로세스를 포함하는 단계별 프로세스여야 합니다. 기성 로그 집계 및 분석 도구를 사용하여 심층 분석이 필요한 문제를 효율적으로 조사합니다. 문제가 해결된 후 잘 정의된 프로세스에 따라 영향을 받는 구성 요소를 워크로드 흐름 경로로 안전하게 다시 가져옵니다.

RCA 인시던트 보고서 생성

고객에게 SLA(서비스 수준 계약)는 인시던트가 해결된 후 특정 기간 내에 RCA 보고서를 발급해야 한다는 것을 지시할 수 있습니다. 인시던트 소유자는 RCA 보고서를 작성해야 합니다. 그러지 못하는 경우 인시던트 소유자와 긴밀하게 협력한 다른 사용자가 RCA 보고서를 작성할 수 있습니다. 이 전략은 인시던트에 대한 정확한 설명을 보장합니다. 일반적으로 조직에는 정보가 표시되는 방법과 공유할 수 있거나 공유할 수 없는 정보의 종류에 대한 지침이 포함된 정의된 RCA 템플릿이 있습니다. 고유한 템플릿 및 지침을 만들어야 하는 경우 관련자가 검토하고 승인했는지 확인합니다.

인시던트 사후 관리 유지

공정한 개인은 흠 없는 사후 조사를 이끌어야 합니다. 사후 세션에서는 모든 사람이 인시던트에서 발견한 결과를 공유합니다. 인시던트 대응에 참여한 각 팀은 인시던트에 근무한 개인이 대표해야 합니다. 이러한 개인은 성공한 영역과 개선될 수 있는 영역의 예제로 준비된 세션에 와야 합니다. 세션은 응답 중에 발생할 수 있는 인시던트 또는 문제에 대한 책임을 할당하기 위한 포럼이 아닙니다. 사후 관리 리더는 다음과 같이 개선에 중점을 둔 작업 항목의 명확한 목록과 함께 세션을 떠나야 합니다.

• 응답 계획의 개선 사항입니다. 적절한 작업을 더 잘 캡처하려면 프로세스 또는 프로시저를 다시 평가하고 다시 작성해야 할 수 있습니다.

• 관찰성 플랫폼이 개선되었습니다. 이전에 특정 유형의 인시던트 catch를 위해 임계값을 다시 평가해야 할 수도 있고, 고려되지 않은 동작을 catch하기 위해 새 모니터링을 구현해야 할 수도 있습니다.

• 워크로드가 개선되었습니다. 이 인시던트는 영구 수정으로 해결해야 하는 워크로드의 취약성을 노출할 수 있습니다.

고려 사항

지나치게 공격적인 대응 전략은 거짓 경보 또는 불필요한 에스컬레이션으로 이어질 수 있습니다.

마찬가지로, 임계값 위반에 대응하기 위해 자동 크기 조정 또는 기타 자체 복구 작업을 적극적으로 구현하면 불필요한 지출 및 관리 부담이 발생할 수 있습니다. 경고 및 크기 조정과 같은 자동 작업에 대해 설정할 정확한 임계값을 알 수 없습니다. 낮은 환경 및 프로덕션 환경에서 테스트를 수행하여 요구 사항에 적합한 임계값을 결정하는 데 도움이 됩니다.

Azure 촉진

Azure Monitor 는 클라우드 및 온-프레미스 환경에서 모니터링 데이터를 수집, 분석 및 응답하기 위한 포괄적인 솔루션입니다. 자동 크기 조정 및 기타 자동 복구 메커니즘과 같은 자동 알림 및 기타 작업에 대해 구성할 수 있는 강력한 경고 플랫폼이 포함되어 있습니다.

Monitor를 사용하여 기계 학습을 통합합니다. 인시던트 심사 및 사전 대응 조치를 자동화하고 최적화합니다. 자세한 내용은 Monitor의 AIOps 및 기계 학습을 참조하세요.

Log Analytics 는 Monitor에 기본 제공되는 강력한 분석 도구입니다. Log Analytics를 사용하여 집계된 로그에 대해 쿼리를 실행하고 워크로드에 대한 인사이트를 얻을 수 있습니다.

Microsoft는 Azure 관련 인시던트 준비 교육을 제공합니다. 자세한 내용은 Azure 인시던트 준비 및 인시던트 준비 소개를 참조하세요.

관련 링크

• 관찰성 프레임워크를 디자인하고 만들기 위한 권장 사항
• 신뢰할 수 있는 모니터링 및 경고 전략을 설계하기 위한 권장 사항
• 자기 치유 및 자기 보존에 대한 권장 사항

운영 우수성 검사 목록

전체 권장 사항 집합을 참조하세요.