はじめに
イレギュラーなことが起きてパニックに陥ると誰しも普段通りのパフォーマンスが出せなかったりしますよね。
インフラ障害に直面した時の僕もそんな気がします。
今回は影響の有無やエラー内容にかかわらず少しでも普段の実力が発揮できるよう
手順化してみました。
最初にほぼ結論ですが、エラーや障害に直面した際のやる事の優先順位として、
概要をつかむ＞問題の切り分けをする＞実際に対応する＞再発防止策を考える
↓
この優先順位で取り組んでいくのがいいのかなと思っています。
意見やアドバイスあればコメントくださると嬉しいです。
1,概要を掴む
問題に直面した際に、急いでいきなり原因を突き止めようとするのはやめて概要をつかむことが大切です。
慣れてくると英語が出来なくても、エラー文見ると何となく何を言われているかわかったりするかと思います。
「failed」とかの単語を見ると何か失敗している、何だろうと色々とコードやコマンド、ファイルパスなどに誤字が無いかとりあえず見に行ったりするかと思います。(これは僕の癖です…)
これをやると、振出しに戻る回数が多くなる気がしてます。
なので「１，概要をつかむ」の結論としてまずは、ログを見に行ったり英語が苦手な場合は、
エラーメッセージをきちんと翻訳することが大事です。
翻訳アプリはこれがおすすめです。Google翻訳よりも精度が高い為こちらを僕は使用しています。
https://www.deepl.com/ja/translator
また、分からないことを聞かれたりサポート的な立ち位置の場合は、
相手からエラーメッセージやエラー画面のキャプチャを貰うことを優先しましょう。
問題の切り分け
ログやエラーメッセージを確認した所で、問題の切り分けができるようになると思います。
SSHエラーはとてもいい例かと思います。
種類が多いので一部見てみましょう。
Warning: Identity file /* not accessible : No such file or directory.
こちらのエラーはsshコマンドでよく-iオプションで秘密鍵のパスを指定することが多いと思います。
その指定したパスに該当の秘密鍵のファイルが無いというエラーになります。
この場合はサーバ側では無く、ユーザ側に問題があるという事が分かると思います。
ssh: connect to host 〇〇〇.〇〇〇.〇〇〇.〇〇〇 port 22: Connection refused
〇〇〇.〇〇〇.〇〇〇.〇〇〇のIPのサーバにport 22でアクセスしようとしたけど接続が拒否されたというエラーになります。
この場合はサーバ側の問題の可能性が高い為サーバ側の設定を確認する必要が有るという事が分かると思います。
このようにエラーメッセージを見ればどこの何を調べればよいかが分かってきたと思います。
実際に対応する
ここはあまり書くことはありません。言葉のままです。
しかし、時にはエラーメッセージの通り対応しても解決できない時があるかと思います。
前述した、SSHエラーの場合ですと秘密鍵のパスの指定を修正して実行したら、
今度は、portのエラーが出たという事もあるかと思います。
要するにユーザ側でもサーバ側でもエラーの原因があったという事ですね。
エラーを解決したらまたエラーか…となってしまう気持ちもとても分かります。
ですが、エラーメッセージが変化したとは、すなわち解決に向けて前進しているともとらえられます！
時にはエラーに対して、ポジティブにいきましょう！
再発防止策を考える
トラブルシュートをした後には再発防止策を考えていく事が大切です。
気にするべき事を書いていきます。
１、そもそも起きた障害を意識する必要がないようにする事はできるか
例えばAWSの場合は、「責任共有モデル」というものがあります。
ユーザ側かAWS側か管理の所在を使用するサービスによって気にする必要があります。
これを考慮して、AWS側管理にできる所はないか等、考えてみると良いかと思います。
ユーザ管理の範囲が小さいとミスも減らすことに繋がります。
２、早期検知はできているか
障害は起きてしまった場合は、どれだけいち早く気づけるかが重要です。
かなり既出なものではありますがアラームの通知設定を、メールアドレス宛にするのではなく、普段コミニュケーションツールとして使用しているチャットルーム宛に通知する方法が考えられます。
その方が多くのメンバーの目につきやすくなるため早期検知に繋がります。
３、自動復旧は可能か
セカンダリの環境を作成する余裕があるのならこの項目も検討する必要があります。
障害が起きてもユーザにサービスを提供し続けることができるに越したことはありません。
最後に
読み返してみると当たり前のことしか書いていないですが、障害やエラーを目の当たりにするとできていない事もあるので、記事として残してみました。
自分用な所もありますが、誰かの役に立てれば幸いです。
参考：
https://atmarkit.itmedia.co.jp/ait/articles/2009/07/news007.html
https://qiita.com/hirokidaichi/items/f9f4549c88aaf8b38bda#%E5%86%8D%E7%99%BA%E9%98%B2%E6%AD%A2%E7%AD%96
お疲れ様でした。