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

by Yasunobu Kawaguchi

Slide 1

Slide 1 text

アジャイルとDevOpsの歴史をチェリーピックして勝手にふりかえりながら仙人と語らうためのスライド

Slide 2

Slide 2 text

川口恭伸かわぐちやすのぶ Twitter: @kawaguti アギレルゴコンサルティング株式会社シニアアジャイルコーチ株式会社ホロラボシニアアジャイルコーチ一般社団法人スクラムギャザリング東京実行委員会代表理事一般社団法人 DevOpsDays Tokyo 代表理事

Slide 3

Slide 3 text

研修やってますアギレルゴアジャイル研修検索

Slide 4

Slide 4 text

前段で勝手なことを話しておけばだまって聞いてる仙人がウズウズしてしゃべりたいことがたくさん出てくるだろうという戦術仙人勝手なことを話してる市井の人

Slide 5

Slide 5 text

ITバブル崩壊 2009年リーマンショック 2001年まことに勝手なる歴史観

Slide 6

Slide 6 text

ITバブル崩壊 2009年リーマンショック 2001年先アジャイル期アジャイル期 DevOps期まことに勝手なる歴史観

Slide 7

Slide 7 text

ITバブル崩壊 2009年リーマンショック 2001年先アジャイル期アジャイル期 DevOps期 2020年 2022年 2020年のコロナ禍と、 2022年の戦争やインフレ・円安が、大きな変動であるのは間違いないと思うので、何か生活のヒントがあるかもしれない。まことに勝手なる歴史観

Slide 8

Slide 8 text

ITバブル崩壊 2009年リーマンショック 2001年先アジャイル期アジャイル期 DevOps期 2020年 2022年まことに勝手なる歴史観

Slide 9

Slide 9 text

ITバブル崩壊 2009年リーマンショック 2001年先アジャイル期アジャイル期 DevOps期 2020年 2022年まことに勝手なる歴史観

Slide 10

Slide 10 text

スクラム the ORIGIN : Jeff Sutherland - Roots of Scrum (2005) を語るナラティブ川口恭伸株式会社ホロラボアギレルゴコンサルティング株式会社シニアアジャイルコーチ

Slide 11

Slide 11 text

https://www.infoq.com/presentations/The-Roots-of-Scrum/ Roots of Scrum (2005) についてスクラムの Co-Creator であるジェフ・サザーランド博士がスクラムを作る前に参考にしたり、作りながら実験した話。なぜスクラムなのか？ 2011年に初めて野中先生と顔をあわせるのですが、その6年前。北米でもスクラムが劇的に広まる少し前、だと思います。

Slide 12

Slide 12 text

スクラムの源流いかにして日本の製造業が世界のソフトウェア開発プラクティスを変革したか JAOO, Aarhus, Denmark, 28 Sep 2005 ジェフ・サザーランド Ph.D. 認定スクラムマスター研修、スクラムプロセスの開発者 https://www.infoq.com/presentations/The-Roots-of-Scrum/

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

https://www.infoq.com/presentations/The-Roots-of-Scrum/ オリジナルのスライドスクラムの源流 • チームプロセス – シリコンバレーの起業家たち • 竹内・野中 – 日本の製造業 • 世界をもっとよい場所に – 内なるビジョン • オブジェクト技術とEasel社のSmallTalkプロダクト • オブジェクト指向アーキテクチャ設計ツールの専門家、ベンダー、顧客 • 進化生物学と複雑適応系 • プロセスと生産性の研究 • ソフトウェア生産性の研究 • 外科手術チーム(人月の神話, IBM) • 邪悪な問題、正しい解決 • ボーランド Quattro Pro プロジェクト • iRobot -サブサンプション・アーキテクチャ

Slide 15

Slide 15 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 北米トヨタ自動車のミッション Toyota Motor Manufacturing North America 1. 米国企業として、地域および米国の経済成長に貢献する。 2. 独立した企業として、チームメンバーの安定と幸福に貢献する。 3. トヨタのグループ会社として、お客様に付加価値を提供することで、トヨタ全体の成長に貢献する。

Slide 16

Slide 16 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 竹内野中論文(1986)が示したマネジメントスタイル • Type A NASAのウォーターフォール型 • 要求、分析、設計、実装、試験と、順に次の工程の部署に引き渡される • Type B 富士ゼロックスのサシミ型 • 前工程と後工程が同席する • Type C ホンダのスクラム型 • 一時は全工程が同席する Jeff SutherlandはこのType Cから、自らのフレームワークの名前をとった。

Slide 17

Slide 17 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ ラグビーのスクラム

Slide 18

Slide 18 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタにおける制約条件の綜合 • 歴史的には、高品質、製品の多様性、低コストを同時に達成することはできない、とされてきた。 • トヨタ生産方式は、それとは全く異なる考え方に基づく。 • 矛盾を綜合する知識創造によって、トヨタは限界に挑戦する。 • 高品質、多品種、低コストを一度に実現する。

Slide 19

Slide 19 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 綜合であって最適化ではない規模/範囲の経済バンドルアンバンドル機械的フロンティア有機的フロンティアスピードの経済

Slide 20

Slide 20 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 顧客が求めているものスピードの経済規模/範囲の経済契約顧客のニーズ

Slide 21

Slide 21 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ さらに「より多く」「少ない労力で」 1. 開発の後半になっても、変化する要求を歓迎する。 2. 動くソフトウェアを頻繁に提供する。 3. ビジネスマンと開発者は毎日一緒に仕事をしなければならない。スクラムは反復的であり、顧客は要件を変更することができ、ソリューションは自己組織化のなかで後発的に生まれます。プランニングスケーリング開発インプリメント (パッケージング)

Slide 22

