DevOpsワークフローを中止することの長所/短所？

私は、devospスタイルのワークフローから従来のdev-then-ops（何と呼ぶか​​わからない）に移行することが良いアイデアかどうかを評価しようとしています。

私たちは、従業員が4000人いる従来のメディア（ソフトウェア以外）などの企業に隠れている5人の小さな部門です。2年前に、部門での生産を大幅に拡大できるソフトウェアの構築を開始しました。私たちはかなり成功しており、より大きな会社が注目を集め始めています。これまでのところ、私たちは、最大10のサービスのAWSマイクロサービスプラットフォームとなったものの設計、開発、デプロイを単独で担当してきました。私たちのチームはDevOpsとして識別しませんが、間違いなく私たちはDevOpsの生活を送っています。各開発者は、コードとそれが実行されるシステムの両方に精通しています。

私たちがまもなく直面する問題の1つは、親会社のIT部門と私たちの間でどのような「効率」が共有されるかです。私たちのプロジェクトオーナーは通常、社内での学習よりもアウトソーシングを好むため、私たちの場合、これらの効率は、可能な限り多くのIT作業を「オフプレート」で行うことを意味します。現在、私たちのチームは、コーディングとインフラストラクチャの経験が70/30％分かれていると思います。IT部門は、IT開発の領域にしっかりと属しており、ソフトウェア開発に目に見えるクロスオーバーはありません。

私たちのプロジェクトオーナー（技術者ではない個人）は、できる限り多くの作業をITチームに引き渡すことで、削減した運用作業の1時間あたりの生産性が最大1：1向上することを期待しています。私はこれについては懐疑的です。私たちの製品はまだプレベータ版です（すでに重要なビジネス資産であるにもかかわらず）。IT部門との限られた経験の中で、ファイルシステムのアクセス許可の変更などの単純なことには通常、大幅な遅延があります。

現在、私の理想的なソリューションは、IT部門が私たちを "採用"し、ITオフィスの標準と要件を確実に満たしながら、私たち自身の仕事を展開し続けることです。それがどれほど現実的かはわかりません。さらに、短期的には追加の運用作業が追加されるため、プロジェクトオーナーが推奨するアプローチとはほぼ逆です。

私たちの状況では、DevOpsアプローチを維持することとITを引き継ぐことの賛成/反対の可能性は何ですか？

それは良い考えではありません。

私の経験では、両方の不利な点が得られますが、予測される利点はなんとかして実現に失敗します。

項目別：

1. あなたはスピードを失うでしょう。
   ITは独自の基準に準拠します。新しいタスク（彼らのための）は、彼らの仕事が今持っているものと同じ「遅い」テンプレートに従います。彼らはそれが挑戦的であることがわかるように準備してください-そのため、標準の単純なアクションよりもさらに速度が遅くなります。
2. オフロードに失敗します。
   ITはすべての異常についてあなたに頼ります。あなたは一人の男をスピードアップするために努力します-そして次のことはあなたが今あなた自身を繰り返すことになるでしょう、なぜなら次の仕事/問題/日が再び新しい男がいるからです。
3. 書類は必要ですが、役に立ちません。
   繰り返しになりますが、テンプレートの振る舞いは、短いマニュアルではすべての異常を捉えることができず、長すぎるために完全なテキストが読まれないというものです。したがって、ここでの投資はすべて損失になります。同様に、ツールを「シュリンクラップ」した品質にするための改善を実装するために必要な多大な労力もかかります。

最後になりましたが、問題はあなたたちに反映されます。タール、ターブラシの原理。

上記が皮肉に聞こえるなら、私はそこに行ったことを恐れています。繰り返し。

代わりに何をしますか？

IT部門で買い物をして、自分に役立つ候補者を見つけ、この人を「ローン」にしておくことで、ワークロードを軽減できます。

DevOps調査の結果には、製品の所有者に読むように依頼する必要がある多くの回答が見つかります。これは、技術的な知識がほとんどなく、理解すべき用語について話すビジネスパーソン向けに特別に書かれたドキュメントです。

同じレベルの機能開発を維持するには、平均して4人ごとに1人の追加の開発者が必要になります（新規作業に費やす時間は38％対49％）。障害から回復するまでの平均時間は最大25倍短縮されます。あなたの作品は20％楽しくなく、あなたの作品を友人にすすめる可能性は40％になります。これら3つの事実で十分です。

IT組織に組み込むことで失うのは、小さなDevOpsチームの「Dev」の部分です。チームがNetOps、SysOps、Devの人工的な役割に分割されると、次の問題が発生します。

1. 不要な赤テープと分離 -開発者は何でもするために、チケットをITに送信し、実装するのを待つ必要があります。彼らはもはや自分自身でそれを実装して対話することができなくなります-彼らがコード化できるインフラストラクチャを制限する彼らのDevとQAインスタンスを含めて。フルスタックでコーディングすることができず、VMバリアで動かなくなっています。彼らがITに提出するものがDevOpsコードのようである場合、彼らはそれを処理するのに不十分であり、手動のデプロイメントに戻る可能性があります。
2. 無視 -または、彼らはそれをそのまま展開し、それとの対話方法がわからないために無視することもできます-彼らは開発者ではないため、コードは問題ではありません。
3. 機能停止-DevOpsの見過ごされがちな利点の1つは、プログラム的な性質です。確かに、そのサーバーをコードとして扱うことにより、サーバーの展開に時間がかかる可能性がありますが、これにより人的ミスが自動化されます。開発への道のりは、QA /テストへの道のりであり、製品への道のりであり、それによって停止を減らします。開発者がネットワーク機器へのアクセスを失うと、サービスまたはコンピューティングインフラストラクチャを展開する必要が生じ、時間がかかるだけでなく、より多くの障害を引き起こす可能性のある人間を招きます。
4. ドキュメント -ある意味で、DevOpsコードは自己文書化されています。コードが教えてくれるので、サーバーがどのように構築およびデプロイされたかがわかります。CentOS 8へのアップグレードの時期が来た5年後、ネットワーク、ストレージ、監視、バックアップレイヤーを含め、アプリケーションをデプロイする方法は誰にもわかりません。

要するに、あなたはあなたのプロジェクトの所有者が読むのに時間がかかることを示唆している必要があります人月の神話あなたは1表示されるという概念の彼または彼女disabuseする：生産性と中1の関係フェニックスプロジェクト文庫良いです（と娯楽）非技術的な人々のために非技術的な言語でDevOpsを使用することによって得られるものと失われるもののイラスト。プロジェクトオーナーが何らかの通勤を行っている場合は、The Phoenix ProjectのAudibleオーディオブックを利用できます。

一部のITチームを採用し、新しいシステムで徹底的なトレーニングを行うことをお勧めします。

彼らがシステムを完全に理解したら、それを彼らにオフロードすることは理にかなっています。

それ以外の場合は、ITのサポートセンターになり、新しいシステムの複雑さを学習するために多くの時間を消防に費やします。