202007に開催した入門監視読書会の資料

1. 『入門監視』読書会
第一回 監視の原則

2. お品書き
- 『入門監視』
- アンチパターン
- デザインパターン
- アラート、オンコール待機と運用チーム
- まとめに代えて ~運用監視は心が大事~

3. 監視、してますか？
あなたのシステム、真っ当に動いてますか？
運用監視チームは、疲弊していませんか？
少しでも後ろめたいことがあれば、読んでください。
本発表では、本書の内容を基に の政治的主張を綴り
ます。より良い監視を共に考えましょう。
目次
第Ⅰ部 監視の原則
1章 監視のアンチパターン
2章 監視のデザインパターン
3章 アラート、オンコール、インシデント管理
4章 統計入門
==========↑今回はここまで↑ ==========
第Ⅱ部 監視戦略
5章 ビジネスを監視する
6章 フロントエンド監視
7章 アプリケーション監視
8章 サーバ監視
9章 ネットワーク監視
10章 セキュリティ監視
11章 監視アセスメントの実行

4. アンチパターン

5. ツール依存の監視
• 何を見るべきかではなく、今あるツールで何が見えるかに立脚
• 自分が知っているツールで何でもやろうとしてしまう
• ツールとは仕事のやり方、前提、文化的 / 社会的規範が具現化したも
ので、それが作られた前提を知らないと意味がない
• ツールで成功したのではなく、チームが成功してツールや方法論が出
来た
• 街灯効果
⇒ 本質的に監視するべきこと、ものは何か？を考えよう
⇒ 自分でツールを作るべき時もある。何でもノンコードで進められると
思うなよ

6. チェックボックス監視
• チェックボックス監視とは、「これを監視してます」と言い張
るための枠組
• 「チーム標準のチェック項目をクリアしているのだから問題あ
りません」という責任回避
• 色々メトリクスを監視はしてるけど、意味は分かってない
(e.g. メモリ使用量とは？IOパフォーマンスとは？)
⇒ チェックボックスは一次調査の道具に過ぎない
⇒ チェック項目の意味を理解する
⇒ 本質的な解決指向のチームビルディング

7. 監視を支えにするな
• 壊れたアプリを大量の監視で運用しようとするのはやめろ
• 監視を足す前にアプリを直すことを考えろ
“このアプリはたまに起動失敗するから、手動で起こす必要が…”
“ワークアラウンドがあるから、ショーストッパーじゃないよね”

8. 役割としての監視
• 監視とは役割ではなくスキルである
• 何でもメンテナンス担当者に押し付けるセクショナリズムはク
ソ。あくまでもチーム全員が監視者である
• 全員が本番環境に誇りと責任を持て
“これはメンテチームの担当だから…”
“メンテチームの調査は終わってるから後は開発チームの責任…”

9. 何をもって動いていると言えるのかが謎
• 誤検知が多いのでアラートを無視する
• 今の挙動が正しいのか誰にも分らないコンポーネント
• システム監視の視点では“何も問題ない”が、ユーザにとっては
大きな障害である問題(e.g.GUIが重すぎ、画面が煩雑すぎ)
⇒ アラートの根本原因調査を放置するな
⇒ 誤報は消し、必要なアラートは追加せよ
⇒ テストコードを書こう
⇒ テック、ビジネス間で使用感を共有しろ

10. 何でも手動で監視しようとするな
• 何でも人力でやろうとするな、自動復旧の仕組みを作れ
• FUD(fear, uncertainty, doubt)によって変えられないルー
ティン
-いつも/みんなやってることなので現状に疑問を抱かなくなる

11. デザインパターン

12. 複数のツールを組合わせよう
• 全てをカバーできるツールというのは存在しない
• 自分だけの監視プラットフォームを作り上げよう

13. ツールの選び方
• 先ずは既存のソフトウェアの中で使えるものがないかを考える
⇒ 楽だし、俺たち監視ツール作る専門家じゃないし
• 知名度や流行で選ぶのではなく、チームが本当に必要としてい
るものを見つけないとダメ
• トップダウンで押し付けてもムダ。外部コンサルとかもワーク
しない。自分達が頑張る前提でなければ。
• 既存のツールに不満を持ち始めたら、魔改造/自作を考える

14. データの貯め方
• 構造化した形でログを貯めよう
• 平文よりも、jsonなどの構造化ログの方が視認性がよく、後処理が楽
• 時系列でデータを持とう
• 時系列形式で持つことで傾向や推移が観察できる
• 統計分析に使える形でデータを持とう
e.g. ディスク使用率等のメトリクスは単なる閾値ではなく変化の割合も
見るべき(急激な増加・低下)
⇒Elastic Searchはいいぞ

15. 監視の視点と戦略
• ユーザ視点での監視
エンドポイント(=ユーザの視点)から監視することを心掛ける
• “障害が起きてない”を担保することだけが監視の目的ではない
プロダクトの価値を向上させるためのメトリクスを継続的に監視
することが目的
• 継続的な改善
監視プラットフォームもまた一つのエコシステムであり、日々進
化していくもの。反復的な改善が大事

16. アラート、
オンコール待機、
運用チーム

17. アラートの在り方
• アラートにはだれかを叩き起こすためのものと、FYIが目的な
ものがあり、分けて考える必要がある
• FYIまで即時対応が必要なアラートとして上がるとチームは疲弊
• 即時対応が必要なアラートには何をするべきかの手順書がある
とよい⇒何をするべきかが曖昧ならログ設計を再検討、明確な
ら自動化
• コンポーネントは以下が分かるようになっているとよい
何のサービスで何をするものか、誰が責任者か、どんな依存性を持って
いるか、インフラのトポロジ、どんなメトリクスやログを送っているの
か、どんなアラートが設定されているのか

18. インシデント対応のチーム
• インシデント対応には次の人が必要。２つ以上兼務するべきで
はない
現場指揮官、書記官、コミュニケーション調整、インシデント対
応者
• インシデント対応チームにおいて組織の上下関係は関係ない
• チームのマネージャはコミュニケーション担当にして、現場指
揮官はエンジニアにした方が上手くいくことが多い
• ソフトウェアエンジニアもチームに巻き込もう

19. まとめ

20. 銀の弾丸はない – 監視とは複雑なもの
• 監視とは複雑なものであり、日々進化していくもの
• “もうこれだけ見ておけば充分”ということはない
• 監視は単に“問題が起きていないこと”を担保するためだけのも
のではない
⇒ ビジネス、システムを継続的に改善していくための活動
• デベロッパー(アプリ/インフラ)、運用担当者、ビジネスが一体
になって全員で監視していくべき

21. プロダクトに向き合う心が何より大事
• “現状維持”以上の監視を実現するためには、メンバーにプロダ
クトを改善する動機づけがなければ話にならない
• 特に改善のモチベもなく、現状維持で仕事をやっていけるのに、
どうして頑張る必要があるのか？
• 本質的に顧客ビジネスが“他人事”であるSierが如何にして改善
への欲を持つのか？
プロダクトへの愛着？誇り？技術向上へのモチベーション？
個々人に精神論で訴えてもスケールしないので、企業として、組
織として、チームとして改善への動機づけを考える必要がある
What do you think?