Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
通知と手順書をセットで 設計してみた / Design Notification and Runbook
Ryo Yoshii
July 26, 2021
Technology
2
730
通知と手順書をセットで 設計してみた / Design Notification and Runbook
2021-07-26(月)19:00 - 20:40 JST 開催の Ops JAWS Meetup#19 勉強会で発表した資料です
Ryo Yoshii
July 26, 2021
Tweet
Share
More Decks by Ryo Yoshii
See All by Ryo Yoshii
OpsJAWS Meetup21 システム運用アンチパターンのすすめ
yoshiiryo1
0
1.7k
OpsJAWS20_Network_Access_Analyzerを触ってみた
yoshiiryo1
0
540
今から始めるAWS設計 ~Well-Archなシステムを作ろう~
yoshiiryo1
0
940
Other Decks in Technology
See All in Technology
私のAWS愛を聞け! ~ここが好きだよStep Functions~ #devio2022
kongmingstrap
0
290
DMMプラットフォーム ゼロから始めるKubernetes運用 課題と改善
pospome
0
420
AWS Step Functions を用いた非同期学習処理の例
hacarus
0
100
第22回 MLOps 勉強会:みてねのMLOps事情
tonouchi510
1
1k
合同IT企業説明会から学ぶエンジニア向けの広報戦略
nagutabby
1
250
疎ベクトル検索と密ベクトル検索: 第68回 Machine Learning 15minutes! Broadcast
keyakkie
1
250
Azure DevOps Online Vol.6 - 業務で必要なCIをみんなで考えよう
kkamegawa
0
280
PMMやプロダクト関係者と協働するために役割を整理した話 / 20220810_pdmtipslt
rakus_dev
0
120
品質特性のすすめ
honamin09
0
180
プロダクトマネージャーの役割と育成、評価
middleokada
17
11k
増田亨さんによる 「設計の考え方とやり方」勉強会オープニング
tsuyok
0
220
ロボットの実行すらメンドクサイ!?
kou12092
0
220
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
337
17k
Building Your Own Lightsaber
phodgson
95
4.7k
Why You Should Never Use an ORM
jnunemaker
PRO
47
7.7k
Stop Working from a Prison Cell
hatefulcrawdad
262
17k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
12
940
Bash Introduction
62gerente
598
210k
Unsuck your backbone
ammeep
659
55k
10 Git Anti Patterns You Should be Aware of
lemiorhan
638
52k
Navigating Team Friction
lara
175
11k
Intergalactic Javascript Robots from Outer Space
tanoku
260
25k
Keith and Marios Guide to Fast Websites
keithpitt
404
21k
The Brand Is Dead. Long Live the Brand.
mthomps
46
2.7k
Transcript
通知と手順書をセットで 設計してみた Ops JAWS Meetup#19 勉強会 2021年7月26日 1 ネクストモード株式会社 吉井
亮
自己紹介 吉井 亮 ネクストモード株式会社 Twitter : @YoshiiRyo1 Blog : https://dev.classmethod.jp/author/yoshii-ryo/
好きな言葉 : No human labor is no human error. 2
本日の内容 ▪ 話すこと ・通知された後の行動 ・つらみ ▪ 話さないこと ・製品の紹介 3
4 システム構成
今回の構成 (スーパー簡易版) 5 HTTPS. SFTP, 管理画面 Customer DC 監視系は CloudWatch
Security系 がっつり通知
6 通知と手順書
やめておいたほうが… と言いたくなる通知 • とりあえず CPU/Memory Usage (設計が無い) • とりあえずメール (重要度の分類が無い)
• 全サーバー ”89の法則” (80%Warn,90%Crit) • ログは ”error” で検知 • 過剰なしきい値 (1回でも通知など) • 定期的な見直しが無い 7
最低限やっておきたい通知 ★ システム利用者が困る事象を発見する レスポンス低下、画面ハングアップなどを メトリクスやログから検知したい。 8
最低限やっておきたい通知 ★ 要アクションと Notice は分ける 要アクションは社用携帯でポップアップなど 復旧アクションが取りやすいように。 Notice は平日日中帯の暇な時に見るくらいで。 9
最低限やっておきたい通知 ★ 単純なメトリクスだけで済まさない Anomaly Detection で異常を検知。 Count だけではなく割合をみる。 「HTTP 500が
nn 回」より 「全リクエストの nn %」のほうが実用的 10
通知が飛んだ後に何するか? 通知ごとにアクションを決めておかないと 通知する意味が無い。 ただノイジーなだけの通知は誰も見なくなる。 手順書を作っておきましょう 11
わかりやすい通知にするには 1. 通知に回復手順書を含ませる a. がっつり作り込む b. メンテナンスは大変かも 2. 通知内容と手順をドキュメントに残しておく 今回こっち
12
ドキュメントの内容 • アラート名 (件名やSlack表示名など) • アラートの意味 • アラート受領後の対応 • インシデント責任者、対応してほしいメンバー
• 影響範囲、依存関係 13
14
ドキュメントの内容 サンプル https://github.com/YoshiiRyo1/document-templates-for-aws/blob/master/design/doc_source/cloud-design-monitoring.md 15
つらかったこと 1 飛んでくる通知の内容が事前にわからない。 セキュリティ系や Health は特に。 ので、構築の初期段階から通知を仕込んでおいて 様々な通知内容をプロジェクト内に溜め込む。 横展開も忘れずに (社内ナレッジ、GitHub
等) 16
つらかったこと 2 ドキュメントの更新を継続できるか? 対応手順の更新、しきい値の修正、 通知内容の更新などドキュメントは継続的改善が 大前提。 17
18 まとめ
今回の構成 (簡易版) 通知は飛ばしたあとが大切。 飛ばしたあとのアクションを定義して 手順書を作りましょう。 システム動作前には不明なところも多いので 動かしながら更新していきましょう。 19
ありがとうございました 20