エンジニア入門研修

用語解説

第17章 オブザーバビリティとSRE

リリース後のシステムを「感想」ではなく「観測データ」で説明するための用語を集める。 ログ、メトリクス、トレースで状態を見て、SLI/SLOで守りたい体験を測り、アラートとインシデント対応で運用を回す、という流れで読むとつながりやすい。

オブザーバビリティ

  • 読み：オブザーバビリティ（observability／可観測性）
  • 一言で言うと：システム内部の状態を、外へ出てくる情報から調べられる性質。
  • くわしく：本番ではコードをすぐに読み替えられない。だから、外から得られるログ、メトリクス、トレースを手がかりに「何が起きているか」を順に追える状態を先に作っておく。あらかじめ想定した異常だけでなく、まだ名前のついていない問題も調べられることを目指す。request、利用者行動、deploy、DB query、外部API呼び出しを結びつけられると、初めて起きた問題でも調査を始められる。観測できないシステムは直せない。
  • 具体例：支援ステータス一覧APIで「一覧取得が成功しているか」「十分な速さで返っているか」「権限外のデータを返していないか」を、外から見える情報だけで切り分けられる状態。
  • つまずきやすい点：監視（決めた異常に気づく仕組み）と混同しやすい。オブザーバビリティは気づいた問題を「調べられる」性質である。
  • 関連語：モニタリング（第17章）、テレメトリ（第17章）、SRE（第17章）
  • テキスト本文での登場箇所：第17章「リリース後のシステムは、観察できなければ直せない」

SRE

  • 読み：エスアールイー（Site Reliability Engineering）
  • 一言で言うと：利用者にとって大事な体験を、感覚ではなく指標、目標、手順、改善で守る考え方。
  • くわしく：信頼性を「気をつける」で終わらせず、SLIで測り、SLOで目標を置き、アラートで気づき、ポストモーテムで次の改善につなげる。大規模サービスだけの話ではない。新人が作る小さなWebアプリでも、何を出すか、どの遅さを問題とみなすか、障害後に何を直すかを説明できることが信頼性に直結する。Googleが体系化した考え方が広く参照される。
  • 具体例：支援ステータス一覧機能で「メンターが担当受講者の状態を見逃さず判断できる」という体験を、SLI/SLOやアラート、インシデントレビューで守る。
  • つまずきやすい点：特別なチームや大企業だけのものと思いがちだが、小さなアプリでも考え方は使える。
  • 関連語：SLI（第17章）、SLO（第17章）、ポストモーテム（第17章）、トイル（第17章）
  • テキスト本文での登場箇所：第17章（章導入）

モニタリング

  • 読み：モニタリング（monitoring／監視）
  • 一言で言うと：あらかじめ決めた指標や条件を継続的に見る活動。
  • くわしく：「5xx error rateが一定以上で通知」「p95 latencyが2秒超で調べる」「CPU使用率が高い状態が続いたら確認」のように、想定した異常に気づくための仕組みである。問題に気づくのが目的で、原因を深く調べるのはオブザーバビリティの役割になる。両者を混ぜると、アラートはあるのに原因が分からない状態になりやすい。
  • 具体例：支援ステータス一覧API（GET /api/mentor/learners）の5xx error rateを継続して見て、しきい値を超えたら通知する。
  • つまずきやすい点：監視があれば調査もできると思い込みやすい。気づく仕組みと調べる性質は別物である。
  • 関連語：オブザーバビリティ（第17章）、アラート（第17章）、メトリクス（第17章）
  • テキスト本文での登場箇所：第17章「リリース後のシステムは、観察できなければ直せない」

テレメトリ

  • 読み：テレメトリ（telemetry）
  • 一言で言うと：システムが外へ出す観測用データの総称。
  • くわしく：OpenTelemetryの文脈では、ログ、メトリクス、トレースを「テレメトリ信号（signals）」として扱う。これらを集めることで、外からシステムの状態を見られるようになる。観測設計とは、必要なテレメトリを増やす作業であると同時に、secretや個人情報など出してはいけないものを止める作業でもある。
  • 具体例：支援ステータス一覧APIが出すリクエストログ、latencyやerror rateのメトリクス、処理区間のトレースが、すべてテレメトリにあたる。
  • つまずきやすい点：多く出すほど良いわけではない。調査に使うものと、出してはいけないものを分ける。
  • 関連語：OpenTelemetry（第17章）、計装（第17章）、メトリクス（第17章）
  • テキスト本文での登場箇所：第17章「ログ、メトリクス、トレースは役割が違う」

