こんにちは、マネージドサービス課の橋本です。最近はAthena、QuickSight、Jupyterあたりが仲良しなプロダクトです。

今日のトピックは弊社が展開している「AWS運用代行」というサービスの内側の話です。中の人の一員として、サービス改善のために実施している取り組みの一つを簡単にご紹介したいと思います。

背景

弊社の「AWS運用代行」は、監視基盤とチケットシステム、24/365の有人対応体制などを中核とする運用サービスです（資料はこちらよりダウンロード可）。ざっくり説明すると、障害発生時の対応フロー(実施する作業内容や関係者への連絡の方法など)をお客様と弊社の間で事前に取り決めておき、本稼働後はこれに準じた障害対応を実施するというものです。

サービス基盤の開発を手がける者や、現場で受け入れ調整を行う者、業務フローの改善を担う者など、様々な関係者によって運営されている本サービスですが、その中で私が関与しているのが所謂データ分析のセクションになります。

現時点の状況は、分析に必要なデータを集める仕組みが軌道に乗りそう、ぐらいの感じです。機械学習のような高度なタスクはほぼ実施していません。ゆくゆくはそちらにも展開を広げていくつもりです。

今、何をしているのか

集計／可視化／考察／改善アクションの提案と（必要に応じて）実行、といったところです。内部のオペレーションを効率化するネタが今の検討の中心です。

R&D的なタスクもいくつか手を出しています。ネタ的には自然言語処理や協調フィルタリングあたりが絡みます。

現在は一段落しつつありますが、以前は集計の仕組みを立ち上げるために開発や運用現場の方と諸々調整したりもしていました。

直近の活動としては、QuickSightを使った障害チケットの集計・可視化を行いました。これについて、以下でご紹介します。

QuickSightでアラート発生数の可視化

分析するにもまずは集計と可視化からということで。チケットシステムのチケット数を集計してみました。

システム概要

概要構成図を以下に示します。基本的には、チケットシステムで発生した何らかの状態変化をLambda Functionにトリガーし、更新後のチケット状態をS3にどんどんPUTしていくことで集計の元データを蓄積しています。分析担当者は、蓄積したデータをAthenaやQuickSightを用いて眺めていくことになります。

可視化してみる

実際の画面サンプルを以下に示します。

アラートの発生数を顧客ごと／アラート種別ごと／時間帯ごとで把握する狙いのグラフを作成しています。Controlsで期間条件を付けています。チケット単位の対応工数なども取得可能です。

集計タスクの内容によってはAthenaでクエリすることもあります。必要に応じてPythonやExcelを用いてレポーティングすることもあります。

考察する

可視化を行う一番の目的は、改善業務のリソース配分を効果的に決めるための判断情報を提供することです。障害実績の傾向を把握することで、時間帯に応じてアサインしておくべきリソース量の当たりを付けたり、頻発傾向にあるアラートの対応工数省力化を検討したり...といったようなことに利用します。数字のレポートと考察、可能なら改善案の叩きを添えて定例などで報告します。

以前に手がけた集計タスクの事例を、1つご紹介します。以下。

CPU／メモリなどのリソース系監視項目は、経時によって自然回復するケースがそれなりにありました。そこで「アラート発生から回復するまでの時間」を顧客横断でサンプルし、復旧時間の分布を眺めてみました。この分布を累積の形で表現すると「このアラートがN分で自然回復する割合はXX%」といったことが視覚的に表現できます。データサンプルが集まれば、この分布をより細かいグループ（顧客ごと、もしくは監視対象ごと）で見ることも可能でしょう。

...と、このような共有を行いました。字面だけでも寂しいですので、実際に可視化した様子を下の図で示します。これは、あるリソース系アラートについて、障害発生〜復旧までに要した時間（つまり復旧時間）を累積分布で図示したものです。指数的な積み上がりをしている様子が見て取れるかと思います。

上記の共有を行った後、チーム内で次のような議論がありました。

リソース系アラートの対応フローは、「発生時点では通知のみ実施して一時的に静観する。アラート状態が長時間継続された場合にはチケットの緊急度を上げてエスカレーション対応を行う」としているケースがそれなりに多く存在している。「一時的な静観」のしきい値を、先の集計結果を基にいい感じに調節できれば、担当者が目にするアラート通知のS/N比が改善するのではなかろうか？

基本的にアラート通知の設定は、取りこぼしたときの罪が深い分「通知が過剰気味になろうとも、漏れなく通知する」方針に寄りがちです。クリティカルレベルの障害通知のS/N比が改善することで、運用担当者の負担を減らすメリットに繋がるはずだ、と。

現在のAWS運用代行サービスですが、リソース系アラートの「一時的な静観時間」のデフォルト値はこの集計結果を基に決定しています。数字の根拠は正直厳密でない部分もあると思いますが、当てずっぽうに静観時間を決めるよりは実績に基づく分だけ信頼できると思われます。

雑感

今の取り組みについて、考えていることなどを雑に述べます。

今後目指していきたい方向性

ここまで述べてきたことは、基本的に「今既に存在するもの」を何かしら改善していく観点です。私としてはもっと色々な方面に活用していきたい思いが強く、ぼんやりと次のような展開を考えています。

(1) 「攻めた」改善をやる

統計や機械学習のエッセンスを含んだ何かしらができればと思っています。たとえば、要エスカレーションの事象（≒チケット）の発生に対して、近しい過去対応実績をレコメンドして対応速度の向上に繋げたり...とか。

正直まだ妄想の域を出ませんが、（私自身の趣味と実益を兼ねて）ここは進めていきたいです。

(2) マネジメント層への交渉材料にする

「こういう取り組みしたいからこのぐらい金（or人）出して」などの交渉を有利に進められるようにしたいなぁ...という趣旨です。適切な投資を引き出すためには、定量的な議論の材料を示すことは必要であろうと考えています。

改善は泥臭い

考察して「こうした方がいいよ」と言ってみても、アクションを伴なければビジネスの成功にはつながらないわけで...。実装に落とすために基盤システムの仕様を把握する必要があったり、現状の業務ルールとの兼ね合い、既存環境への適用可否や適用方法、告知の手段などなど、考えるべきことはそれなりにあります。

数字を扱うことよりむしろ、その結果得られた示唆をビジネスの成果につなげることの方がよほどハードなタスクだなと最近は感じます。

まとめ

まずはデータが取れる & 見える環境づくりから、ということで取り組みを始めてみました。執筆時点（2019年1月）ではデータ収集と可視化が形になってきた、というところです。機械学習のような意識高い系ソリューションはまだまだこれからですが、そうした技術が適用できる問題領域も今後出てくると思いますので、活用していきたいですね。随時改善を回していきますので、弊社のAWS運用代行を引き続きよろしくお願いいたします。