はじめに
この記事ではメンバー目線（特に1、2年目）での障害対応の乗り越え方を書いてみました。
直接現場の先輩から教わったことや、自分なりにやってよかったことをまとめております。
大きく以下の3つに分けて書いております。
①通常時（障害が起きていないとき）
②障害発生時
③障害対応完了後
①通常時（障害が起きていないとき）
- 設計書や必要なドキュメントの場所を把握し、
何のための設計書かを理解しておく - 使用頻度が高いコマンドはすぐに使えるようにまとめておく（Grepコマンドやオプションなど）
- システムの概要を知っておく（データの源泉はどこなのか、何をやるシステムなのか）
上記3つをやっておくことにより、
障害対応する際に原因追及までの速度が各段に上がりました。
特に「何のための設計書かを理解しておく」がとても大切で、
必要な情報をすぐに追うことができるようになります。
②障害発生時
「どういった種類の障害」なのかをすぐに判断する必要があります。
バッチが落ちてしまったのか、APIの処理にて例外エラーが発生しているのか、
通常は10分で終わるバッチ処理が1時間以上たっても終わらないようなものなのか...
しかし、障害の種類さえわかってしまえば原因の追い方はそれぞれ似ています。
私のプロジェクト先では障害は以下の種類が多かったです。
障害が発生した時、最初は焦ってしまいがちですが、
改めて確認すると障害の種類は大体同じです。
種類さえ判別できたなら、あとは設計書と合わせて必要な情報をまとめていくことで原因が見えてくると思います。
また、過去に同じ障害や似た障害が起きていれば、
その時のメモや情報を参考にするのも手です。
③障害対応完了後
一度起きた障害は、よっぽど特殊なものではない限り2回目も起きる可能性があります。
本来は再発を防ぐための対策を取る必要がありますが、
顧客のヒューマンエラーによるものなどは難しい場合があります。
そのため、
- 何を使って調べたか（どの設計書を使った、など）
- どう対応したか（単純リランしたのか、ファイルを置き換えてもらったのか、など）
- 再発した時の対処法
など、メモなどに残すことで
ことが大切です。
この行動はよく評価されやすいと現場リーダーの方にも教えていただきました。
私自身も過去対応のメモで助かった作業も多くありますので、
良い情報を残すことは非常に重要だと思いました。
まとめ
障害対応は純粋な技術力に加え経験も必要です。
しかし、最初からいきなりスイスイとできるわけではないので、
日頃からできる準備や勉強、システムへの理解があることにより対応力が大きく変わってくると思いました。
経験が浅い中、障害対応に苦労している方で
この記事を今後どう乗り換えるかの参考にしていただければ幸いです。