知りたいDevOpsの実践方法はすべてここにあります

[51CTO.comからのオリジナル記事] インターネット産業の急速な発展に伴い、IT研究開発の作業方法はより柔軟かつ多様化しています。アプリケーションの観点から見ると、元の単一サービス アプリケーションから現在のマイクロサービス アプリケーションまで、処理されるデータの量と種類も増加しています。

[[281102]]

画像はPexelsより

チームの観点から見ると、開発者やテスターだけでなく、運用保守、セキュリティ、システム、ネットワークなど、さまざまな職種の人員が含まれます。

したがって、新しい時代においては、DevOps (開発と運用) 方法論をどのように活用して配信プロセスを導くかが特に重要になります。

まず、DevOps の 2 つの重要なポイントと 3 つの原則から始めて、組織、チーム、プロセスのベスト プラクティスを見ていきます。

DevOpsの2つの重要なポイントと3つの原則

あなたが行うすべてのことには価値があり、物事を実行するプロセスは「ビジネスアイデアを顧客価値に変換するプロセス」であり、私たちはこれをバリューストリームと呼んでいます。

R&D チームには、テクノロジーバリューストリームもあります。 「開発＋運用・保守」というアジャイルな反復アプローチを通じてユーザーに価値を提供します。テクノロジーバリューストリームが最初のポイントです。

開発と運用を通じてビジネスアイデアを顧客ニーズに届ける

バリューストリームを作成する作業を 2 つの段階に分けます。

• 最初の段階は設計と開発です
• 第二段階はテストと運用と保守です

テクノロジーバリューストリーム創造の2つの段階

リードタイムとは、顧客が要求を提起した時点から、その要求を解決するために作業指示書を作成し、作業指示書を処理して作業が完了するまでの合計時間です。リードタイムは注意すべき2番目のポイントです。

導入のリードタイムと処理時間

通常、設計、開発、テスト、運用、保守には多くの複雑で時間のかかるプロセスが伴います。

配送プロセスは複雑で時間がかかる

私たちの目標は、コード バージョン管理に小さなバッチのコードを継続的に送信することです。各提出物は、実稼働環境に展開される前に、自動的にコンパイルされ、自動的にテストされ、手動でテストされます (探索的テスト)。

この目標を達成するためには、設計、開発、テスト、リリースにかかる時間を可能な限り短縮し、顧客に最大限の技術的価値フローを提供する必要があります。

上記の 2 つの点を踏まえると、次の 3 つの DevOps 原則が最適な選択肢となります。

フロー原理

開発からローンチまでの時間を短縮し、サービスの品質と信頼性を向上させるために、開発（Dev）と運用（Ops）のフローを高速化します。どのような点に注意する必要があるかを見てみましょう。

① 作品を見えるようにする

従来の業界と比較すると、ソフトウェア開発業界の求人の可視性は低いです。通常、使用可能なユーザー インターフェイスは完全に完成した後にのみ表示され、一部のバックエンド サービスは完成しても表示されない場合もあります。

しかし、人間は目に見えないものをコントロールすることが難しいため、作業を視覚化する必要があります。

アジャイル開発では、各段階でタスクを分割し、プロジェクトの推奨とソフトウェア開発の完了を支援します。

開発、運用、保守、UAT、デリバリーの全プロセス

同時に、ソフトウェアがユーザーに提供され、ユーザーに価値をもたらした場合にのみ、私たちの仕事は完了することをチームに伝える必要があります。

②一人当たり同時に担当できるタスク数を制限する

このようなシナリオによく遭遇しますか?特定の機能を開発しているときに、テスターから緊急に解決する必要があるバグが報告されます。同時に、プロダクトマネージャーがあなたのところに来て、要件を変更する必要があるかもしれないと伝え、アーキテクトもリファクタリングについて話し合います。

その結果、人は同時に多くの事柄に対処しなければならなくなり、それぞれの事柄は重要であり、すぐに完了する必要があります。それはパンケーキを広げて、すべてをやろうとしているのに何もうまくいかないようなものです。頻繁に中断され、タスクを切り替える必要があるため、生産性が低下します。

そのため、カンバンを使って各人の作業量を管理し、作業数を適正なレベルに保ち、品質と効率を確保する必要があります。

1人が複数のタスクを担当

