DevOps 워크 플로 중단의 장단점?

나는 devops 스타일 워크 플로우에서 전통적인 dev-then-ops로 옮기는 것이 좋은지 아닌지 평가하려고합니다 (당신이 무엇이라고 부르는지 확실하지 않음).

우리는 4000 명의 직원 전통적인 미디어 (예 : 소프트웨어가 아닌) 회사 내에 자리 잡은 작은 5 명 부서입니다. 2 년 전 우리 부서에서 생산 규모를 크게 확장 할 수 있도록 소프트웨어를 구축하기 시작했습니다. 우리는 꽤 성공적이었고 더 큰 회사가 주목하기 시작했습니다. 지금까지 우리는 ~ 10 서비스 AWS 마이크로 서비스 플랫폼이 된 것의 설계, 개발 및 배포에 대한 책임을 전적으로 담당했습니다. 우리 팀은 DevOps로 식별되지 않지만, 의심의 여지없이 우리는 개발자와 함께 코드와 시스템에 친숙하게 각 개발자와 함께 DevOps 수명을 보내고 있습니다.

우리가 곧 직면하게 될 질문 중 하나는 우리와 모회사의 IT 부서간에 "효율성"이 공유되는 것입니다. 우리의 프로젝트 소유자는 일반적으로 사내 학습보다 아웃소싱을 선호하므로, 이러한 효율성은 아마도 가능한 한 많은 "IT 작업"을 수행하는 것을 의미합니다. 현재, 우리 팀은 코딩 경험과 인프라 경험이 70 / 30 %로 분리되어 있다고 말합니다. IT 부서는 소프트웨어 개발에 눈에 띄는 크로스 오버없이 IT 영역에 있습니다.

우리의 프로젝트 소유자 (비 기술적 인 개인)는 IT 팀에 가능한 많은 작업을 전달함으로써 우리가 흘린 운영 작업 시간마다 생산성이 ~ 1 : 1 향상 될 것으로 기대합니다. 나는 이것에 대해 회의적입니다. 우리의 제품은 여전히 ​​사전 베타 버전이며 (이미 상당한 비즈니스 자산 임에도 불구하고) IT 부서에 대한 제한된 경험에서는 일반적으로 파일 시스템 권한 변경만큼 단순한 작업에 대한 상당한 지연이 있습니다.

지금, 이상적인 솔루션은 IT 부서가 우리를 "채택"하고 우리 자신의 업무를 계속 배포하면서 IT 사무실의 표준 및 요구 사항을 충족시키는 것입니다. 나는 그것이 얼마나 현실적인지 잘 모르겠습니다. 또한 단기적으로 운영 작업을 추가 할 것이기 때문에 프로젝트 소유자가 옹호하는 것과 거의 반대의 접근 방식입니다.

우리의 상황에서 DevOps 접근 방식을 유지하는 것의 장점과 단점은 무엇입니까?

좋은 생각이 아닙니다.

내 경험상 두 가지의 단점을 얻을 수 있지만 예상되는 장점은 실현되지 않을 것입니다.

품목별 :

1. 속도가 떨어집니다.
   IT는 자체 표준을 준수합니다. 새로운 작업 (그들을위한)은 현재 그들이하고있는 모든 '부진한'템플릿을 따릅니다. 표준 간단한 동작보다 속도가 훨씬 빠릅니다.
2. 오프로드에 실패합니다.
   IT는 모든 예외에 대해 여러분에게 의지 할 것입니다. 한 사람의 속도를 높이기 위해 노력할 것입니다. 다음 작업 / 문제 / 일이 다시 새로운 사람이 될 것이기 때문에 다음으로 자신을 반복하게됩니다.
3. 문서가 필요하지만 도움이되지 않습니다.
   다시 한 번 템플릿 동작은 짧은 매뉴얼이 모든 이상을 포착하지 못하고 너무 긴 텍스트를 읽을 수 없다는 것입니다. 따라서 도구를 '수축'품질로 만들기 위해 개선을 구현하는 데 필요한 엄청난 노력과 마찬가지로 여기에 투자하면 손실이 발생합니다.

마지막으로 문제는 여러분들에게 반영 될 것입니다. 타르, 타 브러시 원리.