Slide 22 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 文化を変える – そこが難しい旧来の組織新しい組織中央集権型分散型統一的な視点多様な視点もともとの意味後発的な意味分析的創発的分析から行動へ実践して学ぶ合理性冗長性確実性不確実性戦略的コンセプト現地の活動命令型参加型階層的フラット

Slide 23

Slide 23 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ コマンド＆コントロールを打ち破る • 伝統的な企業では、戦略は中央で開発される。 • 創発的な戦略は、ローカルな行動によって自己組織化される。 - 分散型の認知と行動 • スクラムチームには自己組織化が求められる - 自律的 - 超越的 - 他家受粉 (Cross-fertilization) • チームは自分で仕事を選ぶ - 個人が自分の仕事を管理する - 経営陣は邪魔をしない

Slide 24

Slide 24 text

オリジナルのスライド 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

Slide 25

Slide 25 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 多様な視点 • クロスファンクショナルチーム • スクラムチームには、プロダクトの知識、ビジネスアナリスト、ユーザーインターフェースデザイン、ソフトウェアエンジニア、QA、のすべてがいます。 • 上級者のスクラムでは、経営陣、顧客、インストール、サポートなど、さらにステークホルダーを招き入れます。

Slide 26

Slide 26 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタ・プリウス-創発的戦略 • 製品、技術、プロセスの革命 - どの製品ラインにも当てはまらない。新しい視点で設計されている。 • 多くの技術を使用 - エンジン、モーター、バッテリー、ブレーキを組み合わせたハイブリッドシステム • 記録的な速さで開発 - 4年かかるものが15ヶ月で • 重複するフェーズ - 研究、開発、設計、生産 • リーダーが作り、利用し、エナジャイズした場 (Ba)

Slide 27

Slide 27 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 場(Ba)というコンセプト: スクラムの禅(本質) • 個人と組織のダイナミックな相互作用は、自己組織化チームという形で統合を生み出します。 • それは、個人が相互に作用することができる共通の文脈を提供するものです。 • チームメンバーは新しい視点を生み出し、対話を通じて矛盾を解決します。 • 場(Ba)は、意味の流れとしての知識が出現する、動きのある共通文脈です。 • 創発された知識はコード化されて動くソフトウェアとなり、自己組織化を通じてプロダクトになります。

Slide 28

Slide 28 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ プリウスのプロジェクトチームは “Ba”をマネジメントした • リーダーは、自発的に形成された場(Ba)を「見つけ」、活用することができる。 • リーダーは、交流のためのスペースを提供することで場(Ba)を構築できる - 会議室などの物理的空間 - コンピュータ・ネットワークなどのサイバースペース - 共通の目標のような精神的空間 • 知識創造（自己組織化）の基盤となるのは、愛、関心、信頼、コミットメントの醸成である。 • スクラムはTRUTH（真実）、TRANSPARENCY （透明性）、COMMITMENT（コミットメント）に基づいています。

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

https://www.infoq.com/presentations/The-Roots-of-Scrum/ Graphic by Conchango, Ken Schwaber, and Microsoft UK スクラムスプリントサイクルプロダクトバックログ顧客が求める機能の優先順位付きリストスプリントバックログスプリント内で完成させる機能機能をより小さなタスクに分解する新しい機能スプリントの終わりにデモする毎日15分のミーティングを行う。スクラムマスターは３つの質問をする 1)昨日なにを達成しましたか？ 2)ゴールを満たすために障害になっているのは？ 3)明日までになにをた達成しますか？スプリント: １か月作業日: １日

Slide 31

Slide 31 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタウェイ : Learn by Doing 張富士夫 : 代表取締役社長 2002 • 私たちが一番重視するのは、実際に実践し、行動することアジャイル原則#1 • わかっていないことはたくさんある。だから「とにかくまずやってみよう」アジャイル原則#3, #11 • 自分の知識の少なさに気づき、自分の失敗に直面して、もう一度やり直し、2回目の試行でまた別の失敗に気づく。そしてもう一度やり直す。アジャイル原則#11, #12 • 絶え間ない改善によって、より高いレベルの実践と知識に至る。アジャイル原則#3

Slide 32

Slide 32 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタウェイは冗長と失敗を許容する • 生物の進化のような創発的プロセスでは、失敗がつきものである • 早期かつ頻繁に失敗することで、迅速な学習と進化を実現する • 合理的、効率的なアプローチでは大惨事を招く - 大規模システムの65%の失敗率 - Caper Jones, 1993 - 国防総省のシステム 75%の故障率 - Jarzombek, 1999 - 英国のシステム 87%の故障率 - Thomas, 2001

Slide 33

Slide 33 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ プロセスの理論定義的プロセスと経験的プロセス • プロセスが動作する基本的なメカニズムが合理的に理解されている場合は、定義された（理論的な）モデリングアプローチを採用するのが一般的である。プロセスが複雑すぎて定義的なアプローチができない場合は、経験的なアプローチが適切な選択となる。 Process Dynamics, Modeling, and Control. Ogunnaike and Ray, Oxford University Press, 1992

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ ローカルなアクションが自己組織化を促す • 個人は仕事を自己組織化する • チームは目標に向かって自己組織化する • アーキテクチャはコードを中心に自己組織化される • 反復的な適応によって製品が生まれる • 権威的なアプローチではなく、参加型のアプローチが必要 • フラットな組織構造

Slide 36

Slide 36 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 最初のスクラム – Easel 1993 • ガント・チャートの廃止 • ジョブタイトル(役職名)の廃止 • スクラムマスターの誕生 • プロダクトオーナーの誕生 • 毎日のミーティングで自己組織化を促進 • スプリント中の干渉からチームを守る • スプリント計画、スプリントレビュー、デモ、レトロスペクティブ • エンジニアリング手法にとらわれない • XPのエンジニアリング手法を採用

