読者です 読者をやめる 読者になる 読者になる

社内勉強会で「ワクワクする!システム監視入門」という発表をした

勉強会 DevOps Zabbix

社内勉強会で「ワクワクする!システム監視入門」という発表をした.

今年の3月頃から DevOps の推進をメインで担当していて,技術的負債の解消,運用改善,外部サービスの導入など,様々な施策を進めている中で,監視の強化も頑張っている.個人的には相当良くなったなー!と思っているんだけど,先日の Infrastructure as Code 勉強会で @songmu さんの話を聞いていたら「監視に対する敷居を下げるべき」という話があって,非常に刺さった.基本的に每日メトリクスを追っているのは僕で,もしかしたら敷居が高いのかもしれないなと感じた.もっとメンバーにもメトリクスを見てもらいたいし,アプリケーション開発に活用してもらいたい!というモチベーションが生まれて今回の発表に繋がった.

kakakakakku.hatenablog.com

発表資料

(公開するために一部画像を加工してる)

speakerdeck.com

負荷低すぎ問題

メトリクスから余剰リソースが大量にあると判断できる場合は,積極的にインスタンスタイプを下げることもしていて,その背景として @mikeda さんの記事を紹介した.余剰リソースの判定を自動化することはできていなくて,僕の判断で決めているけど,現状の管理台数とロール数を考えたら,運用可能なレベルかなとは思っている.Trusted Advisor に関しても検討しているところで,自動化の案として良さそうなら使おうかなという感じ.

mikeda.hatenablog.com

aws.amazon.com

Monitoring is Dead

Infrastructure as Code 勉強会でも一部紹介されていた "Monitoring is Dead" の話も最後に少し紹介した.意訳すると「モニタリングとはシステムやコンポーネントの振る舞いを観察するものである」という主張だと思うけど,その通りだなと思った.一部のサーバがダウンしたところで,サービス全体に影響がないなら,正常と判断できる.特に Docker や AutoScale を使ってると実際に管理してるサーバの台数を意識することも減ってくるし,まぁ確かに.ただ大規模な分散アーキテクチャは別として,一般的なアーキテクチャだとモニタリングは重要だし,今まで通りに傾向を追っていきましょうという話もした.

動画は凄く面白くて,特にコーポレートサイトの開発をデザイナーにお願いしたら,赤ベースのデザインが出てきて,CRITICAL な色はダメだ!緑だ!緑!という話は秀逸だったwww

vimeo.com

github.com

まとめ

今まで監視に対してここまで整理して話す機会が無かったため,社内勉強会という場で話せて良かったなと思っている.一部のメンバーと雑談した感じだと,凄く興味深かった的なコメントをもらえたし,少しは敷居を下げることができたかも?と思う.引き続き頑張っていくぞ!発表の中で紹介したオススメ本はコチラ!

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置

キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置