Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

Agile and DevOps の歴史をチェリーピック

Agile and DevOps の歴史をチェリーピック

Yasunobu Kawaguchi

September 13, 2022
Tweet

More Decks by Yasunobu Kawaguchi

Other Decks in Technology

Transcript

  1. ITバブル崩壊 2009年 リーマンショック 2001年 先アジャイル期 アジャイル期 DevOps期 2020年 2022年 2020年のコロナ禍と、

    2022年の戦争やインフレ・円安が、 大きな変動であるのは間違いないと思うので、 何か生活のヒントがあるかもしれない。 まことに勝手なる歴史観
  2. スクラム the ORIGIN : Jeff Sutherland - Roots of Scrum

    (2005) を語るナラティブ 川口恭伸 株式会社ホロラボ アギレルゴコンサルティング株式会社 シニアアジャイルコーチ
  3. https://www.infoq.com/presentations/The-Roots-of-Scrum/ Roots of Scrum (2005) について スクラムの Co-Creator である ジェフ・サザーランド博士が

    スクラムを作る前に参考にしたり、 作りながら実験した話。 なぜスクラムなのか? 2011年に初めて野中先生と顔を あわせるのですが、その6年前。 北米でもスクラムが劇的に広まる 少し前、だと思います。
  4. スクラムの源流 いかにして日本の製造業が 世界のソフトウェア開発 プラクティスを変革したか JAOO, Aarhus, Denmark, 28 Sep 2005

    ジェフ・サザーランド Ph.D. 認定スクラムマスター研修、スクラムプロセスの開発者 https://www.infoq.com/presentations/The-Roots-of-Scrum/
  5. https://www.infoq.com/presentations/ The-Roots-of-Scrum/ オリジナルのスライド ジェフ・サザーランド ・アジャイルシステムズアーキテクト - 9つのソフトウェア企業でCTO/VPoE - 4つの企業でスクラムのプロトタイプ -

    1993年にEasel社で 最初のスクラムを考案、実施 - 5企業にスクラムを展開 1993-2005 - Ken Schwaber がスクラムを 業界に展開するのを手助けした ・アジャイルマニフェスト起草者、 Agile Alliance 創始者(の一人) ・1/3の時間をスクラム研修、 メンタリング、ピアレビュー、 コンサルティングに https://www.infoq.com/presentations/The-Roots-of-Scrum/
  6. https://www.infoq.com/presentations/The-Roots-of-Scrum/ オリジナルのスライド スクラムの源流 • チームプロセス – シリコンバレーの起業家たち • 竹内・野中 –

    日本の製造業 • 世界をもっとよい場所に – 内なるビジョン • オブジェクト技術とEasel社のSmallTalkプロダクト • オブジェクト指向アーキテクチャ 設計ツールの専門家、ベンダー、顧客 • 進化生物学と複雑適応系 • プロセスと生産性の研究 • ソフトウェア生産性の研究 • 外科手術チーム(人月の神話, IBM) • 邪悪な問題、正しい解決 • ボーランド Quattro Pro プロジェクト • iRobot -サブサンプション・アーキテクチャ
  7. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 北米トヨタ自動車のミッション Toyota Motor Manufacturing North America 1. 米国企業として、地域および米国の経

    済成長に貢献する。 2. 独立した企業として、チームメンバー の安定と幸福に貢献する。 3. トヨタのグループ会社として、お客様 に付加価値を提供することで、トヨタ 全体の成長に貢献する。
  8. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 竹内野中論文(1986)が示した マネジメントスタイル • Type A NASAのウォーターフォール型 • 要求、分析、設計、実装、試験と、

    順に次の工程の部署に引き渡される • Type B 富士ゼロックスのサシミ型 • 前工程と後工程が同席する • Type C ホンダのスクラム型 • 一時は全工程が同席する Jeff SutherlandはこのType Cから、 自らのフレームワークの名前を とった。
  9. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ さらに「より多く」「少ない労力で」 1. 開発の後半になっても、変化する要求を歓迎する。 2. 動くソフトウェアを頻繁に提供する。 3. ビジネスマンと開発者は毎日一緒に仕事をしなけ ればならない。

    スクラムは反復的であり、顧客は要件を変更すること ができ、ソリューションは自己組織化のなかで後発的 に生まれます。 プランニング スケーリング 開発 インプリメント (パッケージング)
  10. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 文化を変える – そこが難しい 旧来の組織 新しい組織 中央集権型 分散型 統一的な視点

    多様な視点 もともとの意味 後発的な意味 分析的 創発的 分析から行動へ 実践して学ぶ 合理性 冗長性 確実性 不確実性 戦略的コンセプト 現地の活動 命令型 参加型 階層的 フラット
  11. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ コマンド&コントロールを打ち破る • 伝統的な企業では、戦略は中央で開発される。 • 創発的な戦略は、ローカルな行動によって自己組 織化される。 - 分散型の認知と行動

    • スクラムチームには自己組織化が求められる - 自律的 - 超越的 - 他家受粉 (Cross-fertilization) • チームは自分で仕事を選ぶ - 個人が自分の仕事を管理する - 経営陣は邪魔をしない
  12. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ Google の戦略: マネジメントを取り除く • Rosing氏がGoogleに入社した2001年当時は、「エンジ ニアリング部門にマネジメントがいました。そして、その 構造は、「そんなことをしてはいけない」と人々に言う傾 向がありました。そこで、Googleは管理職を廃止します。

    現在、ほとんどのエンジニアは3人1組のチームで仕事をし ており、プロジェクトリーダーはチームメンバーの間で交 代しています。何かおかしいことがあれば、それがすでに リリースされたプロダクトであっても、チームは誰にも聞 かずにそれを修正します。アジャイル原則#5, #9, #12 • 「しばらくの間、私には160人の直属の部下がいました」 とRosing氏は言います。マネージャーはいませんでした。 それがうまくいったのは、チームが自分たちのやるべきこ とを知っていたからです。それが人々の頭の中の文化的な スイッチが入りました。あなたがボスだ。出番を待つな。 管理されるのを待ってはいけない。" アジャイル原則#1, #3 • そして、もし失敗しても大丈夫。次のアイデアに向かおう。 「賢くてやる気のある人たちが正しいことをする能力を信 じています」とRosing氏は言います。「それを邪魔するも のが、悪なのです。」 アジャイル原則#5, #12
  13. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタ・プリウス-創発的戦略 • 製品、技術、プロセスの革命 - どの製品ラインにも当てはまらない。新しい視 点で設計されている。 • 多くの技術を使用

    - エンジン、モーター、バッテリー、ブレーキを 組み合わせたハイブリッドシステム • 記録的な速さで開発 - 4年かかるものが15ヶ月で • 重複するフェーズ - 研究、開発、設計、生産 • リーダーが作り、利用し、エナジャイズした場 (Ba)
  14. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 場(Ba)というコンセプト: スクラムの禅(本質) • 個人と組織のダイナミックな相互作用は、自己組織化 チームという形で統合を生み出します。 • それは、個人が相互に作用することができる共通の文 脈を提供するものです。

    • チームメンバーは新しい視点を生み出し、対話を通じ て矛盾を解決します。 • 場(Ba)は、意味の流れとしての知識が出現する、動 きのある共通文脈です。 • 創発された知識はコード化されて動くソフトウェアと なり、自己組織化を通じてプロダクトになります。
  15. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ プリウスのプロジェクトチームは “Ba”をマネジメントした • リーダーは、自発的に形成された場(Ba)を「見つ け」、活用することができる。 • リーダーは、交流のためのスペースを提供することで 場(Ba)を構築できる

    - 会議室などの物理的空間 - コンピュータ・ネットワークなどのサイバースペース - 共通の目標のような精神的空間 • 知識創造(自己組織化)の基盤となるのは、愛、関心、 信頼、コミットメントの醸成である。 • スクラムはTRUTH(真実)、TRANSPARENCY (透明性)、COMMITMENT(コミットメント)に 基づいています。
  16. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 場(ba)のエネルギーは、自己組織化に よって与えられる • 場(ba) が効果的に生まれるためには、自分たちの意図、方 向性、関心、使命によって「エナジャイズ(活性化)」され る必要があります。 •

    リーダーは、自律性、創造的カオス、冗長性、必要な多様 性、愛、ケア、信頼、コミットメントを提供します。 • プリウスの創造的カオスは、目標を要求することで生まれ た。 内山田は、新車開発のあらゆる常識を疑うことをチー ムに要求した。 • 経営陣は、プリウスのプロジェクトチームに大きな時間的 プレッシャーをかけ、それが同時並行のエンジニアリング の極端な使用を引き起こした。 • すべてのレベルで情報への平等なアクセスが重要だった • スクラムマスターとマネジメントは、コロケーション、ダ イナミックな相互作用、フェイス・トゥ・フェイスのコ ミュニケーション、透明性、大胆な目標を促進することで、 場(ba)を「エナジャイズ」しなければならない。
  17. https://www.infoq.com/presentations/The-Roots-of-Scrum/ Graphic by Conchango, Ken Schwaber, and Microsoft UK スクラムスプリントサイクル

    プロダクトバックログ 顧客が求める機能の 優先順位付きリスト スプリント バックログ スプリント内で完 成させる機能 機能をより小さな タスクに分解する 新しい機能 スプリントの 終わりにデモする 毎日15分のミーティ ングを行う。 スクラムマスターは 3つの質問をする 1)昨日なにを達成し ましたか? 2)ゴールを満たすた めに障害になってい るのは? 3)明日までになにを た達成しますか? スプリント: 1か月 作業日: 1日
  18. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタウェイ : Learn by Doing 張富士夫 : 代表取締役社長

    2002 • 私たちが一番重視するのは、実際に実践し、 行動すること アジャイル原則#1 • わかっていないことはたくさんある。だから 「とにかくまずやってみよう」アジャイル原則#3, #11 • 自分の知識の少なさに気づき、自分の失敗に 直面して、もう一度やり直し、2回目の試行で また別の失敗に気づく。そしてもう一度やり 直す。アジャイル原則#11, #12 • 絶え間ない改善によって、より高いレベルの 実践と知識に至る。アジャイル原則#3
  19. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタウェイは 冗長と失敗を許容する • 生物の進化のような創発的プロセスでは、失敗が つきものである • 早期かつ頻繁に失敗することで、迅速な学習と進 化を実現する

    • 合理的、効率的なアプローチでは大惨事を招く - 大規模システムの65%の失敗率 - Caper Jones, 1993 - 国防総省のシステム 75%の故障率 - Jarzombek, 1999 - 英国のシステム 87%の故障率 - Thomas, 2001
  20. https://www.infoq.com/presentations/The-Roots-of-Scrum/ 不確実性が求める 経験主義プロセス制御 プロセス アウトプット • インクリメン タルなプロダ クトの変更 制御

    インプット • 要件 • 技術 • チーム Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. Courtesy of Mike Cohn, Mountain Goat Software
  21. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 最初のスクラム – Easel 1993 • ガント・チャートの廃止 • ジョブタイトル(役職名)の廃止

    • スクラムマスターの誕生 • プロダクトオーナーの誕生 • 毎日のミーティングで自己組織化を促進 • スプリント中の干渉からチームを守る • スプリント計画、スプリントレビュー、デモ、レトロ スペクティブ • エンジニアリング手法にとらわれない • XPのエンジニアリング手法を採用
  22. https://www.infoq.com/presentations/The-Roots-of-Scrum/ スクラムがeXtreme Programmingに与えた影響 From: Reply: Date: Subj: Kent Beck To:

    Jeff Sutherland <jsutherland> [email protected] Mon, 15 May 1995 18:01:15 -0400 (EDT) HBR paper HBRからSCRUMの論文の別刷りを入手できる 良い場所はありますか?よく似たパターンを書 いているところなので、できるだけ多くのアイ デアを盗みたいのです。 Kent
  23. https://www.infoq.com/presentations/ The-Roots-of-Scrum/ 主な役割と責任 • プロダクトの機能を定義し、発売日と内容を決定する • プロダクトの収益性(ROI)に責任を持つ • 市場価値に応じて機能の優先順位を決定 •

    30日ごとに機能と優先順位を変更可能 • 作業結果の承認・不承認 • チームが完全に機能し、生産的であることを保証する • すべての役割や機能を超えた密接な協力を可能にし、 障壁を取り除く • 外部からの干渉からチームを守る • プロセスの遵守を保証する。毎日のスクラム、イテ レーションレビュー、プランニングミーティングへの 招待 • クロスファンクショナル、7人プラスマイナス2人のメン バー • イテレーションゴールの選択と作業結果の指定 • イテレーションゴールに到達するために、プロジェクトガ イドラインの範囲内であらゆることを行う権利を有する • 自分自身とその作業を整理する • 作業結果をプロダクトオーナーに説明する プロダクト オーナー スクラム マスター チーム
  24. 1970-80年代 コンピュータの普及 1990年代 パーソナルコンピュータの普及 ソフトウェア工学の黎明 2000年代 Webブラウザ、仮想化、クラウド、スマホ 2010年代 スマホ/クラウド中心、ビッグデータと機械学習 軽量ソフトウェア開発

    方法論の進展 フリーソフトウェア OSS 2001 アジャイル マニフェスト アジャイルの普及 リーンスタートアップ 2009年 リーマンショック 2010年東日本大震災 DevOps MIT, Xerox PARC, DEC, シリコンバレー Unix, Mac, Windows IE4-, VMware/Xen, Chrome, iPhone, Android ドットコムバブル崩壊 クラウドの普及 ユニコーン企業 GAFA+M ざっくり年表 日米経済摩擦 1985年プラザ合意 2001年同時多発テロ 自動車、半導体産業 1991年バブル崩壊
  25. Paul Hammond 00:51 しかし、始める前に、Flickrとは何 かについて少し話しておきましょう。 フリッカーについて聞いたことがあ る人は手を挙げてください。さて、 フリッカーを知らない人のために説 明しますと、 Flickrは写真共有サイ

    トです。現在、約30億枚の写真を保 存しています。そして、1日の任意 の時点で、1秒間に約40,000枚の写 真を提供しています。これらの写真 は、約6ペタバイトのストレージを 占めています。子猫がたくさんいる ように見えるかもしれませんが、実 はとても大きいのです。 Flickrは写真共有大手
  26. John Allspaw 03:44 これは、ある人にとっては新しい発見か もしれませんが、運用(Ops)の仕事はビ ジネスを可能にすることですよね?もし ビジネス要件として、2週間ごとにサイト を停止しなければならないとしたら、た とえあなたが最大のオンラインゲームプ ラットフォームであり、何百万人もの有

    料顧客を抱えていたとしても、その銀行 顧客は可用性が97%を許容します。 99.999%でなく。これは真実です。こ のサイトの安定性と高速性を維持するこ とは、よくあるビジネス要件です。ビジ ネス要件の話なんです。 Opsの仕事はビジネスを可能にすること
  27. Paul Hammond 05:29 今日お話しする内容のほとんどは、上 手なツールの使い方と、チーム内での 優れた作業文化によって、変更のリス クを低減することです。これらのツー ルを使ってやろうとしていることは、 ある変更がシステム停止や現場での問 題を引き起こさないという確信を高め

    ることです。また、万が一、障害が発 生した場合の復旧能力を高める方法に ついても検討しています。 上手なツールの使い方と、チーム内での優れた 作業文化によって、変更のリスクを低減する
  28. Paul Hammond 09:50 1つの共有リビジョン管理システムがあれば、チーム の誰もが、どこを見れば特定のボックス用の設定の最 新インスタンスを見つけられるのかを知ることができ、 また、アプリケーションで何が起こっているのか、ど こに変更があるのかを知ることができます。これは、 緊急時には本当に便利です。先週の金曜日、私は外で 食事をしているときに、サイトの一部に問題が発生し

    ていることがわかりました。ジョンのチームで働いて いるケビンが私に電話をかけてきたのです。もしソー スコードのリポジトリが違っていたら、ケビンがアク セスできなかったかもしれないし、私が家に帰って ラップトップを取り出し、自分で修正しなければなら なかったでしょう。このように、シングルソースコン トロールは透明性を提供してくれるので、非常に便利 です。 2.共有のリビジョン管理
  29. Paul Hammond 09:50 開発の観点からは、ワンステップビルドを設定することが最 も重要です。ワンステップビルドとは、現在svnのソースコ ントロールシステムに登録されているコードを、本番サー バーにコピーしてサイトを実行できるようなファイルセット にするために必要なすべてのことを意味します。今お見せし ているスクリーンショットは、Flickr内部の開発管理イン ターフェースの一部です。画面の一番下にある「ステージン

    グを行う」と書かれたボタンをクリックすると、SVM チェックアウトが行われ、すべての翻訳、すべてのテンプ レートのコンパイル、最適化のためのコンパイルなどが行わ れます。そして、そのコードをステージング・サーバーにコ ピーして、テストできるようにします。 3.ワンステップビルド
  30. Paul Hammond 14:45 リビジョン管理の分岐システムについて考えてみると、 それはデスクトップソフトウェアを構築する際の現実 に対する反応です。そして、開発チームはすぐに Microsoft Word 1.1の開発を始めます。そして、マ イクを起動し、1.1を起動します。そして数日後、重

    大なセキュリティ上の脆弱性があることに気づきます。 そこで、1.0のコードベースに戻って変更を加え、そ れを出荷しなければなりません。そして、1.2をリ リースします。そして、1.2をリリースすると、また 別の変更を加えなければなりません。つまり、一度に 3つの異なるバージョンのソフトウェアをリリースす ることになります。 旧来のソフトウェアのブランチ戦略
  31. Paul Hammond 14:45 SVNに入ると、そこにはトランクがあります。 先ほど、SVNではブランチを行わないと言い ました。代わりにコードで分岐を行います。 つまり、すぐにはリリースしない機能を開発 しているときは、条件分岐を使ってその特定 の分岐をブロックしているのです。ここでは、 PHPの例を紹介します。これはSmartyの例

    です。つまり、まだリリースされていないす べての新機能のコードを、実際に本番サー バーに置いておくことができるのです。本番 サーバーでは、設定を変更するだけで、まだ 実際には表示されません。 すぐに使わない機能 = 条件分岐を使って特定の分岐をブロック
  32. Paul Hammond 18:11 この機能により、いくつかの優れたトリックが可能になりま す。1つ目は、本番サーバー、本番ハードウェア、本番トラ フィックでプライベートベータを行うことができるというこ とです。もちろん、私たちには現実的なテストを行うことが できる素晴らしいステージング環境があります。そして、そ のような環境で多くのQAを行いました。しかし、私たちが 発見したのは、テストのために2台目のサーバーを使用した

    場合、ベータ版サーバーと本番サーバーの間で設定の変更が あることに気づくかもしれないということでした。構成管理 を行っていても、ベータ版サーバーでは新機能が完璧に動作 していたのに、本番版サーバーに移行した途端に動作しなく なったということがあります。しかし、本番環境に移行した 途端、頼りにしていたバックエンドの内部ウェブサービスが、 本番環境のダブダブからブロックされていることに気付きま した。そのため機能が動作せず、そのバックエンドのウェブ サービスに緊急の変更要求を出さなければなりませんでした。 一部の人にだけプライベートβ版
  33. Paul Hammond 18:11 これでバケットテストができるようになりました。 これは非常に便利なことです。つまり、新しい コードパスを手に入れて、新しいバックエンドシ ステムの使用を検討している場合、まずは5%の トラフィックをプッシュして、その後10, 20, 30,

    50と増やしていき、一部のユーザーに対し て機能をオンにすることができるのです。異なる バージョンのソフトウェアを異なるサーバーで実 行したり、本番環境に入れたり出したりといった ことを慎重に行う必要はなく、すべてコードで行 うことができます。 バケットテスト = 徐々に利用者を増やす
  34. Paul Hammond 18:11 そして最後に、ダークローンチこれは、 先ほどJonathanがFacebookの話をし たときに言っていたことですが、新し い機能を舞台裏で立ち上げることがで きるのです。例えば、検索クラスタの データベース・サーバーの memcachedボックスに負荷をかける

    ような新機能があった場合、その機能 を裏でオンにして、数週間データの取 得を開始し、そのデータは表示しない ようにします。 ダークローンチ = 表示はしないが動かす
  35. John Allspaw 21:12 100%懸念通りの結果がでたら、それを無効にする ことができます。また、サイトに影響を与えている もの、つまり可用性やパフォーマンスに関わるもの の動作を変更することもできます。データベースク ラスターがたまたま劣化していたり、他のバックエ ンドサービスが劣化していたりして、それが機能に 依存している場合は、これを変更することができま

    す。そして、サイトに影響を与えることなく、ロー ルバックすることができます。多くの場合、ロール フォワードしてオフにします。これらの機能フラグ の中には、単にオンかオフかだけではないものもあ ります。Paulが言っていたように、量を変えられる ノブのようなものもあります。だから良いのです。 ダメなら問題なく戻せる
  36. John Allspaw 21:12 これは私たちのガングリオンのインス トールのスクリーンショットです。37の 異なるクラスターがありますが、どれだ けの数のメトリクスを収集しているかわ かりません。 ここで重要なのは、開発者 はこれがどこにあるかを知っているだけ

    でなく、アクセス権を持っていて、運用 と同じくらい熱心に見ているということ です。オフィスを歩けば、すべての開発 者が少なくともブラウザの1つのタブに、 このようなものを持っています。 Devもサーバーメトリクスを見る
  37. Paul Hammond 24:10 これが、アプリケーションにおける適応型フィードバッ クループの作成につながります。つまり、非同期に起 こっていることがあれば、システムがうまく機能してい ない場合には、アプリケーションが手を引いて、システ ムへの負荷を減らすようにすることができるのです。先 ほど説明したオフラインタスクセンターは、データベー スが過負荷になり始めると、実際にダイヤルバックして、

    データベースがリアルタイムの負荷に対応できるように してくれます。もし10分後にオフラインタスクを実行す る必要があっても、それは大したことではありません。 また、Yahooフォトからflickerへの移行を行った際に は、ストレージの空き容量に応じてスロットルをかけ、 ストレージが不足しないようにしました。 問題が出たらDev側で変更対応できる
  38. John Allspaw 27:58 IRCのストリームにイベント、つまりコンピュータ主 導のイベントを流します。例えば、私たちが本当に 気にしている特定のアラートやモニターは、ビルド ログや、何かがデプロイされたときのデプロイログ です。つまり、あなたは会話をしていて、ある書き 換えルールとデプロイでこんな問題が起きているこ とを知らないのです。それについてどう思いますか、

    それともアラートが出ないのですか?そこで実際に やることは、このログに記録された情報をすべて、 検索エンジンに突っ込むことです。そうすれば、2ヶ 月前の木曜日に一体何をしていたのか、何が起こっ ていたのかを知ることができます。以前にもこのよ うな問題があったのか。人間がコンテキストを持つ ようになったということで、本当に助かりました。 IRCツールで過去にさかのぼって調べられるだけでな く、実際に人間の文脈があるわけですから。 ログとアラートをIRCに集める
  39. Paul Hammond 29:28 文化に関して言えば これを言うのはちょっと偽 善的ですが、最も重要なことの1つは固定観念を 避けることです。あなたが5年前に一緒に働いて いたカウボーイは、あなたのアプリケーション に関心がなかったり、システムのアップタイム に関心がなかったりしましたよね。しかし、あ

    なたが一緒に仕事をする開発者の全員が彼のよ うなウイルスに感染しているわけではありませ んし、運用担当者の全員が彼のように妨害され るわけではありません。誰もが最悪の事態を想 定するなら、誰もがあなたに最悪の事態を想定 することになるでしょう。 相手をステレオタイプで捉えるな
  40. John Allspaw 31:20 それは、問題について会話をするときに、「いいえ」 と言うことは、「あなたの問題には関心がありませ ん」と言っているようなものだということです。ブ ルーム・フィルターは書けません。開発者が問題を解 決しようとしているのか、運用担当者が問題を解決し ようとしているのか、何を解決しようとしているのか を知ることができます。ここで最もクールなものを見

    つけることができます。規模の壁を乗り越えて成功し た企業のほとんどは、開発者と運用担当者が一緒に なってユニークなソリューションを考え出したところ です。memcachedがいい例です。かつては、データ ベースといえば、DBAや運用担当者がいて、それが彼 らの仕事だったんです。私は開発者なので、コードを 書きます。そして、どこかに魔法のようなデータベー スがあって、私に代わって答えを出してくれる。そし て、memcachedが開発されました。そして、この問 題を解決するために様々なアーキテクチャが設計され ました。そして、それが実現したのは、開発者と運用 者が一緒に仕事をしたときだけです。 ただ「ノー」と 断るより、建設的に
  41. Paul Hammond 32:41 繰り返しになりますが、開発者にとって、自分の仕事に敬意を 払ってもらうためにできることのひとつは、何かを立ち上げる前、 あるいは何かを提案する前に、その影響について前もってOpsに 相談することです。もしあなたがコードを公開するなら、どのよ うな指標が変わるでしょうか?どのようなボックスでしょうか? CPUの使用量は増えますか?どのボックスの空きメモリが増え ますか?何かが間違っているかもしれないリスクは何ですか?実

    際に何か問題が起きていることを示す兆候は何ですか?では、運 用チームは何に気をつけるべきでしょうか?そして、もし何かが 起こり始めたら?不測の事態とは何か?サイトを継続的に運営す るために、オペレーションチームはどのように回復することがで きるのでしょうか?これらの答えを導き出すための問題は、オペ レーションチームに話を聞きに行く前に、これらの答えを導き出 す必要があるということです。すべての答えを得ることはできな いかもしれませんが、少なくともこれを会話のベースにすべきで す。 対話のきっかけにする
  42. John Allspaw 34:05 そして、信頼へとつながっていきます。最後のスライドには、 この会話を成立させるのに役立つ様々な事柄や推奨事項が書 かれています。つまり、開発者が運用担当者のところに来て、 不機嫌な運用担当者だけど、そんなに長くは不機嫌にならな いだろうと思って、こう言ったとしましょう。クラスタ A,B,Cの低い特性が変わると思うんだ。これを作ったんだけ ど、小さなフックがあって、これをゼロに設定できるんだ。

    何かあったら私のせいにしてください。この機能のために、 このコードを入れるのは良いことだと思わなければなりませ ん。この男は本当に考えているんだな。それだけではなく、 彼はこのことを気にかけています。彼はサイトのアップタイ ムを気にしているし、真夜中に私のチームを起こさないよう に気にしています。 2. 信頼
  43. Paul Hammond 36:17 この会話を確実に行うために私たちが実践し ていることは、可能な限り共有のランブック と共有のエスカレーションプランを作成する ことです。つまり、ジョンと私が一緒に座っ て、どんな機能を見ても、あるいはチームの メンバーが一緒に座って、この新機能が運用 面でどのようにサポートされるのかを検討す

    るのです。何を?失敗する可能性のあるシナ リオは何か?誰がその修正に関与する必要が あるのか、そのためにはどのような会話が必 要なのか。リスクは何か?不測の事態に備え て、全員が参加しているかどうかを確認する。 共有のランブック(作戦)と エスカレーションプラン(不測の事態の作戦)
  44. John Allspaw 37:50 私は、開発者がシステム上で何が起こっているかを確認で きるようにすべきだと考えています。電話のタグを渡すの は最悪です。シェルコマンドでは、ただの馬鹿です。とこ ろで、開発者はあなたのマシンで動いているコードを書い ています。もちろんガードレールは重要ですが、誰かに読 み取り専用のシェルアカウントを与えることは、たとえ本 番用のハードウェアで超偏執的になっていたとしても、リ

    スクは低く、実際に何が起こっているかを見ることができ ます。それは、あなたが共有しているメトリクスを超えて、 あなたが運用担当者として共有しているからこそ、彼らが 実際に内部に入り込み、gangliaやNagiosにあるメトリク スだけでなく、あなたのすべてのメトリクスにアクセスで きることを確認できるということです。そして、何が起 こっているのかを見極める必要があり、それを許可するこ とを恐れてはいけません。 透明性: Opsはすべてを共有すべし
  45. John Allspaw 41:46 問題が発生して、ああ、どうしよう?私はど うすればいいの?もしかしたら変わるかもし れません。何が起こっているかを人に知られ たくないと思っているので ログを削除しよう と思うんだけど、どうしよう?とか、鶏の頭 を切って、私のコードに基づいてではなく、

    あなたのマシンに基づいて、やっとの思いで 解明するんですよ。無駄な時間がやたらと多 いんですよね。縄張り意識が物事を解決する 邪魔をしているんだ。 役割分担が問題の解決を遅らせる
  46. Paul Hammond 43:55 たとえ開発者が待機していたとしても、これが最 初のページであることを知るのは、たいてい運用 チームです。夜中に何かを壊してしまい、朝に なってみると30分もの停電が発生していて、5人 もの人が呼び出されて起こされたのは自分のせい だったというシナリオがあったとしたら、ただ謝 るだけでいいんです。

    多くの開発チームが陥りがちなのが、オペレー ションが存在すること、オペレーションが夜中に 起こされて修正してくれることを当てにしている ことです。しかし、自分自身に問いかけてみるの もいいでしょう。「もし、誰かが私の不足分を 補ってくれなかったら、私は何か違うことをする だろうか?もし自分が夜中に起こされていたとし たら、何かを変えるべきだと思います。 Opsが夜中に起こされないように、自分ごとに