Slide 37

Slide 37 text

https://www.infoq.com/presentations/The-Roots-of-Scrum/ スクラムがeXtreme Programmingに与えた影響 From: Reply: Date: Subj: Kent Beck To: Jeff Sutherland [email protected] Mon, 15 May 1995 18:01:15 -0400 (EDT) HBR paper HBRからSCRUMの論文の別刷りを入手できる良い場所はありますか？よく似たパターンを書いているところなので、できるだけ多くのアイデアを盗みたいのです。 Kent

Slide 38

Slide 38 text

オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ アジャイルを採用＆利用する上での課題／困難組織の抵抗経営陣の無関心不十分な研修伴走型の支援がない公式ガイドラインがない報酬がごく少ないプロジェクト失敗のリスク上昇

Slide 39

Slide 39 text

https://www.infoq.com/presentations/ The-Roots-of-Scrum/ 主な役割と責任 • プロダクトの機能を定義し、発売日と内容を決定する • プロダクトの収益性（ROI）に責任を持つ • 市場価値に応じて機能の優先順位を決定 • 30日ごとに機能と優先順位を変更可能 • 作業結果の承認・不承認 • チームが完全に機能し、生産的であることを保証する • すべての役割や機能を超えた密接な協力を可能にし、障壁を取り除く • 外部からの干渉からチームを守る • プロセスの遵守を保証する。毎日のスクラム、イテレーションレビュー、プランニングミーティングへの招待 • クロスファンクショナル、7人プラスマイナス2人のメンバー • イテレーションゴールの選択と作業結果の指定 • イテレーションゴールに到達するために、プロジェクトガイドラインの範囲内であらゆることを行う権利を有する • 自分自身とその作業を整理する • 作業結果をプロダクトオーナーに説明するプロダクトオーナースクラムマスターチーム

Slide 40

Slide 40 text

ITバブル崩壊 2009年リーマンショック 2001年先アジャイル期アジャイル期 DevOps期 2020年 2022年まことに勝手なる歴史観

Slide 41

Slide 41 text

アジャイル開発の時代川口恭伸アギレルゴコンサルティング株式会社シニアアジャイルコーチ一般社団法人スクラムギャザリング東京実行委員会代表理事一般社団法人 DevOpsDays Tokyo 代表理事

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

ソフトウェアの品質ってなんでしょう？ 30年前なら、動いていればよかったかもしれないけど、今は、きれいに整理されていて、メンテナンスしやすいことが必要。どうやったら変更しにくくなる？ …を考える(たぶん数値では測れない)

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

この本が扱うのは人間だ。それもソフトウェアを書く人間である。ここ10年ほどの間、我々は、共同作業によってソフトウェアを生み出す方法について研究してきた。優れたソフトウェアを効率的に次々と生み出す能力に関心があるのだ。

Slide 46

Slide 46 text

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年バブル崩壊

Slide 47

Slide 47 text

agilemanifesto.org アジャイルマニフェスト

Slide 48

Slide 48 text

agilemanifesto.org 個人と対話動くソフトウェア顧客との協調変化への対応コミュニケーション方法ソフトウェア開発手法ビジネスの進め方リスクへの反応の仕方

Slide 49

Slide 49 text

ボブ・マーティンがミーティングを招集して、こう言った。「私たちが言っていることって、似ているように聞こえるんだけど、これって偶然の一致なのかなぁ？」彼はマニフェストを書くことに関心があることを付け加えた。(私はマニフェストを書くことには全く関心がなかったので、マニフェストへの世間の反応は、私はボブ以上に驚いたんじゃないかと思う)。ボブはワンダフルな人々をミーティングに招待していた。 “軽量プロセス”の提案者として、他の誰より知られた人たちだ。北米だけでなく、イギリスを基盤とするDSDMの代表とも話すことができた。 Ari van Bennekum はオランダからこのミーティングのためだけに来ていた。 XP、スクラム、クリスタル、アダプティブ、FDD、DSDM、軽量で実践的な開発といわれるひとたち (Andy Hunt, Dave Thomas, Brian Marick) が集まっていた。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229

Slide 50

Slide 50 text

「こんにちは、私は xx です」というやり取りが一周した後、車座に座って、お互いをしばらく凝視した後、誰かが言った。「我々は、アジェンダ(今日話す議題)をどうやって作ればいいんだろう？」すると、誰かがアジェンダ項目をインデックスカードに書くことを提案した。XPの人たちは研修用にインデックスカードを持ち歩いていたのですぐに取り出して書き始め、書き終わったものを中央の床に放り込んだ。急に、過半数の人々が床にインデックスカードを入れ始めた。残りの人も、同じようにやり始めて、アイデアが尽きたときには、床のインデックスカードは山になっていた。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229

Slide 51

Slide 51 text

誰かが尋ねた。「このカードをどうやってまとめて、アジェンダにするんだろう？」誰かが言った(私はこのときすでに、誰がなにを言ったかを記録するパワーはなかった)。「アジェンダの順番に意見がある人は、このカードを並べ替えよう。そうでない人は、ここを離れてもいい。」私はトピックの順番は気にしていなかったので、休憩をとった。私が戻ったとき、インデックスカードは壁にテープで貼られていた。後で、誰かが「私は他のアジェンダ項目を考えているんだけど、どうしたらいい？」と言い出した。誰かが「アジェンダの空いているところ、好きなとこに貼りなよ」と答えた。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229

Slide 52

Slide 52 text

