IT 인시던트 관리, 대응, 방지의 미래

5년 전으로 되돌아가서 IT 팀에 누가 인시던트 관리를 담당했는지 물어보면 거의 항상 "저희 IT 팀이요"라고 대답했을 것입니다.

지금 똑같은 질문을 한다면 IT 팀뿐만 아니라 DevOps, SecOps 및 아키텍처 팀도 자신의 팀에서 관리한다고 답할 것입니다. 많은 조직이 “직접 구축하고 직접 운영”한다는 개념으로 서서히 전환하고 있습니다.

이 접근 방식의 분명한 이점은 코드에 가장 익숙한 직원들이 책임을 맡게 되므로 IT 팀의 부담이 줄어들고 대응 시간이 단축된다는 것입니다. 따라서 가동 중지 시간이 최소화되고 팀 생산성은 최대화됩니다. 또한 훌륭한 코드를 작성하도록 유도하는 좋은 방법이기도 합니다. (오전 3시에 일어나 버그를 해결해야 하는 담당자라면, 다음에는 오전 3시에 또 호출을 받지 않도록 코드를 제공할 때 두 번, 세 번 확인할 가능성이 높습니다.)

이 접근 방식의 어려움은, 그래도 조직에는 어느 정도의 중앙 집중화가 필요하다는 것입니다. 경영진은 보고서와 문서에 액세스할 수 있어야 합니다. 비즈니스 이해 관계자는 업데이트를 원합니다. 이들은 평균 해결 시간 및 평균 확인 시간과 같은 인시던트 메트릭을 확인하려고 합니다. 명확한 인시던트 업데이트, 인시던트 사후 검토 보고서 및 수정 작업을 기대합니다.

분산을 향해 나아가고 있으며 잘 해내고 있는 많은 기업의 경우, 이 어려움에 대한 해답은 분산 및 팀 자율성을 통해 인시던트 해결을 민첩하게 유지하고 정보를 중앙 집중식으로 처리하여 비즈니스를 계속 유지하는 기술입니다.

워크플로를 중단시키고 예기치 않은 결과를 초래할 수 있는 다른 큰 변화와 마찬가지로, 많은 조직이 천천히 분산하는 것은 합리적인 결정입니다.

조직에서는 먼저 이와 같은 변화에 문화적으로 적합하고 위험이 낮은 애플리케이션 또는 제품을 관리하는 팀을 파악하는 것에서 시작합니다. 그런 다음, 팀의 특정 애플리케이션 또는 제품에 대한 인시던트 관리를 해당 팀으로 이동합니다. 팀을 교육하고, 대기 일정을 구현하고, 시간 경과에 따른 진행률을 추적하여 다음과 같은 질문을 합니다.

• 복구 시간이 개선되었는가?
• 팀이 어떤 문화적 장벽에 부딪혔는가?
• IT 팀이 어떤 도구를 마련해야 했는가?
• 커뮤니케이션을 위해 어떤 프로세스가 필요했는가?
• 그 팀에서 더 나은 시스템 업데이트가 제공되고 있는가?
• 인시던트 수가 감소했는가?
• 분산을 다른 팀에 적용하기로 하는 경우, 초기의 시험적인 실행으로부터 어떤 점을 얻을 수 있는가?

이러한 테스트 사례는 회사 전체에 “직접 구축하고 직접 지원”하는 프레임워크를 구현할지 여부, 그리고 구현하는 경우 팀 전체에 효과적으로 배포하는 방법을 결정하기 위한 토대를 마련해 줍니다.

분산을 향한 움직임은 교차 팀 공동 작업이 필요함을 의미합니다. DevOps 팀이 인시던트 관리에 관여하는 경우 DevOps 팀은 IT 인시던트 관리 프로세스 회의에 참석해야 합니다. IT 팀이 여전히 인시던트 관리 관행을 이끄는 데 지원하는 경우 다른 팀의 사후 검토에 참여해야 합니다.

각 팀은 인시던트 관리에 각자의 장점을 발휘합니다. IT 팀은 관행과 문서를 개발하고 가이드라인을 따르는 데 능숙합니다. DevOps 팀은 변화와 학습에 능숙하며, SecOps 팀은 보안 관점을 제공할 수 있습니다.

팀 간에 더 많은 공동 작업을 촉진하기 위해, 이것이 잘 이루어지는 회사는 공개적으로 정보를 공유하고, 팀 간에 공감하는 분위기를 조성하며, 팀 간의 비난을 없애고, 채팅을 사용하여 인시던트 중에 팀을 연결하고, 모두가 참여할 수 있는 인시던트 검토를 우선시하고 있습니다.

