障害通知をSlackでまとめてインシデント管理しちゃおう！

# あるある

Aくん「どのアラートが来たら、どう対応するみたいなのまとまってるドキュメントってありますか？」

B先輩「アプリのログもあるし、ケースバイケースで資料化までは・・」

Aくん「では過去の対応履歴はどうなってます？」

B先輩「各自思い立った時に残すメモ書きレベルで管理までは・・」

Aくん「・・ほぼ管理ゼロってことですね・・・」

## 半年後

Aくん「あー誰も履歴なんか残さないし残してもみねーし、適当にやって治ればヨシッ！」

B先輩「今日から中途さんがジョインしたのでヨロシクな」

Aくん「あ、どうも。早速障害対応をレクチャしたいと思うんですけんどーー」

##### 「どのアラートが来たら対応するみたいなのまとまってるドキュメントってありますか？」

あれ？
あれれれ？？？

# 学習性無力感のなせる業よのう

善い行いも悪い行いも伝染するんだよなぁ。。
こういうのは元々出来てなかったサイドに転落していくケースが多い。
何故か。それは改善するには個人の努力でなくチーム全体の意識改革をする必要があり、
元々やってなかった人達の腰を上げさせるのはとんでもなく大変。

でも、めんどくさくなければワンチャンあるかもしれない。彼らもエンジニアだもの。

### というのがなんとかなるかもしれないのが、このツール！

# 作ったわ！

<a href="https://github.com/yasutakatou/IMS"><img src="https://github-link-card.s3.ap-northeast-1.amazonaws.com/yasutakatou/IMS.png" width="460px"></a>

詳しくはリポジトリで。バイナリをダウンロードして即使いたいなら[こっち](https://github.com/yasutakatou/IMS/releases)

## v0.2

- ホットラインモード対応
    - 重要なメッセージを見逃さないようにメンション付きでリポストする機能をつけました
    - これで-reverseモードでも特定メッセージを重点的に監視できます。
- メッセージをチェックするIDを指定できるように
    - 一般的なメッセージのやりとりもチェックしていたので、メッセージをポストするボットなりに絞ってチェックするようにしました。

## v0.3

- 名前解決モード対応
    - ユーザー名やチャンネル名にIDを調べて指定が必要だったけど、実名からIDを名前解決する機能を付けました。

## v0.4

- Reacji Channelerモードを追加しました
    - これでHTML形式のメッセージの転送とリンクで元メッセージに飛べるようになります

## v0.5, 0.6

- 文字のアラートと、Reacjiのアラート両方混在しててもレポートできるようにしました
    - これまではどちらか一方のみだったけど一つのチャンネルにまとめられるように！
- 時間指定でリマインダーとして未対応のアラート残件を定期的にレポートする機能を追加しました
    - チャットOPSで起こりがちな対応漏れにリマインダーを追加してさらにインシデント管理を強力に！

### Reacji Channelerとは？

[Slack 用リアク字チャンネラー](https://slack.com/intl/ja-jp/help/articles/360000482666-Slack-%E7%94%A8%E3%83%AA%E3%82%A2%E3%82%AF%E5%AD%97%E3%83%81%E3%83%A3%E3%83%B3%E3%83%8D%E3%83%A9%E3%83%BC)

特定のリアクションを付けると任意のチャンネルにメッセージを丸コピーしてくれる機能です！
これを使うと、

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189193/93081fdd-42bf-db1b-d0db-d3e947adbdd2.png)

こんなかんじでアラートが入ってきたのにReacji用のマークが付き、

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189193/15297a53-ac83-5ffd-cae3-677abc6bc95c.png)

インシデント管理用のチャンネルにコピーされます

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189193/79a10202-0913-148e-8879-decd6148a535.png)

レポートもリンク付きで見れるようになり、どのアラートか追いやすくなりました！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189193/5e65d29b-8390-2d29-59cc-8b0c8208793b.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189193/6cc69f4b-1fe8-52fa-f612-6cd4be050462.png)

もち、ルール反転モードにも対応しています。

# つかいかたは？

前提として**Slackにアラートメッセージが既に飛ばされている事が必要**です。
そこに**インシデント管理用**と**レポート用**の２つのチャンネルを作って管理していきます。

## ルール決め

https://user-images.githubusercontent.com/22161385/117542584-2f2aaf00-b054-11eb-8405-570a21570f9c.png

**検出、または無視するルール**を書いていきます。
**メッセージの文字列**と、**日時・曜日指定**で**正規表現**を使って絞れます。

```
[Rules]
.*Fault.* .*/.*/.* 1[0-2]:.*:.* .*	[RuleX]	CHANNEL1
```

これならFaultが含まれるメッセージで午前10時～12時までが対象となります。
検出したメッセージは[RuleX]というラベルがつけられ、CHANNNEL1の定義にポストされます。

## インシデント管理チャンネル

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189193/5031752e-bdd1-2339-ee1e-40ff8dd48098.png)

[Rules]で書いたチャンネルラベルの定義です。チャンネルIDを遡って管理するメッセージ数を定義します。

```
[Incidents]
CHANNEL1	C025FKF3QJV	20
```

-reverseのモードでルールに全部ひっかからなかったものを管理対象にする場合はデフォルトでポストするチャンネルを定義します。
このモードは何のメッセージが来るかわからない、既知になったメッセージのフィルターを足していく運用時に有効です

```
DEFAULT	C025FKF3QJV	[Alert]
```

## 解決済みラベル

対応したインシデントを解決済みとして扱うために**リアクションマーク**を定義します。
このマークがついたメッセージは**解決済みになるのでレポートに乗ってこなくなります**。

```
[Label]
white_check_mark
```

## レポート用チャンネル

https://user-images.githubusercontent.com/22161385/122943521-10893900-d3b2-11eb-8d90-db3896fa2d6b.png

周期的（デフォは一日一回）にレポートメッセージをポストするチャンネルを定義します。

```
[Report]
C0256BTKP54
```

# でどう運用すんの？

- slackにアラートメッセージを飛ばしているチャンネルにこのボットを招待します
- インシデントチャンネルにアラートが溜まっていきますので対応した人はスレッドに履歴を書き、解決マーク付けます
- 毎日の朝会などでレポートチャンネルを見て残ってるインシデントが無いか棚卸します
- 検出したい、または無視して良いいメッセージをルールに追記します

これにより、**未対応かつ履歴が無いものが管理されていきます**。
また**無視すべきものは自動的に対応済みとなるためアラートのマネジメント状態が改善されます**！

# あとがき

プロダクトを批判するわけじゃないけどインシデント管理出来てないから例えばPagerDutyみたいなSaaS導入しまっす！で
元々管理出来てなかったものが、更新意欲となるモチベの源泉が、改善されるとは思えないんだ。
なら、せめて公の場感がつよい、~~見せしめ~~チーム周知も出来るSlackにまとめた方が良いと思ってる。