IT 지원 워크플로를 개선하는 방법
DevOps 및 ITIL 비교 - 팀에 중요한 것은 무엇입니까?
IT 업계에서는 DevOps와 ITIL에 대해 다양한 의견이 있으며, 이러한 의견은 두 가지 IT 접근 방식을 서로 대립시키는 경향이 있습니다. 대부분의 경우 ITIL 쪽이나 DevOps 쪽을 듭니다. 흑백논리이자 양자택일의 상황으로, 한 쪽을 선택해야 합니다.
이 토론은 기술 소식 매체에서 흥미로운 읽을거리가 되지만, 이런 이분법적인 접근 방식은 비용이 많이 들고 혼란스러우며 실행자와 비즈니스에 도움이 되지 않을 수 있습니다. 왜냐하면 이는 이분법적인 것이 아니며 굳이 한 쪽을 선택할 필요가 없기 때문입니다.
DevOps와 ITIL은 상호 배타적인 것이 아닙니다. 이 둘은 상호 보완적인 접근 방식이 될 수 있으며 접근 방식마다 각자의 이점을 제공합니다. 애질리티와 협업, 프로세스와 제어와 같은 혼합된 접근 방식에서는 두 가지의 이점을 모두 활용할 수 있습니다.
DevOps란?
DevOps는 개발과 운영 간의 격차를 해소하는 관행으로, 핵심 원칙은 열린 커뮤니케이션, 협업 및 공동의 목표입니다.
"ITIL과 같은 프레임워크와는 달리, DevOps 팀을 위한 모범 사례의 '공식적인' 문서는 없습니다. 그러나 일반적으로 DevOps의 핵심은 조직의 사일로를 허물고, 투명성을 높이며 개발자와 IT 운영 팀 간의 열린 커뮤니케이션을 촉진하여 조직에 비즈니스 가치를 제공하는 데 있다는 점에는 모두가 동의합니다."
ITIL이란 무엇입니까?
DevOps 및 ITIL에 대한 오해
1. DevOps는 ITIL을 대체할 수 있다
"우리는 더 이상 ITIL을 따르지 않습니다. 이제 DevOps 매장이 되었습니다!” 기간에 관계없이 기술 분야에서 일한 적이 있다면 누군가 이렇게 선언하는 것을 들어 봤을 것입니다.
문제는, 이것이 사실이 아니라는 점입니다. 왜냐하면 IT 부서는 ITIL 교육 및 프로세스 사일로에서 벗어날 수 있지만 여전히 서비스 관리의 일부 측면을 수행해야 하기 때문입니다. 운영, 지원, 거버넌스, 비용, 이는 필수 비즈니스 기능이며 DevOps는 ITIL과 같은 방식으로 프로세스 가이드라인을 제공하지 않으므로, DevOps만 사용한다고 주장하는 매장이라도 여전히 일부 ITIL 프로세스 또는 원칙을 따르고 있을 가능성이 높습니다.
2. DevOps = 지속적인 개발, 통합 및 자동화된 제공
DevOps에는 지속적인 개발, 통합 및 자동화된 제공이 포함되지만, 이것이 전부는 아니며 이 관행의 핵심은 아닙니다. DevOps의 컨텍스트와 정신의 대부분은 단순히 오래된 분열에서 벗어나 상호 존중을 갖춘 비난 없는 문화에서 협력하는 것입니다.
그게 전부입니다. 협업, 공동의 목표, 상호 존중, 그리고 더 이상 비난하지 않는 것입니다.
협업 중심의 접근 방식은 팀이 아직 자동화된 제공이나 지속적 개발을 완전히 수용하지 못했더라도 모든 방식의 비즈니스 메트릭을 개선할 수 있습니다.
3. ITIL/ITSM은 팀의 속도를 늦추는 번거로운 프로세스 때문에 항상 문서 작업이 많이 필요하다
ITIL은 해석의 여지가 있는 가이드가 아니라 "규칙"으로 잘못 사용되는 사례가 너무 많습니다.
사실 ITIL은 팀이 만드는 것입니다. 엄격하다고 생각된다면, 그 과정 어딘가에서 엄격한 선택을 한 것입니다. 그리고 그 선택은 바꿀 수 있습니다.
ITIL은 대부분의 비즈니스가 관리해야 하는 복잡한 IT 프로세스를 이해하기 위한 출발점이라고 가장 잘 알려져 있습니다. 로드맵이자 안내 책자입니다. ITIL은 유일한 방법이 아니라, 의사 결정을 내리고 IT 팀을 가능한 한 효과적이며 효율적으로 운영하는 데 필요한 컨텍스트를 제공하기 위한 것입니다.
ITIL이 규칙서처럼 취급되면 일반적으로 문서가 쌓이는 현상과 관료주의가 뒤따릅니다. 그러나 ITIL을 가이드라인으로 사용하면 운영을 방해하는 일 없이 간소화할 수 있습니다.
4. ITIL/ITSM은 대기업에서만 사용한다
대기업이 ITIL 분야를 주도한 것은 사실입니다. 그렇다고 중소기업이 ITIL 가이드라인의 이점을 누리지 않거나 누릴 수 없다는 의미는 아닙니다. 모든 규모의 비즈니스는 ITIL이 토대를 마련하는 다른 기본적인 비즈니스 작업 중에서도 변경 관리, 주요 인시던트 및 지식 관리를 처리하는 방법을 알아야 합니다.
훌륭한 스타트업 회사는 어느 시점에서는 IT 팀을 조직해야 하며, 그렇게 하지 않으면 규모를 확장하는 데 실패합니다. 중소기업도 마찬가지입니다. 자체적으로 자금을 마련하는 2인 앱 프로젝트라도 대기 중 계획과 인시던트 관리 전략이 필요합니다. 그렇지 않으면 한 번의 서비스 중단으로 인해 없어져 버릴 수 있습니다.
DevOps 및 ITIL 사용 사례
DevOps와 ITIL의 사용 사례는 무궁무진하지만, 이 둘을 통해 해결할 수 있는 몇 가지 다양한 이슈와 최적의 솔루션에 도달하기 위해 두 가지 접근 방식이 모두 필요한 경우의 예시는 다음과 같습니다.
DevOps로 새 릴리스 속도 향상
DevOps의 애자일 접근 방식은 속도와 위험 관리 측면의 이점을 모두 제공합니다. 소규모의 정기적인 릴리스는 개발 과정을 더 빠르게 진행할 수 있고 인시던트 발생 시 롤백하거나 수정하기가 더 쉽기 때문입니다.
ITSM으로 IT 서비스 데스크 요청 감소
지식 관리의 ITSM 모범 사례에서 IT 팀은 문제를 해결하는 동시에 설명서를 만듭니다. 이를 통해 내부 및 외부 고객에게 셀프 서비스 옵션을 제공하여 서비스 데스크의 워크로드를 크게 줄일 수 있습니다.
ITIL 및 DevOps로 인시던트 방지
ITIL의 검증된 인시던트 관리 프로세스를 검토 프로세스의 자동화, 비난을 배제한 사후 검토, "직접 구축하고 직접 운영"한다는 접근 방식에 중점을 둔 DevOps와 결합하면 인시던트를 줄이는 방법을 얻게 됩니다.
DevOps를 통해 인시던트 완전히 파악
DevOps가 제공하는 가장 가치 있는 것 중 하나는 비난 없는 문화입니다. 그렇다고 해서 엔지니어가 실수에 대해 책임을 지지 않는다는 의미가 아니며, 이러한 실수에 대해 솔직하게 이야기하고, 무엇이 잘못되었는지에 대해 더 투명한 대화를 나누고, 해고를 당할 염려 없이 대화할 수 있다는 것을 의미합니다.
이러한 문화적 변화는 팀이 인시던트로 이어지는 일련의 이벤트에서 한 개인을 문제로 삼는 대신, 인시던트를 더 빠르게 완전히 파악하고 실제 해결 방법에 집중할 수 있도록 도와줍니다.
ITIL로 고객 혼란 감소
SLA(서비스 수준 계약)는 ITIL 모범 사례입니다. 제품에서, 또는 고객에게 무엇을 약속했고 약속하지 않았는지를 간략하게 설명하므로, 혼란과 불만 사항을 줄이는 데 도움이 될 수 있습니다.
DevOps 및 ITIL을 통한 프로세스 최적화
ITIL은 IT 프로세스의 성경과도 같습니다. 오랜 시간 동안 있어 왔으며 끊임없이 변화하는 업계의 요구에 맞게 진화했습니다.
자체 프로세스를 만들 때 완전히 처음부터 시작할 필요가 없습니다. ITIL은 검증된 출발점을 제공합니다.
DevOps가 비난을 배제한 사후 검토, 자동화, 더 협업 중심의 접근 방식 등을 통해 개선 사항을 추가할 수 있는 경우, ITIL의 프로세스를 조정하여 더 나은 프로세스를 구축할 수 있습니다.
DevOps 및 ITIL 사용 사례
최고의 성과를 내는 팀이 이미 알고 있듯이 IT 팀에는 ITIL과 DevOps의 요소가 모두 필요합니다.
DevOps는 자동화된 개발 그 이상으로, 협업이자 비난 없는 문화입니다. 팀이 경쟁 목표를 위해 사일로 속에서 일하는 것이 아니라 함께 최선을 다할 수 있는 공간을 마련하는 관행입니다.
마찬가지로, ITIL은 설명서 이상의 역할을 합니다. ITIL은 팀의 속도를 늦추거나 불필요한 관료주의로 인한 골칫거리를 만들 필요가 없습니다. 핵심 관행은 타당하고 입증되었으며, 애자일 방식으로 접근하면 IT 파이프라인을 막는 것이 아니라 간소화할 수 있습니다.