DevOps では、開発によって運用と保守の時間が奪われるのでしょうか?

[[208368]]

ほとんどのチームでは、開発と運用・保守の間で一連の対立や駆け引きが起こります。

DevOps の登場により、開発と運用・保守は互いに好き嫌いの関係ではなくなり、これからは両者が手を取り合って楽しくコーディングし、バグをキャッチするようになるという人もいます。

しかし、DevOps では開発に運用と保守の時間が取られると言う人もいます。

これは本当ですか？異なるチーム構造は DevOps の開発にどのような影響を与えますか?

以下を読んでいただければ、あなた自身の答えが見つかるでしょう。

導入

組織内で開始される DevOps 関連のアクティビティの主な目的は、コストの削減、自動化の向上、構成管理からの何かの推進ではなく、顧客とビジネスへの価値提供を改善することです。つまり、効果的な開発と運用のコラボレーションを実現するために、組織によって異なるチーム構造が必要になる可能性があります。

まとめ

どの DevOps チーム構造またはトポロジが組織に適しているかは、いくつかの要素によって決まります。

• 組織の製品ポートフォリオ: コンウェイの法則によれば、製品が少ないほど、小規模で独立したチームの数が少なくなるため、コラボレーションが容易になります。
• 技術的リーダーシップの範囲、強さ、有効性。開発と運用に共通の目標があるかどうか。
• 組織には、IT 運用部門を「ハードウェア ラック」や「サーバーの構成」から実際にバリュー ストリームに合わせるように変更するニーズや能力がありますか。また、ソフトウェア開発チームは運用からの要件を真剣に受け止めていますか。
• 組織には、現在の運用上の問題の解決を主導する能力やスキルがありますか?

もちろん、ここで説明するトピックはさまざまです。トポロジとタイプは、どのパターンが適切かを評価するのに役立つ参照ガイドまたはヒューリスティックとして意図されています。実際、複数のモードを組み合わせたり、1 つのモードを別のモードに変換したりすることが、多くの場合、最善のアプローチとなります。

では、DevOps チームの構造はどのように進化するのでしょうか?明らかに、すべての組織に適した理想的な構造やチーム トポロジは存在しません。ただし、チーム構造については、いくつかの異なるモデルを参照することが有用であり、そのうちのいくつかは他のモデルよりも特定の組織に適しています。コンウェイの法則を考慮しながら、これらのチーム構造 (または「トポロジ」) の長所と短所を検討することで、組織内での DevOps 実践に最も効果的である可能性が高いチーム構造を特定できます。

これらの DevOps トポロジのほとんどは他の場所で説明されています。特に、CollabNet の Lawrence Sweeney は、私がここで Ben Kepes のブログへのコメントで説明しているアンチタイプ B (独立した DevOps チーム) について語っています。

タイプ 3 (インフラストラクチャ サービスとしての運用) とタイプ 1 (開発と運用のコラボレーション)。 DevOpsGuys は 12 個の DevOps アンチパターンをリストしており、Jez Humble、Gene Kim、Damon Edwards (およびその他多数) も同様のことを言っています。ここでは、これまでいくつかのコンテキストで見たことも聞いたこともない 3 つの「トポロジ」を追加しました (共有オペレーション、DevOps-as-a-Service、およびアドホック DevOps チーム)。

DevOps アンチタイプ

「アンチタイプ」（広く普及した「アンチパターン」にちなんで）と呼ぶことができるいくつかの悪い習慣を調べることは有益です。

A: 開発と運用が分離されているB: DevOps チームが別々であるC: 開発には運用と保守は不要D: ツールチームE: システム管理者F: 開発には運用と保守が含まれるG: 開発と DBA が分離されている

反タイプA: 開発と運用の分離

これは、開発と運用を「壁越しに投げる」という典型的な分離です。これは、要件が早期に抽出される可能性があることを意味します (DONE は「機能的に完了」を意味しますが、運用では使用できません)。開発者には運用に関連するコンテキスト情報がないため、ソフトウェアの保守性が損なわれ、運用担当者はソフトウェアがオンラインになる前に開発者と協力して問題を解決する時間も意欲もありません。

このタイプのトポロジが悪いことは誰もが知っていますが、同様の悪いトポロジはたくさんあると思います。少なくとも、反タイプA（開発と運用の分離）が問題であることはわかっています。

反タイプB: DevOpsチームを別にする

独立した DevOps チーム (反タイプ B) は、通常、マネージャーまたは幹部が「DevOps を少し取り入れる必要がある」と判断し、「DevOps チーム」(おそらく「DevOp」と呼ばれる人物) を立ち上げることから生まれます。 DevOps チームのメンバーはすぐに別のグループを結成し、自分たちの役割、スキル、ツールセットが「無知な開発者」や「時代遅れの運用者」によって消滅するのを防ぐ必要があったため、これまで以上に開発と運用を分離しました。

