MackerelチームのCustomer Reliability Engineerになりました

はてな Mackerel

2020/02からMackerelチームのCRE (Customer Reliability Engineer) になりました。もうちょっと早くエントリを書く予定でしたが、職種が変わった & 期初であれこれイベントが多いということで遅くなってしまった...。

CREになろうと思ったきっかけ

一番大きいきっかけはid:missasanと前期一緒に働けたことだろうなぁと思います。id:missasanはCREであり、現在はCREチームのマネージャーをされています。私がアプリケーションエンジニアとして働いていたとき、id:missasanを含むCREとももちろん一緒に仕事をしていたわけ*1ですが、大きくタスクフォースを一緒に組んで仕事をするといったことはあまりありませんでした。そんな中、今年の夏にid:missasanが通称赤本の読書会をチーム内で始めたので、私もほぼ毎回参加しました。

カスタマーサクセスとは何か――日本企業にこそ必要な「これからの顧客との付き合い方」

カスタマーサクセスとは何か――日本企業にこそ必要な「これからの顧客との付き合い方」

カスタマーサクセスという考え方は、今後のMackerelチームに大事になってくるというのが伝わってくると同時に、CREが今後目指していきたい世界観が伝わってきました。また、チーム内のデータの蓄積 / 整備に力を入れることで、カスタマーサクセスをもっと強く進められそうと思いました。個人的にもデータを蓄積 / 整備していく仕事に興味が出てきており、CREのカスタマーサクセスを下支えするデータ整備人として、前期はid:missasanと一緒に仕事をさせてもらったのでした。

ちなみにデータ整備人をする以前は、Mackerelのロール内異常検知という教師なし学習を使った機械学習機能の開発を行なっていました。データの活用の仕事ですね。

データエンジニアの帽子を被りながら、アプリケーションエンジニアを今後も続けることも可能だったとは思いますが

  • 自分自身もカスタマーサクセスに取り組みたいと思った
  • データ基盤の利用者にもなることによって、より使いやすいデータ基盤を提供できると思った

ということもあり、自分自身もCREになるという選択をしました。アプリケーションエンジニアを離れ、プロダクトのコードを書かなくなるということで不安が全くないわけではないです。しかし、コードを書く以外にもサービスに貢献する方法は様々あるというのをこれまでのCREの働き方を見て感じていましたし、データ基盤やデータ分析をスケールさせるために普通にコードも書くので、あまり不安は感じていないです。不安というより、やっていくぞ、うおお!!!という気持ちが圧倒的に強い。

はてなのCREはいくつか軸がありますが、同僚のid:a-knowさんがエントリにまとめてくれているので、興味ある方は是非見てみてください。

今後やっていきたいこと

結論を先に言うと、データを武器にカスタマーサクセス / プロダクトサクセスを推し進めて行きたいと思っています。

Mackerelは「mackerel-agentをインストールしてもらったら、それで完了!」というプロダクトではなく、カスタマー自身が

  • サービスやロールを通じて、自分のサービスの構成を設定する
  • サービスが高負荷や異常な状態であることに気付けるように、監視ルールや通知チャンネルの設定をする
  • ダッシュボードでサービスの状態を可視化する
  • ...

といったことをしてもらうことで、より価値を発揮し、カスタマー自身の成功に近づいてもらう性質のプロダクトです。買い切りのモデルではなく、カスタマーがMackerelに価値を感じてもらい、継続的に利用してもらうことが重要なリテンションモデルとなります。

リテンションモデルでは、カスタマー一人ひとりが現在どういった状態(例: 躓きがあって、プロダクトをうまく利用してもらえていない)にあるのかを深く知ることが重要になってきます。ありがたいことにMackerelのカスタマーの数は増えてきていますが、それに伴なってカスタマー一人ひとりのことを知ることは以前より難しくなってきます。利用してくれているカスタマーの数が増加しても、カスタマー一人ひとりに寄り添いカスタマーにとっての成功を支える、というCREの仕事をスケールさせるための手段の一つがデータだと思います。