③バッチサイズを小さくする

開発プロセス中にこのような状況に遭遇することがよくあります。一つのことは4つのステップから成り、それを100回完了する必要があります。

そこで、抽象化と分業の原則に基づいて、このタスクを 4 つのステップに分割し、各ステップを 1 人の担当者に割り当てて完了させます。このように、各人が各ステップを 100 回完了すると、タスクが完了します。

この方法に間違いはありませんが、これを実行する初期段階では、1 人でこのタスクの 4 つのステップを一度完了して、潜在的な問題がないか確認し、その過程で要約できる経験や回避すべき落とし穴があるかどうかを確認するのが最適です。

このようなやり取りを数回繰り返し、いくつかの問題が解決したら、別のステップで手伝ってくれる他の人を数人見つけます。この方法は、試行錯誤を迅速に行うインターネット企業で広く使用されています。

まずクローズドループプロセスを完了し、その後エクスペリエンスを再現します

④引き継ぎ回数を減らす

タスクを完了するときには、他のチームや他の人とコミュニケーションを取り、依頼し、委任し、通知し、調整し、その他多くの作業を行う必要があります。

たとえば、ソフトウェアのリリース プロセスには、機能テスト、統合テスト、環境構築、サーバー構成、ストレージ管理、ネットワークなどのタスクが必要です。すべてを見直す必要がある場合、調整によって必然的に作業の効率が低下します。

ここでは、インターネット企業のフラットな経営が参考になります。各チームには、技術、ビジネス、管理、さまざまな分野の人員が含まれます。これにより、部門間のコミュニケーションが削減され、作業効率が向上します。

ハンドオフを減らす

⑤制約点の特定と改善

ソフトウェアの開発と配信のプロセスには、人員、時間、ソフトウェア、サーバー、ネットワークなど、多くの制約があります。

DevOps でも同じことが言えます。開発全体の進捗を進めるためには、この制約を常に特定し、継続的に改善する必要があります。

制約点間のスムーズな遷移を可能にする

環境構築：環境全体の構築を高速化するために、自動環境デプロイメントを使用し、最新のコンテナ技術（Docker）を使用することをお勧めします。

コードのデプロイメント: コードのアップロード、コンパイル、デプロイメントを自動化することをお勧めします。これらのアクションはソフトウェア配信チームで毎日実行されており、開発チームの人数が増えるほど、この作業を実行する必要も増えます。

テスト実行: これは前のポイントの続きです。ソフトウェアがリリースされたら、自動テストを実施する必要があります。

コア機能の少なくとも 20% は自動スクリプトを使用してテストし、その後、テスターは特定の機能に対してスモーク テストを実行する必要があります。

ソフトウェアの機能が拡張されるにつれて、テストの作業負荷も増加します。自動テストを使用しない場合、手動テストの作業負荷は非常に大きくなります。

分離アーキテクチャ: マイクロサービスの普及により、現在の設計は基本的にコンポーネントベースになっています。コンポーネントに問題が発生した場合、障害分離と回路ブレーカーのメカニズムが実装されるため、コンポーネントも解放する必要があります。

フィードバックの原則

フロー原則が開発から運用・保守への迅速なフローを指すのであれば、フィードバック原則は運用・保守から開発への迅速なフィードバックを指します。これら 2 つの原則はサイクルで機能し、最高かつ最速のソフトウェア サービスを顧客に提供します。

① 問題をタイムリーに発見する

サービス/製品の提供には、要件分析、プロトタイピング、アーキテクチャ設計、コーディング、テスト、リリース、統合テスト、受け入れテストから発売に至るまで、多くのプロセスが伴います。

各段階には作業員が関わっています。いかなる問題にも理由がある。問題の発生を防ぐことはできないとしても、できるだけ早く問題を発見して公表することはできます。

たとえば、プロダクトマネージャーが徹底的に分析しないと、開発中に不明確な要件が発生します。この時点で、プログラマーは質問を投げかける可能性があり、プロダクトマネージャーは要件を明確にする必要があります。

問題の発見、問題の報告、問題の解決のフローチャート

②分析問題を解く

開発中に発見された問題が要件や設計に記載されていない状況があります。エラーを放置すると、システムの動作に影響が出るのは明らかです。

