インフラの運用保守をしていたとき、使っていたミドルウェアのバグによる障害に対応したことがあります。対応中は3日間タクシーで帰ることになり、今でも印象に残っています。
原因を調べてみると、ポイントはミドルウェアの「マイナーバージョン」でした。製品名や環境の詳細は伏せつつ、当時の調査と、そこから学んだことを振り返ります。
まず、バグの対象バージョンかを確認した
障害の調査では、使っているミドルウェアのバージョンが、疑われていたバグの対象に該当するかを確認しました。そのうえで、各種ファイルの中身も確認しました。
最終的に分かったのは、使っていたマイナーバージョンがバグの対象だったということです。ミドルウェアの名前や大まかなバージョンだけを見ていると、見落としてしまう可能性があります。細かなところまで照らし合わせる大切さを、このとき実感しました。
障害対応は、一人だけでは進められない
もう一つ強く感じたのは、各担当との連携の大切さです。障害対応では、自分の担当範囲で確認したことだけでなく、ほかの担当者が確認したことも合わせて状況を整理する必要があります。
特に原因がすぐには分からないときほど、確認できた事実と、まだ分かっていないことを共有しながら進めるのが大切だと思いました。3日間タクシーで帰るほど対応が続いた経験だったからこそ、技術面だけでなく、連携の重要さも忘れられません。
この経験から学んだこと
今回の経験で特に心に残ったのは、次の二つです。
- バグの対象かを判断するときは、マイナーバージョンなどの細部まで確認する
- 各担当と確認状況を共有し、連携して原因を絞る
障害の原因や対応方法は毎回違います。それでも、大まかな思い込みで判断せずに細部を確認すること、そして担当者同士で情報をつなぐことは、今後の障害対応でも大切にしたいです。
日常的な監視や障害対応で身についたことは、AWS運用保守を3年経験しても転職後に知識不足を感じた理由でもまとめています。
