チャットオペレーション: 人間なしで人を呼ぶ

あなたの近くのネットワークに登場します。 Other API Economyがお届けします。

最近、DevOps コミュニティでは文化を重視する傾向が強まっています。 おそらく、よりオープンで協力的なクロス IT 環境への文化的変化がなければ、DevOps の利点の多くは十分に実現できないためでしょう。 閉鎖的で「知る必要のある」情報共有は、私たちが「IT」と呼んでいるものを構成する各運用領域に固有の部族の知識を囲む防御塔のようにそびえ立つサイロにつながります。

しかし、それらを破壊することは苦痛を伴う可能性があります。 そして気まずい。 そして非常に困難です。 私たちは、ほぼすべての IT 業界の人々の「反社会的」な性質について冗談を言ったり、風刺画を嘲笑したりすることはできますが、現実には、ほとんどの伝説やおとぎ話と同様に、それらの典型は実際の行動や特性から生まれたものであり、今でもこの分野の多くの人々を典型的に表しています。

私はマイヤーズ・ブリッグスではINTJです。 毎回。 はい、「The Architect」です。 私は洞察力スペクトラムの改革型観察者です。これは実際には、マイヤーズ・ブリッグスよりも精度が高いと主張する、非常に理想化されたユング派のテストです。 どちらにしても、私はかなり内向的な人間です。 現在、研究者たちは人口の約50%が内向的であると推定しています。 そして、彼らの多くが私と同じように IT 業界に進み、一方で理解しがたい外向的な同僚たちはマーケティングや管理職に就いたとしても、あなたは驚かないはずです。

内向的な人は、人と交流すること、つまり最近の子供たちが人と交流することを好まない。 それはあなたではなく、私たちなのです。 私たちは外向的な人とは異なる方法で情報やデータを処理しており、あまりに活発なやり取りが多すぎると圧倒されてしまうのです。 人にはできるけど、疲れる。 私たちは、返信する前にテキストで考える時間を好みます。 だからこそ、私たちのコミュニケーションの多くが遠く離れた場所からテキストで行われるデジタル時代において、私たちは実際にかなりうまくやっています。 私たちのことをデジタル形式でしか知らないと、外向的な人間だと勘違いされるかもしれません。

DevOps に必要な文化的変化の前提を考慮すると、すぐに矛盾が生じることがわかります。 共有とコミュニケーションはどちらも DevOps の重要な要素であり、これは、内向的な人たちを集めて、人々を集めるだけでなく、人々を効果的に集めることを意味します。 つまり、「人を使わずに人々に到達する」方法を見つけることは、虹の終わりにある金の壺を見つけるようなものです。

結局のところ、ChatOps はまさに金の壺である可能性があります。

チャットオペレーション: 人間なしで人を呼ぶ

では、ChatOps とは何でしょうか? ジェイソン・ハンドChatOpsの第一人者の一人である 簡潔な定義を与える: 「ChatOps を共有コマンドラインとして考えてください。」

もちろん、それだけではありません。しかし、最も基本的な点としては、ここから始めるのが最適です。

HipChatやSlackなどのツールは、旧式の IM システムのような 1 対 1 のコミュニケーション用に設計されていません。 それは可能ですが、これらの最新のコミュニケーション プラットフォームの真の力は、情報や更新情報を組織内の関心のあるすべての人々と即座に共有できるオープンなコミュニケーション環境を実現することです。 重要なのは継続的な会話ではなく、情報の可用性とアクセス可能性であるため、潜伏が推奨されます。

チャネル (#IRC など) は、信号と雑音の比を制御する手段を提供し、多くの場合、誰がいつ何をしたかの明確な監査証跡を提供します。 これらのツールは、単なるチャット クライアント以上の機能によってこれを実現します。 これらは、API を通じて機能を拡張し、人だけでなくシステムとの双方向通信も提供できるプラットフォームです。 つまり、インフラストラクチャ コンポーネントからのアラートを集約する #alerts チャネルを追加できるということです。

さらに、比較的簡単に、Slack の API を介して情報を照会して返す「アプリ」を構築できます。 それはスイッチ、ロードバランサー、または地元の天気かもしれません。 どのような場合でも、これらのツール内からコマンドを呼び出して、タスクを自動的に実行できます。 また、知る必要のある人や知ることで利益を得る可能性のある人全員に知らせなくても、呼び出しとその結果を共有できます。 タスクは実行した内容によって文書化され、他の人が何が起こっているかを理解できるように記録が残ります。 監視システムからのステータス更新、ヘルプデスクからの新しいチケット、サーバーがダウンして利用できなくなったという通知など。 API 経由で通信できるものなら、ほとんど何でも、実際に人を介さずに他の人と共有できます。

このプロセスにより、開発を含む IT の他の分野に役立つ指導、トレーニング、部族の知識の解放のための豊富な機会が生まれます。 これは、大勢の人が集まる部屋に詰め込んだり、意欲的な新人エンジニア向けのトレーニング演習を実施したりすることなく、大規模な共有を実現します。 これは、「ネットワーク」で DevOps アプローチをうまく導入するために必要な文化的変化を可能にする数少ないツールの 1 つでもあります。

そして私たちはそれを採用しなければなりません。 それでもまだ不安なら、Atlassian と xMatters が2017 年の DevOps 成熟度調査で提示した次の質問を検討してください。

著者らはデータに基づいて独自の仮説を立てていますが、私には別の仮説があります。それは主に、デプロイメント用にリリースされたアプリケーションは運用中のアプリケーションと同じではないことを思い出させる「コンポジションの誤謬」に基づいています。 アプリ サービスの挿入とネットワークとのやり取りによって構成が変わります。 そのアプリケーションの審査は、実稼働環境の正確なレプリカで実行されない限り、完全には適用されなくなります。

さらに悪いことに、ほぼ 3 分の 1 の企業では、顧客からサービス中断の通知を受けるまで、こうした問題は発見されません。 これは、開発部門と IT 部門の間で情報が共有される方法によるものと考えられます。 29% は、特に要求された場合にのみチーム間で情報が共有されると回答しています。 情報を「技術情報、目標、計画、結果を提供するすべての人に公開」しているのはわずか16.8%です。 

運用中のアプリの動作に特有の情報がなければ、問題の原因はもちろん、問題が何であるかを見極めることも難しいことがよくあります。 「私のマシンでは動作する」というのは、多くの場合環境情報の不足から生じる不正な動作を再現できないことに対する開発者のフラストレーションから生まれた防御的なマントラです。

すべてのネットワーク関連の自動化に熱心ではないとしても、ChatOps は IT 部門と開発部門の間のコミュニケーション ラインを開き、問題に対するより深い洞察を提供して MTTR (平均解決時間) を短縮する優れた方法です。  これは、エンジニアに邪魔をしたり、細かく管理したりすることなく、「ネットワーク内」で何が起こっているかをより包括的に把握できる手段です。 これは、内向的な人が人と関わることなく交流できる方法を提供し、より頻繁に、徹底的に、そしておそらく熱心に共有することを促します。

ChatOps を初めて使用する場合は、 Jason Hand の電子書籍「ChatOps for Dummies 」をぜひ読んでみてください。 電子メールを放棄する必要がありますが、その価値はあります。 

ここで引き続きご注目ください。 将来的には ChatOps に関する詳細がさらに増えるでしょう。それは保証します。