DevOpsDays History and my DevOps story

by Yasunobu Kawaguchi

Slide 1

Slide 1 text

サービス運用はボールを落とさない競技 : 2009年DevOpsDays の誕生と私の身の回りの話川口恭伸 @kawaguti

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

• DevOps はどこから来たか • 実践者のコミュニティ • 私のちょっとした実践 • 外の人との共鳴と連鎖反応お話しすること

Slide 4

Slide 4 text

2001年にアンクルボブの呼びかけでユタ州のスキーリゾートに集まった17人の人々が議論の末にまとめたマニフェスト。「アジャイル」という言葉もここで採択された。アジャイルマニフェスト

Slide 5

Slide 5 text

https://agilemanifesto.org/iso/ja/manifesto.html

Slide 6

Slide 6 text

https://agilemanifesto.org/iso/ja/principles.html

Slide 7

Slide 7 text

バックグラウンドの違う 17人が集まったので、テクニカルな話もあれば、文化の話も入っていた・・・のがすごい。その後、たくさんの「私のアジャイル補完計画」が生まれたが、技術と文化の両方が入っているのは多くなさそう。たくさんのアジャイル補完計画

Slide 8

Slide 8 text

さようなら、すべてのアジャイル補完計画シン・アジャイル完結編𝄇𝄇

Slide 9

Slide 9 text

DevOpsの定義はない。 DevOpsDaysは実践者のコミュニティ。自分から情報を取りに行く。フラットなコミュニティは共鳴と連鎖反応を生む。計画外の出会いが大事。 DevOps→Days

Slide 10

Slide 10 text

https://www.devopsdaystokyo.org/

Slide 11

Slide 11 text

https://newrelic.com/blog/nerd-life/devops-name https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 12

Slide 12 text

https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 13

Slide 13 text

https://newrelic.com/blog/nerd-life/devops-name 2007年: ベルギー政府のデータセンター移行のコンサルティングを行っていたシステム管理者のPatrick Deboisは、開発者とシステム管理者の間の対立にフラストレーションを感じます。彼は解決策を考えます。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 14

Slide 14 text

https://newrelic.com/blog/nerd-life/devops-name 2008年8月: トロントで開催されたアジャイルカンファレンスで、ソフトウェア開発者のAndrew Shaferが「アジャイルインフラストラクチャー」と題した「Birds of a Feather」セッションの告知を掲示します。出席したのはちょうど1人だけでした。そう、Patrick Deboisです。そして、彼は会場を独り占めします。自分のトピックに関心がないと思ったAndrew は、自分のセッションをスキップしてしまったのです! 後になって、Deboisは廊下で幅広い会話をするためにShaferを追いかけます。彼らの話に基づいて、アジャイルシステム管理グループを結成します。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 15

Slide 15 text

https://newrelic.com/blog/nerd-life/devops-name 2009年6月: O'Reilly Velocity 09カンファレンスにて、John AllspawとPaul Hammondが「1日10回のデプロイ: Flickrにおける開発と運用の協力」と題した今や有名なトークを行います。遠隔で視聴していたDeboisは、直接出席できないことをTwitterで嘆きます。Paul Nasrat が「なぜベルギーで自分のVelocityイベントを開催しないのか?」とツイートで返信します。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 16

Slide 16 text

https://newrelic.com/blog/nerd-life/devops-name 2009年10月: Deboisはまさにそれを行うことを決意しますが、まず名前が必要でした。彼は開発（development）と運用（operations）の最初の3文字をとり、そこに「days」という単語を加え、DevOpsDaysと名付けました。10月30日、カンファレンスの扉が開き、開発者、システム管理者、ツールスミス、その他の人々の印象的な集まりが現れました。カンファレンスが終わると、継続的な議論がTwitterに移りました。覚えやすいハッシュタグを作るため、Deboisは名前を #DevOpsに短縮しました。そして、このムーブメントはその後ずっとDevOpsとして知られるようになりました。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 17

Slide 17 text

Lindsayは、DevOpsのアイデアをとても気に入り、オーストラリアのシドニーに持ち帰り、ダウンアンダーで最初のDevOpsDaysを開催しました。私自身とAndrew Schaefer、John Willisは一緒になり、Stefan Abbottと LinkedInのDaniel Franciscoの助けを借りて、 2010年版のvelocityの直後に、米国で最初の DevOpsDaysを開催しました。しかし、その間に、もっと興味深いことが起こり始めていました。これらの初期の対面ミーティングの勢いに火をつけられて、世界中から実践者のコミュニティが突然現れ、この新しいDevOpsという旗印の下で経験を共有し、アイデアを議論し始めたのです。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 18

Slide 18 text

これは、ツイートとブログ記事の雪崩の背後に築かれたオンラインの勢いの継続でした。人々は自分の経験を共有し、他の人から学んでいたのです。人々が自作の歌のパロディやミュージックビデオを作るようになったとき、 DevOpsが生の神経に触れていることは多くの人にとって明らかになりました。DevOpsは本格的な草の根運動になったのです。これはかなり稀なことで、当時はベンダーやアナリスト、伝統的なエンタープライズITショップのほとんどに無視されていました。しかし、この運動は、主にウェブ運用の背景を持つ実践者たちの情熱によって成長していました。彼らは主に自分の自由な時間にこれらのトピックについて議論し、書いていたのです。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 19

Slide 19 text

それに対応して、DevOpsコミュニティは、彼らが求めるベストプラクティスを形式化する新世代のツールを推進し始めました。これらのツールには、Puppet、Chef、 Vagrant、Juju、Rundeck、LogStash、FPMなどの楽しい名前がついていました。FPMのFが何を意味するのかは想像するしかありませんが、これらは真剣なツールでした。ほとんどの場合、これらのツールはレガシーツールが提供できるものを軽々と凌駕していました。コミュニティにとって、これらは新しいアイデアやプロセスについての考えを形式化する方法であり、より良い働き方を表す成果物でした。外部の人にとっては、これらは持っていないと羨ましくなるような光り輝く新しいおもちゃであり、会話に引き込まれるものでした。しかし、全体的に、これらのツールに対する熱意は、初期の活力となりました。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 20

Slide 20 text

