“第3回 Hubot×ChatOps勉強会”に参加レポート
久しぶりに参加したChatOps勉強会。
https://hubot-chatops.connpass.com/event/49793/
前回参加したのは1回目の2,3年前です。当時はまだそもそも世の中的にはChatBotてなに？な時期でした。そんな中でもBotで何をさせるのかというものとしてシステムのDeployなどを自動的に行うためのChatOpsというジャンルがあることを知りました。特にHubotというGithub社の利用しているChatBotフレームワークがまさにChatOpsのために作られたBotフレームワークであったことで多くの人がHubotを利用していたと思います。
現在では、Slack用に登場したSlackbot FrameworkやクラウドサービスであるAzureのBot Framworkなど色々出てきており個人的にこのあたり整理してみたいなと思っています。
hubot-slack v4移行時のハマりどころ@knjcode
現在6つのBotを運用している（Bluemixでも動いているって！）。ちょっとニッチな内容です。v4への移行する際に問題（そもそもは slack-sdk のバージョンアップに伴う影響で問題が起きている）になる点を一つづつ説明していただきました。現行のhubot-slackでも出来ることの内容になるので資料は後でしっかり見てみたいと思います。
- 改善されている事が多いのでなにか気になる点があればUpdateしたほうが良い。ただし今回の内容は注意して。
- ユースケース：（例えばAWSのような）クラウドサービスの上のアクセス制限の許可をだしたり、のような作業をBotを利用して行っている。
BotKitで作るイベント駆動Bot@hico_horiuchi
主催者さん、今はNTTComさんのベアメタルクラウドチームとのこと。Botkit( Howdy社）のSlackBotフレームワークのキット。専用ツールなのでHubotより素直に実装することが出来る。Botkitの使い方の説明。
Slackの内部で発生する「イベント」に対して「動き」をつけてみようという話。たとえば、team_join 、emoji_changed など沢山のイベントが発生している。event type を参照。( https://api.slack.com/events )
- 新しくチームに入ってくると通知
- 絵文字が追加されたらメッセージでお知らせ
- 2段階認証を設定をしていないユーザを説教部屋に呼び出す
メッセージに反応する以外の事に反応させるとChatOpsの幅が広がる。
- (質問）Hubotなどで会話を使用した場合にはどうしたら良いのか。/ (解答）自前で創るかしかない。またはクラウドサービスなどを利用する。
- 考え方としてChatBotは、I/Fなので処理は裏側で実施するほうが良い。会話の送受信に徹する。
KubernetesのChatOps gavinzhm
GKEのkubernatesの運用のため、ルーチンワークの自動化のために入れ始めた。
hubotを使ってない理由
- コンテナ運用のため bot の images が大きすぎ、起動がおもい (200MByte)
- stackをシンプルにしたい、coffeescriptsを避けたい（本体のほうがpythonからgolangに移行したので更にcoffescriptを使うのは大変）
- botが重い、機能が多すぎ、メンテコストが高い
- kubernatesとの相性が悪い
- cog , errobt とか、こういったものもBotが重い、機能が大きすぎ
結局作った go-chat-bot 、シンプルなものにした。このようなものは作ったほうが良いものが多い。kuberntete は基本全てAPIで操作できるのでその内容を全てSlackに送りつける。
- Letsencrypt証明書等の更新Bot（All GCPなのでDNSチャレンジで更新出来る）
- podの状態共有、自動構築とか状態確認とかDevチームがOpsによく聞くような内容を応答するBot
まとめ、エンジニアのアシスタントになり（事務処理、on-call standry ,勤怠管理）
- いつもエンジニアといえどもPCを持ち歩いているわけじゃない（持ち歩きたくはない）、そういう時にチャットで出来るのは便利。
- Chatbotの自体の監視はしない。Botは死んでも大丈夫（お金に関わるところではない）なのでリソース監視などで行き過ぎたら再起動させる運用
イケメンを育てる@ladicle
五十嵐さん、お家Hackな付近の人
- 雑談、音楽流す、家電操作、Tracking Activity Time
第一世代
- Node-REDを使って Regxp で文字列マッチして処理する
第二世代
- (Kagome日本語解析) Parser (golang)の文字列解析とおして Regxp
第三世代
- 文字列を保管して、前回のメッセージ（会話）を保管するようにした
第4世代
- ストーリーを持とうとすると、コンテキスト（user ,message ,channel ）などの情報量を増やして条件判断を出来るようになる。自前に設定すると面倒だった
うちのサーバがKubernates、、Fission（Serverless Function）を使ってAPI化するために利用している。
これから、InputでLocationなどの付属情報があれば・・。Replayを創る機能が定型文なので良しなに作りたい。最近のはやりはInputくるとIntentとEntitiesに分類してIntentに応じてResponse Generatorも動きを変える。
まとめ
色々アイディアと経験がたくさんあり面白い会でした。是非次回も期待したいと思います。会話の制御や単純な正規表現でのマッチングでは不足する用途など適材適所になって来たなぁという印象。ChatBotのフレームワークは必要に応じて適切なものを選択するのが良さそうですね。またそのボットがサポート用のツールなのか機能そのものなのかで運用要件も変わって来ますので要件に応じたアーキテクチャも色々考えられますのでバッドノウハウ含めて色々聞きたいです。
