Upgrade to Pro — share decks privately, control downloads, hide ads and more …

通知と手順書をセットで 設計してみた / Design Notification and Runbook

通知と手順書をセットで 設計してみた / Design Notification and Runbook

2021-07-26(月)19:00 - 20:40 JST 開催の Ops JAWS Meetup#19 勉強会で発表した資料です

96c31fe94f5e9b0eef4a606eaadcbc04?s=128

Ryo Yoshii

July 26, 2021
Tweet

Transcript

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

  2. 自己紹介 吉井 亮 ネクストモード株式会社 Twitter : @YoshiiRyo1 Blog : https://dev.classmethod.jp/author/yoshii-ryo/

    好きな言葉 : No human labor is no human error. 2
  3. 本日の内容 ▪ 話すこと ・通知された後の行動 ・つらみ ▪ 話さないこと ・製品の紹介 3

  4. 4 システム構成

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

    Security系 がっつり通知
  6. 6 通知と手順書

  7. やめておいたほうが… と言いたくなる通知 • とりあえず CPU/Memory Usage (設計が無い) • とりあえずメール (重要度の分類が無い)

    • 全サーバー ”89の法則” (80%Warn,90%Crit) • ログは ”error” で検知 • 過剰なしきい値 (1回でも通知など) • 定期的な見直しが無い 7
  8. 最低限やっておきたい通知 ★ システム利用者が困る事象を発見する レスポンス低下、画面ハングアップなどを メトリクスやログから検知したい。 8

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

  10. 最低限やっておきたい通知 ★ 単純なメトリクスだけで済まさない Anomaly Detection で異常を検知。 Count だけではなく割合をみる。 「HTTP 500が

    nn 回」より 「全リクエストの nn %」のほうが実用的 10
  11. 通知が飛んだ後に何するか? 通知ごとにアクションを決めておかないと 通知する意味が無い。 ただノイジーなだけの通知は誰も見なくなる。 手順書を作っておきましょう 11

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

    12
  13. ドキュメントの内容 • アラート名 (件名やSlack表示名など) • アラートの意味 • アラート受領後の対応 • インシデント責任者、対応してほしいメンバー

    • 影響範囲、依存関係 13
  14. 14

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

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

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

  18. 18 まとめ

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

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