takc-techトラブル・障害事例集 その2
作成日時：2024-11-03
更新日時：2025-11-03
これまでに見かけたトラブルや障害を書き起こす。
(私がやらかしたわけではないよ)
巨大なレスポンスを圧縮しないためタイムアウトが発生
事象
巨大なレスポンスを圧縮しなかったためタイムアウトが発生した。
リソースを使い切ってサーバーが落ちた。
ネットワークコストも増大した。
対応/考え
圧縮しろ。
ただし、何にでも圧縮すればいいというわけではない。
小さいレスポンスを圧縮しても効果は無いし、むしろ圧縮処理の分だけ遅くなることもある。
大きいレスポンスでも、リソースに余裕が無い場合はサーバーに負担がかかる。
ケースバイケース+トレードオフである。
- 閾値未満のサイズは圧縮しない
- 事前圧縮してキャッシュする
など行う。
そもそも負荷試験をしろ。本番環境で出す障害じゃないだろ。
要件定義や設計の段階でデータ量を見積もれ。
サーバーが落ちるレベルの通信を行うって、その設計/仕様は正しいか？
tempファイル名を時分秒で作成したため衝突
事象
業務系Webアプリケーション。
tempファイルを作成して処理をするロジックがある。
tempファイル名をシステム日時の時分秒でつけていた。
同一タイミングで対象のロジックが動いたため、tempファイル名が重複してデータに異状が発生した。
対応/考え
Webなんだから同一タイミングでロジックが動くことを考えろ。
UUIDなどのランダム値を使え。
ニュースを見ろ。
富士通JapanのMICJETで相次ぎ発生した証明書誤交付についてまとめてみた - piyolog
※秒までのシステム日付をIDにしていたため発生したのではないか、というのがXで議論されていた。
※なお「ID生成の不備が原因だった」という明確なソースは無い。
客先でモックが動かない
事象
顧客に説明するために作成したモックが動かなかった。
会議中に試行錯誤したがどうにもならなかった。
顧客に不信感を抱かれた。
対応/考え
リハーサルぐらいしろ。
動かないことを想定してリカバリプランを立てろ。
顧客に不信感を抱かれることは一番やってはいけない。
AIの言うことを何も考えずに採用した
事象
LLMの出した内容を特に考えずシステムに組み込んだ。
内容自体は一般的には正解だったが、対象のシステムには適していなかった。
それが起因で障害が発生した。
対応/考え
ふざけんな。
LLMの内容をそのまま出すだけなら、お前は不要だよ。
ネットで検索してコピペしたコードでも、
LLMに出させてコピペしたコードでも、
使った時点でそのコードはお前が責任を持て。
そのコードの説明をできないのは許されない。
APIのパラメーター不正で超大量通信
事象
対応/考え
年月日From-To
事象
対応/考え
証明書更新忘れ(3回)
事象
対応/考え
SPFとドメイン
事象
SPFがpassしなかった。
そもそも登録するDNSが間違っていた。