そーだいなるらくがき帳

そーだいが自由気侭に更新します。

障害対応時にまずはissueを作ると良い

f:id:Soudai:20200430020730p:plain

 先日のAmazon SQSの障害には色々と肝を冷やした人も多いのではないでしょうか。

classmethod.jp

 今回のようなケースとは別に障害は大小あれど、みなさん日々戦っていることだと思います。 障害対応はエンジニアの花形であるものの、サービスに対する知識やソフトウェアの知識など経験と技術の両方が必要です。 そのため、どうしてもトラブルシューティングはエースエンジニアなどの一部の人に依存してしまう…などの問題が発生しがちです。

 そこで今日は私の経験から障害対応のいろはを書いて行きたいと思います。

今回のスコープの外

 実際に障害時の具体的な対応、例えば障害切り分けやRDBMSボトルネックの探し方などの話はしません。

まずissueを作ると良い

 本題です。 トラブルを認知したらまずはissueを作りましょう。 issueを作るときはtemplateが事前に設定されていると便利です。 githubにはissueのtemplateを作る機能があります。 参考までにサンプルのRepositoryを用意しました。

github.com

下記のようなtemplateを用意して新規にissueを作ってもいいですが、templateを複数用意している場合などはSlack botからURLを貰うと便利です。

f:id:Soudai:20200430013829p:plain

通常の issueくれ定例作業issueくれ などの別のissueテンプレを貰うキーワードがあっても便利です。 Slackを使っていない場合もURLの設定だけなので curlシェルスクリプトなどでも対応することができます。

help.github.com

 このissueのメリットは役割分担などの初動を明確にできることです。 特に司令塔が誰かわからず、何をすればいいかわからない人などを防ぐことができます。

 またissueを作ること自体は誰でもできます。 アラートには気付いたがトラブルの対応をどうすればいいかわからない…という人もまずはissueを作り、状況を記載してから引き継ぐなどすることもできますし、後から来た人が二度手間になることを防ぐことができます。

issueから次のアクションを導出できると良い

 templateを作るときのコツとしてテンプレを埋める作業が次のアクションを決めることになるようなtemplateが理想です。 issueを作成することでタスクの内容とゴールが明確になれば、アクションすることができます。 アクションすることができればPDCAが素早く回すことができます。

 特に障害対応は初動の速さと事実の収集が重要で、そのためのアクションを早く取ることが大切です。 状況確認が適切に行われていれば、解決するためのネクストアクションも同じく自然と導出されるはずです。

手順書やチェックリストを作り込まない

 issueのtemplateは適切に育てていく必要があるでしょう。 それに対して手順書やチェックリストは作り込まないようにしましょう。 なぜなら手順書に出来るなら自動化できますし、チェックリストに出来るなら監視ツールで自動的に監視できるはずです。 サンプルとしてリンクを作っていますが、適切なサービス監視が出来ているのであれば、障害の箇所はアラートの時点で判明しています。

 そして適切な復旧対応やバグ対応がされているのにもかかわらず、アラートが飛んでくる場合、それの多くは未知の問題でしょう。 未知の問題に対して、既存の手順書は無力です。

 このように冷静に確認するためのチェックリストはフローチャートの代わりになるので一定のレベルまで意味がありますが、手順書は特に陳腐化しやすいので注意が必要です。

新卒なのでトラブル時に何もできなかった

 4月なので今回のSQSの障害対応では悔しい想いをした新卒も多いのではないでしょうか。 オススメはissueを作る、以外にもタスクがあります。

  1. 書記として実況してまとめる
  2. 関連部署(例えば営業やマーケ)に定期報告する係
  3. チャンネルを作る
  4. 障害対応者や調査者のペアオペ

 テンプレの中で言えばこれらがあります。 例えば1や2はSlackの内容をissueや該当チャンネルに貼り付けたりするだけでも良いですし、司令官の負担を下げることができます。

 4は例えば何もわからなくてもペアオペをすることをオススメします。 障害はサービスの仕組みやドメインを知る大チャンスです。 これを機にしっかり覚えて次に活かすことできますし、パートナーとして「純粋な第三者の目」として見ることができます。 例えば「beginしてませんよ」、「それさっき確認しましたよ」、「今の作業って〇〇ってことでいいですか?」などを聞くだけでも、プレイヤー側は冷静になるきっかけを得ることができます。

 何も出来ないのでは無く、出来ることを見つけることも大切です。

まとめ

 障害対応のハードルを下げることは、対応する人を増やすためにも重要です。 そのためのhowとしてissueを作るコツをご紹介しました。

 またissueを作って実際に障害対応が終わった後は必ず振り返りをしてポストモーテムを作成しましょう。 ポストモーテムの中で新たにtemplateを調整することもあるでしょうし、より良いアクションが生まれるはずです。

 それでは皆さんのissueのtemplateのサンプルのプルリクエスト、お待ちしてます!!!