障害対応の記事
- 障害の振り返りで「注意する」を再発防止策にしない — 防ぐ・気づく・狭める 障害の振り返りで「今後は注意する」「ダブルチェックする」と書いても、同じ障害はまた起きます。原因を「仕組みが間違いを通した」まで掘り下げ、防ぐ・早く気づく・影響を狭めるの3種類の対策に分けて、担当と期限のある変更に落とす進め方をまとめます。
- 切り戻すか前進修正か — リリース後の障害で迷わないための基準 リリース直後に障害が起きたとき、切り戻すか直して出し直すかで迷うと、その間も障害は続きます。切り戻しを既定にする理由、データ移行やキューのジョブで切り戻せなくなる条件、判断にかける時間をリリース前に決めておく進め方をまとめます。
- Redis・Valkeyのキャッシュが落ちたとき — DBに倒すか、機能を落とすか キャッシュの Redis や Valkey が止まると、キャッシュを読むだけの画面まで 500 になったり、応答待ちで全体が詰まったりします。タイムアウトの指定、DB に倒す値と機能を落とす値の分け方、キャッシュスタンピードへの備えを Laravel の例でまとめます。
- Request IDをログとレスポンスに通す — Laravelでの実装と伝播 障害調査で1件のリクエストを追えるかどうかは、Request IDがログ・レスポンス・外部API・キューのジョブまで通っているかで決まります。Laravelのミドルウェアと Context を使った実装と、受け取ったIDを信頼してよい条件、伝播の範囲の決め方をまとめます。
- 原因が分からない障害を、API・DB・インフラを横断して切り分ける手順 「どこが悪いか分からない」障害は、推測で直すほど長引きます。影響範囲の確定、時系列の整理、Request IDによる追跡、層ごとの切り分けという順で原因に近づく手順と、日頃から仕込んでおくべき観測の仕組みをまとめます。