OpenTelemetry

  • 読み：オープンテレメトリ（OpenTelemetry、略称OTel）
  • 一言で言うと：ログ、メトリクス、トレースを共通の形で扱うための業界標準のフレームワーク。
  • くわしく：観測データの作り方や送り方がツールごとにばらばらだと、計装をやり直すたびに負担が増える。OpenTelemetryは、テレメトリ信号（ログ、メトリクス、トレース）を統一的に扱う仕様とライブラリ群を提供し、特定の監視ツールに縛られにくくする。本章では細部には踏み込まないが、ログ・メトリクス・トレースを信号として並べて考える土台になっている。
  • 具体例：支援ステータス一覧APIのspanやtrace_idを、OpenTelemetryの考え方に沿って出すと、後でツールを変えても流れを追いやすい。
  • つまずきやすい点：特定の監視サービスそのものではなく、共通の規格・実装である点を取り違えやすい。
  • 関連語：テレメトリ（第17章）、トレース（第17章）、計装（第17章）
  • テキスト本文での登場箇所：第17章「ログ、メトリクス、トレースは役割が違う」

計装（instrumentation）

  • 読み：けいそう（instrumentation／インストルメンテーション）
  • 一言で言うと：アプリにログ・メトリクス・トレースを出すコードや設定を仕込むこと。
  • くわしく：観測データは自然には出てこない。どのrequestにrequest_idを付け、どの処理区間にspanとdurationを残し、どのメトリクスを記録するかを、あらかじめコードへ組み込む必要がある。最初から完全な分散トレーシングを入れなくてもよいが、ログにrequest_idを入れる、遅い処理にdurationを残す、といった最小の計装だけでも調査の質は大きく変わる。
  • 具体例：支援ステータス一覧APIのhandlerで、request_id・trace_id・duration_msを構造化ログへ出すよう仕込むのが計装である。
  • つまずきやすい点：「あとから入れればよい」と後回しにすると、問題が起きた時点でデータが残っていない。
  • 関連語：テレメトリ（第17章）、構造化ログ（第17章）、trace_id（第17章）
  • テキスト本文での登場箇所：第17章「ログ、メトリクス、トレースは役割が違う」「request_idとtrace_idで、点を線にする」

ログ

  • → 第5章（手元でアプリを動かし、ログを読む基礎）。本章では「構造化ログ」を新概念として詳説する。

構造化ログ

  • 読み：こうぞうかログ（structured log）
  • 一言で言うと：messageの文章だけでなく、検索・集計できるfieldを持たせたログ。
  • くわしく：日本語の文章だけのログは、人が目で探すには使えても、後で機械的に絞り込むのが難しい。endpoint、status、duration_ms のようなfieldを持つJSON形式などにしておくと、status>=500 や duration_ms>1000 といった条件で速く調査できる。CloudWatch Logs Insightsのようなツールでも、時間帯やfield、集計で調べやすくなる。あとで何を調べたいかを先に考えて、必要なfieldを設計するのがコツである。
  • 具体例：支援ステータス一覧APIで、timestamp・request_id・endpoint・status・duration_ms・result_count・image_tagをfieldとして持つログを出す。一方でpassword、token、個人情報は出さない。
  • つまずきやすい点：fieldを増やせばよいわけではない。調査に使うfieldと、出してはいけない情報を分ける。
  • 関連語：ログ（第5章）、CloudWatch Logs（第16章）、request_id（第17章）
  • テキスト本文での登場箇所：第17章「構造化ログは、あとで調べるための設計である」

