빠른 속도의 팀을 위한 인시던트 관리
'직접 구축하고 직접 운영'한다는 관행이 기대치에 부응하고 있습니까?
'직접 구축하고 직접 운영'한다는 관행을 시행한 지 13년이 지났습니다. 약속을 이행했습니까?
13년 전, 인터뷰에서 소프트웨어 배포 및 운영에 대한 새로운 외침이 울린 후 전 세계의 IT 프로세스는 완전히 바뀌었습니다. 오늘날에는 그 어느 때보다 많은 기업이 DevOps의 공동 작업 중심의 접근 방식과 여기에 일반적으로 뒤따르는 “직접 구축하고 직접 운영”한다는 사고 방식을 받아들이고 있습니다. 하지만 10년 넘게 변화를 겪은 현재, 이 개념이 아직 유효합니까? 약속한 효과가 나타났습니까?
변화의 역사
이 모든 것은 2006년 Amazon의 CTO인 Werner Vogels와의 인터뷰에서 시작되었습니다.
"개발자에게 운영 책임을 부여하여 고객 및 기술 관점 모두에서 서비스 품질이 대폭 향상되었습니다. 기존 모델에서는 개발 팀과 운영 팀 사이를 구분하는 벽이 있어 소프트웨어를 넘긴 다음 잊어버렸지만, Amazon에서는 그렇지 않습니다. 직접 빌드하고 운영한다는 관행을 통해 개발자는 매일같이 소프트웨어의 운영 및 고객과의 접점을 가질 수 있습니다. 이 고객 피드백 루프는 서비스 품질을 개선하는 데 꼭 필요합니다."
그래서 "직접 빌드하고 운영"한다는 관행이 시작되었습니다. 빌드하는 관계자와 지원하는 관계자 사이의 벽을 허무는 것이 가장 중요했던, 뒤이어 떠오른 공동 작업 중심의 DevOps 움직임과 잘 어울리는 새로운 업무 방식입니다.
아이디어가 시작되었고 그럴만한 이유가 있습니다. 개발 팀과 운영 팀 간의 격차를 해소하면 큰 효과가 있습니다. 인시던트가 발생했을 때 코드를 작성한 팀(제품에 대해 잘 알고 있는 팀)이 슈퍼히어로가 되지 못할 이유는 없습니다. 이 관행은 해결 시간을 단축할 뿐만 아니라 개발자가 고객 피드백과 실시간으로 발생하는 문제에 더 가까이 다가가도록 하여 상시 서비스를 지원할 수 있습니다.
명확한 이점... 그리고 명확한 어려움
모든 프로세스 변화와 마찬가지로, 이 이점에는 일련의 어려움과 전통적인 구조를 갖춘 비즈니스의 많은 저항이 뒤따랐습니다.
이점으로는 IT 팀의 부담 감소, 프로덕션 준비가 된 설계, 더 빠른 응답 시간 및 더 철저하게 테스트된 코드 등이 있습니다. 결국 버그 해결을 위해 오전 1시에 호출을 받는 경우라면 다음 번 배포를 다시 확인할 가능성이 높겠죠. 또한 개발자에게 새로운 기술을 배우고 비즈니스에 대해 새로운 방식으로 생각하는 임무를 주어 더 뛰어나고 균형 잡힌 개발자가 되도록 해주었습니다.
코드에 대한 책임은 계속하여 같은 팀에 있기 때문에 이 접근 방식은 인시던트 예방에도 긍정적인 영향을 줍니다. 한 보고서에 따르면 배포 전에 외부 팀에서 코드를 검토한 회사는 코드 검토가 전혀 없는 회사와 동일한 성공률을 보였습니다. 반면 제품을 이미 알고 있는 개발자가 동료 검토를 하는 경우 인시던트 예방에 긍정적인 영향을 미쳤습니다.
저희 팀은 인시던트 관리에 대해 변화하는 접근 방식의 몇 가지 어려움을 여기에서 언급했습니다. “[인시던트 관리 분산]의 어려움은 조직에 여전히 중앙 집중식 처리가 필요하다는 것입니다. 경영진은 보고서와 문서에 액세스할 수 있어야 합니다. 비즈니스 이해 관계자는 업데이트를 원합니다. 이들은 평균 해결 시간 및 평균 확인 시간과 같은 인시던트 메트릭을 확인하려고 합니다. 명확한 인시던트 업데이트, 인시던트 사후 검토 보고서 및 수정 작업을 기대합니다.
분산[그리고 "직접 구축하고 직접 운영"한다는 접근 방식]을 향해 나아가고 있으며 잘 해내고 있는 많은 기업의 경우, 이 어려움에 대한 해답은 분산 및 팀 자율성을 통해 인시던트 해결을 민첩하게 유지하고 정보를 중앙 집중식으로 처리하여 비즈니스를 계속 유지하는 기술입니다.”
또 다른 핵심적인 어려움은, 많은 비즈니스의 경우 “직접 구축하고 직접 운영”하는 관행을 수용한다는 것은 팀 구조와 내부 문화의 변화를 의미한다는 데 있습니다. 이것을 위해서는 공동 작업에 대한 열린 태도, 제품에 대한 새로운 사고 방식, 커뮤니케이션 장벽을 허무는 새로운 팀 구조가 필요합니다. 이와 같은 변화는 도전적이며 성공을 위해서는 매우 구체적인 접근 방식이 필요합니다.
"직접 구축하고 직접 운영"한다는 관행이 약속을 이행하고 있습니까?
어려움에도 불구하고 경험상 이 질문에 대한 저희의 대답은 '예'입니다. “직접 구축하고 직접 운영”하는 관행은 계속하여 업계를 변화시키고 있으며 기존 IT 팀조차도 천천히 시험해 보고 있습니다.
“직접 구축하고 직접 운영”한다는 관행의 채택에 대한 연구는 없지만, 경험상 일반적으로 DevOps 원칙과 함께 이루어지는 경우가 많습니다. 이것은 수치로 증명됩니다. Forrester 보고서에 따르면, 2017년에는 63%의 조직이 DevOps를 구현했다고 답했습니다. 또다른 27%는 한 해 안에 구현을 시작할 계획을 가지고 있었으며, 변화하는 데 관심을 보이지 않은 것은 1%뿐이었습니다.
더 매력적인 점은, 기업에서는 DevOps 원칙을 채택할 때 고객 만족도가 평균 45% 증가하고 직원 생산성이 43% 증가했다고 보고했습니다.
"직접 구축하고 직접 운영" 시작하기
유연하고 공동 작업이 뛰어난 플랫폼 없이는 "직접 구축하고 직접 운영"하는 접근 방식을 채택하기란 불가능합니다. 이 모든 것의 전제는 개발 팀과 운영 팀이 원활하게 협력할 수 있다는 것이며, 이 유형의 공동 작업은 적절한 도구를 통해서만 가능합니다.
Jira Service Management는 공동 작업 중심의 통합된 커뮤니케이션을 통해 팀을 하나로 모아, 채팅 채널(Slack, Microsoft Teams)에서 화상 회의(네이티브 비디오 브리지 또는 Zoom을 통해)에 이르기까지 팀이 선호하는 커뮤니케이션 방법으로 연결할 수 있도록 해줍니다. Jira Service Management의 거의 모든 측면은 알림부터 회람 규칙 등에 이르기까지 모든 팀의 요구 사항에 부합하고, 필요한 응답자를 관여시키고, 초기 응답 단계부터 사후 검토 보고 및 문제 관리에 이르기까지 모든 당사자에게 컨텍스트를 제공하도록 사용자 지정할 수 있습니다.
Jira Service Management로 팀이 가진 공동 작업의 잠재력을 실현하는 방법을 자세히 알아보세요.