인시던트 추적

인시던트에는 수명 주기가 있습니다. 가장 효과적으로 대응하려면 해당 수명 주기의 시작 부분에서 인시던트 자체의 진화와 이에 대한 대응의 진화를 추적할 수 있어야 합니다.

알고 있는 내용 평가

특정 인시던트를 사용하여 인시던트 추적 절차를 평가하는 좋은 방법은 일련의 질문을 하는 것입니다.

• 이 문제에 대해 처음 알게 된 경우는 언제인가요? 인시던트에서 복구하는 데 걸리는 시간을 줄이는 것이 목표인 경우 문제를 인식하는 순간부터 정보 캡처를 시작해야 합니다.
• 이 문제에 대해 어떻게 알게 하셨나요? 모니터링 시스템에서 인시던트에 대해 경고했나요? 직접 또는 소셜 미디어에서 불평하는 고객으로부터 먼저 그것에 대해 들으셨습니까?
• 문제에 대해 알아내는 것이라면 가장 먼저 알 수 있습니까? 그렇다면 누가 알려야 합니까? 그렇지 않은 경우 문제를 알고 있는 다른 사람은 누구입니까?
• 다른 사람들이 알고 있다면, 그것에 대해 무엇을하고 있습니까? 모든 사람이 다른 사람이 그것을 조사하고 있다고 가정합니까, 아니면 누군가가 그것을 해결하기 위해 조치를 취하기 시작했는지?
• 얼마나 나쁜가요? 우리는 심각도나 영향에 대한 개념이 없을 수도 있으며, 문제가 실제로 얼마나 나쁜지, 누가 영향을 받는지 알아낼 곳이 없습니다.

아무것도 추적되지 않는 경우 대답하기 어려운 질문이 될 수 있습니다.

인시던트 정보를 추적할 위치 표준화

인시던트 목록(활성 또는 기타)과 해당 인시던트에 대한 모든 현재 정보를 유지하고 공유할 수 있는 많은 장소가 있습니다. Word 문서를 사용하는 공유 파일 영역만큼 간단하며 고도로 특수화된 인시던트 추적 소프트웨어 및 서비스만큼 복잡할 수 있습니다. 이러한 두 극단 사이에는 이 작업을 위해 서비스로 누를 수 있는 발권 및 작업 추적 시스템이 있습니다. 선택하는 시스템은 실제로 사용하는 방법보다 덜 중요합니다. 어떤 시스템을 사용하든 인시던트(엔지니어, 고객 지원, 관리, 홍보, 법률 등)와 전혀 관련이 있을 수 있는 모든 사용자는 시스템을 찾기 위해 어디로 가야 하는지, 인시던트를 발생시키는 방법 및 적절한 경우 데이터에 액세스하는 방법을 알아야 합니다. 인시던트 추적으로 실패하는 한 가지 확실한 방법은 지원되는 사용자가 필요할 때 시스템에 도착하는 방법("시스템에 대한 URL이 무엇이었습니까?")을 모르는 것입니다.

이 모듈에서는 예제 추적 시스템에 Azure DevOps의 작업 항목 기능을 사용합니다.

대화 브리지 만들기

이전 평가 섹션의 몇 가지 질문에 답변하고 인시던트 대응 프로세스를 시작하려면 인시던트에 대해 다른 사용자와 통신할 수 있는 방법이 있어야 합니다. 이상적으로는 전화 브리지도 작동하지만 대화를 위한 일종의 "팀 협업" 전자 매체가 될 것입니다. 전화 회의/전화 브리지는 인시던트 통신을 소급하여 검토하기가 어렵기 때문에 선호도가 낮습니다(따라서 앞에서 언급한 "Scribe" 역할).

어떤 매체를 선택하든 이 인시던트에 대한 논의로 엄격하게 제한되는 고유한 채널을 개척해야 합니다. 데이터를 가져와서 나중에 인시던트 후 검토에서 분석할 수 있어야 하므로 이 채널에서 관련 없는 토론을 유지하는 것이 중요합니다.

이 모듈에서는 Microsoft Teams를 인시던트 통신 방법으로 사용합니다.

인시던트 추적 시작 자동화

그래서, 우리가 지금까지 함께 넣어 조각을 검토 하자. 다음과 같은 사항이 있습니다.

• 통화 중인 사람들의 명단(및 해당 사용자에 대해 정의된 회전).
• 인시던트 작업 사용자에게 할당할 수 있는 역할입니다.
• 인시던트 선언 및 추적을 위한 특정 위치입니다.
• 해당 인시던트에서 작업하는 사람들이 해당 인시던트에 대해 통신할 수 있는 고유한 채널입니다.

