開発が運用に反対するのはなぜですか？

私はまだ学生ですが、業務について知識がなく、私の英語はまだ下手です。

私の質問は、なぜ開発は運用に反対するのですか？反対側のオペレーションの開発はいつですか？

DevOpsのポイントは、開発が運用に反対するのではなく、お互いをサポートする必要があるということです。

従来、ウォーターフォールの展開と大規模な更新により、開発が不適切なテスト、サーバー環境の変更、リストの延々と続くため、展開時にさまざまな問題が発生していました。基本的に、更新は運用チームにとって大きすぎて、プロセスで問題が発生することなく効果的に展開できませんでした。これらの問題が、開発が運用に反対であると信じる理由かもしれません。

一方、DevOpsは、毎年のハンドオフの発生回数を増やすことで、更新サイズを減らし、厳格な環境を減らし、一般に開発と運用の間のアプリケーションのハンドオフを改善するように機能します。製品の更新に必要な大量の作業を自動化したか、更新の予測と準備を改善したため、展開数が増えると、運用の頭痛が少なくなります。

Tldr：DevOpsは、運用と開発が連携して製品をタイムリーかつ容易に再現可能な方法で頻繁に展開するという考え方を作り出すことにより、開発が運用に反対するという理論を無効にすることを目指しています。

すでに包括的な回答は得られていると思いますが、英語は上手ではないとおっしゃっていたので、非常に簡潔で理解しやすい答えを提供しようと思います。

• 開発の主な目標は、変更を加えることです。
• 運用の主な目標は、環境を安定させることです。

これら2つのことは矛盾しています。そうは言っても、開発と運用は互いに対立すべきではありません。両方の目標を確実に達成できるように協力する必要があります。これがDevOpsの目的です。

開発と運用の間の緊張は、多くの場合、インセンティブの不整合とチーム内での最適化の試みによって引き起こされます。

開発者は、多くの場合、通過できる問題の速度と量によって判断され、コードリポジトリにマージされます。また、多くの場合、その報酬は実際に動作または正常に動作するコードに結び付けられていません。スケーリング、パフォーマンス、その他の要素がはるかに少ない。

多くの場合、運用は環境の安定性と運用環境でのコードの動作で判断されますが、変更を迅速に反映するプロセスの品質で判断されることはほとんどありません。

これにより、開発者が大量のコードを作成し、それを運用チームに壁を越えて投げかけるというインセンティブが与えられ、運用チームは環境の安定性を確保するために可能な限り小さな変更を受け入れるインセンティブを持つという問題が生じます。

DevOpsは、ある意味でこの問題に対する一連のソリューションです。

• それらのいくつかは、組織のプロセスであり、チームのプロセスとインセンティブが変わる可能性があります。たとえば、開発者の作業が本番環境でしばらく実行されているときにのみ完了マークが付けられた場合、問題はなく、運用チームはコードの所有権を取得することに同意します。同様に、環境はまだ安定の範囲内にありますが、コードが受け入れられる速度で操作をより多く判断できます。
• ソリューションの別の部分は、コミュニケーションとクロスポリネーションにあります。そこでは、開発チームに運用担当者を組み込み、その逆も同様です。これらのチーム間の壁を壊すと、DevOpsエンジニアは多くの場合、このタイプのブリッジングの結果です。
• 継続的インテグレーションや継続的展開などのプロセスをサポートするツールは、コードのロールバックや修正の迅速な進行によって問題が発生した場合に本番環境の高品質および高速リカバリを維持しながら、変更の速度を上げることができるソリューションの別の部分です生産に。

ほとんどの組織は、組織を機能的な部分に分割し、各部分がそれ自体を改善する方法を見つけ出すことを要求することにより、複雑さに対処しています。これはよく「サイロ」アプローチと呼ばれます。

このサイロアプローチがビジネスの成功を妨げ、多くの場合組織全体の改善に失敗する理由を理解することが重要です。また、開発と運用だけに影響するのではなく、品質保証チーム、財務、製品、プロジェクト管理など、大規模な組織内の他のすべての機能サイロに影響します。

各機能サイロの管理者は、コストの削減または速度の向上によって改善するように命じられているため、多くの場合、その反応は次のとおりです。

• 私は前回の改善努力による問題の修正に完全に圧倒されています。ほっといて。
• あなたは私に何をして、私の責任を果たし、改善プロジェクトに取り組みたいですか？両方をする時間はありません。
• 二度とない！今月の別のプログラムがあります。

これらの典型的な反応により、マイナーな改善努力を開始する経営者が熱意をもって迎えられることはめったにありません。マネージャーは、改善を実行するために必要なリソースをめぐって、他の機能分野との激しい競争に直面しています。したがって、改善するコマンドが機能間の戦いを強化するのも不思議ではありません！

マネージャーが改善プロジェクトの一部を完了した場合でも、マネージャーは仕事をしていない他の機能分野や他の組織（サプライヤー、請負業者など）に会います。これにより、結果が減少するか、完全に無効になります。

このクロスファンクショナルな緊張は改善努力に限定されません。これは、日々の意思決定と組織全体の管理の有効性の判断の中心です。実際の例を次に示します。

財務マネージャーは「改善する」と言われました。彼は、市場で受け入れられている名目価格を超える費用の請負業者をブロックすることにしました。彼は新しいポリシーを実装し、今年100万ドルを節約したと主張しました。開発者とITは、請負業者を雇うことができず、コンテナとコンテナオーケストレーションの使用を支援できません。これらの請負業者は費用がかかるためです。同じ会社のIT運用マネージャーは、インフラストラクチャを改善しないと、毎月100,000ドルを超える追加費用がかかると計算しました。そのレートでは、雇用契約者の年間節約額は、年末までに食い尽くされました。

これらの2つの機能領域間の関係は、必ずしも愛情のこもったものではなかったと想像できます。

これらの職域を超えた対立は、組織が各サイロの改善を個別に測定するサイロアプローチによって推進されます。コストセンターの場合、改善は当然、サイロ内での効率の向上またはコスト削減を意味します。

この参照フレームでは、コストは「加算的」ルールに従うものと見なされます。各サイロのコストを合計すると、組織の総コストに等しくなります。したがって、管理者は、会社全体のコスト削減への直接的な変換を見ているため、その地域のコスト削減は「良い」と見なします。この参照フレームでは、組織全体のコストと無駄を攻撃するための改善努力があらゆる場所に広がっています。

開発チームが以前のように四半期ごとではなく、2週間ごとにアジャイルの作業とQAとオペレーションへのコードのプッシュを開始するときの素晴らしい例です。QAとオペレーションは、そのような変更に対応する準備ができておらず、怠けていると非難されています。繰り返しますが、これは開発と運用の人々の間の愛にはあまり貢献しません。