株式会社リゾーム システム企画・開発部 第4グループの尾古（@patorash）です。
「現場で役立つシステム設計の原則」読書会が終わりましたので、先週から社内の有志で新たに読書会を始めました。 それをレポートしていきたいと思います。
読書会の題材
読書会の題材として選んだのは、入門 監視 ―モダンなモニタリングのためのデザインパターンです。
複数の候補がある中で決戦投票を行った結果、大差でこちらに決まりました。
皆、どう監視と向き合っていけばいいか、何をどう監視したらいいかを理解したいというのが現れていたかと思います。
読書会の進め方
進め方は、「現場で役立つシステム設計の原則」読書会のときと変わらずです。
- 当日までに事前に章を読んでおく
- 感想や疑問点をまとめる
- 読書会当日、感想をそれぞれ発表する
- 意見交換を行う
- まとめをYammerにアウトプットする
ただ、感想を書くときには、以下のような形にしてもらうよう、お願いしました。
- 事前に1章分を読んでおいて、本の感想・疑問点・質問をまとめておいてください。
- ※要点をまとめないでください。
- 感想・疑問点・質問は、なるべく業務や過去の経験と絡めた形にすると助かります。
- 経験知をシェアしましょう。
これは、プロダクト開発での課題・困り事と紐づけて考えてもらうことで、本の内容をより咀嚼することができると思ったからです。
1回目 レポート
初回は「1章 監視のアンチパターン」でした。参加者は6名でした。
出てきた感想
ツール依存
- やりたいことをはっきりさせていく事が大事
- 何を監視するべきなにかを理解しないといけない
- 監視が目的になると、ツール依存やチェックボックス監視になってしまう
- 目的と手段が逆転してしまう開発あるある
- 最初は何らかの問題解決を目的としていた筈が、あるツールを採用後、使い倒すために道具を使う方向にシフトしてしまう
- ツールや技術から選ぶと大体失敗するので、今ある課題を解決するために必要なものを探すという方針は、常に頭の中に入れておけたら苦労しなかった
- ツールに依存するほど使えてない気もする…
自分でツールを作らなければならないときもある
- 以前の職場で監視業務をしていた時は、同僚が作った自作ツールがいっぱいあって、めちゃくちゃ便利だった
- 何だかんだどのCIツールも最後はシェル力が問われるところがある
- 自分でツールを作っても良いという発想は無かった
- 一から作成するのは大変なので、既存の監視サービスに組み込む形がいいのかもしれない(MackerelのカスタムメトリックやNew Relic Flex)
役割としての監視
- 監視専門の人がいればなー、と思っていたが、それではいけないのだなと気づいた。
- 監視しやすいシステムはチームワーク・連携力が段違いだった記憶。
- 監視している誰かがログやアラートを共有してから、例えばアプリ担当者やコンテンツ作成者が心当たりを調査する。
- なので行った操作・出力されたエラーが即時連携されること、これを受けた関係者が即座に自分のこととしてレスポンスを返すこと。
- この辺りが綺麗に流れない組織だと、見通しは一気に悪くなる印象。
- 「オペレーションチームだけでなく、全員が本番環境全体に責任をもつべき」
- すごくいい言葉。自分事にしないと、なかなか身につかない
- 全員が全員、ここまで意識はできていないと思う
チェックボックス監視
- 耳が痛い話。痛いけれど、この監視は不要ですと言い切れる自信もなかったりするよなぁと思う
- 現場に当てはめて考えてみた
- 「メトリクスは記録しているがシステムがダウンした理由がわからない」
- とりあえずサービスを再起動してみることが多いかも
- それで直ったら調査を後回しにしがち
- 「後検知が多すぎるのでアラートを常に無視する」
- 誤検知ではないが、うるさすぎて無視していたことがあった
- 「リソースがギリギリでもレスポンスタイムが許容範囲内なら問題ない」
- 確かに
- むしろリソースを上手に使い切っているとも言える
- 動いているかを定義するのが大事なんだなぁ
- 「メトリクスは記録しているがシステムがダウンした理由がわからない」
「動いている」とはどういう意味か
- 実際の業務では非機能要件の可用性・パフォーマンス辺りの話になってくるが、であれば関係各所との調整必至で明確な答えのない問題
- 監視初心者としては書かれている内容は分かるが、どの程度にしたら良いのか悩んだり迷ったりして固まりそう
監視を支えにする
- 暫定対応としてはありだろうけれど、常態化はよくない。リファクタリングが終わるまでの役目にするべき
- Webアプリのバグ(開発環境やステージング環境で発見可能なレベル)を、本番環境にデプロイしてからインフラ担当者に指摘されることが常習化している現場はあった
- よく指摘されていたのは「Webアプリを実装するエンジニアがあまりログを見ない」というもので、保守・運用経験が少ないとログをよく見る癖が付いていなかったり、障害調査がしやすいログ設計ができなかったり、ということがままある。ログ設計できるようになりたい。
手動設定
- 自動設定できるようになりなさいってことで、やはり入門監視の前にAnsibleに詳しくなるべきではないだろうか…。しかし、日常的にサーバ管理やってるわけではないから、すぐに忘れてしまう。
- 既に動いている自動化されていないシステムを自動化するのは大変
- できることなら開発の早い段階から、理路整然と自動化されたシステムを構築するのが良いんだと思う
その他、色々
- ツールを増やすのを恐るなという話。確かにと思う反面、多すぎて把握できなくなるのでまとめたいという話も出てくる
- ツールの導入にはお金の話も絡むので、簡単に試せないケースがある
- 監視ツールを常に表示しておくためのディスプレイ欲しいなぁ〜と思った
- 会社で導入している監視ツールでどういうことができるのか確認してなかった。調べておきたい
- 自作ツール、作るのはいいけれど、メンテが大変になるケースもちらほら…。
まとめ
アンチパターンの章ということもあって、皆グサグサと刺さっていたと感じました。耳が痛い話ばかりでした。「やりがちですね」とか、「とはいえ、どう設定すればいいのかがちょっとわからない」とか、今の現場での困り事と絡めての感想が出てきて、より自分ごととして考えることができているなと思いました。
ツールを増やしてもいい、自作してもいいというメッセージは、すごくよかったなと思います。いわゆる俺得ツールを自作していくようになっていけば素晴らしいと思います。
次章は「監視のデザインパターン」なので、今からとても楽しみです！
