NotebookLM で社内のSREに関するブログや登壇資料を学習させ、SREのオンボーディングに活かせるか?

はてなのシステムプラットフォームチームで SRE として働いている id:masayoshi です。

この記事は、はてなの SRE が毎月交代で書いているSRE連載の 6 月号です。5 月号の記事は id:KashEightさんの DMARC レポートを Mackerel + OpenTelemetry でいい感じに可視化する - 実装と躓き - Hatena Developer Blog でした。

さて今回の記事ですが、NotebookLMに公開されている自社の技術ブログ(例えば本記事のSRE連載など) や自分の登壇資料や文章を学習させて、新しく入社したSREのオンボーディングへの利用やSREがいない開発チームで活用できるのではないかと思い、ひとまず試してみたというゆるふわ記事になります。
実際に行っているオンボーディングは、2024年のSRE連載記事に詳細があるのですが、AWSやTerraformなど技術的な内容だけではなくて、SREの考え方やSLO運用をどうやって開発チームに提案するのか、障害対応演習など多岐にわたります。これらのオンボーディングや障害対応演習などの取り組みについては、以下の記事で詳しく紹介しています。

これらのオンボーディングは、コーディングなどとは違い非同期にPRなどをレビューするだけではなく、ディスカッションや講義をする講師役が必要になるためSREメンバー側の負担が大きくなってしまいます。また、講師役になれるSREは多くないため、SREという職種のエンジニアならまだしも、アプリケーションエンジニアやマネージャー、開発チーム全体にSREのオンボーディングを実施することは難しいという課題感がありました。

一方で、上記に挙げた記事のように、はてなでは社内で実施した取り組みや、その意図、実施した結果などをブログやイベントの登壇で社内外に発表する文化が根付いているため、オンボーディングの取り組みが文章やスライド、動画などで記録されています。

そこで、それらの資料をNotebookLMで学習させオンボーディングの講師役の人がいなくてもオンボーディングができるのではないか、また、オンボーディングのタイミングだけではなく必要なときに調べられる環境が提供できるのではないか、と思ったので今回様々な試してみました。試してみたといってもオンボーディングまでは実践できていない状況なので、学習させたNotebookLMで遊んでみた結果を紹介します。実際にオンボーディングを実施できたらその結果はまたレポートしようと思います。

先に結論だけ書いておきます。

学習元の内容を比較的そのまま出すため間違いは少ない。逆に言うと学習元のドキュメントが重要で、講師役の人がちゃんとドキュメントやオンボーディングの目的、重要なことなどをドキュメントに書いておく必要がある。
- はてなでは、取り組みをアウトプットする文化によって学習させる文章、スライドが多いためやりやすかった。
ドキュメントや資料ベースだと、内容や状況が古くなりがちで、最新情報をキャッチアップするのは難しい。
デザインドキュメントや手順書、コードなどで構成や設計意図などを伝えることはできるが、SLO運用を開発チームにどう広げるかなど組織に関わることは登壇資料やブログベースであることが多く、今まではその資料を活かすことが難しかった。それらを再利用することが容易になったことで、チームの取り組みのようなオンボーディングなどがだいぶ楽になりそう。

学習に利用したデータ

今回は以下のデータを学習させました。

Hatena Developer Blog のSREタグがついている記事 (本記事のようなSRE連載など)
私(id:masayoshi) の各種登壇資料
私(id:masayoshi) の執筆した記事、ブログ
社内向けのSRE説明資料
はてなのSRE採用ページ
- SRE (Site Reliability Engineer) 職転職・中途 - 採用情報 - 株式会社はてな

今回は会社のドキュメントや登壇資料でどれぐらいカバーできるのか気になったため SRE Workbook などの公開されているSRE関係のイベントやブログなどはあえて学習させていません。

sre.google

実際にNotebookLMに聞いてみた

質問内容: SREについて教えて

こんにちは！SRE（Site Reliability Engineering）についてですね。私は、あなたが提供してくださった資料、例えばAWS Summitのプレゼンテーション、SREに関する連載記事、はてなの開発ブログなど、さまざまな技術情報に精通しています。これらの情報を活用して、SREの概念、実践方法、必要なスキルなどについて、分かりやすくご説明させていただきますね。

