16年入社の新卒エンジニア @b4b4r07 です。先日、10/1 で入社半年ということで、今更ながらではあるのですが節目として、入社エントリを書きました。もしご覧になってなければ、併せてこちらもどうぞ。

www.tellme.tokyo

半年を振り返って

突然ではありますが、すごすぎて笑えたりニヤけたりすることはありませんか。エンジニアならすごすぎる (例えばあまりにきれいに書かれてる等) コードに出くわしたり、人跡未踏な発想・設計のツールを見たりすると思わずニヤけること、あると思います。

こういう体験はそう何度もあるものでもないのですが、メルカリに JOIN してから半年、Slack の bot に生きた技術を見たときに何度も「すごいなぁ」と ニヤケ 感心させられました。感動は何らかの行動のモチベーションにもなるし、この面白く素晴らしい技術について多くの人に知っていただきたいので、今回はそのメルカリを取り巻く bot の技術についてお話ししようと思います。

メルカリの Slack

過去にメルカリのエンジニアブログでも取り上げられている通り、メルカリではコミュニケーションツールとして全社的に Slack を導入しており、多数の bot が動いています。

tech.mercari.com

ゆえに、エンジニア・プロデューサー・デザイナ含め、カスタマーサポート (CS) でも Slack を利用しており、業務中触れている時間の多い Slack の QoL を上げることはとても効率的とも言えます (エンジニアは Slack, エディタ (開発環境), ブラウザの行き来がほとんどだと思います)。

bot の構成

メルカリの Slack では、複数の bot が動いており、それぞれが Supervisord によってプロセス管理されています。そして各 bot は各ディレクトリで構成されており、一つのリポジトリで管理されています。リポジトリは一つの Slack アクセストークンに紐付いていて、bot ユーザとしては一つだけ存在するようになっています。

mercari-bot
├── anon-db-bot
├── big_query_price_bot
├── build-mercari-user-package-bot
├── cdn-bot
├── deploy-verify-bot
├── escalation-bot
├── explain-bot
├── help-bot
├── ipdb-bot
├── it-control-bot
├── kot-alert-bot
├── kot-bot
├── mail-notify-bot
├── mikan-bot
├── redmine-versin-alert-bot
├── report-alert-detail-bot
└── zabbix-bot

bot ユーザとしては一人しか存在していないので、与える引数によって挙動を制御します。面白いのが、bot の呼び出しは bot から始まる文字列で共通なのですが、その後に続く文字列によってあたかも他の bot ユーザが存在するかのような工夫がされています (ディレクトリごとに存在する bot に対してユーザ名とアイコンが振られている)。

もともと私個人でも bot を作ったりしていたのですが、メルカリの bot のコードを読んだとき、実用性と生産性の塊だなと感動しました。巷でよく見る bot 紹介記事の多くは単に echo し返したり、ランダムな画像を返すものが多いですよね (もちろん、業務用とプライベート用の違いはありますが)。

その中でも感動した bot のうち何個か紹介しようと思います。

CDN のキャッシュをクリアする

URL を渡すと Akamai (CDN サービス) にキャッシュされたコンテンツをパージしてくれます。

ただそれだけのことなのですが、bot として存在していれば余計なインターフェースを必要としない (全員に共通した UI を提供できる) のと、権限ややりかたを知らない人間でも、実行できるのが強みですよね。

ユーザパッケージを作成する

Google スプレッドシートよりユーザー情報を読み込み、ユーザーパッケージを作成し社内 yum サーバへの登録までを行う bot です。

この bot のいいところはアクセス制御されている点です。SRE (Site Reliability Engineering) チームのメンバー以外が bot を使おうとすると…

このように怒ってくれます。これで簡単に共通インターフェースを提供しつつ、アクセスをコントロールしたい場合は特定のユーザにのみ実行させるということができました。

仕組みとしては単純で、Slack ではユーザの情報を user オブジェクトで管理しているため、controller.hears() (botkit の場合) で拾ってきたメッセージの発言者が該当する ID を持つ人物かどうかチェックすることで実現できます。

出退勤をつける

bot hello で出勤し、bot bye で退勤です。便利ですね。

これも例によって SRE メンバーに利用制限された便利 bot です。SRE は当番制により日によっては自宅対応を求められるため、リモートで打刻できる必要があり打刻 bot が作られました。

出退勤つけわすれたときは

翌日に DM が飛んできます。

弁当が届いたら

メルカリでは、弁当配達をお願いしているのですが、わざわざ販売員のところに行かなくてもメニューを確認できるようになっています。

弁当がやってくる時間は日によって数分誤差があったりするのでとても助かります。email のインテグレーションから bot 化させたのは @here をつけたかったためです。この bot は #z-bento チャンネル (Slack の弁当チャンネル) に生息しており、弁当にアンテナを張ってる人間に対し効率的に通知できます。

障害が発生したら

大抵は、障害の当番担当者アラートに気づいて対応するのですが、アラートに漏れがあったりした場合に、気づけず対応の初動に遅れてしまうことがあります。そんなとき、いち早く気づけた人が Slack から当番担当者および SRE メンバー全員に対し、着信コールを掛けることができます (インターフェースを共通化するメリットですね)。

以下は、実際に使用された場面。

内部で Twilio の API を呼んでいて、コールが鳴ったときはけたたましい着信音になるそうです (SRE 談)(*1 作ったのも SRE)。もちろん、深夜対応だったり休日の対応になった場合は振休が付きます。

ただニヤけるだけじゃない

bot touban call をリアルタイムに見たときは相当ニヤついたわけですが、単に指をくわえてニヤけているわけではないです。

これら mercari-bot に大きく感化され、自分でも実装やアイデアを盗みつつ便利 bot をいくつか作りました。

github.com

私はある GitHub Organization を持っているのですが、そこでもコミュニケーションに Slack を用い、bot を活用させています。ひとつだけ紹介します。

README.md や docs などバージョン情報の載った複数のファイルやバッジを書き換えて Version bump するのが面倒だったので、bump から GitHub Releases に公開するまでをやってくれる bot を作りました。

これにより、他のコラボレータの方もバージョンアップすることが可能になり、とても便利です。これ以上は手前味噌になるので、気になる方は先程のリンクから見てみてください。

• #xxx 形式のテキストを Issues/P-Rs に展開する bot
• 各 bot のヘルプを表示する bot
• bot を管理 (起動/停止/稼働時間など) する bot
• P-R をマージする bot
• Travis CI で再ビルドする bot
• …

終わりに

半年の振り返りとしては、bot に終始するという稀有な記事となりました。しかし、毎日業務で (プライベートでも) 触れる Slack を有効活用するという点と、他のブログ記事では得られなかった感動を与えてもらったということで、半年の振り返り記事とさせていただきました。

• Designer (New Graduate Position)
• Software Engineer (New Graduate Position)