성공적인 변화 관리에는 무엇이 필요합니까? DevOps?

DevOps 조직에 귀중한 변화 관리 원칙과 실행 방식을 제공하지만, 변화 관리에 있어 유일한 해결책은 아닙니다. 조직은 자유롭게 다음에서 배울 수 있어야 합니다. DevOps 특정 프레임워크에 얽매이지 않고도 변화 가능성을 높이는 모범 사례를 제시합니다.

그러나 조직은 인식해야 합니다. DevOps' 변화 관리 관행에 대한 강점. 다른 대안적인 접근 방식도 유사한 강점을 제공해야 합니다. 그 외에도 제품 안정성과 지속적인 가치 창출에 관심이 있는 IT 리더는 다음과 같은 기술적 측면을 고려해야 합니다. DevOps 자신의 관행에 영향을 미치는 관행.

왜? DevOps 변화 관리에 그렇게 인기가 있나요?

DevOps 전 세계 기업에서 널리 사용되는 프레임워크입니다. 2021년 초 설문 조사에 따르면 조직의 74%가 DevOps 또는 계획 단계에 있습니다. 기업 리더들은 DevOps 최소한의 중단 위험으로 신속한 변화 관리를 촉진하는 능력으로 인해. 고성능 DevOps 조직은 할 수 있습니다 성과가 낮은 기업보다 208배 더 자주 코드를 배포합니다..

가장 큰 이유 중 하나는 DevOps 유연한 변경 관리를 용이하게 하는 것은 순환 구조로 구성되어 있다는 점입니다. 새로운 변경 사항은 이상적으로 지속적인 통합 및 배포(CI/CD) 프로세스를 통해 커밋됩니다. 프로세스 최적화는 팀 간 핸드오프 간의 마찰을 줄여 변경 리드타임을 단축하는 데 도움이 됩니다. 운영 데이터는 또한 릴리스 우선순위를 결정하여 QA 및 기타 배포 전 검토 시간을 늘리는 요인들을 해결할 수 있습니다.

하지만 DevOps 조직이 점점 더 변화로 정의되는 가속화되는 비즈니스 환경에 적응할 수 있는 유일한 방법은 무엇일까요? 꼭 그렇지만은 않습니다. 기술적으로 정의할 수 없는 소프트웨어, 플랫폼, 디지털 서비스에 접근하는 방법은 다양합니다. DevOps. 게다가 정확히 무엇이 필요한지에 대해서는 많은 의견 불일치가 있습니다. DevOps 이다.

당신은 당신이 가지고 있는 것을 '라고 부를 필요는 없습니다.DevOps', 하지만 문제를 바로잡기 위해 노력해야 합니다. DevOps 해결합니다. 이것이 바로 처음에 많은 사람들이 이를 받아들이게 된 이유입니다. 가장 중요한 것은 DevOps- 통제 수단을 마련했습니다. 또한, 협력적 가치 창출을 장려하고 책임의 연속성을 확립하여 조직 간 사일로를 해소하는 모범 사례이기도 합니다.

DevOps 지속적인 변화 배포를 통해 가치 창출을 가능하게 합니다.

구현된 주요 가치 DevOps 개발팀과 운영팀 간의 협업입니다. 이름에서 알 수 있듯이요! 고전적인 옆으로 8개의 다이어그램 각 프로세스가 다음 프로세스로 이어진다는 것을 보여줍니다. 두 팀은 서로 긴밀히 연결되어 변화를 촉진하고 창출하는 동시에 그 가치를 유지합니다. 협력적인 DevOps 이러한 접근 방식은 일반적인 병목 현상을 제거하고, 특히 프로덕션 오류 및 결함과 관련하여 개발자가 IT 운영 문제에 이해관계를 가지고 있음을 보여줍니다.

~에 안내 DevOps 문제 유형을 보여줍니다 DevOps 해결할 수 있습니다:

• 개발팀은 QA 및 배포를 지연시키는 문제에 대해 더욱 인식하게 되었습니다.
• QA 및 운영 부서는 릴리스를 통해 창출되는 비즈니스 목적 및 의도된 고객 가치에 더욱 부합하게 됩니다.
• 개발과 운영이 서로 상반되는 목표를 향해 나아가지 않으면, 문제가 생겼을 때 비효율성과 책임 전가로 이어질 수 있습니다.

