一覧SE-10-3 · 開発の可視化と運用接続

SLOとインシデント後の改善

同じ定義でSLIと許容失敗件数を計算し、短期の悪化と月全体の予算、改善計画と改善の実証をそれぞれ説明します。

説明

SLIはサービスの状態を測る指標、SLOはその目標です。ここでは有効なAPI要求のうち5xxを返さず完了した割合をSLIとし、暦月で99.9%以上を目標とします。目標を満たす範囲の失敗件数をエラーバジェットとして扱います。

11月の途中までの集計、直近1時間、その後の障害を順に追加します。集計期間と分母を確認して予算を計算し、機能追加を保留する判断、障害後の担当・期限・確認条件へつなげます。割合を計算するだけで終えず、次に何を確かめるかまで整理します。

同じ定義でSLIと許容失敗件数を計算し、短期の悪化と月全体の予算、改善計画と改善の実証をそれぞれ説明します。

1数える要求と成功の条件

definition.txtで分母、成功条件、期間、予算を超えたときの方針を確認します。

cat definition.txtSLI・SLO・運用方針の定義を読む

無効入力は集計対象外で、再試行は別の要求として数えます。成功件数を全要求件数で割る前に、何を一件とするかを固定します。遅延についての目標は、この成功率だけでは評価できません。

2月の途中までの予算

counts.csvは同じ月の重複しない二つの期間です。直近1時間も月全体の件数に含めて計算します。

cat counts.csv期間ごとの件数を確認する python3 budget.py月の途中までのSLIと予算を計算する

要求100000、失敗80、成功99920でSLIは99.92%です。失敗率の上限0.1%に対応する許容失敗は100件、残り20件です。月の途中の分母による値なので、月末までの固定枠ではありません。

3直近一時間の悪化

直近1時間だけを取り出し、失敗率を許容割合0.1%で割ります。この比をバーンレートと呼びます。

python3 budget.py --recent直近1時間の失敗割合とバーンレートを計算する

10000件中40件の失敗で失敗率0.4%、バーンレートは4です。月全体のSLIは目標内でも、最近の失敗割合は許容割合の4倍です。要求量や今後の推移を仮定せずに、残り時間へ換算することはできません。

4次の五分間に起きた障害を加える

同じ月に続いた5分間では50件すべてが失敗しました。その分を加えて再集計します。

cat incident.csv追加する期間と失敗件数を読む python3 budget.py --include-incident障害期間を含めて予算を再計算する

要求100050、失敗130でSLIは99.87006%です。許容失敗はfloor(100050×0.001)=100件、残りは−30件。この教材で決めた方針では、機能追加のリリースを保留して信頼性改善を優先します。

5障害の記録から改善対象を絞る

調査記録を読み、観測した事象、確認した不具合、まだ調べる点を確認します。

cat incident.txt事象・確認した不具合・未確定の原因を読む

要求全体の期限がDB接続待ちに適用されていなかった点と、待機自体が増えた原因は別です。期限の適用と待機の調査を分けて、何を直したときに何が変わるべきかを決めます。

6担当と期限だけでは完了を判定できない

改善計画の各行には、担当、期限、確認条件、状態があります。空欄を調べます。

cat actions.csv改善項目の担当・期限・確認条件を読む python3 review_actions.py確認に必要な欄の欠落を調べる

A1の「DBを改善する」には確認条件がありません。A2とA3には、期限切れの応答と同じtrace_idでの照合という確認条件があります。項目が埋まっていること自体は、対策の有効性の証明ではありません。

7何が変われば完了かを具体化する

A1を、注文一覧をJOINで取得し、同じ9注文の結果を保ったままSELECTを10回から1回へ減らす計画に改めます。

cp actions-fixed.csv actions.csv対象と確認条件を具体化した案へ替える python3 review_actions.py欄と計画状態を再確認する

欠落欄はなくなりましたが、全項目の状態はplannedです。SQL回数を減らす案が今回の待機に有効かは、再現条件で検証する必要があります。文章を整えただけで対策完了にはなりません。

8計画を書いてもサービスの実績は変わらない

障害を含む同じ要求記録でSLIを計算します。

python3 budget.py --include-incident改善計画とは別に要求実績を再集計する

失敗130件と予算超過30件は変わりません。対策を適用して確認条件を満たし、その後の要求記録で改善を確かめる工程が必要です。計画の記入、対策の検証、SLOの達成は別々に追跡します。

まとめ

成功率は対象要求・成功条件・期間を決めてから計算します。

月全体の予算と直近のバーンレートは、異なる期間の状態を示します。

障害後の作業には担当・期限・確認条件を付け、計画と実際の改善を別々に確認します。

操作履歴と解説を振り返れます。

シェル / Python 3

1
cat definition.txt
対象: 11月に正しく受け付けたAPI要求の試行。入力誤りで拒否した要求は分母から除外済み。
良い要求: 5xxを返さず完了した対象要求。
SLI: 良い要求数 / 対象要求数。再試行も別の要求試行として数える。
SLO: この月のSLIを99.9%以上にする。
許容する失敗数: floor(対象要求数 × 0.001)。
運用ルール例: 予算を超えたら機能追加の公開を保留し、信頼性の回復と原因調査を優先する。
2
cat counts.csv python3 budget.py
window,requests,bad
earlier_november,90000,40
last_hour,10000,40
requests=100000 good=99920 bad=80 SLI=99.92000%
allowed_bad=100 remaining=20
release_policy=within current budget
3
python3 budget.py --recent
requests=10000 good=9960 bad=40 SLI=99.60000%
bad_rate=0.40000% burn_rate=4
4
cat incident.csv python3 budget.py --include-incident
window,requests,bad
next_five_minutes,50,50
requests=100050 good=99920 bad=130 SLI=99.87006%
allowed_bad=100 remaining=-30
release_policy=hold feature releases
5
cat incident.txt
観測: 次の5分間の対象50要求がすべて5xxで終了した。
固定の調査記録: DB接続待ちの間、要求全体の期限が適用されていなかった。
未確認: 接続待ちが増えた最初の原因。SQL・負荷・接続上限を追加調査する。
改善を二つに分ける: 期限の適用を修正すること、待機増加の原因を調べるため観測を補うこと。
成功条件: 次の再現試験で応答契約と相関記録を確認する。欠陥修正だけでSLO全体の回復を保証しない。
6
cat actions.csv python3 review_actions.py
id,action,owner,due,verification,status
A1,DBを改善する,DB担当,2026-12-05,,planned
A2,待機中にも要求全体の期限を適用する,API担当,2026-12-03,再現負荷で期限切れを504として返し成功扱いしない,planned
A3,待機時間とタイムアウトを同じtrace_idで記録する,運用担当,2026-12-03,一要求の待機開始と期限切れを同じIDで照合できる,planned
A1 status=planned missing=verification
A2 status=planned missing=none
A3 status=planned missing=none
7
cp actions-fixed.csv actions.csv python3 review_actions.py
A1 status=planned missing=none
A2 status=planned missing=none
A3 status=planned missing=none
8
python3 budget.py --include-incident
requests=100050 good=99920 bad=130 SLI=99.87006%
allowed_bad=100 remaining=-30
release_policy=hold feature releases

演習完了