第36回: 本番運用チェックリスト（Laravel版） — リリース前の確認、属人化していませんか？
経験豊富なエンジニアでも、リリース前の確認を頭の中だけで管理していると、プレッシャーや疲労で抜けが発生します。「APPDEBUG=true のまま本番デプロイ」「監視通知先の疎通未確認」——こうしたミスは、チェックリストがあれば防げます。
Category
カテゴリー: Laravel
第35回: 障害対応ランブック作成 — 障害のたびに「どうすればいいか」を考えていませんか？
アラートが飛んできたとき、「まず何を確認すればいいか」「誰に連絡するか」「どこまで判断していいか」——これらが頭の中だけにある状態では、対応者によって復旧時間に大きな差が出ます。
第34回: Queue監視とアラート設計 — 失敗件数だけ見ていて大丈夫ですか？
Queue の失敗件数がゼロでも、処理が遅延していればユーザーへの影響は出ています。メール送信が1時間遅れる、決済処理が詰まっている——こうした「静かな障害」は失敗件数の監視だけでは検出できません。
第33回: 本番DBマイグレーション戦略 — テーブルロックでサービスを止めていませんか？
ALTER TABLE をそのまま実行すると、完了するまでテーブルがロックされます。数分間の書き込み停止が発生し、サービス障害として記録されます。
第32回: ゼロダウンタイムデプロイ基礎 — デプロイのたびにサービスを止めていませんか？
「コードを更新してからマイグレーションを実行する」「マイグレーション後にコードを反映する」——どちらの順番を選ぶかで、デプロイ中の短時間障害が発生するかどうかが変わります。
第31回: レート制限の高度化設計 — 全ユーザーに同じ制限をかけていませんか？
未認証のスクレイパーも、プレミアムプランのユーザーも、同じ制限値が適用されている——こうした設計は、正規ユーザーの体験を損ないながら悪意ある攻撃には十分機能しないことがあります。
第30回: 認証強化（2FA/セッション管理） — パスワードだけで守れていると思っていませんか？
パスワードの使い回しや情報流出は日常的に起きています。「パスワードを設定している」だけでは、現代の認証基準を満たしているとは言えません。
第28回: バッチ処理の分割と再開戦略 — 「途中で止まったバッチ」をゼロから再実行していませんか？
100万件のデータを処理するバッチが、90万件まで進んだところでメモリエラーで止まった——残り10万件のためにゼロから再実行するのは、時間もコストもかかります。
第27回: スケジューラ設計と再実行耐性 — 「2回実行されても大丈夫」な設計になっていますか？
定期バッチが何らかの理由で二重起動された場合——同じデータが2回送信される、請求が重複する、集計値がずれる——こうした事故が起きた経験はありませんか？