メトリクス

  • 読み：メトリクス（metrics）
  • 一言で言うと：時間とともに変化する数値の推移。
  • くわしく：request数、error rate、latency、CPU使用率、memory使用率、DB connection数のように、数値を時系列で見る。全体傾向をつかむのに向いており、「今だけ遅いのか」「数日前から徐々に悪化したのか」「特定のdeploy後から変わったのか」を判断できる。数字そのものではなく、利用者体験の変化として読むことが大切である。
  • 具体例：支援ステータス一覧APIのrequest count、error rate、p95 latencyの推移をグラフで見て、deploy後に変わっていないかを確認する。
  • つまずきやすい点：平均値だけを見ると、一部の遅いrequestを見逃す。percentileも合わせて見る。
  • 関連語：ログ（第5章）、トレース（第17章）、Four Golden Signals（第17章）、percentile（第17章）
  • テキスト本文での登場箇所：第17章「ログ、メトリクス、トレースは役割が違う」

トレース

  • 読み：トレース（trace／distributed tracing）
  • 一言で言うと：一つの処理が通った道筋を、区間に分けて追う仕組み。
  • くわしく：Web requestがAPI handlerに入り、認可を確認し、DBを読み、外部APIを呼び、responseを返すまでを、spanという区間に分けて見る。複数のserviceにまたがってもtrace_idで一つの流れとして追える。「全体は2秒かかったが、そのうち1.6秒はDB queryだった」のように、遅さの場所を特定するのに役立つ。メトリクスやログだけでは分からない「request内のどこが遅いか」に答えられる。
  • 具体例：支援ステータス一覧APIのトレースを見て、全体のlatencyのうちDB queryと外部API呼び出しがそれぞれ何msかを切り分ける。
  • つまずきやすい点：単一serviceだから不要と考えがちだが、将来serviceが分かれたときに備えて早めに考えておくと役立つ。
  • 関連語：span（第17章）、trace_id（第17章）、latency（第17章）、X-Ray（第17章）
  • テキスト本文での登場箇所：第17章「ログ、メトリクス、トレースは役割が違う」

span

  • 読み：スパン（span）
  • 一言で言うと：トレースを構成する、一つの処理区間。
  • くわしく：トレースは複数のspanからできている。各spanは「DB query」「外部API呼び出し」「認可チェック」のように、処理のひとまとまりとその所要時間を表す。spanのdurationを見ると、request全体のどこに時間がかかったかが分かる。遅い処理区間にdurationを残しておくことが、後の調査を楽にする。
  • 具体例：支援ステータス一覧APIのトレースで、DB queryのspanが1.6秒、外部API呼び出しのspanが0.3秒、と区間ごとに時間を見られる。
  • つまずきやすい点：spanとtrace_idを混同しやすい。trace_idは流れ全体の識別子、spanはその中の各区間である。
  • 関連語：トレース（第17章）、trace_id（第17章）、latency（第17章）
  • テキスト本文での登場箇所：第17章「ログ、メトリクス、トレースは役割が違う」

request_id

  • 読み：リクエストアイディー（request id）
  • 一言で言うと：一つのHTTP requestを追うための識別子。
  • くわしく：利用者の一回の操作は、API入口、認可、DB query、外部API、responseのように複数のログに分かれる。これらに同じrequest_idを入れておくと、ばらばらの記録を一つのrequestとしてつなげられる。問い合わせが来たとき、時刻と画面だけでなくrequest_idが分かれば、該当ログへ速くたどり着ける。API入口で作成し、関係するログへ同じ値を入れるのが基本である。
  • 具体例：支援ステータス一覧APIで request_id: req_7f3a を入口で発行し、そのrequestに関わる全ログに同じ値を載せる。
  • つまずきやすい点：1リクエスト内のログをつなぐのがrequest_id、複数serviceをまたぐのがtrace_id、という役割の違いを混同しやすい。
  • 関連語：trace_id（第17章）、構造化ログ（第17章）
  • テキスト本文での登場箇所：第17章「request_idとtrace_idで、点を線にする」

