교정

이 모듈에서 살펴본 것처럼 인시던트 응답 수명 주기를 5단계로 분할하면 프로세스를 이해하는 데 도움이 되지만, 단계가 다이어그램에 표시되는 것처럼 항상 고유하지는 않습니다. 특히 응답 단계와 수정 단계 사이의 선이 흐리게 표시되기 시작하는 경우가 많습니다. 이는 상황을 완화하거나 개선하기 위한 작업이 반대의 영향을 미칠 때 특히 그렇습니다. 이 경우 응답 및 수정은 둘 간에 겹치거나 앞뒤로 이동하는 경향이 있습니다.

이 단원에서는 수정 및 이 단계를 구성하는 단계뿐만 아니라 몇 가지 유용한 팁과 도구에 대해 자세히 알아봅니다. 주의해야 할 한 가지 중요한 점은 여기에 설명된 조치를 규범적 검사 목록으로 사용하면 안 됩니다.

실제로 수정에 대한 검사 목록이 이미 있는 경우 자동화를 그림으로 가져올 때라는 지표가 되는 경우가 많습니다. 수행해야 할 작업과 문제를 해결하기 위해 수행해야 하는 작업을 정확하게 설명할 수 있는 경우 시스템이 이를 수행할 수 있도록 이러한 단계를 컴퓨터에 가르칠 수 있는 완벽한 시기입니다.

시작 위치

인시던트에 대응하는 데 걸리는 시간을 줄이는 것이 중요하다는 것을 배웠습니다. 이제 문제를 수정하거나 해결하는 프로세스를 가속화하는 데 도움이 되는 몇 가지 사항을 살펴보겠습니다.

다른 팀 구성원은 일이 작동하는 방식의 다른 정신 모델과 첫 번째 단계가 무엇인지에 대한 다른 아이디어를 가질 수 있습니다. 먼저 로그를 살펴보고, 다른 하나는 먼저 쿼리를 실행하고 메트릭을 살펴볼 수 있습니다. 성공에 대한 올바른 경로는 하나도 없습니다.

그러나 사람들에게 어디로 가야 하는지, 무엇을 보아야 하는지에 대한 맥락과 지침을 제공하는 데 도움이 됩니다.

에스컬레이션 방법 및 누구에게 할지

개선 시작 지점을 설정할 때 대답해야 할 중요한 질문은 다음과 같습니다: 문제가 발생했을 때, 그 문제를 해결하기 위해 누구에게 연락할 수 있습니까? 운영팀이나 사이트 신뢰성 엔지니어링뿐만 아니라, 일반적으로 팀 전체에 온콜 책임을 더 많이 전가하려고 해야 합니다. 안정성 목표를 달성하기 위해 시스템을 가동하고 실행하는 것은 모든 팀 구성원의 책임이어야 합니다.

첫 번째 응답자에게 도움이 되는 리소스는 무엇인가요?

다음 고려 사항은 첫 번째 응답자가 프로세스를 시작하는 데 사용할 수 있는 항목을 결정하는 것입니다. 여기에는 관련 메트릭, 로그, 쿼리 등이 포함될 수 있습니다. 가능한 경우 Azure 통합 문서/문제 해결 가이드에서 제공해야 합니다. 우리는 잠시 후에 그들에 대해 이야기 할 것입니다.

리소스에 대한 간단한 링크를 제공하는 것도 유용합니다(종종 문제 해결 가이드에서). 가능한 한 빨리 문제에 응답하고 수정하는 것이 목표인 경우 올바른 문서 또는 URL을 검색하지 않고도 질문에 대한 답변을 찾을 수 있도록 지원하면 프로세스 속도가 빨라집니다.

관련자 업데이트

문제를 해결하는 데 너무 집중하여 사건에 대한 대응에 직접 관여하지는 않지만 무슨 일이 일어나고 있는지 알고 싶어하는 많은 사람들이 있다는 것을 잊어 버릴 수 있습니다.

다른 내부 팀과 소통하고 인시던트가 발생할 때 발생하는 일을 계속 파악하는 것이 중요합니다. 일관된 업데이트를 제공하지 않으면 상태 업데이트를 요청할 가능성이 높습니다. 그들은이 정보에 대한 모든 권리를 가지고 있지만, 당신은 그들이 문제와 그것에 대해 무엇을하고 있는지 인식 할 수있는 더 나은 방법이 필요합니다.

내부 팀에 대한 승인에 대해 명확히 해야 합니다. 알고 있는 내용과 수행 중인 작업을 명확하게 제시하고, 언제 피드백을 받을 수 있을지에 대한 기대치를 설정합니다.

이해 관계자와 통신하기 위한 수식은 간단합니다.

• 이것이 우리가 알고 있는 것입니다.
• 이것이 우리가 하고 있는 일입니다.
• X 시간 안에 다시 돌아오겠습니다.

이렇게 하면 문제를 해결하기 위해 노력하는 동안 이해 관계자가 사용자에게 와서 방해하지 않도록 방지할 수 있습니다.