関わらないように、関わらないようにという姿勢をとれば、問題はいつまでも発見されないでしょう。では、問題が発生したときにはどのように対処すればよいのでしょうか?

まず、上流リンクで問題が発生した場合、その問題を下流リンクに持ち込んではなりません。上流段階で問題を解決します。

上流リンクの問題

次に、新たな問題の発生を避けるために、上流リンクでの作業を一時停止します。

問題を発見し、速やかに対処する

3つ目は、PDCAサイクルを確立し、計画（Plan）、実行（Do）、確認（Check）、改善（Action）して、同様の問題が再発しないようにすることです。

PDCAメカニズムの構築

③ 品質を源泉から確保する

情報源は何ですか?上流は下流に対するソースです。プロダクトマネージャーは開発の源泉であり、要件の品質が標準に達していない場合、コードに影響が出ます。

プログラマーはテスターの源であり、プログラムの品質に問題があればテストにも影響が出ます。テスターは顧客の源であり、すべての問題が無視されると、顧客に価値をもたらすことはできません。

したがって、ソースを確保することは、配信の品質を確保することです。各プロセスと段階の監視に重点を置く必要があります。

• 需要段階: 需要のレビュー、需要の確認、および需要の伝達。
• 開発フェーズ: コードレビュー、ペアプログラミング、ユニットテスト。
• テストフェーズ: スモーク テスト、回帰テスト、受け入れテスト。
• リリース フェーズ: 自動構成、自動展開、自動検出。

ルートトレースチャート

④顧客への共感

顧客には、内部顧客と外部顧客の 2 種類があります。外部顧客は通常の意味での顧客です。当社は顧客にソフトウェアを提供し、顧客のニーズを満たし、顧客にとっての価値を創造します。

社内顧客は私たちの下流です。製品マネージャーは開発者を顧客として扱い、開発者はテスターを顧客として扱います。

私たちが何らかの行動を起こすとき、何らかの問題を発見するとき、あるいは何らかの決定を下すとき、私たちは「顧客」のことを考え、それが彼らにとって有益であるかどうかを考えるべきです。私たちは顧客の視点に立って問題を見なければならず、多くの問題はすぐに解決できます。

顧客はどこにいますか?顧客の視点に立つ

学習の原則

学習原則は、前の 2 つの原則をサポートする基本原則です。仕事でどれだけ多くの落とし穴に遭遇しても、コーディングの過程でどれだけ多くの失敗を経験しても、学ぶことを忘れないでください。継続的な学習により、人は強くなり、チームは徐々に成熟します。

①学習組織体制の構築

サービス提供の過程では、どれだけ注意しても間違いを避けることはできません。誰もが責任を負った経験を持っています。

たとえば、ある要件がプロダクトマネージャーによって最初に明確に述べられておらず、プログラマーが実装中にそれを無視した場合、納品時にはプログラマーの責任となり、プロジェクトマネージャーは開発者を心から批判することになります。

このシナリオは、私が仕事を始めた頃にはよく起こりました。その後、より多くのプロジェクトを引き受けるようになると、この「非難」による問題解決のやり方は間違っていることに気づきました。

問題そのものから始めて、問題の原因を突き止めなければなりません。要約すると、定義されたプロセスとメカニズムにより、兄弟が同様の間違いを再び犯すことが防止されます。

組織を3つのカテゴリーに分けるとしたら、ダイナミックな（学習する）組織になることを願っています。

組織タイプの分類

病的: 組織のメンバーは大きな恐怖と脅威（何か間違ったことをするのではないかという恐怖）を感じます。自分を守るために、誰もが責任を取ることを嫌がり、真実や事実さえも隠します。

官僚型: ルールや厳格なプロセスが多く、全員が自分の業務を担当します。

バイタリティ型（学習型）：常に要約し、間違いから学び、改善する。誰もが積極的に探求し、責任を引き受け、喜んで共有します。

生きた組織こそが私たちの目標です

②日常業務の制度化

ここでの制度化は、官僚主義のために煩雑な手続きを追加することではありません。それどころか、これらのシステムは、兄弟たちが仕事を通じて学んだ教訓の結果なのです。これらをシステムに変換する理由は、他の兄弟たちが同じ過ちを繰り返さないことを願うためです。