独立した DevOps チームの存在が本当に意味を持つのは、チームが一時的であり、12 か月または 18 か月未満しか存続せず、Dev と Ops の連携を強めるという明確な目的があり、明示的に義務付けられている場合のみであり、その期間が終了すると、チームは不要になります。これは私がタイプ 5 DevOps トポロジと呼んでいるものです。

反タイプC: 開発には運用とメンテナンスは不要

このトポロジは、特に新しいプロジェクトやシステムの開始時に、開発者と開発マネージャーの無知と傲慢さの組み合わせから生じます。開発者は、Ops が過去のものになったと想定し (「今はクラウドがありますよね?」)、運用スキルとアクティビティの複雑さと重要性を過小評価し、Ops がなくてもやっていける、または Ops が行っていることを余暇にできると考えます。

この反タイプ C DevOps トポロジでは、ソフトウェアがより深く複雑になり、運用に開発作業 (コーディングともいう) が必要になり始めると、最終的にタイプ 3 (Ops as IaaS) またはタイプ 4 (DevOps-as-a-Service) のトポロジが必要になる場合があります。そのようなチームが運用を重要かつ価値のある分野として認識し、ソフトウェア開発におけるその重要性を認識していれば、多くの面倒で不必要な（そしてかなり基本的な）運用ミスを回避できるでしょう。

反タイプD: ツールチームとしてのDevOps

現在の開発チーム (ユーザー ストーリーの実装) の速度に影響を与えずに、デプロイメント パイプライン、構成管理、環境管理などに必要なツールを担当する DevOps チームを編成します。その間、運用担当者はサイロ内で作業を続け、開発チームはアプリケーションを「壁の向こう側」に置き続けます。

この献身的なチームの作業は、ツールチェーンの改善という点では有益かもしれませんが、その影響は限られています。根本的な問題は、アプリケーション開発ライフサイクルの早い段階での運用の関与とコラボレーションが不足していることにあります。

アンチタイプE: 変装したシステム管理者

このアンチタイプは、エンジニアリングの成熟度が低い組織でよく見られます。彼らは業務を改善し、コストを削減したいと考えていますが、IT をビジネスの中核的な推進力として認識していません。 DevOps の業界での成功が明らかになったため、彼らも「DevOps を実行」したいと考えています。残念なことに、彼らは現在の構造と関係のギャップを反省する代わりに、運用チームに「DevOps エンジニア」を雇いました。

DevOps は、SysAdmin と呼ばれる役割の単なるブランド変更であり、実際の文化的/組織的な変化は起こっていません。平凡な採用担当者は自動化とツールのスキルを持つ候補者のみを探すため、この逆のパターンはますます広まりつつあります。残念ながら、DevOps を組織内で成功させるのは、人材のスキルです。

反タイプF: 運用と保守は開発チームに組み込まれている

組織は別個の運用チームを必要としないため、開発チームがインフラストラクチャ、環境の管理、監視などを担当します。ただし、このようなプロジェクトまたは製品主導のアプローチでは、これらのプロジェクトはリソースが制限され、優先順位によって運用方法が不十分になり、ソリューションが中途半端になります。

このアンチタイプでは、組織は効果的な IT 運用に必要な重要性とスキルを認識していません。

反タイプ G: 開発者と DBA の分離

これは、複数のレガシー システムが同じコア データ セットに依存している中規模から大規模の企業でよく見られる、反タイプ A (開発と運用の分離) の一種です。これらのデータベースはビジネスにとって非常に重要であるため、多くの場合、メンテナンス、パフォーマンス チューニング、および災害復旧を担当する専任の DBA チームが社内に存在します。これは理解できますが、問題は、このチームがデータベースの変更の玄関口となり、事実上、小規模で頻繁なデプロイメント（DevOps と継続的デリバリーの中核となる原則）の障壁となることです。

さらに、アンチタイプ A と同様に、DBA チームはアプリケーション開発の初期段階には関与していないため、データの問題 (移行、パフォーマンスなど) は配信サイクルの後半になってから発見されます。複数のアプリケーション データベースをサポートすることによる過負荷と相まって、最終的には、問題解決と展開のプレッシャーが絶え間なく発生します。

DevOps チームのトポロジ

アンチタイピングの反対側に立って、DevOps に適したトポロジをいくつか見てみましょう。

