月曜の朝、追跡ページが止まった
ある宅配便の会社では、お客様がウェブで荷物の場所を調べられます。
月曜の朝9時15分、そのページにエラーが出始めました。アラートが鳴り、入社2か月の佐藤さんのスマホにも届きました。
佐藤さんは、何から手をつければよいか分かりません。このレッスンでは、そのときの動き方を学びます。
このレッスンのゴール
メモ
本番が止まったときに何をするかを説明できる。
キーワード
| ことば | いみ | れい |
|---|---|---|
| インシデント | お客様に影響が出ている、本番の問題です。 | |
| 影響範囲 | 誰に、どこまで影響が出ているかです。 | |
| 切り戻し | 前の正しく動いていた版に戻すことです。 | |
| 振り返り | 収まった後に、原因と次の対策をまとめることです。 | |
| 稼働率 | サービスが使えた時間の割合です。 | 99.9% |
学生が入力するセルは、このプレビューでは空白です。
最初の動きには順番がある
アラートが鳴ったら、まず本当に問題が起きているかを確かめます。
次に、チームに知らせます。指揮を取る人を一人決め、ほかの人はその人に報告します。
そのうえで影響範囲を調べます。全部のお客様か、一部の地域だけか。お客様向けのお知らせを出すかどうかも、ここで決めます。
月曜の朝の記録
| 時刻 | したこと |
|---|---|
| 9:15 | アラートが鳴る (エラー率 18%) |
| 9:17 | 佐藤さんが自分でページを開き、エラーを確かめる |
| 9:19 | チャットで知らせ、田中さんが指揮役になる |
| 9:24 | 全国のお客様に影響があると分かる |
| 9:26 | 「追跡ページがつながりにくい」とお知らせを出す |
学生が入力するセルは、このプレビューでは空白です。
原因探しより先に元に戻す
記録を見ると、金曜の夕方に新しい版 v5.8 が出ていました。
田中さんは、原因を探す前に、一つ前の v5.7 に切り戻すと決めました。お客様が使えるようになることが、何より先だからです。
下は、そのときの実際の画面です。この練習環境では動きません。
前の版に切り戻す
$ deploy history tracking-web
VERSION DEPLOYED AT STATUS
v5.8 2026-10-19 09:02 current
v5.7 2026-10-16 14:30 previous
v5.6 2026-10-12 10:11
$ deploy rollback tracking-web --to v5.7
Rolling back tracking-web to v5.7 ... done
Health check: 3/3 instances healthyよくある間違い
注意
まず原因を突き止めてから直すべきだ、と考える人が多くいます。お客様が困っている間は、それは後回しです。切り戻しや設定の戻しで先に復旧させ、原因はその後で落ち着いて調べます。
振り返りは人ではなく仕組みを見る
落ち着いたら、振り返りを書きます。何が起きたか、なぜ気づけたか、次に何を変えるかです。
大事なのは、誰かを責めないことです。責められると、人は失敗を隠すようになります。
「なぜテストで見つからなかったか」のように、仕組みの穴を探します。もう一つの目安が稼働率です。止まってよい時間を、前もって決めておきます。
止まってよい時間を計算する
# 30日を分に直します
minutes = 30 * 24 * 60
print("30日は", minutes, "分です")
# 稼働率 99.9% のとき、止まってよい時間
allowed = minutes * (100 - 99.9) / 100
print("止まってよい時間は約", round(allowed, 1), "分です")
# 99.9 を 99.0 や 99.99 に変えて、実行してください。