trace_id

  • 読み：トレースアイディー（trace id）
  • 一言で言うと：処理全体を複数のserviceやspanにまたがって追うための識別子。
  • くわしく：trace_idは、一連の処理を一つの流れとして串刺しにする。今のアプリが単一serviceでも、Web app、API、worker、外部serviceが分かれたとき、trace_idがなければ流れを人間が目で推測することになる。ログにtrace_idを入れ、トレースと結びつけておくと、調査が線でつながる。
  • 具体例：支援ステータス一覧APIのログに trace_id: trace_91b2 を入れ、対応するトレースのspan群とひも付ける。
  • つまずきやすい点：単一serviceのうちは不要に見えるが、将来の分散構成に備えて早めに入れておく価値がある。
  • 関連語：トレース（第17章）、span（第17章）、request_id（第17章）
  • テキスト本文での登場箇所：第17章「request_idとtrace_idで、点を線にする」

latency

  • 読み：レイテンシ（latency／遅延）
  • 一言で言うと：requestが返るまでにかかる時間。
  • くわしく：利用者の「遅い」を数値にしたものがlatencyである。平均だけを見ると、一部の極端に遅いrequestを隠してしまうため、p50・p95・p99といったpercentileで分布を見る。Four Golden Signalsの一つで、対象のユーザー行動に結びつけて読む。「速くしました」ではなく「p95が2.4秒から620msに下がった」のように、数値で語れることが重要である。
  • 具体例：支援ステータス一覧API（GET /api/mentor/learners）が何msで返るかを、p50・p95・p99で見る。
  • つまずきやすい点：平均latencyだけを見ると、一部利用者の遅さを見逃す。percentileを併用する。
  • 関連語：percentile（第17章）、Four Golden Signals（第17章）、span（第17章）
  • テキスト本文での登場箇所：第17章「Four Golden Signalsを、ユーザー行動に結びつける」

error rate

  • 読み：エラーレート（error rate／エラー率）
  • 一言で言うと：requestのうち失敗した割合。
  • くわしく：4xxと5xxを区別して意味を読む。4xxは利用者の入力、認可、存在しないresourceなどで起きることがあり、5xxはサーバー側の失敗を示すことが多い。すべての4xxを障害扱いする必要はないが、認可ロジック変更後に403が急増したなら調査が必要である。数字そのものではなく、利用者体験の変化として読む。trafficが少ない時間帯は1件の失敗でも割合が大きく見えるので、最小request数と合わせて考える。
  • 具体例：支援ステータス一覧API（GET /api/mentor/learners）の5xx error rateが、deploy後に急増していないかを見る。
  • つまずきやすい点：trafficが少ないと1件の失敗で率が跳ね上がる。母数（request数）も一緒に見る。
  • 関連語：Four Golden Signals（第17章）、traffic（第17章）、アラート（第17章）
  • テキスト本文での登場箇所：第17章「Four Golden Signalsを、ユーザー行動に結びつける」

traffic

  • 読み：トラフィック（traffic／流量）
  • 一言で言うと：一定時間にどれだけrequestが来ているか。
  • くわしく：Four Golden Signalsの一つで、サービスがどれだけ使われているかを表す。普段との差を見るための基準にもなる。trafficが分かると、error rateやlatencyを正しく解釈できる。たとえば、trafficが少ない時間帯のerror rateは、わずかな失敗でも大きく見えるため、最小request数と合わせて判断する。
  • 具体例：支援ステータス一覧APIに一定時間あたり何request来ているかを見て、普段より急に増えていないかを確認する。
  • つまずきやすい点：他の信号と切り離して見がちだが、latencyやerror rateの解釈にtrafficの大小が効く。
  • 関連語：Four Golden Signals（第17章）、error rate（第17章）、saturation（第17章）
  • テキスト本文での登場箇所：第17章「Four Golden Signalsを、ユーザー行動に結びつける」

saturation

  • 読み：サチュレーション（saturation／飽和）
  • 一言で言うと：resourceが限界にどれだけ近いか。
  • くわしく：Four Golden Signalsの一つで、CPU、memory、DB connection、queue、外部API rate limitなどが限界に近づいていないかを見る。saturationが高いと、近いうちにlatency悪化やerror増加といった利用者影響につながりやすい。利用者影響に直結しない内部指標でも、resource枯渇のように先行して危険を示すものは、アラート対象になり得る。
  • 具体例：支援ステータス一覧APIの処理で、DB connectionやmemory、外部API rate limitが上限に近づいていないかを見る。
  • つまずきやすい点：今すぐの障害でなくても、放置すると利用者影響に変わる「予兆」として読む点を見落としやすい。
  • 関連語：Four Golden Signals（第17章）、メトリクス（第17章）、アラート（第17章）
  • テキスト本文での登場箇所：第17章「Four Golden Signalsを、ユーザー行動に結びつける」

