Why Next💻 開発7 分
1つのバケットに所有者が2人いると、最後にapplyした側が勝つ
S3のlifecycleルールを1つ追加したらterraform applyが失敗した。原因は、同じバケットのlifecycle設定を2つのリソースがそれぞれ所有する構造。S3のlifecycleはルール単位ではなくドキュメント単位なので、最後の勝者が相手のルールを静かに消す。
- #インフラ
- #Terraform
- #S3
- #AWS
- #障害対応
#障害対応
「障害対応」タグの記事
- 💻 開発8 分
テストは緑なのに、通知は一度も送信されていなかった
キューにジョブを入れるコードが初日から毎回失敗していた。エラーは握りつぶされ、テストはモックのおかげで緑のまま。コロン一文字が3つの機能を静かに殺した話。
- #バックエンド
- #BullMQ
- #テスト
- #モック
- #障害対応
- 💻 開発11 分
DBが落ちたという通知が来た。DBは一度も落ちていなかった
1日のうちにCRITICALの通知が4つたまった。504、Prisma P2028、管理画面の500、そして「DATABASEサービスダウン」。RDSの指標をまず開いたら、21時間ずっとCPU最大19.7%で無事だった。遅かったのはDBではなく、大西洋を25回渡る往復であり、「ダウン」の通知はヘルスチェックが自分で作り出したものだった。
- #バックエンド
- #障害対応
- #Prisma
- #PostgreSQL
- #オブザーバビリティ
- 💻 開発7 分
「stagingで止めればいい」で終わらせない - うるさいアラートが隠していた本当のバグ
stagingで毎日鳴っていたGoogle Playの404アラート。発生源を止めれば静かになるが、それと失敗モードを直すことは別の問題だった。404は再試行しても意味のない恒久的なエラーなのに、5xxと一緒くたにされて再試行されていたという話。
- #バックエンド
- #リトライ
- #バックグラウンドジョブ
- #障害対応
- #オンコール
- 💻 開発6 分
終了フックが二重に走っていた - SIGTERMの持ち主が二人いたとき
デプロイのたびにSentryにPrismaのP2028エラーが落ちていた。終了順序を直そうと踏み込んだら、NestJSのenableShutdownHooksとgraceful shutdownライブラリの両方がSIGTERMを掴んでいて、終了フックが毎回二重に実行されていたことが分かった話。
- #バックエンド
- #NestJS
- #終了シーケンス
- #障害対応
- #BullMQ