データをうまく活用することで

  • カスタマーの状態をより正確に把握して、素早くカスタマーの成功に結び付けてもらう
  • プロダクトを改善し、より使いやすいものにする
  • カスタマーから連絡を受けて対応する(reactive)だけではなく、予測的(predictive)にアクションを取ることで、より適切なタイミングで働きかける

ことができるようになってくると思います。そして、データの分析やデータからの予測は自分が得意としている分野です。

研究者からWebアプリケーションエンジニア、WebアプリケーションエンジニアからCREと職種は変わりましたが、業界的には同じようなところにいるので、勉強会等で見かけたら是非声をかけてください。

*1:テクニカルサポート関連の質問や最近のリリース項目の技術的詳細などについての質問を受けたり

データに関連するいくつかの見方と私

データ基盤 データ分析

ポエムです。元々書きたかったエントリがあったのですが、長くなってしまったのでパーツ毎に切り出します。

自分のやりたい方向性やキャリア的なものを考えると、大体その中心には「データ」がいます。データに対してどう向き合い方はいくつかパターンがあると思います。

  • データを生成する
    • Webで言えば、アプリケーションエンジニアがここに該当するのかなと思います
    • ユーザーの活動をログとして記録する
  • データを蓄積する
    • 生成されたデータを継続的に蓄積していきます
    • SREやデータ基盤を整備する人がここに該当するかなと思います
  • データを活用する
    • 貯蓄されたデータを使って意思決定に役立てたり、データからの未来の予測をします
    • データサイエンスやR&D的なものはここに該当するかなと思います

この3つに対して、これまで自分がどう向き合ってきたのか、これからどういう風になっていきたいのかをこのエントリでは整理してみます。

データと自分のこれまで

上に挙げた3つの観点で、これまで自分がある程度やってこれたかなと思うのは「データを活用する」と「データを生成する」の2つです。

データを活用する

何だかんだでここが一番長いし、一番の得意分野もここかなと思います。

データを生成する

はてなでのWebアプリケーションエンジニアとしての活動がここに当たります。

  • 上(フロント)から下(サーバーサイド)までデータを生成する箇所は様々あります
    • Mackerelの場合は特殊で、ユーザー以外にもmackerel-agentやそのプラグインもデータを生成しますし、その開発にも携わってきました
    • データの生成元であり、定義元であり、ドメイン知識を身に付けることができました
  • 当たり前ですが、データの生成以外で気を使うところもたくさんあります
    • 可用性 / UX / インフラコスト / 継続的にメンテナンスできるか / などなどなど

どれかを極める or 全部やる

どっちもありだと思います。自分のキャリアは基礎研究職から始まったわけなので、「データを活用する」を最初は目指していたことになります。しかし、データに関することを考えると、生成 / 蓄積 / 活用のどれが欠けてもうまく回りません。

  • 「生成」が欠けると...
    • データが欠損して蓄積されません
    • ロジックが意図通りになっていなければ、矛盾を孕んだデータが生成され、データの活用時に支障が出ます
  • 「貯蓄」が欠けると...
    • 必要なデータがないため、データの活用ができません
      • サービスに直接影響が出る場合
        • 例: メトリックが投稿できない、課金に関するログが正常に出せていない
      • サービスには直接の影響はないが、間接的に影響が出る場合
        • 例: KPIの数字が正しく出せない、データ欠損により精度の低い(分類|推薦)が行なわれてしまう
  • 「活用」が欠けると...
    • データがただ蓄積されるだけで価値を生まないのであれば、それはゴミを蓄積しているだけです
    • 意思決定に関するデータが活用されなければ、意思決定のスピードは落ちたり、精度が低いものになったり、メンバーからの納得度の低いものになってしまいます
    • ログやイベントのようなデータも活用されなければ、本来はユーザーに提供できたはずの価値(例: 推薦や異常検知)を発揮できないままです