이 정보를 배포하는 한 가지 방법은 마지막 단원에서 언급한 것과 같이 쉽게 편집할 수 있는 상태 웹 페이지를 사용하는 것입니다. 대부분의 경우 내부 이해 관계자를 위한 별도의 자세한 상태 페이지와 고객을 위한 외부 상태 페이지가 있을 수 있습니다. 앞의 수식은 두 경우 모두에 대해 작동합니다.

Azure Monitor 통합 문서 및 문제 해결 가이드 사용

Azure에는 수정 단계에서 팀에 매우 유용할 수 있는 두 가지 긴밀한 관련 기능인 Azure Monitor 통합 문서 및 Application Insights 문제 해결 가이드가 있습니다. 이 모듈의 목적을 위해 동일한 사용자 인터페이스를 포함하는 등 서로 교환할 수 있습니다. Azure 포털의 Azure Monitor 아래에서 Azure Monitor 작업 책을 찾을 수 있습니다. Applications Insight 인스턴스가 선택된 경우 Azure Portal에서 Azure Insights 문제 해결 가이드를 찾을 수 있습니다.

통합 문서 및 문제 해결 가이드를 페이지 만들기 인터페이스를 사용하여 만들 수 있는 "라이브 문서"라고 생각할 수 있습니다. 새 항목을 만들 때 페이지에 추가할 수 있습니다.

• 할 일 항목의 글머리 기호 목록 또는 페이지를 참조하는 사람에게 유용한 기타 정보와 같은 임의의 텍스트
• 다른 시스템에 대한 링크(예: 다른 대시보드 또는 설명서에 대한 링크)
• KQL(Kusto 쿼리 언어) 쿼리

문서를 "라이브"로 만드는 마지막 항목입니다. 이 학습 경로의 이전 모듈에서는 Log Analytics 및 Azure Monitor의 다른 부분에 기본 제공되는 KQL 쿼리 언어를 살펴보았다. 이 언어를 사용하여 애플리케이션 및 Azure 인프라에서 진단 정보를 반환하고 표시하는 자체 쿼리를 작성할 수 있습니다. KQL 쿼리를 통합 문서 또는 문제 해결 가이드에 삽입하면 해당 쿼리의 현재 결과가 문서 판독기에 실시간으로 표시됩니다. 즉, 문제 해결 가이드는 "웹 서버에서 오류 비율을 확인해야 합니다"라고 말할 수 있을 뿐만 아니라 지침 바로 옆에 해당 오류율에 대한 현재 그래프를 표시할 수도 있습니다. 첫 번째 응답자가 필요한 설명서로 바로 연결되는 "여기 웹 서버 다시 시작 설명서"와 같은 링크가 있을 수 있습니다.

또한 Azure는 사용자 고유의 문서 작성을 시작하는 데 도움이 되는 몇 가지 기존 템플릿을 제공합니다. 다음은 제공될 수 있는 미리 만들어진 템플릿의 스크린샷입니다.

통합 문서 및 문제 해결 가이드에 대한 고급 편집 기 기능을 사용하여 해당 문서의 JSON 또는 Azure Resource Manager 템플릿 표현에 액세스하고 삽입할 수 있습니다. 즉, 선택한 소스 제어 시스템을 사용하여 이러한 문서를 추적하고 배포할 수 있습니다. 또한 통합 문서 또는 문제 해결 가이드의 프로비저닝을 자동화할 수 있습니다. 이 가이드는 다른 인프라를 프로비전할 때 유용합니다. 서비스를 프로비전할 때 새 서비스와 함께 사용할 사용자 지정 문제 해결 문서 집합을 만드는 것은 이 모범 사례를 사용하기 쉬워집니다.

기타 유용한 팁 및 도구

이 모듈 전체에서 효율성을 높이고 인시던트 응답 시간을 줄이는 데 사용할 수 있는 다양한 도구와 바로 가기에 대해 알아보았습니다. 이 마지막 단원을 마무리하면서 시스템 내의 문제를 진단하는 데 도움이 되는 몇 가지 도구와 기술에 대한 간략한 개요를 살펴보겠습니다.

• Application Insights의 애플리케이션 대시보드 링크를 사용하여 시작점으로 필요한 대부분의 주요 항목이 있는 대시보드를 자동으로 생성할 수 있습니다. Azure Service Health는 포함되지 않습니다. 시스템 또는 클라우드 서비스 자체에 문제가 있는지 확인할 수 있도록 대시보드에 고정해야 합니다.
• Application Insights의 애플리케이션 맵을 사용하여 문제를 일으키는 원인을 정확히 파악할 수 있습니다. 빵 부스러기를 따라가면서 오류의 원인(예: 잘못된 URL)을 찾을 수 있습니다.
• Log Analytics를 사용하여 시스템의 모든 부분을 쿼리할 수 있습니다.

앞의 모든 도구는 문제를 해결하는 데 매우 중요합니다.