인시던트 추적

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

알고 있는 내용 평가

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

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

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

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

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

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

대화 브리지 만들기

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

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

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

인시던트 추적 시작 자동화

그래서 우리가 지금까지 모아온 조각들을 검토하자. 다음과 같은 사항이 있습니다.

• 대기 중인 사람들의 명단(그리고 그들에 대해 정의된 순환 근무).
• 인시던트에서 작업하는 사람들에게 할당할 수 있는 역할입니다.
• 사고를 선언하고 이를 추적할 특정 장소입니다.
• 해당 인시던트에서 작업하는 사람들이 해당 인시던트에 대해 통신할 수 있는 고유한 채널입니다.

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

코드 없는 자동화를 위해 Logic Apps 사용

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

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

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

• Azure DevOps- Azure Boards 인시던트 작업 항목을 만들고 추적하는 데 사용할 수 있습니다.
• Azure Table Storage- 호출 중인 사용자에 대한 정보를 저장하고 검색하여 적절한 사용자에게 인시던트에 응답하도록 알릴 수 있습니다. 이 예제에서는 호출 중인 명단 데이터에 대한 간단한 스키마 없는 키/특성 저장소로 사용합니다.
• Microsoft Teams- 엔지니어링 팀이 특정 인시던트에 대해 통신할 때 실시간으로 엔지니어링 팀의 대화를 추적하는 새롭고 고유한 인시던트 채널을 만드는 데 사용할 수 있습니다. 이렇게 하면 나중에 인시던트 후 검토를 수행할 때 이벤트의 타임라인과 관련하여 상호 작용을 유지할 수 있습니다.

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

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

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

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

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

이제 통화 중인 사람을 사진으로 가져올 때입니다. 현재 대기 중인 엔지니어를 식별하는 명단 항목에 대한 Azure Table Storage 쿼리합니다. 그러면 JSON 응답이 반환됩니다. 그런 다음 구문 분석합니다.

쿼리에서 목록을 반환할 수 있으므로 일치하는 각 항목을 다음 단계로 반복해야 합니다. 프로덕션 워크플로에서 해당 데이터를 사용하여 기본 인시던트 소유자 및 모든 백업을 식별합니다. 기본 응답자는 Azure DevOps 작업 항목에 할당할 수 있으며, 연결된 작업, 메모 또는 알림을 통해 추가 응답자를 추적할 수 있습니다.

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

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