ITIL 가이드라인에서 일반적으로 인시던트 관리는 인시던트 방지와는 별도의 관행으로 간주됩니다. 둘 다 ITSM의 중요한 요소지만 동시에 이루어지는 경우는 많지 않습니다.

이 접근 방식의 문제점은 인시던트 관리가 대응적인 상태로 유지된다는 것입니다. 대기 중 직원은 불을 끄는 임무를 맡고 있으며, 불이 꺼지면 다음 불을 끄러 갑니다. 머릿속의 유일한 목표는 복구, 즉 시스템을 다시 가동하는 것입니다.

하지만 복구가 전부는 아닙니다. 시간이 지나면서 더 많은 IT 팀에서 이러한 사실을 깨닫고 받아들이고 있으며, 방지를 인시던트 관리 프로세스에 포함시키고 성과를 판단하는 데 평균 복구 시간 대신 평균 해결 시간과 같은 메트릭을 사용하고 있습니다.

이 접근 방식을 종종 문제 관리라고 하며, 그 목표는 여러 프로세스를 서로 더 가깝게 만드는 것입니다. 팀이 단순히 하나의 화재에 대응한 다음 다른 화재로 넘어가는 것이 아니라 인시던트에 대응하고, 복구하고, 학습하여 눈앞의 문제뿐 아니라 관리 중인 더 큰 제품 및 서비스 시스템 모두에 배운 점을 적용하는 것입니다.

많은 엔터프라이즈 IT 조직은 문제 관리를 위한 전담 관행을 갖추고 있으며 일반적으로 그 관행을 각 팀을 위한 별도의 프로세스로 취급합니다. Atlassian은 한 단계 더 나아가서 IT 운영 팀과 개발자 팀이 문제 관리 관행을 인시던트 관행에 포함시키는 혼합된 접근 방식을 사용하는 것을 지지합니다. 이렇게 하면 인시던트 전반에 걸쳐 더 나은 가시성을 제공하고, 인시던트가 실제로 발생하고 오래 지나지 않아 인시던트 분석이 이루어지도록 할 수 있습니다.

왜냐하면 장기적으로는 인시던트에 신속하게 대응하는 것보다 인시던트를 방지함으로써 얻을 수 있는 가치가 더 크기 때문입니다.

인시던트 관리에서 교차 팀 공동 작업이 이루어지는 방향으로의 변화에 내재된 어려움 중 하나는, 어떤 팀은 프로세스 및 문서화에 대해 다른 팀보다 느긋해 한다는 점입니다.

다른 팀이 자체 제품을 관리하는 경우에도 IT 팀이 감독 및 중요한 가치를 제공할 수 있는 부분 중 하나입니다. 확고한 계획 없이는 아무도 오전 3시에 잠이 덜 깬 눈으로 주요 인시던트를 맡고 싶어 하지는 않기 때문입니다.

팀을 인시던트 관리 프로세스에 포함시킬 때, IT 팀은 그 계획을 결정짓는 핵심적인 질문에 답하는 데 도움을 줄 수 있습니다. 예를 들면 다음과 같습니다.

• 어떤 인시던트 대응을 갖추고 있는가?
• 어떤 가치를 따르는가?
• 인시던트 발생 시 어떻게 대응할 것인가?
• 팀이 지원하는 중요한 시스템에 필요한 정보는 어디에 있는가? 여러 시스템에 있는 경우, 정보를 통합하여 대기 중 전문가가 정보에 쉽게 액세스할 수 있도록 하려면 어떻게 해야 하는가?
• 프로세스와 문서가 공동 작업을 중심으로 이루어지며 팀에서 검토할 수 있는가?

분산, 공동 작업, 인시던트 및 문제 관리를 혼합하는 방식으로의 변화를 위해서는 단순히 책임을 다시 분배하고 IT 전문가를 DevOps 사후 검토에 참여시키는 것 이상의 노력이 필요합니다. 여기서 성공의 열쇠는 기술이나 프로세스에 달려 있는 것이 아니라, 변화를 지원하는 내부 문화를 조성하는 데 달려 있습니다.

대다수의 회사에서 이 과정을 건너뛰려고 하지만 이는 성공적인 전환을 위한 토대입니다. 그렇다면 분산되고 공동 작업을 중심으로 하며 미래 지향적인 인시던트 관리를 지원하는 문화는 어떤 문화일까요?

Atlassian에서 생각하는 핵심 구성 요소는 다음과 같습니다.