Slide 1

Slide 1 text

通知と手順書をセットで 設計してみた Ops JAWS Meetup#19 勉強会 2021年7月26日 1 ネクストモード株式会社 吉井 亮

Slide 2

Slide 2 text

自己紹介 吉井 亮 ネクストモード株式会社 Twitter : @YoshiiRyo1 Blog : https://dev.classmethod.jp/author/yoshii-ryo/ 好きな言葉 : No human labor is no human error. 2

Slide 3

Slide 3 text

本日の内容 ■ 話すこと ・通知された後の行動 ・つらみ ■ 話さないこと ・製品の紹介 3

Slide 4

Slide 4 text

4 システム構成

Slide 5

Slide 5 text

今回の構成 (スーパー簡易版) 5 HTTPS. SFTP, 管理画面 Customer DC 監視系は CloudWatch Security系 がっつり通知

Slide 6

Slide 6 text

6 通知と手順書

Slide 7

Slide 7 text

やめておいたほうが… と言いたくなる通知 ● とりあえず CPU/Memory Usage (設計が無い) ● とりあえずメール (重要度の分類が無い) ● 全サーバー ”89の法則” (80%Warn,90%Crit) ● ログは ”error” で検知 ● 過剰なしきい値 (1回でも通知など) ● 定期的な見直しが無い 7

Slide 8

Slide 8 text

最低限やっておきたい通知 ★ システム利用者が困る事象を発見する レスポンス低下、画面ハングアップなどを メトリクスやログから検知したい。 8

Slide 9

Slide 9 text

最低限やっておきたい通知 ★ 要アクションと Notice は分ける 要アクションは社用携帯でポップアップなど 復旧アクションが取りやすいように。 Notice は平日日中帯の暇な時に見るくらいで。 9

Slide 10

Slide 10 text

最低限やっておきたい通知 ★ 単純なメトリクスだけで済まさない Anomaly Detection で異常を検知。 Count だけではなく割合をみる。 「HTTP 500が nn 回」より 「全リクエストの nn %」のほうが実用的 10

Slide 11

Slide 11 text

通知が飛んだ後に何するか? 通知ごとにアクションを決めておかないと 通知する意味が無い。 ただノイジーなだけの通知は誰も見なくなる。 手順書を作っておきましょう 11

Slide 12

Slide 12 text

わかりやすい通知にするには 1. 通知に回復手順書を含ませる a. がっつり作り込む b. メンテナンスは大変かも 2. 通知内容と手順をドキュメントに残しておく 今回こっち 12

Slide 13

Slide 13 text

ドキュメントの内容 ● アラート名 (件名やSlack表示名など) ● アラートの意味 ● アラート受領後の対応 ● インシデント責任者、対応してほしいメンバー ● 影響範囲、依存関係 13

Slide 14

Slide 14 text

14

Slide 15

Slide 15 text

ドキュメントの内容 サンプル https://github.com/YoshiiRyo1/document-templates-for-aws/blob/master/design/doc_source/cloud-design-monitoring.md 15

Slide 16

Slide 16 text

つらかったこと 1 飛んでくる通知の内容が事前にわからない。 セキュリティ系や Health は特に。 ので、構築の初期段階から通知を仕込んでおいて 様々な通知内容をプロジェクト内に溜め込む。 横展開も忘れずに (社内ナレッジ、GitHub 等) 16

Slide 17

Slide 17 text

つらかったこと 2 ドキュメントの更新を継続できるか? 対応手順の更新、しきい値の修正、 通知内容の更新などドキュメントは継続的改善が 大前提。 17

Slide 18

Slide 18 text

18 まとめ

Slide 19

Slide 19 text

今回の構成 (簡易版) 通知は飛ばしたあとが大切。 飛ばしたあとのアクションを定義して 手順書を作りましょう。 システム動作前には不明なところも多いので 動かしながら更新していきましょう。 19

Slide 20

Slide 20 text

ありがとうございました 20