위의 내용이 냉소적으로 들리면 내가 거기에 있었던 것 같습니다. 자꾸.

대신 무엇을해야합니까?

IT 부서에서 쇼핑을하고 유용한 후보를 찾고이 사람을 '임대'로 유지하여 업무량을 줄이십시오.

DevOps 설문 조사 결과 에서 제품 소유자에게 읽도록 요청해야하는 많은 답변을 찾을 수 있습니다 . 이 문서는 이해해야 할 용어로 기술 지식이 거의없는 비즈니스 사용자를 위해 특별히 작성된 문서입니다.

평균적으로 동일한 수준의 기능 개발을 유지하려면 4 명당 1 명의 추가 개발자가 필요합니다 (38 % 대 49 %의 새로운 작업 시간). 고장 복구에 걸리는 평균 시간은 최대 25 배입니다. 당신의 작품은 20 % 덜 즐겁고 40 %는 친구에게 추천 할 것입니다. 이 세 가지 사실만으로도 충분합니다.

IT 조직에 적응함으로써 잃게 될 것은 작은 DevOps 팀의 "Dev"부분입니다. 팀이 NetOps, SysOps 및 Dev의 인공 역할로 분류되면 다음과 같은 문제가 발생합니다.

1. 불필요한 빨간 테이프 및 격리 -개발자는 IT에 티켓을 제출하고 티켓을 구현할 때까지 기다려야합니다. 더 이상 코드를 작성할 수있는 인프라를 제한하는 Dev 및 QA 인스턴스를 포함하여 자체적으로 구현 및 상호 작용할 수 없습니다. 풀 스택에서 코딩 할 수있는 대신 VM 장벽에 갇혀 있습니다. IT 부서에 제출 한 내용이 DevOps 코드처럼 보이는 경우이를 처리하기에 적합하지 않으며 수동 배포로 되돌아 갈 수 있습니다.
2. 방치 -대안으로 그들은 그대로 배치 한 다음 상호 작용하는 방법을 모르기 때문에 짐승을 방치 할 수 있습니다. 개발자가 아니기 때문에 코드는 문제가 아닙니다.
3. 중단 -DevOps의 간과되는 장점 중 하나는 프로그래밍 방식이라는 점입니다. 물론 서버를 코드로 처리하여 해당 서버를 배포하는 데 시간이 더 걸릴 수 있지만 이는 사람의 실수를 자동화합니다. 그것이 개발에 들어간 방식은 품질 보증 / 테스트에 들어가는 방식입니다. 개발자가 네트워크 장비에 액세스 할 수없는 경우 서비스를 배포해야하거나 컴퓨팅 인프라에 시간이 오래 걸릴뿐만 아니라 더 많은 사람을 소개하여 더 많은 중단을 초래할 수 있습니다.
4. 문서 -어떤 의미에서 DevOps 코드는 자체 문서화입니다. 코드에서 알 수 있듯이 서버가 구축되고 배포 된 방법을 알고 있습니다. 5 년 후 CentOS 8 등으로 업그레이드 할 때가되면 네트워크, 스토리지, 모니터링 및 백업 계층을 포함하여 더 이상 애플리케이션을 배포하는 방법을 알 수 없습니다.

요컨대, 프로젝트 소유자는 신화적인 맨-월 을 읽고 생산성과 1 : 1 관계 가 있다는 피닉스 프로젝트 와 소설로 잘 알려진 피닉스 프로젝트 를 읽는 데 시간을 할애 할 것을 제안해야합니다 (그리고 비 기술적 인 사람들을 위해 비 기술적 언어로 DevOps를 사용하여 얻는 것과 잃어버린 것의 예). 프로젝트 소유자가 출퇴근하는 경우 Phoenix 프로젝트의 가청 오디오 북을 사용할 수 있습니다.

IT 팀의 일부를 채택하여 새로운 시스템에 대한 철저한 교육을 제공 할 것을 제안합니다.

일단 시스템을 완전히 이해하면 시스템에 시스템을 오프로드하는 것이 좋습니다.

그렇지 않으면 IT 지원 센터가되어 새로운 시스템의 복잡성을 배우면서 소방에 많은 시간을 할애하게됩니다.