SREって何？現場で学んだサイト信頼性の第一歩

by syossan27

Slide 1

Slide 1 text

©MIXI SREって何？現場で学んだサイト信頼性の第一歩株式会社MIXI 井上翔太

Slide 2

Slide 2 text

©MIXI 自己紹介名前：しょっさん  X（旧: Twitter）/ mixi2：@syossan27  所属：株式会社 MIXI  活動：  ● SRE Kaigi ● SRE Magazine ● ゆるSRE勉強会 ● o11ycon

Slide 3

Slide 3 text

©MIXI Fanstaのご紹介 • スポーツ観戦ができる飲食店に特化した検索サービス • スポーツ観戦できる飲食店をエリアやチーム、放映予定から検索し、予約できる • お店にとってはスポーツ観戦ができることを告知し、集客することができる ©Fansta

Slide 4

Slide 4 text

©MIXI このセッションはインタラクティブ・セッションと題して分岐しながら進みます

Slide 5

Slide 5 text

©MIXI 挙手をとりながら進めていきますので楽しんでいきましょう！

Slide 6

Slide 6 text

©MIXI まずは練習

Slide 7

Slide 7 text

©MIXI SREを知ってるよ！/やってるよ！知ってる/やってる知らない/やってない

Slide 8

Slide 8 text

©MIXI SREとは？ Site Reliability Engineering（サイト信頼性エンジニアリング）という手法です。

Slide 9

Slide 9 text

©MIXI SREとは？ Site Reliability Engineering（サイト信頼性エンジニアリング）という手法です。 Googleが提唱

Slide 10

Slide 10 text

©MIXI SREとは？ Site Reliability Engineering（サイト信頼性エンジニアリング）という手法です。 Googleが提唱サービスの信頼性を担保

Slide 11

Slide 11 text

©MIXI SREとは？ Site Reliability Engineering（サイト信頼性エンジニアリング）という手法です。 Googleが提唱サービスの信頼性を担保 SWEを用いた運用へのアプローチ

Slide 12

Slide 12 text

©MIXI SREとは？ SREは手法であるため、様々なプラクティスが存在しています。 ● SLI / SLO の定義 ● モニタリング / オブザーバビリティ ● トイルの最適化 ● エラーバジェットの策定 / 運用 ● リリースエンジニアリング ● インシデント管理 ● ポストモーテム（ポストインシデントレビュー） ● etc…

Slide 13

Slide 13 text

©MIXI SLI / SLO の定義そもそも"信頼性"とはなにか？

Slide 14

Slide 14 text

©MIXI SLI / SLO の定義そもそも"信頼性"とはなにか？サービスによって大きく異なる ● 店舗予約システム ○ 予約ができること ● ニュースサイト ○ 記事が正しく読み込まれて、閲覧できること ⇒ ユーザーの関心が高い・そのサービスの根幹となる体験が損なわれないこと

Slide 15

Slide 15 text

©MIXI SLI / SLO の定義そもそも"信頼性"とはなにか？サービスによって大きく異なる ● 店舗予約システム ○ 予約ができること ● ニュースサイト ○ 記事が正しく読み込まれて、閲覧できること ⇒ ユーザーの関心が高い・そのサービスの根幹となる体験が損なわれないことこれをSLI / SLOとして定義していく

Slide 16

Slide 16 text

©MIXI SLI / SLO の定義どのようにSLI / SLOを定義するのか？ SLI ユーザー観点でのシステムメトリクス ● ユーザー体験に基づいたメトリクスを取得 ● CUJを設計し、ユーザー体験を理解して、SLIを見つけ出す ● まずはサービスの可用性/レイテンシなど SLO ユーザーが満足する目標値 ● SLIに対してパーセンテージで目標値を設定する ○ 例：一ヶ月の間にサービスは99.9%正常に稼働している ● "時間"をもとに決めるのもGood

Slide 17

Slide 17 text

©MIXI エラーバジェットの策定 / 運用信頼性を保てるエラーの許容量を策定

Slide 18

Slide 18 text

©MIXI エラーバジェットの策定 / 運用信頼性を保てるエラーの許容量を策定 SLOから許容できるエラー量を算出 SLOが99.9%だと0.1%はエラーを発生させる余裕があるということポリシーを設定し、エラーバジェットが減った場合にどうするか？の運用を決めておく ⇒ 基本的には使い切ったら機能リリースをストップし、エラーへの対応を最優先

Slide 19

Slide 19 text