データとsyou6162の今後

データに関連する分野は非常に広大なので、一人で全部を同時期にやるというのは相当スペックの高い人でないと難しいと思います*1。チームで分担することで「自分はこの中のここを極める」といった選択も当然あると思います。一方で、人生のとある時期はこっちをやり別の時期ではあちらをやって、トータルでデータに関連するところを全部見れる、別の分野を知っているからこそ強みを出せるといった選択も考えられます。そして自分の嗜好としてはこちらだなと最近思います。

データの生成 / 蓄積 / 活用の3つの中で「蓄積」に関するところが自分のこれまでの経験ではすっぽり抜けており、そういったこともありデータ基盤の構築をやり始めました。基盤構築自体も楽しいですし、基盤構築をある程度自分で面倒見れるようになったからこそ見えるデータの生成 / 活用の楽しさもあると思います。今後しばらくはデータを蓄積する基盤構築を仕事として取り組みます。

それに伴なって2月から変わるところがありますが、それはまた別のエントリで。

*1:趣味サービスならまだしも、仕事ではやるのは私は無理...

近況報告

データ分析 Mackerel 機械学習

生存してます。最近色々インプットしまくることに時間を取ってる結果、アウトプットが死んでいました。記憶がまだあるうちにまとめて書いておきます。

MLCTで登壇しました

前回も登壇させてもらっていたMLCTのパネリストとして登壇させてもらいました。お声がけいただいた@hurutoriyaさんに感謝。

テーマは「アンチパターン」。SNS共有厳禁なので詳しくは書けないですが、大雑把にはこんな感じでした*1。

  • 5年前はあまり当たり前でなかった機械学習の運用知見、少しずつ業界でノウハウが溜まってきている
    • 特に打ち合わせしてたわけではないですが、こういう感じでやっています、というのが各社結構似ていた
  • 機械学習単独の話題、というよりソフトウェアエンジニアリングを当たり前にやっていく

Mackerel Drink Up #9 Tokyoで登壇しました

Mackerelのdrinkupで最近の機能リリース3本のうちの一つということで7月末に正式リリースをしたロール内異常検知についてお話しさせて頂きました。スライドの内容としては新しい内容は特にないですが、自分がメインで作った機能がこうして世の中に出て、ユーザーさんに使ってもらってフィールドバックをもらって、という場があるのはありがたいですね。

もちろん、これまでも機能開発自体には携わってきていたわけですが、プロトタイプから大体担当していたものだけあって思い入れが結構大きいのかなと思います。OSSやSaaSで異常検知エンジンはぼちぼち出てき始めている中で、以下のようなことを考えながら作っていました。

  • Mackerelの特徴をどう生かして機能をデザインするか
    • ロール内異常検知単体で存在するわけではない。Mackerelというサービスの中でどういう問題を解決するものなのか、既存の機能とどう補完し合うものなのか
      • 機械学習で全ての問題を解決しようとしない
    • アラートや障害対応する人との関わり方。人間をどうサポートするか
  • MLOps的な観点、メンテナンス性、コスト

首都大で非常勤講師を担当しました

学生時代からお世話になっている首都大の小町さんからお声がけいただいて、非常勤講師として講義を担当させてもらいました。一人一日 * 4日のうちの一人として担当しましたが、他の講師の方(Amazon 荒木さん @ar1 / クックパッド伊藤さん @takahi_i / PFN 小嵜さん @smly)が豪華だったのでこれはヤバイな...と思いながら頑張って資料を作っていました。

大学での講義(しかも実習)自体が初めてだったため、どれくらいうまくできたかは謎だったのですが、感想をパラパラ読ませてもらった限りではなかなか好評だったようでよかったです。とはいえ、学生さんの色んな手元環境を想定しきれていなくて本質的でないところに時間を割かせてしまったりした箇所もあったので、また機会があれば資料もブラッシュアップしていきたいなと思います。

データ基盤構築活動をやってます

