L47:運用監視(Monitoring)+インシデント対応(Incident Response)+ポストモーテム(振り返り)+改善バックログ(TRAINING ONLY/流用禁止)
【重要:本レッスンは訓練専用】
- このレッスンで作る「監視設計」「アラート条件」「対応Runbook」「告知文(ダミー)」「ポストモーテム」「改善バックログ」等は訓練専用です。通常業務でそのまま使用することは禁止します(コピペ流用禁止)。
- 実サイト更新・実公開・実リポジトリ反映は禁止:本番環境/実CMS/実タグ/実URLには触れません(ローカル・ダミーのみ)。
- 実データ・個人情報・未公開情報は禁止(実案件名、実ページID、実在の条件/取引先/素材などは書かない)。
- 本番で必要になった場合は、訓練成果物を流用せず、情報を取り直し、別途レビュー/承認を経て新規作成してください。
L46で「変更管理/Go/No-Go/ロールバック/引継ぎ」を作ったら、次は“出した後に壊れた時の設計”です。
運用は「頑張って気づく」ではなく、監視(検知)→判断(Severity)→対応(Runbook)→記録(ポストモーテム)→改善(バックログ)で回します。
本レッスンでは、L44のログ(requestId等)やL45のQA観点を材料に、再現可能な訓練インシデントを作り、対応〜振り返りまでを型に落とします。
このページの使い方
1レッスン=1LP(1ページ)です。上から順に当日の時間割に沿って進めてください。
各項目の冒頭に EC事業部/文房具カフェ事業部・準備室 の実施時間を併記しています。
※本レッスンはダミーのみで行います(実データ・個人情報・未公開情報は入力しない)。
このレッスンの狙い(到達状態)
- 監視を「ログを眺める」ではなく、SLI(測る指標)+しきい値として定義できる
- アラートを「全部鳴らす」ではなく、Severity(重要度)で整理できる
- インシデント対応を、Runbook(手順・判断・記録)として書ける
- ロールバック判断を、トリガー→復帰確認(TC)で説明できる
- ポストモーテムを、再発防止の改善バックログにつなげられる
受講ルール(共通)
- 実データ禁止:実URL、実ページID、実アカウント、実顧客情報、未公開企画などは禁止
- 訓練成果物の流用禁止:訓練で作った監視/Runbook/告知/振り返りを通常業務へコピペしない
- 通常業務をしない:訓練日は講義・演習・レビュー・理解度確認に専念する
- 命令系統の具体化をしない:役割は「運用担当」「対応担当」「レビュー担当」「承認担当」など抽象ロール
- 相互レビュー2件以上:前日までの他者成果物に2件以上コメント(本ページの観点を使用)
今日の目標(できた範囲でOK)
受講者のレベル差があるため、強制の提出物は設けません。今日の目標を選び、できた範囲を「今日進めたこと」に記録してください。
- (A)TRN-OPS47 監視Specヘッダ(v0.1):対象/SLI/しきい値/観測ポイント
- (B)アラート設計(v0.1):最低5本(Severity付き)
- (C)インシデントRunbook(v0.1):最低1本(手順表)
- (D)ポストモーテム(v0.1):最低1件(訓練インシデントでOK)
- (E)改善バックログ(v0.1):最低5件(再発防止の粒度)
結論:運用は「検知→判断→対応→記録→改善」で回す
運用が壊れる典型
- 気づけない:異常が起きているのに検知できない(指標がない)
- 鳴りすぎる:アラートが多すぎて無視される(重要度がない)
- 迷う:誰が何をするか決まっておらず対応が遅れる(Runbookがない)
- 繰り返す:直した気になって、原因・再発防止が残らない(ポストモーテムがない)
今日の最小ルール(これだけは揃える)
- SLI:何を測るか(例:error率、timeout率、復帰成功率)
- しきい値:いつ異常扱いか(例:3分でerror>=3回 など)
- Severity:S1〜S4で優先度を決める
- Runbook:最初の10分でやることを固定する
- ポストモーテム:再発防止に落とす(改善バックログ)
標準テンプレ(TRAINING ONLY)
A) TRN-OPS47 監視Specヘッダ(v0.1)
【TRN-OPS47 監視Specヘッダ(v0.1:訓練専用・流用禁止)】
Spec-ID:TRN-OPS47
版:v0.1
状態:DRAFT / REVIEW / FINAL(訓練内)
対象(ダミー):
* 例:TRN-JS44(擬似API+requestId+cancel+retry+ログ)
* 例:TRN-JS43(フォーム送信:loading/success/error)
目的(1行):
* 例:異常を再現可能に検知し、対応→振り返り→改善へつなぐ練習をする
範囲(やる/やらない):
* やる:SLI定義、アラート設計、Runbook、ポストモーテム、改善バックログ(ダミー)
* やらない:実運用監視、実アラート設定、実顧客への告知、実公開反映
想定状態(enum:使うものに○):
* idle / loading / success / empty / error / timeout / canceled
観測ポイント(何を見れば分かる?):
* ログイベント名(例:FETCH_START / FETCH_OK / FETCH_FAIL / FETCH_CANCEL / FETCH_IGNORED)
* requestId(世代)
* 状態遷移(from→to)
* 条件(category/failSwitch/slowSwitch等:ダミー)
SLI(測る指標:最大3つ):
* SLI1:
定義:
測り方(ログの数え方でOK):
しきい値:
* SLI2:
* SLI3:
Severity(S1〜S4:訓練用):
* S1:作業停止レベル(復帰不能/ロールバック検討)
* S2:重大(影響大・短時間で悪化)
* S3:中(限定影響・回避あり)
* S4:低(軽微・改善候補)
完了条件(採点可能):
* SLIとしきい値が具体(曖昧語なし)
* アラートがSeverity付きで最低5本
* Runbookが最初の10分で迷わない粒度
* ポストモーテムが再発防止(バックログ)に落ちている
* 訓練専用の明記がある/実データ混入なし
B) シグナル定義(ログ/メトリクス:v0.1)
| Sig-ID | 種類 | 定義(何を数える?) | 収集(訓練) | 関連状態 | しきい値(例) | 対応 |
|---|---|---|---|---|---|---|
| SIG-01 | ログ | FETCH_FAILの回数 | logBox(訓練) | error/timeout | 3分で3回以上 | AL-01発火→Runbookへ |
| SIG-02 | ログ | timeoutの回数(messageにtimeout含む等) | logBox(訓練) | timeout | 5分で2回以上 | AL-02発火→条件確認 |
| SIG-03 | ログ | FETCH_STARTの増殖(連打) | logBox(訓練) | loading | 1操作で2回以上 | AL-03(ガード不足) |
| SIG-04 | ログ | FETCH_IGNOREDの比率(競合が多い) | logBox(訓練) | loading/success | 10回中5回以上 | AL-04(UX/導線見直し) |
| SIG-05 | メトリクス(擬似) | 復帰成功率(error/timeout→retry→success) | TC結果(訓練) | error/timeout | 80%未満 | AL-05(復帰導線改善) |
C) アラート設計(v0.1:最低5本)
| AL-ID | Severity | 条件(しきい値) | 検知(根拠) | 一次対応(最初の10分) | エスカレーション(抽象) | 記録 |
|---|---|---|---|---|---|---|
| AL-01 | S2 | FETCH_FAILが3分で3回以上 | SIG-01 | Runbook-01を開始(条件/ログ確認→復帰導線) | 運用担当→レビュー担当 | INC-xxに記録 |
| AL-02 | S2 | timeoutが5分で2回以上 | SIG-02 | 遅延条件(slow)確認→timeout設定見直し案 | 運用担当→承認担当 | INC-xxに記録 |
| AL-03 | S1 | 二重実行(1操作でFETCH_STARTが2回以上) | SIG-03 | 操作停止(loadingガード確認)→No-Go/ロールバック検討 | 対応担当→承認担当 | RB-xx紐づけ |
| AL-04 | S3 | IGNORED比率が10回中5回以上 | SIG-04 | 導線/操作回数を棚卸し→UX改善バックログへ | 対応担当→レビュー担当 | PM(振り返り) |
| AL-05 | S3 | 復帰成功率が80%未満 | SIG-05 | 復帰導線(retry/reset)の仕様確認→TC追加 | 対応担当→レビュー担当 | Backlog追加 |
D) インシデントRunbook(v0.1:手順表)
※「最初の10分」で迷わないように、入力/出力/チェックまで書きます。
| Step | 作業 | 担当(抽象) | 入力(Input) | 出力(Output) | チェック(品質) | 所要目安 | メモ |
|---|---|---|---|---|---|---|---|
| 1 | インシデントIDを発行し、状況を1行で固定する | 運用担当 | AL-ID/観測ログ | INC-xx概要 | 再現条件(固定)が書かれている | 3分 | 推測で断定しない |
| 2 | Severityを仮決めし、優先順位を固定する | 運用担当 | AL条件/影響(ダミー) | S1〜S4 | 基準と一致している | 2分 | 迷ったら高めに置く |
| 3 | 再現条件で再現する(成功/失敗を固定) | 対応担当 | 条件(fail/slow/category等) | 再現手順 | 第三者が再現できる粒度 | 5分 | ランダム禁止 |
| 4 | ログ抜粋(3〜8行)を取る | 対応担当 | logBox | 証跡 | 時刻/イベント/requestId/状態/条件が読める | 3分 | 根拠を先に確保 |
| 5 | 一次対応(止血)を実施する(復帰導線/操作停止) | 対応担当 | Runbook/仕様 | 復帰/停止 | ユーザーが戻れる導線がある(訓練) | 10分 | ロールバック検討条件を確認 |
| 6 | ロールバック要否を判断する(Go/No-Go/要相談) | 承認担当 | TC結果/ログ/RB計画 | 判断(ダミー) | 根拠が残る | 5分 | 戻すなら復帰TCも指定 |
| 7 | ポストモーテム作成→改善バックログへ落とす | レビュー担当 | INC記録/差分 | PM+Backlog | 再発防止の行動が書けている | 20分 | 責めない。改善する。 |
E) インシデント記録テンプレ(INC:v0.1)
【TRN-OPS47 インシデント記録(INC:v0.1:訓練専用・流用禁止)】
INC-ID:
発生日時(訓練):
対象(Spec-ID):
検知(AL-ID):
Severity(S1〜S4):
1. 概要(1行):
*
2. 再現条件(固定):
*
3. 再現手順(番号):
1)
2)
3)
4. 期待結果:
*
5. 実際結果:
*
6. 根拠(ログ抜粋:3〜8行):
*
7. 一次対応(止血):
*
8. ロールバック判断(ダミー):
* Go / No-Go / 要相談
根拠(TC/ログ/RB):
*
9. 次アクション:
-
F) 告知・連絡テンプレ(ダミー/断定禁止)
※実顧客向けに送らない。訓練用に「構造だけ」練習します。
【TRN-OPS47 連絡文(初報:ダミー)】
件名:【訓練】UI不具合の可能性(調査中)
本文:
現在、(ダミー対象)において不具合の可能性を検知しました。
事象:____(断定しない)
影響:____(範囲を限定して書く/不明はUNKNOWN)
対応状況:調査中(次回更新予定:___)
再現条件(ダミー):___
備考:本連絡は訓練用です(流用禁止)。
【TRN-OPS47 連絡文(経過:ダミー)】
件名:【訓練】UI不具合(経過報告)
本文:
状況:____(state/ログ根拠)
対応:____(一次対応/回避策:ダミー)
次の更新:___
備考:推測は断定しない(UNKNOWNはUNKNOWNと書く)。
【TRN-OPS47 連絡文(終報:ダミー)】
件名:【訓練】UI不具合(復旧)
本文:
復旧:____(完了条件:TC-ID)
原因:____(断定は根拠がある範囲まで)
再発防止:____(バックログID)
備考:本連絡は訓練用です(流用禁止)。
G) ポストモーテム(PM:v0.1)
【TRN-OPS47 ポストモーテム(PM:v0.1:訓練専用・流用禁止)】
対象(INC-ID / Spec-ID):
版:
日時:
1. 何が起きた?(要約:3行)
*
*
*
2. 影響(ダミー)
* 影響範囲:
* 影響時間:
* Severity:
3. タイムライン(時刻は相対でOK)
* t+0:検知(AL-xx)
* t+5:一次対応
* t+xx:復旧(TC-IDで確認)
4. 根本原因(仮説→検証→結論:断定は根拠がある範囲)
* 仮説:
* 根拠(ログ/状態/再現):
* 結論:
5. 5 Whys(任意:やるなら短く)
Why1:
Why2:
Why3:
Why4:
Why5:
6. うまくいったこと(1〜3)
*
*
*
7. うまくいかなかったこと(1〜3)
*
*
*
8. 改善アクション(バックログ化)
* BL-01:内容/理由/完了条件(TC追加など)
* BL-02:
* BL-03:
9. 再発防止の検収(回帰テスト)
* 追加TC:
* 期待結果:
H) 改善バックログ(v0.1)
| BL-ID | カテゴリ | 内容(再発防止の行動) | 完了条件(採点可能) | 優先 | 担当(抽象) | 状態 | メモ |
|---|---|---|---|---|---|---|---|
| BL-01 | 仕様 | timeout条件の仕様をState表に追記(再現条件固定) | TC-timeoutが再現可能でOK | 高 | 作成担当 | TODO | |
| BL-02 | 実装 | 二重実行ガードを強化(loading中の入力抑止) | TC-二重実行がOK | 高 | 作成担当 | TODO | |
| BL-03 | QA | 競合(stale)ケースの回帰テストを追加 | TC-競合がOK、IGNOREDが想定どおり | 中 | レビュー担当 | TODO | |
| BL-04 | 運用 | AL-01の通知先(抽象)と初動10分のRunbookを短文化 | Runbookで迷わずStep1〜3が実施可能 | 中 | 運用担当 | TODO | |
| BL-05 | 記録 | ログ項目(条件/状態/requestId)を不足なく残す | INC票の根拠欄が埋まる | 中 | 対応担当 | TODO |
ダミー課題(どれか1つでOK)
OPS-47A(易):error増加(FETCH_FAIL)を検知→Runbook→PM
状況(ダミー):
- failSwitch=ONでerrorが増える(再現可能)
- error→retryでsuccessに戻れる導線がある
要求:
* SLI:error回数(しきい値)
* AL:error増加
* Runbook:初動10分
* PM+Backlog:最低5件
OPS-47B(中):timeoutを検知→ロールバック判断(ダミー)
状況(ダミー):
- slowSwitch=ON+timeout短でtimeoutにできる(再現可能)
- 復帰が弱い(retryで戻れない想定)を作ってもOK
要求:
* SLI:timeout率
* AL:timeout増加(S2)
* Runbookに「No-Go/ロールバック検討条件」を入れる
* 復帰確認をTC-IDで指定
OPS-47C(中):二重実行(連打)をS1扱い→止血→改善
状況(ダミー):
- loadingガードをわざと外した想定で「二重実行」を再現
- FETCH_STARTが増殖する
要求:
* AL:二重実行(S1)
* Runbook:操作停止→ロールバック想定
* PM:原因仮説→再発防止(ガード+TC追加)
ChatGPTに投げるプロンプト(コピペ用)
1) 監視Spec(SLI/しきい値)とアラートを作る
【L47 プロンプト①:監視+アラート(訓練用)】
前提(安全):
* 教育訓練用ダミー。実データ・実URLは禁止。
* 成果物は流用禁止。実運用アラート設定はしない。
入力:
* 対象(TRN-JS43/44など)
* 状態一覧(idle/loading/success/empty/error/timeout/canceled)
* ログイベント一覧(例:FETCH_START/OK/FAIL/CANCEL/IGNORED)
* 既知の弱点(例:timeoutが多い/二重実行が起きる)
出力形式(必須):
* TRN-OPS47 監視Specヘッダ(v0.1)
* SLI(最大3)+しきい値
* アラート設計(最低5本:Severity/条件/一次対応/記録)
2) インシデントRunbookを手順表で作る
【L47 プロンプト②:Runbook(訓練用)】
入力:
* AL一覧(AL-01〜)
* 再現条件(固定)
* 参照:L46のロールバック観点、L45のQA観点
出力形式(必須):
* Runbook手順表(Step/作業/担当/入力/出力/チェック/所要目安/メモ)
* 最初の10分でやることを明確化
* INC記録テンプレ(埋める前提の項目定義)
3) ポストモーテム→改善バックログへ落とす
【L47 プロンプト③:PM→Backlog(訓練用)】
前提:
* 責めない。再発防止の行動に落とす。
* 断定は根拠(ログ/再現/状態)がある範囲まで。
入力:
* INC記録(再現手順/ログ抜粋/一次対応/判断)
* 修正案(あれば)
出力:
* ポストモーテム(PM:v0.1)
* 改善バックログ(最低5件:完了条件=TCやログで採点可能)
相互レビュー観点(L47専用)
- 訓練専用の担保:流用禁止が明記され、実在情報が混入していないか
- SLI/しきい値:測り方が具体で、第三者が同じ判定に到達できるか
- アラートの設計:Severityがあり、一次対応が現実的(最初の10分)か
- Runbook:入力/出力/チェックがあり、迷わず実行できるか
- PM→Backlog:再発防止の行動(完了条件つき)に落ちているか
レビューコメントテンプレ(コピペ用)
【L47 相互レビューコメント】
対象(TRN-OPS47):
版:
1. 良い点(1つ):
*
2. SLI/しきい値は採点可能?
* OK / 要改善
曖昧な箇所(1つ):
*
3. アラートはSeverityと一次対応が揃ってる?
* OK / 要改善
不足AL(1つ):
*
4. Runbookは最初の10分で迷わない?
* OK / 要改善
改善案(1つ):
*
5. PM→Backlogが再発防止の行動になってる?
* OK / 要改善
弱い点(1つ):
*
6. 次の一手(v+0.1で直すなら):
-
本日の流れ(タイムライン)
目次(クリックで移動)
- 出席・当日選択カリキュラムの内容確認
- 時間差相互評価(2件以上コメント)
- 休憩
- 自分への受領レビュー確認・改善方針メモ
- L47 レクチャー本編(講師説明・質疑込み)
- 昼休憩
- 個人演習①:監視/アラート設計
- 休憩
- 個人演習②:Runbook→PM→Backlog
- 休憩
- 復習:共有できる形に整形(できた範囲でOK)
- 質問・コメント・感想の提出(指定スレッド)
1) 出席・当日選択カリキュラムの内容確認
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 08:30–09:10 |
| 文房具カフェ事業部/準備室 | 10:00–10:40 |
この時間にやること
- 今日の目標(A〜E)を選ぶ(できた範囲でOK)
- ダミー課題(OPS-47A/B/C)を1つ選ぶ
- 注意点を1行で書く(例:しきい値を曖昧にしない/最初の10分を固定/流用禁止)
セルフ棚卸し(コピペ用)
【L47 セルフ棚卸し】
1) 今日選ぶダミー課題:
- OPS-47A / OPS-47B / OPS-47C
2. 自分が弱い点(1つ):
* (例:SLI設計/Severity判断/Runbook粒度/PMの改善化)
3. 今日の目標(1行):
*
2) 時間差相互評価(前日までの他者成果物に2件以上コメント)
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 09:10–10:00 |
| 文房具カフェ事業部/準備室 | 10:40–11:30 |
この時間にやること
- 前日までの他者成果物を2件選び、L47レビュー観点でコメントする
- 「理屈」より、採点可能(測れる)/迷わない(Runbook)/改善に落ちる(Backlog)を見る
3) 休憩
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 10:00–10:15 |
| 文房具カフェ事業部/準備室 | 11:30–11:45 |
休憩:学習作業なし
4) 自分への受領レビュー確認・改善方針メモ(講師レビュー含む)
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 10:15–10:45 |
| 文房具カフェ事業部/準備室 | 11:45–12:15 |
改善方針メモ(コピペ用)
【L47 改善方針メモ】
受領した指摘の要点(最大3つ):
1)
2)
3)
## 直す理由(しきい値が曖昧/Severity不明/Runbookが長すぎ/短すぎ/改善が抽象 等):
直し方(どこを改善する?):
* SLI/しきい値:
* アラート(Severity/一次対応):
* Runbook(最初の10分):
* PM→Backlog(完了条件):
今日の最優先ルール(1行):
*
5) 当日選択カリキュラム実施:L47レクチャー本編(講師説明・質疑込み)
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 10:45–12:00 |
| 文房具カフェ事業部/準備室 | 12:15–13:30 |
ここからが「読む/聞く」パート
運用は「ミスをしない」ではなく、壊れても早く戻す設計です。
監視(SLI)→アラート(Severity)→Runbook(初動)→PM→Backlog を、訓練用ダミーで一度つなげます。
6) 昼休憩
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 12:00–13:00 |
| 文房具カフェ事業部/準備室 | 13:30–14:30 |
昼休憩:学習作業なし
7) 個人演習①:監視/アラート設計
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 13:00–14:30 |
| 文房具カフェ事業部/準備室 | 14:30–16:00 |
演習①のやり方(必須)
- TRN-OPS47 監視Specヘッダ(v0.1)を埋める(SLI/しきい値)
- アラートを最低5本作る(Severity+一次対応+記録)
- しきい値は「採点可能」にする(曖昧語禁止)
提出用フォーマット(演習①:コピペ用/できた範囲でOK)
【L47 演習① 提出(できた範囲でOK)】
Spec-ID:TRN-OPS47
対象(ダミー):
## (1) 監視Specヘッダ(v0.1):
(2) アラート設計(v0.1):
*
8) 休憩
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 14:30–14:45 |
| 文房具カフェ事業部/準備室 | 16:00–16:15 |
休憩:学習作業なし
9) 個人演習②:Runbook→PM→Backlog
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 14:45–15:45 |
| 文房具カフェ事業部/準備室 | 16:15–17:15 |
演習②のやり方(必須)
- ALのうち1つを選び、インシデント記録(INC)を作る(再現条件+ログ抜粋)
- Runbookを手順表で作る(最初の10分が迷わない粒度)
- ポストモーテム(PM)を作り、改善バックログを最低5件作る(完了条件つき)
提出用フォーマット(演習②:コピペ用/できた範囲でOK)
【L47 演習② 提出(できた範囲でOK)】
Spec-ID:TRN-OPS47
## (1) INC記録(v0.1):
## (2) Runbook(v0.1):
## (3) PM(v0.1):
(4) 改善バックログ(v0.1:最低5件):
*
10) 休憩
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 15:45–16:00 |
| 文房具カフェ事業部/準備室 | 17:15–17:30 |
休憩:学習作業なし
11) 復習:共有できる形に整形(できた範囲でOK)
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 16:00–16:30 |
| 文房具カフェ事業部/準備室 | 17:30–18:00 |
最終チェック(コピペ用)
【L47 最終チェック】
- 訓練専用(流用禁止)が明記されている
- 実データ/実URL/実公開が混入していない
- SLI/しきい値が採点可能(曖昧語なし)
- アラートがSeverity/一次対応/記録まで揃う
- Runbookが最初の10分で迷わない
- PMがBacklog(完了条件つき)に落ちている
12) 講師への質問・コメント・感想の提出(指定スレッド)
【実施時間】
| 対象 | 時間 |
|---|---|
| EC事業部 | 16:30–17:00 |
| 文房具カフェ事業部/準備室 | 18:00–18:30 |
提出先(参考)
EC事業部・文房具カフェ事業部:ChatWork の指定スレッド/準備室:Slack の指定スレッド
提出テンプレ(コピペ用)
【L47 提出(本人レポート)】
1. 今日の学習内容(要約:3行)
*
*
*
2. 今日進めたこと(TRAINING ONLY:流用禁止)
* 対象(OPS-47A/B/C):
* SLI/しきい値:
* アラート(本数):
* Runbook(有/無):
* INC(有/無):
* PM(有/無):
* Backlog(件数):
3. 一番工夫した点(1つ)
-(例:しきい値を採点可能にした/最初の10分を固定した/Backlogに完了条件を付けた 等)
理由:
*
4. 次に改善したい点(1つ)
*
## 理由:
5. 質問(最低1つ)
*