私はこの作業にずっと付き合ったのだが、それは、このグループの２つの特徴が私の心を打ったからだ。リスペクト(Respect) その部屋にいた全ての人が、他の人に対して、絶大な信頼を置いていたこと。だれもミーティングをハイジャックすることを試みたりしなかった。全員が他の人の意見を極めてじっくりとよく聞いていた。常に、話している人に最大の信頼をおいていた。自己組織化(Self-organization) そこは、最も優れた人々の自己組織化の場だった。それまで経験した他の場では、常に一人の人（または、もっと悪い場合は複数の人）がミーティングを "動かそう" とするものだった。偉い人が部屋にいて、お互いをよく知らない場合、まず最初に権力闘争が始まりやすい。そこでは、そんなことは一切起こらなかった。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

https://kawaguti.hateblo.jp/ entry/2018/10/31/114305

Slide 55

Slide 55 text

https://kawaguti.hateblo.jp/ entry/20130217/1361047033

Slide 56

Slide 56 text

https://speakerdeck.com/ kawaguti/hagechabin 現場感覚や当事者感覚がない人のSystem1で棄却される問題 System1 System2

Slide 57

Slide 57 text

ITバブル崩壊 2009年リーマンショック 2001年先アジャイル期アジャイル期 DevOps期 2020年 2022年まことに勝手なる歴史観

Slide 58

Slide 58 text

DevOps の源流 : Flickr 10+ Deploys per Day のトーク (2009年) を再訪する

Slide 59

Slide 59 text

10 deploys per day Dev &ops cooperation at Flickr JohnAllspaw &Paul Hammond Velocity 2009

Slide 60

Slide 60 text

10 deploys per day Dev &ops cooperation at Flickr JohnAllspaw &Paul Hammond Velocity 2009

Slide 61

Slide 61 text

一日に10回デプロイする FlickrでのDevとOpsの協調ジョン・アルスポー (Ops) ポール・ハモンド (Dev) 2009年オライリーの Velocityカンファレンスにて

Slide 62

Slide 62 text

Paul Hammond 00:51 しかし、始める前に、Flickrとは何かについて少し話しておきましょう。フリッカーについて聞いたことがある人は手を挙げてください。さて、フリッカーを知らない人のために説明しますと、 Flickrは写真共有サイトです。現在、約30億枚の写真を保存しています。そして、1日の任意の時点で、1秒間に約40,000枚の写真を提供しています。これらの写真は、約6ペタバイトのストレージを占めています。子猫がたくさんいるように見えるかもしれませんが、実はとても大きいのです。 Flickrは写真共有大手

Slide 63

Slide 63 text

John Allspaw 01:26 そうそう、今回は歴史的、伝統的に開発(Dev)と運用(Ops)についてお話します。今でも、これは通常、開発vs 運用と考えられています。ハイデガーの基調講演では、このような二人の男がいるという図式がありました。よく耳にする言葉ですね。開発(Dev) vs 運用(Ops)

Slide 64

Slide 64 text

Paul Hammond 02:45 運用担当者というと、もうひとつのステレオタイプは、「不機嫌な老人」です。そう、いつも「ノー」と言う不機嫌なおじさんです。彼らは、これらの新しい機能がサイトを壊すのではないかと恐れています。とてもとても指摘好きで、批判ばかり。新しい機能がサイトを壊す

Slide 65

Slide 65 text

John Allspaw 03:00 そうそう、彼らはいつもノーと言います。だってサイトが予期せず壊れちゃいますよ。ステレオタイプのOPSのマネージャーは、こんな不機嫌な男のように、「いや、それはやりたくない」と言うんでしょうか。いや、私はそうはなりたくありません。そんな人とだれが働きたいんでしょう？誰もいませんよ、嫌な奴だから。批判ばかりの嫌な奴

Slide 66

Slide 66 text

Paul Hammond 03:24 多くの人が考えるのは、開発者(Dev) の仕事はサイトに新しい機能を追加すること。そして運用者(Ops)の仕事は、サイトの安定性と高速性を維持することです。伝統的なDevとOps

Slide 67

Slide 67 text

John Allspaw 03:44 これは、ある人にとっては新しい発見かもしれませんが、運用(Ops)の仕事はビジネスを可能にすることですよね？もしビジネス要件として、2週間ごとにサイトを停止しなければならないとしたら、たとえあなたが最大のオンラインゲームプラットフォームであり、何百万人もの有料顧客を抱えていたとしても、その銀行顧客は可用性が97%を許容します。 99.999%でなく。これは真実です。このサイトの安定性と高速性を維持することは、よくあるビジネス要件です。ビジネス要件の話なんです。 Opsの仕事はビジネスを可能にすること

Slide 68

Slide 68 text

Paul Hammond 04:34 ビジネス、特にオンラインビジネスで働く上での現実の一つは、ビジネスには変化が必要だということです。もしあなたのビジネスが立ち止まっていたら、TwitterやFacebookのような新興企業に乗っ取られ、追い越されることになるでしょう。そして、ビジネスには変化が必要

Slide 69

Slide 69 text

Paul Hammond 04:34 もちろん、問題はその変化です。ほとんどの障害の根本原因を調べて一般化すると、「変化」という結論に至ります。ほとんどの障害の根本原因は「変化」なのでしょうか？数日前、数時間前、数週間前に変更がなければ、ほとんどの停電は起こりません。ほとんどの障害の根本原因は「変化」

Slide 70

Slide 70 text

John Allspaw 05:09 つまり、2つの選択肢があります。安定性を重視して変化を阻止するか。それとも、賢くなって、必要に応じて変化を起こせるようなツールや文化を構築するかです。安定性を重視して変化を阻止する？変化を起こせるツールや文化を構築する？

Slide 71

Slide 71 text

