こんにちは、donutです。
あっという間に12月が見えてきました。つい先日ブログを書いた記憶はありますが
時が経つのは非常に速く感じますね...
そんな今回は、「問題の切り分け方法」について書いていきたいと思います。
問題の切り分けとは
「問題の切り分け」は、「何らかの問題が発生したときに、どの部分が原因で起きているのか？」を
突き止めるためにとても重要な要素となります。
エンジニアの間では、バグやエラー等の発生原因を特定するために利用されていますが、
日常生活でも有効な手法として提起されています。
この切り分けができていないと、不要な部分まで確認する必要があり、問題解決までの道が
遠回りになってしまうため、かなりの時間を要してしまう場合もあります。
問題が起きたときにやるべきこと
問題が発生した時にやるべきこととして、主に以下があります。
①まずは冷静になる
→「原因究明が優先じゃないのか？」と思った方もいらっしゃるかもしれませんが
侮れません。
人によってはひとたび問題が発生すると、「どうしよう！早く直さないと
仕事が進まなくなる！」と焦ってしまいますが、焦れば焦るほど沼にはまり、
二次災害のようにさらなる問題を引き起こしてしまう可能性があります。
まずは冷静になり、問題対処を行うための体勢を整えることが大切です。②現在の状況を整理する
→「この問題が発生する直前に何をやっていたか？」「業務への影響度は？」
「今の時点では何ができていて、何ができていないのか？」を意識しながら
順番に整理を行っていきましょう。③上司、案件に関わっているメンバーへ状況を共有・報告する
→自力での解決が見込めない場合、なるべく早くメンバーや上司へ報告しましょう。
特に、②で記載したような問題発生前後の状況を事前に整理した上で
情報共有を行うことで、対応をスムーズに進めることができると思います。
問題の切り分け方
ここで、日常生活での一例と、donut自身がVSCodeで経験したエラー内容を元に、各観点での
問題の切り分け方を記載したいと思います。
～日常生活編～
一般的な例として、「スマホでYahooを開いたが、突然閲覧できなくなった」という事象が
発生した場合の切り分け方を考えてみましょう。
①ネットワーク接続設定の問題か？
(例)Yahoo以外のアプリやサイト(Google等)が起動/閲覧できる場合、ネットワーク
(Wi-fiや5G回線など)の問題ではない。
→ネットワークの状態に問題があれば、他のアプリやサイトも起動不可に
なっているため。
②Yahoo側のサーバーの問題か？
(例)Yahooのサイト自体が閲覧できる場合、サーバー側の問題ではない
→仮にサーバーダウンが発生している場合、Yahoo全体が閲覧不可となり、
他のユーザーにも影響が出ているかもしれない。
③Yahooアプリ側の問題か？
(例)他のブラウザ(ChromeやSafari等)で問題なくYahooのサイトが閲覧できる場合、
Yahooアプリの問題である可能性が考えられる。
このように、③の切り分けの段階でYahooアプリの問題である可能性が浮上した場合、
アプリのアップデート状況(最新版に更新されているか？)や、公式が発信している
障害情報などを確認する必要があります。
～VSCode編～
次に、VScode上で発生したエラー事象の切り分けについてご紹介します。
＜発生までの流れ＞
①VSCode上で内容修正のため、特定のsql・ymlファイルの削除を実行
②ファイル削除後、変更されたファイルを[ステージされた変更]項目へ設定
③[コミットしてプッシュ]よりGitHubのブランチへ実行した際に下記エラーが発生bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)→システムが「en_US.UTF-8 ロケール」を正しく認識できていない、もしくは
「LC ALL」のロケール設定に問題がある場合に表示されるエラーとなります。
＜事象発生当時に切り分けた内容＞
・直近でブランチの変更作業は行っていない(Aブランチ→Bブランチに変更した等)
・VSCodeや連携中のDockerファイル内でも設定変更は行っていない。
・削除対象ではない別のsql、ymlファイルを対象にファイル変更/更新作業を実施
→対象のファイルのみコミット＋プッシュの結果、正常に実行され、
Github側にも内容が反映されていた。
＜結論＞
・他のファイルの内容を修正→コミット＋プッシュ時に事象は発生せず。
・特定のファイルを削除→コミット＋プッシュ時に前述のエラーが発生するという
限定的な事象であったため、いったん様子見となった。
※対象のファイル削除対応については別メンバーへ状況説明＋代理で依頼し、
作業は正常に終了しました。
今回遭遇したエラーについて、教訓として以下の内容が重要であると感じました。
①想定と事実を分けて伝える
→エラーやバグなどの情報は過不足なく事実として伝えることが重要です。
例えば、スクリーンショットの内容と合わせて「○○というエラーが出ていた」
という情報と、 「○○というエラーが出ていたと思います...」といった曖昧な情報
では正確な切り分けが行えず、問題解決までに時間を要してしまいます。
②切り分けながら範囲を絞り込んでみる
→問題が複雑である場合、特定が難しい場合もあります。ですが、全体の中から
問題のない部分を一つずつ除外していくことで、実際に原因となっている
箇所の特定につなげることができます。
エンジニアの観点ではログの確認が有効な方法として挙げられています。
広い範囲から始まり、徐々に問題がありそうなログを絞り込む...という
地道な作業ですが、確実に絞り込んでいくことで問題箇所を特定していくことが
重要だと思います。
③解決までの流れを残しておく
→備忘録として、ブログやナレッジ等で解決までの流れを記載することも大切です。
問題が解決した場合でも、今後同様の事象が発生する可能性はゼロでは
ありません。もし、別の誰かが同様の問題に見舞われた場合、自身が経験した
解決手段を共有することで役に立つかもしれません。
ISLでも社内ナレッジを展開し、社員間で共有を行っていますが、エラー事象が
役立ったケースもあります。
今回は、問題の切り分け方法についてご紹介しました。
仕事や日常生活を問わず、様々な問題に直面し「どうしよう...」となっても、内容を細分化していく
ことで、結果的にシンプルな箇所が原因となっている場合もあります。
皆さんも日々の生活で試してみてはいかがでしょうか。
ここまでお読みいただき、ありがとうございました。
