IT 지원 워크플로를 개선하는 방법
IT 지원을 DevOps 방식으로 실행하는 방법
DevOps 원칙을 IT 서비스 및 엔지니어링 팀에 도입하면 서비스 품질, 팀 사기, 문제 해결 및 비즈니스 생산성을 크게 향상하는 것으로 입증되었습니다. 실제로 DevOps 원칙을 채택한 기업은 평균적으로 고객 만족도가 45% 향상되고, 직원 생산성이 43% 증가하고, 디플렉션 비율이 41% 개선되며, IT 관련 비용이 38% 감소했다고 보고했습니다.
이와 같은 통계를 고려할 때 DevOps 원칙을 IT 서비스 관리에 통합하는 것은 기업에 큰 이익입니다. 하지만 팀에는 복잡한 변화처럼 들릴 수도 있습니다. 사실은 생각하는 것처럼 복잡하지는 않습니다. 더 높은 성과를 제공하는 서비스의 핵심은 놀랄 만큼 매우 간단합니다.
DevOps란?
그렇다면 DevOps란 정확히 무엇입니까? DevOps는 개발 및 운영이라는 오랜 상충의 역사를 가진 자주 사일로되는 두 팀을 하나로 모으는 일련의 관행입니다. 목표는 공동 작업 및 열린 커뮤니케이션이며 두 부서가 각자의 목표를 달성할 수 있는 방법을 찾는 것입니다.
Atlassian의 파트너는 "DevOps란 소프트웨어 개발 팀과 IT 팀이 더 빠르고 안정적으로 소프트웨어를 빌드, 테스트 및 릴리스할 수 있도록 두 팀 간의 프로세스를 자동화하는 일련의 관행입니다. DevOps의 개념은 지금까지 상대적으로 사일로된 환경에서 일해 온 팀 간에 공동 작업 문화를 구축하는 것입니다. 신뢰도를 향상하고 소프트웨어 릴리스 속도를 높이고 중요한 이슈를 빠르게 해결하며 미리 계획되지 않은 업무를 더 잘 관리하기와 같은 이점을 약속합니다."라고 설명합니다.
IT 지원에 DevOps가 필요한 이유는?
비즈니스 관점에서 숫자가 그 이유를 설명합니다. 고객 만족도를 45% 향상하고, 직원 생산성이 43% 증가합니다. IT 관련 비용은 38% 감소합니다. DevOps 운동이 비즈니스 수익에 의미 있는 방식으로 도움이 되었습니다. 이것이 바로 5개 기업 중 4개가 적어도 몇 가지 DevOps 원칙을 적용하고 있다고 하는 이유일 것입니다.
DevOps는 팀 자체에도 필요성이 있을 뿐만 아니라 잘 수행하면 직원과 팀의 만족도, 공동 작업 및 인지도를 향상합니다. 매끄럽지 않은 프로세스를 원활하게 하고 작업 속도를 높이며 IT, 개발 및 기타 상호 연관된 팀 전체에 오랫동안 긴장을 일으켰던 관료주의를 제거합니다.
예전에는 운영 팀이 전혀 알지 못하고 지원할 준비가 되지 않은 새로운 릴리스 때문에 좌절감을 느꼈지만(Gartner에 따르면 인시던트의 85~87%의 원인), DevOps는 커뮤니케이션 라인을 열고 향후 상황에 대비한 IT 운영팀을 준비합니다. 예전에는 개발 팀이 롤아웃 속도를 늦추는 운영 지연으로 인해 불만을 느꼈지만, 이제 팀은 SLA 약속 및 SLO 목표를 위험에 빠뜨리지 않는 더 빠른 롤아웃을 위해 협력할 수 있습니다.
IT 서비스에 대한 DevOps: 모범 사례
문화적 변화 우선 순위 지정
DevOps 통합의 가장 큰 과제는 문화적 변화입니다.
기존의 IT 조직은 사일로화된 경우가 많으며, 개발 팀은 별도의 에코시스템 내에서 작업하고, 변경이 시작되면 시스템 변경이 발생하기 전에 종종 경고가 거의 또는 전혀 없이 운영 팀이 작업을 대신합니다.
반면 DevOps 조직은 해커톤, 스탠드업, 채팅방과 같은 도구와 관행을 통해 공동 작업과 팀 간 커뮤니케이션의 우선 순위를 둡니다.
이 변화를 수용한다는 것은 팀 간 커뮤니케이션과 공동 성공을 우선시하는 새로운 도구, 새로운 프로세스 및 새로운 문화적 관점을 수용한다는 것을 의미합니다.
가능한 부분을 자동화
DevOps의 생산성 향상은 적어도 부분적으로 자동화를 우선시하는 철학 덕분입니다. DevOps를 수용한다는 것은 팀이 지속적으로 자동화할 수 있는 부분은 어디인지 질문하도록 유도하는 것을 의미합니다.
일반적인 오류에 대한 코드 검토를 자동화할 수 있습니까? 문제, 인시던트 및 요청을 트리거했을 수 있는 변경 또는 릴리스에 이들을 연결하도록 시스템을 자동화할 수 있습니까? 보안 또는 법적 요구 사항을 충족하지 않는 코드를 릴리스하지 않도록 확인 및 균형을 자동화할 수 있습니까? SLO 목표에 너무 가까워졌을 때 시스템을 자동화하여 새 릴리스를 동결할 수 있습니까?
DevOps 메트릭을 자동화하고 개선하는 방법에는 많은 방법이 있습니다. 가장 일반적인 세 가지 방법은 다음과 같습니다.
- 워크플로(예: 서비스 데스크를 통해 지원 티켓을 더 빠르게 이동)
- 지식(인시던트가 발생하면 서비스 관리 도구가 관련 지식 및 설명서를 자동으로 표시해야 함)
- 에스컬레이션(조직에 문제를 해결할 수 있는 팀원이 두 명뿐인 경우, 스마트한 시스템은 엄격한 선형 에스컬레이션 경로를 따르지 않고 바로 문제를 이들에게 에스컬레이션해야 함)
중요한 메트릭 추적
개발 및 IT 운영이 협업하면서 좋은 관행에 따라 상황이 어떻게 진행되고 있는지도 추적해야 합니다.
일반적인 DevOps 핵심 성과 지표(KPI)에는 평균 장애 간격(MTBF), 평균 복구, 수리, 응답 또는 해결 시간(MTTR), 평균 장애까지 시간(MTTF) 및 평균 확인 시간(MTTA)이 포함됩니다. 또한 많은 회사에서는 특정 기간에 생성된 경고 또는 요청 수, 가동 중지 분당 비용 또는 통화/요청당 지원 비용과 같은 수치에 의존하고 있습니다.
팀이 추적해야 하는 메트릭은 팀 자체, SLA 계약에서 고객에게 한 약속, 조직과 합의한 SLO 목표 및 목표로 삼고 있는 특정 문제 지점에 따라 다릅니다. 메트릭이 움직이는 목표라는 점을 깨닫는 것도 중요합니다. IT가 지원하는 제품에서 이해 관계자의 요구 사항, 외부 법률 또는 보안 의무에 이르기까지 회사 내에서 상황이 변화하면서 추적하는 메트릭과 추적 방법도 전환해야 할 수 있습니다.
공유에 우선 순위를 두기
DevOps는 작성 및 유지 관리와 작성자 및 지원자 간의 격차를 해소하는 것입니다. 공유하는 보기, 목표, 프로세스 및 어휘를 만드는 것입니다. 지식과 커뮤니케이션을 공유하는 것입니다. 공유 도구 집합, 리소스 및 코드베이스에 관한 것입니다. 아마도 가장 중요한 것은 공유 소유권에 관한 것입니다. 즉, 공동 책임과 공동 성공을 의미합니다.
많은 기존 조직의 경우 DevOps로 전환한다는 것은 공동 책임과 성공을 정의, 보상 및 추적하는 방법을 다시 생각한다는 것을 의미합니다. 개발 및 운영 팀의 목표가 상충됩니까? 한 팀의 성공이 다른 팀의 성공을 더 어렵게 만듭니까?
예를 들어 개발 팀이 가능한 한 빨리 새로운 기능을 배포해야 하고 IT 운영 팀이 가동 시간을 유지해야 하는 경우, 두 가지 목표는 서로에게 부정적인 영향을 줄 수 있습니다. 운영 팀은 가동 시간 목표를 초과하기 위해 개발자의 속도를 늦추고, 개발 팀은 배포 목표를 달성하지 못하게 하는 운영 팀에 불만을 느낄 수 있습니다.
많은 DevOps 팀을 위한 솔루션은 가동 시간이 SLO 목표 내에 있는 한 개발 팀이 원하는 만큼 릴리스할 수 있는 SRE 접근 방식입니다. 가동 시간이 허용 불가능한 수준으로 떨어지면 팀이 함께 작업하여 가동 시간을 원래 상태로 되돌릴 때까지 모든 릴리스를 중단합니다.
ITIL 및 DevOps 비교
ITIL을 따른다면 DevOps가 어디에 해당하는지 궁금할 것입니다. 많은 회사에서 ITIL 및 DevOps 관행이 함께 작동할 수 있습니다. 실제로 Atlassian은 많은 회사가 이 둘의 장점과 강점을 모두 수용하는 것을 확인하고 있습니다.
DevOps와 ITIL을 비교하는 이 문서에서는 "둘 다 필요합니다. 우리는 경쟁이 아니라 상호 보완적인 것에 대해 이야기하고 있습니다. 더 스마트하고 빠르게 작업할 수 있어야 하지만 프로세스와 제어도 여전히 필요합니다. 최근의 성과가 높은 팀과 조직은 이것을 인식하고 두 가지 요소를 모두 사용하기 시작했습니다. 이들은 둘 중 하나 또는 극한을 넘어섰습니다."라고 설명합니다.
ITIL은 운영, 지원, 거버넌스 및 기타 핵심 비즈니스 기능에 대한 모범 사례를 다루는 경향이 있습니다. DevOps는 지속적 배포, 비난을 배제하는 문화, 공동 작업 도구, ITIL 가이드라인에 오랫동안 구축된 관행을 기반으로 만들어지고 그러한 관행을 강화하는 애자일 관행과 같은 것을 제공합니다.
DevOps 지향 조직을 위한 도구
DevOps 접근 방식을 채택한다는 것은 커뮤니케이션, 자동화 및 팀 간 공동 작업을 위한 새로운 도구를 수용한다는 의미일 수도 있습니다.
새로운 도구를 평가할 때는 다음과 같은 질문을 하는 것이 중요합니다.
- 이 도구가 현재 환경에서 작동하고 기존 도구와 통합됩니까?
- 요구 사항에 부합합니까?
- 모든 새 도구가 포괄적이고 유기적인 도구 집합에서 함께 작동합니까?
물론 우리 자신에 대한 평가이지만, Atlassian에서는 IT 서비스 관리에는 Jira Service Management를 , 소프트웨어 개발에는 Jira Software를, 코드 리포지토리에는 Bitbucket을 사용합니다.
이 도구가 잘 작동하는 이유는 함께 잘 작동하기 때문입니다. 또한 팀 구조 내의 사일로에서 벗어날 때 어떤 도구를 선택하더라도 사일로에서 벗어나야 합니다.
The Total Economic Impact™ Of Atlassian For ITSM
The Total Economic Impact™ of Atlassian Jira Service Management. The report includes cost savings and business benefits enabled by Jira Service Management.
백서 읽기Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
백서 읽기