Four Golden Signals

  • 読み：フォーゴールデンシグナルズ（Four Golden Signals／四つの黄金信号）
  • 一言で言うと：user-facing systemで見る基本的な四つの信号。latency、traffic、errors、saturation。
  • くわしく：Google SREで広く使われる、利用者向けシステムを見るときの出発点である。日本語では遅延・流量・エラー・飽和と考えるとよい。四つを暗記するだけでは使えない。対象のユーザー行動に結びつけて、何を成功とみなすかを決めて初めて実務に役立つ。ダッシュボードやSLOを考えるときの土台になる。
  • 具体例：支援ステータス一覧APIで、latency（何msで返るか）、traffic（何request来るか）、errors（4xx/5xxの数）、saturation（CPU/memory/DB connection）を、メンターの利用体験に沿って見る。
  • つまずきやすい点：四つの名前を覚えるだけで満足しがち。ユーザー行動に結びつけないと意味を持たない。
  • 関連語：latency（第17章）、traffic（第17章）、error rate（第17章）、saturation（第17章）、SLI（第17章）
  • テキスト本文での登場箇所：第17章「Four Golden Signalsを、ユーザー行動に結びつける」

percentile（p50 / p95 / p99）

  • 読み：パーセンタイル（percentile）。p50、p95、p99
  • 一言で言うと：データを小さい順に並べたとき、ある割合がその値以下に収まる境界値。
  • くわしく：p50は中央値、p95は95%のrequestがその値以下で終わる値、p99は99%のrequestがその値以下で終わる値である。平均は一部の極端に遅いrequestを隠すことがあるため、latencyのように分布が偏る指標はpercentileで見る。「多くの人は速いが一部だけ極端に遅い」という問題は、平均よりp95やp99で見つけやすい。
  • 具体例：支援ステータス一覧APIのlatencyをp50/p95/p99で見て、「p95が2.4秒から620msに下がった」のように改善前後を比較する。
  • つまずきやすい点：p99は「最悪値」ではなく「99%がそれ以下」の値である。残り1%はさらに遅いことがある。
  • 関連語：latency（第17章）、メトリクス（第17章）、SLI（第17章）
  • テキスト本文での登場箇所：第17章「Four Golden Signalsを、ユーザー行動に結びつける」

SLI

  • 読み：エスエルアイ（Service Level Indicator）
  • 一言で言うと：service levelを測るための指標。
  • くわしく：守りたい体験を「測れる数値」にしたものがSLIである。SLOという目標を立てる前に、まず何を測るかを決める。SLIは利用者の行動から選ぶ。「serviceが起動していること」は内部状態であって体験ではない。「一覧が1秒以内に表示され、権限外の情報が出ないこと」のほうが体験に近い。何を成功とみなし、何を除外するかを明示すると、レビュー可能な指標になる。
  • 具体例：支援ステータス一覧APIで「GET /api/mentor/learnersのうち、HTTP 2xxで成功し、server-side latencyが1000ms以下のrequest割合」をSLIとする。
  • つまずきやすい点：SLI（指標）とSLO（目標値）を混同しやすい。SLIは測るもの、SLOはその目標である。
  • 関連語：SLO（第17章）、SLA（第17章）、latency（第17章）、Four Golden Signals（第17章）
  • テキスト本文での登場箇所：第17章「SLIとSLOは、守りたい体験を測れる形にする道具である」

