こんにちは、Mackerel CREの
id:do-su-0805です。
この記事では、プロダクト運用において活用されている有識者の経験や知識を、Mackerelの機能を利用して表現することで、特定個人に依存せずチームの知識として活用・運用する事例についてご紹介いたします。
このようなシチュエーションに心当たりはありませんか
開発しているが運用にかかわっていないプロダクトに対して、以下のような状況になったことはありませんか。
- 監視ツールからアラートが上がったが、この監視が設定されている理由や閾値の意味がよく分からないので、詳しそうな人に確認をお願いしている。
- 監視ツールでシステムの状況を見たときに違和感を覚えるメトリックがあったが、運用担当者から「それはいつものことなんで気にしないでください」と言われてスルーし、結局何だったのかよくわからない。
あるいは、プロダクト運用を担当している方で、 以下のような状況になったことはありませんか。
- 監視ツールを利用して監視を設定したが、チームメンバーからよくわかりませんと言われて全部自分が見ている。
- 数週間や数か月に1回だけ発生するメトリックのスパイクについて説明してもみんな忘れるので、このメトリック異常じゃないですかという質問に「いつものことです」と返答して説明しなくなってしまった。
上記は属人化した知識に頼っている側のメンバーと、知識や経験を展開できず属人化してしまった側のメンバーそれぞれの事象例となっています。
今回は具体例を交えて、このような属人化した運用知見をMackerelで表現する例をご紹介いたします。
ケース1 : 有識者がイベントの有無をフォローしているようなケース
シチュエーション
あなたは開発チームのエンジニアです。プロダクトの開発はしていますが、リリースのタイミングは運用メンバーに任せています。
月例のメトリック確認で、結構前のメトリックでロードバランサーの5XX率が急上昇している期間があったことを発見しました。
運用メンバーに聞いてみたところ、数日後に「リリースきっかけで5XXが継続して発生し続けたため、ロールバックした」と返答がありました。
リリースタイミングはお任せしているので、聞かないと理由がわからない状況であると分かりました。
質問者が困ったこと
- 身に覚えがないメトリックの変化があったが、理由がわからなかった。
Mackerelの機能でできるアプローチ
グラフアノテーションを設定する
リリースやロールバック、障害やメンテナンスなどが発生した期間を対象に、グラフアノテーションを設定できます。
グラフアノテーションは、Mackerel上で確認できるグラフに対して、時系列のメモを記載できる機能です。
グラフアノテーションは、Mackerelのコンソール上やCLIツール mkr などを利用して作成できます。
グラフアノテーションを利用することで、ロールグラフやダッシュボード上からこの日に何があったかを確認できるようになります。
今回の例では、5XXが急上昇していた期間に「リリース」「ロールバック」のように状況を記録したグラフアノテーションが作成されていれば、後でもこの状況について把握できます。
グラフアノテーション機能に関するより便利に活用いただけるTipsのご紹介
- グラフアノテーションの一覧を確認できます。
- 今回の例では「メトリックの変化があった日に何かあったっけ」を確認できる例をご紹介しましたが、逆に「あのイベントがあった時メトリックの変化はどうだったのだろう」という確認ができます。
- カスタムダッシュボード上にグラフアノテーションを表示できます。
- カスタムダッシュボードは、Mackerelに投稿されている様々なメトリックなどをまとめて表示できる機能です。
- サービスAのカスタムダッシュボードに、サービスAと連携するサービスBのアノテーションを表示することで、リリースなどとメトリックの変化相関を確認するなど、様々なご利用が可能です。
ケース2 : 有識者がメトリックの見方をフォローしているようなケース
シチュエーション
あなたはサービスチームの運用メンバーで、月例でシステムのキャパシティに問題がないかの確認をチームで実施しています。 アプリケーションサーバの負荷を確認すると、毎月24日の23:10ごろだけCPU負荷が異常に高騰しています。
この原因はなんだっけと開発メンバーから質問されたので、「これは月例のバッチが走って集計用のアクセスを受けているからですね」と返答していました。しかし、説明しても毎月聞かれてしまい、他にも話したい議題があるので、「それは大丈夫ですから次行きましょう」と言うようになってしまいました。
また、普段の表示では100%を上限に表示されているグラフが、このタイミングを含む表示のときだけ上限が高くなってしまい、バッチ期間以外のCPU負荷の機微が確認しづらい状況になっています。
有識者が困ったこと
- 毎月発生するメトリック高騰の理由を聞かれ続け、説明しても忘れられてしまう。
- 異常値が表示されているタイミングでは、他の期間に比べて表示上限が高くなってしまい、CPU負荷の機微が見づらい。
Mackerelの機能でできるアプローチ
カスタムダッシュボードにMarkdownウィジェットを追加する
カスタムダッシュボードでは、メトリックを表示するだけでなく、Markdownウィジェットを利用して説明を記載できます。
今回の例では、ダッシュボードに「毎月24日の23:10ごろに数分発生するCPU高騰は、月例バッチの影響のため無視して構いません。」と記載することで、ダッシュボードを見たメンバーが状況を把握できます。
グラフウィジェットの縦軸を固定する
カスタムダッシュボードで使えるメトリック表示用のウィジェットでは、縦軸の表示範囲を固定できます。
期間が選択されたグラフウィジェットでは、期間内に記録されたメトリックの上限を含めて表示するように自動調整されるため、その他の期間のCPU利用率は縦軸が圧縮されるようになっています。
表示範囲の固定機能を利用すると、「0% ~ 200%」のように表示範囲を限定できるため、上振れした分が表示されないようになります。
カスタムダッシュボードに関するより便利に活用いただけるTipsのご紹介
グラフウィジェットでは、今回ご紹介した表示範囲のほか補助線を設定したり、単位を設定したりできます。
ケース3 : 監視ルールの目的やアラートが発生した意味がわからない
シチュエーション
あなたはチームに異動してきたばかりで、サービスの構成を大まかに理解し、アラート対応を少しずつ実施している状態です。
いくつかの対応には手順書が用意されていますが、配置場所がバラバラだったり、暫定対応で1つ前のバージョンで対応する必要があったりするので、その辺りは記憶やメモでカバーしています。
イレギュラー対応などはエスカレーションして一緒に対応していますが、対応ログの場所が手順書同様バラバラだったり、手順に未記載の対応が実施されていたりしていて、なかなか知識として定着していません。
そんな中、チームメンバー全員でアラート対応をしていくことになり、いままで対応していなかったメンバーへどう伝えていくとよいかや、エスカレーション対応でタスクが溢れてしまうのではないかと懸念しています。
有識者が困ったこと
- アラートの対応方法がアラートだけを見てもわからない。
Mackerelの機能でできるアプローチ
監視ルールにメモを追加する
Mackerelでは、アラートの発生条件である監視ルールにメモを記載できます。
メモ欄にはURLを貼り付けるとリンクとして機能させることも可能です。
また、監視ルールに設定したメモは、その監視ルールを元に発報したアラート画面で確認できます。
監視ルールのメモに対応手順やそのアラートの過去対応を遡ることができるリンクなどを貼り付けることで、アラート発報時の初動を共有できます。
アラートにメモを追加する
また、発生したアラート1つ1つにもメモを記載可能です。
アラートに設定したメモはアラート一覧画面での表示からも確認できます。対応が多岐にわたる場合やイレギュラー対応が発生した場合は、メモに対応方針や対応ログのリンクを記載しておくと、一覧から参照して対応を進めたり、手順を作成する必要がある対応の一覧取得などに利用できます。
メモ機能に関するより便利に活用いただけるTipsのご紹介
今回の例では「アラート」「監視ルール」に設定できるメモ機能について紹介しましたが、Mackerelにはほかにも「ホスト」「サービス」「ロール」などにもメモを記載できます。
また、メモとは毛色が異なりますが、ホストとオーガニゼーションには管理名を付けることもできます。
このようなメモ機能や管理名機能を利用して、情報伝達の補強につながれば幸いです。
まとめ
Mackerelの「カスタムダッシュボード」「グラフウィジェット」「メモ」を活用して、属人化した知識をMackerel上に反映し、チームの知識として共有する例を3つご紹介いたしました。
ご紹介した機能を活用することで、冒頭にあったシチュエーションは以下のように変化させることができます。
- 監視ツールからアラートが上がったが、この監視が設定されている理由や閾値の意味がよく分からないので、詳しそうな人に確認をお願いしている。
- => Mackerelからアラート発報した際に、監視ルールのメモを確認することでアラートの理由や対応手順が分かり、誰でも対応を開始できるようになった。
- 監視ツールでシステムの状況を見たときに違和感を覚えるメトリックがあったが、運用担当者から「それはいつものことなんで気にしないでください」と言われてスルーし、結局何だったのかよくわからない。
- => メトリックの状況を確認したところ違和感を覚えるメトリックがあったが、ダッシュボードに記載された内容から、月例で発生する予期された変化であると、有識者に聞かなくても都度判断できるようになった。
このように運用の属人化をほぐし、システムの運用・監視にチームで取り組む文化を作る「クラウド運用の道標」を目指すMackerelをぜひ一度ご利用いただければ幸いです。