すぐに、より洞察力のあるアナリストたちが、ここで何か面白いことが起こっていることに気づき始めました。そして、会話に加わるべきだと考えたのです。最初は、当時Redmonkにいた Michael Cote や、451グループにいた Jay Lyman などでした。その後、Gartner の Cameron Haight などが続きました。Cameron の影響は興味深いものです。それは微妙ですが、DevOps とエンタープライズの関係にとって潜在的に重要な転換点となる可能性があります。私はこの主張を決定的に証明することはできませんが、タイミングは確かに興味深いものです。2011年3月、Cameron はプレゼンテーションでスライドを紹介しました。それは、エンタープライズ IT ショップとそれにサービスを提供するベンダーに、 DevOps ムーブメントではそれまでほとんど聞かれなかったような強いシグナルを送ったのです。では、 Cameron が何と言ったのかを見てみましょう。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 21

Slide 21 text

彼は次のように言いました。「2015年までに、 DevOpsは大規模クラウドプロバイダーが採用するITストラテジーから、グローバル2000企業の20％が採用するメインストリームのストラテジーに進化するだろう」と。アナリストの言葉がわからないかもしれませんが、これは大まかに「DevOpsは本物だ、注目せよ」と訳せます。この20％という予測に固執する人もいるかもしれません。あまりに強気すぎるとか、控えめすぎるとか。しかし、それはポイントではありません。ポイントは、ここに明確なメッセージがあるということです。つまり、「DevOpsはエンタープライズに来ている。 DevOpsに乗るんだ」というメッセージです。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 22

Slide 22 text

それからそれほど経たないうちに、偶然かどうかはわかりませんが、ほとんどすべての大手ベンダーがDevOpsという言葉を取り上げ、自社のメッセージングに組み込み始めました。うまく使いこなしている企業もあれば、的を外している企業もあります。しかし、いずれにせよ、 DevOpsはあちこちに登場していて、それは良いことです。DTOでも、同じ頃にエンタープライズの関心が大幅に高まりました。突然、大手の有名企業が、お洒落なウェブ企業とは程遠いところで、DevOpsに興味を持ち始めたのです。 DevOpsは本当にキャズムを越えて、主流になる途上にありました。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 23

Slide 23 text

では、なぜこの歴史がそんなに重要なのでしょうか。私がDevOpsの歴史をそんなに大切にするのはなぜでしょうか。古い言葉にもあるように、自分がどこから来たのかを知らなければ、自分がどこに行くのかを知ることはできないと私は信じています。この歴史は、DevOpsについていくつかの重要なことを思い出させてくれます。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 24

Slide 24 text

まず、DevOpsは実践者から生まれ、実践者のためのものであることを思い出させてくれます。ベンダーやアナリストから生まれたものではありません。すでに見てきたように、ベンダーやアナリストが、メッセージをハイジャックしたり、人々が望まない製品やアイデアを押し付けたりしようとすると、コミュニティはあなたを回避する方法を見つけるでしょう。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 25

Slide 25 text

次に、DevOpsはモノではなく、製品でも仕様でも標準でもなく、職種でもないことを思い出させてくれます。コミュニティの集合的な声以外に、DevOpsが何であるか、何でないかを決める真の権威はありません。なぜなら、DevOpsは経験に基づく運動だからです。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 26

Slide 26 text

そう、DevOpsは実践者たちが集まり、何がうまくいって何がうまくいかないかを共有し、自分たちをより良くし、働く会社を助けるために協力することなのです。また、DevOpsは分散化されており、誰でも参加できることを思い出させてくれます。共有したい経験がある場合や、他の実践者から質問がある場合、あるいは他の実践者に質問がある場合は、いつでも歓迎されます。これがこの運動が始まった方法であり、今日も続いている方法なのです。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 27

Slide 27 text

そう、続けることに関して言えば、 DevOpsDaysはどうなっているでしょうか。最初の数回のイベントの後、シリーズ全体が本当に勢いを増し、それ以来、世界中で続いています。これらはコミュニティが主催するもので、無料か無料に近いものです。そして、勢いは衰えず、本当に運動の中核となる対面のミーティングになっています。そして、開催されるたびに、活力を与え、再活性化するのに役立っています。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 28

Slide 28 text

この分野で世界最高の人々と交流したいなら、ぜひDevOpsDaysに参加してください。実際、イタリアでもうすぐ開催されますし、その次はオーストラリアです。そして、世界中を巡っていくのです。ぜひDevOpsDaysに参加してください。そして、DevOpsDaysや他のDevOps関連のイベントで、このPatrick Duboisに会ったら、ハイタッチをして、ビールを奢って、ありがとうと伝えてください。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 29

Slide 29 text

でも、実際のDevOpsDaysイベントを待つ必要はありません。一年中、24時間365日、 DevOpsの会話はオンラインで続いています。だから、どんどん参加して、自分が学んだことを他の人と共有してください。というわけで、私が見てきたDevOpsの歴史はこんな感じです。時間の都合上、様々な人々や異なるイベントが省略されています。誰かを怒らせてしまったらごめんなさい。私は、正確な貢献よりも全体的なコンセプトを伝えようとしました。 https://www.youtube.com/watch?v=o7-IuYS0iSE

Slide 30

Slide 30 text

Agile 2008 での出会い。 2009年のFlickrの発表。ベルギーで第一回のカンファレンスを行い、その後 #DevOps がハッシュタグとして生まれる。そして、活動が自然と広がっていき、各地でイベントが行われる。実践者の集まり。 DevOps→Days

Slide 31

Slide 31 text

「DevOpsってなんなのかわからない」と聞かれます。そもそもDevOpsとはなんなのでしょうか？運用。運用が利益を生んでいることを明らかにすること全体のエコシステム。開発チームだけではない。 DevOpsって

Slide 32

Slide 32 text

開発チームが運用することもできる時代 = クラウド組織運営が必要だとして、アジャイル拡張手法やツリー型統制でうまくいくのか？ Flickrのスライドを再訪しよう開発と運用

Slide 33

Slide 33 text

DevOps の源流 : Flickr 10+ Deploys per Day のトーク (2009年) を再訪する https://www.youtube.com/watch?v=LdOe18KhtT4

Slide 34

Slide 34 text