SREについてのご質問、承知いたしました。以下に、SREに関する主要な情報をまとめました。

SRE (Site Reliability Engineering)とは

SREは、Googleが提唱した概念で、「ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの」と定義されています。これはDevOpsの思想を「Class SRE implements DevOps」と表現されるように、その実践であり実現手段とされています。

SREの主な目的は、「特定の信頼性のもとで開発速度を最大化する」ことです。Webサービス開発においては、機能開発と信頼性はトレードオフの関係にあり、このバランスを定量的に制御することがSREの重要な役割です。

SREの核となる考え方：SLO、SLI、エラーバジェット

SLO (Service Level Objective): サービスの信頼性の目標値で、通常は割合で示されます。ユーザーの満足度を満たす信頼性を目指し、プロダクトの特性や開発フェーズ、ユーザー体験などを考慮して設定されます。SLOは状況に応じて変更可能であり、定期的な見直しが必要です。

SLI (Service Level Indicator): サービスの信頼性を定量的に測る指標です。サービスの状態を正確に推定できることが好ましく、「可用性（成功したリクエストの割合）」や「レイテンシ（高速に処理されたリクエストの割合）」などが代表的です。ストリーム処理やバッチ処理を含むパイプライン形式のサービスでは、「新鮮さ」「正確性」「カバレッジ」といったSLIも考慮されます。

エラーバジェット: エラーの許容範囲を示す「予算」で、「100% - SLO」で計算されます。この予算を使い切った場合、新機能開発を一時停止し、バグ修正やパフォーマンス改善に注力して信頼性を回復させる必要があります。

これらの指標をチームや会社全体で共有し、定量的なデータに基づいて意思決定を行うことがSREの根幹をなします。

SREに必要なスキル

SREは「ソフトウェア技術」「インフラ技術」「ソフトスキル」の3つのスキルを駆使する「総合格闘技」とも表現されます。

ソフトウェア技術:

運用自動化のためのスクリプトやIaC (Infrastructure as Code) の読み書き能力。

モニタリングに必要なメトリック取得用プラグインの作成能力。

プロダクトコードの読解、ログ出力やAPM (Application Performance Monitoring) 追加などの比較的簡単な修正・追加能力。

プロダクトコードのリファクタリング、テスト改善、パフォーマンス改善など、高度な変更能力。

インフラ技術:

一般的なWebサービスが動くインフラ環境（ロードバランサ、Webサーバ、コンテナ、データベースなど）をクラウドで設計・構築する能力。

必要なリソースのモニタリングと、基本的な障害対応のための調査能力。

分散システムなど複雑なシステムのインフラ環境やモニタリングの設計、構築、運用能力。

未知の障害が発生した際に、適切な障害対応ができる能力。

ソフトスキル（コミュニケーション能力）:

障害対応時に適切なコミュニケーション（非難しない文化、明確な指示、定期的な報告）を取る能力。

プロダクトマネージャーや開発チームを巻き込み、SLOを策定し、共通の目標として運用を進める能力。

はてなでは、SREの職種として「Embedded SRE」（サービス開発チームと連携）と「Platform SRE」（全社共通システムの管理運用）の2つがあります。

SREの主な活動と実践

モニタリング: システムの状態を把握し、異常を検知するために重要です。

メトリクス: サービスの全体的な状態を定量的に把握するために利用され、アラート、SLI/SLOの判断、キャパシティプランニングに役立ちます。

ログ: 特定の時間にどこで何が起こったか（イベント）を記録し、テキストデータが基本です。網羅性が高く、エラーやアクセス情報、セキュリティ、監査などに利用されます。

トレース: 特定のリクエスト単位で発生したイベントを記録し、システム全体の繋がりやパフォーマンス調査に適しています。

コンテナ環境での監視では、サイドカーパターンを用いて監視エージェントを動かし、メトリクスをネットワーク経由で取得したり、CloudWatch MetricsやLogsを活用したりします。

障害対応:

障害対応は特殊な状況であり、技術的スキルだけでなく訓練や知識が必要です。

