社内障害情報共有のススメ

こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今日は社内で数年ほど取り組んでいる障害情報の社内共有についてご紹介したいと思います。

障害情報を社内共有する理由

サービスを運営しているなら、出来る限りサービスが一時的に止まってしまうなどの障害を起こさないように事前に対策を取るなど気をつけるべきです。しかし、どれだけ事前に対策をとっても、急激なアクセスの増加や、意図しないバグの混入、オペレーションのミスなどを理由として、障害を起こしてしまうことがあります。

障害が起きた時、それに暫定的に対応して終わりとしてしまうことも多いです。しかし、復旧した後大事なのは、障害に対して適切に振り返りをし、同じサービスで同様の理由で障害を起こさない、また社内で同様の理由の障害を未然に防ぐことです。

そこで、はてなでは障害の暫定対応をした後は、障害の振り返りや他チームへの知識共有のために、社内のグループウェアに障害の情報をまとめ、全エンジニアに周知するようにしています。

障害情報共有のやり方

では、その障害情報共有のやり方を紹介します。ちょっとしたルールと共有のフォーマットを決めているだけで、難しいことは特にありません。

どのような時に報告するか
- サービスのユーザに影響があったものは必ず報告する
- 障害にまでならなかったヒヤリ・ハットな事例でも、他チームに有用そうな事例なら報告する
誰が報告するか
- 障害全体を把握しているチームメンバーの誰かが責任をもって報告する
誰に報告するか
- 社内のエンジニア全員
何を報告するか
- 状況: どのような障害が起こり、どのような影響があったか
- 原因: その障害の原因
- 対応: 障害が起こった時に暫定的にどのような対応をしたか
- 今後の対策: 根本的にその障害を今後起こさないようにするために、どのような対策が必要か
- 備考

はてなでは、はてなグループをグループウェアとして利用しているので、

社内の日記に障害情報を書き、エンジニア全員にメンションで通知
「これまでの障害情報まとめ」というキーワードにリンクし、そのキーワードへのリンク一覧から情報を一覧して見れるように

という運用をしています。

障害情報共有例

上のやり方を使い、例えば以下のように報告しています。適当に作った例なので少し漠然としていますが、通常はサービス名や状況などはもう少し具体的に書いています。

# アプリケーションサーバが応答を返さなくなった問題
## 状況
- 2/13の12:00~12:15ごろまで、アプリケーションサーバが全く応答を返さなくなった
- 応答を返さないため、ユーザーはサービスにアクセスができず、全ての機能が使えな
い状況であった

## 原因
- 非常にヘビーにサービスを利用しているユーザが退会処理をした結果、それに紐づく
データが一斉に削除されるクエリがDBに対して発行された
- そのクエリによってDBが詰まり、クエリを一切受け付けなくなった
- また削除も終わらない状況だった

## 対応
- 一旦該当のクエリを手動で停止させた
- ユーザーの退会処理は、DBが詰まらないように注意し、こちら側で行った

## 今後の対策
- ユーザーの退会処理における関連データ削除を、同期的に、かつ一気に行っている
のが問題であった
- 後からの削除で問題ないようなデータは、ジョブキューなどを利用し非同期にした上で、
DBに影響が出ない程度に少しずつ削除するような対応をアプリケーションに入れたい

## 備考
- まとめissue https://github.com/hatena/hoge/issues/1234

> エンジニアにメンション

障害情報の共有の効果

このように障害が起こったら情報を社内に共有しているのですが、これにより得られていると感じる効果は以下のようなものがあります。

情報をまとめることで自然と振り返りがなされる
別チームで同じ状況があれば、それに対して対応できる
別チームからアドバイスが得られる

まず一つ目は、障害を共有する側が障害の情報をまとめることで、自然とその障害への振り返りがなされるということです。障害が起こった時に一時的な対応で満足してしまうと、その障害の根本的な原因を調査しなかったり、根本的な対策を行わなかったりしてしまうことがあります。しかし、決まったフォーマットでまとめることで、何が起こり、根本的にどういう原因で起こり、今後根本的にはどのような対策が必要かということを考える機会となっていると思います。

二つ目は、別チームで同じ状況があれば、障害が起こる前に対応ができるということです。殆どの場合、障害はそのサービスごとに原因は別々ですが、例えば同じ外部APIを使っている時のハンドリング方法のミスなど、時々同じことを別チームでも行っていることがあります。そのような時に別チームでは障害が起こる前に対策できます。

三つ目は、別チームから根本的な対策の方法についてアドバイスがもらえることです。はてなでは、エンジニア用のはてなグループに投稿すると、エンジニアが全員入っているSlackのチャンネルに投稿が流れるようになっています。そこに障害情報が共有された時に、たまに「このような対策をすればよいのではないか」などの議論がなされていることがあります。このように、他のチームからアドバイスがもらえることはメリットであると感じています。