# ChatOps ## 定義 ChatOps とは、チャットプラットフォーム(Slack、Hipchat 等)を運用操作の主要インターフェイスとして位置づける DevOps・SRE の実践パターンである。ボット(チャットボット)がチャットチャンネルで会話を傍聴し、コマンドを受け取り、外部サービス(監視・デプロイ・オンコール管理)を操作する。インシデント対応においては、操作と会話のログが同一チャンネルに残るため、コンテキスト共有と事後の監査可能性が高まる。Netflix の Scorebot([[@2016__SREcon16__Incident Management and Chatops @ Netflix Feat Scorebot]])はその典型実装であり、2015 年 12 月に Go で実装された。 ## ペインポイントと設計課題 Netflix Scorebot の事例から見えた ChatOps 特有の設計課題: - **コールバック管理(callbacks)**: JavaScript/Node.js の非同期コールバックはソフトウェアエンジニアが毎日触るなら問題ないが、SRE は月1〜四半期に1回コードに戻る。コールバックは「再度頭に読み込む」コストが高い。Go のブロッキングコードは上から下に読めるため SRE に適している(Tobey 2016)。 - **テスト困難(testing)**: チャット API に実際にリクエストしないとテストできない。Go の強い型付けとコンパイル時エラー検出がテストの代替として機能する。 - **コンテキスト不足(we require more context)**: Hubot はテキスト文字列しかプラグインに渡さない。新設計では Slack イベントを解析してユーザーID・チャンネル・リアクション等を構造化データとして渡す。 - **ボットの騒々しさ(obnoxious bot)**: `!oncall` がテキストの壁をインシデントチャンネルに貼り出す問題。インシデント中に500人が同じチャンネルを追っているとき、このノイズは致命的。解決策は結果を DM に振り向ける設定。 ## 主要機能パターン Scorebot が実装した機能パターン(transcript 確認済み): - **bookmarking**: `!mark <テキスト>` でタイムスタンプ + メモをチャンネル内に記録(Brian Tolson 発案)。インシデント指揮者が Jira や Google ドキュメントに切り替えずにコミュニケーションに集中できる。事後のタイムライン構築の起点になる。 - **presence**: ネイティブの緑ドット(プレゼンス)は過敏すぎて実質使えない。ボットはチャンネルでの発言タイムスタンプをデータベースに記録し、「実際にキーボードの前にいる」状態を問い合わせ可能にする。 - **after-hours**: 夜間に `@here` するとボットが「コアチームは 9〜17時のみ在籍。緊急の場合は以下にページして」と案内。プロセスをチャンネル内で完結させて MTTR を短縮する。 - **secrets**: ボットのデータベースにクレデンシャルを暗号化して保存(Hashicorp Vault / Netflix CryptX との連携)。Git リポジトリへのトークン混入を防ぎ、再デプロイなしにトークン更新できる。 - **archive(開発中)**: 絵文字リアクションで発言を「promising / not promising」にタグ付けし、インシデントレポートの 90% を自動生成することを目標とする。 ## 横断的知見 - **ボット = サービスへの薄いインターフェイス**: Tobey は「ボットに機能を詰め込みすぎない」ことを強調する。重要なロジックはデーモン(Rails app・Puppet 等)として独立して動かし、ボットはそれらへの操作インターフェイスに留める。"sugar more than pure functionality"——Slack が落ちても本質ロジックは別で動く設計。 - **可用性の所有権**: Slack が落ちてインシデント対応できないのはボットの問題ではなくオペレータがバックアッププランを持っていないことの問題。ChatOps は利便性を提供するが可用性の最終責任はチームにある。 - **SRE 向けボット実装言語選択**: ソフトウェアエンジニア向けの実装(毎日触る前提)と SRE 向けの実装(月1〜四半期に1回触る前提)は異なる最適解を持つ。SRE 向けでは「認知負荷を下げるブロッキングコード」が「非同期パターンの性能最適化」より重要になりうる。 ## 未解決の問い - Netflix はその後 Scorebot をどのように発展させたか? 他の大規模組織の ChatOps ボット(PagerDuty の Slack 統合、GitHub の Hubot 等)と比較してどのような独自性があるか? - Slack ベースの ChatOps から AI エージェント型インシデント管理([[agentic SRE]])への移行で、ChatOps の「チャンネル単位のコンテキスト共有」という価値はどう変化するか? - ボットの騒々しさ問題(obnoxious bot)への対策として、通知フィルタリング・優先度付け(→ [[アラート管理]])のアプローチは研究でどう扱われているか? ## 関連 - [[インシデント管理]] — ChatOps が適用される主要ユースケース - [[ワークフロー自動化]] — ChatOps の一形態としての位置づけ - [[オンコール自動化]] — after-hours 機能との接続 - [[agentic SRE]] — ChatOps から自律エージェントへの発展方向 - [[@2016__SREcon16__Incident Management and Chatops @ Netflix Feat Scorebot]] — Netflix Scorebot の事例 ## 出典 - [[@2016__SREcon16__Incident Management and Chatops @ Netflix Feat Scorebot]] — Netflix SRE [[Al Tobey]] による SREcon16 発表。Scorebot の設計思想・機能・課題を網羅。