©MIXI エラーバジェットの策定 / 運用信頼性を保てるエラーの許容量を策定 "挑戦"と"安定"のバランスを保つ指標とする SLOから許容できるエラー量を算出 SLOが99.9%だと0.1%はエラーを発生させる余裕があるということポリシーを設定し、エラーバジェットが減った場合にどうするか？の運用を決めておく ⇒ 基本的には使い切ったら機能リリースをストップし、エラーへの対応を最優先

Slide 20

Slide 20 text

©MIXI モニタリング / オブザーバビリティサービスを"知る"ためのプラクティス

Slide 21

Slide 21 text

©MIXI モニタリング / オブザーバビリティサービスを"知る"ためのプラクティスモニタリング：「既知の未知」を知ることができるリアクティブに既知の障害で未知な状態であることをユーザーに知らせる（例. 特定時間帯にCPU負荷が高くなる現象が発生している[既知]が、何故かはわからない[未知]）オブザーバビリティ：「未知の未知」を知ることができるプロアクティブに未知の障害で未知な状態を調査することができる（例. サービスが動いていないと一部ユーザーから報告が来た[未知]が、何故かはわからない[未知]）

Slide 22

Slide 22 text

Slide 23

Slide 23 text

©MIXI トイルの最適化繰り返して行われる手作業を最適化

Slide 24

Slide 24 text

©MIXI トイルの最適化繰り返して行われる手作業を最適化大量の作業が発生する前に最適化を ● 戦術的である ● 長期的価値がない ● 自動化できる ● サービス成長に比例するに当てはまるものは優先的に対応しましょうトイルは自動化して変容させたり、仕組みの再設計で不要化させることで対応する

Slide 25

Slide 25 text

©MIXI トイルの最適化繰り返して行われる手作業を最適化大量の作業が発生する前に最適化を ● 戦術的である ● 長期的価値がない ● 自動化できる ● サービス成長に比例するに当てはまるものは優先的に対応しましょうトイルは自動化して変容させたり、仕組みの再設計で不要化させることで対応する恒常的にトイル対応して、信頼性の高い組織へ

Slide 26

Slide 26 text

©MIXI リリースエンジニアリング高い信頼性はリリースから始まる

Slide 27

Slide 27 text

©MIXI リリースエンジニアリング高い信頼性はリリースから始まる CI/CDの整備や、安全なリリース手法、デプロイ高速化など信頼性と直結一見すると信頼性との関連性がないように見えるが、SREとの結びつきが強いエンジニアの負荷を減らし、リリースサイクルを円滑化させ、信頼性が担保された成果物をデプロイし、障害時には迅速なロールバックを実現させる

Slide 28

Slide 28 text

Slide 29

Slide 29 text

©MIXI インシデント管理障害時の対応を標準化する

Slide 30

Slide 30 text

©MIXI インシデント管理障害時の対応を標準化する個々が自由に対応するのではなく、 "障害が起きたらこうする "を決める ● ウォールームの設置 ● 役割の設定 ● エスカレーションプロセス突然やりましょう！となっても上手く動くことが難しいので、事前にロールプレイをやって慣れておきましょう

Slide 31

Slide 31 text

©MIXI インシデント管理障害時の対応を標準化する信頼性の毀損を最小化するための備え個々が自由に対応するのではなく、 "障害が起きたらこうする "を決める ● ウォールームの設置 ● 役割の設定 ● エスカレーションプロセス突然やりましょう！となっても上手く動くことが難しいので、事前にロールプレイをやって慣れておきましょう

Slide 32

Slide 32 text

©MIXI ポストモーテム（ポストインシデントレビュー）インシデントをその後の糧にする

Slide 33

Slide 33 text

©MIXI ポストモーテム（ポストインシデントレビュー）インシデントをその後の糧にするインシデントは解決して終わりではないインシデント後になるたけ早くチーム全体で行う ● インシデント状況の共通理解 ● ネクストアクションを中心に記録し、話し合いすることでインシデントへのレジリエンスを高め、より信頼性を高めるキッカケにする

Slide 34

Slide 34 text

©MIXI ポストモーテム（ポストインシデントレビュー）インシデントをその後の糧にする大事なのは"非難なき話し合い" インシデントは解決して終わりではないインシデント後になるたけ早くチーム全体で行う ● インシデント状況の共通理解 ● ネクストアクションを中心に記録し、話し合いすることでインシデントへのレジリエンスを高め、より信頼性を高めるキッカケにする

Slide 35

Slide 35 text

©MIXI これを踏まえて

Slide 36

Slide 36 text

©MIXI 現場の話

Slide 37

Slide 37 text

©MIXI 前提

Slide 38

Slide 38 text

©MIXI 開発チーム：６名 SREチーム：　　

