障害対応に強くなりたいのでレポートの書き方について考えてみた

この記事は feedforce Advent Calendar 2018 - Adventar の15日目です！昨日は @sunao さんが湯島カレーマップ | SNOPN を書いてくれました！個人的には 9 の clover カレーが大好きで、2週に1回は行っている気がします。

この記事について

最近ちょっとずつお仕事で任される領域も増えていき、イテレーションの開発だけでなく、障害対応やエラー調査を行うことも増えてきました。

ただ！！障害対応のレポートって難しい！！！！！上手く書くのって難しい！！！！

というわけで、調べた結果をまとめる際に、最低限これぐらいは書くようにした方がよいと思ったこと(先輩のレポートやコメントから感じたこと)を書いていきます。

もっとこんな感じで書くと良いよ！や、ここはこう書くと良いよ！などあれば教えていただけると嬉しいです (o_ _)o

なお、自分のチームでは障害対応の調査に関しては Github issue に書くことが多いので、それを前提に見ていただければと思います🙏

まずは、0コメに今回何があってどうしたのか？をまとめる時の構成。これの書けない要素があるなら調べたりなかったりする。

調べていく段階で、別々のコメントとして乱立させたものを この１コメントを見ればだいたい分かる ようなものにするということ。 0コメ以外に書くなら『ここまでのあらすじ』や『まとめ』的な見出しを付けたコメントにする。

それぞれの詳細について次から書いていきます。

何が起こっているのか？をまとめる章。

本番環境でお客様のアカウントで再現しようとせずに、一旦ローカル環境で同様の現象が起こることを確認できるようにしていきましょう。

サンプルデータの用意
- 本番環境と同じデータを別途用意して、ローカル環境で試せるようにする
- 修正が行われるまでは、いつ実行しても同様の再現が行えることを心がける
再現手順の記述
- どんな方法でどんな結果が起これば再現できたと言えるかを記述

対応に関してはお客様向けと内部的なものとに分けて書いていきます。どちらも基本的には、「いつまで」に「何をするか？」が重要になっていきます。

プロダクトオーナーに状況を説明しつつお客様への対応が必要かを確認する。必要に応じて、営業の担当者も巻き込みつつ確認や報告作業を進める。

特に非エンジニアに対するコミュニケーションとなるので、いつも以上に丁寧な言葉選びを心がける。エンジニア用語を読み解いて説明する。

ここは現場チームの関係者で話し合うときの材料として使う。

正確にどこで何を見つけて何を対応したのか？を誰にでも伝わる言葉で書く。

冗長化している環境ならどのサーバーで作業を行ったのか？
生ログもあれば、合わせて書く
- そのまま貼るとコメントが長くなるので <details> タグと <summary> タグを使うと見やすさが上がると思います

サンプル

$ [dev@ip-xx-xx-xx-xx ~]$ ps aux  | grep delayed_job
結果つらつら

大きめの障害対応が終わったときなどは、ふりかえりもセットでしてみると良いと思います。その時は、時系列の事象をベースにどんな対応をしたか？の YWT 形式が再度発生しうる障害対応に強いチーム作りへ繋がっていくのではないでしょうか？💪

サービスを運用していたら、何かしら障害が起こることはつきものだと思うので、いかに対応するかは非常に大事だと思います。

経験も積んできたし、障害対応もできるように頑張っていきたい。

明日は、弊社エンジニアブログ最大はてブ獲得の @daido1976 くんが書いてくれます！楽しみ！

現場からは以上です！