SLO

  • 読み：エスエルオー（Service Level Objective）
  • 一言で言うと：SLIについて守りたい信頼性の目標。
  • くわしく：SLIで測った指標に対して「これを満たし続けたい」という目標値が SLO である。利用者の行動から始め、サービス提供者の都合で決めない。完璧な数値を最初から当てることが目的ではなく、何を成功とみなし、どの時間窓で見て、何を除外し、測れていないものをどう扱うかを明示することで、レビュー可能な目標になる。アラートはSLOとつなげて考えると、人を起こす理由を説明しやすい。
  • 具体例：支援ステータス一覧APIで「直近7日間で、対象requestの99%がSLI条件（2xxかつlatency 1000ms以下）を満たす」をSLOとする。
  • つまずきやすい点：SLOを内部都合（serviceの起動）で決めがち。利用者が何をできればよいかからSLIを選ぶ。
  • 関連語：SLI（第17章）、SLA（第17章）、error budget（第17章）、アラート（第17章）
  • テキスト本文での登場箇所：第17章「SLIとSLOは、守りたい体験を測れる形にする道具である」

SLA

  • 読み：エスエルエー（Service Level Agreement）
  • 一言で言うと：契約や対外的な合意を含む、サービス水準の取り決め。
  • くわしく：SLAは、SLOに加えて「守れなかったときどうするか」という対外的な約束（返金や補償など）を含むことが多い。SLIで測り、SLOで内部目標を置き、SLAで対外合意を結ぶ、という関係で並べると整理しやすい。新人の段階では、まずSLIとSLOを自分の機能で説明できればよく、SLAは外部との契約が関わる発展概念として押さえておく。
  • 具体例：支援ステータス機能を外部へ提供する場合、「月間99.9%の可用性を保証し、下回れば補償する」のような対外的合意がSLAにあたる（本研修のSLO草案より厳しい約束になる）。
  • つまずきやすい点：SLOとSLAを同じものと思いがちだが、SLAは契約・対外合意を含み、より重い。
  • 関連語：SLI（第17章）、SLO（第17章）
  • テキスト本文での登場箇所：第17章「SLIとSLOは、守りたい体験を測れる形にする道具である」

error budget

  • 読み：エラーバジェット（error budget／エラー予算）
  • 一言で言うと：SLOで許容される「失敗してよい量」。
  • くわしく：SLOが「99%成功」なら、残りの1%が許容される失敗の枠＝error budgetである。100%を目指すと変更が一切できなくなるため、SREでは一定の失敗を予算として認め、その範囲で機能追加やリスクのある変更を進める考え方をとる。予算を使い切ったら、新機能より安定化を優先する、といった判断にも使える。本章では明示の用語としては深掘りしないが、SLOの裏側にある発想として押さえておくと、SLOやアラートの設計が理解しやすい。
  • 具体例：支援ステータス一覧APIのSLOが「7日間で99%成功」なら、残り1%がerror budget。これを使い切る勢いで失敗が増えたら、変更を止めて原因を直す判断につなげる。
  • つまずきやすい点：「失敗ゼロが理想」と思いがちだが、SREはあえて一定の失敗を許容枠として扱う。
  • 関連語：SLO（第17章）、トイル（第17章）、SRE（第17章）
  • テキスト本文での登場箇所：第17章「SLIとSLOは、守りたい体験を測れる形にする道具である」（SLOの考え方の発展）

トイル

  • 読み：トイル（toil）
  • 一言で言うと：手作業で繰り返され、価値を生みにくい運用作業。
  • くわしく：SREの文脈で、自動化できるのに毎回手で行っている繰り返し作業を toil と呼ぶ。toilが多いと、信頼性を高める本質的な改善に時間を使えなくなる。インシデントレビューのaction itemを「次に誰が何を変えるか」という作業へ落とし、ログfield追加やrunbook整備、テスト追加などで手作業を減らすことは、toilを減らす方向の取り組みといえる。本章では用語として深掘りしないが、SRE文化の背景概念として押さえておくとよい。
  • 具体例：支援ステータス機能の障害のたびに毎回手でログをかき集めている状態がtoil。request_idを入れて検索で追えるようにすれば減らせる。
  • つまずきやすい点：「忙しい＝働いている」と思いがちだが、繰り返しの手作業は減らすべき対象として扱う。
  • 関連語：SRE（第17章）、error budget（第17章）、ポストモーテム（第17章）
  • テキスト本文での登場箇所：第17章（SRE文化の背景概念）