今期(8月)からチーム内のデータ基盤構築をやり始めました。データ基盤、いつか関わってみたいと思ってはいたものの知識は特にない初心者でした。あれこれ勉強すべく、都内での出張タイミングで色んな勉強会に顔を出させてもらったり、社外の人や社内の経験のある人にひたすら知見を聞くということをやってました。例えばここ。

技術的なことはもちろん、データ基盤をどうやって使ってもらうかが不安だったため、どういった工夫をされているか着手前に聞けたのはとても役に立ちました。ある程度運用が上手くいき始めたらこれもどこかで発表したいですね。異常検知と違ってデータ基盤は各社やっていると思うので、目新しさはあまりないかもしれませんが...。

  • チームKPIを出すための業務フロー可視化 / フロー整備
    • スクリプト化 / 自動化
  • 何を出すべきか、その意図は何かチーム内関係者にひたすらヒアリング
  • BigQueryを中心にデータ基盤構築を考えていたため、Embulk / Digdagを使ってデータ転送
  • BigQueryにデータが入り始めた段階で、Data Studioを使ってプロトタイプ的なダッシュボードをいくつか作った
    • 「みんなこれを見ようぜ」という完成系を一気に作る、というよりはBigQuery経由するとこういうことできますよ、というのをチームメンバーに少しでも思ってもらえれば、という意識が強い
      • BigQueryだけ用意しても何ができるか分からんと思うので、各職種の人に響きそうかなと思うダッシュボードのプロトタイプをがっと作った
      • 作り込み自体は必要な人がやれるように、後述しているようなサポートを意識
    • Data Studioは細かいところでは微妙(ヒストグラム書けないとか)だと思いつつ、初手で運用の手間のかかるものを増やしたくなかったので採用
  • CREがやりたいと思っている分析をスムーズにやれるようにしたかったので、Mackerelを題材にしたSQL100本ノックを作る
  • 社内の他チームでもデータ分析をやり始めたチームがあった && 結構同じようなことをやっている / 困っていたので、社内勉強会を開始
    • 参加者の半分近くがエンジニア以外の職種の方。エンジニアのみでやっていても仕方ない領域なので、ありがたい...
    • これも数回回してみたらどこかにアウトプットしたい

やっていきます。

*1:このくらいの粒度での共有はOKと確認いただいてます

Twitter検索結果の語義曖昧性を解消するsaba_disambiguatorのアップデートを行ないました

Mackerel Go

タイトルだけ見ると何のこっちゃという感じですが、前提としてはこんな感じです。

今回はこのツールのアップデートに関する話です。

apexからAWS SAMへ

リリースした当初はAWS公式のcli経由でのdeployツールは(確か)存在しておらず、apexを使っていました。

便利に使わせてもらっていたのですが、今年の夏にNo longer maintainedとなってしまっており、AWS SAMに移行しました。

AWS公式である安心感やCloudFormationっぽい形で必要なIAMやCloudWatch Eventも一緒に管理できてよいですね。

TweetをBigQueryに転送できるように

Slackでサービスに関する言及が流れてくるのはよいのですが、使っているうちに例えばこんな欲が出てきます。

  • サービスへの言及数が最近多い気がする。先月と比べるとどうなんだろう
  • この機能要望多い気がするけど、定量的に見るとどうなんだろう
  • 今月よく言及されていたBlogのリストをピックアップしたいけど、Slackの履歴を一月分遡るのダルいな...

定期的に手動で集計するのは手間なので、よしなに分析できるようにBigQueryに転送する機能を追加しました。

BigQueryに送っておくと、例えばこういったことがData Studioで分析 / 可視化できます。

Tweetの一覧が簡単に遡れます。meetup開催直後の期間に絞ったり、ユーザーを絞ったりすることも簡単です。Data Studioは画像のURLを書いておくと画像も表示できるので、アイコンも表示されて便利ですね。

Tweet一覧

時系列で言及数の推移を見ることができます。11/6が特に多いですが、ダッシュボードで調べたところ、プレスリリースが出た日でした。

