DevOpsの方法論はかなり前から使用されてきましたが、それでも活発な議論の中心となっています。企業はそれを望んでいますが、どのようにアプローチするかがわかりません。
DevOpsはどこにでもあります 。これは興味深いトレンドですが、製品に適合させる必要があります。その逆ではありません。
しかし、一部の人々はそれをそのように見ていません。 「Dockerを使い始めるべきだと思いますか、それともKubernetesに直接飛び込むべきだと思いますか？」などの質問をよく受けます。そのような質問は、製品が何であるかさえ知らなければ意味がありません。
これらすべての派手な用語—クラウド、 知事 、コンテナ、構成管理、Infrastructure-as-Code-いくつかの改善を約束します。しかし、彼らは DevOps 望遠鏡が天文学にあるのと同じように。それらは役に立つかもしれませんが、必須ではありません。
DevOpsの核となるのは、クライアントが注文したものと開発チームが提供したものとの間のギャップを埋めることです。短いリリースサイクル、設計への反復的なアプローチ、および反復的なステップの自動化に重点が置かれています。それらを実現するために最も重要なことは何だと思いますか？
あなたが「素晴らしいコミュニケーション」と言ったなら、あなたは正しいです。ツールはすべて問題ありません。しかし、彼らがコミュニケーションを改善するとき、彼らは彼らに投資されたお金の価値があるだけです。
コミュニケーションの1つの側面は、仕事を成し遂げるために何が必要かを知ることです。そして、この仕事は「コードがリポジトリにコミットされる」という意味ではありません。むしろ「クライアントは生産の変化を見てそれを受け入れた」と考えてください。
この最初のステップが決定され、何が必要かが誰もがわかったら、それを書き留めるのに最適な時期です。どこ？ええと、私はREADME.mdを維持することを大いに支持しています。チームの各メンバーは、いつでもチーム内を覗いてプロジェクトの状態を知ることができます。これは、プロジェクトの新規参入者にとって当然のことです。
READMEを作成した後の次のステップである自動化はオプションです。ただし、これはプロセスを文書化することの自然な結果です。そして、はい、自動化はDevOpsについて考えるときにしばしば頭に浮かぶものです。
ちょっと待ってください…DevOpsに関しては自動化はオプションですか？ DevOpsは、展開を行う人の部門ではありませんか？
フロントエンドデザインとは
「DevOpsエンジニア」という用語で通常理解されるのは、ソフトウェア信頼性エンジニア、プラットフォームエンジニア、または運用自動化エンジニアのいずれかです。これらはすべて、DevOpsの実践を可能にする有効な役割ですが、「DevOpsエンジニア」という総称を使用することは少し曖昧かもしれません。
それでは、DevOps自体を詳しく見てみましょう。
まず、DevOpsが何でないかをお見せしましょう。
これを知っていると、将来を見据えたものにするために、企業で単に「DevOpsエンジニアを雇う」または「DevOpsチームを作成する」ことはできないことに気づきました。 DevOpsはアジャイル開発に似ています。アジャイル開発者を雇いますか など ？おそらくそうではありません。アジャイルな方法で製品を開発するか、しないかのどちらかです。
では、DevOpsはどのように説明できますか？それは方法論です。または多分 文化 。おそらく精神さえ。 DevOpsの原則に従って製品を実行するということは、開発者、運用エンジニア、製品マネージャーなど、すべての人が共通のビジョンを共有し、コミュニケーションを通じてそれを維持することを意味します。程度は低いですが、それはまた、誰もが同じツールを使用することを意味します。これらのツールは、単一のグループの人々を支援することを目的としたものではありません。それらは製品を前進させることを目的としています。
UIデザイナーとは
このコンセプトを採用するには、考え方を大きく変える必要があり、それが主な障害です。何故ですか？それは、人々が自分の快適ゾーンから出て、さまざまな能力を持つ人々とのコラボレーションを開始する必要があるためです。開発者は突然、クラウドがどのように機能するかを学び、独自のコードのデプロイを開始する必要があります。運用担当者は、手動セットアップを中止してコーディングを開始する必要があります。誰もが新しい概念を学ぶ必要があります。誰もが持っています 新しい責任 。
これは簡単なことではありませんが、良好なコミュニケーションと共通の目標があれば、かなり達成可能です。このコミュニケーションには、文化の確立、軽量プロセスの設定、および適切なドキュメントの維持が含まれます。
あなたはおそらくそれをそのように考えたことはありません。しかし、DevOpsに一般的に関連付けられているツールのほとんどは ドキュメントツール ：
Dockerfile s 特定のマイクロサービスを構築および構成する方法を文書化したこれらの凝った概念はすべて、基本的に1つのことを行います。プロセスを文書化することにより、チームメンバーのコミュニケーションを改善します。これらのプロセスは、手動または自動で実行できます。重要なのは、プロジェクトのすべての利害関係者がそれらをフォローできることです。
プロセスをコードとして文書化することには、通常の取扱説明書に比べて大きな利点が1つあります。コードは検証でき、予測的に動作します。同じ入力が与えられると、同じ出力が生成されます。
書面による指示があれば、読者と同じ数の解釈が得られます。あいまいなドキュメントやあいまいなドキュメントを作成した場合、それを読んだ人がギャップを埋めます。重要なのは、ギャップに何が入るかを制御できないということです。
コードを使用するとはるかに簡単になります。具体的な手順がないと、プログラムの実行が停止します。これらの具体的な手順は、DevOpsコミュニケーションの重要な側面の1つです。
本の中で フェニックスプロジェクト 私たちは、大きなプロジェクトの展開を任された最近昇進したマネージャーの問題を目の当たりにしています。何が起こっているのか誰も知らないので、誰もがあまり進歩することなく火事と戦っています。本のサブタイトルは、それがDevOpsの物語であると述べています。私はそれに同意します。
しかし、興味深いのは、本の中で、新しいツールが1つも紹介されていないことです。コミュニケーションだけを改善することで、DevOpsの状態を実現できますか？この本の主人公がやったので、あなたにも希望があります！
主人公のアプローチは「古い学校」と見なされる場合がありますが（適切なバグ追跡システムの代わりに実際の紙のカードを使用）、関係者全員が互いに話し始めて初めて状況は良くなり始めます。
サービスレベルアグリーメントやインシデントバックログなど、開発と運用の間のより良いインターフェイスを作成することによってのみ、開発と運用の間のコラボレーションを改善できると考えるかもしれません。しかし、その逆が当てはまります。インターフェースを解体し、共感と共通の原因を導入することで、共通の目標に向かって取り組むチームができます。
理想的には、各製品には1つのチーム（製品チーム）のみが必要です。
私はかつて、他のチームとの共通の目標がなかった開発チームに所属していました。開発チームは、できるだけ多くの変更をプッシュしたいと考えていました。検証チームは、欠陥の導入を防ぐという任務を負っていました。彼らには異なるマネージャーがいて、個別に評価されました。
結果？開発と検証は、欠陥レポートでピンポンをしました。検証で合格しないテストが見つかったとき、開発者は、独自のコードにバグがないようにするよりも、テストコード自体の欠陥を見つけることに関心がありました。
もちろん、レポートやカウンターレポートなどを適切に入力するために膨大なオーバーヘッドが必要だったため、リリースサイクルは急増しました。最も認識していなかったのは、製品に関しては、両方のチームが共通の目標を共有し、それを達成するために協力する必要があるということでした。しかし、適切な協力とサイロ精神の欠如は、気付くのを非常に難しくしました。
色は人々にどのように影響しますか
アジャイルソフトウェア開発のマニフェストに影響を与えたリーン生産方式の考え方（ これにより、DevOpsが紹介されました ）無駄と戦うことについてでした。無駄とは、クライアントの注文に直接関係のないすべてのものを意味します。積み上げられた仕掛品は無駄です。明らかにリリースにつながらないプロセスのすべてのステップは無駄です。
しかし、廃棄物は高いレベルからしか見ることができません。 1つのチームの範囲では、いくつかの手順が不可欠に思えるかもしれません。ただし、製品の観点からは、役に立たない可能性があります。
どの努力が無駄になっているのかを把握するには、力を合わせて、出荷された製品のライフサイクルを検討する必要があります。また、クライアントの視点から考える必要があります。この機能はクライアントが望んでいたものですか？そうでない場合は、この時点でスキップすることをお勧めします。あなたのプロセスはシンプルで無駄がありませんか？特にチームの境界を越えるものについて詳しく見てみましょう。
製品の開発が可能な限り効率的になるようにしたいですか？あなたがどのように働いているかを見るために部外者を招待してください。チームに属していない人は、洞察に満ちた質問をしたり、改善すべき新しい領域を見つけたりすることができます。
CALMSは、DevOpsを実践する方法を非常に正確に説明しています。
サンドイッチのように形成されていることに注意してください。真ん中の3つの値はより技術的ですが、外側の値はソフトスキルに関連しています。しかし、すべての文化の基本はコミュニケーションです。私たちは、物事がどのように振る舞うべきかについて合意に達するまで、他のチームメンバーと価値観や信念を交換します。
同じことが共有にも当てはまります。食べ物のような基本的なものを共有することは、コミュニケーションを必要としません。ただし、ジェスチャー自体はコミュニケーションの行為と見なすこともできます。 「私はあなたのことを気にかけているので、あなたと分かち合います。」範囲を口頭でのコミュニケーションだけに限定したくはありません。
ただし、アイデアやツールを共有するには、コミュニケーションが必要です。それらをどのように共有する必要がありますか？どこに置くの？チームのすべての人に役立ちますか、それとも少人数のグループに役立ちますか？
より技術的な側面（自動化、リーン、測定）のみに焦点を当てると、DevOpsのポイントが失われます。自動化された展開スクリプトを使用して、作成者以外に誰も使用しないほど優れている点は何ですか。スクリプトが彼女の時間を節約するなら、それは正当化されるかもしれません。しかし、全員がこのスクリプトを共有した場合、どれだけの時間を節約できるか想像してみてください。これは無駄との戦いについて何かを言います！
より技術的な側面（自動化、リーン、測定）のみに焦点を当てると、DevOpsのポイントが失われます。 つぶやきDevOpsは運用を開発に近づけると言う人もいます。これは真実ですが、それが完全な真実ではありません。正しく行われると、DevOpsはすべてのユニットを近づけます。これにより、ビジネスとクライアントは、開発が何を行っているかをほぼリアルタイムで確認できます。
この短いフィードバックループは、すべての利害関係者に利益をもたらします。作業は一般的に見やすく、開発者も、クライアントが生成したコードをどのように使用しているかを簡単に確認できます。従来の展開では、誰かがバグや要件の欠落に気付くまでに数か月待つことができます。継続的デプロイにより、問題が発生したときに誰でも対応できます。開発者、運用、ビジネス、およびクライアントは、1つの部屋に座って、現在のニーズに応じて作業アプリケーションを変更できます。
もちろん、それを可能にするためのすべてのツールが必要です。
しかし、社内での良好なコミュニケーションと共感に代わるツールはありません。私はかつて、ビルドプロセスが1つのチームによって所有され、提供されたコードが別のチームによって所有されている製品を観察しました。
ビルドシステムの問題は一般的でした。開発者はそれを使用する方法がわかりませんでした。これは標準ツールに基づいていましたが、Web上で利用可能なすべてのドキュメントが役に立たないことが判明するまでカスタマイズされました。
誰もが状況を改善したかったのですが、2つのチームの間に理解がありませんでした。これは、双方が反対側と協議することなく新しいツールを導入したことを意味しました。これは、ギャップを埋めるのではなく、ギャップを広げるだけでした。
組織内でDevOpsの変革を開始したい場合は、コミュニケーションの方法を改善することから始めます。単純に解決策を想定しないでください。オープンマインドでブレインストーミングを行います。 最初 。次に、たとえば、ツールのサポートがニーズに対して不十分であることに気付く場合があります。そのとき、現在のツールを微調整したり、新しいツールを導入したりすることを検討できます。そうしないと、元の問題に追加される可能性があります。
はじめに、クライアントからよく聞かれる質問について説明しました。「Dockerを使用する必要がありますか、それともKubernetesに直接ジャンプする必要がありますか？」この記事を読んだ後、DevOpsの考え方で準備作業を行った後、そのような質問に最もよく答えられることがわかります。
製品チームがDevOpsの利点を自分自身とクライアントにとって理解していることがわかっている場合、チームとクライアントは期待を設定することから始めることができます。次に、エンジニアは開発および展開モデルを理解できます。最後に、必要なツールを決定できます。
すべての要件が文書化されると、テクノロジーの選択がはるかに簡単になります。
私は、作業をより簡単で管理しやすくするすべての優れたDevOps自動化ツールの提唱者です。しかし、私たちの毎日の仕事は 人 。別のテクノロジー証明書を取得するのではなく、DevOpsのベストプラクティスのこの側面を改善するために時間を費やしましょう。
DevOpsチームは、開発と運用を融合して、以前よりもはるかに迅速かつ堅牢な方法でソフトウェアの増分を提供します。
DevOpsチームの責任には、幅広い分野の役割が含まれます。QAエンジニア、クラウドプラットフォームエンジニア、サイト信頼性エンジニア、自動化エンジニア、製品デザイナー、製品開発者、製品所有者、ソフトウェアアーキテクトはすべてその一部です。
コードの書き方
DevOpsの原則は、無駄、顧客中心の行動、エンドツーエンドの責任、部門の枠を超えた自律的なチーム、継続的な改善、優れたコミュニケーション、そして可能な限り自動化を回避することです。
DevOpsは、開発チームと運用チームの人々を、口頭で、また共通のプロセスとツールを使用して、より良いコミュニケーションを支援することにより、集める方法です。
DevOpsは、アジャイルチームが高品質のソフトウェア増分を提供できるようにするために使用されます。