ダッシュボード

  • 読み：ダッシュボード（dashboard）
  • 一言で言うと：見る人が次の判断をするための、指標をまとめた画面。
  • くわしく：ダッシュボードはグラフを並べる場所ではない。確認したい問いが違えば、必要なパネルも違う。開発者がdeploy直後に見るものと、運用担当がサービス状態を見るものでは中身が変わる。普段から見るものと、問題時に詳しく調べるものを分け、すべてを一枚に詰め込まない。最初の一枚は、利用者影響・直近変化・調査の入口に絞る。
  • 具体例：支援ステータス一覧用に、request count、error rate、p95 latency、saturation、recent errors、deploy markerを並べたダッシュボードを作る。
  • つまずきやすい点：情報を詰め込むほど良いと考えがち。詰め込みすぎると誰も読まなくなる。
  • 関連語：メトリクス（第17章）、アラート（第17章）、Four Golden Signals（第17章）
  • テキスト本文での登場箇所：第17章「ダッシュボードは、見る人の判断に合わせて作る」

アラート

  • 読み：アラート（alert／alarm）
  • 一言で言うと：人が対応すべき状態になったと知らせる通知。
  • くわしく：多ければ安心ではない。行動につながらない通知が頻発すると、やがて無視され、本当に重要な問題も見逃される。設計時は「利用者影響につながるか」「受けた人は何を確認・実行できるか」「どのくらい続いたら問題か」「一時的な揺れで鳴りすぎないか」「どのrunbookを見るか」を問う。条件は最小request数や時間窓と一緒に考え、SLOとつなげると鳴らす理由を説明しやすい。見るだけでよい情報はダッシュボードへ置く。
  • 具体例：支援ステータス一覧APIで「5xx error rate > 5% for 5 minutes（かつ最小request数を満たす）」を、対応手順とセットでアラートにする。
  • つまずきやすい点：アラートを増やせば安全と考えがち。行動できない通知はアラート疲れを生む。
  • 関連語：モニタリング（第17章）、SLO（第17章）、ダッシュボード（第17章）、runbook（第16章）
  • テキスト本文での登場箇所：第17章「アラートは、人を起こす理由を説明できるものだけにする」

インシデント

  • 読み：インシデント（incident）
  • 一言で言うと：利用者影響が出る、あるいは出かねない障害・問題の発生。
  • くわしく：インシデント対応の最初の目的は犯人探しではなく、影響の把握・縮小・復旧である。影響が続いている最中に全部を解明しようとすると対応が遅れる。「何が起きているか短く表す→誰にどの範囲で影響しているか→すぐ影響を下げる一時対応→観測データで復旧確認→事実のtimeline→恒久対応と再発防止」の順で進める。対応中のメモは、時刻・見たもの・判断・実行・結果を残すと、後の振り返りに使える。
  • 具体例：直近deploy後に支援ステータス一覧APIが5xxを返し始めたら、対象環境・endpoint・error rate・開始時刻・直近deploy・rollback可否を見て、まず影響を止める判断をする。
  • つまずきやすい点：原因究明を最優先にしがちだが、まず利用者影響を小さくする一時対応を選ぶ。
  • 関連語：ポストモーテム（第17章）、rollback（第16章）、runbook（第16章）、アラート（第17章）
  • テキスト本文での登場箇所：第17章「インシデント対応は、まず影響を小さくする」

ポストモーテム

  • 読み：ポストモーテム（postmortem）。インシデントレビューとも呼ぶ
  • 一言で言うと：障害を、責任追及ではなく次の改善へ変えるための振り返り文書。
  • くわしく：誰が悪かったかを決める文書ではない。何が起き、どの情報で気づき、どの判断をし、何が足りず、次に何を改善するかを残す。Google SREのポストモーテム文化でも、学習と再発防止が中心にある。事実（発生・検知・復旧時刻、影響範囲）→timeline→原因と再発防止、の順で書く。原因は一つとは限らず、コード不具合・テスト不足・SLO未定義・アラート不足・ログ不足・runbook不足が重なることがある。action itemは反省文ではなく、所有者と期限を持つ作業にする。
  • 具体例：stagingでdeploy後に一覧APIが5xxを返し、ログにrequest_idがなく調査に時間がかかった件を、timelineとaction item（ログfield追加など）付きで振り返る。
  • つまずきやすい点：反省会・犯人探しにしてしまいがち。事実・影響・原因・action itemへ落とす。
  • 関連語：インシデント（第17章）、SRE（第17章）、トイル（第17章）
  • テキスト本文での登場箇所：第17章「インシデントレビューは、責任追及ではなく次の設計である」