「指揮官」「作業者」「コミュニケーション役」「書記」といった役割分担を定めたフォーメーションを組むことが推奨されます。

障害対応テンプレートを用意し、必要な情報に素早くアクセスできるようにすることが重要です。

障害対応フローのロールプレイや、検証環境での実作業訓練を通じて、障害対応力を高めます。

ポストモーテム（障害の振り返り）:

障害発生後に再発防止策を検討するために行われます。

「非難をしない」文化が最も重要であり、心理的安全性の確保がサービスの信頼性向上につながります。

すべての障害で実施するのではなく、SLOへの影響度や発生頻度に基づいて実施基準を定めます。

過去のポストモーテムは障害対応訓練にも活用できます。

自動化: CI/CD (Continuous Integration/Continuous Delivery) や IaC (Infrastructure as Code) による自動化は、SREの重要な実践です。

はてなにおけるSRE

はてなでは、以前からオンプレミス環境の運用を行い、その後AWSへの移行、さらにECSやEKSといったコンテナ環境へのCloud Native化を進めてきました。SREを推進する上で、社内のドッグフーディング文化（自社サービスを自社製品で運用すること）を活用し、SLI/SLOの実装と改善に役立てています。また、SRE研修を新卒やキャリアチェンジした社員向けに実施し、SREの原理原則やSLI/SLOの設計・運用、インフラ構築・運用、CI/CD環境構築などを教えています。

SREに関する概要は以上です。SREの領域は非常に幅広いですが、この説明でSREがどのようなものか、少しでもイメージが湧きましたでしょうか？

もしよろしければ、SREの特定の側面について、さらに詳しく掘り下げてみましょうか？例えば、「SLOの具体的な決め方」や「障害対応の練習方法」などはいかがでしょうか？それとも、今お話しした内容の理解度を確認するために、短いクイズを出してみましょうか？

どうでしょう？なかなかいい感じな気がします。ところどころ強気に言い切っているところがあるので、そこは誤解を多少与えそうですが社内のオンボーディングで利用する分には良さそうです。
最後にある提案も良さそうな感じです。「SLOの具体的な決め方」、「障害対応の練習方法」、短いクイズなんかもオンボーディングとしてはやりたい内容なので、講師役がいなくても独学で次に進めそうな感じも出ています。実際のプロンプトにも以下のような提案になっており、こちらもいい感じです。

せっかく提案してもらったので「SLOの具体的な決め方」について教えてもらいましょう。

質問内容: SLOの具体的な決め方について教えてください

こんにちは！SREの目標とSLOの具体的な決め方についてですね。私は、あなたが提供してくださった資料、例えばAWS Summitのプレゼンテーション資料やはてなデベロッパーブログの記事、SREに関する連載記事、そしてSREの採用情報などを基に、SLOの定義から具体的な決定プロセスまで、分かりやすくご案内できます。これらの資料は、SREの基本的な考え方から、実際の運用事例、そしてチーム作りまで、幅広い情報を含んでいます。

それでは、SLOの具体的な決め方について、詳細にご説明します。

SLOの具体的な決め方

SLO（Service Level Objective：サービスレベル目標）は、SREにおいて「特定の信頼性のもとで開発速度を最大化する」というSREの目標を達成するために非常に重要な要素です。SLOはサービスの信頼性の目標値を表し、通常は割合で示されます。SLOを適切に設定し運用することで、Webサービス開発における機能開発と信頼性の難しいバランスを定量的に制御することができます。

SLOを決定する際には、以下の要素を考慮し、関係者間で合意形成を行うことが不可欠です。

1. ステークホルダーとの合意形成

SLOは、運用チームだけでなく、開発チーム、プロダクトマネージャー、そしてサービスに関わる他のすべてのステークホルダーが共有すべき目標値です。運用チームだけの目標にしてしまうと、SREの基本的な考え方であるDevOpsの実現が難しくなります。

