原因追及の重要性

sa-ba

こんにちは。
エクソンスタッフの高山です。

日常業務の傍ら、社内システムの管理を担当していることもあり、どちらかといえばICTに関わるコラムを不定期にアップしていきます。

トラブルは突然やってくる

過日、社内で運用しているサーバのファームウェアを更新しました。
ファームウェア更新といえば以前はバグ潰しや機能追加が主でしたが、最近ではセキュリティホールの修正などもあるので、避けて通れない作業の1つです。

ファームウェアはOSと違って更新に失敗すると機材そのものが使用不能になり、ユーザレベルでの回復が非常に難しくなるので、色々とメーカーサイトの注意なども確認して全スタッフ退勤後の負荷の下がったタイミングで作業したのですが・・・

なんと更新後にサーバが起動不能になってしまいました

さぁ大変です。
起動不能になったサーバはメインサーバ。無いと仕事が進みません。

バックアップもありましたが、最終バックアップがちょっと古いこともあって、できれば使いたくない。
何とかして今あるデータでメインサーバを復旧しないと誰かしらの業務に少なからず影響が出ます。

ただ、唯一の救いは起動不能になった場合にデータだけサルベージする手順を事前準備の段階で準備してあったこと。
そのため、少し時間と手間は要したもののメインサーバに保存された全データはそのまま回復することができました

現象面から解決すると本質が見えない

さて、今回は結果としてデータの損失なく障害復旧できたわけですが、それはあくまで結果論。

通常であれば障害発生後に最初にやるべきは原因の特定です。
どのような要素や環境が絡み合ってその結果をもたらしたかを調査してから根本的原因の解消と環境回復を図らないと、状況によっては障害回復に余計な工数が必要になることもありますし、そもそも今後に向けた有効な対策が打てません。

今回のトラブルも実は、「RAIDで構成された記憶装置の一つがすでに破損しており、ファームウェア更新によって記憶装置上の記録情報に不整合が生じたため、再起動時のシステムチェックに失敗し起動不能になった」というのが真相で、そもそもの原因は記憶装置の物理障害であり、ファームウェアの更新は障害発生の引き金を偶然引いただけだったのです。

つまり最初から原因として記憶装置の物理障害まで特定していれば、障害の発生した記憶装置を交換するだけで全データが自動回復できたはずで、障害対応に掛かった時間も大幅に短縮できていたことになります。

まとめ

最近ではメーカーサイトのFAQやコールセンターの応対などでも、トラブルに対する解決策としてそのトラブルの原因や発生メカニズムに言及しないまま、対症療法的に解決手順のみを提示することが増えています。

加えて、慣れた管理者であっても一度トラブルが発生すると平常心を失いやすく、つい見えている現象面から一足飛びで対処方法を検討してしまいがちになります。

どのような現象にもすべて原因と過程があります。
まずは現象面を正しく捉えた上で、「どうしてそうなったのか」を考察する癖を付けることが「デキる管理者」の第一歩です。

次回はバックアップ環境でよく使われる「RAID」についてお話しします。

それでは。