on-call

  • 読み：オンコール（on-call）
  • 一言で言うと：アラートが鳴ったとき、最初に対応する担当を決めておく当番体制。
  • くわしく：アラートは「人が行動すべき状態」を知らせるものなので、受け取って動く人がいて初めて機能する。誰が通知を受け、どのrunbookを見て、どう一時対応するかを決めておくのがon-callの役割である。研修では実名でなく担当ロールでもよいが、「このアラートで誰が動くか」を決めておくと、インシデント時に迷わない。アラート設計で「通知を受けた人は何を実行できるか」を問うのも、on-callを前提にした考え方である。
  • 具体例：支援ステータス一覧APIのhigh error rateアラートが鳴ったら、当番が最初にCloudWatch Logsを見て、rollback可否を判断する、と決めておく。
  • つまずきやすい点：アラート条件だけ決めて、誰が受けて動くかを決め忘れると、通知が放置される。
  • 関連語：アラート（第17章）、インシデント（第17章）、runbook（第16章）
  • テキスト本文での登場箇所：第17章「アラートは、人を起こす理由を説明できるものだけにする」（通知後に動く人を前提とする考え方）

CloudWatch Logs

  • → 第16章（AWS上のアプリやserviceのログを見る場所）。本章では、観測の入口として、時間帯・service・environment・revision・error種別を分けて見る観点を加える。CloudWatch Logs Insightsを使うと、構造化ログをfieldや集計で調査できる。

X-Ray

  • 読み：エックスレイ（AWS X-Ray）
  • 一言で言うと：AWSの分散トレーシング（トレース）サービス。
  • くわしく：App Runnerなどで動くアプリのrequestを、処理区間（span）に分けて追えるようにするAWSのトレーシング機能である。trace上のlatencyを見て、request内のどの処理が遅いかを切り分けるのに使う。本章では画面操作を暗記する対象にはしないが、CloudWatchのlogs/metrics/alarmsに加えて、tracesの入口としてX-Rayがあると押さえておくとよい。
  • 具体例：支援ステータス一覧APIのトレースをX-Rayで見て、DB queryのspanが全体latencyの大半を占めていることを確認する。
  • つまずきやすい点：ログ（CloudWatch Logs）やメトリクスとは別の信号（トレース）を扱うサービスである点を取り違えやすい。
  • 関連語：トレース（第17章）、span（第17章）、CloudWatch Logs（第16章）、latency（第17章）
  • テキスト本文での登場箇所：第17章「App RunnerとCloudWatchでは、何を見るかを決めてから開く」

N+1 query

  • 読み：エヌプラスワン クエリ（N+1 query）
  • 一言で言うと：一覧を取るときに、1回のqueryに加えて件数分のqueryを余分に発行してしまう、性能上のアンチパターン。
  • くわしく：一覧をまず1回のqueryで取り、その各行の関連データを1件ずつ別queryで取りに行くと、件数Nに対して合計N+1回のqueryになる。件数が増えるほどlatencyが膨らむ。多くはORMの書き方や設計で起き、まとめて取る（JOINや一括取得）ことで避けられる。
  • 具体例：支援ステータス一覧で、受講者ごとに担当メンターを1件ずつ取りに行くとN+1になる。request一回あたりのquery数を見て、急に多ければN+1を疑う。
  • つまずきやすい点：「遅い＝N+1」と決めつけない。ログ・トレース・DBのquery数・コード差分で、実際にN+1かを確かめてから直す。
  • 関連語：latency（第17章）、トレース（第17章）、ORM（第14章）、インデックス（第10章）
  • テキスト本文での登場箇所：第17章「遅いAPIを、感想ではなく証拠で調査する」

教材を検索