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

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

発表資料

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

負荷低すぎ問題

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

mikeda.hatenablog.com

aws.amazon.com

Monitoring is Dead

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

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

vimeo.com