1: 開発と運用のコラボレーション 2: 共有運用 3: インフラストラクチャ サービスとしての運用 4: DevOps-as-a-Service 5: 臨時 DevOps チーム 6: DevOps エバンジェリスト チーム 7: SRE チーム 8: コンテナ ドライバー 9: データベース機能

タイプ1: 開発と運用との連携

これは DevOps の「約束の地」です。開発チームと運用チームの間でスムーズに連携し、それぞれの分野が必要な場所に存在しながらも共有されます。多数の独立した開発チームが存在し、それぞれが別個または半独立した製品スタックに取り組んでいる場合があります。

つまり、このタイプ 1 モデルを確立するには、技術管理チーム間の高いレベルの競争力を伴う、かなりの組織変更が必要であるということです。開発者と運用部門は、明確に定義された明確な共通の目標 (「高品質の提供、変化の受け入れ」など) を持っている必要があります。運用担当者は、テスト駆動型コーディング スキルと Git ツールを習得するために開発者とペアを組む必要があり、開発部門は運用機能のリクエストを真剣に受け止め、ログの実装に参加する運用担当者を探す必要があります。これらすべてを現在の状態からこの状態に移行するには、かなりの文化的変化が必要になります。

タイプ 1 適応性: テクノロジー主導の組織。

有効性の可能性: 高

タイプ2: 運用と保守の責任を完全に共有

運用スタッフが製品開発チームに統合されている状況では、タイプ 2 トポロジが見られます。開発と運用の間にはほとんど隔たりがなく、全員が共通の目標に重点を置いています。これはタイプ 1 (開発と運用のコラボレーション) の一種ですが、いくつかの特別な機能があります。

Netflix や Facebook などの組織は、Web ベースの製品でこのタイプ 2 トポロジを効果的に実装していますが、予算の制約や複数の製品ライン間で頻繁に発生するコンテキストの切り替えにより、開発と運用をさらに分離する必要が生じる可能性があるため (たとえば、タイプ 1 モデルに戻す)、純粋な製品の観点から以外ではあまり適用できないと思います。このトポロジは、明白または目に見える運用チームが存在しないため、「NoOps」と呼ばれることもあります (ただし、Netflix NoOps はタイプ 3 (IaaS としての Ops) としても可能です)。

タイプ 2 の適応性: 組織には単純な Web ベースの製品またはサービスしかありません。

有効性の可能性: 高

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

非常に伝統的な IT 運用部門を持つ組織では、変化を迅速に受け入れることができない、あるいは受け入れることができません。すべてのアプリケーションをパブリック クラウド (Amazon EC2、Rackspace、Azure など) で実行する組織の場合、運用は、アプリケーションの展開と運用の機能のみを提供する必要がある、回復力のあるインフラストラクチャ チームであると考えられる場合があります。したがって、社内運用チームは、Amazon EC2 または Infrastructure as a Service に直接相当します。

Dev 内のチーム (おそらく仮想チーム) は、運用機能、メトリック、監視、サーバー構成などの専門知識のソースとして機能し、IaaS チームとのコミュニケーションの大部分を担当する可能性があります。ただし、このチームは依然として開発チームであり、TDD、CI、反復開発、人材メンタリングなどの標準的なプラクティスに従います。

IaaS トポロジには、実装を容易にする潜在的な有効性 (運用担当者との直接的なコラボレーション) があり、後で試みられるタイプ 1 (開発と運用のコラボレーション) よりも早く価値を実現できる可能性があります。

タイプ 3 に適合: さまざまな製品やサービス、従来の運用部門を持つ組織、またはアプリケーションが完全にパブリック クラウドで実行される組織。

有効性: 中程度

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

一部の組織、特に小規模な組織では、ソフトウェア運用を主導するための資金、経験、またはスタッフが不足している場合があります。開発チームは、テスト環境の設定やインフラストラクチャと監視の自動化の支援を求めて、Rackspace などのサービス プロバイダーに連絡し、ソフトウェア開発サイクルで実装されるさまざまな運用機能に関するアドバイスを受ける場合があります。 DevOps-as-a-Serviced と呼ばれるものは、自動化、監視、構成管理の目的と実装を理解している小規模な組織またはチームであり、ビジネスが成長して従業員が増えると、タイプ 3 (IaaS としての運用) またはタイプ 1 (開発と運用のコラボレーション) モデルに移行する可能性があります。

タイプ 4 の適応性: 運用経験がほとんどない小規模なチームまたは組織。

有効性: 中程度

タイプ5: 期限のあるDevOpsチーム

