개발이 운영에 반대하는 이유는 무엇입니까?

저는 여전히 학생이지만, 운영에 대해 잘 모르고 있으며 영어는 여전히 나쁩니다.

내 질문은 : 왜 개발이 운영에 반대 하는가? 언제 반대 작전을 개발합니까?

DevOps의 요점은 개발이 작업을 반대 하지 말고 서로를 지원해야한다는 것입니다.

일반적으로 폭포수 배포 및 대규모 업데이트로 인해 부적절한 테스트, 서버 환경 변경으로 인해 배포시 목록을 작성하는 작업으로 인해 다양한 문제가 발생할 수 있습니다. 기본적으로 업데이트가 너무 커서 운영 팀이 프로세스에서 발생하는 문제없이 효과적으로 배포 할 수 없었습니다. 이러한 문제는 개발이 운영에 반대 한다고 믿는 이유 일 수 있습니다 .

반면, DevOps는 매년 핸드 오프 발생 횟수를 늘림으로써 업데이트 크기를 줄이고, 엄격한 환경을 줄이며, 일반적으로 개발 및 운영간에 애플리케이션의 핸드 오프를 개선하기 위해 노력합니다. 배포 횟수가 증가하면 제품 업데이트에 필요한 많은 양의 작업을 자동화했거나 업데이트를 더 잘 예측하고 준비하기 때문에 운영에 어려움이 줄어 듭니다.

Tldr : DevOps는 운영과 개발이 함께 작동하여 제품을시기 적절하고 쉽게 재현 할 수있는 방식으로 자주 배포 할 수있는 사고 방식을 만들어 개발이 운영 에 반대 한다는 이론을 무효화합니다 .

나는 당신이 이미 포괄적 인 응답을 받았지만 영어가 훌륭하지 않다고 말했기 때문에 매우 간단하고 이해하기 쉬운 대답을 제공하려고 노력할 것입니다.

• 개발의 주요 목표는 변경하는 것입니다.
• 운영의 주요 목표는 환경을 안정적으로 유지하는 것입니다.

이 두 가지가 상충됩니다. 즉, 개발과 운영은 서로 반대해서는 안됩니다. 그들은 두 목표를 달성 할 수 있도록 협력해야합니다. 이것이 DevOps의 목적입니다.

개발과 운영 사이의 긴장은 종종 인센티브의 오정렬과 팀 내에서의 최적화 시도로 인해 발생합니다.

개발자 는 종종 코드 저장소로 가져 와서 코드 저장소에 병합 할 수있는 문제의 속도와 양으로 판단되며 보상은 실제로 실제로 작동하거나 올바르게 작동하는 코드와 관련이없는 경우가 많습니다. 확장 성, 성능 및 기타 요소가 훨씬 적습니다.

운영 은 종종 환경의 안정성과 코드가 프로덕션에서 얼마나 잘 작동하는지 판단하지만, 빠르게 변화를 가져 오는 프로세스의 품질에는 거의 영향을 미치지 않습니다.

이로 인해 개발자들이 많은 코드를 작성하고 운영 팀에 코드를 던지도록 장려하는 문제가 발생하고 운영 팀은 환경의 안정성을 보장하기 위해 가능한 한 적은 변화를 수용하도록 장려합니다.

DevOps는이 문제에 대한 일련의 솔루션입니다.

• 그들 중 일부는 조직적 일 수 있으며 팀의 프로세스와 인센티브가 변경 될 수 있습니다. 예를 들어, 개발자 작업이 일정 시간 동안 프로덕션에서 실행되었을 때 완료된 것으로 표시되는 경우 아무런 문제가 없으며 운영 팀은 코드의 소유권을 얻는 데 동의합니다. 유사하게, 환경이 여전히 일정한 안정성 범위 내에있는 동안, 코드가 수용되는 속도에 대해 동작이 더 판단 될 수있다.
• 솔루션의 또 다른 부분은 커뮤니케이션 및 교차 수분에있을 수 있으며, 운영 팀을 개발 팀에 포함시키고 그 반대도 마찬가지입니다. 이러한 팀 사이의 벽을 허물고 DevOps 엔지니어는 종종 이러한 유형의 브리징의 결과입니다.
• Continuous Integration 및 Continuous Deployment와 같은 프로세스를 지원하는 도구는 코드의 롤백 또는 빠른 수정 진행을 통해 문제가 발생할 경우 프로덕션 환경의 고품질 및 빠른 복구를 유지하면서 변경 속도를 높일 수있는 솔루션의 또 다른 부분입니다. 생산으로.

