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

  • 아티클

이 Azure Well-Architected Framework 운영 우수성 검사 목록 권장 사항에 적용됩니다.

OE:08 효과적인 응급 운영 사례를 개발합니다. 워크로드가 인프라 및 코드에서 의미 있는 상태 신호를 내보내도록 합니다. 결과 데이터를 수집하고 이를 사용하여 대시보드 및 쿼리를 통해 긴급 대응을 시행하는 실행 가능한 경고를 생성합니다. 호출 회전, 인시던트 관리, 긴급 리소스 액세스 및 사후 관리 실행과 같은 사람의 책임을 명확하게 정의합니다.

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

주요 디자인 전략

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

  • 필수 구성 요소
    • 가시성 플랫폼 개발
    • 인시던트 대응 계획 만들기
  • 인시던트 단계
    • 감지
    • Containment
    • 심사
  • 인시던트 후 단계
    • RCA(근본 원인 분석)
    • 사후 분석
  • 진행 중인 활동
    • 비상 대응 훈련

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

가시성

강력한 비상 대응 전략을 사용하려면 강력한 가시성 플랫폼이 있어야 합니다. 가시성 플랫폼에는 다음과 같은 특성이 있어야 합니다.

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

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

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

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

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

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

인시던트 대응 계획

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

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

역할

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

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

프로세스 및 절차

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

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

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

포함할 기타 항목

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

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

응급 대응 드릴 지침을 만들고 드릴이 수행된 시점의 기록을 유지합니다.

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

인시던트 검색

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

Containment

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

심사

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

RCA 보고

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

인시던트 사후 관리

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

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

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

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

고려 사항

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

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

Azure 촉진

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

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

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

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

운영 우수성 검사 목록

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

운영 우수성 검사 목록