“DevOps 변환”에는 무엇이 포함됩니까?
답변:
DevOps가 무엇인지,보다 구체적으로 내가 참여한 DevOps 변환 내에서이 질문에 대한 대답을해야합니다. DevOps는 전체 소프트웨어 개발 수명주기의 소유권입니다. 차트의 모든 관행은 DevOps의 중요한 부분이며, 시스템 사고 와 피드백 루프 증폭을 가능하게 합니다.
그러나 CI / CD와 DevOps의 주요 차이점은 프로덕션 환경에서 소프트웨어를 실제로 운영하여 고객과 비즈니스에 가치를 제공 할 수 있다는 것입니다.
DevOps 혁신에 참여하거나 이끄는 컨설턴트로서 저는 다음과 같은 측면을 생각합니다.
문화 : Dave가 올바른 실험과 학습 의 문화를 지적한 바에 따르면 모든 혁신의 성공에 매우 중요합니다. DevOps 관점에서 이것은 선택된 DevOps 모델을 지원하는 문화를 어떻게 창출 하는가에 달려 있습니다.이 모델은 "You Build It, You Run It"이거나 Google의 사이트 신뢰성 엔지니어링 실무에 따라 더 많을 수 있습니다. .
운영 모델 : 이것은 일반적으로 함께 사용되는 인력, 프로세스 및 도구를 명확하게 표현함으로써 조직이 어떻게 가치를 제공 할 것인지를 설명하는 비즈니스 제안의 일부입니다. 운영 모델이 없으면 조직이 문화가 정의한 관행을 채택하는 방식에 대한 청사진이 없으므로 명확성이 떨어지고 행동이 다양하지 않습니다.
C-Level Aircover : 비즈니스 운영 방식을 근본적으로 변화시키기 위해 혁신 프로그램 내에서 컨설턴트로 일하는 것이 종종 우리의 업무입니다. 당신은 사람들을 화나게 할 것이며, 어떤 사람들은 변화를 좋아하지 않을 것입니다. 일을 바꾸고 앞으로 나아 가기 위해서는 위에서 "에어 커버"를 갖는 것이 중요합니다.
높은 수준에 도달하면 현실적으로 제공 할 수있는 것을 찾아야합니다.
- 문화를 이해하는 사람들, 운영 모델의 스케치 및 경영진의 바이 인이 "최소 실행 가능한 프로젝트"를 만들면 DevOps를 도입하여 바다를 끓이지 말고 가능한 한 작은 규모로 시작하십시오. 수천 명의 청중에게. 달성 가능한 목표를 설정하십시오.
- 제품 X에서 인프라 생성을 자동화하십시오.
- 모든 환경에서 Product X를 Azure로 자동 전달합니다.
- 아웃소싱 업체 Y에서 런던의 개발 팀으로의 핸드백 지원.
- 가장 위험한 기능을 중심으로 일련의 테스트를 작성하고 지속적인 통합으로 실행하십시오.
- 벨트 아래에서 약간의 성공을 거두었으므로 이제 더 많은 팀에이 빵을 굽고 다른 팀을 믹스에 추가하여 가동시킬 차례입니다. 전환에 도움을주기 위해 "백색 장갑 지원"을 처음 제공하는 것을 두려워하지 마십시오. 앞으로 몇 주와 몇 달 동안 많은 손을 잡고 있어야합니다.
- 새로운 작업 방식을 따르는 얼리 어답터가 몇 명 있습니다. 당신은 비판적인 집단을 가지고 있습니다. 이제 더 많은 청중과 함께하고있는 일을 복음화해야합니다.
- 정기적 인 쇼 앤텔 세션을 개최하여 얼리 어답터에게 얼마나 성공적인지 보여달라고 요청하십시오.
- 모집 드롭 인 세션은 그들이 당신의 팀과 함께 보드에 올 수있는 방법을 탐구하는 조직의 다른 부분을 허용합니다.
- 지속적인 배포, 자동화 된 테스트, 비즈니스 커뮤니케이션, 위험 관리, 모니터링 및 경고 등 특정 분야에 중점을 둔 실무 커뮤니티를 만들 수 있습니다 .
코스를 유지하고 나머지 조직을 온 보딩하여 변화를 막으십시오. Gartner Hype Cycle 과 Adoption Lifecycle 의 관계를 이해하십시오 . 변화 프로그램이 "환풍의 어려움"에 빠질 수 있도록 준비하고, 코스를 유지하고 최종 목표를 계속 지켜보십시오.
마지막 요점에 대해 더 자세히 알아 보려면 Geoffrey A. Moore의 틈을 건너십시오 . 문자 그대로 DevOps 변환을 제공하는 방법에 대한 책을 쓸 수는 있지만 완료했을 때 필자가 더 이상 DevOps 변환 작업을 수행하지 않았을 것입니다.
DevOps는 다음 세 가지 주요 차원으로 분류되는 경향이 있습니다.
문화
DevOps 문화는 모든 이해 관계자, 특히 Dev, Ops 및 Security 간의 높은 수준의 신뢰, 협업 및 커뮤니케이션을 강조 합니다. 이 그룹들 사이의 자연스러운 긴장과 경쟁은 마찰을 일으키고 종종 기능 장애를 일으 킵니다. DevOps는 (아마도) 가장 먼저 이들 팀 간의 노력 조정에 관한 것입니다.
Process
DevOps 개발 프로세스는 애자일 프로세스와 밀접한 관련이 있습니다. Ops는 개발자의 노력에 더 잘 적응하기 위해 민첩한 관행을 채택하는 것이 좋습니다. DevOps 정렬 프로세스는 개발 / 배달 라이프 사이클 전체에서 고속 및 빠른 피드백 루프를 지원하도록 설계되었습니다. 지속적인 통합, 지속적인 전달 및 지속적인 개선 (kaizen)은 DevOps 프로세스의 핵심 영역입니다.
Technology
DevOps는 도구가 아니지만 도구에서 지원합니다. 지속적인 통합, 소스 제어 및 응용 프로그램 수명주기 관리를 포함한 다양한 영역을 지원하는 전체 도구 제품군이 있습니다.
"DevOps 변환"은 세 가지 요소를 모두 다루어야하지만 동시에 모두 똑같이 반드시 같은 것은 아닙니다. 자연스런 진보와 변화를위한 "핵심 경로"가 있습니다. 예를 들어, DevOps는 최소한 개발 팀 / 팀 내에서 어떤 형태의 민첩한 관행에 의존합니다. 툴링에 투자하기 전에 문화 문제를 해결해야 할 수도 있습니다.
참조 :
문화 : https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture
기술 : https://xebialabs.com/periodic-table-of-devops-tools/