arrow_back 日々のつぶやきへ戻る
2026年8月23日

初めての障害対応

こんばんは。もう日曜の夜ですね。この週末はめちゃくちゃ寝ました。幸せですが、毎週やらないように気をつけたいです。 さて、今週は障害対応を初めて行いました。 月曜日に社員の方からslackで報告が来ました。通知を見た瞬間に冷や汗がでました。午前中でちょっと眠かったですが一瞬で目が覚めました。 軽くDBを調査してみたしたがやはり報告通り。上司から対応いけますか?と言われたので「いけます!」と意気揚々と返しました。とは言ったものの何からすれば分からないのでログを見ることにしました。しかし有益なログを見つけることが出来ず、社員の方に詳細情報をヒアリングすることにしました。前から気になっていた処理の実行が行われていたため、その調査をすると何やら想定外の使い方をされていることに気づきました。その機能のログを見るとやはり怪しそう。ここまで4時間程かかりました。次に影響範囲はどれくらいなのかを調査することにしました。データやログの調査をすると影響範囲が小さいことがすぐにわかりました。しかし正確な範囲を捉えるために細かく調べると2~3時間かかりました。抜け漏れが合った場合に洒落にならないと思ったので結構時間がかかりました。次は同様の障害が起こらないように暫定的な処置を行いました。こちらは一瞬で対応が出来ました。次はデータ復旧です。こちらがかなりの曲者で、影響範囲が分かったものの正となるデータがなんなのかはログの前後関係を正確に整理しなければいけません。またログが豊富に残っていなかったため、相当慎重に整理しました。(かなりのストレスでした。) 整理が出来たら対応です。本番DBの操作は脂汗が出ます。この重圧に打ち勝ってSQLコマンドを実行して対応しました。最後に恒久対応です。 こちらはもう日々の開発とやることは変わらないためいつも通りのマインドで取組むことが出来ました。結局3~4日この対応に奪われてしまいました。 この経験から得られたこと: 1. 障害対応のフローを全て一人で対応出来たこと。対応フローを身を持って知ることが出来ました。実装以外のスキルが身についたので1つ強くなれました。 2. 障害対応は相当なストレスがかかることが分かりました。今回は私が実装したところではなかったのですが、もし自分の実装したところのせいだったらと思うと怖いです。 対応最終日にはタバコがとても吸いたくなりました。吸ったことほぼないのに。 3. 最初から怪しい機能に対してチームでもっと議論しておくべきだった。 障害対応で数日なくなってしまい、本来実装されるはずだった機能をリリース出来ませんでした。日々スピード感をもって開発をしているのでかなり痛かったです。 障害が起きると時間と精神が削られるだけではなく、サービスの信頼も落ちてしまいます。なるべく起きないように日々チームで会話をするべきだなぁと思いました。 それでも一定確率で起きてしまと思うので、そのときはできる限り速く対応が出来るようになりたいなぁと思いました。 しばらくは障害対応したくないので安定稼働してくださいmm 平和が一番です。 p.s. google cloudで謎の費用が発生していました。原因は勉強用に使っていたcloud sqlのインスタンスがずっと起動していたことでした。ラーメン1杯食えたのでとても悲しいです。

コメント

最初のコメントを投稿しましょう。

コメントを書く

© 2026 Buildlog. Crafted for clarity.