Paul Hammond 05:29 今日お話しする内容のほとんどは、上手なツールの使い方と、チーム内での優れた作業文化によって、変更のリスクを低減することです。これらのツールを使ってやろうとしていることは、ある変更がシステム停止や現場での問題を引き起こさないという確信を高めることです。また、万が一、障害が発生した場合の復旧能力を高める方法についても検討しています。上手なツールの使い方と、チーム内での優れた作業文化によって、変更のリスクを低減する

Slide 72

Slide 72 text

John Allspaw 06:03 もちろん、開発者と同じような考え方をする人たちがオペレーションをしてくれれば、それはとても助かります。開発者と同じような考え方をするOps

Slide 73

Slide 73 text

Paul Hammond 07:42 そこで今回は、ツールについて少しお話ししましょう。そして、このツールの議論でやりたいことは、これらは私たちに有効なツールの一部です。必ずしもすべての人に使えるわけではありません。全体を通して、私たちが使っている具体的なツールの例を挙げていきたいと思います。しかし、私たちが伝えようとしている重要なことは、このカンファレンスの共通テーマになるでしょう。まず、ツールについて

Slide 74

Slide 74 text

Paul Hammond 07:42 自動化されたインフラとは、そのような技術であり、オペレーションの仕事を可能にするものです。1,000台以上のサーバーがある場合、個々のサーバーを手動で管理することは現実的ではありません。開発者の視点から見ると、アプリを構築するための一貫した予測可能なプラットフォームを提供します。 1.自動化されたインフラ

Slide 75

Slide 75 text

Paul Hammond 09:50 1つの共有リビジョン管理システムがあれば、チームの誰もが、どこを見れば特定のボックス用の設定の最新インスタンスを見つけられるのかを知ることができ、また、アプリケーションで何が起こっているのか、どこに変更があるのかを知ることができます。これは、緊急時には本当に便利です。先週の金曜日、私は外で食事をしているときに、サイトの一部に問題が発生していることがわかりました。ジョンのチームで働いているケビンが私に電話をかけてきたのです。もしソースコードのリポジトリが違っていたら、ケビンがアクセスできなかったかもしれないし、私が家に帰ってラップトップを取り出し、自分で修正しなければならなかったでしょう。このように、シングルソースコントロールは透明性を提供してくれるので、非常に便利です。 2.共有のリビジョン管理

Slide 76

Slide 76 text

Paul Hammond 09:50 開発の観点からは、ワンステップビルドを設定することが最も重要です。ワンステップビルドとは、現在svnのソースコントロールシステムに登録されているコードを、本番サーバーにコピーしてサイトを実行できるようなファイルセットにするために必要なすべてのことを意味します。今お見せしているスクリーンショットは、Flickr内部の開発管理インターフェースの一部です。画面の一番下にある「ステージングを行う」と書かれたボタンをクリックすると、SVM チェックアウトが行われ、すべての翻訳、すべてのテンプレートのコンパイル、最適化のためのコンパイルなどが行われます。そして、そのコードをステージング・サーバーにコピーして、テストできるようにします。 3.ワンステップビルド

Slide 77

Slide 77 text

Paul Hammond 14:45 ジョンがすでに述べたように、私たちのビルドとデプロイのシステムは完全に自動化されているので、より頻繁にデプロイすることができます。また、1回のデプロイを小さくすることができるので、個々のデプロイのリスクが少なくなり、万が一何か問題が発生した場合でも、何が起こったのかを簡単に調べることができるので、リカバリーが可能になります。小さく頻繁に変更をデプロイ

Slide 78

Slide 78 text

Paul Hammond 14:45 次に紹介するのは、これまた開発者向けの話です。それは、フィーチャーフラグと呼ばれるものです。これは、コードの分岐と考えることもできます。 4.フィーチャーフラグ (コード内でブランチする)

Slide 79

Slide 79 text

Paul Hammond 14:45 リビジョン管理の分岐システムについて考えてみると、それはデスクトップソフトウェアを構築する際の現実に対する反応です。そして、開発チームはすぐに Microsoft Word 1.1の開発を始めます。そして、マイクを起動し、1.1を起動します。そして数日後、重大なセキュリティ上の脆弱性があることに気づきます。そこで、1.0のコードベースに戻って変更を加え、それを出荷しなければなりません。そして、1.2をリリースします。そして、1.2をリリースすると、また別の変更を加えなければなりません。つまり、一度に 3つの異なるバージョンのソフトウェアをリリースすることになります。旧来のソフトウェアのブランチ戦略

Slide 80

Slide 80 text

Paul Hammond 14:45 しかし、ウェブアプリケーションのインスタンスが1つしかない場合は、そうはいきません。私たちが持っているのは、現在デプロイされているものだけであり、古いバージョンはもう重要ではありません。 Webアプリのブランチ戦略

Slide 81

Slide 81 text

Paul Hammond 14:45 私たちがこの問題に対処する方法は、常にトランクを出荷することです。すべての開発をトランクで行っているわけではありませんが、ブランチで開発を行い、そのブランチをマージすることも可能です。常にトランクをデプロイする

Slide 82

Slide 82 text

Paul Hammond 14:45 しかし、常にトランクを出荷することで、チームの誰もが、現在サイトにデプロイされているコードのバージョンがどこにあるのかを正確に知ることができ、どのブランチのどのパッチリリースが現在リリースされているものなのかを考える必要がなくなります。全員が現在の状態を知ることができる

Slide 83

Slide 83 text

Paul Hammond 14:45 SVNに入ると、そこにはトランクがあります。先ほど、SVNではブランチを行わないと言いました。代わりにコードで分岐を行います。つまり、すぐにはリリースしない機能を開発しているときは、条件分岐を使ってその特定の分岐をブロックしているのです。ここでは、 PHPの例を紹介します。これはSmartyの例です。つまり、まだリリースされていないすべての新機能のコードを、実際に本番サーバーに置いておくことができるのです。本番サーバーでは、設定を変更するだけで、まだ実際には表示されません。すぐに使わない機能 = 条件分岐を使って特定の分岐をブロック

