DevOpsの「正しい」コマンド構造

こんにちは、Habr！ 銀行での2年目は、開発チームと運用チームを適切に編成する方法を理論と実践で議論してきました。 最近、実務経験の新しい部分によって強化された議論が次のラウンドに入り、それがアイデアと議論の次の検索へと私を促しました。









その結果、私は非常に好奇心across盛な資料に出くわし、できるだけ多くの聴衆と共有したいという欲求が怠と翻訳の時間不足によって克服されました。 「サイロ」という言葉にふさわしいロシア語を見つけようとするたびに追いつくという完全な落胆にもかかわらず。 サイロ？ ドイツのオスカロビッチは、「よく」という言葉を使用したことを覚えています...彼の同僚と相談した後、私は「プロット」という用語について考えることにしました。



この記事の何が好きでしたか？ まず第一に-提供されるさまざまなオプション。 エバンジェリストやコンサルタントからよく聞かれる「それだけで、あなたは幸せになります」ということはありません。 以下は、組織で試すことができる9つの「正しい」オプションと7つの「間違った」オプションで、さまざまな方法で組み合わせて、実行可能なものではないにしても、少なくともいくつかのアイデアを「試す」ことができます。 第二に、これらの物語は「流血の企業」の実世界から明らかに取られています-ほとんどは5人のスタートアップではなく、最初からすべてを正しく行っているが、独自のレガシー、複雑な組織構造、複雑な人間を持つ大規模オフィス向けのDevOpsモデルを提供します関係。 結局のところ、 最近のHabrのヒットからわかるように、最も先進的な組織でさえ、一定のサイズに達すると互いに似たものになります。



だから、マシュー・スケルトンとマヌエル・パイスの記事、 DevOpsを開発するための最高のチーム構造は何ですか？ 。 最初のバージョンは2013年に登場しました。それ以来、著者は多くの修正と修正を行っています。

アンチタイプのDevOpsトポロジー

「アンチタイプ」（ユビキタスな用語「アンチパターン」ではなく）と呼ばれる可能性のある悪い慣行のアイデアを持っていることは常に役立ちます

アンチタイプA：プロットの開発と運用

これは、「ソフトウェアを壁から投げる」という原則に基づいた、開発者と運用者間の古典的な分離スキームです。 実際には、Devにとって、これはタスクの遂行を早期に認識することを意味します（「完了」は「戦闘で働く」よりも「機能を作る」を意味します）が、Devは産業で実際に何が起こっているかを知らないため、ソフトウェアの作業能力が低下します環境、Opsには、ユーザーのアプリケーションの新しいバージョンがリリースされるまで、Devが問題を解決する能力も時間もありません。



私たちは皆、このトポロジーが最良ではないと聞いていますが、私は個人的にはさらに悪い選択肢があると思います。

アンチタイプB：DevOpsコマンドのプロット

原則として、このアンチタイプは、特定の上級管理者が「このDevOpsを少し必要とする」と判断し、「DevOpsチーム」（場合によっては「DevOps people」で構成されることもあります）を作成するように指示したときに発生します。 このようなチームは、開発者と運用者を互いから遠ざけて、それぞれのコーナー、スキル、およびツールをこれらの「曲がった開発者」または「愚かな管理者」から保護できるように、個別のプロットで非常に迅速に自身をシールドします。



このモデルが実用的である唯一の状況は、DevOpsチームを限られた期間（最大12か月から18か月など）で作成し、当初の目標であるDevとOpsをより近づけ、DevOpsチームを排除することについて明確な声明を出すことです。この時間の満了。 この場合、 タイプ5と呼ばれるDevOpsモデルが実装されます。

アンチタイプC：Dev-Opsは必要ありません

このモデルは、開発者とそのマネージャーの素朴さとand慢さの組み合わせから生まれます。特に新しいプロジェクトやシステムが立ち上げられた場合は特にそうです。 IT Opsが過去からのイメージであると仮定すると（「現在、私たちの周りにクラウドがありますか？」）、開発者は運用スキルとアクティビティの複雑さと重要性を過小評価し、それらがなくても存在できる、または実行できると信じ始めます。 「自由な」時間。