John Allspaw 00:11 皆さん、聞こえていますか？はい。私の名前はジョン・アルスポー、Flickrのオペレーショングループを担当しています。 Paul Hammond 00:22 フリッカー社でエンジニアリンググループを担当しているポール・ハモンドと申します。 John Allspaw 00:29 今日の話は、実際には様々なトピックを扱う予定ですが、開発と運用がどのようにフィットして仲良くなり、実際に協力して、お互いに大馬鹿者ではないことを説明するための手段とでも言いましょうか。

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

John Allspaw 03:44 私はそうは思いません。運用チームの仕事は、サイトを安全で高速に保つことではありません。それは彼らの仕事ではありません。これは一部の人にとっては驚くべきニュースかもしれませんが、運用チームの仕事はビジネスを可能にすることです。

Slide 38

Slide 38 text

Paul Hammond 04:34 ビジネス要件に関して言えば、ビジネス、特にオンラインビジネスで働く上での最も重要な現実の1つは、ビジネスが変化を必要としているということです。もしあなたのビジネスが止まっているなら、TwitterやFacebookのような生意気な新興企業に乗っ取られてしまうでしょう。

Slide 39

Slide 39 text

Paul Hammond 04:34 もちろん、問題は変化です。ほとんどの障害の根本原因を見て一般化すると、変化がほとんどの障害の根本原因であるという結論に達します。ほとんどの障害は、数日前、数時間前、数週間前に変更がなければ起こらなかったでしょう。

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Paul Hammond 05:29 ですから、今日話すことのほとんどは、適切なツールの使用と、チーム内の良好な作業文化を通じて、変更のリスクを下げることについてです。これらの多くのツールで私たちが試みていることは、どんな変更でもサイトの障害や問題を引き起こさないという自信を高めることです。そして、障害が発生した場合に、それらから回復する能力を高める方法も見ていきます。

Slide 42

Slide 42 text

適切なツールの使用と、チーム内の良好な作業文化を通じて、変更のリスクを下げるサイトの障害や問題を引き起こさないという自信を高める障害が発生した場合に、回復する能力を高める Flickr ツール＋文化

Slide 43

Slide 43 text

少し時間をいただいて、私がやってきたことを話します。開発と運用、という２つの面へのかかわりについて。 DevOpsに出会った時にどう感じたかの背景として。わたしの話

Slide 44

Slide 44 text

97年から新卒で(株)QUICK に勤務しました。情報メンテナンスをする部門で3.5年。日々の市場データの管理をやったり、当番制でバッチ開始指示したり。 PC配ったり効率化したり。データが日々、利益を上げているので重要な仕事でした。情報の運用

Slide 45

Slide 45 text

2000年くらいに異動で、アプリを開発する部門に。株価がパカパカするアプリを JavaScriptとCSSで作りました。通信はActiveXコントロール、グラフは他社さん製で、 JVMで作られてました。アプリ開発

Slide 46

Slide 46 text

部署で新規サービスを出すことになり、企画に入って金融工学の話をしながら、PDFを Webデザインから動的に生成する仕組みを作ってました。ライブラリを見つけてきてはめただけですけど。「動くパンフレット」の基盤ができました。サービス開発

Slide 47

Slide 47 text

サーバ運用やる人がいないということでそちらも。最初1ラック8台くらいだったんですけど、8ラックくらいになりました。客先にもエッジサーバを置く仕組みだったのでその辺も設計から面倒みました。中身がなるべくシンプルで安定して動くものを。サービス運用

Slide 48

Slide 48 text

という感じで、開発と運用を両方ともやってきました。運用といってもほぼ自分が関わって基本設計から作ったものの運用でした情報の運用アプリ開発サービス開発サービス運用

Slide 49

Slide 49 text

運用の世界で、障害(Incident)というのは何らかの原因でサービスが中断した状態になること。障害中は復旧最優先で、対応に追われるし、信頼も低下して、結果的に収益も下がる。障害を避ける

Slide 50

Slide 50 text

障害 = 想定外の状況コントロールを失っている状態なので、いち早く本線に戻して、通常の業務を進められる状態にしたい。これが「対処」。本格的な「対応」はそのあと考えていく。

Slide 51

Slide 51 text

対処中にしてはいけないこと • 後悔、周りに言う • 根本原因を推測する • 正解あてっこゲーム • ドヤ顔、キレる • 作業者の集中を乱す • 犯人捜し • 障害の影響の話 • 今後の対応の話

Slide 52

Slide 52 text

対処中にすべきこと • 全員でゴールをはっきりさせる • 口と手を同時に動かす • 最も重要なことに集中する • できることを一つずつ終わらせる • ダメだとわかるのも完了 • なるべく短い時間で進捗を出す • 勝手にヒーローになろうとする人を避ける • 長期の話や改善案は、あらかじめ時間を決めて行う • ちゃんと休憩する

Slide 53

Slide 53 text

なので、できれば状況を予測可能な範囲に置きたい。確率的事象に関しては、確率分布を知りたい。統計的には大数の法則と、独立性が重要。ヒストリカル = 繰り返す。条件を同じにして、何度も行えば、いずれ安定する。とても不安

Slide 54

Slide 54 text

サイコロの確率サイコロを１つ振ると、 1～6のどれが出るかは、均等な確率になる。しかし、２つ振ると、最も中央の数値が確率が高くなる釣鐘型のカーブとなる。 (ただし独立していること)

Slide 55

Slide 55 text

サイコロの確率

Slide 56

Slide 56 text

二重化すると同時に落ちない限りはサービスが継続できる。じゃあ、3重化、4重化すればもっと安定する？しかし、故障確率も上昇する。毎日のように壊れた機材を直し続けることになる。機材の複雑性も増加。はっきり壊れてくれないのも大変困る(ゾンビは最悪)。多重化の功罪

Slide 57

Slide 57 text

どちらがよい？

Slide 58

Slide 58 text

実際のところ、クラスタリング(二重化)は相互監視のイベントの連続で、タイムアウトの閾値に依存する。ぜんぜんシンプルな仕組みではない。

Slide 59

Slide 59 text

負荷分散と耐障害のために多重化するのだけど、シンプルにしておくと、最小限のセットは小さくなる。その分だけを、ステージングのVM上に展開、１セットでテスト可能にする。これをゴールドディスク、と呼んでました。ゴールドディスク

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

