DevOps 文化を築くときに知っておくと便利なサイト「DevOps Topologies」を読んだ．「アンチパターン = DevOps Anti-Types」な組織構造（計7種類）と「ベストプラクティス = DevOps Team Topologies」な組織構造（計9種類）が紹介されている．サイトではそれぞれの組織構造の解説と関係性を図解した絵が載っていてわかりやすい！本記事ではサイトを翻訳するのではなく，あくまで個人的なメモとしてまとめる．なお，日本語訳も参考程度に載せておいた！
目次
- 1. DevOps Anti-Types
- Anti-Type A: Dev and Ops Silos（Dev と Ops のサイロ化）
- Anti-Type B: DevOps Team Silo（DevOps チームのサイロ化）
- Anti-Type C: Dev Don't Need Ops（Dev が Ops を必要としない）
- Anti-Type D: DevOps as Tools Team（ツールチームとしての DevOps）
- Anti-Type E: Rebranded SysAdmin（リブランディングした SysAdmin）
- Anti-Type F: Ops Embedded in Dev Team（Dev に組み込まれた Ops）
- Anti-Type G: Dev and DBA Silos（Dev と DBA のサイロ化）
- 2. DevOps Team Topologies
- Type 1: Dev and Ops Collaboration（Dev と Ops のコラボレーション）
- Type 2: Fully Shared Ops Responsibilities（完全に共有された Ops 責任）
- Type 3: Ops as Infrastructure-as-a-Service（IaaS としての Ops）
- Type 4: DevOps as an External Service（外部サービスとしての DevOps）
- Type 5: DevOps Team with an Expiry Date（有効期限のある DevOps チーム）
- Type 6: DevOps Advocacy Team（DevOps 推進チーム）
- Type 7: SRE Team（SRE チーム）
- Type 8: Container-Driven Collaboration（コンテナ駆動コラボレーション）
- Type 9: Dev and DBA Collaboration（Dev と DBA のコラボレーション）
1. DevOps Anti-Types
🌀 Anti-Type A: Dev and Ops Silos（Dev と Ops のサイロ化）
「Anti-Type A: Dev and Ops Silos」は，よく知られた Dev と Ops の間に壁があるような状況で，お互いにコンテキストが合わないためにソフトウェアの開発と運用に問題が出てしまう．2009年に Flickr によって提唱された「Dev and Ops」に似ていると思う．
🌀 Anti-Type B: DevOps Team Silo（DevOps チームのサイロ化）
「Anti-Type B: DevOps Team Silo」は，独立した「DevOps チーム」が作られて，また別のサイロ化が進んでしまう状況のことを表現している．単純に「DevOps」というバズワードに翻弄されている可能性もあるし，僕自身も数年前に「DevOps Engineer」という肩書を使っていた経験もあり実際の現場ではよくありそう！ただ一時的に「Dev と Ops を近付ける目的」で「DevOps チーム」を作るのは効果があるとも書かれている．その場合は，後半に出てくるベストプラクティス「Type 5: DevOps Team with an Expiry Date」となる．
個人的には以下の Netflix のプレゼンテーション「How Netflix Thinks of DevOps」に出てくる「DON'T DEVOPS / DO CULTURE」というフレーズが好きで，この YouTube は何度も繰り返し観ている．おすすめ！
🌀 Anti-Type C: Dev Don't Need Ops（Dev が Ops を必要としない）
「Anti-Type C: Dev Don't Need Ops」は，Dev 主導で DevOps を実現する組織構造となり，最初はベストプラクティスなのでは？と感じたけど，意味としては，例えば「クラウドを使えば Ops は不要」というような思想から「運用の必要性」を過小評価してしまっている状況のことを表現している．その後，運用の波が押し寄せて，ある意味で現実を知ることになると「Type 3: Ops as Infrastructure-as-a-Service」や「Type 4: DevOps as an External Service」に進化していく．
🌀 Anti-Type D: DevOps as Tools Team（ツールチームとしての DevOps）
DevOps を実現するために，例えば「継続的デリバリーパイプライン」を構築したり，「構成管理」の仕組みを作ったり，自動化ツールの開発にフォーカスしすぎてしまう状況のことを表現している．個人的には「Anti-Type B: DevOps Team Silo」にも似ていると感じた．当然ながらツールチェーンが整うことによる価値はあるけど，Dev と Ops のコラボレーションが実現できない点に再検討の余地がある．
Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス
- 作者:Kief Morris
- 発売日: 2017/03/18
- メディア: 単行本（ソフトカバー）
🌀 Anti-Type E: Rebranded SysAdmin（リブランディングした SysAdmin）
よく知られた SysAdmin（システム管理者）という役割をリブランディングして DevOps（やることは SysAdmin と同じ）として採用を進めているような状況のことを表現している．エンジニアリングの成熟度が低い組織で起きると書いてある．重要なのは，役割をリブランディングしただけでは「文化的／組織的な価値」は生まれないことだと思う．「Anti-Type A: Dev and Ops Silos」や「Anti-Type C: Dev Don't Need Ops」にも関連するけど「DevOps」というバズワードに翻弄されていると Anti-Type に近付いてしまう．
🌀 Anti-Type F: Ops Embedded in Dev Team（Dev に組み込まれた Ops）
組織は Ops を長く存続させたくなく，Dev に「インフラ構築」や「モニタリング」などを担当させる．しかし，プロダクト主導で行うと中途半端になる可能性があると書いてある．解説では，後半に出てくる「Type 2: Fully Shared Ops Responsibilities」とは違うと書いてある．ようするに「中途半端になるな！」ということだと理解したけど，個人的にはベストプラクティスなのでは？と感じたし，わかりにくかった．
🌀 Anti-Type G: Dev and DBA Silos（Dev と DBA のサイロ化）
レガシーで大規模な組織構造において，専任の DBA (Database Administrator) がデータベース関連タスクを担当している状況のことを表現している．重要なのは DBA の良し悪しではなく，データベースに関係するリリースの全てを DBA に頼むため，継続的デリバリーの観点で DBA がボトルネックになってしまう．過去に似た経験もあり，イメージしやすかった．
2. DevOps Team Topologies
次に「ベストプラクティス = DevOps Team Topologies」を紹介する．それぞれに「Potential effectiveness（潜在的な有効性）」という効果を表す指標も載っている．
⭐️ Type 1: Dev and Ops Collaboration（Dev と Ops のコラボレーション）
- Potential effectiveness:
HIGH
「Anti-Type A: Dev and Ops Silos」で紹介した「Dev and Ops」に載っている DevOps のイメージに非常に近いと思う．Dev と Ops がコラボレーションをしながら，それぞれの技術的な専門性を共有していく．具体的な例としては，Dev はログのことを深く考えて実装したり，Ops は TDD (Test-Driven Development) を理解したり Git の操作に慣れたりすると書いてある．
⭐️ Type 2: Fully Shared Ops Responsibilities（完全に共有された Ops 責任）
- Potential effectiveness:
HIGH
Dev と Ops の役割が完全に共有（オーバーラップ）されている．チーム全員が同じ目標に向けて集中している．Netflix や Facebook などウェブサービスを提供していると実現しやすいけど，多くの場合では適用しにくく「Type 1: Dev and Ops Collaboration」のように Dev と Ops の役割は分割されていくと書いてある．本当？個人的には1番好きな組織構造だと感じた．関連した役割としては Netflix の提唱する「Full Cycle Developers」という考え方もとても好き！
⭐️ Type 3: Ops as Infrastructure-as-a-Service（IaaS としての Ops）
- Potential effectiveness:
MEDIUM
クラウドを活用することにより，アプリケーションをデプロイしたり，拡張性を高めることができる．特にコードでインフラを操作できるようになるため，Dev が運用のことを考えながら進めやすくなる．納得できる内容だった．最初から「Type 1: Dev and Ops Collaboration」に挑戦するよりも素早く価値を引き出せると書いてある．
⭐️ Type 4: DevOps as an External Service（外部サービスとしての DevOps）
- Potential effectiveness:
MEDIUM
特に小規模な組織だと，ソフトウェアの運用を主導するための資金や経験やメンバーがいない場合がある．そこで，例えば Rackspace などのサービスプロバイダーと連携をして，サポートを受けながら学んでいく．その後「Type 3: Ops as Infrastructure-as-a-Service」もしくは「Type 1: Dev and Ops Collaboration」に移行していく．
⭐️ Type 5: DevOps Team with an Expiry Date（有効期限のある DevOps チーム）
- Potential effectiveness:
LOW to HIGH
組織構造としては「Anti-Type B: DevOps Team Silo」に似ているけど，チームとしての寿命が異なる．最終的にベストプラクティスの「Type 1: Dev and Ops Collaboration」や「Type 2: Fully Shared Ops Responsibilities」を目指すために一時的な責任を与える．コラボレーションを実現するために「スタンドアップ」や「カンバン」などの DevOps プラクティスを組織に広めていく．さらに技術的な検証や実装も進めていく．「Anti-Type B: DevOps Team Silo」にならないように気を付ける．
⭐️ Type 6: DevOps Advocacy Team（DevOps 推進チーム）
- Potential effectiveness:
MEDIUM to HIGH
「Type 5: DevOps Team with an Expiry Date」で長期的な責任を与えるべきではないと書いてあったけど「Type 6: DevOps Advocacy Team」は，継続的に Dev と Ops のコラボレーションを推進する役割を担当する．DevOps プラクティスを組織に広めていくことから「DevOps 推進者（アドボケイト）」と呼ばれることもあると書いてある．「Anti-Type B: DevOps Team Silo」にならないように気を付ける．
⭐️ Type 7: SRE Team（SRE チーム）
- Potential effectiveness:
LOW to HIGH
DevOps では，Dev もオンコール（障害対応）に参加することが推奨されている．例えば Google により提唱されている SRE (Site Reliability Engineering) モデルを採用して，ソフトウェア開発に対してサポートを受けることもできる．サイトに載っている図解によると Dev / Ops / DevOps / SRE それぞれの役割が少しずつオーバーラップしている．さらに SRE はコード（実装）の見直しまで手を出す点もポイントと言える．「Anti-Type A: Dev and Ops Silos」にならないように気を付ける．
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- 発売日: 2017/08/12
- メディア: 単行本（ソフトカバー）
⭐️ Type 8: Container-Driven Collaboration（コンテナ駆動コラボレーション）
- Potential effectiveness:
MEDIUM to HIGH
Kubernetes の普及など，コンテナワークロードが一般的になった今，アプリケーションのデプロイやランタイム要件をコンテナイメージとしてカプセル化できるようになった．エンジニアリング文化をうまく築けていると，コンテナは Dev と Ops の境界として機能すると書いてある．しかし，コンテナワークロード特有の運用もあることも忘れないこと！「Anti-Type A: Dev and Ops Silos」にならないように気を付ける．
⭐️ Type 9: Dev and DBA Collaboration（Dev と DBA のコラボレーション）
- Potential effectiveness:
MEDIUM
Dev と DBA (Database Administrator) の溝を埋めるために，能力を補完しながらコラボレーションを実現する．大規模なデータベースを管理している組織に適していると書いてある．それ以上は具体的に書かれてなく，少しイメージしにくかった．「Anti-Type G: Dev and DBA Silos」にならないように気を付ける．
まとめ
DevOps 文化を築くときに知っておくと便利なサイト「DevOps Topologies」を読んだ．実際に組織構造がパターン化されているとイメージしやすく，再利用性も高そうに感じた．興味があったら是非サイトを見てみてもらえればと！
関連記事
今思うと，数年前に経験した「DevOps 推進タスク」は「Type 5: DevOps Team with an Expiry Date（有効期限のある DevOps チーム）」に似ているように感じた．
コラボレーションを実現するなら「Effective DevOps」も合わせて読むと良さそう！