たとえば、以前リリースしたとき、データベース スクリプトを公開するのを忘れてしまい、その結果、実稼働環境でプログラムを実行できなくなっていました。その後、リリース前に必ず実行する必要があるものとして、データベース スクリプトの更新をリリース システムに記述しました。

その後、自動リリース用の自動スクリプトとして作成されました。実際、仕事では良い経験がたくさんあります。注意を払えば、このような継続的な改善の仕組みを構築し、暗黙のシステムにすることができます。実際、私たちの日々のコーディングには要約できることがたくさんあります。

たとえば、コーディング標準、命名標準、標準の MVP/MVC/MVVM 記述方法、リリース プロセス、テスト ケース、テスト スクリプトなどです。

システムはプロセスに役立つ

③ ローカル体験のグローバル化

開発・運用・保守の過程では、簡単に解決できるものもあれば、長い間悩まされるものもある、さまざまなイベント（落とし穴）に遭遇することがあります。

しかし、問題が最終的に解決された後、私たちはこれらの経験を、共有された経験の宝である知識ベースに保存したいと考えています。

実際、プロジェクトを完了した後、そこから何を学んだか、つまりこれらの経験の蓄積について自問してみてください。

次の仕事を探しているときに、面接官から「これまで遭遇した最も困難な問題は何か」と尋ねられたら、その経験を誇らしげに話すことができます。

経験がどんなに小さなものであっても、全体的な文脈で捉えると、他の技術者や、さらには部門を超えた技術者にとって刺激となり、役立つものとなる可能性があります。

ナレッジベースによるエクスペリエンスの管理

④射出弾性モード

ここで言う弾力性には 2 つの意味があります。1 つは人員の弾力性、もう 1 つは保守システムの弾力性です。

人員の柔軟性には、長征の回復力と、プロジェクトを全力で進める際に大渡河を渡る勇気が必要です。プロジェクトが忙しくないときでも、常に要約し、新しい知識を学習する必要があります。一人ひとりの成長だけがチーム全体の成長を推進することができます。

プロジェクトの弾力性では、ストレス テスト手法を使用して、保守対象のシステムに対して正と負のストレス テストを実行し、システムの許容限界を調査して改善します。

チームの回復力とシステムの回復力

DevOps 組織構造

コンウェイの法則によれば、ソフトウェア アーキテクチャとソフトウェア チームの構造は一貫しています。これは、コンウェイの法則によるチームとアーキテクチャの解釈です。

私はチームが小さなものから大きなものへと成長していく様子を目の当たりにしてきました。人数が少なかった初期の段階では、ワークフローの概念は強くなく、1 人が複数の役割の作業を行い、通信コストは基本的になく、ソフトウェア アーキテクチャは基本的に単一のアプリケーションでした。

その後、開発、テスト、運用、保守の人員が増加し、処理する必要のある全体的な作業負荷も増加しました。管理を容易にし、プロジェクトの効率化を促進するために、人と物を分割し、チーム間のプロセスとコミュニケーション方法を規定します。

アーキテクチャも当初の単一アプリケーションからその後のマイクロサービスへと変化し、データベースも当初の単一データベースから分割されたテーブルとデータベースのモデルへと変化しました。

組織構造がソフトウェアアーキテクチャを決定する

開発、テスト、運用保守の統合

開発プロセスでは、開発、テスト、運用・保守がそれぞれ異なる専門分野に属し、プロジェクトを進める過程でそれぞれが独自の責任を負います。 DevOps 組織構造では、これら 3 つを相互に統合する必要があります。

開発が完了したら、コードの品質を確保するためにユニットテストとペアプログラミングが必要になります。テストでは、バグを発見/検証し、運用および保守と連携してストレス テスト/パフォーマンス テストを完了する必要があります。

現在、多くの大企業では、第一線の運用・保守担当者が開発チームから出ており、開発者やテスターに​​運用・保守業務への参加を奨励している企業も増えています。自分の仕事が下流の仕事に与える影響を感じてもらいましょう。

開発、運用、保守、テストの統合

DevOps チームビルディング

チームメンバーはお互いに頼り合っている

DevOps の組織構造を理解したところで、チームのどのメンバーが参加する必要があるでしょうか?