ここをゴールドディスクにする

Slide 62

Slide 62 text

本番環境に複数台あるサーバにゴールドディスクからなるべく差異なく展開したいので、展開は自動化。 OSインストールして、最小限のソフトウェアをインストールした後は、自動展開されるように。展開の自動化

Slide 63

Slide 63 text

ゴールドディスク本番環境デプロイデプロイデプロイ

Slide 64

Slide 64 text

構成をシンプルにして、障害を検知しやすくしても、結局、直すのは人間。中身をわかっているチームを作らないと対処も対応もできない。障害への対処と対応をできるチームを作る必要がある。復旧は人間

Slide 65

Slide 65 text

構成を理解し、手順を作ったり、繰り返し見直したり。その中で自動化すべきところを自動化したり。自分でわかってないと対処が難しい。

Slide 66

Slide 66 text

自分を主人公にした時初めて、自分と物語空間の（リアルさを持った）一体化されたイメージを立体的に描くことが可能となる。中埜博 Hiroshi Nakano “ ” 16:00-

Slide 67

Slide 67 text

少し時間をいただいて、私がやってきたことを話しました。開発と運用、という２つの面へのかかわりについて。ツールと文化はたぶん両方必要なんです。わたしの話開発と運用

Slide 68

Slide 68 text

バージョン管理を使う。開発チームを超えてバージョン管理を共有。ワンクリックでデプロイまで行う。運用者は自分の作業範囲を安全なものにするのではなく、開発者に自由と責任を果たす機会を提供する。 Flickrのツール (前半)

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

Paul Hammond 09:35 私たちにはあらゆる種類のツールがありますが、このトークはそれについてではありません。アダムとエズラがもう少し後でそれについてのトークをする予定で、このトピックについてはもっと優れたプレゼンテーションが半ダースほどあります。しかし、ここでの主なポイントは、OSイメージを持っているというアイデアがあるということです。そして、このサーバー、このインフラストラクチャーのピース、またはクラウドのビットが実際に実行する何らかの役割があります。それはタスク駆動型のインフラストラクチャーです。

Slide 72

Slide 72 text

Paul Hammond 09:35 このサーバーとクラウドの違いは、このサーバーの周りに青い雲があるかどうかです。それだけで、考え方は同じです。例えばEC2でサーバーを運用していて、OSのイメージング側はamiが担当していても、その上にロールと構成管理のレイヤーが必要になるということですね。

Slide 73

Slide 73 text

Paul Hammond 09:50 次に紹介するツールは、バージョン管理です。開発チームの中には、バージョン管理なしで運用しようとする人はあまりいないでしょう。そして、ますます多くの運用チームが使うようになっています。バージョン管理を使うことは、実際、かつて私たちがやっていたことでもあります。かつては、 FlickrのソースコードはCVS に格納されていましたが、運用やパッケージ、構成管理のすべてはPerforceに格納されていました。そのため、開発者は何が起こっているのかわからず、Perforceのリポジトリをどうやってチェックすればいいのかわからず、ジョンは CVSのリポジトリをどうやってチェックすればいいのかわからなかったのです。

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

Paul Hammond 09:50 開発の観点からは、ワンステップビルドを設定することが最も重要です。ワンステップビルドとは、現在svnのソースコントロールシステムに登録されているコードを、本番サーバーにコピーしてサイトを実行できるようなファイルセットにするために必要なすべてのことを意味します。

Slide 76

Slide 76 text

Paul Hammond 09:50 今お見せしているスクリーンショットは、Flickr内部の開発管理インターフェースの一部です。画面の一番下にある「ステージングを行う」と書かれたボタンをクリックすると、svnチェックアウトが行われ、すべての翻訳、すべてのテンプレートのコンパイル、最適化のためのコンパイルなどが行われます。そして、そのコードをステージング・サーバーにコピーして、テストできるようにします。 John Allspaw 12:07 自動的に自動的に、つまり、人がこのコマンドを実行していないのに、このコマンドを実行するのです。結論から言うと、コンピュータはコマンドを同時に実行するのがとても得意で、何度も同じ順番で実行されます。

Slide 77

Slide 77 text

Paul Hammond 12:20 ワンステップビルドができたら、次に必要なのはワンステップデプロイです。

Slide 78

Slide 78 text

Paul Hammond 12:20 これはFlickerの内部管理ツールで、上部にはデプロイログがあります。これは非常に安価な変更管理の形態で、誰もが何が起こっているのかを見ることができ、システムの他の部分で何か変更が行われているため、今はデプロイするのに最適な時期ではないかもしれないと警告することができます。

Slide 79

Slide 79 text

Paul Hammond 12:20 そして、下部には「I'm feeling lucky」というボタンがあり、これを押すとコードがサイトにプッシュされます。これは、コードをサイトにプッシュしているときの様子です。ここでも同じ原則が当てはまります。ボタンを1つにすることで、エラーの余地が非常に少なくなります。つまり、一貫した環境でビルドとデプロイを行うことができ、間違える可能性のある手動の手順がないことを意味します。

Slide 80

Slide 80 text

Paul Hammond 12:20 そのため、ソースコードの差分を見ていれば、それがデプロイ時のアプリケーションの動作に見られる唯一の違いであることをかなり確信することができます。

Slide 81

Slide 81 text

John Allspaw 13:35 継続的デプロイメントをトレンドとして見ています。そして、継続的インテグレーションは、多くの運用ツールやベンダーが販売しているものだけでなく、オープンソースプロジェクトにも登場し始めています。それは良いアイデアなのです。このプロセスの最大の利点の1つは、デプロイログを持っていることです。これを一瞬でも見逃さないでください。私たちは誰が、いつ、何をしたのかを知っています。これは本当に重要です。

Slide 82

Slide 82 text

John Allspaw 13:35 ジョン・アダムスは先ほど、モニタリングとメトリクスツールの一番上にデプロイのタイムスタンプを置いていると言いました。コンテキストは絶対的に重要です。このトークのタイトルは「1日10回以上のデプロイ」ですが、1日に10回ダウンしてしまうのなら、1日に10回デプロイしようとしたり、そのふりをしたりすることはできません。それはアジャイルではなく、単に遅れているだけです。

