Support Engineer Night vol.2
サポートエンジニアNight vol.2 に参加してきました！ #supennight
メモ、感想などを書きます。 📝
Cloudera のサポートエンジニアリング
Cloudera は 機械学習と分析のための基盤( Hadoop など)を提供している会社で、サポートエンジニアは年間契約のサブスクリプション(有料サポート)の中の人という立ち位置。
おおまかな拠点はアジア、ヨーロッパ、アメリカの3拠点だが日本語のサポートは日本のタイムゾーンの日中に限られているらしい(日本語を話せるメンバーが少ないため)。
サポートと言っても複数のチームに分かれていて、お客さんと直接やり取りするチームやそこからのエスカレーション先として対応したりクローズした問い合わせの分析・製品ロードマップへの反映を行なうチーム、製品のドッグフーディングやサポートシステムの開発を行うチーム、クローズした問い合わせを全てレビューしコミュニケーションについてのアドバイスを行なうチーム、サポートチームに特化した技術トレーニングを行なうチームと多岐にわたっている。
分散システムのトラブルシューティングは大変(お客さんによって規模も構成もバラバラなど)だが、クラスタ管理ツールや診断ツールでデータを収集・社内の分析基盤で分析を行い「データファースト」で対応している(先立つのはデータであって推測ではない)。
ミッションの一つに サポータビリティ の向上があって、サポータビリティとは何かというと製品をサポートしやすくするための取り組みを指す。例えば原因特定しやすいログを出力するように製品を設計することなどが挙げられる。
感想
サポートとしてトラブルシューティングを行なうための基盤を内製していたりサポートエンジニアチームも複数のロールに分かれていたり、これがガチサポートエンジニアか…！クラスタが数千台とかだと、ログだけでビッグデータになってしまうので分析基盤が必要らしい。
サポータビリティ向上のためにサポートしやすいログを出力する仕組みを入れるという話は、以前参加した Monitoring Seminar in mercari で聞いた「監視の口を開ける」という話に似ていてなるほどなあと思った。
サポータビリティの精神はサポートの人だけでなく、エンジニアリングで何かする人全般に当てはまりそう。
Dairy of Support Engineering Manager
Treasure Data のサポートチームについて。
意外にサポートメンバーは5人しかいないらしい(8人に増える予定)。問い合わせはどんどん増えていて大変。
サポートの KPI を設定しているが、指標が難しい(お客さんの満足度調査？対応したチケットの数？)。
KPI を取る理由を改めて考えると、「良いサポートをすることでお客さんにファンになって欲しい」が根底にある。
そのために最低限やるべきことを幾つか挙げて、それに向かってやっている(チケットは7日間以内に解決する、とか)。それを可視化してトラッキングしている。
可視化したサポートのグラフはサポートチームだけでなく、セールスチームなどのメンバーそれぞれが自分の担当するサービスのサポートの状態を見れるようになっている。
Slack をサポートでも使っているが、 Slack は流れていってしまうのでタスクの管理には向いていない。そこで、BubbleIQ というアプリを Slack と連携させている。 BubbleIQ は Slack と Zendesk を繋いでくれるアプリで、 Slack でのリアクションやスレッドの返信を Zendesk に送ってくれる。これにより効率 UP ！
Treasure Data の OSS に対する問い合わせや issue も出来る限り頑張って見ているらしい。
感想
とにかく人が足りなそうだったｗ
サポートの成果を意味のある指標として定義するのは確かに難しそうだなあと思った。お客さんはそんなにフィードバック(アンケートの回答など)をくれないので満足度を数値化するのが困難とか。
BubbleIQ は普通に便利そう。
Support at CircleCI
CircleCI のサポートについて。
サポートチームの指標としては SLA や顧客満足度などがある。 Slack と Zendesk 、 iscourse を使っている。
日本のビルド数はどんどん増えていっている。ブログを書くのも仕事としてある。
サポートエンジニアという立場を気に入っている点は、
- リモート OK
- お金 💰
- 自己管理がしやすい
- エンジニアとしての成長がある
- 様々な技術スタックに触れられる
が挙げられる。
問い合わせのエスカレーションについては基本的にはエンジニアが調査を行なうが、例えば npm リポジトリの調子が悪くてパッケージをロードできなかった場合にお客さんが CircleCI が原因と思い問い合わせがあったりして、そういうのはサポートが対応している。でもはっきりしたフローは特に無いらしい。
感想
やはりサポートは色々な技術に触れる機会があるので、それを楽しいと思えるかどうかなのかなと思った。なんとなく CircleCI はサポートが厚そうと思ったけど結構カジュアルな感じで驚いた。
Fun working as a GitHub Enterprise Support Engineer
GitHub エンタープライズのサポートのお話。
エンタープライズサポートはアジア、ヨーロッパ、アメリカに各10人ちょっといる。日本語のサポートは例によって日本タイムゾーンの日中のみ。
仕事は好きな場所でしてよくて、コミュニケーションは Slack, GitHub, ビデオチャット( Zoom )を活用して行っている。
Slack はおはようコメントしたり何か質問したりけっこうカジュアルに使われていて、 GitHub はナレッジの共有用リポジトリがあり、 issue に質問したりしている。タイムゾーンの違うメンバーに対して質問したい場合は issue を使っている。
ビデオチャットはミーティングや 1on1, ペア作業時に使っている。
Mini-summits というイベントを各拠点ごとに定期開催していて、皆で集まってナレッジを共有したりご飯を食べたり、コミュニケーションの場としている。
お客さんからの問い合わせは基本的に Zendesk を使っていて、問い合わせ数はグローバルで 1400/月 くらい。ただ、日本は特殊で月によって問い合わせ数が全然違ったりするらしい…。
あと日本人はあまりチケットを切ってくれないらしい。 GitHub エンタープライズはお客さんのローカルに GitHub をインストールして使う仕様上、お客さんの環境に入って調査ができないのでチケットをちゃんと出してくれることが重要。
トラブルシューティングとして、ユーザーの情報はツールを提供しそれで収集している。
サポートチームの体制としては現在 Swarming という仕組みを検証中。 Swarming とはどういう仕組みかというと、サポートチームを3つの swarm に分割して回す仕組み。 swarm はそれぞれ Priority, Triage, Backlog がある。 Triage がサポートの重要度を判断し Priority や Backlog に回す。
swarm は定期的にローテションしているらしい。ローテションの期間もやりながら検証中。
サポートを効率化するために個人で行っていることとしては、ショートカットキーを活用したり定型文を入力できるようにしたり、トラブルシューティングで毎回行なうような作業をスクリプトに起こしたりしている。
バグの修正もサポートチームが行なうことができて、バグを見つけて報告しても「ユー直しちゃいなYo!」みたいなノリで自分で直すことが出来る(リリースもやる)。
サポートエンジニアで楽しいことは、
- いろんな技術に触れられる
- いろんなバックグラウンドのエンジニアがいて交流できる
- 元データセンターエンジニアや Ruby のコミッターなど色々な人がいる
- デバッグが楽しい！
感想
英語は最初は得意ではなかったけど今は普通にやり取りできるようになったとのこと。見習う！
GitHub を社内のナレッジ共有ツールとして使っていたり質問ツールとして使っていたりしていて面白い。リビジョン管理できるし良さそう。
まとめ
イベントのサイトにもありますが、サポートエンジニアの話に焦点を当てた勉強会はなかなか無いので面白かったです。良いサポートを行なうためにはやはりトラブルシューティング力が必要で、そのためのツールをどこも内製しているのが印象的でした。
あと共通していたのが色々な技術に触れられる・触れる必要があるということ。
チーム編成も様々でそれぞれ工夫がある。やっぱりサポートエンジニアでもある程度ロールを分けて分業するのが効率良さそう…。
Slack と Zendesk が強い。でも KPI をうまくやるためのツールはまだあまりないのかな？コードと違って定量的に質を評価する指標みたいなのがなかなか定義しづらそうなので、その辺はどこも手法が異なっている感じでした。
また機会があれば参加してみようと思います。