障害対応時にまずはissueを作ると良い - そーだいなるらくがき帳

先日のAmazon SQSの障害には色々と肝を冷やした人も多いのではないでしょうか。 classmethod.jp 今回のようなケースとは別に障害は大小あれど、みなさん日々戦っていることだと思います。 障害対応はエンジニアの花形であるものの、サービスに対する知識やソフトウェアの知識など経験と技術の両方が必要です。 そのため、どうしてもトラブルシューティングはエースエンジニアなどの一部の人に依存してしまう…などの問題が発生しがちです。 そこで今日は私の経験から障害対応のいろはを書いて行きたいと思います。 今回のスコープの外 実際に障害時の具体的な対応、例えば障害切り分けやRDBMSのボトルネックの探し方などの話はしません。 まずissueを作ると良い 本題です。 トラブルを認知したらまずはissueを作りましょう。 issueを作るときはtemplateが事前に設定されていると便利です。 g

[titilat]

こういうのはとても大事。めんどくさがる人もいるけどちゃんと後から検証できるようにしとこう。 で、後で検証しよう（絶対やらない奴）。

[n593977]

緊急時こそ手順を残さないと後でその作業が妥当だったか、同様の障害が発生した時に次どうするかの検証をするためにも必要

[htnmiki]

backlogとかredmineとかはもう流行ってないのか

[ya--mada]

“新卒なのでトラブル時に何もできなかった” コレは現場による。「4.ペアオペ」も単なるアリバイ証人。観点を与えて、誰が何をしていたかを見て覚えてもらうのが良いのかな。そもそもリモワだと事前の対応環境作りが

[katzchang]

モニタリングツールのアラートからチケット発行を自動化するのは良くあるけど、アラートの整理が大変だったりして、それに対して複数の通知を1インシデントとして扱う機能が生まれてるのが2020年の最新トレンド（続き

[mayumayu_nimolove]

いいしゅっね

[maecchi]

障害履歴を残すためにもIssue作成はかなり大事

[s99e209]

課題や作業タスクをgithub or Gitlab の issue で管理してるの最近よく見かける（Redmineのチケットはtextile記法だし古い？）

[ksk_uchimura]

これは作ると良いを通り越して作らないといけないレベル。 時系列で何をしたかを書かないと。

[morimarii]

ITILはDevopsと相反すると考えられがちだけど、枠組みは同じなのできちんと勉強したほうがいいよ。簡単だし。

[MtAsuka]

逆にIssueなり障害管理票なりを起票せずに障害対応してるとこがそんなに多いの？対応の経緯の共有や担当の分担、事後の根本原因究明/対策なんかはどうやってるんだろう？

[yoshi-na]

“なぜなら手順書に出来るなら自動化できますし、チェックリストに出来るなら監視ツールで自動的に監視できるはずです。” これがな〜できてないとこ多いんだよなぁ

[k1take]

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

[kzm1760]

SlackのカスタムレスポンスにGitHubのissueテンプレートを呼び出すの便利そう。障害テンプレート以外でもやってみよう。

[tanority]

障害対応時

[yarumato]

“githubで新規issue作る。初動（役割分担、司令塔明示など）を明確にできるのが利点。次のアクションを導出するtemplateを事前に設定してSlack botでURL通知。手順書やチェックリストは作り込まず自動化”

[roshi]

DesignDocやMinispecのようになるとよさそう。

[inductor]

当たり前のようであまりできてない。

[lesamoureuses]

手動で書いてたけどこれだと誰でも書けて楽そう “下記のようなtemplateを用意して新規にissueを作ってもいいですが、templateを複数用意している場合などはSlack botからURLを貰うと便利です。 ”

[tofu-kun]

障害 issue 弊社もやっている。これは他のメンバーへの知見の塊にもなるし、関係者への報告資料にもなる。とても有意なもの。

[sogaoh]

これは広げたい文化。何か貢献したい。