Slide 39

Slide 39 text

©MIXI 開発チーム：６名 SREチーム：１名

Slide 40

Slide 40 text

©MIXI 少人数チームでの話

Slide 41

Slide 41 text

©MIXI ここで分岐！

Slide 42

Slide 42 text

©MIXI どちらの話を聞きたい？具体的なタスクや施策の話文化や進め方の話

Slide 43

Slide 43 text

©MIXI 具体的なタスクや施策の話

Slide 44

Slide 44 text

©MIXI トイルの最適化運用が始まって一年ほど経ってから、SREの実践が始まったのでトイルはたんまりありました。最初期はコスパの良いトイルを片付けていきましょう。初期 ● スクラム運用ツールの開発 ● QA作業円滑化のためにデバッグツールを開発 ● 開発環境の使用状況管理ツールの開発 ● Xでのサービスに対するポストをSlack通知 ● メンテナンスモードの簡易化

Slide 45

Slide 45 text

©MIXI トイルの最適化 ❏ GH PJ上に各ステータスごとのストーリーポイント数を表示するChrome拡張の作成 ❏ バーンダウンチャート可視化・管理

Slide 46

Slide 46 text

©MIXI トイルの最適化運用が始まって一年ほど経ってから、SREの実践が始まったのでトイルはたんまりありました。初期 ● スクラム運用ツールの開発 ● QA作業円滑化のためにデバッグツールを開発 ● 開発環境の使用状況管理ツールの開発 ● Xでのサービスに対するポストをSlack通知 ● メンテナンスモードの簡易化初期はコスパの良いトイルを優先的に

Slide 47

Slide 47 text

©MIXI トイルの最適化運用が始まって一年ほど経ってから、SREの実践が始まったのでトイルはたんまりありました。現在 ● Slack bot × OpenAI APIでの自然言語による一時権限付与 ● GPTsを利用したQAチーム向けSQL作成支援 ● Claude Code Actionを利用したRenovateの自動一次調査現在はAIの興隆で最適化に新たな視点が芽生えた

Slide 48

Slide 48 text

©MIXI リリースエンジニアリング git-flow, CI/CDをgit-pr-releaseやArgoCD, CircleCIを利用して構成

Slide 49

Slide 49 text

©MIXI ポストモーテム（ポストインシデントレビュー） SRE本を参考にしたテンプレートを用意し、インシデント後に必ずレビューを行う ● 障害概要 ● 時系列 ● 詳細 ● 対応内容 ● モニタリング情報 ● 再発防止策 ● 気付き ● 参考情報

Slide 50

Slide 50 text

©MIXI ポストモーテム（ポストインシデントレビュー） SRE本を参考にしたテンプレートを用意し、インシデント後に必ずレビューを行う ● 障害概要 ○ 「詳細な障害発生時刻」「対応者」「ステータス（どういう状態になったのか経過と結果）」を記載 ● 時系列 ○ 箇条書きで「起こったこと」「行ったこと」についてコンパクトに記載 ● 詳細 ○ 「発生した要因」「発生に至った根本原因」「影響範囲」について記載 ● 対応内容 ○ 修正したPRのリンクや実行したコマンドなど、技術観点を忘れず対応した内容を記載

Slide 51

Slide 51 text

©MIXI ポストモーテム（ポストインシデントレビュー） SRE本を参考にしたテンプレートを用意し、インシデント後に必ずレビューを行う ● モニタリング情報 ○ インシデントに気付いた際のモニタリング情報や、調査/解決までのプロセスで利用したモニタリング情報を記載 ● 再発防止策 ○ インシデントの再発を防止するための案を記載 ○ チームで考えた結果を記載するのが良い ● 気付き ○ 個人的なメモ、教訓など気付いたことを記載 ● 参考情報 ○ インシデント対応で参考になった情報など

Slide 52

Slide 52 text

©MIXI 他にも色々やってるよ！ ● 小さなサービスでの SREとの付き合い方【MIXI TECH CONFERENCE 2023】

Slide 53

Slide 53 text

©MIXI 他にも色々やってるよ！ ● Fanstaの１年を大解剖！一人SREはどこまでできるのか！？

Slide 54

Slide 54 text

©MIXI 他チームとのコラボレーション SREを実施する場合には、他チームとの"信頼関係"を構築することをよく考えなくてはいけない

Slide 55

Slide 55 text

