ChatOps：人手を介さない人員配置

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

あなたの身近なネットワークにも、まもなく登場します。提供は もう1つのAPIエコノミー。

最近、DevOpsコミュニティでは、文化をより重視する方向へと関心が移っています。これはおそらく、IT部門全体がよりオープンに連携できる環境へと文化を変えなければ、DevOpsがもたらす多くのメリットを十分に享受できないためです。「知る必要がある人にだけ伝える」という閉鎖的な情報共有は、私たちが親しみを込めて「IT」と呼ぶ組織を構成する各運用領域固有の暗黙知を、防御塔のように囲い込むサイロを生み出します。

しかし、こうしたサイロを打ち壊すには、痛みや気まずさが伴い、極めて困難な場合があります。IT業界のほぼすべての人に見られる「非社交的」な性質を冗談の種にしたり、ステレオタイプをからかったりすることはできます。しかし実際には、多くの伝説やおとぎ話と同様、そうした典型像は現実の行動や特性から生まれたものであり、今なおこの分野の多くの人に当てはまります。

私はMeyers-Briggsでは、いつも INTJ です。そう、「建築家」です。 Insights の分類ではReforming Observerです。これは、Meyers-Briggsより精度が高いとうたう、ユングの類型論を極端に理想化したようなテストにすぎません。いずれにせよ、私はかなりの内向型です。現在、研究者は人口の約50%が内向型だと推定しています。その多くが私と同じようにITの道へ進み、一方で、私たちには理解しがたい外向型の人々がマーケティングや管理職へと軽やかに進んでいったと聞いても、驚くことはないでしょう。

内向型の人は「人付き合い」があまり得意ではありません。最近の若者は、人と交流することをそう呼ぶそうです。いえ、相手が悪いのではなく、こちらの問題なのです。内向型は外向型とは異なる方法で情報やデータを処理するため、活発なやり取りが多すぎると圧倒されてしまいます。人付き合いができないわけではありませんが、とても疲れます。返事をする前に、文章でやり取りし、考える時間を取るほうを好みます。だからこそ、コミュニケーションの多くを離れた場所から文章で行うデジタル時代には、実はうまく適応できるのです。デジタル上の姿しか知らなければ、外向型だと勘違いするかもしれません。

DevOpsに必要な文化的変革の前提を考えると、すぐに矛盾があることに気づきます。情報共有とコミュニケーションはいずれもDevOpsに欠かせない要素です。つまり、大勢の内向的な人たちに、単に人と関わるだけでなく、効果的に関わってもらう必要があります。そのため、「人と関わらずに人と関わる」方法を見つけるのは、虹のたもとにある金の壺を探すようなものです。

ChatOpsこそが、その「虹のふもとの金の壺」なのかもしれません。

ChatOps：人がいなくても人とつながる

では、ChatOpsとは何でしょうか。Jason Hand氏はChatOpsの第一人者の1人であり、簡潔に定義しています。「ChatOpsは共有コマンドラインと考えるとよいでしょう」

もちろん、ChatOpsはそれだけではありませんが、基本を理解するには、この定義が最適な出発点です。

Tools like HipChatやSlackなどのツールは、従来のIMシステムのような1対1のコミュニケーションを目的に設計されたものではありません。1対1でも利用できますが、こうした最新のコミュニケーションプラットフォームの真価は、情報や最新情報を、関心のある組織内の誰もが即座に共有できるオープンなコミュニケーション環境を実現することにあります。継続的に会話することよりも、情報をいつでも利用でき、容易にアクセスできることが重要なため、閲覧だけの参加も推奨されます。

チャネル（#IRCなど）を使えば、シグナル対ノイズ比を調整でき、多くの場合、誰がいつ何をしたかを明確に追跡できる監査証跡も得られます。こうしたツールは、単なるチャットクライアントではありません。APIを通じて機能を拡張し、人だけでなくシステムとも双方向に通信できるプラットフォームです。つまり、#alertsチャネルを追加し、インフラストラクチャコンポーネントからのアラートをそこに集約できます。

SlackのAPIを介して情報を照会し、結果を返す「アプリ」は、比較的簡単に構築できます。対象はスイッチやロードバランサー、地域の天気情報など、さまざまです。いずれの場合も、こうしたツール内からコマンドを呼び出し、タスクを自動実行できます。また、知る必要がある人や、知ることで役立つ可能性がある人を全員集めなくても、コマンドの呼び出しとその結果を共有できます。実行した内容がタスクの記録となり、状況を他の人が把握できる履歴も残ります。たとえば、監視システムからのステータス更新、ヘルプデスクの新規チケット、サーバーが停止して利用できなくなったという通知などです。API経由で伝達できるものなら、ほぼ何でも、人が直接介在することなく他の人と共有できます。

このプロセスにより、メンタリングやトレーニングに加え、属人化した知識を解放し、開発を含むITの他の領域で活用するための多くの機会が生まれます。大勢を1つの部屋に集めたり、意欲に満ちた新人エンジニア向けの研修を実施したりすることなく、大規模な知識共有が可能になります。また、「ネットワーク」でDevOpsアプローチを導入し、成功させるために必要な文化的変革を実現できる数少ないツールの1つでもあります。

そして、私たちはこれを採用しなければなりません。まだ不安がある場合は、AtlassianとxMattersが2017年DevOps成熟度調査で投げかけた次の問いについて考えてみてください。

著者らはデータに基づく独自の仮説を立てていますが、私には別の仮説があります。その根拠の大部分を占めるのが、デプロイ用にリリースされたアプリケーションと本番環境で稼働するアプリケーションは同一ではないことを示す「合成の誤謬」です。アプリサービスの追加やネットワークとの相互作用によって、その構成は変化します。そのため、本番環境を正確に再現した環境で検証しない限り、そのアプリケーションに対する検証結果は完全には当てはまらなくなります。

さらに深刻なのは、3分の1近くの企業では、顧客からサービス停止の連絡を受けるまで、こうした問題が発見されないことです。その原因は、開発部門とIT部門の間での情報共有の方法にあるのかもしれません。29%は、チーム間で情報が共有されるのは、明示的に要求された場合だと回答しています。「技術情報、目標、計画、結果を提供するすべての人に情報を公開している」のは、わずか16.8%です。

本番環境でのアプリの挙動に固有の情報がなければ、問題の原因はおろか、何が問題なのかを見極めることさえ困難な場合が少なくありません。「自分のマシンでは動く」という言葉は、環境情報の不足に起因することが多い不具合を再現できない開発者の苛立ちから生まれた、自己防衛的な決まり文句です。

たとえ、すぐにネットワークのあらゆるものを自動化することに乗り気でなくても、ChatOpsはIT部門と開発部門のコミュニケーションを促進し、問題への理解を深めてMTTR（平均解決時間）の短縮につなげる有効な手段です。エンジニアの業務に過度に干渉したり、細かく管理したりすることなく、「ネットワーク内」で何が起きているのかをより包括的に把握できます。また、内向的な人でも対面で人と関わらずに交流できるため、より頻繁かつ詳細に、場合によっては積極的に情報を共有しやすくなります。

ChatOpsを初めて利用する方には、Jason Handの電子書籍『ChatOps for Dummies』をぜひお読みになることをお勧めします。メールアドレスの提供が必要ですが、読む価値はあります。

今後もぜひご注目ください。ChatOpsについては、これからもさらに詳しく取り上げていくことをお約束します。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事