Slide 83

Slide 83 text

Slide 84

Slide 84 text

ここからは、カンファレンスの話をしていきます。私の話であり、 DevOpsの話であり、たぶん皆さんの話でもあるかなとカンファレンス

Slide 85

Slide 85 text

2007年にVMWorldというカンファレンスに参加した。キーノートで ESXiが発表。サーバ本体にUSBメモリで供給される仮想OSになった。これで時間のかかる OSインストールが不要に。 VMWorld

Slide 86

Slide 86 text

OS ESXi OS OS

Slide 87

Slide 87 text

ESXi によってハードウェアとソフトウェアがキレイに分離し、単機能のOS/アプリが実現可能になった。その後のコンテナ技術やクラウド技術の基本形と一致する。 ESXi とコンテナ化

Slide 88

Slide 88 text

VMWareを実際に作っている人が来て話している。これからどうしようとしているのか、どんな意見に対応するのか。見えている技術トレンドや他社との協業関係。戦略の話からチュートリアルまで。商業カンファレンスだけど、コミュニティ作りだった。海外カンファレンス

Slide 89

Slide 89 text

有名な人に話をしてもらおう。そうすれば、聴衆が集まる。人が多いイベントには価値がある。マーケティングしよう。その技術に関する人が集まるなら、スポンサーも集まる。

Slide 90

Slide 90 text

やってる人に話をしてもらおう。そうすれば、やってる人ややろうとしている人が集まる。学びや勇気をもらえるイベントには価値がある。継続的に開催しよう。その技術に関する人が集まるなら、スポンサーも支援してくれるかも。

Slide 91

Slide 91 text

最初に栃木の関将俊さんの講演を聞いた。新しいことを社内で始めるには「信頼貯金」が必要だと。これまでの人間関係や社内での活動の実績の集積。「アイツになら、しばらく任せてみようか」と納得してもらえるかどうか。デブサミ

Slide 92

Slide 92 text

ハイキュー!! 10巻（C）古舘春一／集英社

Slide 93

Slide 93 text

ハイキュー!! 10巻（C）古舘春一／集英社 “その瞬間”が有るか、無いかだ

Slide 94

Slide 94 text

Slide 95

Slide 95 text

関さんに聞いた「信頼貯金」。入社10年の自分にも結構あるかも。機会があったら、思い切って自分が考える通りにやらせてもらうことが重要かもしれない。 (自分の労力を超える部分について) 信頼貯金

Slide 96

Slide 96 text

10か月後くらいに、社内で相談が来た案件(ボール)を「チームを作る」ことを前提に拾った。担当しているインフラ運用もチームにした。あるべき方向に地道に話す。タイミングよく話す。

Slide 97

Slide 97 text

カンファレンスって、他校と集まる合宿みたいなものだな。なにが学べるのかを事前に知ることは難しいし。事前にわかっていることは、たぶん、そんなに重要じゃない。ハイキュー!! 10巻（C）古舘春一／集英社

Slide 98

Slide 98 text

トランクベース開発と、フィーチャフラグを組合わせ、本番にデプロイする。本番環境で、プライベートベータや、バケットテストやダークローンチが可能になる。メトリクスを共有する。コマンドとログを合わせてテキストチャットに流す。コンテキストがわかるように。 Flickrのツール (後半)

Slide 99

Slide 99 text

Paul Hammond 14:45 次に話すのは、これも開発者に焦点を当てたものですが、私たちがフィーチャーフラグと呼んでいるものです。これは、コード内でのブランチング (分岐)とも考えることができます。

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

Paul Hammond 14:45 私たちがそれに対処する方法は、常にトランクを出荷することです。これは、すべての開発をトランクで行うということではありませんが、私たちはそうしています。ブランチで開発を行い、それらのブランチをマージすることもできます。 ※現在主流の GitHubでは 2020年にtrunk は main に変更されました。

Slide 103

Slide 103 text

Paul Hammond 14:45 しかし、常にトランクを出荷することで、チームの全員が、現在サイトにデプロイされているコードのバージョンを正確に把握することができます。つまり、現在リリースされているのがどのパッチリリースのどのブランチなのかを考える必要がなく、SVNに行けば、そこにトランクがあるのです。 ※現在主流の GitHubでは 2020年にtrunk は main に変更されました。

Slide 104

Slide 104 text

Paul Hammond 14:45 SVNではブランチングを行わないと言いましたが、その代わりにコードでブランチングを行います。つまり、すぐにリリースしない機能を開発する際は、条件文を使ってそれらの特定のコードパスをブロックするのです。ここにPHPの例があります。smartyの例です。実際にはまだリリースされていないすべての新機能のコードを、本番サーバーの本番環境に置くことができるのです。ただ、設定が行われているので、まだ実際には見えないだけなのです。

Slide 105

Slide 105 text

Paul Hammond 18:11 これにより、いくつかの本当に素晴らしいトリックができるようになります。1つ目は、本番サーバー、本番ハードウェア、本番トラフィックでプライベートベータを行えるということです。もちろん、私たちには非常にリアルなテストができる素晴らしいステージング環境があります。そして、それらの環境で多くの QAを行っています。しかし、私たちが発見したことは、テストに別のサーバーセットを使用すると、ベータサーバーと本番サーバーの間の設定の変更に気づかない可能性があるということです。構成管理を使用していても、それは起こります。過去には、新しい機能がベータサーバーで完璧に動作していたのに、本番環境に移行した途端、依存していたバックエンドの内部 Webサービスが本番のWWWからブロックされていることに気づいたケースがありました。そのため、その機能は動作せず、そのバックエンドWebサービスに緊急の変更要求を出さなければなりませんでした。

Slide 106

Slide 106 text

Paul Hammond 18:11 これにより、バケットテストを行うことができます。これは非常に便利で、新しいコードパスがあれば、使用を検討している新しいバックエンドシステムがあれば、トラフィックの5%をそこにプッシュし始め、それを10、20、30、50%と増やすことができます。ユーザーのサブセットに対して機能をオンにすることができます。そして、異なるバージョンのソフトウェアを異なるサーバーで実行し、ボックスを本番環境に出し入れするために細心の注意を払う必要はありません。すべてをコードで行うことができるのです。

