株式会社リゾーム システム企画・開発部 第3グループの藤岡です。
入門監視 読書会の第11回目のレポートです。 10回目のレポートは、こちらになります。
読書会の題材
前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン | Mike Julian, 松浦 隼人 |本 | 通販 | Amazon を題材としています。
11回目レポート
今回は、「11章 監視アセスメントの実行」と「付録C 実践 監視 SaaS C.1~C.5」で、参加者は5名でした。
感想・意見交換
ビジネスKPI
- 製品毎に何のメトリクスが取れるか
- 施設数(テナント数)、月次経常収益、顧客あたりの収益
- 顧客あたりのコスト、導入・サポートコスト
- 各種機能の活用率（検索・登録・閲覧）、オプション機能導入率
- 顧客生涯価値
- 項目毎の検索実行数
- ユーザー毎、契約会社毎のログイン回数
- システムの利用状況
- 営業やお客様からユーザーのログイン回数やシステムの利用状況を求められることがあるので、真面目に検討していきたい
フロントエンド監視・セキュリティ監視・アラート
- 本書に挙げられている、ほとんどの項目は流用できそう
- 締め処理など非同期処理が反映されるまでの時間を計測したい
- NewRelicで監視できそう。この辺りをダッシュボード化したい
- ミドルウェア周りの監視(メトリクス取得)ができていない
- Nginx, PostgreSQL
- 秒間トランザクション数とかHTTPレスポンスコードとか、レイテンシとか
- Nginx, PostgreSQL
- 何ができて、何ができてないのかを見直す時がきたのかも
実践 監視 SaaS
- PaaS, SaaS, laaS は確かに料金コストがかかるが運用コストはもっとかかるし、知識・技術の不足やセキュリティのことを考えると利用した方が安心だよな...
- 導入自体は、エージェントをインストールするだけで簡単だが、監視・アラートやダッシュボード設計とかの学習コストはかかる
- 今は外形監視をしているだけなので活用できてないな...
監視SaaSの利点
- チーム全員が監視システムにアクセス出来て、属人化が排除できる
- ただ現状はSaaSを利用しても属人化してしまっているので、使い方の勉強会や手順書の整備は必須
- Mackerelはサーバー監視・New RelicはAPMとして組み合わせて使うとか出来ればいいが、ツールが増えると面倒だったり、お金の問題がある
監視SaaSは信用できるのか
- 疑って手をださなかったらいよいよ何もしないだろうな
- だったら手軽にでも始めるのがきっと正解なんだと思う
- 料金改定・障害発生率・セキュリティインシデント、最近は特に目立つ気がしている
- 運用をサービスに合わせる姿勢は大事だと強く思う
- サービスを運用に合わせることが基本スタンスになっていると、改善も見込めず非常に使いづらい
- GitHub, GitLab, Bitbucket etc... のように類似サービスのコア機能にはほとんど違いがなくなり、差別化された機能や料金、サービス停止や買収なんかの心配をするようになる日が、既に来ているのかも
まとめ
現状、SaaSを利用しても属人化してしまっている、活かすことが出来ていないと思います。 今回の章で課題や検討事項を整理出来たので、その内容を他のメンバーにも共有して改善していければと思います。
