ギャップを埋める：DevOpsコミュニケーションの重要性

公開: 2022-03-11

DevOpsの方法論はかなり前から存在していますが、それでも活発な議論の中心となっています。企業はそれを望んでいますが、どのようにアプローチするかがわかりません。

DevOpsはどこにでもあります。そして、それは興味深い傾向ですが、その逆ではなく、製品に適合させる必要があります。

しかし、一部の人々はそれをそのように見ていません。「Dockerを使い始めるべきだと思いますか、それともKubernetesに直接飛び込むべきだと思いますか？」などの質問をよく受けます。そのような質問は、製品が何であるかさえ知らなければ意味がありません。

クラウド、Kubernetes、コンテナー、構成管理、Infrastructure-as-Codeなどのこれらすべての派手な用語は、いくつかの改善を約束します。しかし、望遠鏡が天文学にあるのと同じように、それらはDevOpsにあります。それらは役に立つかもしれませんが、必須ではありません。

DevOpsの核となるのは、クライアントが注文したものと開発チームが提供したものとの間のギャップを埋めることです。短いリリースサイクル、設計への反復的なアプローチ、および反復的なステップの自動化に重点が置かれています。それらを実現するために最も重要なことは何だと思いますか？

あなたが「素晴らしいコミュニケーション」と言ったなら、あなたは正しいです。ツールはすべて問題ありません。しかし、彼らがコミュニケーションを改善するとき、彼らは彼らに投資されたお金の価値があるだけです。

コミュニケーションの1つの側面は、仕事を成し遂げるために何が必要かを知ることです。そして、この仕事は「コードがリポジトリにコミットされる」という意味ではありません。むしろ、「クライアントは本番環境の変更を見て、それを受け入れた」と考えてください。

この最初のステップが決定され、誰もが何が起こる必要があるかを知ったらすぐに、それを書き留めるのに最適な時期です。どこ？ええと、私はREADME.mdを維持することを大いに支持しています。チームの各人はいつでもチーム内を覗いてプロジェクトの状態を知ることができ、プロジェクトの新規参入者にとっては当然のことです。

READMEを作成した後の次のステップである自動化はオプションです。ただし、これはプロセスを文書化することの自然な結果です。そしてそうです、自動化はDevOpsについて考えるときにしばしば頭に浮かぶものです。

ちょっと待ってください…DevOpsに関しては自動化はオプションですか？ DevOpsは、デプロイメントを行う人の部門ではありませんか？

「DevOpsエンジニア」という用語で一般的に理解されているのは、ソフトウェア信頼性エンジニア、プラットフォームエンジニア、または運用自動化エンジニアのいずれかです。これらはすべて、DevOpsの実践を可能にする有効な役割ですが、「DevOpsエンジニア」という総称を使用することは少しあいまいな場合があります。

それでは、DevOps自体を詳しく見てみましょう。

DevOpsの説明

まず、DevOpsが何でないかをお見せしましょう。

役職の接頭辞だけではありません
チームではありません（ただし、「Dev」と「Ops」はチームです）
テクノロジーではありません
「コーディングできるシステム管理者」という意味ではありません
「ものを自動化する」という意味ではありません
「現在、運用チームがない」という意味ではありません。

これを知っていると、将来を見据えたものにするために、会社で単に「DevOpsエンジニアを雇う」または「DevOpsチームを作成する」ことはできないことに気づきました。 DevOpsはアジャイル開発に似ています。アジャイル開発者をそのように雇いますか？おそらくそうではありません。アジャイルな方法で製品を開発するか、しないかのどちらかです。

では、DevOpsはどのように説明できますか？それは方法論です。または多分文化。おそらく精神さえ。 DevOpsの原則に従って製品を実行するということは、開発者、運用エンジニア、製品マネージャーなど、すべての人が共通のビジョンを共有し、コミュニケーションを通じてそれを維持することを意味します。程度は低いですが、それはまた、誰もが同じツールを使用することを意味します。これらのツールは、単一のグループの人々を支援することを目的としたものではありません。それらは製品を前進させることを目的としています。

このコンセプトを採用するには、考え方を大きく変える必要があり、それが主な障害です。何故ですか？それは、人々が自分の快適ゾーンから出て、異なる能力を持つ人々と協力し始めなければならないからです。開発者は突然、クラウドがどのように機能するかを学び、独自のコードのデプロイを開始する必要があります。運用担当者は、手動セットアップを放棄してコーディングを開始する必要があります。誰もが新しい概念を学ぶ必要があります。誰もが新しい責任を負っています。

これは簡単なことではありませんが、良好なコミュニケーションと共通の目標があれば、かなり達成可能です。このコミュニケーションには、文化の確立、軽量プロセスの設定、および適切なドキュメントの維持が含まれます。

DevOpsAutomationはドキュメントです