개발과 운영 간의 프로세스를 통합하면 변경 실패나 배포 병목 현상으로 인해 릴리스 일정이 심각하게 지연되는 상황을 방지할 수 있습니다. 이러한 상황은 쉽게 상상할 수 있습니다. 버그가 발견되었는데, 운영팀이 개발자가 잘못된 아티팩트를 제공했다고 말합니다. 개발자는 테스트 환경에서는 모든 것이 잘 작동했다고 지적합니다. 디버깅 훈련이 시작되고, 운영팀은 밤새도록 프로덕션 문제를 해결합니다. 프로덕션 환경은 개발팀과 QA팀의 책임이 아니기 때문입니다.

DevOps 변화 관리는 이러한 상황을 방지하는 데 도움이 됩니다. 두 부서의 노력을 통합하고 운영 과정에서 생성된 피드백을 활용하도록 장려하면 책임감을 강화하고 제품 품질을 향상시킬 수 있습니다.

DevOps ITIL과 같은 기존 접근 방식의 단점도 해결합니다. ITIL은 특정 역할과 프로세스를 정해 놓지만, 지속적인 문제를 항상 효율적으로 해결하는 것은 아닙니다. ITIL 비판론자들은 ITIL이 "IT가 효율적이고 관리 가능하다는 조직의 망상을 초래하는 통제의 환상"을 만들어낸다고 지적합니다. 이러한 프레임워크에는 "'내 문제가 아니다'라는 태도"와 함께 사일로가 여전히 존재합니다.

책임 소재를 명확히 하는 것이 ITIL의 본질적인 특성은 아니지만, 많은 ITIL 중심 조직 구조는 기존 프로세스를 개선하기보다는 반복하는 데만 치중하는 것이 현실입니다. 업무 자체가 목표가 되는 반면, DevOps목표는 가장 효율적인 프로세스를 통해 지속적인 제품 개선을 이루는 것입니다.

일부 회사나 제품은 사용으로 인해 이점을 얻지 못할 수 있습니다. DevOps 변화 관리를 위해

어떤 종류의 조직이나 제품이 혜택을 받지 못할지에 대한 논란이 많은 토론이 있었습니다. DevOps. 혁신적인 응용 프로그램이 필요하다는 것이 일반적인 가정입니다. DevOps, 아주 소수의 예외를 제외하고. "일반적인 의견은 소프트웨어(특히 앱 개발)를 사용하여 해당 분야에서 혁신을 이루는 조직은 다음을 구현하는 것을 고려해야 한다는 것입니다. DevOps 문화," 한 기자가 쓴 것처럼.

하지만 기술 전문가들은 몇 가지 예외적인 사례를 제시합니다. 예를 들어, 다른 소프트웨어 회사를 지원하는 PaaS가 있습니다. 다음을 사용하여 변경 빈도를 개선할 수 있습니다. DevOps 병목현상을 완화하기 때문입니다.

보험 회사 AVIVA의 CIO는 다음과 같이 주장합니다. DevOps 소규모 스타트업에게는 필수이지만, 대기업은 이러한 접근 방식을 채택하는 것을 미루고 싶어할 수도 있습니다. "소규모 기업과 스타트업에게는 선택의 여지가 없습니다." CIO가 쓴다"대체 가능한 역할, 극도의 자동화, 그리고 모두가 참여하는 것이 일반적입니다. 이것이 바로 그들이 고객에게 신속하게 기능을 제공하는 방법입니다. 하지만 이러한 조직적 민첩성은 대기업들이 어려움을 겪는 부분입니다."

그러나 고려할 때 DevOps 조직에 "적합"할 수도 있지만, 전부 아니면 전무라는 사고방식을 피하는 것이 중요합니다. 어떤 조직이든 핵심을 채택할 수 있습니다. DevOps 개념, 워크플로, 모범 사례를 격리하여 비즈니스 목표에 가장 적합한 방식으로 적용합니다.

명확한 프로세스, 책임 소재, 그리고 가능한 한 자동화를 구축하는 것은 논쟁의 여지가 없는 부분입니다. 가치를 창출하는 변경 사항을 적용하여 제품을 정기적으로 업데이트하는 것이 최우선 과제이므로, 신속한 릴리스 생성, 통합 및 배포 프로세스에도 이러한 사항이 반영되어야 합니다.

많은 변화 관리 프로세스가 활용됩니다. DevOps 원칙(그것을 그렇게 부르지 않더라도) DevOps)

