こんにちは。IT忍者です。たまに全くタッチしていないシステムのトラブルシューティング依頼が来るのですが、24時間動いているシステムだと厄介ですよね。皆さんトラブルシューティング力を合わせて鍛えておりますでしょうか？ 私もトラブルに見舞われるときがありますが、技術と知識の引き出しに救われている事が多いです。役に立ちそうであれば、参考にと思います。実施している方も多いとは思いますが。
開発運用トラブルシューティング方法論
よく発生しそうなところでいうと・・
発生しやすいトラブル事例
・プログラム不具合からの不正データ
・業務手順による不正データ
・インフラ/ネットワークシステムエラー
・環境依存による不正動作
・外的要因によるエラーメッセージ
・システム起動エラー
・要件漏れ、設計漏れ
・ソフトウェアVersion不一致
・ソフトウェアの設定値ミス
・ミドルウェアの不具合
・OS・ソフトウェアVersionUp
・ハードウェアの故障
・ハッキング、WEBサイトアタック
こういった問題で長時間捕まると厄介ですよね。すぐに解決する必要がありますので、どうやって短期間で解決するかですが、私はこういったトラブルシューティング手法です。直近では、まさかのChromeのVupでArray.reduceが仕様通りに動いていないなんてのもありました。こちらの内部処理わざわざ苦労して処理変更したのに、翌日には修正されているという。。うが！( ﾟДﾟ) さて本題ですが。
エラー・不具合の事象把握と事象分析
AI系以外は、プログラムは決められた通りにしか動きませんので、人間的な良きに計らう事も出来ませんし、何も触ってなければ同じ動きしかしないですよね。安定稼働している状態からの異常状態へシステムが状態遷移してしまっているのであれば下記事象を記録し整理します。
・発生事象：正常な状態と異常な状態の比較と正しい挙動の把握
・発生トリガー：何が発端なのか
・発生時間/発生回数：いつ起きたのか、何度も起きるのか
・エラー内容：発生したエラーの内容が何か
・関係個所：類似の関係個所があるか
・直近の変更内容：どこの何を変更したのか
・操作したのは誰か
・どういった操作オペレーションをしたのか
・どういったデータを投入したのか
・発生しているエラーは何が出ているのか
・毎回同じエラーが出るのか
仮説と検証と裏付け
特にこの仮説を立てるという部分が非常にポイントなのですが、若干知識と経験値が必要になるかもしれません。上記発生事象に対して、今、システム、コンピュータがどんな状態にあるのかと、なぜそうなったのかという部分で、論理的、仮説を立てる必要があり、闇雲にWEB検索しても全く関係ない原因で泥沼にハマるというケースが起きる可能性があります。保守しやすいようにログ設計がきちんと出来ていればいいのですが、内部的な問題ではない場合には、事象から発生しうるエラー原因のパターン化をして、エラー理由を絞り込んであげる必要があり、最も事象に近い仮説を１～３つぐらいまで絞りこみます。からのWEB検索。
私もよく「問題への当たりが付いているのか？」と言いますが、 まずは論理的な仮説が立てられているか？から入ります。その上で論理的に事象とマッチする仮説であれば、テスト用の環境で今度は検証フェーズです。ぶっつけ本番しかない場合とかだと、さらに仮説をピンポイントで合わせに掛らないといけませんので、さらに慎重に事を運ぶ必要がありますね。そういった環境であればぜひテスト環境構築をです。
検証して、事象と同じ事が起きれば、仮説が正しいとなり、裏付けが取れます。
対応方針と影響個所の確認
原因がはっきりしたところで、どういうアプローチで解決すべきかを検討する必要があります。さらに類似の影響個所の有無も合わせてチェックし、適切なアプローチで解決すると。データ補正でいいのか、プログラム修正が必要か、インフラ設定を見直すのか、機能設計から直さないといけないのか、などなど時間と作業量のトレードオフも判断し対応します。
開発運用トラブルシューティングまとめ
この力があるないでは、いざという時にどれだけMTTR 【 Mean Time To Repair/Recovery 】 平均復旧時間/平均修復時間 を短縮できるかとなりますが、この言葉は本来システムそのものに適用する用語ですが、「私自身のトラブルシューティングパフォーマンスでMTTRを短縮しているシステムです！」と言えたらかっこいいですよね♪さらに不要な工数もだいぶ削減♪まさに個のSPECを示す事にも繋がります。ぜひこういった修行も視点を変えながら実践して見ては如何でしょうか？
