OpsJaws ＃18 での資料です。 監視論 https://qiita.com/qryuu/items/c55b1e8c472eb716f616 および 監視論Ⅱ https://qiita.com/qryuu/items/94890340b958185cb8be の内容をまとめました。

1. 監視論
～監視の概念とMSPの生存戦略～
OpsJaws

2. 自己紹介
▪ PN:九龍真乙
▪ Twitter: @qryuu
▪ SlideShre: https://www.slideshare.net/qryuu
▪ GitHub: https://github.com/qryuu
▪ クックパッド: https://cookpad.com/kitchen/4142562
▪ Youtube: https://www.youtube.com/channel/UCcPidyLCfGp49pmF4Zb761Q
▪ 専門：Zabbix, テクニカルサポート, クラウドアーキテクト
2

3. 注意
Qiitaにて公開してる監視論および監視論Ⅱをまとめた内容です。
3

4. セッションの目的
4

5. セッションの目的
▪ 監視ツール、監視SaaSなどITシステム監視に関する
ツールや仕組みについては多くのドキュメントがあります。
しかしそもそもITシステム監視そのものについてはあまり語ら
れる事がありません。
▪ このセッションでは特定の監視ツールや監視サービスについて
ではなく
ITシステム監視そのものの定義や意義、監視サービスのあるべ
き未来について考察します。
▪ さらにマイクロサービスやSREといった変化のなかでMSP事業者
やモニタリングエンジニアの生存戦略ついてかんがえます。
5

6. セッションの目的
▪ ITシステム監視とは何か
▪ 監視エンジニアの未来
▪ SREとアウトソーシングの関係
6

7. ITシステム監視とは
7

8. ITシステム監視とは
▪ プロセス監視
▪ 機器監視
▪ アプリケーション監視
▪ ログ監視
8

9. ITシステム監視とは
▪ システム監視の目的はシステムの安定稼働
▪ システム稼働効率の最適化
9

10. 監視システムの４要素
10

11. 監視システムの４要素
▪ 収集
▪ 判定
▪ 通知
▪ 分析
▪ 単一のソフトやサービスによって全てを実現する場合もあれば、
複数のソフトウェアやサービスを組み合わせて機能を満たす場
合もあります。
11

12. 収集
▪ 対象システムやセンサー、ネットワーク機器等からデータを集
める。
▪ CPU使用率やメモリ使用率、ディスク情報やネットワーク負荷
ログ情報や環境データの収集を行う。
12

13. 収集
▪ 標準的なプロトコルやAPIにより監視ツールなどにデータ提供を
行う対象システム
▪ 監視システム独自Agentによって対象システムからデータ収集を
行う
▪ 対象システム自身の状態確認コマンド、統計コマンドにより出
力される情報をスクリプトやAgent等により収集する場合もある。
13

14. 判定
▪ 収集により集められたデータに対して、正常・障害/ノーマル・
アラートなどの判定を行う。
▪ 判定では、「イコール/ノットイコール」や「含む/含まない」、
「以上/以下（超過/未満）」
などにより、数値判定、文字列判定を行う。
▪ 2015年ごろから、近似計算による将来値予測を行いこの予測値
に対する判定を行うシステムも登場している。
▪ 複数の条件やAIの利用など判定の高度化も行われている
14

15. 通知
▪ 通知先は人間とは限らない
▪ システムに通知する＝自動復旧・自律制御
▪ 何のために通知するのか＝通知するけど静観は意味が無い
▪ 通知した後のフローを意識して通知条件を設計する
▪ 通知を受けた人物が「決断」「操作」する必要がある場合に
通知する
15

16. 分析
▪ ソース
– 収集されたデータ
– 判定の頻度
▪ 目的
– 現状把握
– 将来予測
▪ 効果
– ボトルネックの判断
– ボトルネックの移動予測
– コスト最適化
16

17. 分析
▪ 分析は立案である
▪ 監視は終端ではなく先端
▪ 分析に必要な能力は勘ではなく知識
17

18. なぜ可視化するのか
18

19. なぜ可視化するのか
▪ 監視対象データは時系列データ
▪ 瞬間値ではなく、値の推移が意味を持つ
▪ 数値表を眺めるのではなくグラフ化することで変曲点が把握で
きる。
▪ ボトルネック分析やシステム負荷ではデータ同士の相関やス
ケール変更が重要
▪ データアナリストやデータサイエンティストに繋がる経験
19

20. MSPという業態
20

21. MSPという業態
▪ MSP（Managed Service Provider）
▪ MSP（Monitoring Service Provider）
▪ MSPは本来運用サービスを提供するものであるが、実体として
は監視サービスを提供し、サービス運用についてはエンドユー
ザの指示に従うような業態となっている。
21

22. MSPという業態
▪ AWSがMSPパートナープログラムとして、「Next Generation
MSP」としてパートナー要件を定義
▪ MSPに高度なナレッジ、システムの自動化、DevOpsの実現など
が求められた。
22

23. MSPという業態
▪ DevOps＝開発・SIer機能
▪ ナレッジ提供＝コンサルティング機能
▪ 24-365＝カスタマーサポート機能
23

24. SREの役割
24

25. SREの役割
▪ SRE（Site Reliability Engineering）
▪ 運用のためのコードを書く
▪ 開発者が運用を行うという思想
▪ SREとはITサービス企業自身の役割でありMSPのようなアウト
ソーサーとして提供する事に向いたロールでは無い。
▪ 少なくとも業態や関係性を変える必要がある
25

26. 監視の役割は開発ではない
26

27. 監視エンジニアとしての価値
▪ SREが登場した当時DevOpsの文脈が強くOpsやSREも開発を行う
という総員コーダーのような雰囲気が強くなった。
▪ OpsやSREの本領はパフォーマンスの分析でありそこで求められ
る能力は統計やログ解析、アプリケーション解析である。
▪ 大規模SaaSではSREとソフトウェアデペロッパーは別のチーム
▪ SREやOpsに求められる役割は根拠となるデータを示し、設計
フェイズに対してフィードバックを行う事
27

28. 知識と技術
28

29. 知識と技術
論理 センス
知識 技術
学者 職人
コンピュータサイエンス プログラミング
29

30. 知識と技術
▪ どちらが優れているではなく人類が進歩するために必要な両輪
▪ 天才的とされる人材は1人で両方のスキルを兼ね備える場合も
あるが、組織設計においては本来両方が補完関係にあるべき
30

31. 設計と監視 Opsサンドイッチ
31

32. 設計と監視 Opsサンドイッチ
32

33. 設計と監視 Opsサンドイッチ
▪ インフラモニタリング
– →スレッドプログラミングの偏り・メモリリーク検知
▪ ミドルウェアモニタリング
– コネクションプーリング実装の不備検知
▪ アプリケーションパフォーマンスモニタリング
– 非効率な再帰呼び出し実装検知
– cache実装の不備検知
▪ 値から意味を読み取り設計へとフィードバックすることがこれ
からのMSP事業者やSREに求められる
33

34. MSPがこの先生きのこるためには
34

35. MSPがこの先生きのこるためには
▪ MSP事業者やSREは読影能力や設計能力を高める事が重要
である。
▪ 読影能力＝分析
▪ 分析で必要となるのはコンピュータサイエンスの知識
35

36. MSPやSREを活かす開発体制
▪ 分析に基づくフィードバックを適切にソフトウェアの実装に反
映する開発体制が必要
▪ フィードバックを反映しその効果を確認するまでの期間は1週
間以内長くとも1ヶ月以内が理想的
▪ ショートウォーターフォール、アジャイルモデル
36