Slide 84

Slide 84 text

Paul Hammond 18:11 この機能により、いくつかの優れたトリックが可能になります。1つ目は、本番サーバー、本番ハードウェア、本番トラフィックでプライベートベータを行うことができるということです。もちろん、私たちには現実的なテストを行うことができる素晴らしいステージング環境があります。そして、そのような環境で多くのQAを行いました。しかし、私たちが発見したのは、テストのために2台目のサーバーを使用した場合、ベータ版サーバーと本番サーバーの間で設定の変更があることに気づくかもしれないということでした。構成管理を行っていても、ベータ版サーバーでは新機能が完璧に動作していたのに、本番版サーバーに移行した途端に動作しなくなったということがあります。しかし、本番環境に移行した途端、頼りにしていたバックエンドの内部ウェブサービスが、本番環境のダブダブからブロックされていることに気付きました。そのため機能が動作せず、そのバックエンドのウェブサービスに緊急の変更要求を出さなければなりませんでした。一部の人にだけプライベートβ版

Slide 85

Slide 85 text

Paul Hammond 18:11 これでバケットテストができるようになりました。これは非常に便利なことです。つまり、新しいコードパスを手に入れて、新しいバックエンドシステムの使用を検討している場合、まずは5%のトラフィックをプッシュして、その後10, 20, 30, 50と増やしていき、一部のユーザーに対して機能をオンにすることができるのです。異なるバージョンのソフトウェアを異なるサーバーで実行したり、本番環境に入れたり出したりといったことを慎重に行う必要はなく、すべてコードで行うことができます。バケットテスト = 徐々に利用者を増やす

Slide 86

Slide 86 text

Paul Hammond 18:11 そして最後に、ダークローンチこれは、先ほどJonathanがFacebookの話をしたときに言っていたことですが、新しい機能を舞台裏で立ち上げることができるのです。例えば、検索クラスタのデータベース・サーバーの memcachedボックスに負荷をかけるような新機能があった場合、その機能を裏でオンにして、数週間データの取得を開始し、そのデータは表示しないようにします。ダークローンチ = 表示はしないが動かす

Slide 87

Slide 87 text

John Allspaw 21:12 100%懸念通りの結果がでたら、それを無効にすることができます。また、サイトに影響を与えているもの、つまり可用性やパフォーマンスに関わるものの動作を変更することもできます。データベースクラスターがたまたま劣化していたり、他のバックエンドサービスが劣化していたりして、それが機能に依存している場合は、これを変更することができます。そして、サイトに影響を与えることなく、ロールバックすることができます。多くの場合、ロールフォワードしてオフにします。これらの機能フラグの中には、単にオンかオフかだけではないものもあります。Paulが言っていたように、量を変えられるノブのようなものもあります。だから良いのです。ダメなら問題なく戻せる

Slide 88

Slide 88 text

John Allspaw 21:12 メトリクスの共有。メトリクスを共有することは、バージョンコントロールを共有することと同じです。あなたは私のビットを見ることができ、私はあなたのビットを見ることができます。まあ、私たちはメトリクスを集めています。 5.メトリクスの共有

Slide 89

Slide 89 text

John Allspaw 21:12 これは私たちのガングリオンのインストールのスクリーンショットです。37の異なるクラスターがありますが、どれだけの数のメトリクスを収集しているかわかりません。ここで重要なのは、開発者はこれがどこにあるかを知っているだけでなく、アクセス権を持っていて、運用と同じくらい熱心に見ているということです。オフィスを歩けば、すべての開発者が少なくともブラウザの1つのタブに、このようなものを持っています。 Devもサーバーメトリクスを見る

Slide 90

Slide 90 text

Paul Hammond 24:10 これが、アプリケーションにおける適応型フィードバックループの作成につながります。つまり、非同期に起こっていることがあれば、システムがうまく機能していない場合には、アプリケーションが手を引いて、システムへの負荷を減らすようにすることができるのです。先ほど説明したオフラインタスクセンターは、データベースが過負荷になり始めると、実際にダイヤルバックして、データベースがリアルタイムの負荷に対応できるようにしてくれます。もし10分後にオフラインタスクを実行する必要があっても、それは大したことではありません。また、Yahooフォトからflickerへの移行を行った際には、ストレージの空き容量に応じてスロットルをかけ、ストレージが不足しないようにしました。問題が出たらDev側で変更対応できる

Slide 91

Slide 91 text

John Allspaw 27:58 コミュニケ―ションは、ツールの最後のパートです。flickerでは、他の多くの場所と同様に、IRCを多用しています。開発者と運営者の間の継続的な対話のために使用しています。IRCは、特にリモートで仕事をしている人にとっては便利です。それで、このような会話が行われているわけです。そして、文脈があるのは良いことだと思います。そこで私たちは、前回のFMで、まさにこのようなことをするための素晴らしい小さなツールを書きました。 6.IRCとIMロボット

Slide 92

Slide 92 text

John Allspaw 27:58 IRCのストリームにイベント、つまりコンピュータ主導のイベントを流します。例えば、私たちが本当に気にしている特定のアラートやモニターは、ビルドログや、何かがデプロイされたときのデプロイログです。つまり、あなたは会話をしていて、ある書き換えルールとデプロイでこんな問題が起きていることを知らないのです。それについてどう思いますか、それともアラートが出ないのですか？そこで実際にやることは、このログに記録された情報をすべて、検索エンジンに突っ込むことです。そうすれば、2ヶ月前の木曜日に一体何をしていたのか、何が起こっていたのかを知ることができます。以前にもこのような問題があったのか。人間がコンテキストを持つようになったということで、本当に助かりました。 IRCツールで過去にさかのぼって調べられるだけでなく、実際に人間の文脈があるわけですから。ログとアラートをIRCに集める

