masarasiの日記

私は Mackerel CRE テクニカルサポート担当です。

検索

はてなに入社して1年と7ヶ月ぐらい経つので、自分のMackerel利用歴もそれと同じぐらいなんだけど、最近になってはじめて知ったMackerelの機能がある。

いや、本当は知っていたけど忘れていたのかもしれない。

少なくともこの機能を使った記憶がない。

なんと、Webコンソールの左上には検索ボックスがあって、ここからホストをキーワードで検索できるのだ。

これだ。

試しに linux というキーワードで検索してみる。

ちゃんとホストの管理名にも反応してくれる。

便利だ。

ホスト一覧画面にはサービスやロールでフィルターをかける機能はある。

だけど、検索ボックスはない。あったらいいなと思っていた。

なぜ今まで気づかなかったんだ。

チェック監視

チェック監視を設定したけどエラーになってしまうというお問い合わせは多い。エラーの原因はいろいろあるけど、案外プラグインがインストールされていないケースが結構ある。

それはなぜなのか。理由としては主に下記のようなものがあると思う。

  1. プラグインのインストールを忘れていた
  2. プラグインのインストールが必要なことを知らなかった
  3. プラグインはインストールしたつもりだったけどメトリックプラグインだった

1 は少なくともインストールが必要という意識はあるし、人間なのでしょうがない。しかし、残りは少し性質が違う。2 や 3 に関してはサービスを提供する側のガイドが不足しているのではないか。

Mackerelを使い始めるとおそらくは誰もが目にする導入マニュアルがある。これにはオーガニゼーション作成後にやることが書いてあり、ホスト登録やロール設定、監視ルールの設定、通知の設定、などの基本的な内容になっている。

しかし、プラグインについては書いていない。最後の段落に、もう少し進んだ使い方が書かれている下記のヘルプへのリンクがある。これはリンクが箇条書きになっているだけのかなり素朴な内容だし、導入マニュアルとかぶっている情報もあるので正直微妙である。

mackerel.io

また、ここにもプラグインについては直接書かれていない。カスタムメトリックの投稿についてのリンクがあるので、がんばって読み進めればメトリックプラグインのインストールまではたどり着けるかもしれない。しかし、チェック監視については導線がないのだ。思い返してみればメトリックプラグインがインストールされていなくてエラーになるというお問い合わせはあまり印象に残っていない。やはりチェック監視の存在に気づきづらい状況と言えそうだ。(とはいえ、メトリックプラグインへのガイドも適切かと言われるとそうでもない)

いちおうWebコンソールの監視ルール追加画面にチェック監視という項目があって、ここにはチェック監視を行う方法についてのリンクがある。もしかするとここで気づくユーザはいるかもしれない。しかし、チェック監視の存在はたまたま気づいたとか、見つけた、というものであってはいけなくて、Mackerelを使い始めてすぐの段階から選択肢として認識しておいてほしいもののはずだ。

使い始めのガイドをもっと親切にしてもよいかもな、と思った。

今期の目標軸

少し前にもなんとなくの目標を書いたけど、ちゃんと決めなければいけない。ちょうど今日面談で目標についての話をしたので現状まとめ。

問い合わせを分析する

何のために分析するのかはちゃんと考える必要があるけど、今日の時点でよさそうだなと思っているものは以下。

  • 対応に時間がかかる
    • チーム内でも知見が少なかったりするもの。仕様確認とか検証に時間がかかってしまう。よく聞かれることと、そこから発展して聞かれそうなことをあらかじめ深堀りしておくのは良いことだし、勉強会のネタにもなりそう。
  • 調査がしづらい
    • インテグレーションなどユーザの環境に依存するもの。ユーザの詳しい設定状況はこちらから見えないので、わかっている情報から想像したり、少しづつ切り分けしたり、対応が結構大変。たとえばエラーが原因なら、もう少し詳しいエラーの内容が画面に表示されたり、ログに出るようになるとユーザが自己解決できたり、こちらの調査も楽になるかもしれない。そういった議論をするための情報集めが目的。

これらを対応にかかっている時間や返信回数なども考慮して、対応の優先度を決められるような情報として可視化できるとよさそう。

情報発信

ヘルプなどの更新は最近日々の業務として定着している感があるし、これからもやっていく。

それに加えて、まだ存在しないユーザにとって有用な情報を何らかの形で公開したい。これは公式のドキュメントだともちろんよいけど、それだと書きづらくて結局やらないことになりそうなので、まずは書きやすい個人ブログとかでやっていきたい。発信するという行為が自分には足りなくて、前期の評価を踏まえてもそれを求められていると感じるので、やりやすい方法でとにかく継続しながら、あわよくば公式情報として情報公開できるとよい。

PWG

