SRE

IoT システムや SaaS の提案書を書いていると、お客様から「このシステム、ちゃんと動くんですか?」と聞かれます。この質問にどう答えるか で、契約交渉の主導権が決まります。 「99.9% 動きます」と言い切れば SLA（契約）になり、下回ったら違約金。「目標値です」と言えば SLO（内部目標）で、未達でも返金義務はない。この 1 文字違いで法的拘束力が変わります。 本記事では、SRE（Site Reliability Engineering）業界で標準となっている SLI / SLO / SLA の 3 用語の 違いと使い分け を、提案書を書く立場から整理します。 3 用語の違い（要点） 略語 正式名 一言で 性格 SLI Service Level Indicator 計測する指標 データ SLO Service Level Objective 目指す目標 内部約束 SLA Service Level Agreement 契約上の保証 対外契約 順序は SLI → SLO → SLA で考えます。 SLI で「何を測るか」を決める（例: イベント検知から通知メール送信までの遅延時間） SLO で「目標値」を内部で握る（例: 95%ile が 60 秒以内） SLA で「契約条項」に格上げする（例: SLO 違反が月 3 件超えたら月額の 10% 返金） なぜ 3 つに分かれているのか Google SRE Book が提唱した「エラーバジェット」の考え方が背景にあります。 ...

前回の記事で「サーバー監視の王道スタック」として Prometheus + Loki + Grafana + Alloy を整理しました。アラート設計のセクションで触れた Grafana OnCall について、改めて単独で深掘りします。 ただし重要な注意点があります — Grafana OnCall OSS（grafana/oncall リポジトリ）は 2026 年 3 月 24 日にアーカイブされました。後継は **Grafana Cloud IRM（Incident Response Management）**で、OnCall と Incident の両アプリが 1 つに統合されています。 「Grafana OnCall を新規導入したい」「既存環境を移行すべきか」という人に向けて、何が終わって、何が始まったのかを整理します。 Grafana OnCall とは何だったのか Grafana OnCall は 「アラートが鳴った後の対応フロー」を管理するツールでした。 Prometheus / Loki / Grafana が「異常を検知する」までを担当 Grafana OnCall は「鳴ったアラートを誰に・どうやって届け、どう対応するか」を管理 PagerDuty や Opsgenie の OSS 互換ツールとして、Grafana エコシステムの中で重要なポジションを占めていました。 主な機能（当時） アラートの集約とルーティング — 複数の監視システムからのアラートを統合、内容に応じてチームへ振り分け オンコールシフト管理 — 担当者のカレンダー（シフト表）に従って当番者にだけ通知 エスカレーションポリシー — 一定時間応答がなければ次の担当者へ自動エスカレーション ChatOps 連携 — Slack / Telegram 上でアラート確認・対応開始（Acknowledge）・解決（Resolve）が完結 柔軟な通知手段 — Slack / Microsoft Teams / SMS / 自動音声通話（電話）/ モバイルプッシュ IaC 対応 — Terraform プロバイダで設定をコード管理可能 連携先（インテグレーション） カテゴリ 代表的な連携先 監視・アラート検知 Grafana, Prometheus (Alertmanager), Datadog, Zabbix, AWS CloudWatch, New Relic 通知・コミュニケーション Slack, Microsoft Teams, Telegram, SMS, 自動音声通話 OSS 版で自社サーバーに構築することも、Grafana Cloud のマネージドサービスとして利用することも可能でした。 ...

サーバー監視は「死活監視 + リソース監視」の時代から、「メトリクス + ログ + トレース」を 1 つの画面で相関分析するオブザーバビリティの時代に移りました。クラウドネイティブ環境では、Grafana Labs の OSS スタック（Prometheus + Loki + Grafana + Alloy）が、コスト・自由度・運用ノウハウの蓄積において事実上の王道になっています。 この記事では、なぜこの組み合わせが現代の標準なのか、各コンポーネントがどう役割分担しているのか、そして最小構成から本番運用までの全体像を整理します。 なぜこの構成が「王道」なのか サーバー監視の選択肢は大きく分けて 3 系統あります。 カテゴリ 代表例 特徴 OSS スタック（Grafana Labs） Prometheus + Loki + Grafana + Alloy 無料、自由度高、運用責任は自分で OSS スタック（Elastic） Elasticsearch + Logstash + Kibana + Beats 全文検索が強力、コストとリソース消費が大 SaaS Datadog、New Relic、Grafana Cloud 楽だが高価、データ主権がない このうち Prometheus + Loki + Grafana + Alloy が王道とされる理由: ...

2026年の今、Google のシニア SRE 面接に「LeetCode をひたすら解けば受かる」という時代は終わった。本記事は韓国エンジニアコミュニティでバズったツイートとその英語スレッドをもとに、2026年版の攻略ポイントをまとめたものだ。 元ツイートの要旨： “2026年には、アルゴリズムパズルよりも「5PB のデータを 10Gbps で転送したら 46 日かかる」をすぐに暗算できる物理的感覚がはるかに重要。図を描く前に暗算をして、障害時は原因分析より先にシステムを安定化させる習慣が身についていないといけない。コーディングテストも連結リストの逆転ではなく、限られたメモリで数十 GB のログを処理する実践的な問題に変わっている。” 1. NALSD ラウンドは「アーキテクチャ」ではなく「物理」 NALSD（Non-Abstract Large Systems Design）ラウンドで最も多い失敗は、まず図を描いてしまうことだ。 典型的な落とし穴： 問題: 「4 時間 SLA で 5PB クラスターの DR を設計してください」 NG 回答: きれいな active-passive 構成図を描く → 即アウト なぜ即アウトか： 1 2 3 4 5 PB = 5 × 10^15 bytes 10 Gbps = 10 × 10^9 bps = 1.25 × 10^9 bytes/sec 転送時間 = 5 × 10^15 / 1.25 × 10^9 = 4,000,000 秒 ≈ 46 日 これを暗算で弾ければ「この要件では 4 時間 SLA は物理的に不可能」とわかる。図を描く前に数字を出すのがシニア SRE の姿勢だ。 ...

概要 IC（Incident Commander）は修復作業をせず指揮・コーディネーションに専念。ポストモーテムは「非難のない文化」で仕組みの問題として捉える。MTTD/MTTA/MTTR を TTAssemble/TTInvestigate/TTFix に分解して改善ポイントを具体化。