アンチタイプCは、リリースされたソフトウェアが実際の運用負荷を作成し、開発時間を吸収し始めると、 タイプ3 （IaaSとしての操作）またはタイプ4 （外部サービスとしてのDevOps）に変わる可能性があります。 このチームが専門分野としてIT運用の重要性を認識した場合にのみ、痛みや不必要な運用エラーを回避できます。

アンチタイプD：ツールチームとしてのDevOps

開発者の現在の生産性を犠牲にすることなく（つまり、機能的な機能を実装することなく）「DevOpsになる」ために、DevOpsチームがDev内に作成され、開発パイプライン、構成管理システム、環境管理アプローチなどのツールセットをDevに提供します。 同時に、Opsは単独で動作し、Dev-「壁を越えてソフトウェアを投げる」。



このようなスキームのDevOpsチームは、ツールの導入により実際のメリットをもたらすことができるという事実にもかかわらず、最終的な効果は制限されます。 基本的な問題は未解決のままです。Opsの早期関与の欠如と、ソフトウェアライフサイクル全体にわたる機能の相互作用です。

アンチタイプE：ブランド変更されたシステム管理者

このアンチタイプは、エンジニアリングの成熟度が低い組織に一般的です。 彼らはプラクティスを改善し、コストを削減したいのですが、ビジネスの重要な成功要因をITで把握することはできません。 業界にとってのDevOpsの利点は（すでに）明白であると考えられているため、「DevOpsを行う」ことも望んでいます。 残念ながら、チームの構造や関係の実際の問題を解決する代わりに、Opsチームの「DevOpsエンジニア」を雇って間違った道を選択します。



「DevOps」という用語は、システム管理者の役割をブランド変更するために使用され、プロセスの文化や組織に実際の変更は発生しません。 無差別のリクルーターが自動化スキルとDevOpsツールを備えた人々の検索に参加するにつれて、このアンチタイプはより一般的になりつつあります。 実際には、DevOpsを機能させるのは人々のコミュニケーションスキルです。

アンチタイプF：Ops Inside Dev

この組織は、別の運用チームを持つことを望まないため、開発チームはインフラストラクチャ、環境管理、監視などを担当します。 このアプローチでは、プロジェクトまたは製品チームで、運用タスクがリソースの制約または低優先度の犠牲になり、その結果、品質の低い生製品につながります。



このアンチタイプは、効果的なIT運用の役割とスキルの重要性に対する過小評価を示しています。

アンチタイプG：開発とDBAのプロット

これはアンチタイプAの種類の1つで、多くの古いシステムが集中型データベースに関連付けられている中規模および大規模企業で非常に一般的です。 これらのデータベースはビジネスクリティカルであるため、通常はOpsフレームワーク内の別のDBAチームが、障害の管理、構成、および復旧を担当します。 このようなスキームは論理的です。 しかし、同時にDBAチームが境界の保護者となり、データベース内のすべての可能な変更を遅くすると、これは定期的なソフトウェア更新の追加の障害になります（DevOpsの主な目標は加速です）。



さらに、DBAチームが初期段階でソフトウェアの開発に関与していない場合、データの移行やデータベースのパフォーマンスなどに関するすべての問題はライフサイクルの後期段階でのみ発見され、管理者への重い負荷と相まって、絶え間ない戦いとDBAに対するプレッシャーの増加。

DevOpsトポロジーのタイプ

悪いオプションについて話した後、DevOpsの動作に役立つモデルを見てみましょう。

タイプ1：コラボレーション開発および運用

これは、非常に「約束の地」であるDevOpsです。必要に応じて、開発チームと運用チームの「スムーズな」相互作用-専門性が適用され、必要に応じて-チームが連携します。 このオプションでは、いくつかの個別のDevコマンドがあり、それぞれが部分的に独立した製品で動作します。



私の意見では、タイプ1の実装には、組織の大幅な変更とIT組織の管理における高いレベルの能力が必要です。 開発者と運用者には、明確で明確でわかりやすい共通の目標が必要です（たとえば、「信頼性の高い頻繁なソフトウェア変更を提供する」）。 Opsの人々は、開発（テストによる開発（TDD）やバージョン管理など）に固有の問題について、開発者と協力して快適に作業できるはずです。 一方、Devは運用上の問題に真剣に関与する必要があり、またOpsから入門して新しいソリューションを開発するよう努力する必要があります。 これにはすべて、過去の従来のアプローチと比較して、重要な文化的変化が必要です。









