Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Revisit the DevOps Origin: 10+ Deploys Per Day...

Revisit the DevOps Origin: 10+ Deploys Per Day by Flickr

DevOpsDaysの活動のきっかけになった (そして DevOps という言葉ができることにつながった)、2009年のFlickr社の発表について、文字起こしして日本語をつけてみました。

DevOpsDays Tokyo 2022
https://confengine.com/conferences/devopsdays-tokyo-2022/proposal/16208/devops-flickr-10-deploys-per-day-2009

Original Video:
Velocity 09: John Allspaw and Paul Hammond, "10+ Deploys Per Day
https://www.youtube.com/watch?v=LdOe18KhtT4

Original Slide Deck:
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

Yasunobu Kawaguchi

April 21, 2022
Tweet

More Decks by Yasunobu Kawaguchi

Other Decks in Technology

Transcript

  1. DevOps の源流 : Flickr 10+ Deploys per Day のトーク (2009年)

    を再訪する https://www.slideshare.net/jallspaw/ 10-deploys-per-day-dev-and-ops-cooperation-at-flickr https://www.youtube.com/watch? v=LdOe18KhtT4
  2. 10 deploys per day Dev &ops cooperation at Flickr John

    Allspaw &Paul Hammond Velocity 2009
  3. John Allspaw 00:11 皆さん、聞こえていますか?はい。私の 名前はジョン・アルスポー、Flickrのオ ペレーショングループを担当しています。 Paul Hammond 00:22 Flickr社でエンジニアリンググループを

    担当しているポール・ハモンドと申しま す。 John Allspaw 00:29 今日の話は、実際には様々なトピックを 扱う予定ですが、開発と運用がどのよう にフィットして仲良くなり、実際に協力 して、お互いに大馬鹿者ではないことを 説明するための手段とでも言いましょう か。 Flickrで。
  4. Paul Hammond 00:51 しかし、始める前に、Flickrとは何 かについて少し話しておきましょう。 Flickrについて聞いたことがある人 は手を挙げてください。さて、 Flickrを知らない人のために説明し ますと、 Flickrは写真共有サイトで

    す。現在、約30億枚の写真を保存し ています。そして、1日の任意の時点 で、1秒間に約40,000枚の写真を提 供しています。これらの写真は、約6 ペタバイトのストレージを占めてい ます。子猫がたくさんいるように見 えるかもしれませんが、実はとても 大きいのです。
  5. John Allspaw 01:59 そして、ステレオタイプは、開発者と 運用者の典型的なタイプを作ります。 開発者の中には、ちょっと変わった人 もいるでしょう。開発者の中には、 ちょっと変わった人もいるかもしれま せん。彼らは数学の分野では本当に優 秀で、運用担当者は何か問題が起こる

    たびにパニックになります。興奮しや すいのです。お酒を飲みすぎることも あるし、飲まないこともある。このよ うに、真面目な話をすると、「どう ぞ」というステレオタイプになってし まうのです。
  6. John Allspaw 03:44 これは、ある人にとっては新しい発見かも しれませんが、運用(Ops)の仕事はビジネ スを可能にすることですよね?もしビジネ ス要件として、2週間ごとにサイトを停止 しなければならないとしたら、たとえあな たが最大のオンラインゲームプラット フォームであり、何百万人もの有料顧客を

    抱えていたとしても、その銀行顧客は可用 性が97%を許容します。 99.999%でな く。これは真実です。このサイトの安定性 と高速性を維持することは、よくあるビジ ネス要件です。ビジネス要件の話なんです。
  7. Paul Hammond 06:11 会場にいる皆さんの中で、自分はDev だと思っている人は何人いますか?自 分はOps側の人間だと思っている人は どれくらいいるでしょうか?また、両 方の仕事をしている人はどのくらいい るでしょうか?では、会場にいる運用 担当者の中で、最近、ユーザー向けの

    アプリケーションコードを変更したこ とがある人は何人いますか? John Allspaw 06:51 一握りですね。その変更をしたことを 喜んでくれる開発者と一緒に仕事をし ている人はどれくらいいるでしょう か?はは、何かおかしいですね。
  8. Paul Hammond 07:02 開発者の皆さんの中で、サイトに何ら かの問題が発生して、週末の夕方に見 つかったために、家で仕事をしたこと がある人はどれくらいいるでしょう か?この会場にいる開発者の3分の1 くらいでしょうか。ポケベルを持って いる人はどれくらいいますか?あるい

    はオンコールで、開発者である開発者 と開発者である開発者がいますか?サ イトが完全に落ちてしまうまでに、何 台のウェブサーバーを失っても大丈夫 かを知っている人は何人いるでしょう か?
  9. .Automated infrastructure If there is only one thing you do…

    Chef Puppet CFengine FAI System Imager Cobbler BCfg2
  10. Paul Hammond 07:42 つまり、Apache 1.3を実行している 10台のウェブサーバーと、 Apache 2.xを実行している3台の ウェブサーバーは、アップグレードの 最中でなければ、それが動いているこ

    とを、知ることができます。しかし、 このような一貫したプラットフォーム がなければ、開発者が仕事をするのは 本当に難しいのです。
  11. Paul Hammond 09:50 次に紹介するツールは、バージョン管理です。開発チームの 中には、バージョン管理なしで運用しようとする人はあまり いないでしょう。そして、ますます多くの運用チームが使う ようになっています。 バージョン管理を使うことは、実際、 かつて私たちがやっていたことでもあります。かつては、 FlickrのソースコードはCVSに格納されていましたが、運用

    やパッケージ、構成管理のすべてはPerforceに格納されてい ました。そのため、開発者は何が起こっているのかわからず、 Perforceのリポジトリをどうやってチェックすればいいのか わからず、ジョンはCVSのリポジトリをどうやってチェック すればいいのかわからなかったのです。
  12. Paul Hammond 09:50 1つの共有リビジョン管理システムがあれば、 チームの誰もが、どこを見れば特定のボック ス用の設定の最新インスタンスを見つけられ るのかを知ることができ、また、アプリケー ションで何が起こっているのか、どこに変更 があるのかを知ることができます。これは、 緊急時には本当に便利です。先週の金曜日、

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

    面の一番下にある「ステージングを行う」と書かれたボタンをク リックすると、SVMチェックアウトが行われ、すべての翻訳、 すべてのテンプレートのコンパイル、最適化のためのコンパイル などが行われます。そして、そのコードをステージング・サー バーにコピーして、テストできるようにします。
  14. Paul Hammond 09:50 今お見せしているスクリーンショットは、Flickr内部の開発管理インター フェースの一部です。画面の一番下にある「ステージングを行う」と書か れたボタンをクリックすると、svnチェックアウトが行われ、すべての翻 訳、すべてのテンプレートのコンパイル、最適化のためのコンパイルなど が行われます。そして、そのコードをステージング・サーバーにコピーし て、テストできるようにします。 John

    Allspaw 12:07 自動的に自動的に、つまり、人がこのコマンドを実行していないのに、こ のコマンドを実行するのです。結論から言うと、コンピュータはコマンド を同時に実行するのがとても得意で、何度も同じ順番で実行されます。 Paul Hammond 12:20 また、開発者が自分のワークステーションでビルドを行い、それが開発者 とは微妙に異なる設定になっているような状況もありません。そのため、 コードに大きな変更がなくても、その後の変更で、アプリケーションがデ プロイされたときの支払いが大きく変わってしまうのです。
  15. Paul Hammond 09:50 これはFlickr内部のデプロイ用管理ツールで、上部にはデプロイログ が表示されています。これは非常に安上がりな変更管理方法で、誰も が何が起こっているかを見ることができ、システムの他の場所で何か 変更が起こっているので、今がデプロイの絶好の機会であることを警 告することができるということです。下部には「I'm feeling lucky」と書かれたボタンがあります。これを押すと、コードが横に

    押し出されます。コードを横に押し出しているときの様子はこんな感 じです。同じ原理がここにも当てはまります。ボタンを1つにするこ とで、エラーの余地が非常に少なくなり、一貫した環境でビルドやデ プロイを行うことができ、間違った手動の手順がなくなるのです。つ まり、ソースコードの差分を見れば、それがデプロイされたときのア プリケーションの動作に見られる唯一の違いになると、かなりの自信 を持って言えるのではないでしょうか。
  16. John Allspaw 13:35 このプロセスで最も素晴らしいことの一つは、 デプロイ・ログがあることです。誰が、いつ、 何をしたかがわかります。John Adamsは、 監視・測定ツールの一番上にデプロイ時のタ イムスタンプを置いていることを先ほど紹介 しました。コンテキストが絶対的に重要なの

    です。この講演のタイトルは、1日に10回以 上のデプロイを行うというものです。1日に 10回もデプロイするふりをしたり、しよう としたりすることはできません。1日に10回 もサーバダウンしていたら、それはアジャイ ルではなく、ただのダメな人です。
  17. Paul Hammond 14:45 私がここで伝えたいことの一つは、Webページ上にプロセスを結びつけ ないワンボタンを設置するだけではないということです。ソースコント ロールのルートにmakeスクリプトやmakeファイルを置いているかもし れません。デプロイに関しては シェルスクリプトを実行するだけでもい いですし、Capistranoを使ってもいいですし、RPMを使ってもいいで しょう。先ほど紹介したデプロイシステムは、Flickrのメインアプリ

    ケーションがどのようにデプロイされるかを示しています。周辺の小さ なアプリケーションで実験を始めていることの一つに、継続的インテグ レーション・サーバー(Hudson)を使ってパッケージを自動的に生成 し、運用チームがボックスにデプロイする方法があります。繰り返しに なりますがSVNのファイルをコミットするだけのシングルステップビル ドです。SVNのファイルをコミットし、ボタンを1つ押すだけでパッ ケージが生成されます。そして、シングルステップデプロイでは、運用 チームの誰かが実際にそのパッケージや開発者をデプロイしていきます。 ※Hudsonは 現在の Jenkins です。
  18. Paul Hammond 14:45 リビジョン管理の分岐システムについて考えて みると、それはデスクトップソフトウェアを構 築する際の現実に対する反応です。そして、開 発チームはすぐにMicrosoft Word 1.1の開発 を始めます。そして、makeを動かして、1.1を

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

    のです。ここでは、PHPの例を紹介し ます。これはSmartyの例です。つまり、 まだリリースされていないすべての新 機能のコードを、実際に本番サーバー に置いておくことができるのです。本 番サーバーでは、設定を変更するだけ で、まだ実際には表示されません。
  20. Paul Hammond 18:11 この機能により、いくつかの優れたトリックが可能 になります。1つ目は、本番サーバー、本番ハード ウェア、本番トラフィックでプライベートベータを 行うことができるということです。もちろん、私た ちには現実的なテストを行うことができる素晴らし いステージング環境があります。そして、そのよう な環境で多くのQAを行いました。しかし、私たち

    が発見したのは、テストのために2台目のサーバー を使用した場合、ベータ版サーバーと本番サーバー の間で設定の変更があることに気づくかもしれない ということでした。構成管理を行っていても、ベー タ版サーバーでは新機能が完璧に動作していたのに、 本番版サーバーに移行した途端に動作しなくなった ということがあります。しかし、本番環境に移行し た途端、頼りにしていたバックエンドの内部ウェブ サービスが、本番環境のダブダブからブロックされ ていることに気付きました。そのため機能が動作せ ず、そのバックエンドのウェブサービスに緊急の変 更要求を出さなければなりませんでした。
  21. John Allspaw 20:00 Opsにとっては、不安を取り除くことができるという点で、非常に大き なメリットがあります。申し訳ありませんが、ギグから恐怖を取り除く ことができるのです。そうではなくて、新しいお酒のホームページの例 を挙げてくれましたか?私は知りませんでした。そうですね。つまり、 私たちは新しいFlickrのホームページを再設計し、より多くの情報、基 本的にはあなたの連絡先からのアクティビティや、リアルタイムでスト リーミングされる様々な量のアクティビティを持っています。膨大な量

    のデータだよ。そうでしょ?ではどうすればいいのかというと、これか ら配信するすべてのホームページは、データベースからより多くのデー タを取得することになります。でも、データベースは最悪です。それは とても面倒なことです。そして、そして、そして、本当に怖いです。そ こで私たちは実行しました。何週間もかけてリリースしました。そう。 アプリケーションがそれを受け取って、データはどうなるんですか?お かげで、実際のローンチはまったく拍子抜けするようなものになりまし た。これはとてもいいことですね。そう、この時点で明らかになってい るはずなんです。これらの機能フラグや無効フラグは、今いくつあるの かな。
  22. John Allspaw 21:12 100点満点の結果が出れば、それを無効 にすることができます。また、サイトに 影響を与えているもの、つまり可用性や パフォーマンスに関わるものの動作を変 更することもできます。データベースク ラスターがたまたま劣化していたり、他 のバックエンドサービスが劣化していた

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

    でなく、アクセス権を持っていて、運用 と同じくらい熱心に見ているということ です。オフィスを歩けば、すべての開発 者が少なくともブラウザの1つのタブに、 このようなものを持っています。
  24. John Allspaw 21:12 CPU、ネットワーク、メモリ、ディスクなど のアプリケーションレベルのメトリクスをそこ に入れることができるということです。ユー ザーCPUが75%であろうと、そのうちの何% であろうと、私は気にしません。その役割とは、 サーバーがウィジェットを食べているかどうか、 1秒間に何個のウィジェットを食べているか、

    それぞれのパーツ、それぞれのビット、それぞ れのCPUの割合です。これは当然、キャパシ ティマネジメントやキャパシティプランニング などにも関わってきますが、もしそれが重要だ と思うのであれば、そのようなことも必要です。 これは、画像処理を行う特定のサーバーの、過 去1分間の平均値を示したグラフです。あなた が子猫をFlickrにアップロードすると、私たち はそれを6つ、あるいは5つ、あるいは6つの 異なるサイズに切り分けます。それぞれの処理 にかかった時間の平均値を示しています。
  25. Paul Hammond 24:10 これは、非同期タスクキューにあるバックグ ラウンドタスクの数を示したグラフです。面 白いのは、このグラフに表示されている指標 を私が実際に作ったことです。このグラフを 作成した理由の一つは、Johnのチームに頼ま れたからではなく、オフラインタスクシステ ムのパフォーマンスをある程度把握したかっ

    たからです。ここで興味深いのは、開発者が 伝統的な運用指標を作りたがるというダイナ ミックな状況があることです。ジョンのチー ムは、私たちがこれらを簡単に作れるように してくれました。今では、アプリケーション のどの部分であっても、キーと値のペアを含 むファイルを書くだけで、ガングリオンの セットアップがそれを取り込んで、かなり アーティスティックなグラフを作ってくれる フレームワークを持っています。
  26. Paul Hammond 24:10 これが、アプリケーションにおける適応型 フィードバックループの作成につながります。 つまり、非同期に起こっていることがあれば、 システムがうまく機能していない場合には、 アプリケーションが手を引いて、システムへ の負荷を減らすようにすることができるので す。先ほど説明したオフラインタスクセン

    ターは、データベースが過負荷になり始める と、実際にダイヤルバックして、データベー スがリアルタイムの負荷に対応できるように してくれます。もし10分後にオフラインタス クを実行する必要があっても、それは大した ことではありません。また、Yahooフォトか らFlickrへの移行を行った際には、ストレー ジの空き容量に応じてスロットルをかけ、ス トレージが不足しないようにしました。
  27. John Allspaw 25:42 ああ、あれは本当にいい例です。このように、数ヶ月に及ぶプロセスが ありますよね。彼らはYahooフォトを閉鎖していますが、Yahooフォ トをどうするかの選択肢の1つとして、Shutterflyや他のいくつかの場 所に行って、 Flickrに移行することができますよね?本質的には何なの でしょうか?10年分のYahooの写真を、Flickrが持っているのと同じ フォーマットで、すべてのメタデータとともにFlickrにインポートする

    には、膨大な時間がかかるでしょう。ですから「Flickrに移行したいと 思うのですが」「わかりました。あとでご連絡します。」と答えなけれ ばなりませんでした。Yahooの写真とFlickrでは大きな違いがあったの で、異なるサイズに処理しなければなりませんでした。ご存知のように、 私たちはどのくらいの量のストレージがいつオンラインになるのか、か なり厳密に把握しています。しかし、私たちが知らなかったのは、何人 の人がそのボタンをクリックするのかという巨大な未知の変数でした。 「はい、フリッカーに行きます」と言う人はどれくらいいるか。移行の 全期間を通じて、本当にこの変数に依存していました。つまり、いつス ペースが足りなくなるかを予測し、それを変更していくということです。 そして、それに適応するための移行は、私たちにとって非常に大きな勝 利でした。
  28. John Allspaw 27:24 私たちは、すべての指標のすべてのページに、 最後にサイトが展開された時刻を表示してい ますが、これはすでに設定済みです。 Paul Hammond 27:35 そのため、あるグラフがなぜ2倍になったの

    か、あるいは半分になったのかを簡単に把握 することができます。これは、私のチームが 画像処理コードの最適化を行った例です。ど のような効果があるのかわからなかったので すが、ちょっとしたことだろうと思っていた ら、かなりの効果があることがわかりました。
  29. Dev, Ops, and Robots Having a conversation IRC search engine

    alerts monitors deploy logs build logs
  30. John Allspaw 27:58 IRCのストリームにイベント、つまりコンピュー タ主導のイベントを流します。例えば、私たちが 本当に気にしている特定のアラートやモニターは、 ビルドログや、何かがデプロイされたときのデプ ロイログです。つまり、あなたは会話をしていて、 ある書き換えルールとデプロイでこんな問題が起 きていることを知らないのです。それについてど

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

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

    つけることができます。規模の壁を乗り越えて成功し た企業のほとんどは、開発者と運用担当者が一緒に なってユニークなソリューションを考え出したところ です。memcachedがいい例です。かつては、データ ベースといえば、DBAや運用担当者がいて、それが彼 らの仕事だったんです。私は開発者なので、コードを 書きます。そして、どこかに魔法のようなデータベー スがあって、私に代わって答えを出してくれる。そし て、memcachedが開発されました。そして、この問 題を解決するために様々なアーキテクチャが設計され ました。そして、それが実現したのは、開発者と運用 者が一緒に仕事をしたときだけです。
  33. Developers:Talkto ops about the impact of your code: •what metrics

    will change, and how? •what are the risks? •what are the signs that something is going wrong? •what are the contingencies? This means you need to work this out before talking to ops
  34. Paul Hammond 32:41 繰り返しになりますが、開発者にとって、自分の仕事に敬意を払っても らうためにできることのひとつは、何かを立ち上げる前、あるいは何か を提案する前に、その影響について前もってOpsに相談することです。 もしあなたがコードを公開するなら、どのような指標が変わるでしょう か?どのようなボックスでしょうか?CPUの使用量は増えますか?ど のボックスの空きメモリが増えますか?何かが間違っているかもしれな いリスクは何ですか?実際に何か問題が起きていることを示す兆候は何

    ですか?では、運用チームは何に気をつけるべきでしょうか?そして、 もし何かが起こり始めたら?不測の事態とは何か?サイトを継続的に運 営するために、オペレーションチームはどのように回復することができ るのでしょうか?これらの答えを導き出すための問題は、オペレーショ ンチームに話を聞きに行く前に、これらの答えを導き出す必要があると いうことです。すべての答えを得ることはできないかもしれませんが、 少なくともこれを会話のベースにすべきです。
  35. Ops needs to trust dev to involve them on feature

    discussions Dev needs to trust ops to discuss infrastructure changes Everyone needs to trust that everyone else is doing their best for the business http://www.flickr.com/photos/85128884@N00/2650981813/
  36. John Allspaw 34:05 最後のスライドには、会話を成立させるのに役立つ様々な事柄や推奨事項が 書かれています。つまり、開発者が運用担当者のところに来て、不機嫌な運 用担当者だけど、そんなに長くは不機嫌にならないだろうと思って、こう 言ったとしましょう。「クラスタA,B,Cの低い特性が変わると思うんだ。こ れを作ったんだけど、小さなフックがあって、これをゼロに設定できるんだ。 何かあったら私のせいにしてください。」この機能のために、このコードを 入れるのは良いことだと思わなければなりません。この男は本当に考えてい

    るんだな。それだけではなく、彼はこのことを気にかけています。彼はサイ トのアップタイムを気にしているし、真夜中に私のチームを起こさないよう に気にしています。これは信頼の問題です。運用担当者は、機能の議論に参 加させるために開発者を信頼する必要があります。つまり、自分たちの間で 「新しい機能ができた、最高だ」と話しているわけです。ここで言っている のは、キャパシティプランニングのような、早期に行われるべき通常のオペ レーションの話ではありません。私が言っているのは、サイトに起こる変化 のことです。
  37. Paul Hammond 35:25 開発チームは、運用チームがインフラの変更につい て事前に話し合うことを信頼する必要があります。 繰り返しになりますが、本当に当たり前のことをし ているように聞こえます。しかし、私は過去にいく つかの機能不全のチームで働いたことがありますが、 そこではこれが必要なこととして受け入れられてい ませんでした。これは、組織全体のためにベストを

    尽くそうとしている他のメンバーを、皆が信頼して いるということに帰結します。 John Allspaw 35:58 「うん、うん、ジムには言わない方がいいよね。 だって、言ったらどうせ怒り散らすよね」「いいか らやっちまおうぜ」それはつまりあなたもクソッタ レのカウボーイになるってことです。ほかのみんな にもそれをしてほしくはないでしょう。
  38. John Allspaw 36:57 そうは言っていられないのです。開発者が苦労 して作ったコードを監視するためのノブやレ バーを提供することが多すぎるのです。そして、 開発者はこれらのことが運用できるように、 フックやノブ、レバーを書きます。 Paul Hammond

    37:20 ただコードを投げ込むだけでは不十分で、すべ ての変数にまつわる仮定があらかじめコンパイ ルされていて、オペレーションがそれを変更で きないようになっています。20個の子プロセ スを持つことが良い数字だと思うなら、オペ レーションが設定できるようにして、その下に あるハードウェアをアップグレードしたら、自 分たちでそれを実行できるようにしなければな りません。
  39. John Allspaw 41:46 こうすればいいんじゃないかな?あな たはそれを理解することができます。 あなたは物事を修正することができま す。そして、後でそのことについて罪 悪感を感じたいなら、そうすればいい。 これは一般的に起こることです。私の チームでもPaulのチームでも、「自分

    のせいだ」と証明しようとする人が出 てきます。自分のせいで壊れた。だっ て、1日に10回は誰にもわからないん だから。そうすれば、彼らはそれを修 正する人になれると思います。そして、 彼らはそれを修正する男になれるので す。
  40. Developers: Remember that someone else will probably get woken up

    when your code breaks http://www.flickr.com/photos/alex-s/353218851/
  41. Paul Hammond 43:23 何か変なことが起きていますね。うん。 John Allspaw 43:28 そうですね。繰り返しになりますが、「開発者 の皆さん、コードを書くときに、誰かが夜中に 目を覚ますかもしれない、ということを忘れな

    いでください」とおっしゃっていましたね。開 発者を待機させている組織もあります。真夜中 に何かが起こるかもしれないと考えたとき、あ なたが不在であったり、セントマーチン島の感 謝祭に行っていたりしたら、他の人があなたの クソを直してくれるでしょう。他の人があなた のクソを直してくれます。
  42. Paul Hammond 43:55 たとえ開発者が待機していたとしても、これが 最初のページであることを知るのは、たいてい 運用チームです。夜中に何かを壊してしまい、 朝になってみると30分もの停電が発生してい て、5人もの人が呼び出されて起こされたのは 自分のせいだったというシナリオがあったとし たら、ただ謝るだけでいいんです。

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

    4.Feature flags 5.Shared metrics 6.IRC and IM robots 1.Respect 2.Trust 3.Healthy attitude about failure 4.Avoiding Blame