有効期限のある DevOps チーム (タイプ 5) は、アンチタイプ B (DevOps チーム サイロ) に似ていますが、意図と存続期間はまったく異なります。このアドホック チームの任務は、開発と運用をより緊密に連携させ、理想的にはタイプ 1 (開発と運用のコラボレーション) またはタイプ 2 (運用責任の完全共有) モデルに近づけ、最終的にはチーム自体を廃止することです。アドホック グループのメンバーは、開発部門の話し方と運用部門の話し方を「翻訳」し、運用チーム向けにスタンドアップやカンバン ボードなどの斬新なアイデアを紹介し、開発チーム向けにロード バランサー、NIC の管理、SSL のオフロードなどの「面倒な」詳細について検討します。十分な数の人々が開発と運用を統合することの価値を理解し始めれば、アドホック チームが目標を達成できる可能性が高まります。重要なのは、デプロイメントおよび本番環境の長期的な分析診断の責任をアドホック チームに与えてはならないということです。そうしないと、孤立した DevOps チーム (反タイプ B) になってしまう危険性があります。

タイプ 5 の適応性: 運用経験がほとんどない小規模なチームまたは組織。

有効性の可能性: 低～中

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

Dev と Ops の間に大きなギャップがある (または大きなギャップが生じる傾向がある) 組織では、Dev 側と Ops 側のコミュニケーションを維持するために「促進」DevOps チームを設置することが効果的です。これはタイプ 5 (有効期限付き DevOps チーム) のバージョンですが、DevOps チームは、Dev チームと Ops チーム間のコラボレーションと協力を継続的に促進するという特定の責任を負って存在します。このチームのメンバーは、DevOps プラクティスの認知度向上に貢献するため、「DevOps エバンジェリスト」と呼ばれることもあります。

「DevOps チーム」の目標は、組織の他の部分を有効にすることでビジネス自体を有効にすることです。 — Twitter: EricMinick

タイプ 6 の適応性: 開発と運用のトレンドが分散型組織に。タイプBの危険に注意してください。

効果: 中〜高

タイプ 7: SRE チーム (Google モデル)

DevOps では、開発チームが定期的なオンコール会議に参加することが推奨されることが多いですが、これは必須ではありません。実際、一部の組織（Google を含む）では、開発チームからソフトウェアを実行するチーム（サイト信頼性エンジニアリング (SRE) チーム）への明示的な「引き継ぎ」を伴う異なるモデルを実行しています。このモデルでは、開発チームは、ソフトウェアが十分な基準を満たしており、SRE チームによってサポートされていることを示すために、SRE チームにテストの証拠 (ログ、メトリックなど) を提供する必要があります。

最も重要なのは、SRE チームが運用基準を満たさないソフトウェアを拒否し、本番環境に導入する前に開発者にコードの改善を要求することができることです。開発チームと SRE チームのコラボレーションは運用標準に基づいて行われますが、SRE チームがコードに満足したら、開発チームではなく SRE チームが本番環境でコードをサポートします。

タイプ 7 の適応性: タイプ 7 は、エンジニアリングと組織の成熟度が高い組織にのみ適しています。 SRE/Ops チームに「JFDI」デプロイを指示された場合は、アンチタイプ A に戻ることに注意します。

有効ポテンシャル: 低～高

タイプ8: コンテナ駆動型コラボレーション

コンテナは、アプリケーションのデプロイメントとランタイム要件をコンテナにカプセル化することで、開発と運用の間の特定のコラボレーションの必要性を排除します。このように、コンテナは開発と運用の間の責任の境界となります。優れたエンジニアリング文化があれば、コンテナ駆動型のコラボレーション モデルはうまく機能しますが、開発者が運用側が考慮する必要のある事項の一部を無視し始めると、「私たち対彼ら」という構図に変わってしまう可能性があります。

タイプ 8 の適応性: コンテナーはうまく機能しますが、運用チームが開発チームが出荷したものを実行することが期待される反タイプ A には注意してください。

効果: 中〜高

タイプ9: 開発とDBAのコラボレーション

開発チームと DBA チームの溝を埋めるために、一部の組織では、DBA チームのデータベース機能が開発チームのデータベース機能 (または専門知識) に見合ったタイプ 9 と同様のデータベース機能を実験しています。これは、データベースの開発中心のビュー (基本的にはアプリケーションの仮想永続ストアとして) とデータベースの DBA 中心のビュー (インテリジェントで豊富なビジネス価値のソースとして) の間の切り替えに役立つようです。

タイプ 9 の適合性: 1 つ以上の大規模な中央データベースに接続する複数のアプリケーションを持つ組織向け。

有効性: 中程度

覚えておいてください: 特定の組織に「適切な」チーム トポロジは存在しませんが、「不適切な」トポロジはいくつか存在します。