SREとは
SRE（Site Reliability Engineering）とは、ソフトウェアエンジニアリングの原則と手法を運用に応用し、サイトの信頼性を制御する取り組みです。
🌾 ソフトウェアエンジニアリングとは？
ソフトウェアを「安定して・効率よく・継続的に」作り、改善し、運用していくための考え方や技術の総称です。
SREエンジニアが必要な理由
SREエンジニアが必要な一番の理由は、サービスを安定稼働させながら、開発スピードも落とさないためです。
SREの価値観
- 信頼性は機能の一部である
- 100%の信頼性を目指すわけではない
- 運用をエンジニアリングする
- データにもとづいて意思決定を行う
- 失敗から学び、非難なき文化を構築する
押さえておきたい用語
| 用語 | 意味 |
|---|---|
| SLA（Service Level Agreement） | サービス提供者と利用者の間で結ばれる合意事項 |
| SLO（Service Level Objective） | サービスの信頼性に関する具体的な目標値 |
| SLI（Service Level Indicator） | サービスの信頼性を測るための具体的な指標 |
| エラーバジェット | SLOに対して許容される失敗の範囲 |
SLO導入ステップ
-
クリティカルユーザージャーニーの特定
- ユーザー行動の分析
-
SLO目標値の設定
- SLIの決定
- SLO目標値の決定
-
組織的な合意・運用
- 体制の構築
- 役割の明確化
- 教育・浸透
-
継続的な改善
- 定期的な見直しと改善
クリティカルユーザージャーニーの特定手順
- ユーザーペルソナの作成：典型的なユーザーの特徴や行動パターンを定義する
- 主要な目標の特定：ユーザーがサービスを利用する主な目的を明確にする
- 操作の流れの洗い出し：目標達成までの一連の操作や体験を詳細に記述する
- クリティカルポイントの特定：ユーザー満足度に大きく影響する箇所を見つける
- 測定可能な指標への変換：特定したクリティカルポイントをSLIに変換する
モニタリングとオブザーバビリティ
| 用語 | 役割 | 例 |
|---|---|---|
| モニタリング | 異常の検知 | エラー数の増加、CPU使用率の高騰 |
| オブザーバビリティ | 原因の分析 | どのAPIか？どのメソッドか？ |
モニタリングの基本
モニタリングは、システムの状態を見守り、トラブルを未然に防ぐための手法です。代表的なフレームワークを3つ紹介します。
The Four Golden Signals（Google）
Googleが提唱したモニタリングの基本概念です。
| 指標 | 説明 | 具体例 |
|---|---|---|
| レイテンシー | リクエストの処理にかかった時間 | HTTPリクエストを受け取ってからレスポンスを返すまでの時間 |
| トラフィック | リクエスト数 | 単位時間あたりのリクエスト数 |
| エラー | システム内で発生するエラーの頻度や割合 | 5xxエラー、パフォーマンス要件を満たさないレスポンス |
| 飽和度 | システムリソースの許容量に対する限界 | CPU・メモリ・ストレージの使用率、メッセージキューの長さ |
USEメソッド（Linux）
インフラの健全性を効率的に監視・調査するためのフレームワークです。
| 指標 | 説明 | 具体例 |
|---|---|---|
| 使用率（Utilization） | リソースがビジー状態だった時間の割合 | CPUやメモリの使用率 |
| 飽和度（Saturation） | リソースの許容量の限界にどれだけ近いか | 処理待ちキューの長さ、メモリのswap使用率 |
| エラー（Errors） | システム内で発生するエラー数 | OSやコンテナが出力するエラーログ |
REDメソッド（Grafana Labs）
マイクロサービスの監視に適した手法です。
| 指標 | 説明 | 具体例 |
|---|---|---|
| レート（Rate） | 単位時間あたりのリクエスト数 | 特定ページへの1分あたりのリクエスト数 |
| エラー率（Errors） | 失敗したリクエストの割合 | APIリクエストにおける5xxエラーの割合 |
| 処理時間（Duration） | リクエストの処理にかかる時間 | 特定ページやAPIの平均応答時間 |
オブザーバビリティを高める取り組み（個人的な意見）
これまでの経験から、オブザーバビリティを高めるには次のステップが有効だと考えています。
-
網羅的に収集する
メトリクス・ログ・トレースなどのテレメトリデータを、REDメソッドなどのフレームワークを活用して収集する -
自動で集約する
異常発生時に、原因調査に必要なログやメトリクスなどの関連情報を自動的に収集・集約できる仕組みを構築する -
AIで分析する
収集したデータをAIで分析し、異常検知・原因特定・対応方法の提案につなげる
ポストモーテムを行う
ポストモーテムとは、システム障害や重大なインシデントが発生したあとに、その原因・影響・対応プロセスを振り返って学びを得るための分析プロセス、およびその記録のことです。
ポストモーテムのフレームワーク
-
目的の明確化
目的は責任追及ではなく、今後の改善策を導き出すことです。 -
必要なデータの収集
インシデント発生時のログやモニタリング情報を収集します。 -
チームの招集
インシデントに関与したすべての関係者を集めます。 -
タイムラインの作成
インシデント発生から復旧までの流れを時系列で整理し、どのタイミングで何が起きたのかを振り返ります。 -
原因分析
ポストモーテムで最も重要な部分です。直接原因を明確にします。（例：テストケースの不足、設定ミス） -
影響の評価
障害によるシステムへの影響とビジネスへの影響を洗い出します。 -
再発防止策の検討
特定した原因について、再発を防ぐための具体的な改善策を検討します。 -
アクションアイテムの定義
再発防止策を具体的な作業に落とし込み、担当者と期限を設定します。 -
ドキュメントへの記録
ポストモーテムで議論した内容はすべて記録します。 -
チーム内での共有
ドキュメントをチーム全員に共有します。不明点があれば振り返りを行い、チーム全体で学びを共有します。 -
定期的なレビュー
ポストモーテムは一度で終わりにせず、定期的にレビュー・振り返りを行います。 -
必要に応じた外部共有
顧客やステークホルダーへの透明性を確保するため、外部向けのポストモーテムも作成・公開します。