DevOpsDays History and my DevOps story

a keynote at DavOpsDays Tokyo 2024
https://www.devopsdaystokyo.org/

Transcript

1. サービス運用は ボールを落とさない競技 : 2009年DevOpsDays の誕生 と私の身の回りの話 川口恭伸 @kawaguti
2. 川口 恭伸 かわぐち やすのぶ Twitter: @kawaguti YesNoBut株式会社 代表取締役社長 アギレルゴコンサルティング株式会社 シニアアジャイルコーチ 一般社団法人スクラムギャザリング東京実行委員会 代表理事 一般社団法人 DevOpsDays Tokyo 代表理事
3. • DevOps はどこから来たか • 実践者のコミュニティ • 私のちょっとした実践 • 外の人との共鳴と連鎖反応 お話しすること
4. 2001年に アンクルボブの呼びかけで ユタ州のスキーリゾートに 集まった17人の人々が 議論の末にまとめた マニフェスト。 「アジャイル」という言葉も ここで採択された。 アジャイル マニフェスト
5. https://agilemanifesto.org/iso/ja/manifesto.html
6. https://agilemanifesto.org/iso/ja/principles.html
7. バックグラウンドの違う 17人が集まったので、 テクニカルな話もあれば、 文化の話も入っていた ・・・のがすごい。 その後、たくさんの 「私のアジャイル補完計画」 が生まれたが、 技術と文化の両方が 入っているのは多くなさそう。 たくさんの アジャイル 補完計画
8. さようなら、 すべての アジャイル補完計画 シン・アジャイル完結編𝄇𝄇
9. DevOpsの定義はない。 DevOpsDaysは 実践者のコミュニティ。 自分から情報を取りに行く。 フラットなコミュニティは 共鳴と連鎖反応を生む。 計画外の出会いが大事。 DevOps→Days
10. https://www.devopsdaystokyo.org/
11. https://newrelic.com/blog/nerd-life/devops-name https://www.youtube.com/watch?v=o7-IuYS0iSE
12. https://www.youtube.com/watch?v=o7-IuYS0iSE
13. https://newrelic.com/blog/nerd-life/devops-name 2007年: ベルギー政府のデー タセンター移行のコンサルティ ングを行っていたシステム管理 者のPatrick Deboisは、開発 者とシステム管理者の間の対立 にフラストレーションを感じま す。彼は解決策を考えます。 https://www.youtube.com/watch?v=o7-IuYS0iSE
14. 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
15. 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
16. 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
17. Lindsayは、DevOpsのアイデアをとても気に 入り、オーストラリアのシドニーに持ち帰り、 ダウンアンダーで最初のDevOpsDaysを開催 しました。私自身とAndrew Schaefer、John Willisは一緒になり、Stefan Abbottと LinkedInのDaniel Franciscoの助けを借りて、 2010年版のvelocityの直後に、米国で最初の DevOpsDaysを開催しました。しかし、その 間に、もっと興味深いことが起こり始めていま した。これらの初期の対面ミーティングの勢い に火をつけられて、世界中から実践者のコミュ ニティが突然現れ、この新しいDevOpsという 旗印の下で経験を共有し、アイデアを議論し始 めたのです。 https://www.youtube.com/watch?v=o7-IuYS0iSE
18. これは、ツイートとブログ記事の雪崩の背後に 築かれたオンラインの勢いの継続でした。人々 は自分の経験を共有し、他の人から学んでいた のです。人々が自作の歌のパロディやミュー ジックビデオを作るようになったとき、 DevOpsが生の神経に触れていることは多くの 人にとって明らかになりました。DevOpsは本 格的な草の根運動になったのです。これはかな り稀なことで、当時はベンダーやアナリスト、 伝統的なエンタープライズITショップのほとん どに無視されていました。しかし、この運動は、 主にウェブ運用の背景を持つ実践者たちの情熱 によって成長していました。彼らは主に自分の 自由な時間にこれらのトピックについて議論し、 書いていたのです。 https://www.youtube.com/watch?v=o7-IuYS0iSE
19. それに対応して、DevOpsコミュニティは、彼らが求め るベストプラクティスを形式化する新世代のツールを推 進し始めました。これらのツールには、Puppet、Chef、 Vagrant、Juju、Rundeck、LogStash、FPMなどの 楽しい名前がついていました。FPMのFが何を意味する のかは想像するしかありませんが、これらは真剣なツー ルでした。 ほとんどの場合、これらのツールはレガシーツールが提 供できるものを軽々と凌駕していました。コミュニティ にとって、これらは新しいアイデアやプロセスについて の考えを形式化する方法であり、より良い働き方を表す 成果物でした。 外部の人にとっては、これらは持っていないと羨ましく なるような光り輝く新しいおもちゃであり、会話に引き 込まれるものでした。しかし、全体的に、これらのツー ルに対する熱意は、初期の活力となりました。 https://www.youtube.com/watch?v=o7-IuYS0iSE
20. すぐに、より洞察力のあるアナリストたちが、ここで何 か面白いことが起こっていることに気づき始めました。 そして、会話に加わるべきだと考えたのです。最初は、 当時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
21. 彼は次のように言いました。「2015年までに、 DevOpsは大規模クラウドプロバイダーが採用 するITストラテジーから、グローバル2000企 業の20％が採用するメインストリームのスト ラテジーに進化するだろう」と。アナリストの 言葉がわからないかもしれませんが、これは大 まかに「DevOpsは本物だ、注目せよ」と訳せ ます。この20％という予測に固執する人もい るかもしれません。あまりに強気すぎるとか、 控えめすぎるとか。しかし、それはポイントで はありません。ポイントは、ここに明確なメッ セージがあるということです。つまり、 「DevOpsはエンタープライズに来ている。 DevOpsに乗るんだ」というメッセージです。 https://www.youtube.com/watch?v=o7-IuYS0iSE
22. それからそれほど経たないうちに、偶然かどう かはわかりませんが、ほとんどすべての大手ベ ンダーがDevOpsという言葉を取り上げ、自社 のメッセージングに組み込み始めました。うま く使いこなしている企業もあれば、的を外して いる企業もあります。しかし、いずれにせよ、 DevOpsはあちこちに登場していて、それは良 いことです。DTOでも、同じ頃にエンタープラ イズの関心が大幅に高まりました。突然、大手 の有名企業が、お洒落なウェブ企業とは程遠い ところで、DevOpsに興味を持ち始めたのです。 DevOpsは本当にキャズムを越えて、主流にな る途上にありました。 https://www.youtube.com/watch?v=o7-IuYS0iSE
23. では、なぜこの歴史がそんなに重要 なのでしょうか。私がDevOpsの歴 史をそんなに大切にするのはなぜで しょうか。古い言葉にもあるように、 自分がどこから来たのかを知らなけ れば、自分がどこに行くのかを知る ことはできないと私は信じています。 この歴史は、DevOpsについていく つかの重要なことを思い出させてく れます。 https://www.youtube.com/watch?v=o7-IuYS0iSE
24. まず、DevOpsは実践者から生まれ、 実践者のためのものであることを思 い出させてくれます。ベンダーやア ナリストから生まれたものではあり ません。すでに見てきたように、ベ ンダーやアナリストが、メッセージ をハイジャックしたり、人々が望ま ない製品やアイデアを押し付けたり しようとすると、コミュニティはあ なたを回避する方法を見つけるで しょう。 https://www.youtube.com/watch?v=o7-IuYS0iSE
25. 次に、DevOpsはモノではなく、製 品でも仕様でも標準でもなく、職種 でもないことを思い出させてくれま す。コミュニティの集合的な声以外 に、DevOpsが何であるか、何でな いかを決める真の権威はありません。 なぜなら、DevOpsは経験に基づく 運動だからです。 https://www.youtube.com/watch?v=o7-IuYS0iSE
26. そう、DevOpsは実践者たちが集まり、何が うまくいって何がうまくいかないかを共有し、 自分たちをより良くし、働く会社を助けるた めに協力することなのです。 また、DevOpsは分散化されており、誰でも 参加できることを思い出させてくれます。共 有したい経験がある場合や、他の実践者から 質問がある場合、あるいは他の実践者に質問 がある場合は、いつでも歓迎されます。 これがこの運動が始まった方法であり、今日 も続いている方法なのです。 https://www.youtube.com/watch?v=o7-IuYS0iSE
27. そう、続けることに関して言えば、 DevOpsDaysはどうなっているでしょうか。 最初の数回のイベントの後、シリーズ全体が 本当に勢いを増し、それ以来、世界中で続い ています。 これらはコミュニティが主催するもので、無 料か無料に近いものです。そして、勢いは衰 えず、本当に運動の中核となる対面のミー ティングになっています。そして、開催され るたびに、活力を与え、再活性化するのに役 立っています。 https://www.youtube.com/watch?v=o7-IuYS0iSE
28. この分野で世界最高の人々と交流したいなら、 ぜひDevOpsDaysに参加してください。実際、 イタリアでもうすぐ開催されますし、その次 はオーストラリアです。そして、世界中を 巡っていくのです。 ぜひDevOpsDaysに参加してください。そし て、DevOpsDaysや他のDevOps関連のイベ ントで、このPatrick Duboisに会ったら、ハ イタッチをして、ビールを奢って、ありがと うと伝えてください。 https://www.youtube.com/watch?v=o7-IuYS0iSE
29. でも、実際のDevOpsDaysイベントを待つ必 要はありません。一年中、24時間365日、 DevOpsの会話はオンラインで続いています。 だから、どんどん参加して、自分が学んだこ とを他の人と共有してください。 というわけで、私が見てきたDevOpsの歴史 はこんな感じです。時間の都合上、様々な 人々や異なるイベントが省略されています。 誰かを怒らせてしまったらごめんなさい。私 は、正確な貢献よりも全体的なコンセプトを 伝えようとしました。 https://www.youtube.com/watch?v=o7-IuYS0iSE
30. Agile 2008 での出会い。 2009年のFlickrの発表。 ベルギーで第一回の カンファレンスを行い、 その後 #DevOps が ハッシュタグとして生まれる。 そして、活動が自然と 広がっていき、 各地でイベントが行われる。 実践者の集まり。 DevOps→Days
31. 「DevOpsってなんなのか わからない」と聞かれます。 そもそもDevOpsとは なんなのでしょうか？ 運用。運用が利益を生んで いることを明らかにすること 全体のエコシステム。 開発チームだけではない。 DevOpsって
32. 開発チームが運用することも できる時代 = クラウド 組織運営が必要だとして、 アジャイル拡張手法や ツリー型統制で うまくいくのか？ Flickrのスライドを 再訪しよう 開発と運用
33. DevOps の源流 : Flickr 10+ Deploys per Day のトーク (2009年) を再訪する https://www.youtube.com/watch?v=LdOe18KhtT4
34. John Allspaw 00:11 皆さん、聞こえていますか？はい。私の名前 はジョン・アルスポー、Flickrのオペレー ショングループを担当しています。 Paul Hammond 00:22 フリッカー社でエンジニアリンググループを 担当しているポール・ハモンドと申します。 John Allspaw 00:29 今日の話は、実際には様々なトピックを扱う 予定ですが、開発と運用がどのようにフィッ トして仲良くなり、実際に協力して、お互い に大馬鹿者ではないことを説明するための手 段とでも言いましょうか。
35. Paul Hammond 00:51 しかし、始める前に、Flickrとは何かにつ いて少し話しておきましょう。フリッカー について聞いたことがある人は手を挙げて ください。さて、フリッカーを知らない人 のために説明しますと、 Flickrは写真共有 サイトです。現在、約30億枚の写真を保 存しています。そして、1日の任意の時点 で、1秒間に約40,000枚の写真を提供し ています。これらの写真は、約6ペタバイ トのストレージを占めています。子猫がた くさんいるように見えるかもしれませんが、 実はとても大きいのです。
36. Paul Hammond 03:24 多くの人が考えるのは、開発 者(Dev)の仕事はサイトに新 しい機能を追加すること。そ して運用者(Ops)の仕事は、 サイトの安定性と高速性を維 持することです。
37. John Allspaw 03:44 私はそうは思いません。運用チー ムの仕事は、サイトを安全で高速 に保つことではありません。それ は彼らの仕事ではありません。 これは一部の人にとっては驚くべ きニュースかもしれませんが、運 用チームの仕事はビジネスを可能 にすることです。
38. Paul Hammond 04:34 ビジネス要件に関して言えば、ビジネ ス、特にオンラインビジネスで働く上 での最も重要な現実の1つは、ビジネ スが変化を必要としているということ です。もしあなたのビジネスが止まっ ているなら、TwitterやFacebookの ような生意気な新興企業に乗っ取られ てしまうでしょう。
39. Paul Hammond 04:34 もちろん、問題は変化です。ほとんどの 障害の根本原因を見て一般化すると、変 化がほとんどの障害の根本原因であると いう結論に達します。ほとんどの障害は、 数日前、数時間前、数週間前に変更がな ければ起こらなかったでしょう。
40. John Allspaw 05:09 つまり、2つの選択肢があります。 安定性を重視して変化を阻止するか。 それとも、賢くなって、 必要に応じて変化を起こせるような ツールや文化を構築するか です。
41. Paul Hammond 05:29 ですから、今日話すことのほとんどは、 適切なツールの使用と、チーム内の良好 な作業文化を通じて、変更のリスクを下 げることについてです。 これらの多くのツールで私たちが試みて いることは、どんな変更でもサイトの障 害や問題を引き起こさないという自信を 高めることです。そして、障害が発生し た場合に、それらから回復する能力を高 める方法も見ていきます。
42. 適切なツールの使用と、 チーム内の良好な作業文化 を通じて、 変更のリスクを下げる サイトの障害や問題を 引き起こさないという 自信を高める 障害が発生した場合に、 回復する能力を高める Flickr ツール＋文化
43. 少し時間をいただいて、 私がやってきたことを 話します。 開発と運用、 という２つの面への かかわりについて。 DevOpsに出会った時に どう感じたかの背景として。 わたしの話
44. 97年から新卒で(株)QUICK に勤務しました。 情報メンテナンスをする部門 で3.5年。日々の市場データ の管理をやったり、当番制で バッチ開始指示したり。 PC配ったり効率化したり。 データが日々、利益を上げて いるので重要な仕事でした。 情報の運用
45. 2000年くらいに異動で、 アプリを開発する部門に。 株価がパカパカするアプリを JavaScriptとCSSで 作りました。 通信はActiveXコントロール、 グラフは他社さん製で、 JVMで作られてました。 アプリ開発
46. 部署で新規サービスを 出すことになり、 企画に入って金融工学の 話をしながら、PDFを Webデザインから 動的に生成する仕組み を作ってました。 ライブラリを見つけてきて はめただけですけど。 「動くパンフレット」の 基盤ができました。 サービス開発
47. サーバ運用やる人が いないということでそちらも。 最初1ラック8台くらいだった んですけど、8ラックくらいに なりました。 客先にもエッジサーバを置く 仕組みだったのでその辺も 設計から面倒みました。 中身がなるべくシンプルで 安定して動くものを。 サービス運用
48. という感じで、 開発と運用を両方とも やってきました。 運用といっても ほぼ自分が 関わって基本設計から 作ったものの運用でした 情報の運用 アプリ開発 サービス開発 サービス運用
49. 運用の世界で、 障害(Incident)というのは 何らかの原因で サービスが中断した 状態になること。 障害中は復旧最優先で、 対応に追われるし、 信頼も低下して、 結果的に収益も下がる。 障害を避ける
50. 障害 = 想定外の状況 コントロールを失っている 状態なので、いち早く 本線に戻して、 通常の業務を進められる 状態にしたい。 これが「対処」。 本格的な「対応」は そのあと考えていく。
51. 対処中にしてはいけないこと • 後悔、周りに言う • 根本原因を推測する • 正解あてっこゲーム • ドヤ顔、キレる • 作業者の集中を乱す • 犯人捜し • 障害の影響の話 • 今後の対応の話
52. 対処中にすべきこと • 全員でゴールをはっきりさせる • 口と手を同時に動かす • 最も重要なことに集中する • できることを一つずつ終わらせる • ダメだとわかるのも完了 • なるべく短い時間で進捗を出す • 勝手にヒーローになろうとする人を避ける • 長期の話や改善案は、 あらかじめ時間を決めて行う • ちゃんと休憩する
53. なので、できれば状況を 予測可能な範囲に置きたい。 確率的事象に関しては、 確率分布を知りたい。 統計的には大数の法則と、 独立性が重要。 ヒストリカル = 繰り返す。 条件を同じにして、何度も 行えば、いずれ安定する。 とても不安
54. サイコロの確率 サイコロを１つ振ると、 1～6のどれが出るかは、 均等な確率になる。 しかし、２つ振ると、 最も中央の数値が確率が 高くなる釣鐘型の カーブとなる。 (ただし独立していること)
55. サイコロの確率
56. 二重化すると同時に落ちない 限りはサービスが継続できる。 じゃあ、3重化、4重化すれば もっと安定する？ しかし、故障確率も上昇する。 毎日のように壊れた機材を 直し続けることになる。 機材の複雑性も増加。 はっきり壊れてくれない のも大変困る(ゾンビは最悪)。 多重化の功罪
57. どちらが よい？
58. 実際のところ、クラスタリング(二重化)は 相互監視のイベントの連続で、 タイムアウトの閾値に依存する。 ぜんぜんシンプルな仕組みではない。
59. 負荷分散と耐障害のために 多重化するのだけど、 シンプルにしておくと、 最小限のセットは小さくなる。 その分だけを、 ステージングのVM上に展開、 １セットでテスト可能にする。 これをゴールドディスク、 と呼んでました。 ゴールド ディスク
61. ここをゴールドディスクにする
62. 本番環境に複数台あるサーバ にゴールドディスクから なるべく差異なく展開したい ので、展開は自動化。 OSインストールして、 最小限のソフトウェアを インストールした後は、 自動展開されるように。 展開の自動化
63. ゴールドディスク 本番環境 デプロイ デプロイ デプロイ
64. 構成をシンプルにして、 障害を検知しやすくしても、 結局、直すのは人間。 中身をわかっているチームを 作らないと対処も対応も できない。 障害への対処と対応をできる チームを作る必要がある。 復旧は人間
65. 構成を理解し、 手順を作ったり、 繰り返し見直したり。 その中で自動化すべき ところを自動化したり。 自分でわかってないと 対処が難しい。
66. 自分を主人公にした 時初めて、自分と物 語空間の（リアルさ を持った）一体化さ れたイメージを立体 的に描くことが可能 となる。 中埜博 Hiroshi Nakano “ ” 16:00-
67. 少し時間をいただいて、 私がやってきたことを 話しました。 開発と運用、 という２つの面への かかわりについて。 ツールと文化は たぶん両方必要なんです。 わたしの話 開発と運用
68. バージョン管理を使う。 開発チームを超えて バージョン管理を共有。 ワンクリックで デプロイまで行う。 運用者は自分の作業範囲を 安全なものにするのではなく、 開発者に自由と責任を 果たす機会を提供する。 Flickrのツール (前半)
69. Paul Hammond 07:42 そこで今回は、ツールについて少しお話 ししましょう。そして、このツールの議 論でやりたいことは、これらは私たちに 有効なツールの一部です。必ずしもすべ ての人に使えるわけではありません。全 体を通して、私たちが使っている具体的 なツールの例を挙げていきたいと思いま す。しかし、私たちが伝えようとしてい る重要なことは、このカンファレンスの 共通テーマになるでしょう。
70. Paul Hammond 07:42 自動化されたインフラとは、そのよ うな技術であり、オペレーションの 仕事を可能にするものです。1,000 台以上のサーバーがある場合、個々 のサーバーを手動で管理することは 現実的ではありません。開発者の視 点から見ると、アプリを構築するた めの一貫した予測可能なプラット フォームを提供します。
71. Paul Hammond 09:35 私たちにはあらゆる種類のツールがあります が、このトークはそれについてではありませ ん。アダムとエズラがもう少し後でそれにつ いてのトークをする予定で、このトピックに ついてはもっと優れたプレゼンテーションが 半ダースほどあります。しかし、ここでの主 なポイントは、OSイメージを持っているとい うアイデアがあるということです。そして、 このサーバー、このインフラストラクチャー のピース、またはクラウドのビットが実際に 実行する何らかの役割があります。それはタ スク駆動型のインフラストラクチャーです。
72. Paul Hammond 09:35 このサーバーとクラウドの違いは、 このサーバーの周りに青い雲がある かどうかです。それだけで、考え方 は同じです。 例えばEC2でサーバーを運用してい て、OSのイメージング側はamiが 担当していても、その上にロールと 構成管理のレイヤーが必要になると いうことですね。
73. Paul Hammond 09:50 次に紹介するツールは、バージョン管理です。 開発チームの中には、バージョン管理なしで運 用しようとする人はあまりいないでしょう。そ して、ますます多くの運用チームが使うように なっています。 バージョン管理を使うことは、 実際、かつて私たちがやっていたことでもあり ます。かつては、 FlickrのソースコードはCVS に格納されていましたが、運用やパッケージ、 構成管理のすべてはPerforceに格納されていま した。そのため、開発者は何が起こっているの かわからず、Perforceのリポジトリをどうやっ てチェックすればいいのかわからず、ジョンは CVSのリポジトリをどうやってチェックすれば いいのかわからなかったのです。
74. Paul Hammond 09:50 1つの共有リビジョン管理システムがあれば、 チームの誰もが、どこを見れば特定のボックス用 の設定の最新インスタンスを見つけられるのかを 知ることができ、また、アプリケーションで何が 起こっているのか、どこに変更があるのかを知る ことができます。これは、緊急時には本当に便利 です。先週の金曜日、私は外で食事をしていると きに、サイトの一部に問題が発生していることが わかりました。ジョンのチームで働いているケビ ンが私に電話をかけてきたのです。もしソース コードのリポジトリが違っていたら、ケビンがア クセスできなかったかもしれないし、私が家に 帰ってラップトップを取り出し、自分で修正しな ければならなかったでしょう。このように、シン グルソースコントロールは透明性を提供してくれ るので、非常に便利です。
75. Paul Hammond 09:50 開発の観点からは、ワンステップビルド を設定することが最も重要です。ワンス テップビルドとは、現在svnのソースコ ントロールシステムに登録されている コードを、本番サーバーにコピーしてサ イトを実行できるようなファイルセット にするために必要なすべてのことを意味 します。
76. Paul Hammond 09:50 今お見せしているスクリーンショットは、Flickr内部の 開発管理インターフェースの一部です。画面の一番下に ある「ステージングを行う」と書かれたボタンをクリッ クすると、svnチェックアウトが行われ、すべての翻訳、 すべてのテンプレートのコンパイル、最適化のためのコ ンパイルなどが行われます。そして、そのコードをス テージング・サーバーにコピーして、テストできるよう にします。 John Allspaw 12:07 自動的に自動的に、つまり、人がこのコマンドを実行し ていないのに、このコマンドを実行するのです。結論か ら言うと、コンピュータはコマンドを同時に実行するの がとても得意で、何度も同じ順番で実行されます。
77. Paul Hammond 12:20 ワンステップビルドができたら、 次に必要なのは ワンステップデプロイです。
78. Paul Hammond 12:20 これはFlickerの内部管理ツールで、 上部にはデプロイログがあります。 これは非常に安価な変更管理の形態 で、誰もが何が起こっているのかを 見ることができ、システムの他の部 分で何か変更が行われているため、 今はデプロイするのに最適な時期で はないかもしれないと警告すること ができます。
79. Paul Hammond 12:20 そして、下部には「I'm feeling lucky」というボタンがあり、これを押 すとコードがサイトにプッシュされま す。これは、コードをサイトにプッ シュしているときの様子です。ここで も同じ原則が当てはまります。ボタン を1つにすることで、エラーの余地が非 常に少なくなります。つまり、一貫し た環境でビルドとデプロイを行うこと ができ、間違える可能性のある手動の 手順がないことを意味します。
80. Paul Hammond 12:20 そのため、ソースコードの差分を見 ていれば、それがデプロイ時のアプ リケーションの動作に見られる唯一 の違いであることをかなり確信する ことができます。
81. John Allspaw 13:35 継続的デプロイメントをトレンドとして 見ています。そして、継続的インテグ レーションは、多くの運用ツールやベン ダーが販売しているものだけでなく、 オープンソースプロジェクトにも登場し 始めています。それは良いアイデアなの です。このプロセスの最大の利点の1つ は、デプロイログを持っていることです。 これを一瞬でも見逃さないでください。 私たちは誰が、いつ、何をしたのかを 知っています。これは本当に重要です。
82. John Allspaw 13:35 ジョン・アダムスは先ほど、モニタリン グとメトリクスツールの一番上にデプロ イのタイムスタンプを置いていると言い ました。コンテキストは絶対的に重要で す。このトークのタイトルは「1日10回 以上のデプロイ」ですが、1日に10回ダ ウンしてしまうのなら、1日に10回デプ ロイしようとしたり、そのふりをしたり することはできません。それはアジャイ ルではなく、単に遅れているだけです。
83. バージョン管理を使う。 開発チームを超えて バージョン管理を共有。 ワンクリックで デプロイまで行う。 運用者は自分の作業範囲を 安全なものにするのではなく、 開発者に自由と責任を 果たす機会を提供する。 Flickrのツール (前半)
84. ここからは、 カンファレンスの話を していきます。 私の話であり、 DevOpsの話であり、 たぶん皆さんの 話でもあるかなと カンファレンス
85. 2007年にVMWorldという カンファレンスに参加した。 キーノートで ESXiが発表。 サーバ本体にUSBメモリで 供給される仮想OSになった。 これで時間のかかる OSインストールが不要に。 VMWorld
86. OS ESXi OS OS
87. ESXi によって ハードウェアと ソフトウェアが キレイに分離し、 単機能のOS/アプリが 実現可能になった。 その後の コンテナ技術や クラウド技術の基本形と 一致する。 ESXi とコンテナ化
88. VMWareを実際に作っている 人が来て話している。 これからどうしようとして いるのか、どんな意見に 対応するのか。 見えている技術トレンドや 他社との協業関係。戦略の 話からチュートリアルまで。 商業カンファレンスだけど、 コミュニティ作りだった。 海外 カンファレンス
89. 有名な人に話をしてもらおう。 そうすれば、聴衆が集まる。 人が多いイベントには価値がある。 マーケティングしよう。 その技術に関する人が集まる なら、スポンサーも集まる。
90. やってる人に話をしてもらおう。 そうすれば、やってる人や やろうとしている人が集まる。 学びや勇気をもらえるイベントに は価値がある。 継続的に開催しよう。 その技術に関する人が集まる なら、スポンサーも支援してくれ るかも。
91. 最初に栃木の関将俊さんの 講演を聞いた。 新しいことを社内で始めるには 「信頼貯金」が必要だと。 これまでの人間関係や 社内での活動の実績の集積。 「アイツになら、しばらく 任せてみようか」 と納得してもらえるかどうか。 デブサミ
92. ハイキュー!! 10巻 （C）古舘春一／集英社
93. ハイキュー!! 10巻 （C）古舘春一／集英社 “その瞬間”が 有るか、無いかだ
94. https://haikyu.jp/movie/ （C）©2024「ハイキュー 」製作委員会 ©古舘春一／集英社 続きは 劇場で！
95. 関さんに聞いた「信頼貯金」。 入社10年の自分にも 結構あるかも。 機会があったら、思い切って 自分が考える通りに やらせてもらう ことが重要かもしれない。 (自分の労力を超える部分に ついて) 信頼貯金
96. 10か月後くらいに、 社内で相談が来た案件(ボール)を 「チームを作る」ことを 前提に拾った。 担当しているインフラ運用も チームにした。 あるべき方向に地道に話す。 タイミングよく話す。
97. カンファレンスって、 他校と集まる 合宿みたいなものだな。 なにが学べるのかを 事前に知ることは難しいし。 事前にわかっていることは、 たぶん、そんなに重要じゃない。 ハイキュー!! 10巻 （C）古舘春一／集英社
98. トランクベース開発と、 フィーチャフラグを組合わせ、 本番にデプロイする。 本番環境で、 プライベートベータや、 バケットテストや ダークローンチが可能になる。 メトリクスを共有する。 コマンドとログを合わせて テキストチャットに流す。 コンテキストがわかるように。 Flickrのツール (後半)
99. Paul Hammond 14:45 次に話すのは、これも開発者に焦点を 当てたものですが、私たちがフィー チャーフラグと呼んでいるものです。 これは、コード内でのブランチング (分岐)とも考えることができます。
100. Paul Hammond 14:45 リビジョン管理のブランチングシステムについて 考えると、それはデスクトップソフトウェアを構 築する現実への対応です。あなたはマイクロソフ トで、Microsoft Wordを開発し、Microsoft Word 1.0をリリースしました。そして、開発 チームはすぐにMicrosoft Word 1.1の開発に取 りかかります。そして、1.1をリリースします。 そして数日後、重大なセキュリティの脆弱性があ ることに気づきます。そこで、1.0のコードベー スに戻って変更を加え、それを出荷しなければな りません。そして、1.2をリリースします。そし て、もう一度変更を加えなければなりません。つ まり、3つの異なるバージョンのソフトウェアを 同時にリリースしているのです。
101. Paul Hammond 14:45 私たちのように、ウェブアプリケーショ ンのインスタンスが1つしかない場合、そ のようなことはありません。私たちが 持っているのは、現在デプロイされてい るものだけで、古いバージョンはもはや 重要ではありません。
102. Paul Hammond 14:45 私たちがそれに対処する方法は、 常にトランクを出荷することです。 これは、すべての開発をトランク で行うということではありません が、私たちはそうしています。ブ ランチで開発を行い、それらのブ ランチをマージすることもできま す。 ※現在主流の GitHubでは 2020年にtrunk は main に 変更されました。
103. Paul Hammond 14:45 しかし、常にトランクを出荷することで、 チームの全員が、現在サイトにデプロイ されているコードのバージョンを正確に 把握することができます。つまり、現在 リリースされているのがどのパッチリ リースのどのブランチなのかを考える必 要がなく、SVNに行けば、そこにトラン クがあるのです。 ※現在主流の GitHubでは 2020年にtrunk は main に 変更されました。
104. Paul Hammond 14:45 SVNではブランチングを行わないと言い ましたが、その代わりにコードでブランチ ングを行います。つまり、すぐにリリース しない機能を開発する際は、条件文を使っ てそれらの特定のコードパスをブロックす るのです。 ここにPHPの例があります。smartyの例 です。実際にはまだリリースされていない すべての新機能のコードを、本番サーバー の本番環境に置くことができるのです。た だ、設定が行われているので、まだ実際に は見えないだけなのです。
105. Paul Hammond 18:11 これにより、いくつかの本当に素晴らしいトリックが できるようになります。1つ目は、本番サーバー、本 番ハードウェア、本番トラフィックでプライベート ベータを行えるということです。もちろん、私たちに は非常にリアルなテストができる素晴らしいステージ ング環境があります。そして、それらの環境で多くの QAを行っています。しかし、私たちが発見したことは、 テストに別のサーバーセットを使用すると、ベータ サーバーと本番サーバーの間の設定の変更に気づかな い可能性があるということです。構成管理を使用して いても、それは起こります。過去には、新しい機能が ベータサーバーで完璧に動作していたのに、本番環境 に移行した途端、依存していたバックエンドの内部 Webサービスが本番のWWWからブロックされている ことに気づいたケースがありました。そのため、その 機能は動作せず、そのバックエンドWebサービスに緊 急の変更要求を出さなければなりませんでした。
106. Paul Hammond 18:11 これにより、バケットテストを行うことができま す。これは非常に便利で、新しいコードパスがあ れば、使用を検討している新しいバックエンドシ ステムがあれば、トラフィックの5%をそこに プッシュし始め、それを10、20、30、50%と 増やすことができます。ユーザーのサブセットに 対して機能をオンにすることができます。そして、 異なるバージョンのソフトウェアを異なるサー バーで実行し、ボックスを本番環境に出し入れす るために細心の注意を払う必要はありません。す べてをコードで行うことができるのです。
107. Paul Hammond 18:11 最後に、Jonathan がさきほど Facebook について話したときに言及した、ダーク ローンチ（水面下でのローンチ）ができま す。新しい機能を舞台裏でローンチするの です。memcached ボックス、データベー スサーバー、検索クラスターに負荷がかか る新しい機能がある場合、その機能を舞台 裏でオンにして、数週間データを取得し始 めますが、そのデータは表示しません。そ して、実際にこの新しい機能をローンチす る頃には、数週間負荷をかけていたので、 負荷に耐えられることがわかっているので す。
108. John Allspaw 21:12 私たちは数百のフラグを持っているので、物事をオ フにしたり、サイトの可用性やパフォーマンスに影 響を与えている物事の動作を変更したりできます。 データベースクラスターに何らかの劣化があったり、 他のバックエンドサービスに何らかの劣化があり、 それが特定の機能に関連している場合、私たちはこ れを変更できます。そして、サイトに影響を与える ことなく、ロールバックするのでしょうか。実際に はそれほど頻繁ではありません。私たちがするのは、 前に進んで、それをオフにすることです。 これらのフィーチャーフラグの中には、オンとオフ だけでなく、ポールが言ったように、可変量を持つ ノブのようなものもあります。
109. John Allspaw 21:12 バージョン管理と同じように、共有メトリ クスも重要です。共有バージョン管理を持 つのと同じように、私はあなたのビットを 見ることができ、あなたは私のビットを見 ることができます。私たちはメトリクスを 収集しています。大量のメトリクスを収集 しています。
110. John Allspaw 21:12 これは私たちのGangliaのスク リーンショットです。私たちは 約37の異なるクラスターを持っ ており、1秒間に何万ものメトリ クスを取得しています。ここで 重要な点は、開発者はこれがど こにあるかを知っているだけで なく、アクセス権を持ち、運用 と同じくらい執着心を持って見 ていることです。
111. Paul Hammond 24:10 これは、私たちの非同期タスクキューにあるバック グラウンドタスクの数を示すグラフです。興味深い ことの1つは、実際に私がこのグラフに表示されて いるメトリクスを作成したことです。 そして、私がこのグラフを作成した理由の1つは、 ジョンのチームに頼まれたからではなく、私たちの オフラインタスクシステムがどのように機能してい るかを知りたかったからです。ここで興味深いのは、 開発者がこれらの伝統的に運用上のメトリクスを作 成したいと考えているという状況があることです。 そして、ジョンのチームは、私たちがそれを簡単に 作成できるようにしてくれます。私たちは今、アプ リケーションのどの部分でもキーと値のペアを含む ファイルを書き込むだけで、Gangliaの設定がそれ を取り込み、私たちのために美しいグラフを作成し てくれるフレームワークを持っています。
112. Paul Hammond 24:10 これは、アプリケーションの中に適応型フィード バックループを作成することにつながります。非 同期に発生している事柄がある場合、システムが うまく機能していないときに、アプリケーション がバックオフしてシステムへの負荷を軽減しよう とすることができます。先ほど述べたオフライン タスクセントリズムは、データベースが過負荷に なり始めると実際に調整されて、データベースが リアルタイムの負荷に対処できるようにします。 オフラインタスクを10分後に実行する必要が あっても、それは大した問題ではありません。 そして、Yahoo PhotosからFlickrへの移行を 行った際には、ストレージの空き容量に基づいて スロットリングを行い、ストレージが不足しない ようにしました。
113. John Allspaw 27:24 実際に、私たちが持っている全てのメトリクス の全てのページに、最後のサイトデプロイの時 間を記載しています。 Paul Hammond 27:35 そして、これによって、特定のグラフが2倍に なったり半分になったりした理由を簡単に特定 できることがよくあります。これは、私のチー ムの1人が画像処理コードの最適化をロールア ウトした例です。私たちはそれがどのような効 果をもたらすかわかりませんでしたが、少しの 効果があるかもしれないと考えていました。し かし、結果はかなり大きなものでした。
114. John Allspaw 27:58 コミュニケーションは、ここでのツールの話の 終わりに近づいています。私たちは、他の多く の場所と同じように、Flickrでは多くのIRCを 使用しています。そして、開発者と運用担当者 の間の継続的な対話、サイトで何が起こってい るのか、何に取り組んでいるのかに使用してい ます。多くのボールを空中に持っている多くの 人がいて、IRCは特にリモートで働く人に役立 ちます。この会話が行われています。そしてコ ンテキストを持つことは良いことです。 ※IRC(Internet Relay Chat)は、 1990～2010年くらいまで 主流だったオンライン チャットプロトコル。
115. John Allspaw 27:58 コンピューター駆動のイベントをIRCのストリー ムに送り込みます。例えば、私たちが本当に気に している特定のアラートとモニター、ビルドログ、 何かがデプロイされたときのデプロイログなどで す。(中略) そこで私たちが実際に行っていることは、このロ グ情報のすべてを取得して、検索エンジンに突っ 込むことです。そうすれば、「2ヶ月前の木曜日に 一体何をしたのか、何が起こっていたのか、この 問題を以前に見たことがあるか」などと言うこと ができます。 これは本当に役立ちます。なぜなら、人間がコン テキストを持つことができるからです。 ※IRC(Internet Relay Chat)は、 1990～2010年くらいまで 主流だったオンライン チャットプロトコル。
116. トランクベース開発と、 フィーチャフラグを組合わせ、 本番にデプロイする。 本番環境で、 プライベートベータや、 バケットテストや ダークローンチが可能になる。 メトリクスを共有する。 コマンドとログを合わせて テキストチャットに流す。 コンテキストがわかるように。 Flickrのツール (後半)
117. 2017年にMS訪問。 牛尾さんからのお誘い。 その場で会場に連絡して、 Eventbrite作って、 3ヶ月でリリースした。 ただし翌年もやること。 目標は「コミュニティを 作ること」とした。 DevOpsDays Tokyo リブート
118. 東京でのDevOpsDays は 2012年、2013年に行われたが、 その後は続いていなかった。 (理由は知りません。) https://legacy.devopsdays.org/events/2012-tokyo https://legacy.devopsdays.org/events/2013-tokyo
119. 企業の会場を借りてカンファレンスを やるのは、社員さんに多大な負担が かかることをRSGTで学んだ。 楽天テクノロジーカンファレンスでも DevOpsのセッションをやったが、 「DevOpsDays」として企業が 会場ホストして無料でやり続けるのは ちょっと続かないと感じた。
120. 海外カンファレンスだと、 USD1000～2000くらいの参加費。 大崎ブライトコアホールは 品川区の持ち物なので、 リーズナブルに貸してくれる。 この会場代や、招待スピーカーの渡航 費を考えれば、全く無料ではなく、 USD100～200くらいの負担を 参加者に求めるのは継続性がある と思う。 スタッフはボランティア。 https://osaki-hall.jp/
121. https://kawaguti.hateblo.jp/entry/2018/12/27/164751 カンファレンス運営の キャッシュフローの 特性についてまとめました。
122. 2020年4月はコロナ 緊急事態宣言が出た時期で、 飲み会も、海外からの入国も 出来なくなり、開催断念。 2021年はハイブリッド開催。 一人も来なくても 会場は開けて待つことに。 低コストで配信できる 仕組みを作った。 ハイブリッド 開催へ
123. 海外カンファレンスだと、 USD1000～2000くらいの参加費。 大崎ブライトコアホールは 品川区の持ち物なので、 リーズナブルに貸してくれる。 この会場代や、招待スピーカーの渡航 費を考えれば、全く無料ではなく、 USD100～200くらいの負担を 参加者に求めるのは継続性がある と思う。 スタッフはボランティア。 https://osaki-hall.jp/
124. DevOpsDays を 東京でやることになり、 国内外から実践者の スピーカーを集めて 話をしてもらうことに。 高くない会場を借りて、 チケット設定して、 スポンサーをお願いしただけ ですけど、場の基盤が 出来ました。 サービス開発
125. スピーカーが会場に 来ても来なくても登壇できる ように、配信の仕組みを 考えました。 専用の人員を配置しなくても、 継続的に配信できるように、 iPad を使って、Zoomで 繋がる仕組みを作りました。 配信はボランティアスタッフ。 サービス運用
126. という感じで、 開発と運用を両方とも やってきました。 運用といっても ほぼ自分が 関わって基本設計から 作ったものの運用でした サービス開発 サービス運用 サービス開発 サービス運用
127. 2017年にMS訪問。 牛尾さんからのお誘い。 その場で会場に連絡して、 Eventbrite作って、 3ヶ月でリリースした。 ただし翌年もやること。 目標は「コミュニティを 作ること」とした。 実践者の コミュニティ
128. 相手が異なるスキルを持つ ことを尊敬する。 相手を信頼して、 ノブとレバーを渡す。 障害は常に起こる。 そのための訓練を怠らない。 相手のせいにしない。 常に相手がカバーして くれていることを想像し、 問題を起こさない方法を 考える。ちゃんと謝る。 Flickrの文化
129. Paul Hammond 29:28 これらのツールを全てインストールして も、非常に議論好きで好戦的な文化が続 いていれば、あまり役に立たないという ことです。 そして、Flickrで私たちの仕事をとても やりやすくしていると思うもう一つのこ とは、私たちが持っている文化です。自 動化されたインフラストラクチャーのよ うに、それは、申し訳ありませんが、 ツールに関して行う必要がある非常に基 本的なことのようなものです。
130. Paul Hammond 29:28 文化に関しては、最も重要 なこと、始めるべきことは、 尊重の文化を持つことです。
131. Paul Hammond 29:28 私たちがこれを言うのは少し偽善的ですが、 できる最も重要なことの一つは、ステレオ タイプを避けることです。 5年前に、あなたのアプリケーションやシ ステムの稼働時間を気にしないカウボーイ と一緒に働いたことがあるのは知っていま す。しかし、あなたが一緒に働くことにな る開発者全員が彼のようなウイルスではあ りませんし、運用担当者全員が彼のように 妨害的ではありません。
132. Paul Hammond 29:28 もし皆に最悪のことを想定するなら、皆も あなたに最悪のことを想定するでしょう。 誰もが繊細な小さな雪の結晶で、誰もが少 しだけ...それぞれの人の専門知識と意見を 尊重することが大切です。 なぜなら、彼らには異なる経験があり、あ なたとは異なる問題解決の方法を思いつく からです。それらの解決策が最善とは限り ませんが、少なくとも彼らの提案を尊重す べきです。
133. John Allspaw 34:05 運用担当者は、機能の議論に自分 たちを巻き込んでくれる開発者を 信頼する必要があります。
134. John Allspaw 34:05 つまり、あなたたちは「新しい素晴らし い機能が必要だ」と自分たちの間で話し 合っているわけです。そして、「ねえ、 運用担当者に話した方がいいかな、たぶ ん運用担当者にこのことを伝えるべきか な」と自問してみてください。 私が言っているのは、キャパシティプラ ンニングのような早期に行われるべき通 常の運用作業のことではありません。そ れは当然のことです。私が言っているの は、サイトに起こる変更のことです。
135. Paul Hammond 35:25 そして、開発チームは、運用担当者が事前にイ ンフラストラクチャーの変更について彼らと話 し合ってくれることを信頼する必要があります。 PHPがPHP 5にアップグレードされたことを、 それが起こった翌日に知ることはないでしょう。 繰り返しになりますが、これは本当に明らかに すべきことのように思えます。しかし、私は過 去に本当に機能不全なチームで働いたことがあ り、そこではこれが必要不可欠なものとして受 け入れられていませんでした。そして、それは、 組織全体のために皆が最善を尽くそうとしてい ることを、全員が信頼することに戻ってきます。
136. Paul Hammond 35:25 この会話が確実に行われるようにするために私 たちが実践していることは、可能な限り、共有 ランブックと共有エスカレーション計画を作成 するよう努めることです。 つまり、ジョンと私、あるいは私たちのチーム のメンバーが一緒に座って、新しい機能がオペ レーション上どのようにサポートされるかを正 確に把握します。どのようなシナリオで問題が 発生する可能性があるのか？ それらを修正す るために誰が関与する必要があるのか？ そし て、それは単に、リスクは何か、不測の事態は 何かについての会話を強制し、全員が同意して いることを確認するのです。
137. John Allspaw 36:57 開発者が監視し、注視するためのノブとレバー、つ まり、開発者が苦労して作ったコードを監視するた めのノブとレバーを提供することについて、私たち は言い過ぎることはできません。そして、開発者は フックとノブとレバーを書いて、これらのものを運 用可能にします。 Paul Hammond 37:20 コードを塀の向こうに投げ込むだけでは不十分で、運 用担当者が変更できないように、全ての変数に関する 全ての前提条件をプリコンパイルしておく必要があり ます。20個の子プロセスを持つことが良い数だと思う なら、運用担当者が設定できるようにする必要があり ます。そうすれば、下層のハードウェアをアップグ レードした場合に、運用担当者は自分たちでそれを実 行できます。
138. Paul Hammond 38:53 さて、私たちが話したい文化の 3つ目の側面は、障害に対する 健全な態度だと考えているもの です。
139. Paul Hammond 38:53 ここで認識すべき重要なことは、障 害は起こるものだということです。 それは、起こるかどうかの問題では なく、いつ起こるかの問題です。
140. Paul Hammond 38:53 そして、障害を防ぐためにどうすればい いかを考えるのにずっと時間を費やして いるなら、障害が起きた時にどう対応す るかを考える時間が全然ないことになり ます。 例えば、航空会社、つまり航空機のパイ ロットは、何時間も、毎月何日もシミュ レーターで過ごし、エンジンを失ったら どうなるか、ハドソン川に不時着したら どうなるかを計画しています。
141. Paul Hammond 40:13 しかし、それでも、何かが上手くいかない 時のために手順を作成し、避難計画などを 立てています。 一つの考え方は、もしサイトの停止に直面 しているなら、つまり、何らかの医療上の 問題を抱えているなら、年に一度心臓発作 に対処するEMT（救急隊員）に治療しても らいたいですか？それとも、数週間ごとに 心臓発作に対処するEMTに対処してもらい たいですか？あなたの運用チームと開発 チームの両方で育成する必要があるものの 一つは、問題に迅速かつ効果的に対応する 能力です。
142. John Allspaw 41:46 非難しないことは、 本当に基本的なことの ように聞こえます。
143. John Allspaw 41:46 私たちには「だれかのせいにし ない(No fingerpointing)」と いうルールがありますが、実際 にはそれを強制しなければなら ないようなルールではありませ ん。なぜなら、私は非常に幸運 なことに、責任が生じるとすぐ にそれを引き受ける組織に関 わっているからです。
144. John Allspaw 41:46 はい、これは進化した世界での典型的な問 題です。問題が起こると、「ああ、なんて こった？どうしよう？変更するつもりだっ たのかも。私はわからない。人々に何が起 こっているのか知られたくない。ログを削 除しよう。何が起こっているんだ？」と いった感じで、狼狽します。そして、「こ れは私のコードが原因ではない。あなたの マシンが原因だ」と言います。そして、よ うやく原因を突き止めます。大量の時間の 無駄ですよね？縄張り意識が物事の修正を 妨げています。
145. John Allspaw 41:46 これは提案ですが、こんな風にすることが できます。原因を突き止めて、物事を修正 する。そして後で、もし罪悪感を感じたい なら、そうすればいい。これが一般的に起 こることです。これはFlickrで実際に起こ ることで、私のチームでもポールのチーム でも、むしろ、人々は自分たちのせいで壊 れたのだと証明しようと必死になります。 なぜなら、一日に10回も誰が原因かわから ないですからね。そうすれば、彼らは問題 を修正した人になれるのでしょう。
146. John Allspaw 43:28 そうですね。あなたが言ったことを再 度強調しますが、開発者の皆さん、 コードを書く時は、誰かが真夜中に起 きることを覚えておいてください。開 発者をオンコールにする組織もありま す。真夜中に何かが起こるかもしれな いと思っていて、自分はその場にいな いか、セントマーチンの感謝祭に行く 予定なら、他の人があなたのゴタゴタ を片付けることになります。
147. Paul Hammond 43:55 たとえ開発者がオンコールになってい ても、最初にページを受けるのは一般 的に運用チームです。そして、あなた が真夜中に何かを壊してしまい、翌朝 出社してみると、30分間の停止があな たのせいで、5人の人が呼び出されて 起こされたことがわかったとします。 そんな時は、ただ「ごめんなさい」と 言えば、みんな気分が良くなります。
148. Paul Hammond 44:25 そして、多くの開発チームが陥りがちなこ との一つは、運用担当者がいるという事実、 つまり運用担当者が真夜中に起こされて彼 らのためにこれらのことを修正するという 事実に頼っていることです。しかし、自分 に聞くべき質問の一つは、自分のミスを取 り繕ってくれる人がいなかったら、何を違 うようにするだろうか、ということです。 もし真夜中に起こされるのが自分だったら 変えるようなことがあるなら、たぶんそれ らのことを変えるべきでしょう。
149. John Allspaw 44:49 運用担当者は、物事がどのように進んでいるかに ついて、建設的なフィードバック、継続的な フィードバックを提供すべきです。これらの人々 は、あなたのビジネスを運営し、より多くのユー ザーを獲得し、世界を支配するためにコードを書 いているのです。だから、物事がどのように進ん でいるか知るべきです。文句を言わないでくださ い。彼らに何が起こっているのかを説明して、 「ほら、毎朝6時に実行されるこのcronジョブは、 そこまで大したことではないけど、でも...」と 言ってください。彼らに説明してください。あら ゆる種類のメトリクスがあります。あなたが見た いものも、彼らが見たいものも。情報を共有する だけです。
150. 相手が異なるスキルを持つ ことを尊敬する。 相手を信頼して、 ノブとレバーを渡す。 障害は常に起こる。 そのための訓練を怠らない。 相手のせいにしない。 常に相手がカバーして くれていることを想像し、 問題を起こさない方法を 考える。ちゃんと謝る。 Flickrの文化
151. お話しすること (再掲とまとめ) • DevOps はどこから来たか • 実践者のコミュニティ • 私のちょっとした実践 • 外の人との共鳴と連鎖反応
152. DevOpsの定義はない。 DevOpsDaysは 実践者のコミュニティ。 自分から情報を取りに行く。 フラットなコミュニティは 共鳴と連鎖反応を生む。 計画外の出会いが大事。 DevOps→Days
153. 関さんに聞いた「信頼貯金」。 入社10年の自分にも 結構あるかも。 機会があったら、思い切って 自分が考える通りに やらせてもらう ことが重要かもしれない。 (自分の労力を超える部分に ついて) 信頼貯金
154. 適切なツールの使用と、 チーム内の良好な作業文化 を通じて、 変更のリスクを下げる サイトの障害や問題を 引き起こさないという 自信を高める 障害が発生した場合に、 回復する能力を高める Flickr ツール＋文化
155. 相手が異なるスキルを持つ ことを尊敬する。 相手を信頼して、 ノブとレバーを渡す。 障害は常に起こる。 そのための訓練を怠らない。 相手のせいにしない。 常に相手がカバーして くれていることを想像し、 問題を起こさない方法を 考える。ちゃんと謝る。 Flickrの文化
156. 相手が異なるスキルを持つ ことを尊敬する。 相手を信頼して、 ノブとレバーを渡す。
157. 構成をシンプルにして、 障害を検知しやすくしても、 結局、直すのは人間。 中身をわかっているチームを 作らないと対処も対応も できない。 障害への対処と対応をできる チームを作る必要がある。 復旧は人間
158. この場所が 実践者のコミュニティで あり続けますことを。 予想外の 共鳴と連鎖反応を IMAXを超える 極上のシアターで ご体験ください。