• プロダクトオーナー: ビジネスの代表者であり、顧客と考えることができます。
• 開発チーム：特定の機能の開発を担当します。
• QA チーム: 品質保証を担当します。
• 運用保守チーム: 運用環境、構成、リリースを維持します。
• 情報セキュリティチーム: システムと情報のセキュリティを担当します。

もちろん、会社のニーズに応じて管理チームやサポート チームを追加することもできます。

スタートアップの場合、運用保守や情報セキュリティチームが存在しない場合は、開発チームからその役割を担う兄弟を見つけることをお勧めします。

チームバリューストリーム

複数のチームが協力して作業する場合、コミュニケーションと統一された理解に問題が生じます。バリュー ストリーム マップの目的は、全員の考えを統一し、各チーム メンバーにどの段階で何を行う必要があるかを知らせることです。実は、これらの図は以前の記事でも紹介されています。単純にチームとステージをマッチングするだけです。

チームバリューストリームマップ

オンラインで働く

チームを同じ方向に導きたい場合、効率的なツールを使用することが不可欠です。例: Confluence、Graphite Document、Jira、ZENTAO、ProcessOn、Jenkins、Bamboo、Git、JMeter、LoadRunner。

設計、開発、テストからリリースまで、あらゆる段階で作業効率を向上させることができます。チームの統一性を保ち、すべての作業をオンラインで維持します。

ツールをチームに役立ててオンラインで作業する

DevOpsパイプラインの展開

チームの目的は顧客のために価値を創造することです。ソフトウェアをユーザーに提供するプロセスは、工場の組立ラインのようなものです。組立ラインの上流は原材料であり、加工後の出力は商品です。 DevOps パイプラインの展開では、このプロセスを自動化する必要があります。

デリバリー チームとして、コードの記述を完了するたびに、それをバージョン ライブラリに送信する必要があります。送信後、バージョン ライブラリはコード全体をコンパイル (ビルド) し、ユニット テスト コードを実行します。

失敗した場合は、エラー メッセージが配信チームに送り返され、プログラマーはエラーを修正した後でコードを再度送信します。テストに合格した後のみ、自動スクリプト テストのためにテスト環境にリリースされます。

自動テストが失敗した場合は、開発チームに送り返され、さらに修正されます。このプロセスは、ユーザー受け入れテストに合格してリリースされるまで繰り返されます。

DevOpsパイプライン

提出段階：技術的な観点からシステムが機能するかどうかを判断します。このフェーズでは、通常はプログラマー自身によって記述されたユニット テスト スクリプトをコンパイルして実行します。

さらに、経験豊富なプログラマーが特定のコードについてコードウォークスルーを実施したり、プログラマー間でコードチェックを実施したりします。ここでは Junit ユニット テスト ツールを使用できます。

自動受け入れテスト フェーズ: システム全体が機能的かつ非機能的であること、つまりシステムの動作がユーザーのニーズを満たし、顧客の要件を満たしていることを確認します。

手動テスト フェーズ: システムが利用可能であり、システム要件を満たしているかどうかを判断し、自動テストでは検出できない欠陥を見つけるために使用されます。テストのこの部分はより複雑で、より多くのステップがあり、複数のシステムの切り替えも必要になります。

このフェーズには通常、探索的テスト、統合環境でのテスト、UAT (ユーザー受け入れテスト) が含まれます。テスターは、UAT のユースケースに基づいてシステムをテストします。

リリース フェーズ: ソフトウェアをユーザーに提供し、アプリケーションを運用環境に直接展開することを目的とします。導入後は運用・保守フェーズに入ります。

組立ラインに従って展開する利点は、各段階で配送品質を管理し、配送者の信頼を徐々に構築し、何層ものスクリーニングを通じて問題を回避できることです。

これは、開発者、テスト担当者、運用保守担当者向けのテストでもあります。アプリケーションをパイプライン上で継続的に処理し、さまざまな役職のチーム メンバーにタイムリーなフィードバックを提供するには、多くの共同作業が必要です。

パイプラインのいくつかのステージについて理解した後、各ステージでどのようなデータが生成され、そのデータがどのように流れるかを見てみましょう。

①プロセスの出発点は、開発者がコードリポジトリにコードを送信することです。コードをチェックインする前に、開発者はコード ライブラリ内の関連コードとコンポーネントをローカル コンピューターにダウンロードして、変更されたコードをローカルでコンパイルできることを確認する必要があります。