SLOを決定する際には、以下の点をそれぞれの立場で検討し、合意する必要があります: * 運用可能性の現実性：その目標値で現実的に運用が可能か。 * 開発速度への影響：開発チームがそのSLOによって許容されるエラーバジェット（100% - SLO）で十分な開発ができるか。 * ユーザー満足度：そのSLOでユーザーが満足し、ユーザー離れにつながらないか。 * ビジネスへの影響：サービスが直接的に収益につながっているか、市場に競合がいるか、サービスが有料か無料か、コンシューマー向けか企業向けかなども考慮します。

2. SLOの初期設定と暫定運用

適切なSLOを最初から正確に見積もることは困難です。そのため、まずは暫定的な運用で始めてみるのが良いでしょう。

一般的なWebサービスの目安：最初のSLOとしては、99%から99.9%あたりで始めるのが良いでしょう。

既存データからの算出：もしSLI仕様に近いデータがすでに取得できるのであれば、現在の実績値に近い値を採用するのが一番簡単です。

開発速度からの見積もり：現在の開発チームの変更速度（デプロイ頻度、変更失敗率、平均修復時間）から、必要となるエラーバジェットを定量的に見積もる方法があります。

変更起因障害の予想時間 = デプロイ頻度 × 変更失敗率 × 平均修復時間。この予想時間から、必要なエラーバジェットを見積もることができます。

この見積もりは変更起因の障害のみを考慮しているため、ネットワーク障害やAWSなどの外部要因による障害の割合も考慮する必要があります。

SLIの選定：初期のSLIとしては、ロードバランサ（ALBなど）から取得できるHTTP 5xxエラー率や90%ile、99%ileのレスポンスタイムなど、比較的簡単に計測できるものが推奨されます。

3. SLO Docsの作成

SLOの定義、SLIの仕様、そしてそれらがなぜその値になったのか（特にデータがない場合はその根拠がないことも明記）を「SLO Docs」というドキュメントにまとめることが重要です。これは、ソフトウェア開発におけるデザインドキュメントのようなもので、今後の改善や見直しの際に経緯を知った上で取り組むために役立ちます。

SLO Docsには、SLIとSLOのリストの他に、以下の情報も含まれると良いでしょう: * サービスの概要 * サービス構成図 * 補足情報 * 次回の見直し時期（Revisit date）。

4. SLIの選択と実装

SLOはSLI（Service Level Indicator：サービスレベル指標）に基づいて設定されます。SLIはサービスの状態を推測できるものであることが好ましいです。

SLIの種類の選択：サービスの特性に合わせてSLIを選択します。一般的なサービスの種類とSLIの例としては以下のものがあります:

リクエスト駆動サービス（APIリクエストやブラウザアクセスなど）:

可用性 (Availability): レスポンスに成功したリクエストの比率。

レイテンシ (Latency): 閾値よりも高速に処理されたリクエストの比率。

品質 (Quality): デグレードしていない状態で返されたリクエストの比率。

パイプラインサービス（バッチ処理やストリーム処理など）:

新鮮さ (Freshness): データが特定の閾値よりも最近に更新された比率、または処理が完了するまでの時間。

正確性 (Correctness): 正しい値の出力につながった入力レコードの比率。

カバレッジ (Coverage): 時間ウィンドウ内に処理に成功した入力レコードの比率。

ストレージサービス（ログ、画像、動画など）:

耐久性 (Durability): 書き込まれたレコードのうち、正しく読み出せるものの比率。

SLI仕様と実装の分離：SLIの仕様（例：「500ミリ秒以下に応答できたリクエストの比率」）と、その実装（例：サーバーのアクセスログから計測、またはフロントエンドで計測）は分けて考えることが重要です。実装方法にはメリット・デメリットがあり、最初は実装しやすいものから始めるのが良いでしょう。

ユーザー視点の重視：ALBのメトリクスやログだけでは不十分な場合（特に非同期書き込み型サービスなど）、ユーザーが機能完了を期待する「エンドツーエンド」の可用性やレイテンシを計測することが重要です。例えば、動画投稿サービスなら「動画が共有できる状態になった」時点までの時間を計測するなどが考えられます。

可観測性（Observability）の向上：アプリケーションからメトリクスやログを適切に出力することで、より可観測性のあるWebサービスになります。これは、メトリクス、ログ、トレースを使い分けることで実現されます。

