빠른 속도의 팀을 위한 인시던트 관리
인시던트 관리 KPI 및 메트릭을 선택하는 방법
시간 경과에 따른 인시던트 관리 추적 및 개선
오늘날의 상시 가동 서비스가 제공되는 세상에서, 기술 인시던트는 심각한 결과를 초래합니다.
시스템 가동 중지 시간은 회사에 시간당 평균 30만 달러의 수익 손실, 직원 생산성, 유지 관리 비용을 초래합니다. 대규모 서비스 중단의 경우 그 비용을 훨씬 뛰어넘을 수 있습니다(델타항공은 2017년 IT 서비스 중단 후 약 1억 5천만 달러의 손실을 입음). 그리고 청구서 비용을 지불할 수 없거나, 중요한 회의에서 화상 회의에 접속할 수 없거나, 비행기 표를 구입할 수 없는 고객은 빠르게 경쟁업체로 옮겨갈 수 있습니다.
많은 것을 잃을 위험이 있는 상황에서, 팀이 인시던트 관리 KPI를 추적하고 그 결과를 바탕으로 인시던트를 감지, 진단, 해결하고 궁극적으로는 방지하는 일이 그 어느 때보다 중요합니다.
좋은 소식은 (기계 및 오프라인 시스템과는 달리) 웹 및 소프트웨어 인시던트의 경우 팀에서는 보통 더 많은 데이터를 캡처하여 이해와 개선에 도움이 될 수 있다는 것입니다.
나쁜 소식은 데이터가 너무 많으면 때로는 이슈를 밝혀내는 것이 아니라 이슈를 모호하게 만들 수 있습니다.
인시던트 KPI, 메트릭, 분석의 가치
KPI(핵심 성과 지표)는 비즈니스가 특정 목표를 달성하고 있는지 판단하는 데 도움이 되는 메트릭입니다. 인시던트 관리의 경우, 이러한 메트릭은 인시던트의 수, 평균 해결 시간 또는 인시던트 사이의 평균 시간이 될 수 있습니다.
인시던트 관리에 대한 KPI를 추적하면 프로세스와 시스템의 문제를 파악 및 진단하고, 팀이 노력할 벤치마크와 현실적인 목표를 설정하고, 더 큰 질문에 대한 출발점을 제공할 수 있습니다.
예를 들어, 비즈니스 목표는 모든 인시던트를 30분 이내에 해결하는 것인데 팀에서는 현재 평균 45분이 걸린다고 가정해 보겠습니다. 구체적인 메트릭이 없다면 문제가 무엇인지 파악하기 어렵습니다. 알림 시스템이 너무 오래 걸립니까? 프로세스가 중단되었습니까? 진단 도구를 업데이트해야 합니까? 팀 문제입니까, 아니면 기술 문제입니까?
이제 몇 가지 메트릭을 추가하세요. 알림 시스템이 정확히 얼마나 오래 걸리는지 파악하면 알림 시스템을 문제로 식별하거나 문제가 아닌 것으로 배제할 수 있습니다. 시간의 50% 이상이 진단에 사용되면 이 부분에 대한 문제 해결에 집중할 수 있습니다. B 팀이 A, C, D 팀보다 시간이 25% 더 많이 걸린다는 사실을 알게 되면 그 이유를 자세히 살펴볼 수 있습니다.
KPI가 자동으로 문제를 해결해 주지는 않지만, 문제가 어디에서 발생했는지 파악하고 알맞은 부분을 더 심층적으로 살펴보는 데 집중할 수 있도록 합니다.
가장 많이 사용되는 인시던트 KPI 및 메트릭
만들어진 알림
알림 도구를 사용하는 경우 특정 기간에 얼마나 많은 알림이 생성되는지 알면 도움이 됩니다. Jira Service Management와 같은 솔루션을 사용하면 알림을 보내고 보고서와 대시보드를 만들어서 이를 추적할 수 있습니다.
수치가 평소와 다르게 상당히 증가 또는 하락하거나 상승 추세를 보이는 기간을 관찰하고, 그 기간을 보면서 왜 그런 변화가 일어나는지, 그리고 팀이 어떻게 대응하는지 더 심층적으로 살펴보세요.
시간 경과에 따른 인시던트
시간의 경과에 따른 인시던트 추적이란 시간 경과에 따른 평균 인시던트 수를 확인하는 것을 의미합니다. 주간, 월간, 분기별, 연도별, 심지어는 일일 인시던트 수일 수도 있습니다.
시간이 지남에 따라 인시던트가 더 자주 발생합니까, 덜 발생합니까? 인시던트의 수가 받아들일 수 있는 정도입니까, 아니면 줄여야 합니까? 인시던트 횟수에 대한 문제가 발견되면 인시던트가 왜 상승 추세를 보이거나 계속 높게 유지되고 있는지, 그리고 팀이 이슈 해결을 위해 무엇을 할 수 있는지에 대한 질문을 시작할 수 있습니다.
MTBF
MTBF(평균 장애 간격)는 기술 제품에 발생하는 수리 가능한 장애 사이의 평균 시간입니다. 제품 전반의 가용성과 안정성을 추적하는 데 도움이 될 수 있습니다.
다른 메트릭과 마찬가지로, 더 큰 질문을 위한 좋은 시작점이 됩니다. MTBF가 원하는 수치보다 낮으면 시스템에 장애가 자주 발생하는 이유와 향후 장애 발생을 줄이거나 방지할 수 있는 방법에 대해 질문해야 합니다.
MTTA
MTTA(평균 확인 시간)는 시스템 알림이 전송된 후 팀원이 인시던트를 확인하고 해결을 시작할 때까지 걸리는 평균 시간입니다. 여기서의 가치는 이슈에 대한 팀의 대응성을 파악하는 것입니다.
대응성에 문제가 있다는 것을 알게 되면 다시 심층적으로 살펴볼 수 있습니다. MTTA가 왜 높습니까? 팀의 업무 부담이 지나치게 높습니까? 방해를 받고 있습니까? 알림을 누가 담당해야 하는지 명확하지 않습니까? MTTA는 문제를 찾아내는 데 도움이 되며, 이러한 질문을 통해 문제의 핵심에 도달할 수 있습니다.
MTTD
MTTD(평균 감지 시간)는 팀이 이슈를 발견하는 데 걸리는 평균 시간입니다. 이 용어는 사이버 보안 분야에서 팀이 공격 및 침해 감지에 집중할 때 자주 사용됩니다.
이 메트릭이 급격하게 변경되거나 목표치를 달성하지 못한다면 다시 한번 그 이유를 살펴볼 때입니다.
MTTR
MTTR은 수리, 해결, 대응 또는 복구에 걸리는 평균 시간을 나타냅니다. 이 메트릭 중에서 가장 유용한 것은 평균 해결 시간으로, 이는 즉각적인 문제를 진단하고 해결하는 데 소요되는 시간뿐만 아니라 이슈가 다시 발생하지 않도록 하는 데 소요되는 시간도 추적합니다. 복구는 DevOps 연구 및 평가(DORA)에서 DevOps 팀의 안정성을 측정하는 데 핵심 사항이라고 언급한 주요 DevOps 메트릭입니다.
다시 강조하자면, 이 메트릭은 진단을 위해 사용할 때 가장 효과적입니다. 해결 시간이 원하는 만큼 빠르고 효율적입니까? 그렇지 않다면 해결 시간이 어떻게, 그리고 왜 목표치를 달성하지 못하는지에 대해 더 심층적으로 질문해야 합니다.
복구는 DevOps 연구 및 평가(DORA)에서 언급한 것과 같이, DevOps 팀의 안정성을 측정하는 데 사용할 수 있는 주요 DevOps 메트릭입니다. 문제를 감지하고, 완화하고, 해결하는 데 걸리는 총 시간입니다.
대기 근무 시간
대기 중 교대 근무를 시행하는 경우 직원 및 계약업체가 대기 근무에 할애하는 시간을 추적하면 도움이 될 수 있습니다.이 메트릭을 사용하면 직원이나 팀이 과도한 부담을 받지 않도록 할 수 있습니다.
Jira Service Management를 사용하면 포괄적인 보고서를 생성하여 이 수치를 한눈에 볼 수 있습니다.
sla
SLA(서비스 수준 계약)는 가동 시간, 대응 및 책임과 같은 측정 가능한 메트릭에 대한 공급자와 고객 간의 계약입니다.
SLA에서 한 약속(가동 시간, 평균 복구 시간 등)은 인시던트 관리 팀이 이러한 메트릭을 추적해야 하는 이유 중 하나입니다. 평균 대응 시간 또는 평균 장애 간격과 같은 수치가 변경되면 빠르게 계약을 업데이트하거나 수정이 이루어져야 합니다.
SLO
SLO(서비스 수준 목표)는 가동 시간과 같은 특정 메트릭에 대한 SLA 내의 계약입니다. SLA와 마찬가지로 SLO는 회사가 고객 서비스 측면에서 책임을 다하고 있는지 확인하기 위해 추적해야 하는 중요한 메트릭입니다.
타임스탬프(또는 타임라인)
타임스탬프는 인시던트 전후 및 그 도중의 특정 시간에 일어난 일에 대한 정보를 인코딩한 것입니다. 보통 메트릭으로 간주되지는 않지만, 인시던트 관리 상태를 평가하고 개선 전략을 세울 때 필요한 중요한 데이터입니다.
타임스탬프는 팀에서 리드업 및 대응 노력과 함께 인시던트의 타임라인을 구축하는 데 도움이 됩니다. 인시던트 사후 검토 중에 가장 유용한 아티팩트 중 하나는 분명하고 공유된 타임라인입니다.
연속운영시간
가동 시간은 시스템을 사용할 수 있고 가동되는 시간(백분율로 표시)입니다.
온라인 서비스의 연결성이 높아지고 시스템 자체가 복잡해지면서, 보통 가동 시간이 100% 보장되지는 않습니다. 대다수 제품의 목표는 고가용성으로, 시스템이나 제품을 오랜 기간 동안 중단 없이 운영하는 것입니다. 업계 표준에 따르면 99.9%의 가동 시간은 아주 좋은 수준이며 99.99%는 뛰어난 것입니다.
이 메트릭으로 성공을 추적하는 경우, 고객과의 약속을 하고 지키는 것이 중요합니다. 그리고 다른 메트릭과 마찬가지로 시작점에 불과합니다. 가동 시간이 99.99%에 미치지 못한다면 그 이유를 알아보기 위해서는 더 많은 연구, 팀과의 대화, 그리고 프로세스, 구조, 액세스 또는 기술에 대한 조사가 필요합니다.
인시던트 분석에 대한 주의 사항
KPI의 단점은 얕은 데이터에 너무 의존하게 되기 쉽다는 것입니다. 팀의 인시던트 해결 속도가 충분히 빠르지 않다는 사실을 아는 것 자체로는 문제를 해결할 수 없습니다. 왜냐하면 팀이 이슈를 어떻게, 그리고 왜 해결하거나 해결하지 못하는지도 알아야 하기 때문입니다. 또한 비교하는 여러 이슈가 실질적으로 비교 가능한지도 알아야 합니다.
KPI는 팀이 까다로운 이슈에 어떻게 접근해야 하는지 알려주지 못합니다. 인시던트 사이의 시간이 왜 길어지는 것이 아니라 짧아졌는지, 그리고 인시던트 A가 왜 인시던트 B보다 3배 더 오래 걸렸는지는 설명하지 못합니다.
그러한 질문에 답하려면 인사이트가 필요합니다. 데이터는 인사이트를 확보하기 위한 출발점이 될 수도, 걸림돌이 될 수도 있습니다. 데이터로 인해, 메트릭이 개선되지 않더라도 충분히 열심히 하고 있는 것처럼 느껴질 수 있습니다. 또한 실제로는 서로와 아주 큰 차이가 있으며 다른 방식으로 접근해야 하는 여러 인시던트를 하나로 묶어버릴 수 있습니다. 팀의 경험과 인시던트 자체의 근본적인 복잡성을 간과할 수도 있습니다.
“인시던트는 상식적으로 생각하는 것보다 훨씬 더 고유합니다. 기간이 같은 2개의 인시던트라도, 어떤 일이 발생했는지 이해할 때의 놀라움과 불확실성의 수준은 상당히 다를 수 있습니다. 상황을 완화 또는 개선하기 위한 조치를 취하는 데 있어서 각각 다른 위험이 내재되어 있을 수도 있습니다. 인시던트는 물리적 크기의 제한적인 변화가 품질의 주요 지표로 간주되는, 제작되는 위젯이 아닙니다.”
- John Allspaw, Moving Past Shallow Incident Data
여기서 중요한 점은 KPI가 나쁘다는 게 아닙니다. 나쁜 것은 버리되 중요한 것은 유지해야 합니다. 요점은 KPI만으로는 충분하지 않다는 것입니다. KPI는 시작점, 진단 도구이자 진정한 개선을 위해 조금 더 복잡한 길로 나아가는 첫 번째 단계입니다.
Jira Service Management는 팀이 KPI를 추적하고 인시던트 관리 관행을 모니터링 및 최적화할 수 있도록 보고 기능을 제공합니다.