대부분의 조직은 조직을 기능 부분으로 나누고 각 부분이 자신을 개선하는 방법을 파악하도록 요구함으로써 복잡성을 처리합니다. 이를 종종 "사일로"접근 방식이라고합니다.

이 사일로 접근 방식이 비즈니스의 성공을 차단하고 조직 전체를 개선하지 못하는 이유를 이해하는 것이 중요합니다. 또한 개발 및 운영에만 영향을 미치지 않으며 품질 보증 팀, 재무, 제품 및 프로젝트 관리와 같은 대규모 조직 내의 다른 모든 기능 사일로에도 영향을줍니다.

각 기능 사일로의 관리자는 비용을 줄이거 나 속도를 높여서 개선하라는 명령을 받으면 다음과 같은 반응이 나타납니다.

• 마지막 개선 노력으로 문제를 해결하는 데 완전히 압도되었습니다. 날 내버려둬
• 내가하고 싶은 일, 책임을 다하거나 개선 프로젝트에 참여하고 싶습니까? 둘 다 할 시간이 없습니다.
• 다시는 아니야! 이달의 또 다른 프로그램이 있습니다.

이러한 전형적인 반응으로, 사소한 개선 노력을 시작한 경영진은 열의가 거의 없습니다. 관리자는 개선을 실행하는 데 필요한 리소스에 대해 다른 기능 영역과 치열한 경쟁을 벌입니다. 따라서 개선 명령이 기능 간 전투를 강화시키는 것은 놀라운 일이 아닙니다!

관리자가 개선 프로젝트의 일부를 마치더라도 업무를 수행하지 않은 다른 기능 영역 및 기타 조직 (공급 업체, 계약 업체 등)을 만납니다. 결과가 줄어들거나 완전히 무시됩니다.

이 교차 기능 장력은 개선 노력에 국한되지 않습니다. 조직 전체의 일상적인 의사 결정 및 관리 효과 성 판단의 핵심입니다. 실제 예는 다음과 같습니다.

재무 관리자에게 "개선"이라고 들었습니다. 그는 시장에서 허용되는 공칭 가격보다 많은 비용이 드는 고용 계약자를 차단하기로 결정했습니다. 그는 새로운 정책을 시행했으며 올해 100 만 달러를 절약했다고 ​​주장했다. 개발자와 IT는 계약 업체를 고용하여 컨테이너 및 컨테이너 오케스트레이션을 사용하도록 도와 줄 수 없습니다. 같은 회사의 IT 운영 관리자는 인프라를 개선하지 않으면 매달 10 만 달러 이상의 추가 비용이 드는 것으로 계산했습니다. 그 속도로, 고용 계약자의 연간 절감액은 연말 전에 사라졌습니다.

이 두 기능 영역 사이의 관계가 정확히 lovey-dovey가 아니라고 상상할 수 있습니다.

이러한 교차 기능 충돌은 조직이 각 사일로를 독립적으로 측정하는 사일로 접근 방식에 의해 발생합니다. 코스트 센터 인 경우 개선은 당연히 사일로 내에서 더 큰 효율성 또는 비용 절감을 의미합니다.

이 기준 틀에서 비용은 "첨가"규칙을 준수하는 것으로 간주됩니다. 각 사일로의 비용이 합산되면 조직의 총 비용과 같습니다. 따라서 관리자는 회사 전체의 비용 절감을 직접적으로 해석하므로 해당 영역의 모든 비용 절감은 "좋은"것으로 간주합니다. 이 기준 틀에서, 조직 전체의 비용과 낭비를 공격하기 위해 개선 노력이 도처에 퍼져 있습니다.

개발 팀이 민첩하게 작업하고 코드를 QA 및 운영 부서에 분기마다 대신 2 주마다 밀어 붙일 때 좋은 예입니다. QA와 운영 부서는 그러한 변경을 준비하지 않았으며 느슨해 졌다고 비난받습니다. 다시 말하지만, 이것은 개발과 운영에있는 사람들 사이의 사랑에 크게 기여하지 않습니다.