빠른 속도의 팀을 위한 ITSM
변경 관리에 대한 10개 주요 모범 사례
변경 관리는 프로세스가 무겁고 복잡하며 어려운 것으로 알려져 있지만, 사실 꼭 그럴 필요가 없습니다. IT 변경 관리가 제대로 실행되면 인시던트를 줄이는 동시에 프로세스를 애자일하게 유지하고 업무 중단을 최소화합니다.
이를 어떻게 달성할 수 있을까요? Atlassian은 조직에서 변경 관리를 시작하기 위한 10가지 모범 사례 목록을 작성했습니다.
1. 조직의 위험 허용 범위를 파악하고 그에 따라 계획 수립
위험과 속도의 균형을 맞추는 데 있어 변경 관리에는 모든 상황에 맞는 단 하나의 솔루션이란 없습니다. 모든 조직에는 고유한 문화, 위험 허용 범위 및 준수해야 할 규정 요구 사항이 있으며 각 조직은 이러한 고려 사항을 변경 관리 관행에 통합해야 합니다.
위험을 파악하는 것은 비즈니스의 규제 및 컴플라이언스 의무를 이해하는 것을 포함합니다. 규제가 시작되면 비즈니스에 손실이 발생하기 전까지 시스템이 얼마나 많은 가동 중지 시간을 버틸 수 있는지 또는 문제를 해결해야 할 경우 어떤 리소스가 필요한지에 대한 문제는 더 이상 중요하지 않습니다. 규제는 협상할 수 없는 일련의 규칙입니다. 특정 승인이 필요하며 직무를 분리하게 될 것입니다. SOX 및 GDPR과 같은 규정으로 인해 프로세스가 약간 느려지더라도 특정 활동을 협상할 수 없습니다.
좋은 소식은 이 계획이 정적일 필요는 없다는 것입니다. 더 많은 승인과 엄격한 워크플로를 요구하는 보수적인 접근 방식을 선택하는 회사는 시간이 지남에 따라 언제든지 계획을 다시 평가하여 위험 수준에 맞게 프로세스의 엄격 수준을 조정할 수 있습니다.
Jira Service Management를 사용하면 조직의 요구 사항에 맞게 승인 및 워크플로를 사용자 지정할 수 있습니다. 원하는 만큼 유연하거나 자동화된 프로세스를 만드세요. 위험이 낮은 프로세스는 더 자동화하고, 복잡한 프로세스는 승인을 통해 보호할 수도 있습니다.
2.데이터 기반 위험 평가를 사용하여 변경 관리 관행을 지속적으로 조정
메트릭 추적, 특히 변경과 인시던트 간의 연결을 추적하는 것은 변경 관행을 개선하는 데 중요한 기반입니다. 데이터는 추세를 강조하여 인시던트와 관련될 가능성이 가장 낮은 변경 관리 유형, 팀원 및 서비스를 보여줍니다. 이러한 정보를 통해 다양한 변경 요청에 대한 위험과 엄격 수준을 일치시킬 수 있습니다.
스마트 위험 평가는 더 많은 변경 요청을 덜 엄격한 승인 워크플로로 다운그레이드할 수 있음을 의미합니다. Gartner의 조정 가능한 변경 관리 프로세스에서 알 수 있듯이 조직은 점점 더 많은 일반 변경이 표준으로 분류되고 이어서 사전 승인 및 자동화되도록 할 수 있습니다.
아래에는 표준 변경을 새로운 일반 변경으로 만들기 위한 몇 가지 실용적인 단계가 정리되어 있습니다.
- 지난 몇 개월 동안의 변경 검토
- 가장 일반적인 변경은 무엇입니까?
- “표준 변경”은 어떤 변경입니까?
- 어떤 서비스에 영향을 미칩니까?
- 어떤 변경이 성공적이었습니까?
- 이러한 변경을 구현하는 데 평균적으로 얼마나 걸렸습니까?
- 개발 팀에서 요청한 변경은 무엇입니까?
- 자동화할 항목으로 3~5개의 표준 변경 선택
- 서비스 관리 소프트웨어의 표준 변경을 위한 셀프 서비스 요청 유형 구축
- 표준 변경 요청의 목적과 범위를 명확히 하는 텍스트 추가
- 변경되는 시스템, 애플리케이션 또는 서비스와 같은 중요한 필드 캡처
- 변경을 자동 승인하고 상태를 전환하며 직원에게 업데이트를 알리는 자동화 규칙 만들기
- 시간을 내어 이 새로운 기능에 대해 IT 직원과 개발 팀 교육 및 훈련
- 향후 몇 개월 동안 성능 모니터링
- 기존 서비스를 개선하기 위한 인사이트 확보
- 자동화할 추가 표준 변경 식별
팀의 이전 변경 관리 관행과 변경에 따른 위험을 평가한 후에 위험 평가 설명서를 한곳에 모아두면 유용하게 사용할 수 있습니다. 팀은 Jira Service Management의 Confluence 통합을 사용하여 변경 계획 문서에 있는 단일 정보 소스를 참조할 수 있습니다. 이 페이지에서 공동 작업자는 위험 평가 정보 외에도 변경 계획 템플릿을 추가할 수 있습니다.
3. 변경 관리를 최대한 간단하게 유지
추가적인 작업을 원하는 직원은 아무도 없습니다. 그래서 변경 관리는 골칫거리로 간주되는 경우가 많습니다. 변경 관리 관행은 종종 직원들에게 작업하고 싶지 않은 도구로 무언가를 문서화하고 한두 개의 추가 단계가 필요한 프로세스를 기다리도록 요청합니다. 또한 코드를 실시간으로 푸시해야 하는 개발자의 경우 이러한 추가 작업이 실제 업무에 방해가 된다고 느낄 수 있습니다. 이 단계에서 변경 계획 Confluence 페이지와 같은 중앙 집중식 정보 지점을 통해 팀 전체를 참여시켜 쉽게 문서화할 수 있습니다.
이러한 주요 문제에 대한 해답은 변경 관리 프로세스를 최대한 간단하게 만드는 것입니다. 승인을 가능한 한 최소한으로 유지하세요. 개발자가 여러 시스템에 동일한 정보를 입력할 필요가 없도록 원활하게 통합되는 기술 도구를 선택하고 가능한 모든 작업을 자동화하세요. Jira Service Management의 이러한 기능은 팀이 각자의 속도에 따라 각자의 방식으로 운영할 수 있는 유연성을 제공합니다.
프로세스를 더 간단하게 만들수록 팀을 더 쉽게 참여시키고 팀의 참여를 유지할 수 있습니다.
4. 기존 CAB 모델 재고
대부분의 기존 IT 조직에서 CAB(변경 자문 위원회)는 변경 요청의 기술적 영향 및 비즈니스 영향을 평가하는 임무를 맡고 있습니다. 기존 프로세스에서는 느린 릴리스 속도, 복잡한 프로세스, 때로는 커뮤니케이션 및 협업 부족과 같은 몇 가지 문제가 발생합니다. 그래서 최고의 성과를 거두는 팀은 CAB 모델을 재고하고 있습니다.
목표는 이러한 위원회가 IT 프로세스에 추가하는 가치를 유지하여 커뮤니케이션을 지원하고 변경의 필요성과 이러한 변경의 위험 간의 균형을 유지하면서 일반적인 CAB 프로세스를 보다 민첩하고 전략적으로 만드는 것입니다. 이것은 일반적으로 다음을 의미합니다.
- 가장 위험한 변경에 대해서만 CAB 승인 요청(덜 위험한 변경에 대한 관리는 동료 검토, 가상 체크리스트 및 자동화와 같은 검증된 도구 사용)
- CAB에 전략을 부여하고 팀이 프로세스 효율성 및 자동화를 통해 위험을 줄이고 변경 관리에 대한 작업량을 줄이는 관행을 개발하도록 지원
- 대면 회의를 기다리지 않고도 주요 변경 및 질문을 처리할 수 있도록 가상 형태의 실시간 CAB 도입
여기에서 핵심은 전략을 위한 변화입니다. 새로운 CAB는 게이트키퍼 역할을 하는 대신 변경을 가능하게 하며 병목 현상을 유발하는 대신 전략적 리소스가 됩니다. 코드 검토 및 자세한 기술 사항 검토는 동료 검토 및 코드의 오류를 포착하는 데 가장 적합한 직원들이 수행하며 CAB는 프로세스, 전략 및 지속적 배포 지원에 집중할 수 있게 됩니다.
5. 도구를 사용하여 프로세스 자동화 및 개선
6. 변경이 잘 진행되도록 소규모 릴리스를 점진적으로 배포
릴리스에 대한 레거시 접근 방식은 릴리스를 번들로 묶어 한 번에 제공하는 것이었습니다. 이러한 접근 방식은 주요 인시던트로 이어질 수 있으며 인시던트가 발생할 때 문제의 원인을 찾기가 어렵다는 사실을 잘 알고 있습니다. 규모가 더 작고 빈번한 릴리스는 잠재적 인시던트의 범위를 제한할 수 있습니다. 점진적 릴리스는 전체 배포 전에 안정성을 테스트하고 입증하기 위해 소규모 사용자 하위 집합에 카나리아 또는 기능 플래그를 배포합니다.
팀이 변경 일정에서 릴리스를 조정할 수 있는 경우, 제어되는 더 소규모의 릴리스를 구성하는 일이 더 쉬워집니다. 그러면 개발자는 충돌 영역이 발생하지 않도록 하거나 일시 중단 날짜를 파악할 수 있습니다. Jira Service Management 변경 관리 기능을 사용하면 팀에서는 이렇게 단편화된 릴리스를 실행하는 데 필요한 정보를 가지고 중앙 집중식 일정에 액세스할 수 있습니다.
7. ITIL을 엄격한 규칙이 아닌 가이드라인으로 취급
ITIL은 때때로 부당한 평가를 받으며 제한적이고 구식적인 방식으로 간주됩니다. 하지만 사실 ITIL은 DevOps 문화를 수용한 직원들을 포함하여 IT 팀에 많은 것을 제공합니다. 여기서 문제는 ITIL이 너무 엄격하다는 것이 아닙니다. 문제는 우리가 가이드라인에 접근하는 방식입니다.
ITIL을 엄격한 규칙으로 여기면 당연히 제한적으로 느껴질 것입니다. 반면 회사가 기반으로 삼을 일련의 기본 가이드라인으로 여기면 변경 관리 관행을 개발할 때 도움을 받을 수 있습니다.
이것은 모든 프레임워크와 문화적 접근 방식에 적용됩니다. ITIL, 린, DevOps, 애자일, CD 등 아무리 사랑받는 프레임워크도 모든 문제를 한 번에 해결할 수는 없습니다. 내부 문제를 해결하기 위해 팀 문화를 살펴봐야 할 때조차 프레임워크나 도구에만 기대는 경우가 너무 많습니다.
8. 협업에 우선 순위 두기
CAB에서 DevOps 그룹에 이르기까지 주요 팀은 협업, 열린 문화 및 실시간 업데이트를 수용하고 있습니다. 변경 관리는 팀 간 조정을 위해 존재합니다. 변경, 인시던트 및 문제는 둘 이상의 팀에 파급 효과를 가져옵니다. 이는 조직이 복잡해질수록 더욱 분명해집니다.
사일로에서는 좋은 변경 관리가 이루어질 수 없습니다. 보다 열린 협업을 장려하기 위해 노력하는 조직은 변경 관행을 개선할 가능성이 높습니다.
Jira Service Management의 모든 기능은 팀을 통합하여 목표를 더 빠르게 달성하는 데 맞춰져 있으며, 이 경우에는 인시던트 없이 변경 사항을 더 빠르게 적용하는 것입니다. 응집력 있고 속도가 빠른 팀의 메커니즘은 공동 작업입니다. Confluence와 같은 도구, 통합 채팅 및 화상 회의, 사용자 지정 가능한 워크플로를 갖춘 투명한 플랫폼을 통해 모두가 완전한 컨텍스트를 가진 상태로 참여하여 자신의 역할을 다할 수 있습니다.
9. 카오스 엔지니어링 및 복원력 엔지니어링 활용
카오스 엔지니어링은 제품 또는 서비스의 컴포넌트를 끊거나 차단하여 복원력을 테스트하는 데 중점을 둔 최근 관행입니다. 마찬가지로 복원력 엔지니어링은 시스템에서 발생할 수 있는 모든 스트레스 요인을 의도적으로 해결합니다. 예를 들어 사용자 수가 많거나 트래픽이 많은 시스템을 푸시합니다.
두 가지 관행 모두 향후 인시던트를 방지하기 위해 필요한 문제와 변경을 식별하기 위한 것입니다. 이러한 선제적 접근 방식은 변경 관리 팀에 많은 가치를 제공하며 인시던트 관리 팀의 시간, 예산 및 알림 피로를 크게 줄여줍니다.
10. 개발 팀에 익숙하고 수용되는 도구 선택
좋은 변경 관리 프로세스는 개발자가 사용하는 도구 전반에 걸쳐 구축되어야 합니다. 팀에 새로운 도구를 배우거나, 여러 도구에 정보를 입력하거나, 익숙하지 않고 불편한 도구를 다루도록 요청하면 채택 속도가 느려지는 경향이 있어 고객에게 중요한 업데이트를 제공하는 능력이 저하될 수 있습니다.
Atlassian에서는 Jira Service Management를 사용하여 변경 사항을 추적합니다. Jira 플랫폼을 사용하면 개발 팀과 운영 팀을 쉽게 통합할 수 있으므로 심지어 개발자가 코딩을 시작하기 전부터 변경 사항이 프로덕션에 배포되는 시점까지 투명성과 추적 가능한 컨텍스트를 제공할 수 있습니다.