Slide 107

Slide 107 text

Paul Hammond 18:11 最後に、Jonathan がさきほど Facebook について話したときに言及した、ダークローンチ（水面下でのローンチ）ができます。新しい機能を舞台裏でローンチするのです。memcached ボックス、データベースサーバー、検索クラスターに負荷がかかる新しい機能がある場合、その機能を舞台裏でオンにして、数週間データを取得し始めますが、そのデータは表示しません。そして、実際にこの新しい機能をローンチする頃には、数週間負荷をかけていたので、負荷に耐えられることがわかっているのです。

Slide 108

Slide 108 text

John Allspaw 21:12 私たちは数百のフラグを持っているので、物事をオフにしたり、サイトの可用性やパフォーマンスに影響を与えている物事の動作を変更したりできます。データベースクラスターに何らかの劣化があったり、他のバックエンドサービスに何らかの劣化があり、それが特定の機能に関連している場合、私たちはこれを変更できます。そして、サイトに影響を与えることなく、ロールバックするのでしょうか。実際にはそれほど頻繁ではありません。私たちがするのは、前に進んで、それをオフにすることです。これらのフィーチャーフラグの中には、オンとオフだけでなく、ポールが言ったように、可変量を持つノブのようなものもあります。

Slide 109

Slide 109 text

John Allspaw 21:12 バージョン管理と同じように、共有メトリクスも重要です。共有バージョン管理を持つのと同じように、私はあなたのビットを見ることができ、あなたは私のビットを見ることができます。私たちはメトリクスを収集しています。大量のメトリクスを収集しています。

Slide 110

Slide 110 text

John Allspaw 21:12 これは私たちのGangliaのスクリーンショットです。私たちは約37の異なるクラスターを持っており、1秒間に何万ものメトリクスを取得しています。ここで重要な点は、開発者はこれがどこにあるかを知っているだけでなく、アクセス権を持ち、運用と同じくらい執着心を持って見ていることです。

Slide 111

Slide 111 text

Paul Hammond 24:10 これは、私たちの非同期タスクキューにあるバックグラウンドタスクの数を示すグラフです。興味深いことの1つは、実際に私がこのグラフに表示されているメトリクスを作成したことです。そして、私がこのグラフを作成した理由の1つは、ジョンのチームに頼まれたからではなく、私たちのオフラインタスクシステムがどのように機能しているかを知りたかったからです。ここで興味深いのは、開発者がこれらの伝統的に運用上のメトリクスを作成したいと考えているという状況があることです。そして、ジョンのチームは、私たちがそれを簡単に作成できるようにしてくれます。私たちは今、アプリケーションのどの部分でもキーと値のペアを含むファイルを書き込むだけで、Gangliaの設定がそれを取り込み、私たちのために美しいグラフを作成してくれるフレームワークを持っています。

Slide 112

Slide 112 text

Paul Hammond 24:10 これは、アプリケーションの中に適応型フィードバックループを作成することにつながります。非同期に発生している事柄がある場合、システムがうまく機能していないときに、アプリケーションがバックオフしてシステムへの負荷を軽減しようとすることができます。先ほど述べたオフラインタスクセントリズムは、データベースが過負荷になり始めると実際に調整されて、データベースがリアルタイムの負荷に対処できるようにします。オフラインタスクを10分後に実行する必要があっても、それは大した問題ではありません。そして、Yahoo PhotosからFlickrへの移行を行った際には、ストレージの空き容量に基づいてスロットリングを行い、ストレージが不足しないようにしました。

Slide 113

Slide 113 text

John Allspaw 27:24 実際に、私たちが持っている全てのメトリクスの全てのページに、最後のサイトデプロイの時間を記載しています。 Paul Hammond 27:35 そして、これによって、特定のグラフが2倍になったり半分になったりした理由を簡単に特定できることがよくあります。これは、私のチームの1人が画像処理コードの最適化をロールアウトした例です。私たちはそれがどのような効果をもたらすかわかりませんでしたが、少しの効果があるかもしれないと考えていました。しかし、結果はかなり大きなものでした。

Slide 114

Slide 114 text

John Allspaw 27:58 コミュニケーションは、ここでのツールの話の終わりに近づいています。私たちは、他の多くの場所と同じように、Flickrでは多くのIRCを使用しています。そして、開発者と運用担当者の間の継続的な対話、サイトで何が起こっているのか、何に取り組んでいるのかに使用しています。多くのボールを空中に持っている多くの人がいて、IRCは特にリモートで働く人に役立ちます。この会話が行われています。そしてコンテキストを持つことは良いことです。 ※IRC(Internet Relay Chat)は、 1990～2010年くらいまで主流だったオンラインチャットプロトコル。

Slide 115

Slide 115 text

John Allspaw 27:58 コンピューター駆動のイベントをIRCのストリームに送り込みます。例えば、私たちが本当に気にしている特定のアラートとモニター、ビルドログ、何かがデプロイされたときのデプロイログなどです。(中略) そこで私たちが実際に行っていることは、このログ情報のすべてを取得して、検索エンジンに突っ込むことです。そうすれば、「2ヶ月前の木曜日に一体何をしたのか、何が起こっていたのか、この問題を以前に見たことがあるか」などと言うことができます。これは本当に役立ちます。なぜなら、人間がコンテキストを持つことができるからです。 ※IRC(Internet Relay Chat)は、 1990～2010年くらいまで主流だったオンラインチャットプロトコル。

Slide 116

Slide 116 text

Slide 117

Slide 117 text

2017年にMS訪問。牛尾さんからのお誘い。その場で会場に連絡して、 Eventbrite作って、 3ヶ月でリリースした。ただし翌年もやること。目標は「コミュニティを作ること」とした。 DevOpsDays Tokyo リブート

Slide 118

Slide 118 text

東京でのDevOpsDays は 2012年、2013年に行われたが、その後は続いていなかった。 (理由は知りません。) https://legacy.devopsdays.org/events/2012-tokyo https://legacy.devopsdays.org/events/2013-tokyo

Slide 119

Slide 119 text

