ChatOpsを「Chatというインターフェースでサービスやプログラムと連携することによる業務改善」ととらえた時、どのような活用方法があるのかを雑多に調べて勝手にカテゴリわけしてみました。特に複数の要素について説明されていた文書などは印象に残ったものだけで分類しており、基本的に筆者の主観によるものです。
とりあえず目に入ったものを片っ端から見ていった感じですが、ここが違うよとか、こういう事例もあるよというご指摘は歓迎です。
サービスインターフェース
利用ユーザ側からシステム・サービスに対してなんらかの働きかけをするもの。
ビルドやデプロイの管理
ChatOpsの本懐（らしい）。Chatでビルドやデプロイの命令を発行する。コマンドを単純化し余計なステップを極力なくすことで特定の個人やエンジニアに依存しないオペレーションが可能になる。
- チャット経由でデプロイする
- 非エンジニアが自然とChatOpsを使いこなせるようになった話
- プログラミングいらずのChatOpsがあなたの元に。そう、Typetalkならね
- ChatOps時のブランチ運用戦略(実装 / コードレビュー / 関係者確認 / 自動テスト / デプロイを円滑に行う)
- SUUMOスマホサイトでのChatOps事例
- ChatOps( Slack / Hubot / Docker )で検証環境をポンポン作って、ポンポン捨てる
- 開発しにくかった現場がなぜ素早くリリースできるようになったか？ SUUMOのChatOps活用術
- ビジネスチャットツールdirectからSORACOM Airの速度クラスを変更する
- ChatOps とは何か？どのように進化し、受け入れられ、重要視されるようになったのか？
- ChatOpsでOSのセキュリティアップデートを自動化出来るようにした
外部サービスとのインタラクション
外部サービスの操作をChat経由で実施する、あるいはChatに常駐するbotに仲介させる。自動化や単純化されたコマンドの他に、外部サービスからのイベント通知と連動しやすい（通知を見る→直ぐに反応できる）という使い方ができる。
参照コマンドの発行
上記2つと似ているが、システムへの変更を加えるのではなく参照だけのもの。外部サービスへ参照も含む（事例ではWikipeidaへの検索）。検索などで最低限決めないとならない条件などを再定義することで、エンジニアの人でも参照のための手順が楽になり、さらに非エンジニア役職の人が触りにくかったような情報でも自力で参照できるようになる。
- SlackからHubotを経由してDBを参照する
- Slackで，世界を，もっと，はたらきやすく
コミュニケーションの向上をめざして――サーバーワークスの場合 (Software Design 2016年1月号)
現実世界とのインタラクション
現実世界での手続きをChatにのせるアプローチ。必ずしもChatから叩く直接的な優位性はないが、普段使っているインターフェースだけで完結すること、手続きを他の人と共有しやすいというところが良さ。
リソースなどの状態管理
事例ではstaging環境が使用中かどうかを管理している。
- IRCからHubot中心のChatOpsへ XFLAGスタジオ「モンスターストライク」の裏側 (Software Design 2016年1月号)
通知
発生したイベントの周知や報告。
障害・システム状態監視の通知
一番需要が高いと思われる通知。単純にログの転送などではChatが埋まってしまうので、必要な情報だけを通知する工夫が必要だが、そのあたりは従来の障害監視などと同じ。普段使いのインターフェースに通知することで、担当者の応答性を高めることや、通知されたイベントについてそのままメンバーとコミュニケーションできるのが強み。
- ZabbixとSlackでChatOpsのススメ
- ChatOpsによるアプリケーションのエラー監視 (Slack / Hubot / SQS)
- ゆるきゃら「ぺこbot」が生まれた理由
ぺこbot爆誕！＠Socket (Software Design 2016年1月号) - エンジニアのためのより良い環境づくり
はてなにおけるChatOpsのこれまでとこれから (Software Design 2016年1月号)
事前に決まっている予定の通知
事例では定期的に変わる当番をその都度通知してくれる、というもの。事例はプライベートでの活用方法だが、業務における当番やゴミ捨て当番の通知なども他事例であり。
あとは、スケジュールサービスと連動させて特定のイベントが発生した、あるいは発生する直前に通知するという他事例もあり。
チームなど活動の通知
比較的粒度の細かい個人の活動を特定チャネルに流し込むことで、メンバーの活動状況を可視化する。Twitterのようにひとりごと？を自分で流し込む他に、レポジトリへのcommitのような活動や、情報共有ツールへの投稿なども自動的に取り込むと、より可視性が高まる。
現実世界におけるイベントの通知
現実世界でのイベントをセンスする方法が必要だが、通知のインターフェースを一本化するという点においてメリットがある。特に2番めの事例で来客通知をChatに流すというのが興味深かった。あまり事例をみかけなかったが、いろいろなセンサーと組み合わせると面白いことができそう。
雑談・ほのぼの
業務改善などに直接寄与しないが、人を和ませたりするもの。これはこれで重要。
- DocomoruでBOTと雑に会話する
- SlackでLitaと雑談してみる
- Slackに住む僕らのペット(Capybara)
- Cloudn PaaSチームのChatOps実践
- 2015年にプライベートで作ったbotたち
余談
画像を使ったチャットコミュニケーション
ChatOpsをやるにあたってのメリットまとめ
調べた結果の感想です。
- 共通インターフェース。常に立ち上げているツールでいろいろなことができる。一昔前？のUnixエンジニアのterminalと同じ。ただしコマンドなどが増えると結局は学習曲線の問題に直面する。
- インタラクティブ性がある。通知を受け取るインターフェースと何かの動作をするためのインターフェースが統一しやすい。
- 応答性。常時利用している可能性の高いツールなので、素早く通知などを検知し対応にうつれる。逆に言うと通知されるべきメッセージの制御は重要。
- 共有がしやすい。チーム内で何をやったかの可視化になる。
- 記録に残しやすい。明示的に記録をするという手続きをしないでも作業記録が残り、後からの検索も容易
- 業務プロセスの再定義。結局のところ必要な入力・出力パラメータは何か？というのがはっきりする。逆にいうとこれがはっきりしていないとあまり意味が無い。
参考