SRE顧問とは、Webサービスの信頼性と運用の改善について、継続的に相談できる外部の技術者です。この記事では、現状の課題を調べ、改善の優先順位や実装方針を一緒に決める契約形態を指します。実装や障害対応をどこまで担当するかは、個々の契約で決まります。

脆弱性が公表されるたびに担当者を探す、更新が止まる、障害時に確認すべきログが分からない。こうした運用を、担当者、手順、コード、監視の設定として残していくことが相談の対象になります。

SREはサービスを安定して変更するための仕事

SREはSite Reliability Engineeringの略です。GoogleのSRE書籍では、ソフトウェア工学の手法を運用へ適用する考え方が説明されています。監視、変更管理、障害対応、性能や容量の管理などを扱います。

動いているシステムを維持しながら、機能追加や更新も続ける必要があります。その判断の基準となるのが、利用者にとっての品質です。サーバーのCPU使用率だけでなく、注文を完了できるか、画面が十分な速さで返るかといった業務の結果から考えます。

SLI・SLO・エラーバジェットの関係

SLIは実際に測る品質の指標、SLOはその目標です。たとえば「計測対象のリクエストの成功率」をSLIとし、「直近30日で99.9%以上」をSLOと置きます。この値は説明用の例で、全サービスに一律で当てはめるものではありません。

対象リクエストが100万件なら、99.9%の目標に対する失敗の許容量は1,000件です。このような許容分をエラーバジェットと呼び、変更を進めるか、安定性の改善へ力を割くかの判断に使います。リクエスト成功率から計算した値を、そのまま許容停止時間に置き換えることはできません。

出典：Google SRE「Service Level Objectives」、「Embracing Risk」。対象、計測方法、除外条件も決めて初めて、目標値が判断に使えます。契約上の保証や違反時の取り扱いを定めるSLAとは区別します。

SRE顧問に相談できることと手元に残るもの

GitHub依存関係の更新Prometheusメトリクスの監視OpenTelemetry計測データの収集

本文で扱う技術の例です。ロゴは各技術の識別に使用し、公式サイトへリンクしています。提供元との提携・認定を示すものではありません。

以下は依頼範囲を考えるための例です。すべてが月額契約に含まれるという意味ではありません。提案資料を受け取るだけか、リポジトリや監視設定の変更まで行うかで、必要な体制が変わります。

相談テーマ作業の例残す成果物の例
構成と依存関係公開環境、データの流れ、更新対象を整理構成図、管理台帳、改善タスク
監視・通知利用者への影響を測り、対応できる通知に絞るSLI/SLO、ダッシュボード、通知先と対応手順
デプロイテスト、承認、反映、失敗時の判断を整えるCI/CD設定、リリース・復旧手順
権限と更新IAM、依存ライブラリ、秘密情報の扱いを見直す権限設計、更新ルール、例外と期限の記録
障害への備え連絡体制、切り分け、復旧を確認する当番・連絡先、手順書、振り返りと再発防止タスク
コストと容量利用量と費用の関係を調べる計測方法、予算アラート、変更案

Prometheusはメトリクスの監視、OpenTelemetryはトレースやメトリクス、ログなどの計測データを扱う技術の例です。製品を導入するだけで運用は完成しません。誰が通知を受け、何を確認して、どこへ連絡するかまで決めます。

Googleの監視に関する章は、応答時間、トラフィック、エラー、飽和度の4つを基本的な指標として扱います。平均値では一部の遅い処理が見えにくいため、利用者の体験に合う計測を選びます。

セキュリティ対策とSREが重なるところ

php2shellへの対応のような緊急の更新を、止めてよい時間や検証方法が分からないために適用できない。ここには脆弱性の知識と、サービスを安全に変更する運用の両方が必要です。

ライブラリを更新できるデプロイ経路、必要な操作に限定されたIAM、退職者のアクセス停止、監査ログ、復旧手順は、セキュリティと信頼性に共通する土台です。Webサービス事業者が行う技術的な対策で具体的な確認項目を整理しています。

一方、侵入の有無を調べる専門的なフォレンジックや脆弱性診断、法令上の判断まで、SREという名称で引き受けるとは限りません。情報漏洩時の対応を参考に、緊急時に呼ぶ専門家と、平時の運用担当を決めておきます。

保守会社・社内担当と役割をどう分けるか

名称だけでは決まりません。

保守会社が改善設計まで担当する場合も、SRE顧問が助言だけを行う場合もあります。比較するのは「誰が何をするか」です。

判断・作業契約や運用で確認すること
改善の優先順位事業上の影響を誰と評価し、誰が決めるか
本番環境の変更顧問・社内・開発会社の誰が実行し、誰が承認するか
障害の一次対応通知を受ける人、対応時間、応答の目安、代替担当は誰か
専門調査・報告調査会社や法務との連携を誰が担うか
契約終了設定・手順・コードを引き継ぎ、アクセスをいつ取り消すか

社内には、事業の優先順位と本番変更を承認する責任者が必要です。顧問への依頼で、その役割まで自動的に移るわけではありません。

最初の取り組みは一つの運用で成果を確かめる

最初から監視や基盤を全面的に入れ替える必要はありません。たとえば、依存関係の更新が止まっているなら、対象を一つ選び、通知から検証・反映・記録まで通して確認します。

現状を確認

構成、権限、過去の障害を調べる

対象を決定

業務への影響で優先順位を決める

運用を改善

設定・コード・手順として残す

結果を確認

担当者が実行できるか試す

Fig. 01 — 顧問と取り組む進め方の例。期間と作業範囲はシステムの状態に応じて決めます。

評価には、未対応の更新件数と滞留日数、手動で行うデプロイ操作、復旧訓練の結果、対応につながらない通知の数などを使えます。導入したツールの数より、困っていた作業がどう変わったかを見ます。

反復する手作業を減らす考え方は、Google SREのtoilの説明に整理されています。障害後は、ポストモーテムで影響や原因、復旧までの対応を振り返り、改善の担当者と期限を決めます。

wrenの自社運用と、SRE顧問で扱うこと

wrenは、ad-cre.aiやKokage.aiを開発・運営し、自社でも日々ライブラリのバージョン管理と技術的な防御を行っています。コーポレートサイトではlockfileによる依存関係の管理、CIでの固定した依存関係のインストール、フォーム入力のサーバー側検証、セキュリティヘッダーの設定を実施しています。

自分たちでもコードや設定を管理する立場から、手順を決めることと、実際に動く状態を確認することを扱います。自社サイトで確認した実装は、セキュリティ対策の記事に掲載しています。

当社の受託開発・SRE顧問の対応領域では、インフラの構成のコード化、デプロイの自動化、アラートと障害対応の手順づくり、AIの費用の見える化を扱っています。SRE・EMの採用要件や面接についても相談を受け付けています。

料金や関わり方は、対象システム、社内の体制、助言と実装の範囲を伺ったうえで決めます。24時間の緊急対応や専門的なセキュリティ調査を標準で含むと考えず、必要な体制を確認してください。

SRE顧問の相談フォームには、サービスの概要、現在の困りごと、社内で担当できる範囲を記載してください。関わり方の案をメールでお返しします。初回の連絡に認証情報や顧客データを添付する必要はありません。