信頼性について考えてみる（SRE NEXT 2026 miniLT）

Transcript

1. 信頼性について考えてみる
2. hym 所属 株式会社3-shake Sreake事業部 趣味 コンテナとかk8sとかSREとかk8sとか
3. 今日の話のベースになった3つの記事 SRE Magazine「 『SREは信頼性、PEは生産性』に引っかかったので、"信頼性"を考え直してみる」 hym（@hymaaa_k / 3-shake SRE） https://sre-magazine.net/articles/13/hym/ Qiita「SRE NEXTで、バラバラの課題が"信頼性"という枠組みでつながった話」 https://qiita.com/ryucciarati/items/1dd4df9ac2fb04fee600 Zenn「SREを『努力』から『仕組み』へ — Platform Engineeringという選択」 mekka（株式会社ログラス） https://zenn.dev/loglass/articles/f4dda877788337
4. 「SREは信頼性、PEは開発者体験」ってよく聞く SREとPE（Platform Engineering）の違いを説明するとき、この対比が定番になっている SRE: サービスの信頼性に責任を持つ PE: 開発者体験・生産性に責任を持つ 綺麗な整理に見えるが、この対比が成立するのは「信頼性」の意味が共有されているときだけ そこで言う"信頼性"、稼働率（Uptime）のことだと思っていませんか？
5. 教科書的には、信頼性はもっと多面的に定義されている RASIS: 情報システムの品質を測る古典的な5観点 Reliability（信頼性）: 壊れにくさ。代表指標はMTBF（平均故障間隔） Availability（可用性）: 使いたいときに使えること。代表指標は稼働率 Serviceability（保守性）: 直しやすさ・復旧しやすさ。代表指標はMTTR Integrity（完全性）: データが壊れず、一貫していること Security（安全性）: 不正アクセスや情報漏洩から守られていること
6. RASISで見ると、"Reliability"と"稼働率"は別物 Reliability（狭義の信頼性） 壊れにくさ、そのもの MTBF: どれだけ長く故障せずに動き続けるか 「落ちない」を作り込む観点 Availability（可用性） 使いたいときに使える状態 稼働率: 落ちても素早く戻れば高くなる 「落ちてもすぐ戻る」も含む観点
7. 現場の課題も、"信頼性"という枠組みでつながる 性能が悪化しないようにする 問題が起きたときに、影響を広げない 異常を早く検知する 復旧しやすい状態にしておく これらは別々の話ではなく、すべてサービスの信頼性を支えるための設計 「99.99%」という数字は、その中の一要素でしかない
8. そもそもSREの"Site"は、Webサイトのことじゃない Site Reliability Engineering = 「サイト」の信頼性のエンジニアリング ここでのSiteは「サーバー」でも「Webページ」でもなく、サービスそのもの つまりSREが引き受けているのは「サーバーの稼働率」ではなく「サービスの信頼性」 名前を素直に読み直すだけで、対象がぐっと広がる
9. "Reliability"という語感が、SREの仕事を矮小化する Reliabilityを素直に読むと「壊れない・落ちない」に寄ってしまう その結果、SREの仕事はRASIS的な「守りの品質」に矮小化されがち 稼働率を維持する人、障害対応する人、監視を整える人…… でもRASISは、あくまで「守り」を整理した枠組み サービスの信頼性は、守りだけでは語り切れない
10. サイトの信頼性には、"攻め"も含まれる 新機能を、誰よりも早く出せること 法改正に、誰よりも早く対応できること ユーザーが欲しい機能を、ちゃんと出し続けられること どれも「このサービスは期待に応え続けてくれる」という信頼の源泉 つまり開発速度・デリバリー能力も、サービスの信頼性の一部
11. 「落ちていないのに、信頼を失う」ことがある 法改正対応が遅れて、業務に使えない期間が生まれる 外部APIの仕様変更に追従できず、連携機能が壊れたまま 脆弱性対応や不正対策が遅く、安心して使えない 稼働率のグラフはずっと緑のまま、ユーザーの信頼だけが削れていく 逆もある: 夜間バッチ基盤が日中止まっていても、締め処理が確実に完了すれば「信頼できる」
12. 「そのSLO 99.9%、本当に必要ですか？」 クラウドネイティブ会議2026（Topotal・VTRyo氏）での問いかけ CSチームへのヒアリング結果: 障害による解約よりも、機能不足による失注・解約の方が数が多かった 稼働率の過剰維持をやめて機能開発に投資するのは、 「信頼性を捨てる判断」ではなく「事業にとって の信頼性優先度の組み換え判断」
13. そもそも、なぜSREはサービスの信頼性を上げるのか サービスが信頼されると、ユーザーが使い続けてくれて ビジネスが成功して、ちゃんと儲かって 良い給料をもらって、カンファレンスに参加して、いいホテルに泊まって美味しいご飯を食べるため！
14. 信頼性向上は目的ではなく、手段 ビジネスの成功につながらない信頼性向上は、優先度が下がって当然 「稼働率を上げること」自体がゴールになっていたら、それは手段の目的化 問うべきは「うちのサービスは、何によって信頼され、何を失うと解約されるのか」 会計・給与SaaSなら: 締め日・給与計算日に処理が確実に終わること パスワードマネージャーなら: 秘密が漏れないこと。可用性はその次
15. SREとPEの違いは、目的ではなくアプローチ ログラスのSREチームは1年間「SREの民主化」に取り組み、突き当たったのは"努力"では続かないと いう壁だった mekka（株式会社ログラス） 「SREを『努力』から『仕組み』へ — Platform Engineeringという選択」 https://zenn.dev/loglass/articles/f4dda877788337 「SREを『努力』から『仕組み』へ。これが1年間で得た最大の学びである」 同記事の整理: SREの実践（目的）をPlatform Engineering（仕組み）が支え、Kubernetes（手段） が基盤となる まとめ: SREもPEも、サービスの価値を守り育てるという目的は同じで、違うのはアプローチだけ
16. 画一化されたSREプラクティスにとらわれ ず、自分たちの事業にとっての"信頼性"を定義 しよう