# Reliability is a Question > [!info] Talk metadata > - **会議:** [[SRE NEXT 2026 参加録]] キーノート1（オープニングキーノート、Day 1・2026年7月10日、Track A、10:40-11:20） > - **登壇者:** David Blank-Edelman（『Seeking SRE: Conversations About Running Production Systems at Scale』編者、『Becoming SRE: First Steps Toward Reliability for You and Your Organization』著者、いずれもO'Reilly刊。SREcon共同創設者。オペレーションの分野で約40年の経験を持つ） > - **URL:** https://sre-next.dev/2026/schedule/#slot050 > - **出典:** [[Reliability is a Question - transcript|一次ソース（公式アブストラクト、登壇者略歴、逐語文字起こし）]]（スライドは未公開） > [!note] 日付に関する注記 > `event_date`・会場・時間は公式スケジュールページ（https://sre-next.dev/2026/schedule/#slot050 ）で確認済みの値である。 > 前回の執筆時点ではトランスクリプト内に開催日の明言がなく「Day 1 と推定」としていたが、公式スケジュールにより確定した。 > [!abstract] 概要（公式アブストラクトの日本語訳） > 組織が生業として何をしていようと、大きな環境であれ小さな環境であれ、その中間であれ、みなが共有しているものが一つある。 > 信頼性への渇望だ。 > > 我々はシステムに適切な水準の信頼性を求めることに多くの時間を使っている。 > あるいは、使うべきだと思っている。 > そして期待どおりにいかないとき、その理由を問おうとする。 > ときには答えのヒントを得ることもある。 > > 問題は、素朴な問いが必ずしも正しい答えに導くとは限らないことだ。 > 関係性は直観に反することがある。 > サイトリライアビリティエンジニアリング（SRE）の考え方で取り組んだとしても、いや、おそらくそう取り組むからこそ、障害から学ぶことは容易ではない。 > 本講演では、これらの問いと、それらがどれほど経験を積んだSREであっても道を誤らせうるかを語る。 > より良い問いによって正しい道へ戻し、いくつかの答えも用意する。 > 障害、コミュニケーション、組織構造、モニタリング、その他いくつかの意外なテーマをめぐる課題への具体的な取り組み方を持ち帰ってもらえるはずだ。 > 自分の出した答えに問いを立て、信頼性についての問いに答える機会に、ぜひ参加してほしい。 ## リルケの手紙から始まる講演 - 大きな環境でも小さな環境でも、組織が何を生業にしていても共有しているものが一つある、信頼性への渇望だ、と切り出した。 - ドイツの詩人リルケの手紙の一節を英語で読み上げた。「Live the questions now（今は問いを生きてほしい）」という趣旨の一節であり、本講演の狙いを、良い答えを与えることではなく良い問いの立て方を教えることだと位置づけた。 > 「あなたの心の中にあるまだ解決されていないすべてのものに耐え忍び、その問いそのものを、鍵のかかった部屋や見知らぬ外国語で書かれた書物であるかのように、愛してみてほしい。今は答えを探さないでほしい。今のあなたにはまだ生きることができないのだから、答えは与えられない。すべてを生きることに尽きる。今は問いを生きてほしい。そうすればおそらく、いつか遠い未来に、気づかぬうちに、少しずつ答えの中へ生き入っていくことになるだろう」（リルケの手紙、講演中に英語から読み上げられた一節の趣旨） - 「AI tax（講演でAIに触れることを求められる慣習）」を自認し、AIの話題は終盤まで持ち越すと予告した。 - 質疑はセッション内では受け付けず、終演後の「Ask the Speaker」枠に譲ると案内した。本トランスクリプトにその内容は含まれていない。 ## 「システムは信頼できるか」という問いを広げる - 多くの人は信頼性を可用性、つまりシステムが動いているか落ちているかだけで考えがちだが、それは信頼性が持つ期待の一つにすぎない、と述べた。 - 信頼性を構成する側面として、レイテンシ（応答の速さ）、スループット、カバレッジ（バッチ処理でデータを漏れなく処理できたか）、正しさ（コードが意図どおりに動き、それを計測できているか）、フィデリティ（顧客に想定どおりの体験を届けられているか）、鮮度、耐久性（書き込んだビットを後で読み出せるか）を列挙した。 - レイテンシの例として、自身がかつて勤めていたMicrosoftのXbox部門を挙げ、「slow is the new down（遅さは新手のダウンタイムだ）」という言い回しを紹介した。 - フィデリティの例としてNetflixのウェブページを挙げた。レコメンドエンジンが動かないとき、白い空白画面ではなく静的なコンテンツに差し替えることで、体験の一部を保つ設計を説明した。 - 100台のサーバーのうち14台がデータセンターの電源サージや不良アップデートで焼損した、という想定でクイズを行った。「86台が正常で14台が故障している」状況が、A（気にせず休暇を続けてよい）、B（すぐデスクに戻って直す）、C（深夜でもCEOとCTOを叩き起こす緊急事態）のどれに当たるかを会場に問い、票はBに最も集まった。 - 自分の答えは「It depends（場合による）」だと明かした。顧客が何も気づかなければA、顧客体験が遅くなるだけならB、会社の収益源そのものが止まっているならCになる、と説明した。監視システムは「86 up, 14 down」としか教えてくれないが、それは問題の本質ではないと結論づけた。 - ここから導かれる原則として、「信頼性は顧客の視点から測るものであり、コンポーネントの視点から測るものではない」と二度繰り返して強調した。 ## 「すべての障害をなくすには」とSREの好奇心 - SREの発想は好奇心から始まる、と述べた。「システムはどう動くのか」と「システムはどう壊れるのか」という二つの問いは、同じ好奇心の表裏だとした。 - SREが問うのは本番環境でどう動いているかであり、ホワイトボードや設計書の上でどう動くはずかではない、と釘を刺した。 - 信頼性に関わる仕事は「relentlessly collaborative（徹底して協働的）」であり、一人きりのキュービクルでは成立しない、と述べた。 - 一般的な組織がエラーや障害を排除すべき敵とみなすのに対し、SREはそれらをシグナルとして扱う、という関係性の違いを指摘した。障害を歓迎するという意味ではなく、そこから学ぶ姿勢を持つという意味だと補足した。 - したがって「すべての障害をなくすにはどうすればよいか」という問いは適切ではなく、「そこからどう学ぶか」を問うべきだ、と述べた。理想的に追いかけるべきは、毎回同じ原因で起きる障害ではなく、新規または一過性の障害だとした。 ## 「root cause（根本原因）」という言葉が覆い隠すもの - root causeという言葉について、自分が最も強い感情を見せる話題だと前置きした。 - 架空のトートバッグ会社を舞台にした一連の出来事を語った。Patがデータセンターで、Oscarが敷いたケーブルにつまずき、Susanが設定したデータベースが停止する。データの扱いはYasminが担い、バックエンドはNirajが書いたコードで、処理が遅くなるにつれてフロントエンドの問題も悪化する。Lizの監視は検知が遅れ、通知が届く前に、Samが設定したロードバランサーが503を大量に返し始める、という展開だった。 - 「この販売機会の損失は誰の責任か」という問いに対して、望ましい答えは「None of them and all of them—it's the system（その誰でもあり、誰でもない。システムの問題だ）」だと述べた。 - root causeという発想は単一の原因があるという前提に立ってしまい、実際の障害からの学びを狭めてしまう、と指摘した。ほとんどの障害には単一の根本原因など存在しないとした。 - 参考文献としてRichard Cookの論文「How Complex Systems Fail」を挙げ、複雑なシステムが実際にどう動いているかを理解するうえで有用だと紹介した。英語の論文だが4、5ページ程度で、翻訳も出回っているはずだと補足した。 - root causeの代わりに、トリガー（何が引き金になったか）とcontributing factors（寄与要因）という語を使うことを提案した。post-incident reviewを、ナイフを持った一人の犯人を捜す推理小説のように扱うべきではない、とも述べた。 - 視点を変える問いとして、「昨日、今日の障害が起きる前は、何がその成功のroot causeだったのか」を挙げた。この問いを突き詰めると、root causeという語自体が扱いにくくなると述べた。 - ここからresilience engineering（レジリエンスエンジニアリング）の話題に接続し、Erik HollnagelのSafety-II（障害が起きた30分にばかり注意を払うのではなく、残りの時間がうまくいっている理由に注目する考え方）と、MITのNancy Leveson教授によるSafety-IIIを紹介した。 ## SREは組織でどんな役割を担うべきか - 組織におけるSREの役割や成熟度モデルについてよく聞かれる、と前置きした。 - Ben Treynor Sloss が示したモデルとして、SREは多くの場合「firefighting（消火活動）」から始まると紹介した。 - 消火活動から抜け出すと、しばしば「二度と本番環境で問題を起こさせない」というgatekeeper（門番）の役割に陥りがちだが、これは長く留まるべき役割ではないと述べた。空港の税関職員を例に、誰かに「no」と言う人を好きになる人はいない、と説明した。 - そこからadvocate（信頼性を組織内で推進する立場）、さらにはpartner（相手のロードマップを一緒に作る立場）へと進みうるが、実現するかどうかはケースバイケースだとした。宮崎駿の映画のような話に聞こえるかもしれない、と冗談を交えた。 - この先に、全員が信頼性を考えるengineerという段階を置いたが、このモデルは線形ではなく、どの段階からでも新しいシステムの導入でfirefightingに引き戻されうる、とした。それ自体は問題ではなく、この業界に身を置く以上は前提にすべきだと述べた。 - 結論として、問うべきは「自分は将来何になりたいか」ではなく、「組織が今日、SREにどんな役割を求めているか」だとした。 ## SREを社内でどう売り込むか - SREを社内で売り込む際によくある失敗のパターンを列挙した。 - 一つ目は保険営業のような売り方だと指摘した。ダウンタイムは高くつくからSREに投資すればよい、という言い方は、実体化していないリスクを煽るだけであり、避けるべきだとした。 - 代わりに、実際に発生したダウンタイムの復旧コストと、再発防止のために要した追加コストを基準に、必要な投資額をエンジニアリングの数字として示すべきだと提案した。 - 二つ目の失敗は、信頼性を「税金」のように扱い、他の機能の上に一律で乗せるコストとして説明することだとした。信頼性はセキュリティと同様、後から付け足してうまくいくものではなく、最初からロードマップに組み込むべき機能だと述べた。 - 三つ目の失敗は、SREを入れても何も変わらず痛みもない、と約束することだとした。ジムに通うことに例え、実際には最初のうちは変化に不満が出るものだと説明した。 - 四つ目の失敗は、ビジネス側の人間にSLIやSLOの言葉でいきなり語りかけることだとした。ビジネス側が気にしているのはレジのシステムが動いているかどうかであり、相手の言語で、実データに基づく真実を語るべきだと提案した。 ## トイルの自動化とAIへの問い - toil（トイル）の定義として、SRE bookおよびSRE workbookにあるVivek Rauの定義を採用した。手作業であること、繰り返しであること、戦術的で戦略的でないことを挙げた。最も重要な点として、持続的な価値を生まないこと、つまり今日実施しても翌日のシステムがより信頼できるようにはならないことを挙げた。 - toilはサービスの成長に対してO(N)で増えるものであり、SREが人海戦術に頼れずスケールしない理由だと説明した。 - 「AIでトイルを自動化する」という切り口から、AIについて自分の意見を語るのではなく、AIと向き合うための明確化のための問いを提示した。 - 「AIとは何を指しているのか」。多くの場合、現在は大規模言語モデル（LLM）を指しているにすぎないと確認した。 - 「誰が使うのか」。経験のあるシニアなエンジニアはいつAIに反論すべきかを知っているが、ジュニアなエンジニアにはその経験がない、という違いを指摘した。 - 「いつ成功し、いつ失敗するのか」。AIを使ってものを作った経験のある人なら、失敗に気づくのが想定より遅れることを知っているはずだと述べた。 - 「何が得意なのか」。AIは迎合的（sycophant）にふるまうことが得意であり、ドメイン知識を持たず、次に来る適切なトークンを選ぶことに長けているにすぎないと述べた。 - 学習データの質にも注意すべきだと述べ、米ニューメキシコ州の歴史教育の例を挙げた。生徒にAIを使って課題をやらせたあとファクトチェックさせると、主要なAIモデルはニューメキシコ史について十分な学習データを持たず、誤った内容を生成していたという。 - SREはすでに自動化の成功と失敗について知見を持っている、として、自動化がどう失敗しうるかを論じた古い論文を「読むとAIについて語っているようで薄気味悪くなる」と紹介した（文字起こし中では具体的な書誌情報は読み上げられていない）。 ## レジリエンスと信頼性の違い - resilience engineering（レジリエンスエンジニアリング）という分野から学べることとして、レジリエンスと信頼性は同じ概念ではないと述べた。 - 多くの人が「resilient」という語を、フォールトトレラント、冗長、事前設計されている、可用性が高い、自己修復的である、といった意味で使っているが、それは本来のresilienceの意味ではないと指摘した。 - John Allspawの例を引用した。車に積んであるスペアタイヤは冗長性の例であって、バッテリーが上がって車が動かなくなったときには役に立たない。レジリエンスとは、そのときに別の車を調達する方法や、タクシー、配車サービスを呼ぶ方法を知っている、という適応力を指すと説明した。 - レジリエンスが持つ複数の側面として、rebound（元の状態に戻す力）、robustness（負荷がかかった状態でも保たれる頑健さ）、拡張性（サプライズに対応できること）、持続的な適応能力（sustained adaptability）を挙げた。 - 信頼性の将来はこの適応能力（adaptive capacity）の中にある、と述べ、この講演のタイトルの由来である、David Woodsの論文「Resilience is a Verb」を紹介した。 - 最後に、信頼性とは結局、自分たちがどんな問いを立てるかの問題だ、と締めくくった。質疑は終演後のAsk the Speakerで受け付けると案内した。