빠른 속도의 팀을 위한 인시던트 관리
DevOps 시대의 인시던트 관리
인시던트 관리 팀에 비난을 배제한 열린 커뮤니케이션의 원칙 적용
인시던트에 대응하는 방법을 재검토하지 않고는 소프트웨어를 구축, 배포 및 운영하는 방법을 재검토할 수 없습니다.
2009년의 중요한 강연인 “하루에 10건 이상의 배포: Flickr에서 개발 팀 및 운영 팀의 공동 작업"에서, John Allspaw 및 Paul Hammond는 개발자와 IT 운영 팀이 협력하고 자주 제공하는 세상에 대한 비전을 구상했습니다. 그후 10년 동안 이 비전은 DevOps 움직임이라는 형태를 갖췄습니다.
DevOps의 특성은 인시던트에 대응하는 새로운 방식에 의존합니다. Allspaw와 Hammond의 강연에서 인시던트 관리가 이렇게 많은 관심을 받은 것은 놀라운 일이 아닙니다.
Hammond는 "깨달아야 할 중요한 사실은, 실패는 일어나기 마련이라는 것입니다."라고 강연에서 말하며 "일어날지 말지가 아니라, 언제 일어날지에 대한 문제입니다."라고 덧붙였습니다.
ITIL과 같은 프레임워크와는 달리, DevOps 팀을 위한 모범 사례의 '공식적인' 문서는 없습니다. 그러나 일반적으로 DevOps의 핵심은 조직의 사일로를 허물고, 투명성을 높이며 개발자와 IT 운영 팀 간의 열린 커뮤니케이션을 촉진하여 조직에 비즈니스 가치를 제공하는 데 있다는 점에는 모두가 동의합니다.
투명성, 가시성 및 신속한 학습이라는 똑같은 문화가 인시던트 관리까지 확장됩니다.
왜 그럴까요? 인시던트 관리의 첫 번째이자 가장 중요한 단계는 어떤 문제가 발생했는지 이해하고, 문제 해결을 위해 적절한 담당자를 할당하고, 비난을 배제한 문화를 조성하는 것입니다.
DevOps 인시던트 관리에는 개발자와 IT 운영 팀 간의 비난을 배제한 열린 커뮤니케이션의 문화가 필요합니다. 또한 IT 서비스의 신뢰성을 개선하고 고객 만족도를 높이며 비즈니스 가치를 창출하는 간단한 프로세스도 구축해야 합니다. DevOps 엔지니어는 DevOps 문화와 사례를 실천하는 데 도움을 줄 수 있습니다.
이에 비해, ITIL은 IT 서비스 관리의 특정 관행을 개선하도록 고안된 26개의 프로세스, 절차, 작업 및 체크리스트로 이루어져 있는 규정된 집합입니다. ITIL은 서비스 품질과 일관성, 시스템의 복원력 향상에 중점을 둡니다.
ITIL의 이점은, ITSM을 개선하려는 조직이 처음부터 시작하는 대신 템플릿 형식의 모범 사례를 사용하여 시작할 수 있다는 것입니다. ITIL이 대기업에 가장 적합하다고 생각할 수도 있지만, 이 프레임워크는 더 작은 규모의 기업 역시 비즈니스에 적합한 프로세스를 선택하면서도 가치를 찾을 수 있을 정도로 유연합니다.
ITIL의 한 가지 단점은, 인시던트 대응 프로세스를 급하게 변경해야 하는 경우 공식적인 변경 관리와 전문 컨설턴트가 참여하여 개선이 지연될 수 있다는 것입니다.
바로 시작하려는 팀의 경우 DevOps 인시던트 관리 접근 방식을 통해 하나로 모여 즉시 이점을 실현할 수 있습니다.