궁극적으로 개발팀과 운영팀 간의 구분을 없애면 가치 감소의 원인(예: 문제, 재작업, 지연)이 더욱 명확하게 드러납니다. 개발팀과 운영팀이 협업할 때, 문제 해결 방법과 담당자에 대한 프로세스를 공식화해야 할 것입니다.

그러나 이상과 목표는 DevOps 보편적이며 두 가지가 없습니다 DevOps 조직은 모두 비슷합니다. 각 조직은 모든 ​​단계에서 최적화된 프로세스를 갖추고 있습니다. 더욱이 제품과 목표의 차이로 인해 한 조직에서 사용하는 프로세스는 DevOps 다른 것과는 크게 다를 것입니다. 그러나 많은 비즈니스 및 IT 리더는 두 가지를 살펴보고 둘 다 어떤 형태의 DevOps그들의 프로세스의 특정한 특성을 감안할 때.

또한 채택하는 것도 기억하는 것이 중요합니다. DevOps 원칙적으로 변경 배포 속도가 자동으로 빨라지지는 않습니다. 많은 비즈니스 리더들은 여전히 ​​복잡한 변경 관리 프로세스를 정기적으로 구현하고 있습니다. DevOps 뼈대.

이 경우 프로젝트 관리팀과 운영팀은 프로덕션 환경에서 잘못된 코드를 방지하기 위해 소프트웨어 개발 프로세스를 엄격하게 관리합니다(Diginomica 참조). 하지만 실제로는 더 많은 제어 기능을 구현하는 것이 DevOps 워크플로는 종종 "병목 현상, 지연 및 백업"을 초래하며, 이는 모두 더 크고 덜 빈번하며 더 위험한 릴리스로 이어져 변경 실패율을 높이는 데 기여합니다.

또한 2019년의 상태 DevOps 보고서에 따르면 "중량 프로세스를 사용하는 사람들은 성과가 낮을 가능성이 2.6배 더 높습니다."

구현 여부에 관계없이 기억하십시오. DevOps 또는 다른 방법론을 사용하더라도 중요한 것은 변화 실현이라는 목표에 집중하고 이를 가능한 한 효율적으로 촉진하는 관행을 채택하는 것입니다.

변화 활성화를 위해서는 다음에서 배우십시오. DevOps 모범 사례를 따르지만 그에 따라 통제받는다고 느끼지 마세요.

유동적인 정의와 다양한 사용 사례 환경으로 인해 DevOps 애자일은 하나의 고정된 "것"이 아닙니다. 애자일은 하나의 고정된 개념이 아닙니다. 특정 관행에 관한 것이 아니라, DevOps 핵심은 "IT 운영과 공유되는 교차 기능, 책임 및 목표를 염두에 두고 지속적인 개발 주기를 위한 길을 마련하고 민첩한 소프트웨어 개발 규범을 수용하는 문화적 변화"입니다. 한 작가가 말했듯이.

IT 리더는 다음 효과의 우선 순위를 기억해야 합니다. DevOps 매우 구체적인 원칙들을 고수하는 것이 아니라, 실질적인 변화 관리를 실천하는 것이 중요합니다. 시스템이 실질적인 변화 지원을 제공하는지 평가할 때는 성공적인 지속적 제공(CDM)의 징후를 살펴보세요. 긍정적인 신호 하나 팀이 "생산에 대한 주문형 변경 사항을 배포할 수 있고, 품질 피드백 배포가 즉시 가능하며, 팀은 해당 피드백을 바탕으로 신속하게 조치를 취해 다음 배포 주기를 개선할 수 있습니다."

또 다른 긍정적인 신호는 개발자들이 버전 관리 시스템을 정기적으로 확인한다는 것입니다. TechBeacon에 따르면, "이 이벤트는 자동으로 빌드와 일련의 자동화된 테스트를 시작해야 합니다." "빌드나 테스트가 실패하면 팀에 즉시 알림이 전송되어야 합니다."

생성된 데이터와 유동적인 변화 활성화를 나타내는 지표를 기반으로 프로세스를 평가하면 IT 및 조직 리더가 시간이 지남에 따라 작업 시스템을 최적화할 수 있습니다.

결론은 가시성을 유지하고 모든 이해관계자에게 가치 창출의 걸림돌을 알리는 것입니다. 데이터 분석은 이러한 목표 달성에 도움이 될 수 있지만, 조직은 실무 및 워크플로우의 기반이 되는 개념적 프레임워크가 필요합니다. DevOps 또는 다른 것.