©MIXI 他チームとのコラボレーション ※ David N. Blank-Edelman 編, 山口能迪監訳、渡邉了介訳 (2021年) SREの探求 - オライリージャパンより引用 SREを実施する場合には、他チームとの"信頼関係"を構築することをよく考えなくてはいけない弾力性が高いサービスを構築するためには、考え方の多様性がチーム内に存在している必要があります。この最後の要因は、技術的な知識のレベルよりもエンジニア同士の関係性のほうがはるかに大きな影響を与えます。※

Slide 56

Slide 56 text

©MIXI 他チームとのコラボレーション SREを実施する場合には、他チームとの"信頼関係"を構築することをよく考えなくてはいけない弾力性が高いサービスを構築するためには、考え方の多様性がチーム内に存在している必要があります。この最後の要因は、技術的な知識のレベルよりもエンジニア同士の関係性のほうがはるかに大きな影響を与えます。※ ※ David N. Blank-Edelman 編, 山口能迪監訳、渡邉了介訳 (2021年) SREの探求 - オライリージャパンより引用個人的には信頼貯金を貯めるという考え方が好き信頼貯金を貯めるフェーズ・消費するフェーズを分けて施策を変えていく

Slide 57

Slide 57 text

©MIXI 文化や進め方の話

Slide 58

Slide 58 text

©MIXI なぜSREを実践することになったのか？

Slide 59

Slide 59 text

©MIXI 経緯 ■ 2021/03〜とある機能の実装の流れからインフラをちょこちょこと触るようになる ■ 2021/04〜負荷計測・パフォーマンスチューニング、インフラ・デプロイフローの障害時調査などのタスクに積極的に関わる ■ 〜2021/10 上記を続けながらアラートを追加したり整理したり、トイルを無くすように仕組み作りをしたり、インシデント管理をしたり・・・

Slide 60

Slide 60 text

©MIXI これはSREというやつでは・・・?

Slide 61

Slide 61 text

©MIXI サービス規模に関わらず、SREは誰かが必ずやっている何故SREは必要となったか？気付いたら"SRE"と呼ばれることをやっていた

Slide 62

Slide 62 text

©MIXI サービス規模に関わらず、SREは誰かが必ずやっている何故SREは必要となったか？気付いたら"SRE"と呼ばれることをやっていた ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。※ 小さなチームでは運用チームを持たないことが多いので（雰囲気兼任が多い） "明確な"運用チームの動きが生まれたらそれがSREのはじまりと言える

Slide 63

Slide 63 text

Slide 64

Slide 64 text

©MIXI SREの始め方 How SRE teams are organized, and how to get started （SREチームの編成方法とその始め方） ※ Google社のブログ記事の中で６つのSREの導入パターンが紹介されています。 ※ Goolge Cloud Blog 「How SRE teams are organized, and how to get started」 https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started より引用 1. SREも開発もやるなんでも屋さん 2. インフラの保守や、CI/CDなどの保守 3. SREに関するツールを開発・導入・運用 4. 主要なアプリケーションのみの信頼性向上を担う 5. 特定の開発チームに組み込まれたSREチーム 6. 開発チームに組み込まれないSREチーム

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

©MIXI １人でSREをやるのは中々難しい場面が多いので出来れば複数人チームで！

Slide 68

Slide 68 text

©MIXI 何からやるか？

Slide 69

Slide 69 text

©MIXI 何からやるか？何はなくともサービスにおける"信頼性"の定義から！ SLI/SLOを定義することにより、目指すべき信頼性を見える化する

Slide 70

Slide 70 text

©MIXI 何からやるか？何はなくともサービスにおける"信頼性"の定義から！ SLI/SLOを定義することにより、目指すべき信頼性を見える化するまずはSLIの開発をして観察意味のあるSLOを設定してみる観察更新

Slide 71

Slide 71 text

©MIXI 何からやるか？その後はDickersonの信頼性の階層構造 ※ を参考にするのがオススメ ※ David N. Blank-Edelman 著 / 山口能迪訳 (2024年) SREをはじめよう - オライリージャパンより引用

Slide 72

Slide 72 text

©MIXI 何からやるか？その後はDickersonの信頼性の階層構造 ※ を参考にするのがオススメ ※ David N. Blank-Edelman 著 / 山口能迪訳 (2024年) SREをはじめよう - オライリージャパンより引用あくまでも一つの"型"。組織に合わせてプラクティスをチョイスしよう！

Slide 73

Slide 73 text

©MIXI 何からやるか？「SREをはじめよう」にもあるが、まずはモニタリング・オブザーバビリティとインシデントレスポンスを整備することで、耐障害性を向上させる ※ David N. Blank-Edelman 著 / 山口能迪訳 (2024年) SREをはじめよう - オライリージャパンより引用 Done ● Cloud Monitoringによるアラートポリシー拡充 ● Cloud Loggingに沿った構造化ロギング ● 各種サービスでのAudit Logsの導入と通知設定 ● Cloud Trace × OpenTelemetryの導入 ● 各種Runbookの作成

