Close

더 나은 인시던트 관리를 위한 길은 여기에서 시작됩니다

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

과거에는 기술 인시던트에 대응하는 임무를 맡은 팀은 거의 항상 IT 팀이었습니다. Network Operations Centers(NOC)에 있는 팀이 시스템을 모니터링하고 서비스 중단에 대응하는 경우가 많았습니다. 소프트웨어를 구축한 것은 공급업체지만, 배포 및 운영은 고객의 IT 운영 팀의 몫이었습니다. 오늘날 클라우드 서비스가 확산되면서 공급업체는 소프트웨어를 구축하고 배포 및 운영도 하게 되었습니다.

그러나 인시던트 관리는 여전히 핵심 ITSM 관행으로 남아 있습니다. 또한 IT 팀은 가이드라인을 개발하고 예산을 관리하며 주요 인시던트를 진단, 해결, 문서화 및 방지하는 부담을 모두 오랜 시간 감수해 왔습니다.

물론 기술 분야의 모든 것과 마찬가지로 과거를 통해 항상 미래를 예측할 수 있는 것은 아니며, 현재 인시던트 관리 관행은 변화를 맞이하고 있습니다. DevOps, SecOps 및 아키텍처 팀의 참여도가 높아지고 있고, 새로운 기술과 상호 연결된 제품으로 인해 인시던트 관리 방식이 바뀌었습니다. 그리고 이러한 변화에 맞추기 위해 사고 방식, 관행 및 팀 구조가 변화하고 있습니다.

그렇다면 인시던트 관리는 어떻게 변화하고 있으며 역할, 제품, 프로세스 및 팀의 미래에 어떤 영향을 줄까요?

분산을 향한 움직임

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에서 생각하는 핵심 구성 요소는 다음과 같습니다.

열린 태도 및 정보 공유

다른 팀이 하는 일에 대해 알지 못하고 액세스할 수 없다면 팀은 더 나은 커뮤니케이션, 프로세스 및 제품으로 이어지는 깨달음의 순간을 가질 기회를 잃게 됩니다.

고객 중심의 사고 방식

“고객에게 가장 좋은 것은 무엇인가?”와 같은 질문을 할 때, 생각해낸 답은 현재의 관행과 일치하지 않는 경우가 있습니다. 궁극적으로 고객을 위해 제품을 개선하는 커뮤니케이션, 프로세스 및 구조적 효율성을 향해 나아가려면 의도적으로 고객에게 초점을 맞춰야 합니다.

정기적인 상태 점검

각 팀의 상황은 어떠한가? 개별 팀원들은 어떻게 생각하는가? 팀은 어떤 부분을 개선할 수 있는가? 정말 잘 하고 있는 부분은 무엇인가? Atlassian에는 팀의 상태를 확인하고 새로운 업무 방식을 소개하는 데 도움이 되는 팀 플레이북이 있습니다.

공감

DevOps가 IT 팀을 탓하고 IT 팀이 DevOps의 느긋한 접근 방식에 대해 불만을 가진다면 공동 작업이 제대로 이루어질 수 없습니다. 팀이 소통하고 혁신하며 효과적으로 협업하기를 바란다면 팀 간에 공감과 연결을 이뤄야 합니다.

권한 부여

팀은 문제를 빠르게 해결하고 가능할 때마다 독립적으로 의사 결정을 내릴 수 있는 권한을 부여받아야 합니다. 그런 팀 내의 개인은 팀에서의 위치나 경력에 관계없이 질문, 제안 또는 우려 사항이 있는 경우 의견을 말할 수 있는 권한을 부여받았다고 느껴야 합니다.

경력이 더 많은 선임 개발자가 담당한 코드인 경우에도, 후임 개발자가 회의에서 손을 들어 문제를 제기할 수 있다고 느끼면 혁신적인 새로운 아이디어가 나오고, 프로세스가 개선되고 버그가 코드에 들어가기 전에 잡아내게 된다는 장점이 있습니다.