企業の会場を借りてカンファレンスをやるのは、社員さんに多大な負担がかかることをRSGTで学んだ。楽天テクノロジーカンファレンスでも DevOpsのセッションをやったが、「DevOpsDays」として企業が会場ホストして無料でやり続けるのはちょっと続かないと感じた。

Slide 120

Slide 120 text

海外カンファレンスだと、 USD1000～2000くらいの参加費。大崎ブライトコアホールは品川区の持ち物なので、リーズナブルに貸してくれる。この会場代や、招待スピーカーの渡航費を考えれば、全く無料ではなく、 USD100～200くらいの負担を参加者に求めるのは継続性があると思う。スタッフはボランティア。 https://osaki-hall.jp/

Slide 121

Slide 121 text

https://kawaguti.hateblo.jp/entry/2018/12/27/164751 カンファレンス運営のキャッシュフローの特性についてまとめました。

Slide 122

Slide 122 text

2020年4月はコロナ緊急事態宣言が出た時期で、飲み会も、海外からの入国も出来なくなり、開催断念。 2021年はハイブリッド開催。一人も来なくても会場は開けて待つことに。低コストで配信できる仕組みを作った。ハイブリッド開催へ

Slide 123

Slide 123 text

Slide 124

Slide 124 text

DevOpsDays を東京でやることになり、国内外から実践者のスピーカーを集めて話をしてもらうことに。高くない会場を借りて、チケット設定して、スポンサーをお願いしただけですけど、場の基盤が出来ました。サービス開発

Slide 125

Slide 125 text

スピーカーが会場に来ても来なくても登壇できるように、配信の仕組みを考えました。専用の人員を配置しなくても、継続的に配信できるように、 iPad を使って、Zoomで繋がる仕組みを作りました。配信はボランティアスタッフ。サービス運用

Slide 126

Slide 126 text

という感じで、開発と運用を両方ともやってきました。運用といってもほぼ自分が関わって基本設計から作ったものの運用でしたサービス開発サービス運用サービス開発サービス運用

Slide 127

Slide 127 text

2017年にMS訪問。牛尾さんからのお誘い。その場で会場に連絡して、 Eventbrite作って、 3ヶ月でリリースした。ただし翌年もやること。目標は「コミュニティを作ること」とした。実践者のコミュニティ

Slide 128

Slide 128 text

相手が異なるスキルを持つことを尊敬する。相手を信頼して、ノブとレバーを渡す。障害は常に起こる。そのための訓練を怠らない。相手のせいにしない。常に相手がカバーしてくれていることを想像し、問題を起こさない方法を考える。ちゃんと謝る。 Flickrの文化

Slide 129

Slide 129 text

Paul Hammond 29:28 これらのツールを全てインストールしても、非常に議論好きで好戦的な文化が続いていれば、あまり役に立たないということです。そして、Flickrで私たちの仕事をとてもやりやすくしていると思うもう一つのことは、私たちが持っている文化です。自動化されたインフラストラクチャーのように、それは、申し訳ありませんが、ツールに関して行う必要がある非常に基本的なことのようなものです。

Slide 130

Slide 130 text

Paul Hammond 29:28 文化に関しては、最も重要なこと、始めるべきことは、尊重の文化を持つことです。

Slide 131

Slide 131 text

Paul Hammond 29:28 私たちがこれを言うのは少し偽善的ですが、できる最も重要なことの一つは、ステレオタイプを避けることです。 5年前に、あなたのアプリケーションやシステムの稼働時間を気にしないカウボーイと一緒に働いたことがあるのは知っています。しかし、あなたが一緒に働くことになる開発者全員が彼のようなウイルスではありませんし、運用担当者全員が彼のように妨害的ではありません。

Slide 132

Slide 132 text

Paul Hammond 29:28 もし皆に最悪のことを想定するなら、皆もあなたに最悪のことを想定するでしょう。誰もが繊細な小さな雪の結晶で、誰もが少しだけ...それぞれの人の専門知識と意見を尊重することが大切です。なぜなら、彼らには異なる経験があり、あなたとは異なる問題解決の方法を思いつくからです。それらの解決策が最善とは限りませんが、少なくとも彼らの提案を尊重すべきです。

Slide 133

Slide 133 text

John Allspaw 34:05 運用担当者は、機能の議論に自分たちを巻き込んでくれる開発者を信頼する必要があります。

Slide 134

Slide 134 text

John Allspaw 34:05 つまり、あなたたちは「新しい素晴らしい機能が必要だ」と自分たちの間で話し合っているわけです。そして、「ねえ、運用担当者に話した方がいいかな、たぶん運用担当者にこのことを伝えるべきかな」と自問してみてください。私が言っているのは、キャパシティプランニングのような早期に行われるべき通常の運用作業のことではありません。それは当然のことです。私が言っているのは、サイトに起こる変更のことです。

Slide 135

Slide 135 text

Paul Hammond 35:25 そして、開発チームは、運用担当者が事前にインフラストラクチャーの変更について彼らと話し合ってくれることを信頼する必要があります。 PHPがPHP 5にアップグレードされたことを、それが起こった翌日に知ることはないでしょう。繰り返しになりますが、これは本当に明らかにすべきことのように思えます。しかし、私は過去に本当に機能不全なチームで働いたことがあり、そこではこれが必要不可欠なものとして受け入れられていませんでした。そして、それは、組織全体のために皆が最善を尽くそうとしていることを、全員が信頼することに戻ってきます。

Slide 136

Slide 136 text

Paul Hammond 35:25 この会話が確実に行われるようにするために私たちが実践していることは、可能な限り、共有ランブックと共有エスカレーション計画を作成するよう努めることです。つまり、ジョンと私、あるいは私たちのチームのメンバーが一緒に座って、新しい機能がオペレーション上どのようにサポートされるかを正確に把握します。どのようなシナリオで問題が発生する可能性があるのか？それらを修正するために誰が関与する必要があるのか？そして、それは単に、リスクは何か、不測の事態は何かについての会話を強制し、全員が同意していることを確認するのです。

Slide 137

Slide 137 text