より標準化された企業では、コードレビューを申請し、他の同僚にコードをチェックしてもらうことが求められます。コード ベースにチェックインすると、プラットフォームは自動的にユニット テストを実行します。ただし、最初にユニットテストを実行することをお勧めします。

受け入れ段階に入ると、コンパイルに多くの時間がかかるからです。問題が発生した場合、システムはエラー レポートを生成し、チーム リーダーまたはプロジェクト チームに送信します。

その時点でコードを変更すると、バグがあなたから来たものであることが全員に知られてしまうのではないかと心配です。したがって、最初にローカルでユニット テストを実行することをお勧めします。

その範囲には、コードを変更するモジュールだけでなく、他のモジュールも含まれます。実際、他のモジュールを変更していなくても、コードを変更すると他のモジュールに影響する可能性があります。

継続的インテグレーション管理システムは、このコードの送信に応答し、指定されたコード リポジトリからコードを取得し、コンパイルし、単体テストを実行し、コード分析を実行し、コードをアセンブルしてパッケージ化します。

ユニット テストに合格し、コードがコーディング標準を満たしている場合は、実行可能ファイルにパッケージ化して、アーティファクト リポジトリに配置できます。

現在の継続的インテグレーション サーバーはすべてこれらの機能を提供しており、ユーザーとパイプラインの後続のステージが簡単に進行できるようにしています。

さらに、プロセス成果物の管理に役立つ Nexus や Artifactory などのツールもあります。現時点では比較的成熟した製品です。たとえば、Bamboo と Jenkins は、スクリプト コマンドを使用してコード ライブラリと完成品ライブラリを構成することで、上記の操作を完了できます。

②第2段階は通常、実行時間が長い自動受け入れテストで構成されます。これらのテストの主な内容は、いくつかの API とモジュールのテストです。

一部のプロジェクト チームではページのテストにも使用していますが、ページ自動化は個人的にはお勧めしません。特にページ設計の初期段階では、ページ要素が頻繁に変更され、自動化されたスクリプトも大きく変更されるため、効果はあまり良くありません。

この後、デプロイメント パイプラインが分岐して、ユーザー受け入れテスト環境、キャパシティ テスト環境、運用環境など、複数の異なる環境にビルドを個別にデプロイできるようになります。

DEV（開発）環境、INT（統合テスト）環境、MO（準本番）環境、Prod（本番）環境などのシリアル例もあります。

通常、テスターや運用・保守担当者がセルフサービス、つまり手動で必要なバージョンを選択できるようにすることが望まれます。

たとえば、Bamboo または Jenkins を使用して、完成した製品ライブラリ内のアプリケーション バージョンを選択し、指定された環境に公開することができます。

いわゆる自動デプロイメント スクリプトは、サーバー上で実行できる一連のコマンドであり、コマンドを実行することでデプロイメント作業が完了します。

テスターは、手動でテストする必要があるすべてのビルドとそのステータスを確認し、ボタンをクリックして対応するデプロイメント スクリプトを実行し、選択したビルドを選択した環境にデプロイできる必要があります。

提出と承認の段階

要約する

DevOps モデルは、迅速なフロー、タイムリーなフィードバック、継続的な学習という 3 つの原則に従う必要があります。したがって、DevOps 組織構造では、開発、テスト、運用の間の緊密な連携が必要です。

この基準に従ってチームを構築し、チームにバリューストリームを生成させ、オンラインで作業することでユーザーに価値を提供します。

DevOps の価値はパイプラインの展開方法にあり、そのためには送信、承認、手動テスト、リリースの各段階を適切に構成する必要があります。アプリケーションを迅速に配布し、チームがタイムリーなフィードバックを受け取れるようにすることで、ソフトウェア配信を着実に進めることができます。

著者: 崔昊

紹介: 16 年間の開発およびアーキテクチャの経験を持ち、HP 武漢デリバリー センターで技術専門家、需要アナリスト、プロジェクト マネージャーとして勤務し、その後、スタートアップ企業でテクノロジー/製品マネージャーとして勤務しました。学習が得意で、共有する意欲があります。現在は技術アーキテクチャと研究開発管理に重点を置いています。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]