2009年、Yahoo傘下の写真共有サイトFlickrはサービスを絶えず更新していた。業界の既定の分業、すなわち開発者が機能を出荷し運用がサイトの安定を保つという構図は、あらゆる変更を闘争に変えていた。変更はほとんどの障害の根本原因であるため、サイトを最も厳しく「守る」チームこそが最も遅く出荷するチームだった。

変更をまれにするのではなく安全にする。共通ツール(フィーチャーフラグ、ワンステップのデプロイ、共有メトリクス、チャットロボット)と非難しない文化が、1日10回以上のデプロイを日常にした。

運用側のマネージャーJohn Allspawとエンジニアリング側のマネージャーPaul Hammondは、共同の責任のもとでリリースを再構築した。自動化されたインフラ、共有の単一バージョン管理トランク、ワンステップのビルドとデプロイ、フィーチャーフラグ、共有メトリクスのダッシュボード、IRCチャットロボット。それに加えて、尊重、信頼、失敗に対する健全な姿勢、非難の回避という明示的な文化の一覧を掲げた。

2009年6月のVelocityでの彼らのセッションは、会議中のどの講演よりも注目を集め、ツールと文化という枠組みはDevOpsの手引きの中核となった。数か月後、この運動はヘントで開かれた最初のdevopsdaysで自らを名乗り、「1日あたりのデプロイ回数」は業界のベンチマークになった。

2009年までに、Yahoo傘下の写真サイトFlickrは絶えず出荷していた。通常の日でも、ウェブサイトの完全なデプロイを本番に対して10回以上行っていた。その年の6月、サンノゼで開かれたO'ReillyのVelocityカンファレンスで、Flickrの運用側とエンジニアリング側を率いる2人のマネージャー、John AllspawとPaul Hammondが、「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」と題した講演でその方法を説明した。Data Center Knowledgeの会議報告は、これをイベントで最も話題を呼んだプレゼンテーションと呼んだ。

彼らの主張は、業界の既定の組織図を攻撃するものだった。開発者が機能を追加し、運用がサイトの安定と速度を保つというステレオタイプは、変更を敵に変える。変更はほとんどの障害を引き起こすからだ。AllspawとHammondはこれを逆転させた。運用の仕事はビジネスを可能にすることであり、ビジネスは変更を必要とする。だから本当の仕事は、ツールと文化によって変更のリスクを下げることだ。ツールキットは、自動化されたインフラ、共有のバージョン管理トランク、ワンステップのビルドとデプロイ、コードをユーザーに見せないまま出荷できるフィーチャーフラグ、共有メトリクス、そして誰でもリリースの様子を見られるIRCロボットだった。

もう半分は文化だった。尊重、信頼、失敗に対する健全な姿勢、非難の回避。これには、失敗は必ず起きるものだから、ジュニアのエンジニアでも本番障害を実際に経験しておけるようにする消防訓練も含まれた。その10月、Patrick Deboisはベルギーのヘントで最初のdevopsdaysを開催した。そのイベントから名を得た運動は、Flickrの講演の枠組み、すなわちツールを共有し誰も非難しないチームによる小さく安全で頻繁なリリースを、世界中のエンジニアリング組織に広めた。

それは本当の制約に名前を与えた。ウェブビジネスではリリースの列車こそがビジネスであり、1日に10回安全にデプロイできるチームは、月に1回しか出荷しないチームを単純に学習で上回る。

共通ツールは共通の運命を生み出した。単一のトランク、単一のダッシュボード、単一のデプロイボタン。だからどちらの側も、相手を負かすことで勝つことはできなかった。

それは運用を、安定性の守護者から変更の実現者へと再定義し、自動化と文化をただ一つの問いで評価できるようにした。すなわち、どれだけ頻繁に安全に出荷できるか。

それは非難を、性格の欠陥ではなくエンジニアリングの欠陥として扱った。人が過ちを隠せばリスクは静かに積み上がる。消防訓練と非難しないレビューが情報の流れを保つ。

スループットは、変更をまれにするのではなく安全にすることから生まれる。共通ツールは共通の運命を生み、非難はエンジニアにリスクを隠すことを教え、運用はビジネスを可能にするのであって、ビジネスから稼働時間を守るのではない。

セッションの録画は今もオンラインにあり、今もDevOpsの創設物として示されている。その10月、Deboisによるヘントでの最初のdevopsdaysがこの運動に名前を与え、「1日に何回デプロイするか」はベンチマークであると同時に挑戦状になった。Allspawはその手法をEtsyに持ち込み、そこでは非難しないポストモーテムや継続的デプロイといった類縁の手法がそれ自体で有名になった。15年後、デプロイ頻度は標準的なエンジニアリング指標であり、「開発対運用」は主に、この講演が打ち壊した藁人形として生き残っている。

出典をたどる

出典

  1. Velocity: Flickr on Devs, Ops and Teamwork Data Center Knowledge · datacenterknowledge.com ·
  2. 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr dev2ops · dev2ops.org ·
  3. It's the 5th Anniversary of DevOps dev2ops · dev2ops.org ·
  4. About devopsdays devopsdays.org · devopsdays.org