John Allspaw 36:57 開発者が監視し、注視するためのノブとレバー、つまり、開発者が苦労して作ったコードを監視するためのノブとレバーを提供することについて、私たちは言い過ぎることはできません。そして、開発者はフックとノブとレバーを書いて、これらのものを運用可能にします。 Paul Hammond 37:20 コードを塀の向こうに投げ込むだけでは不十分で、運用担当者が変更できないように、全ての変数に関する全ての前提条件をプリコンパイルしておく必要があります。20個の子プロセスを持つことが良い数だと思うなら、運用担当者が設定できるようにする必要があります。そうすれば、下層のハードウェアをアップグレードした場合に、運用担当者は自分たちでそれを実行できます。

Slide 138

Slide 138 text

Paul Hammond 38:53 さて、私たちが話したい文化の 3つ目の側面は、障害に対する健全な態度だと考えているものです。

Slide 139

Slide 139 text

Paul Hammond 38:53 ここで認識すべき重要なことは、障害は起こるものだということです。それは、起こるかどうかの問題ではなく、いつ起こるかの問題です。

Slide 140

Slide 140 text

Paul Hammond 38:53 そして、障害を防ぐためにどうすればいいかを考えるのにずっと時間を費やしているなら、障害が起きた時にどう対応するかを考える時間が全然ないことになります。例えば、航空会社、つまり航空機のパイロットは、何時間も、毎月何日もシミュレーターで過ごし、エンジンを失ったらどうなるか、ハドソン川に不時着したらどうなるかを計画しています。

Slide 141

Slide 141 text

Paul Hammond 40:13 しかし、それでも、何かが上手くいかない時のために手順を作成し、避難計画などを立てています。一つの考え方は、もしサイトの停止に直面しているなら、つまり、何らかの医療上の問題を抱えているなら、年に一度心臓発作に対処するEMT（救急隊員）に治療してもらいたいですか？それとも、数週間ごとに心臓発作に対処するEMTに対処してもらいたいですか？あなたの運用チームと開発チームの両方で育成する必要があるものの一つは、問題に迅速かつ効果的に対応する能力です。

Slide 142

Slide 142 text

John Allspaw 41:46 非難しないことは、本当に基本的なことのように聞こえます。

Slide 143

Slide 143 text

John Allspaw 41:46 私たちには「だれかのせいにしない(No fingerpointing)」というルールがありますが、実際にはそれを強制しなければならないようなルールではありません。なぜなら、私は非常に幸運なことに、責任が生じるとすぐにそれを引き受ける組織に関わっているからです。

Slide 144

Slide 144 text

John Allspaw 41:46 はい、これは進化した世界での典型的な問題です。問題が起こると、「ああ、なんてこった？どうしよう？変更するつもりだったのかも。私はわからない。人々に何が起こっているのか知られたくない。ログを削除しよう。何が起こっているんだ？」といった感じで、狼狽します。そして、「これは私のコードが原因ではない。あなたのマシンが原因だ」と言います。そして、ようやく原因を突き止めます。大量の時間の無駄ですよね？縄張り意識が物事の修正を妨げています。

Slide 145

Slide 145 text

John Allspaw 41:46 これは提案ですが、こんな風にすることができます。原因を突き止めて、物事を修正する。そして後で、もし罪悪感を感じたいなら、そうすればいい。これが一般的に起こることです。これはFlickrで実際に起こることで、私のチームでもポールのチームでも、むしろ、人々は自分たちのせいで壊れたのだと証明しようと必死になります。なぜなら、一日に10回も誰が原因かわからないですからね。そうすれば、彼らは問題を修正した人になれるのでしょう。

Slide 146

Slide 146 text

John Allspaw 43:28 そうですね。あなたが言ったことを再度強調しますが、開発者の皆さん、コードを書く時は、誰かが真夜中に起きることを覚えておいてください。開発者をオンコールにする組織もあります。真夜中に何かが起こるかもしれないと思っていて、自分はその場にいないか、セントマーチンの感謝祭に行く予定なら、他の人があなたのゴタゴタを片付けることになります。

Slide 147

Slide 147 text

Paul Hammond 43:55 たとえ開発者がオンコールになっていても、最初にページを受けるのは一般的に運用チームです。そして、あなたが真夜中に何かを壊してしまい、翌朝出社してみると、30分間の停止があなたのせいで、5人の人が呼び出されて起こされたことがわかったとします。そんな時は、ただ「ごめんなさい」と言えば、みんな気分が良くなります。

Slide 148

Slide 148 text

Paul Hammond 44:25 そして、多くの開発チームが陥りがちなことの一つは、運用担当者がいるという事実、つまり運用担当者が真夜中に起こされて彼らのためにこれらのことを修正するという事実に頼っていることです。しかし、自分に聞くべき質問の一つは、自分のミスを取り繕ってくれる人がいなかったら、何を違うようにするだろうか、ということです。もし真夜中に起こされるのが自分だったら変えるようなことがあるなら、たぶんそれらのことを変えるべきでしょう。

Slide 149

Slide 149 text

John Allspaw 44:49 運用担当者は、物事がどのように進んでいるかについて、建設的なフィードバック、継続的なフィードバックを提供すべきです。これらの人々は、あなたのビジネスを運営し、より多くのユーザーを獲得し、世界を支配するためにコードを書いているのです。だから、物事がどのように進んでいるか知るべきです。文句を言わないでください。彼らに何が起こっているのかを説明して、「ほら、毎朝6時に実行されるこのcronジョブは、そこまで大したことではないけど、でも...」と言ってください。彼らに説明してください。あらゆる種類のメトリクスがあります。あなたが見たいものも、彼らが見たいものも。情報を共有するだけです。

Slide 150

Slide 150 text

Slide 151

Slide 151 text

お話しすること (再掲とまとめ) • DevOps はどこから来たか • 実践者のコミュニティ • 私のちょっとした実践 • 外の人との共鳴と連鎖反応

Slide 152

Slide 152 text

Slide 153

Slide 153 text

Slide 154

Slide 154 text

Slide 155

Slide 155 text

Slide 156

Slide 156 text

相手が異なるスキルを持つことを尊敬する。相手を信頼して、ノブとレバーを渡す。

Slide 157

Slide 157 text

Slide 158

Slide 158 text

この場所が実践者のコミュニティであり続けますことを。予想外の共鳴と連鎖反応を IMAXを超える極上のシアターでご体験ください。