言及数の推移

どういうブログに関しての言及数が多いんだろうというのもすぐ分かります。

言及数が多いURL一覧

dependabotの導入

利用しているライブラリのアップデートは定期的にやっていきたいですね。dependabotが便利なので、導入しました。それをやるためにGo Modulesもちゃんと使うようにしました。

PR: このツールのアップデートは業務時間を使って行なわれました

saba_disambiguatorのようなちょっとしたNLPツール、サーバー監視を支えるための機械学習を使ったロール内異常検知などを開発しています。ご応募お待ちしております。

はてなで一緒に働きませんか？

最近の砂場活動その13: Vue.js + Nuxt.jsで構築したアプリケーションをTypeScript化する

Vue.js Nuxt.js TypeScript

趣味プロジェクトであるML-Newsのフロントを整備したのは約一年前。その頃はVue.jsのTypeScript対応も微妙な時期(?)だった。

ちょいちょいTypeScriptサポート対応したよという声も(個人的に)見るようになった気がして、自分もやってみることにした。趣味プロジェクトのように忙しいときは結構触らない期間があるプロジェクトでは、型が分かったりlinterで怒ってくれるサポートがあるのはありがたいのである(普段はScala / Golan /Python with mypyで生活しているので)。

やったこと

困ったこと

導入するためにちょい困ったりはしたけど、得られた恩恵のほうが大きいかなという印象です。

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発

最近の砂場活動その12: Data Studioを使ってGoogle Analyticsと任意のデータを紐付けてデータ分析する

データ分析 Data Studio

仕事でデータ分析をやる機運が高まっていて、Google Data Studioをぼちぼち使っていこうとしてる。仕事のデータは分析する前のデータパイプラインなどあれこれ考える必要があるので、ひとまず趣味プロジェクトのML-Newsを題材にして遊んでみる。こういうときに雑に遊べる砂場プロジェクトは最高。

Data Studioの大雑把な概念

Data Source

Data StudioにはData Sourceという概念がある。Data Sourceは名前の通りデータソースで分析をかける対象データを指す。例えば

  • Google Spreadsheet
  • Google Analitics
  • BigQuery
  • Cloud Spanner
  • Search console

などなど様々なものをデータソースとして指定できる。手元のcsvをアップロードするFile Uploadなどもある。

Reports / Explore

同じようにグラフが書けて似ているなって感じだけど、こういう使い分けかな。

  • Reports: みんなで定期的に見るダッシュボードを整理する用
  • Explore: データ分析担当者が探索的に条件等を指定して分析速度重視でやる用

綺麗にやるのは後でやるとして、Data Studioで何ができるか知りたいので、Exploreを先に触った。ここでは中心となるData SourceをGoogle Analyticsとする。

ページタイトル毎のPVなどをテーブルに吐き出したりグラフに描画できて、便利は便利であるけど、これ単独ではGoogle Analyticsでできることとあまり変わらない。ちょいちょい触った結果、威力を発揮しそうなのは複数のデータソースを統合する時かなと思った。SQLでいうjoinを相当ができると思うとよい。

複数のData Sourceを統合して分析

ML-NewsのURIはこういう感じになっていて、以下の数字の箇所がDB内のexample_idというものに対応している。

このexample_idに関連するtweet一覧やブコメ一覧をDBの中に持っている。ちなみにDBではtweetのスキーマを以下のように持っている。

go-active-learning=> \d tweet
                                             Table "public.tweet"
      Column       |            Type             |                         Modifiers
-------------------+-----------------------------+------------------------------------------------------------
 id                | integer                     | not null default nextval('tweet_id_seq'::regclass)
 example_id        | integer                     | not null default nextval('tweet_example_id_seq'::regclass)
 created_at        | timestamp without time zone | not null
 id_str            | text                        | not null
 full_text         | text                        | not null
 favorite_count    | integer                     | not null
 retweet_count     | integer                     | not null
 lang              | text                        | not null
 screen_name       | text                        | not null
 name              | text                        | not null
 profile_image_url | text                        | not null
 label             | integer                     | not null default 0
 score             | double precision            | not null default 0.0