メトリクス：サービス全体の定量的な状態把握に利用され、アラート、SLI/SLO、キャパシティプランニングに適しています。

ログ：網羅性を重視した重要なイベントの記録に利用され、エラーやアクセス情報、セキュリティ、監査に適しています。

トレース：サンプリングされた詳細なイベントの記録に利用され、パフォーマンスチューニングやプロセス間の関係把握に適しています。

最初はメトリクスの強化に力を入れ、サービスが異常かどうかに気づけるようにすることが推奨されます。

5. SLOの調整と継続的な改善

SLOは一度決めたら終わりではなく、サービスの運用状況やビジネス目標の変化に応じて、定期的に見直し・調整が必要です。

データに基づく見直し：SLIを計測しデータを蓄積することで、定常的にSLOに基づいた運用や改善ができるようになります。SLOは高すぎると開発速度が下がり、低すぎるとユーザーの信頼を失う可能性があるため、適切なバランスを見つけることが重要です。

開発パフォーマンスとの関係：SLOを変更することはデプロイ頻度に大きな影響を与えます。例えば、SLOをわずか0.1%下げるだけでデプロイ回数が2倍になることもあります。このバランスをチームで議論し、定量的にコントロールしていくことがSREの実践につながります。

定期的な確認：SLIの推移やSLOは、スクラム開発のスプリントレビューなど、定期的にチームで振り返りを行う場で確認すると良いでしょう。

エラーバジェットポリシー：エラーバジェットを使い切った際の方針（エラーバジェットポリシー）も、SLOと同時に定義しておく必要があります。最初は厳密にデプロイを禁止しなくても良いですが、チーム内で合意が得られたら有効にすることを検討します。

SLOの運用はマラソンであり、詳細で複雑な理想を目指すのではなく、全体を捉える簡単なSLIから始めて、足りなくなったら設計・実装するというアジャイルなアプローチが推奨されます。

SLOの決定は、単なる技術的な数値設定ではなく、プロダクトとユーザー、そして開発・運用チームの間の複雑なバランスを管理するための重要なプロセスです。

もしよろしければ、次にSLIの実装例について深掘りしてみましょうか？例えば、異なるサービスタイプ（リクエスト駆動、パイプラインなど）でのSLIの実装方法について詳しく説明できます。

こちらも良い感じです！座学として最初にインプットする量としては十分だと思います。(というか一回の回答で出てくる量が多いので設定で調整したほうが良いかも?) このアウトプットを見て感じたのは、学習させたドキュメントのリンクは出してくれるのですが、学習元のドキュメントを書くときに参考にした文献の表示や引用が表示されない点が少し気になります。上記の回答では、SLIの種類の分類は Google SRE - Continuous Improvement To Get Reliability を参考に私が書いた文章になります。今回のように自分自身が学習元のドキュメントを把握している場合は大丈夫そうですが、学習元のドキュメントが大量になると、本来は引用で扱うべき文章や参考文献を示すべき内容が、生成された文章として扱われてしまい引用だと気づかない場合も出てきそうです。これらのNotebookLMなどを一般公開する際には気をつけないといけないポイントになりそうです。

他にも障害対応の仕方などもいい感じに出てくるのですが、全部書くとブログが長くなってしまうのでここまでにしておきます。
この2つの質問だけでもオンボーディングに活かせそう！という感じがしてくるのではないでしょうか。

あとがき

思った以上にオンボーディングに使えそうな出来栄えだったので、試してよかったなと思います。

IaCやAWSの設計といった技術的なことは結構オンボーディングがしやすいのですが、SLO設計や障害対応演習、チームにSREの文化を伝えていくにはどう進めるかといった点はオンボーディングがやりにくいな、伝わりにくいなと思っていたので、今後はこのNotebookLMを育てていってオンボーディングに活かしていきたいです。あとは、今までやってきた登壇などのアウトプット活動がそのまま活かせるのは非常に良いですね！はてなは会社でアウトプットを推進してきましたが、会社のブランディングや個人のキャリア形成だけではなく、こういった実務にも活かしやすくなったのは嬉しく思います。
実際にオンボーディングを実施したらそのレポートもしてみようと思いますのでお楽しみに!