開発チームのPWGに参加した。

実はPWGの意味をわかっていなくてググったりしていたけど、これってはてな用語だったのか。

mackerel.io

PWGではMackerelのパフォーマンスデータをみんなで眺めて、問題がなさそうか確認していく。サービスの監視はしているし異常があればアラートが上がるから大丈夫、というわけではなくて、日々の細かな変化を定期的に見ることで事前に問題に気づいたりできる。

こうやってデータを眺める時間を取るのって大事だなと思った。テクニカルサポートでもこういうことってできそう。

サポートチケットには問い合わせ種別(設定方法、仕様確認、トラブルシューティングなど)や、機能(監視ルール、プラグインなど)を紐付けできるので、これを少し長めのスパンで見てみるとか。

なんとなく最近こういう種類の問い合わせが多いとかの肌感はあっても、たまたまその1ヶ月だけ多かったのかもしれないし、実は何年も前から話題になっていたことかもしれない。結局個人の感覚だけに頼っても根拠に乏しいので、PWGで見るようなデータとして可視化しておきたい。

そのデータを根拠にどういうアクションを取るのか考えたり、そのアクションの優先度などを議論するっていう流れがチームにあるとよいと思う。CREチームから開発チームへ要望を上げる時にも説得力が上がるし、開発する側も優先度を考えやすいはず。

今でもZendeskで情報を見ることはできるけど、操作などクセがあるしお世辞にも見やすいとは思えないので、Mackerelに投稿してダッシュボードを作りたい。

Mackerelの使い始めやすさ

先日、新しく入社した方のMackerelハンズオンをした。あらためて、Mackerelって使い始めるのはものすごく簡単だなと実感した。

MackerelはサーバにエージェントをインストールするとSaaSのMackerel側にホストが自動的に登録されるので、本当にエージェントをインストールするだけでよい。(in -> out の通信はあまり厳格に制限していない環境が多いんじゃないかなぁ)

監視ルールを作るのも簡単なので、申し込みからあっという間に監視をはじめられる。

前職では監視にZabbixを使っていて、Zabbixもエージェントをインストールするのは変わらないけど、監視サーバから監視対象サーバへの10050番ポートを開けなくちゃいけない。さすがに out -> in の通信は制限しているのでFWのポリシーを変更するのだけど、FWってあまり触りたくない。

LAN側のサーバを監視するときにはFWでポートフォワードしていて、サーバが増える度に10051、10052、10053みたいな感じで受けるためのポートを増やしていくみたなことをいちいちやっていた。LAN側に監視サーバを置く方法もあるけど、面倒を見るサーバは増やしたくない。

そしてMackerelでもかなり問い合わせがあるログ監視の難易度が結構高くて、Zabbixではcheck-logみたいに差分じゃなくファイル全体を毎回見るので、1度でも検知したい文字列がログに出てしまうとローテーションされるまで常にアラートの状態になってしまう。これだとちょっと使い方が限定されてしまう。たぶんそんな仕様なので監視するログファイルのサイズにも制限があって、当時使っていたバージョンはたしか2GBぐらいまでのファイルしか扱えなかった。いちおうアクティブ監視というオプションがあって、これを有効にすると差分でログ監視ができるようにはなったけど、そのためには追加でポートを開けるなどいくつかの条件があった。これがネットを探してもあまり情報がなくて結構苦労した。

Mackerelならエージェントインストールしてcheck-logプラグインを設定するだけで簡単にログ監視ができるし、わからないことがあればサポートに聞けるなんて最高だったりする。

サポートを受ける側の満足度とは何か

何だろう。

「納得感」と「人間味」が重要な気はしている。

納得感については、問い合わせに対して「できない」という回答をする時に、単にできないと言うのと、できない理由をちゃんと説明して相手に納得感を持ってもらうのとで印象はかなり違うはず。自分は前者に偏りがちな自覚はあるので気をつけたい。

人間味については、たとえばユーザが不便に感じていることがあって自分もそこに共感できるなら、自分もそう思うので社内にフィードバックしますね、みたいな伝え方をしてみてもよさそう。「仕様です」という機械的な感じではなく、共感していることを表現することで寄り添ってくれた感じがある。

もちろん、できるだけ早く回答したり、必要以上にやりとりの回数が増えないように気をつけるのは前提にある。

下半期

新しい期が始まった。入社して1年と6ヶ月が経った。

今期は前期に目標にしながらもほとんどできなかった、テクニカルサポートにおいてのユーザ満足度向上について試行錯誤したい。

あとはいつか自分が「これは自信を持ってできる」、「周りの人も安心して任せられる」ものを持ちたい。今はないし、すぐにそうはならないだろうけど、これかも?って感覚ぐらいは見つけたい。