빠른 속도의 팀을 위한 인시던트 관리
인시던트 및 문제 관리의 변화하는 역할
지난 10년 동안 인시던트 관리에는 많은 변화가 일어났습니다.
ITIL 지침이 업데이트되고, IT 팀은 DevOps 및 SecOps와 책임을 공유하기 시작했습니다. 시스템이 점점 더 복잡해지면서 인시던트 관리 솔루션이 더욱 복잡해졌습니다. 또한 많은 기업에서 비난을 배제한 사후 검토와 성과를 측정하는 새로운 방법을 받아들이고 있습니다.
인시던트 관리가 계속 변화하고 발전함에 따라 인시던트 관리의 가까운 사촌뻘인 문제 관리, 그리고 그 두 관행 간의 관계도 마찬가지로 변화하고 발전합니다.
문제란 무엇이며 인시던트와 어떻게 다릅니까?
ITIL은 문제를 "하나 이상의 인시던트의 원인 또는 잠재적 원인"이라고 정의합니다.
또한 인시던트는 서비스 중단을 야기하는 계획되지 않은 단일 이벤트라고 정의합니다.
즉, 인시던트란 일반적으로 대기 중 직원이 최대한 빠르고 완벽하게 해결하기 위해 노력하는 나쁜 사건입니다. 그리고 문제란 이 사건의 근본 원인입니다.
문제는 단일 인시던트 또는 여러 인시던트를 유발할 수 있습니다. 또한 인시던트는 단일 문제 또는 때로는 여러 문제로 거슬러 올라갈 수 있습니다.
예를 들어, 2016년 델타항공에 1억 5천만 달러의 비용을 유발했던 5시간의 중단은 인시던트였습니다. 이 인시던트를 일으킨 문제는 운영 센터의 전력 손실이었고, 아마도 정전이 발생할 경우의 백업 계획이 마련되어 있지 않았을 것입니다.
마찬가지로, Apple에 약 2천 5백만 달러의 비용을 유발했던 12시간의 앱 스토어 중단도 인시던트였습니다. 그 뒤에 숨겨진 문제는 DNS 문제였습니다.
기술의 세계를 벗어나서 이 용어를 사용하자면, 편두통이 있어 병원을 방문하는 것은 인시던트입니다. 편두통의 원인, 즉 알레르기, 시력 문제 또는 스트레스는 문제에 해당합니다.
문제 관리와 인시던트 관리 비교
분명히 나타나듯이, 문제와 인시던트는 불가분의 관계가 있습니다. 하나는 다른 하나를 유발하며 팀은 두 가지 모두에 주의를 기울여야 합니다.
기존 IT 팀의 경우, 최신 ITIL 지침에 따르면 팀은 문제와 인시던트를 모두 관리하되 별도로 관리해야 합니다. 문제 관리는 인시던트를 예방하거나 그 영향을 줄이는 데 중점을 둔 관행이며, 인시던트 관리는 실시간으로 인시던트를 해결하는 데 중점을 둡니다.
ITIL 접근 방식의 이점은 문제 관리와 인시던트 관리 모두의 핵심 목표를 우선시한다는 것입니다. 이 지침은 아마도 이 두 가지를 똑같이 중요한 별도의 관행으로 만들어, IT 팀이 계속하여 화재의 근본 원인을 해결하지 않고 인시던트라는 화재를 끄려고 하는 흔한 문제를 피하려고 시도하는 것입니다.
인시던트 관리자의 주요 목표가 인시던트의 빠른 해결이고 문제 관리자의 기본 목표가 인시던트 예방인 경우, 이 역할을 결합하면 이 목표 중 하나(둘 다 조직에 필수적)가 다른 목표에 우선 순위를 양보하게 될 수 있습니다.
이 접근 방식의 단점은, 현실에서 아주 밀접하게 연결된 두 가지 관행을 분리하면 지식의 격차가 발생하고 인시던트 해결과 기본 원인으로 이어지는 근본 원인 분석 간의 커뮤니케이션이 중단될 수 있다는 것입니다.
DevOps와 문제 및 인시던트 관리의 변화하는 역할
늘 그렇듯이, 공동 작업 중심의 DevOps 움직임은 문제 및 인시던트 관리를 두 가지의 서로 다른 관행이 아니라 전체적인 관점에서 절반이 겹치는 것으로 간주하여, 기존 IT 사고의 경계를 흐릿하게 만들었습니다.
이 변화는 두 관행이 인시던트를 예방하고 해결한다는 동전의 양면이라는 사실뿐만 아니라 일반적으로 다음을 확인시켜주는 DevOps 접근 방식에서 비롯됩니다.
- 인시던트의 근본 원인은 두 개 이상인 경우가 많습니다
- 사후 검토는 비난을 배제하고 인시던트의 영향을 받는 팀을 참여시켜야 합니다
- 공동 작업은 지속적인 개선의 핵심입니다
문제 및 인시던트 관리가 겹치는 것은 "직접 구축하고 직접 운영"한다는 접근 방식을 향한 업계 전반의 변화와 관련이 있을 수도 있습니다. 시스템을 구축하는 팀은 해당 시스템 내에서 인시던트를 해결할 책임을 지게 되기 때문에, 같은 팀이 사후 검토를 실행하고, 인시던트의 근본 원인을 파악하기 위해 조사하고, 향후 인시던트의 영향을 예방하거나 줄이는 권장 사항을 제시하는 것이 합리적입니다.
여기서 문제와 인시던트 관리 사이를 이어주는 것은 비난을 배제한 사후 검토입니다. 일단 긴급성이 잦아들면 인시던트 관리자는 조사관으로 변하여 문제 관리 및 예방 과제를 맡습니다.
이 두 관행 간의 경계를 모호하게 만드는 DevOps 팀이 직면하게 될 주요 어려움은 덜 시급하지만 가치가 아주 높은 장기적인 목표를 가진 문제 관리가 인시던트 관리의 긴급성에 밀려 우선 순위가 낮아지지 않도록 하는 것입니다.
물론 인시던트 관리와 문제 관리를 통합하는 것은 말처럼 쉽지 않은 경우가 많지만 근본 원인을 찾고 해결하는 데 꼭 필요합니다. 인시던트 관리 솔루션인 Jira Service Management가 팀이 협업할 수 있는 유연성을 제공하는 방법을 알아보고, 컨텍스트를 기록하고 풍부한 타임라인을 만들면서 인시던트를 해결한 다음 이를 활용하여 팀이 문제를 더 효과적으로 관리할 수 있도록 지원하세요.