タイプ1の適用可能性：強力な技術コンポーネントを持つ組織

潜在的な効率： 高

タイプ2：完全に統合されたチーム

Opsの従業員が製品開発チームに完全に統合されると、タイプ2のトポロジーが得られますが、この場合、DevとOpsの違いはごくわずかであるため、すべての従業員は共通の目標に完全に集中します。 原則として、これはタイプ1の種類の1つですが、独自の特性があります。



単一の純粋なデジタル製品を顧客に提供するNetflixやFacebookのような企業は、タイプ2トポロジーを使用しますが、組織が顧客に複数の製品を提供する場合、このアプローチの適用範囲は限られると思います。 通常、複数の製品を生産する組織で見られる予算の制約とコンテキストスイッチングの必要性により、開発部門と運用部門の間の距離が長くなる可能性があります（ タイプ1トポロジを使用）。



タイプ2は「NoOps」と呼ばれることもあります。これは、このモデルには別個または表示可能なOpsコマンドがないためです（ただし、NetflixのNoOpsモデルもタイプ3 （IaaSなどのOps）に似ています）。









タイプ2適用性：単一の完全デジタル製品を提供する組織

潜在的な効率： 高

タイプ3：IaaSとしての運用（サービスとしてのインフラストラクチャ）

急速に変更できない、または変更しない従来のIT Opsユニットを持つ組織、およびすべてのアプリケーションにAmazon EC2、Azureなどのパブリッククラウドを使用する組織の場合、Opsをチームとして扱うと便利です。これにより、アプリケーションがインストールおよび実行される柔軟なインフラストラクチャが提供されます。 このモデルでは、OpsコマンドはAmazon EC2、つまりIaaS（サービスとしてのインフラストラクチャ）アプローチに似ています。



このスキームでは、別のチーム（仮想の場合もあります）がDev内で作業し、運用機能、メトリック、監視、サーバー展開などの専門知識の中心として機能します。 彼女はまた、IaaSチームとのすべてのコミュニケーションの面倒を見ることができます。 このチームは本質的に開発者であり、TDD、CI、反復開発などの標準的なプラクティスを使用しています。



実装を簡素化するために、IaaSトポロジの有効性は限られています（Opsチームとの連携が失われたため）が、 タイプ1を直接実装しようとする場合（次の開発ステップになる可能性があります）よりも速く結果を得ることができます。









タイプ3の適用可能性：従来のIT運用部門を持つ、いくつかの異なる製品とサービスを持つ組織。 アプリケーションがパブリッククラウドで完全に実行される組織

潜在的な効率： 中

タイプ4：外部サービスとしてのDevOps

一部の組織、特に小規模な組織では、ソフトウェアに関連する運用タスクに適切に対処するための財源、経験、または有資格者がいない場合があります。 この場合、開発チームは、Rackspaceなどの外部サービスプロバイダーを見つけて、テスト環境システムの構築、インフラストラクチャの自動化、監視の構築を支援し、開発中に実装する必要がある非機能要件に関するアドバイスを提供できます。



このオプションは、小規模な組織や、自動化、監視、または構成管理への最新のアプローチについて実践的に学びたいチームに役立ちます。 将来、組織が成長し、運用活動に重点を置いて人々が組織に登場すると、組織はタイプ3またはタイプ1モデルに移行できるようになります。









タイプ4の適用可能性： IT運用の経験が少ない小規模のチームおよび組織

潜在的な効率： 中

タイプ5：ライフタイムDevOpsチーム

このモデルは、 アンチタイプB （「プロット」DevOps）と同じように見えますが、DevOpsチームのタスクと寿命は根本的に異なります。 一時的なDevOpsチームは、DevとOpsを近づけ、理想的にはType 1またはType 2に持ち込み、無用のために自己排除するという使命を持って作成されます。



