인시던트 추적
인시던트에는 수명 주기가 있습니다. 가장 효과적으로 대응하려면 해당 수명 주기의 시작 부분에서 인시던트 자체의 진화와 이에 대한 대응의 진화를 추적할 수 있어야 합니다.
무엇을 알고 있는지 평가
특정 인시던트를 사용하여 인시던트 추적 절차를 평가하는 좋은 방법은 다음의 질문을 하는 것입니다.
- 문제를 언제 처음 알게 되었습니까? 인시던트를 복구하는 데 걸리는 시간을 줄이는 것이 목표인 경우 문제를 알게 되는 순간부터 정보 수집을 시작해야 합니다.
- 문제를 어떻게 발견했습니까? 모니터링 시스템에서 인시던트에 관해 경고했습니까? 직접 또는 소셜 미디어를 통해 불평하는 고객에게서 처음 들었습니까?
- 문제를 방금 발견한 경우 문제를 처음으로 알게 된 사람인가요? 그렇다면 누구에게 알려야 합니까? 그렇지 않다면 문제를 알고 있는 다른 사람이 있습니까?
- 다른 사람이 알고 있다면 문제와 관련해 어떤 작업(있는 경우)이 수행되고 있습니까? 모든 사람이 다른 사람이 확인하고 있다고 생각하고 있습니까? 아니면 누군가 해결하기 위한 작업을 시작했습니까?
- 얼마나 잘못되었습니까? 심각성이나 영향의 개념이 없을 수도 있고 문제가 실제로 얼마나 심각한지와 누가 영향을 받는지 확인할 방법이 없습니다.
아무것도 추적하지 않는 경우 대답하기 어려운 질문일 수 있습니다.
인시던트 정보를 추적할 위치 표준화
인시던트(활성 또는 기타) 목록과 해당 인시던트의 모든 최신 정보를 유지하고 공유할 수 있는 가능한 여러 장소가 있습니다. 이러한 위치는 Word 문서가 포함된 공유 파일 영역과 같이 단순할 수도 있고 매우 전문화된 인시던트 추적 소프트웨어 및 서비스와 같이 복잡할 수도 있습니다. 이 두 가지 극단 사이에는 이 작업을 위해 서비스를 이용할 수 있는 티켓팅 및 작업 추적 시스템이 있습니다. 어떤 시스템을 선택하느냐는 실제로 그것을 어떻게 사용하느냐보다 덜 중요합니다. 어떤 시스템을 사용하든 인시던트와 약간이라도 연관이 있을 수 있는 모든 사람(엔지니어, 고객 지원, 관리, 홍보, 법률 등)이 시스템을 찾을 수 있는 위치, 인시던트를 제기하는 방법 및 해당하는 경우 데이터에 액세스하는 방법을 알고 있어야 합니다. 인시던트 추적에 실패하는 확실한 방법 하나는 시스템에서 지원할 사람이 필요할 때 시스템을 이용하는 방법을 모르게 하는 것입니다(“시스템의 URL이 뭐라고 하셨나요?”).
이 모듈에서는 예제 추적 시스템으로 Azure DevOps의 작업 항목 기능을 사용합니다.
대화 브리지 만들기
무엇을 알고 있는지 평가 섹션에 있는 질문에 답하고 인시던트 대응 프로세스를 시작하기 위해서는 인시던트에 관해 다른 사람과 소통하는 방법이 있어야 합니다. 이 방법으로 전화 브리지도 사용할 수 있지만 대화를 위한 일정의 "팀 협업" 전자 미디어가 가장 좋습니다. 인시던트 통신을 소급해서 검토하기가 더 어렵기 때문 전화 회의/전화 브리지는 덜 선호됩니다. 이런 이유로 앞에서 설명한 “서기” 역할이 필요합니다.
어떤 미디어를 선택하든 이 인시던트에 대한 논의만으로 엄격히 제한되는 고유한 채널을 개설해야 합니다. 관련이 없는 논의를 이 채널로 들이지 않는 것이 중요한데, 나중에 인시던트 사후 검토에서 이 데이터를 가져와 분석할 수 있어야 하기 때문입니다.
이 모듈에서는 Microsoft Teams를 인시던트 통신 방법으로 사용합니다.
인시던트 추적 시작 자동화
지금까지 맞춘 조각을 검토해 보겠습니다. 준비된 조각은 다음과 같습니다.
- 대기 중인 사람의 명단(및 이들에 대해 정한 교대).
- 인시던트를 담당하는 사람에게 할당할 수 있는 역할.
- 인시던트를 선언하고 추적할 특정 장소.
- 해당 인시던트를 담당하는 사람이 관련된 통신에 사용할 고유한 채널.
이러한 모든 항목의 만들기와 관리를 최대한 자동화할 수 있고 자동화해야 합니다. 긴급한 문제가 발생했을 때 인시던트 제기하고 적절한 사람을 투입하고 추적하기 위해 필요한 모든 단계를 기억할 필요가 없어야 합니다. “이동” 단추를 누르면 문제를 처리하는 작업이 즉시 시작될 수 있어야 합니다.
코드 없는 자동화를 위해 Logic Apps 사용
초기 대응을 자동화하는 한 가지 방법은 작업, 비즈니스 프로세스 및 워크플로를 예약, 자동화 및 오케스트레이션하는 작업을 간소화할 수 있는 Logic Apps를 사용하는 것입니다.
Logic Apps는 통합 솔루션을 빌드하기 위한 Azure 클라우드 서비스입니다. 이 서비스는 ‘커넥터’를 사용하여 자동 워크플로를 만듭니다. 트리거는 특정 이벤트가 발생하거나 데이터가 지정된 조건에 맞으면 논리 앱을 시작합니다. ‘작업’은 그런 다음 논리 앱 워크플로에서 수행되는 작업입니다.
여기의 예제에서는 인시던트 추적을 위해 다음 논리 앱 커넥터를 사용합니다.
- Azure Boards(Azure DevOps의 일부) - 문제/인시던트를 만들고 추적하는 데 사용할 수 있습니다.
- Azure Storage - 인시던트에 대응할 적절한 인원을 할당할 수 있도록 대기 중인 사람에 관한 정보를 저장하고 검색할 수 있습니다. 이 예에서는 엔지니어 목록과 대기 상태를 쉽게 저장할 수 있는 매우 간단한 "키-값" 스토리지를 제공하는 Azure Table Storage를 사용합니다.
- Microsoft Teams: 새롭고 고유한 인시던트 채널을 만들어 엔지니어링 Teams가 특정 인시던트에 관해 소통할 때 실시간으로 대화를 추적하는 데 사용할 수 있습니다. 이를 통해 나중에 인시던트 사후 검토를 수행할 때 이벤트 타임라인과 관련된 상호 작용을 보존할 수 있습니다.
이제 이 모두를 논리 앱과 연결해 보겠습니다. 먼저 Logic Apps 디자이너에 표시된 전체 앱을 살펴본 후 단계별로 살펴보겠습니다.
첫 번째 단계는 앞서 언급한 HTTP 요청인 트리거를 처리하는 것입니다. HTTP POST 요청은 논리 앱에 하며, 선언하려는 인시던트에 관한 정보가 있는 JSON 페이로드를 포함합니다. 해당 페이로드를 구문 분석하고 받았다는 확인을 다시 보냅니다.
이 정보를 사용하여 Azure DevOps 조직에서 이 인시던트를 나타내는 새 작업 항목을 만듭니다.
그런 다음 인시던트를 위한 새 팀 채널을 만듭니다.
채널이 만들어지면 조금 전에 만든 작업 항목이 새 채널에 대한 링크로 업데이트됩니다. 따라서 모든 정보가 같은 위치(작업 항목)에 유지되고 나중에 사람들이 이 정보를 보고 해당 채널에 참여하려는 경우 어디로 가야 할지 알 수 있습니다.
이제 대기 중인 사람을 참여시킬 시간입니다. 대기 중인 것으로 표시된 엔지니어의 이메일 주소를 Azure Table Storage에서 조회합니다. 그런 다음 반환되는 JSON 대응을 구문 분석합니다.
쿼리에서 목록이 반환되므로, 다음 단계로 해당 목록의 각 항목을 반복해야 합니다. 각 사람에게 작업 항목을 할당합니다(이제 이 사람들은 인시던트의 “소유자”임).
마지막 단계로, 채널에 참여하고 해당 인시던트의 신뢰할 수 있는 정보가 저장된 위치를 알고 싶어 하는 사람을 위해 작업 항목에 대한 포인터가 포함된 메시지를 Teams 채널로 보냅니다.
이는 인시던트 추적 및 커뮤니케이션을 위한 메커니즘 설정을 자동화할 수 있는 방법의 한 예일 뿐입니다. 다음 단원에서는 인시던트 관련 통신의 측면을 좀 더 자세히 살펴보겠습니다.