Slide 93

Slide 93 text

Paul Hammond 29:28 どのようなツールを導入しても、信じられないほどの議論好き、闘争心の強い文化の下では、役に立ちません。そしてもうひとつ、私たちの仕事ぶりを非常に楽にしていると思うのが、フリッカーが持つ文化です。自動化されたインフラのようにね。申し訳程度のグラウンドゼロのようなもので、ツールに関しては非常に基本的なことをしなければならないようなものです。そしてここから文化の話

Slide 94

Slide 94 text

1.リスペクト

Slide 95

Slide 95 text

Paul Hammond 29:28 文化に関して言えばこれを言うのはちょっと偽善的ですが、最も重要なことの1つは固定観念を避けることです。あなたが5年前に一緒に働いていたカウボーイは、あなたのアプリケーションに関心がなかったり、システムのアップタイムに関心がなかったりしましたよね。しかし、あなたが一緒に仕事をする開発者の全員が彼のようなウイルスに感染しているわけではありませんし、運用担当者の全員が彼のように妨害されるわけではありません。誰もが最悪の事態を想定するなら、誰もがあなたに最悪の事態を想定することになるでしょう。相手をステレオタイプで捉えるな

Slide 96

Slide 96 text

Paul Hammond 30:36 誰もが繊細な小さな雪の結晶であり、誰もが少しずつ、彼らは異なる経験を持っており、あなたとは異なる問題解決策を思いつくからです。それらの解決策はベストなものではないかもしれませんが、少なくとも彼らの提案を尊重すべきです。もうひとつ重要なことは、人それぞれの責任を尊重することです。私たちは皆、ビジネスに対して異なる責任を負っています。つまり、私たちはそれぞれ異なる優先順位を持っているということです。それを理解し、認識し、そして尊重することが大切です。人々の専門性、意見、責任感を尊重する

Slide 97

Slide 97 text

John Allspaw 31:20 それは、問題について会話をするときに、「いいえ」と言うことは、「あなたの問題には関心がありません」と言っているようなものだということです。ブルーム・フィルターは書けません。開発者が問題を解決しようとしているのか、運用担当者が問題を解決しようとしているのか、何を解決しようとしているのかを知ることができます。ここで最もクールなものを見つけることができます。規模の壁を乗り越えて成功した企業のほとんどは、開発者と運用担当者が一緒になってユニークなソリューションを考え出したところです。memcachedがいい例です。かつては、データベースといえば、DBAや運用担当者がいて、それが彼らの仕事だったんです。私は開発者なので、コードを書きます。そして、どこかに魔法のようなデータベースがあって、私に代わって答えを出してくれる。そして、memcachedが開発されました。そして、この問題を解決するために様々なアーキテクチャが設計されました。そして、それが実現したのは、開発者と運用者が一緒に仕事をしたときだけです。ただ「ノー」と断るより、建設的に

Slide 98

Slide 98 text

Paul Hammond 32:41 もし、あなたが問題を解決しようとしているときに、同僚や他のチームからの反応が「それはダメだ」というものであることがわかっているなら、解決策を隠しておくのは、本当にダメなことです。私がやりたいことをジョンが断るとしたら、それはおそらく正当な理由があるはずです。それを隠してしまうと、彼に専門知識を提供する機会を与えないことになります。さらに重要なことは、もし私が何かを隠していたら、彼はいずれそれを知ることになるでしょうし、知ったときにはきっと怒るでしょう。べきです。専門知識を包み隠さず

Slide 99

Slide 99 text

Paul Hammond 32:41 繰り返しになりますが、開発者にとって、自分の仕事に敬意を払ってもらうためにできることのひとつは、何かを立ち上げる前、あるいは何かを提案する前に、その影響について前もってOpsに相談することです。もしあなたがコードを公開するなら、どのような指標が変わるでしょうか？どのようなボックスでしょうか？ CPUの使用量は増えますか？どのボックスの空きメモリが増えますか？何かが間違っているかもしれないリスクは何ですか？実際に何か問題が起きていることを示す兆候は何ですか？では、運用チームは何に気をつけるべきでしょうか？そして、もし何かが起こり始めたら？不測の事態とは何か？サイトを継続的に運営するために、オペレーションチームはどのように回復することができるのでしょうか？これらの答えを導き出すための問題は、オペレーションチームに話を聞きに行く前に、これらの答えを導き出す必要があるということです。すべての答えを得ることはできないかもしれませんが、少なくともこれを会話のベースにすべきです。対話のきっかけにする

Slide 100

Slide 100 text

John Allspaw 34:05 そして、信頼へとつながっていきます。最後のスライドには、この会話を成立させるのに役立つ様々な事柄や推奨事項が書かれています。つまり、開発者が運用担当者のところに来て、不機嫌な運用担当者だけど、そんなに長くは不機嫌にならないだろうと思って、こう言ったとしましょう。クラスタ A,B,Cの低い特性が変わると思うんだ。これを作ったんだけど、小さなフックがあって、これをゼロに設定できるんだ。何かあったら私のせいにしてください。この機能のために、このコードを入れるのは良いことだと思わなければなりません。この男は本当に考えているんだな。それだけではなく、彼はこのことを気にかけています。彼はサイトのアップタイムを気にしているし、真夜中に私のチームを起こさないように気にしています。 2. 信頼

Slide 101

Slide 101 text