一時的なチームのメンバーは、最初に開発チームと運用チームの間の「翻訳者」として働き、一方で運用チーム用のスタンドアップやかんばんボードなどのクレイジーなアイデアを提供し、一方で、設定のような低レベルの「キッチン」を考えている開発者チームと協力しますバランサー、SSLオフロード、またはネットワークコントローラーの管理。 十分な人が開発と運用の融合に価値を見出し始めれば、DevOpsチームは目標を達成する本当のチャンスを得ます。 重要：アプリケーションの実装または運用に対する長期的な責任は、一時的なチームに「ハング」させないでください。そうしないと、このスキームはすぐにアンチタイプBに変わります。









タイプ5適用性：これはタイプ1の前兆ですが、 アンチタイプBになるリスクがあります。

潜在的な効率： 低から高

タイプ6：DevOpsエバンジェリストチーム

DevとOpsの間に大きなギャップがある（またはこのギャップを広げる傾向がある）組織内では、DevとOps間の通信をサポートするDevOpsチームを作成することが役立つ場合があります。 これは、DevOpsチームが継続的に存在するタイプ5ベースのバージョンですが、そのタスクは、DevチームとOpsチーム間のコミュニケーションと相互作用を促進することです。 このDevOpsチームのメンバーは、DevOpsプラクティスに関する知識を広めるため、しばしば伝道者と呼ばれます。









タイプ6適用性： DevとOpsに距離を置く傾向がある組織。 危険- アンチタイプBへのスライド

潜在的な効率： 中から高

タイプ7：SREチーム（Googleモデル）

DevOpsは通常、電話で勤務中のDevチームを巻き込むことを推奨していますが、これは必須ではありません。 実際、一部の組織（Googleを含む）は異なるモデルを使用しており、開発チームから運用を担当するチーム（SRE（Site Reliability Engineering））へのソフトウェア転送の明示的な儀式があります。 このモデルでは、開発チームはSREチームに証拠（ログ、メトリックなど）を提示し、送信されたアプリケーションがSREでサポートされるのに十分な信頼性があることを明確に示す必要があります。



重要なこと-SREチームは、SRE標準を満たさないアプリケーションをサポートしない場合があり、アプリケーションが商用操作モードになる前に特定の「機能」をやり直すように開発者に要求する場合があります。 開発チームとSREチームの相互作用は運用指標を中心に展開されますが、SREチームがアプリケーションの品質に満足すると（開発チームではなく）、SREはこのソフトウェアのサポートを開始します。









タイプ7適用可能性：タイプ7は、エンジニアリング文化と組織の成熟度が高い組織にのみ適用されます。 そうしないと、SRE / Opsコマンドが単にソフトウェアをインストールするための指示を受け取り、それに従っているAnti-Type Aを取得するリスクがあります。

潜在的な効率： 低から高

タイプ8：コンテナベースのコラボレーション

アプリケーションランタイムをコンテナに配置すると、開発と運用のコラボレーションの本当の必要性がなくなります。 この場合、コンテナは開発部門と運用部門の責任範囲の区切り文字として機能します。 エンジニアリングの成熟度が高い場合、このモデルはうまく機能しますが、Devが運用上の問題を無視し始めると、このオプションは古典的な「私たちは彼らに敵対する」対立に変わる可能性があります。









タイプ8の適用可能性：コンテナーは正常に動作する可能性がありますが、Opsチームが開発チームが投入するものをサポートすることが期待される場合、このオプションはAnti-Type Aに変更できます

潜在的な効率： 中から高

タイプ9：Dev-DBAコラボレーション

このオプションは、 アンチタイプGで説明されている状況への応答です。 開発者とDBAのギャップを埋めるために、一部の組織では、中央データベースの改良を専門とする別の開発チームにDBAチームを近づけています。 これは、データベースをアプリケーションデータが格納されている開発オブジェクトと見なすことに慣れている人と、同じデータベースを膨大な量の複雑なビジネス情報と認識する人との間のコミュニケーションに役立ちます。









タイプ9の適用性：複数のアプリケーションが1つ以上の集中型データベースと連携する組織に適しています

潜在的な効率： 中



PS私たち（Raiffeisenbank）は、今年の夏、 タイプ1 （すべての人にとっての基本的なオプション）とタイプ2 （ターゲットとなることが判明した「高度な」）を検討することに同意しました。 人生は、この選択が正しかったことを示します。



PPSそして元気ですか？ 組織にはどのような種類のDevOpsがありますか？