あなたはおそらくそれをそのように考えたことはありません。しかし、DevOpsに一般的に関連付けられているツールのほとんどは、ドキュメントツールです。

読みやすくするために作成されたビルドスクリプトは、ビルドプロセスを文書化するのに役立ちます
継続的インテグレーションパイプラインは、単一のピースの構築から製品全体までの統合プロセスを文書化します
継続的デプロイのパイプラインは、クライアントが使用できる製品をデプロイする方法を文書化することでさらに進んでいます
構成管理ファイルは、インストールと構成のプロセスを文書化します
Infrastructure-as-codeの仕様には、必要なインフラストラクチャが文書化されています（実際にはかなり正式に！）
コンテナーには、特定のマイクロサービスを構築および構成する方法を文書化した独自のDockerfileが付属しています

これらの派手な概念はすべて、基本的に1つのことを行います。プロセスを文書化することで、チームメンバーのコミュニケーションを改善します。これらのプロセスは、手動または自動で実行できます。重要なのは、プロジェクトのすべての利害関係者がそれらをフォローできることです。

プロセスをコードとして文書化することには、通常の取扱説明書に比べて大きな利点が1つあります。コードを検証して予測的に動作させることができます。同じ入力が与えられると、同じ出力が生成されます。

書面による指示があれば、読者と同じ数の解釈が得られます。あいまいまたはあいまいなドキュメントを作成すると、それを読んだ人がギャップを埋めます。ポイントは、ギャップに何が入るかを制御できないということです。

コードを使用すると、はるかに簡単になります。具体的な手順がないと、プログラムの実行が停止します。これらの具体的な手順は、DevOpsコミュニケーションの重要な側面の1つです。

DevOpsコミュニケーション：開発と運用の間のギャップを埋める唯一の方法

『フェニックスプロジェクト』という本では、最近昇進したマネージャーが大きなプロジェクトの展開を任されているという問題を目の当たりにしています。何が起こっているのか誰も知らないので、誰もがあまり進歩することなく火事と戦っています。本のサブタイトルは、それがDevOpsの物語であると述べています。私はそれに同意します。

しかし、興味深いのは、本の全過程を通じて、新しいツールが1つも紹介されていないことです。コミュニケーションだけを改善することで、DevOpsの状態を実現できますか？本の主人公がやったので、あなたにも希望があります！

主人公のアプローチは「古い学校」と見なされるかもしれませんが（適切なバグ追跡システムの代わりに実際の紙のカードを使用）、関係者全員が互いに話し始めて初めて状況は良くなり始めます。

サービスレベルアグリーメントやインシデントバックログなど、開発と運用の間のより良いインターフェイスを作成することによってのみ、開発と運用の間のコラボレーションを改善できると考えるかもしれません。しかし、その逆が当てはまります。インターフェースを解体し、共感と共通の原因を導入することで、共通の目標に向かって取り組むチームができます。

DevOpsチーム構造：チームには誰がいますか？

理想的には、各製品には1つのチーム（製品チーム）のみが必要です。

私はかつて、他のチームとの共通の目標がなかった開発チームに所属していました。開発チームは、できるだけ多くの変更をプッシュしたいと考えていました。検証チームは、欠陥の導入を防ぐという任務を負っていました。彼らには異なるマネージャーがいて、個別に評価されました。

結果？開発と検証は、欠陥レポートでピンポンを行いました。検証で合格しないテストが見つかった場合、開発者は、独自のコードにバグがないようにするよりも、テストコード自体の欠陥を見つけることに関心がありました。

もちろん、レポートやカウンターレポートなどを適切に入力するには膨大なオーバーヘッドが必要だったため、リリースサイクルは急増しました。最も認識されていないように思われたのは、製品に関しては、両方のチームが共通の目標を共有し、それを達成するために協力する必要があるということでした。しかし、適切な協力とサイロ精神の欠如は、気付くのを非常に難しくしました。

廃棄物との戦いは共同の努力です

アジャイルソフトウェア開発のマニフェスト（DevOpsを紹介した）に影響を与えたリーン生産方式は、無駄との戦いに関するものでした。無駄とは、クライアントの注文に直接関係しないすべてのものを意味します。積み上げられた仕掛品は無駄です。明らかにリリースにつながらないプロセスのすべてのステップは無駄です。

しかし、廃棄物は高いレベルからしか見ることができません。 1つのチームの範囲では、いくつかの手順が不可欠に見える場合があります。ただし、製品の観点からは、役に立たない可能性があります。

どの努力が無駄になっているのかを把握するには、力を合わせて、出荷された製品のライフサイクルを検討する必要があります。また、クライアントの視点から考える必要があります。この機能はクライアントが望んでいたものですか？そうでない場合は、この時点でスキップすることもできます。あなたのプロセスはシンプルで無駄がありませんか？特にチームの境界を越えるものを詳しく見てください。