Slide 74

Slide 74 text

©MIXI ■ Audit Logsの通知例過去の経緯からFirebaseでのサービスアカウント一覧画面の表示時に通知を出すようにしている。 Audit Logsは基本取っておくようにしておくとよし

Slide 75

Slide 75 text

©MIXI ■ Cloud Trace

Slide 76

Slide 76 text

©MIXI ■ Cloud Trace - Span

Slide 77

Slide 77 text

©MIXI 最後の分岐

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

©MIXI SRE × AIを考える SREのどこにでもAIを活用できる余地がある既に関連サービスはいち早く取り組んでいる ● PagerDuty ○ Agentic Site Reliability Engineer ○ Agentic Operations Analyst ○ Agentic Scheduler ● Datadog ○ Bits AI

Slide 84

Slide 84 text

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Slide 87

Slide 87 text

Slide 88

Slide 88 text

Slide 89

Slide 89 text

©MIXI 一時権限付与ツール Slack botに自然言語でメンションを飛ばすことでGCの一時権限付与を実行開発チームに存在した ● スラッシュコマンドでの複雑さ ● 適切なロールを探し出す手間を解決！ OpenAI API（Responses API）,VectorStore, Function Callingで実装

Slide 90

Slide 90 text

©MIXI 作る以外もやるよ！ "モノをつくる"以外にも様々なAIに関するアレコレを一手に引き受けた ● AI利用の書類業務 ○ 申請 / 契約や、それに付随する説明 ● 利用推進 ○ Slackチャンネルを作成し、AIに関する情報を逐一放流 ○ 困っている利用者の拾い上げ ● ガイドラインなどのドキュメント整備 ○ Claude Codeなどツールの利用ドキュメント ○ MCPサーバーの安全利用のためのガイドライン ● etc…

Slide 91

Slide 91 text

Slide 92

Slide 92 text

Slide 93

Slide 93 text

Slide 94

Slide 94 text

©MIXI Andrej Karpathy曰く ※ アイアンマンスーツのようにaugmentation（能力拡張）と agent（自律エージェント）が調節できるような "autonomy slider"を今後10年間でagentに徐々に動かしていくことが重要になってくる SREもこの流れがきているので乗っていこう！ ※ Andrej Karpathy: Software Is Changing (Again) (2025年) https://www.youtube.com/watch?v=LCEmiRjPEtQ

Slide 95

Slide 95 text

©MIXI 反省など過去の話

Slide 96

Slide 96 text

Slide 97

Slide 97 text

Slide 98

Slide 98 text

Slide 99

Slide 99 text

©MIXI 失敗事例１：目安箱開発チームが潜在的に抱えている問題を拾い上げるために目安箱を設置投票数が少なく、目立った効果を上げることは出来ず撤廃・・・原因１導入時期の問題 ● リリースからまだ日が経っておらず、問題として出やすい運用に関するトイルが生まれていなかった ● 新規メンバーが入ってまだ間もないタイミングだった原因２トイルの自覚 ● トイルがトイルだと自覚されずに律儀に対応されてしまっていた

Slide 100

Slide 100 text

Slide 101

Slide 101 text

Slide 102

Slide 102 text

©MIXI 失敗事例２：相談アワー対面で相談を受け付けるための相談アワーを試してみた成果に繋がる相談もあったものの、利用頻度が低く撤廃・・・原因１バーチャルオフィスの利用率低下 ● チームとしてGatherを使っていたが、そもそもバーチャルオフィスの利用率が段々低下した原因２作業時間の確保を優先 ● 終了理由ではあるのですが、SREにかけられる時間が増えてきた時期で作業時間確保を優先したため

Slide 103

Slide 103 text

Slide 104

Slide 104 text

Slide 105

Slide 105 text

©MIXI 失敗→成功事例：依存ライブラリのアップデート運用 Renovateを利用したライブラリアップデートを一人で担っていたそのため、頻度が半年に一回に・・・リベンジ運用を開発チームを巻き込む形に ● コラボレーションの意識が希薄だったなと反省をもとに運用に開発チームを巻き込むことにした ● 今ではスプリントプランニングにライブラリアップデートを盛り込んでもらえることに ● さらに、AIを活用してClaude Code Acitonを利用した一次調査、またアップデートにもClaude Codeを利用

Slide 106

Slide 106 text

Slide 107

Slide 107 text

©MIXI エンディング