Indexes:
    "tweet_pkey" PRIMARY KEY, btree (id)
    "example_id_id_str_idx_tweet" UNIQUE, btree (example_id, id_str)
    "example_id_idx_tweet" btree (example_id)
Foreign-key constraints:
    "tweet_example_id_fkey" FOREIGN KEY (example_id) REFERENCES example(id) ON DELETE CASCADE

よって、example_idを軸にjoinしてあげれば、PVと言及があるtweet数などの関係を解析することができる。これはあくまで一つの例であって、他にも例えば

  • 顧客の満足度(別のアンケートが手元にある想定)とWebサイト上での使われ方(Google Analiticsが持ってる)
  • 顧客毎の売り上げとWebサイト上での使われ方(Google Analiticsが持ってる)

といったことが業務関連だとできそう。

複数のData Sourceを統合するにはData SourceをBlended Dataというものにする必要がある。

tweetの元データはAWS上のRDSに存在する。業務で真面目にやる場合は何らかのデータパイプラインを組んでBigQueryに定期的に流す、といったことが必要になる(この辺はあまり詳しくない...)と思う。しかし、今回はアドホックな分析がしたいだけなので雑にやる。

  • SQLを叩いてcsvとして手元に落としてくる
  • そのcsvをData Sourceの一つとして選択できるFile Upload経由でGCSに保持

雑にこういった感じのコマンドでcsvにする。

psql -U postgres -h hogehoge -d go-active-learning -p 5431 -F "," -A --pset footer -c 'SELECT example_id, favorite_count, retweet_count, screen_name FROM tweet;' > tweets.csv

統合されたData Sourceの完成系はこういう感じになる。Join keysを元にどう繋ぐかを決定する。統合後に分析対象としたいものはDimensionsやMetricsに入れておく。左側がGoogle Analitics、右側がDBから抽出したcsvをData Sourceに指定したもの。

Google Analitics側はどの情報を元にexample_idとすればよいか当然知らないので、指定する必要がある。Google Analiticsのデータソースは、関数を使って自分が必要な列を持たせることができる。今回必要な情報はPage Pathというところにあるので、それを正規表現を使って抽出する。

Google Analiticsで持っている各行のデータには今回の解析の対象外(個別のページではなくカテゴリ別のページ、など)としたいものも存在する。そういったものはFilterを使って抽出する。今回はPathの情報とタイトルの情報を使ってフィルターを書いた。

あとは分析しまくる

ここまでくれば後は簡単。やりたい分析をやるだけ。棒グラフや散布図を書いて自分が欲しい情報を抽出してくればよい。Google Analiticsだけで分からない分析の例として、Page Viewsとretweetされた数の総数の関係を散布図で書いてみた。

各点のページタイトルもしゅっと分かるので、深掘りなどもすぐできる。といっても深掘りするのもめちゃくちゃ簡単で、散布図中の深掘りしたい点をクリックしてやると他のテーブルや図もその条件に勝手に絞ってくれる。

感想

Data Studioを使ってみる前はデータソースをあれこれ指定してダッシュボードで可視化できる君くらいに思っていたが、join相当のことができると知って印象ががらっと変わった。join keysのことを意識しつつ、何らかの形でデータソースに上げることができれば分析可能になるので、エンジニアとしては(ひとまず)データを上げるところまでを考えれば使ってもらえる形にできる。分析者視点としてはデータソースにまで上がっていれば、複数のデータソースを統合してより詳細な分析をExploreでアドホックにやったり、みんなで見るダッシュボードを整備するといったことができる。かなり便利であることが分かったので、もっと使い込んでみようと思います。

参考

Machine Learning Casual Talks #10でMackerelのロール内異常検知について発表しました