Paul Hammond 35:25 開発チームは、運用チームがインフラの変更について事前に話し合うことを信頼する必要があります。繰り返しになりますが、本当に当たり前のことをしているように聞こえます。しかし、私は過去にいくつかの機能不全のチームで働いたことがありますが、そこではこれが必要なこととして受け入れられていませんでした。これは、組織全体のためにベストを尽くそうとしている他のメンバーを、皆が信頼しているということに帰結します。勝手にやっちまう前に相談する = 信頼

Slide 102

Slide 102 text

Paul Hammond 36:17 この会話を確実に行うために私たちが実践していることは、可能な限り共有のランブックと共有のエスカレーションプランを作成することです。つまり、ジョンと私が一緒に座って、どんな機能を見ても、あるいはチームのメンバーが一緒に座って、この新機能が運用面でどのようにサポートされるのかを検討するのです。何を？失敗する可能性のあるシナリオは何か？誰がその修正に関与する必要があるのか、そのためにはどのような会話が必要なのか。リスクは何か？不測の事態に備えて、全員が参加しているかどうかを確認する。共有のランブック(作戦)とエスカレーションプラン(不測の事態の作戦)

Slide 103

Slide 103 text

John Allspaw 37:50 私は、開発者がシステム上で何が起こっているかを確認できるようにすべきだと考えています。電話のタグを渡すのは最悪です。シェルコマンドでは、ただの馬鹿です。ところで、開発者はあなたのマシンで動いているコードを書いています。もちろんガードレールは重要ですが、誰かに読み取り専用のシェルアカウントを与えることは、たとえ本番用のハードウェアで超偏執的になっていたとしても、リスクは低く、実際に何が起こっているかを見ることができます。それは、あなたが共有しているメトリクスを超えて、あなたが運用担当者として共有しているからこそ、彼らが実際に内部に入り込み、gangliaやNagiosにあるメトリクスだけでなく、あなたのすべてのメトリクスにアクセスできることを確認できるということです。そして、何が起こっているのかを見極める必要があり、それを許可することを恐れてはいけません。透明性: Opsはすべてを共有すべし

Slide 104

Slide 104 text

Paul Hammond 38:53 文化の3つ目の側面として、失敗に対する健全な態度についてお話しします。 3. 失敗に対する健全な態度

Slide 105

Slide 105 text

Paul Hammond 38:53 ここで重要なことは、失敗は必ず起こるということです。起こるかどうかは問題ではなく、いつ起こるかが問題なのです。失敗は必ず起こる

Slide 106

Slide 106 text

Paul Hammond 38:53 もしあなたが失敗を防ぐ方法を考えることに時間を費やしているのであれば、失敗が起こったときにどのように対応するかを考えることに時間を費やしていないことになります。例えば、航空会社のパイロットは、毎月何日も何時間もシミュレーターに通い、エンジンが止まったらどうなるかを考えます。何か問題が起きたときのための手順や、避難計画なども策定しています。防止策を考える時間 vs 回復策を考える時間

Slide 107

Slide 107 text

Paul Hammond 38:53 Flickrで障害が発生した場合は、オペレーションチームの担当者と上級エンジニア数名が待機し、できるだけ早く問題を解決するようにします。私が始めたことのひとつに、チームのジュニアエンジニア1人か2人にメッセージを送ることがあります。「いいかい、誰もオフィスにいないと仮定して、サイトがダウンしたと仮定して、君しかいないんだ。そして、停電が終わった後に、その内容を比較するのです。これは、この種の問題にどのように対応すべきか、チームの若手メンバーを訓練するための方法なのです。あなたしかいないときはどうする？

Slide 108

Slide 108 text

John Allspaw 41:46 非難しないこと。それは本当に基本的なことのように聞こえます。 4.非難を避ける

Slide 109

Slide 109 text

John Allspaw 41:46 問題が発生して、ああ、どうしよう？私はどうすればいいの？もしかしたら変わるかもしれません。何が起こっているかを人に知られたくないと思っているのでログを削除しようと思うんだけど、どうしよう？とか、鶏の頭を切って、私のコードに基づいてではなく、あなたのマシンに基づいて、やっとの思いで解明するんですよ。無駄な時間がやたらと多いんですよね。縄張り意識が物事を解決する邪魔をしているんだ。役割分担が問題の解決を遅らせる

Slide 110

Slide 110 text

John Allspaw 41:46 こうすればいいんじゃないかな？あなたはそれを理解することができます。あなたは物事を修正することができます。そして、後でそのことについて罪悪感を感じたいなら、そうすればいい。これは一般的に起こることです。私のチームでもPaulのチームでも、「自分のせいだ」と証明しようとする人が出てきます。自分のせいで壊れた。だって、1日に10回は誰にもわからないんだから。そうすれば、彼らはそれを修正する人になれると思います。そして、彼らはそれを修正する男になれるのです。見つけたら自分で直す

Slide 111

Slide 111 text

Paul Hammond 43:55 たとえ開発者が待機していたとしても、これが最初のページであることを知るのは、たいてい運用チームです。夜中に何かを壊してしまい、朝になってみると30分もの停電が発生していて、5人もの人が呼び出されて起こされたのは自分のせいだったというシナリオがあったとしたら、ただ謝るだけでいいんです。多くの開発チームが陥りがちなのが、オペレーションが存在すること、オペレーションが夜中に起こされて修正してくれることを当てにしていることです。しかし、自分自身に問いかけてみるのもいいでしょう。「もし、誰かが私の不足分を補ってくれなかったら、私は何か違うことをするだろうか？もし自分が夜中に起こされていたとしたら、何かを変えるべきだと思います。 Opsが夜中に起こされないように、自分ごとに

Slide 112

Slide 112 text

John Allspaw 45:56 はっきり言って、これは絶対に簡単なことではありません。しかし、あなたは、あなたは、あなたは、あなたが望むならば、お互いに興奮し続けることは自由です。これは簡単なことではない