이러한 모든 항목을 최대한 만들고 관리하는 작업을 자동화할 수 있고 자동화해야 합니다. 긴급한 문제가 발생하는 경우 인시던트를 발생시키고, 올바른 사람을 데려오고, 추적하는 데 필요한 모든 단계를 기억할 필요가 없습니다. 작업을 즉시 처리할 수 있도록 "이동" 단추를 누르기만 하면 됩니다.

Codeless 자동화에 Logic Apps 사용

초기 응답을 자동화하는 한 가지 방법은 작업, 비즈니스 프로세스 및 워크플로를 예약, 자동화 및 오케스트레이션하는 작업을 간소화할 수 있는 Logic Apps를 사용하는 것입니다.

Logic Apps는 통합 솔루션을 빌드하기 위한 Azure 클라우드 서비스입니다. 커넥터를 사용하여 자동화된 워크플로를 만듭니다. 트리거는 특정 이벤트가 발생하거나 데이터가 지정된 조건을 충족하는 경우 논리 앱을 시작합니다. 작업은 논리 앱 워크플로에서 수행되는 작업입니다.

이 예제에서는 인시던트 추적에 다음 논리 앱 커넥터를 사용합니다.

• 문제/인시던트를 만들고 추적하는 데 사용할 수 있는 Azure Boards(Azure DevOps의 일부).
• Azure Storage- 호출 중인 사용자에 대한 정보를 저장하고 검색하여 인시던트에 응답할 적절한 사람을 할당할 수 있습니다. 이 예제에서는 엔지니어 목록과 해당 호출 상태를 쉽게 저장할 수 있는 매우 간단한 "키-값" 저장소를 제공하므로 Azure Table Storage를 사용합니다.
• Microsoft Teams는 엔지니어링 팀이 특정 인시던트에 대해 통신할 때 실시간으로 엔지니어링 팀의 대화를 추적하는 새롭고 고유한 인시던트 채널을 만드는 데 사용할 수 있습니다. 이렇게 하면 나중에 인시던트 후 검토를 수행할 때 이벤트의 타임라인과 관련하여 상호 작용을 유지할 수 있습니다.

이제 이 모든 것을 논리 앱과 연결해 보겠습니다. 먼저 Logic Apps 디자이너에 표시된 대로 전체 앱을 살펴본 다음 단계별로 살펴보겠습니다.

첫 번째 단계는 언급한 HTTP 요청인 트리거를 처리하는 것입니다. 선언하려는 인시던트에 대한 정보가 포함된 JSON 페이로드를 포함하는 논리 앱에 대한 HTTP POST 요청이 이루어집니다. 해당 페이로드를 구문 분석하고 받은 승인을 다시 보냅니다.

이 정보를 사용하여 이 인시던트를 나타내는 Azure DevOps 조직에 새 작업 항목을 만듭니다.

그런 다음 인시던트에 대한 새 Teams 채널을 만듭니다.

채널이 만들어지면 잠시 전에 만든 작업 항목이 새 채널에 대한 링크로 업데이트됩니다. 이렇게 하면 모든 정보가 동일한 위치(작업 항목)에 유지되고 나중에 해당 채널을 보는 사람들이 해당 채널에 참가하려는 경우 어디로 가야 할지 알 수 있습니다.

이제 통화 중인 사람을 사진으로 가져올 때입니다. Azure Table Storage에서 호출 중인 것으로 나열된 엔지니어의 이메일 주소에 대한 조회를 수행합니다. 그러면 JSON 응답이 반환됩니다. 그런 다음 구문 분석합니다.

쿼리에서 목록을 반환하므로 다음 단계로 해당 목록의 각 항목을 반복해야 합니다. 각 사용자에게 작업 항목을 할당합니다(이제 인시던트 "소유자").

그런 다음, 마지막 단계로 채널에 가입하고 해당 인시던트에 대한 신뢰할 수 있는 정보가 저장되는 위치를 알고자 하는 사용자를 위해 작업 항목에 대한 포인터가 있는 메시지를 Teams 채널에 보냅니다.

이는 인시던트 추적 및 통신을 위한 메커니즘 설정을 자동화하는 방법의 한 예에 불과합니다. 다음 단원에서는 인시던트를 둘러싼 통신의 측면을 좀 더 자세히 살펴보겠습니다.