登壇 異常検知 Mackerel

メルカリさんのオフィスで開かれたMachine Learning Casual Talks (MLCT) #10に「教師なし学習によるMackerelの異常検知機能について 〜設計/運用/評価の観点から〜」というタイトルで登壇してきました。

MLCTは機械学習をサービスで運用していく知見を共有する勉強会です。YouTube等で動画配信を積極的にしてくださっていて、はてなの京都オフィスでも鑑賞会と称してランチタイムに同僚と発表を見させてもらっていました。普段から勉強させてもあっていた勉強会に、登壇という形でちょっとはお返しできているとうれしいです。登壇させて頂き、ありがとうございました!

私の発表資料はこちらです。スライド46枚ありますが、発表は15分だったので本番はこれの短縮バージョンで発表させてもらいました。

f:id:syou6162:20190530065428j:plain

‪@chezou‬さんのこういうTweetもありましたが、開発者の僕自身結構胸熱(?)で、発表の見所としてはMackerelというプロダクトの概念にフィットするものを、運用が大変にならないようにいかにシンプルに作るか、というところです。具体的にはこういう感じ。

  • どの単位で異常検知モデルを作るか
    • 全体で一つだと大きすぎる、ホストに一つだと細かすぎる
    • Mackerelというサービスの根幹にある「ロール」という概念をうまく利用する
      • ロールは例えば、はてなブログのDBサーバーというようなグルーピングのことです
    • 異常検知のために特別な設定をしてもらうというより、Mackerelの概念に沿って使ってもらえば、異常検知も自然とうまく動作するような設計を目指した
    • プロダクトが先、機械学習が後
  • ホストを異常と判定したときに、その根拠をどうやって提示するか
    • 世の中的には、ブラックボックスのモデルを人間が解釈可能な近似したモデルを用意する(例: LIME)のが主流になりつつある
    • しかし、運用観点では管理しないといけない機械学習モデルが増えて厳しい。予測のlatencyの増加という観点からも望ましくない
    • 異常判定に使っている混合ガウス分布の条件付き確率分布を計算し、どのメトリックが異常かを判定している
      • 混合ガウス分布は性質のよい確率モデルがベースにあるので、条件付き確率も閉じた形で書き表わせる
      • 根拠提示用にもう一つモデルを用意する必要がない
    • 混合ガウスを使っていたとしても、混合数が大きかったり次元数が高いとlatencyなどの観点では厳しいが、ここでも「ロールに対してモデルを作る」ということが効いてくる
      • ロール内では状態数はそこまで多くならないので、混合数はそこまで大きくする必要がない
      • 判定に必要な次元数を抑えるため、ドメインエキスパート(つまり監視のプロである社内のSRE)にどの特徴量は削っても監視には影響なさそうかヒアリングしにいった
  • 誤検知を防ぎたいが、教師なしであるモデルの挙動を人間の直感とどう合わせるか
    • ほぼ動きがないメトリックがほんの少し動いた場合、モデルは異常と判定するが人間はそれを誤報と感じる
    • なるべく人間の直感に合うように振る舞わせたいが、教師ラベルを整備して制御といったことは教師なしではできない...
    • 混合ガウス分布を選択したことがここで生きる
    • 混合ガウス分布は由緒正しき(?)確率的生成モデルであるので、分散の事前分布に「memoryで全体のX%くらい変動するのはまあありえるよね」といった人間のドメイン知識を埋め込む
  • 継続的な改善
    • 自動で取れる数値はダッシュボードにまとめているが、手動でのアノテーションでのシステム評価にそれなりに力を入れている
    • ほぼ全ての異常検知によるアラートに目を通し、正しいアラートか誤報かのアノテーションをしている
      • 誤報率を時系列でトラッキング
    • 誤報の中でカバレッジの大きいものに関しては改善の施策を実施、施策の実施後には再度アノテーションをして実際に改善しているか確認、というのをひたすら繰り返している

発表に対する反応

合わせて読みたい