製品の開発が可能な限り効率的になるようにしたいですか？部外者を招待して、あなたがどのように働いているかを見てもらいます。チームに属していない人は、洞察に満ちた質問をしたり、改善すべき新しい領域を見つけたりすることができます。

DevOpsの原則：CALM（S）を維持する

CALMSは、DevOpsを実践する方法を非常に正確に説明したものです。

文化
utomation
リーン
測定
共有

サンドイッチのように形成されていることに注意してください。 3つの中間の値はより技術的ですが、外側の値はソフトスキルに関連しています。しかし、すべての文化の基本はコミュニケーションです。私たちは、物事がどのように振る舞うべきかについて合意に達するまで、他のチームメンバーと私たちの価値観と信念を交換します。

同じことが共有にも当てはまります。食べ物のような基本的なものを共有することは、コミュニケーションを必要としません。ただし、ジェスチャー自体はコミュニケーションの行為と見なすこともできます。「私はあなたのことを気にかけているので、あなたと分かち合います。」範囲を口頭でのコミュニケーションだけに限定したくはありません。

ただし、アイデアやツールを共有するには、コミュニケーションが必要です。それらをどのように共有する必要がありますか？それらをどこに置くのですか？チームのすべての人に役立ちますか、それとも少人数のグループに役立ちますか？

自動化、リーン、測定など、より技術的な側面のみに焦点を当てると、DevOpsのポイントが失われます。自動展開スクリプトを作成することで、作成者以外に誰も使用しないほど優れている点は何ですか？スクリプトが彼女の時間を節約するなら、それは正当化されるかもしれません。しかし、全員がこのスクリプトを共有した場合、どれだけの時間を節約できるか想像してみてください。これは無駄との戦いについて何かを言います！

自動化、リーン、測定など、より技術的な側面のみに焦点を当てると、DevOpsのポイントが失われます。

つぶやき

DevOpsはビジネスを開発に近づけます

DevOpsは運用を開発に近づけると言う人もいます。これは真実ですが、それは完全な真実ではありません。正しく行われると、DevOpsはすべてのユニットを近づけます。これにより、ビジネスとクライアントは、開発が何を行っているかをほぼリアルタイムで確認できます。

この短いフィードバックループは、すべての利害関係者に利益をもたらします。作業は一般的に見やすく、開発者も、クライアントが生成したコードをどのように使用しているかを簡単に確認できます。従来の展開では、誰かがバグや要件の欠落に気付くまでに数か月待つことができます。継続的展開により、問題が発生したときに誰もがそれに対応できます。開発者、運用、ビジネス、およびクライアントは、1つの部屋に座って、現在のニーズに応じて動作中のアプリケーションを変更できます。

DevOpsツールを最初に？もう一度考えて

もちろん、それを可能にするためのすべてのツールが必要です。

しかし、社内の良好なコミュニケーションと共感に代わるツールはありません。私はかつて、ビルドプロセスが1つのチームによって所有され、提供されたコードが別のチームによって所有されている製品を観察しました。

ビルドシステムの問題は一般的でした。開発者はそれを使用する方法がわかりませんでした。これは標準ツールに基づいていましたが、Web上で利用可能なすべてのドキュメントが役に立たないことが判明するまでカスタマイズされました。

誰もが状況を改善したかったのですが、2つのチームの間に理解がありませんでした。これは、双方が他方に相談することなく新しいツールを導入したことを意味しました。これは、ギャップを埋めるのではなく、ギャップを広げるだけでした。

組織内でDevOpsの変革を開始したい場合は、コミュニケーションの方法を改善することから始めます。単純に解決策を想定しないでください。最初に心を開いてブレインストーミングを行います。次に、たとえば、ツールのサポートがニーズに対して不十分であることに気付く場合があります。そのとき、現在のツールを微調整したり、新しいツールを導入したりすることを検討できます。そうしないと、元の問題に追加される可能性があります。

DevOpsを確立する最も簡単な方法は？より良いコミュニケーション！

イントロダクションで、クライアントからよく聞かれる質問について説明しました。「Dockerを使用する必要がありますか、それともKubernetesに直接ジャンプする必要がありますか？」この記事を読んだ後、DevOpsの考え方で準備作業を行った後、そのような質問に最もよく答えられることがわかります。

製品チームがDevOpsのメリットを自分自身とクライアントにとって理解していることがわかっている場合、チームとクライアントは期待を設定することから始めることができます。次に、エンジニアは開発および展開モデルを理解できます。最後に、必要なツールを決定できます。

すべての要件が文書化されると、テクノロジーの選択がはるかに簡単になります。

私は、作業をより簡単で管理しやすくするすべての優れたDevOps自動化ツールの提唱者です。しかし、私たちの毎日の仕事は人々と協力することです。別のテクノロジー証明書を取得するのではなく、DevOpsのベストプラクティスのこの側面を改善するために時間を費やしてみましょう。