カオスの管理: テクノロジー マップを利用して物事を整理する

画像： Unsplash

こんにちは、みんな！ 私たちは社内の自動化エンジニアです ポジティブテクノロジー また、当社は会社の製品の開発をサポートします。開発者によるコード行のコミットから、更新サーバーでの完成品とライセンスの公開に至るまで、アセンブリ パイプライン全体をサポートします。 非公式には、私たちは DevOps エンジニアと呼ばれます。 この記事では、ソフトウェア制作プロセスの技術段階と、それらをどのように認識し、どのように分類するかについて説明したいと思います。

この資料から、複数製品の開発を調整することの複雑さ、技術マップとは何か、ソリューションの合理化と複製にそれがどのように役立つか、開発プロセスの主要な段階と手順は何か、責任領域はどのようになっているのかについて学びます。 DevOps と社内のチームの間で。

カオスとDevOpsについて

簡単に言うと、DevOps の概念には、開発ツールとサービス、およびそれらを使用するための方法論とベスト プラクティスが含まれます。 グローバルを取り上げましょう 目標 当社での DevOps アイデアの実装によるものです。これは、製品の生産およびメンテナンスのコストを定量的に (工数またはマシン時間、CPU、RAM、ディスクなど) 一貫して削減することです。 会社全体のレベルで開発の総コストを削減する最も簡単かつ明白な方法は、 一般的なシリアルタスクの実行コストを最小限に抑える 生産のあらゆる段階で。 しかし、これらの段階とは何でしょうか、一般的なプロセスからどのように分離するのか、どのようなステップで構成されているのでしょうか?

企業が 5 つの製品を開発するときは、すべてが多かれ少なかれ明確です。通常、共通のロードマップと開発スキームが存在します。 しかし、製品ラインが拡大して製品数が増えたらどうすればよいでしょうか? 一見したところ、それらは似たようなプロセスと組み立てラインを持っており、ログとスクリプトから「X 個の違いを見つける」ゲームが始まります。 しかし、すでに XNUMX つ以上のプロジェクトが活発に開発されており、数年かけて開発された複数のバージョンのサポートが必要な場合はどうなるでしょうか? 製品パイプラインで可能な限り最大数のソリューションを再利用したいですか、それともそれぞれのソリューションに独自の開発に資金を費やす準備ができていますか?

独自性とシリアル ソリューションの間のバランスを見つけるにはどうすればよいでしょうか?

2015 年以降、こうした疑問がますます頻繁に私たちの前に現れるようになりました。 製品の数が増加したため、これらの製品の組み立てラインをサポートする自動化部門 (DevOps) を最小限に拡大しようとしました。 同時に、製品間でできるだけ多くのソリューションを複製したいと考えました。 結局のところ、なぜ XNUMX 個の製品で同じことが異なる方法で行われるのでしょうか?

開発ディレクター: 「皆さん、DevOps が製品に対して何を行うかを何らかの方法で評価することはできますか?」

我々: 「そのような質問をしたわけではないのでわかりませんが、どのような指標を考慮する必要がありますか?」

開発ディレクター： "知るか！ 考える…"

あの有名な映画のように、「ホテルにいるよ！ ..」 - 「ええと...道を教えてくれませんか?」 熟考した結果、私たちはまず製品の最終状態を決定する必要があるという結論に達しました。 これが私たちの最初の目標になりました。

では、ソリューションを複製する際に、10 ～ 200 人のかなり大規模なチームで十数の製品をどのように分析し、測定可能な指標を決定するのでしょうか?

1:0 で Chaos または肩甲骨上の DevOps を支持

私たちは、IDEF0 図と BPwin シリーズのさまざまなビジネス プロセス図を適用する試みから始めました。 混乱は、次のプロジェクトの次のステージの 50 番目の正方形の後に始まりました。各プロジェクトのこれらの正方形は、XNUMX 以上の手順で長いニシキヘビの尾のように描くことができます。 悲しくて月に向かって吠えたいと思ったのですが、それは一般的には当てはまりませんでした。

一般的な制作タスク

生産プロセスのモデリングは非常に複雑で骨の折れる作業です。さまざまな部門や生産チェーンから大量のデータを収集、処理、分析する必要があります。 これについては、記事「」で詳しく読むことができます。IT企業における生産プロセスのモデリング'。

生産プロセスのモデル化を開始したとき、当社の製品開発に携わるすべての従業員とプロジェクト マネージャーに次のことを伝えるという特定の目標がありました。

• コード行のコミットから始まり、製品とそのコンポーネントがインストーラーやアップデートの形でどのように顧客に届くのか、
• 製品の生産の各段階にどのようなリソースが提供されるか、
• 各段階でどのようなサービスが関与するか、
• 各段階の責任範囲がどのように区切られているか、
• 各段階の入り口と出口にはどのような契約が存在するのか。

画像をクリックするとフルサイズで開きます。

社内での私たちの仕事はいくつかの機能分野に分かれています。 インフラストラクチャの方向性は、部門のすべての「鉄」リソースの運用の最適化、および仮想マシンとその環境の展開の自動化に取り組んでいます。 監視の方向により、24 時間 7 日のサービス パフォーマンス制御が提供されます。 開発者向けのサービスとしてモニタリングも提供しています。 ワークフローの方向性により、開発およびテストのプロセスを管理し、コードの状態を分析し、プロジェクトの分析を行うためのツールがチームに提供されます。 そして最後に、Webdev の指示により、GUS および FLUS 更新サーバーでのリリースの公開と、LicenseLab サービスを使用した製品のライセンス供与が提供されます。 実稼働パイプラインをサポートするために、私たちは開発者向けにさまざまなサポート サービスをセットアップし、維持しています (そのうちのいくつかについては、古いミートアップで話を聞くことができます: オプ!DevOps! 2016年 и オプ!DevOps! 2017年）。 また、次のような内部自動化ツールも開発しています。 オープンソース ソリューション.

過去 XNUMX 年間、私たちの仕事には同じような種類の日常的な業務がたくさん蓄積されており、他の部門からの開発者は主にいわゆる「人材」から来ています。 典型的なタスク、そのソリューションは完全または部分的に自動化されており、実行者に困難を引き起こすことはなく、大量の作業を必要としません。 私たちは主要分野と協力してそのようなタスクを分析し、個々の作業カテゴリを特定することができました。 生産工程、ステージは分割できないステップに分割されており、いくつかのステージが合計されます。 生産プロセスチェーン.

技術チェーンの最も単純な例は、社内での各製品の組み立て、導入、テストの段階です。 たとえば、ビルド段階は、GitLab からのソースのダウンロード、依存関係とサードパーティのライブラリの準備、単体テストと静的コード分析、GitLab CI でのビルド スクリプトの実行、GitLab CI でのリポジトリ内のアーティファクトの公開など、多くの個別の一般的な手順で構成されます。社内の ChangelogBu​​ilder ツールを使用したアーティファクトとリリース ノートの生成。

典型的な DevOps タスクについては、Habré に関する他の記事で読むことができます。個人的な経験: 当社の継続的インテグレーション システムがどのようなものであるか"そして"開発プロセスの自動化: Positive Technologies で DevOps アイデアをどのように実装したか'。

多くの典型的な生産チェーンが形成されます 製造プロセス。 プロセスを記述する標準的なアプローチは、機能的な IDEF0 モデルを使用することです。

製造 CI プロセスのモデル化の例

私たちは、継続的統合システムの標準プロジェクトの開発に特に注意を払いました。 これにより、プロジェクトの統合が可能になり、いわゆる プロモーション付きのリリース ビルド スキーム.

仕組みは次のとおりです。 すべてのプロジェクトは典型的なものに見えます。これらのプロジェクトには、Artifactory のスナップショット リポジトリに分類されるアセンブリの構成が含まれており、その後、テスト ベンチでデプロイおよびテストされてから、リリース リポジトリにプロモートされます。 Artifactory サービスは、チームと他のサービス間のすべてのビルド アーティファクトの単一の配布ポイントです。

リリース スキームを大幅に簡素化して一般化すると、次の手順が含まれます。

• クロスプラットフォームの製品アセンブリ、
• テストベンチへの展開、
• 機能テストやその他のテストの実行、
• Artifactory でリポジトリをリリースするためにテスト済みのビルドを促進する、
• アップデートサーバー上でのリリースビルドの公開、
• アセンブリの配信と生産への更新、
• 製品のインストールとアップデートを開始します。

たとえば、機能的な IDEF0 モデルの形式での、この典型的なリリース スキームの技術モデル (以下、単にモデル) を考えてみましょう。 これは、CI プロセスの主要な段階を反映しています。 IDEF0 モデルは、いわゆる ICOM表記 (入力-制御-出力-メカニズム)。どのようなルールと要件に基づいて各段階で使用されるリソース、作業が実行されるか、出力は何か、および特定の段階をどのようなメカニズム、サービス、または人々が実装するかを記述します。

画像をクリックするとフルサイズで開きます。

一般に、機能モデルでプロセスを分解して詳細に説明する方が簡単です。 しかし、要素の数が増えると、その中の何かを理解することがますます難しくなります。 しかし、実際の開発には、監視、製品の認証、作業プロセスの自動化などの補助的な段階もあります。 この説明を放棄したのは、スケーリングの問題のためです。

希望の誕生

ある本の中で、技術プロセスを説明した古いソ連の地図に出会った（ちなみに、この地図は今でも多くの国営企業や大学で使われている）。 待って、待ってください。ワークフローもあります!. ステージ、結果、メトリクス、要件、指標などがあります... 製品パイプラインにもフローシートを適用してみてはいかがでしょうか? 「これだ！」という感覚がありました。 適切な糸を見つけました。しっかりと糸を引く時が来ました。

単純な表に、製品を列ごとに記録し、技術段階と製品パイプラインのステップを行ごとに記録することにしました。 マイルストーンとは、製品の構築ステップなどの大きなものです。 また、ソース コードをビルド サーバーにダウンロードするステップやコードをコンパイルするステップなど、ステップはより小さく、より詳細なものになります。

マップの行と列の交点に、特定の段階と製品のステータスを記載します。 ステータスについては、一連の状態が定義されています。

1. 情報なし - または不適切です。 製品の段階に対する需要を分析する必要があります。 分析はすでに実行されていますが、その段階は現時点では必要ないか、経済的に正当化されません。
2. 延期した - または現時点では関係ありません。 パイプラインの段階が必要だが、今年実施する力はない。
3. 予定。 このステージは今年中に実装される予定だ。
4. 実装済み。 パイプラインのステージは必要なボリュームで実装されます。

表への記入はプロジェクトごとに始まりました。 まず、一つのプロジェクトの段階とステップを分類し、その状況を記録します。 次に、次のプロジェクトを開始し、そのプロジェクトのステータスを修正し、以前のプロジェクトに欠けていたステージとステップを追加しました。 その結果、本番パイプライン全体のステージとステップ、および特定のプロジェクトにおけるそれらのステータスを取得しました。 それは、製品パイプラインのコンピテンシー マトリックスに似たものであることが判明しました。 このようなマトリックスを技術マップと呼びます。

技術マップの助けを借りて、私たちは、その年の作業計画と、一緒に達成したい目標（今年プロジェクトにどの段階を追加し、どの段階を後に残すか）を計量学的に合理的にチームと調整します。 また、仕事をしていく中で、たった一つの製品に対して完成した段階で改善が行われることもあります。 次に、マップを拡大してこの改善を段階または新しいステップとして導入し、各製品を分析して改善を再現する実現可能性を見つけます。

彼らは私たちにこう反論するかもしれません。「もちろん、これはすべて良いことですが、時間が経つにつれて、ステップや段階の数が法外に大きくなるだけです。 どうすればいいですか？

社内の全員が同じように理解できるように、各段階とステップごとに標準的かつ十分に完全な要件の説明を導入しています。 時間の経過とともに、改善が導入されると、ステップが別のステージまたはステップに吸収され、その後それらが「崩壊」することがあります。 同時に、すべての要件と技術的なニュアンスが一般化段階またはステップの要件に適合します。

ソリューションを複製する効果を評価するにはどうすればよいですか? 私たちは非常に単純なアプローチを使用します。つまり、新しいステージの実装にかかる初期資本コストを年間の一般的な製品コストに帰し、複製するときにすべてで割ります。

開発の一部はすでにマップ上にマイルストーンとステップとして示されています。 一般的な段階に自動化を導入することで、製品のコスト削減に影響を与えることができます。 その後、定性的特性、定量的指標、チームが得た利益 (工数または機械時間の節約) の変化を考慮します。

生産工程の技術マップ

すべての段階とステップを取得し、タグでエンコードして XNUMX つのチェーンに展開すると、非常に長くて理解できないものになります (記事の冒頭で説明したまさに「Python の尾」です)。 :

[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]

これらは、製品の構築 [Build]、テスト サーバーへの展開 [Deploy]、テスト [Test]、テストの結果に基づいたリリース リポジトリへのビルドのプロモート [Promote]、ライセンスの生成と公開 [License]、公開 [ GUS アップデート サーバーでの公開] と FLUS アップデート サーバーへの配信、製品構成管理 [インストール] を使用した顧客のインフラストラクチャへの製品コンポーネントのインストールと更新、およびインストールされた製品からのテレメトリ [テレメトリ] の収集。

これらに加えて、インフラストラクチャ状態の監視 [InfMonitoring]、ソース コードのバージョン管理 [SourceCodeControl]、ビルド環境の準備 [Prepare]、プロジェクト管理 [Workflow]、チームへのコミュニケーション ツールの提供 [Communication]、製品認証 [認証] と CI プロセスの自給自足性の確保 [CISelfSufficiency] (たとえば、インターネットからのアセンブリの独立性)。 私たちのプロセスにおける数十のステップは、非常に特殊なため、考慮すらされません。

生産プロセス全体を形で示すと、非常に理解しやすくなり、見やすくなります。 技術地図; これは、モデルの個々の生産段階と分解されたステップが行と列に書かれた表であり、各段階またはステップで行われる内容の説明です。 主に、各段階を提供するリソースと責任範囲の境界に重点が置かれます。

私たちにとってマップは一種の分類子です。 これは、製品製造の大きな技術的な部分を反映しています。 そのおかげで、自動化チームは開発者と対話し、自動化段階の実装を共同で計画することが容易になり、また、これに必要な人件費とリソース (人間とハードウェア) を理解することが容易になりました。

弊社内では、jinja テンプレートから通常の HTML ファイルとしてマップが自動生成され、GitLab Pages サーバーにアップロードされます。 完全に生成されたマップの例を含むスクリーンショットを表示できます。 リンク.

画像をクリックするとフルサイズで開きます。

つまり、技術マップは生産プロセスの一般化された図であり、典型的な機能を備えた明確に分類されたブロックを反映しています。

ロードマップの構成

マップはいくつかの部分で構成されています。

1. タイトル領域 - ここにはマップの一般的な説明があり、基本概念が紹介され、主要なリソースと制作プロセスの結果が定義されます。
2. ダッシュボード - ここでは、個々の製品のデータの表示を制御できます。すべての製品に対して一般的に実装された段階と手順の概要が提供されます。
3. 技術マップ - 技術プロセスを表形式で説明したもの。 地図にある：
   • すべての段階、ステップ、およびそのコードが示されています。
   • ステージの短く完全な説明が記載されています。
   • 各段階で使用される入力リソースとサービスが示されます。
   • 各段階と個別のステップの結果が示されます。
   • 各段階とステップの責任範囲が示されています。
   • HDD (SSD)、RAM、vCPU などの技術リソースと、この段階での作業をサポートするために必要な工数が、現時点 (事実) と将来の計画 (計画) の両方で決定されています。
   • 各製品について、その技術段階またはステップが実装されているか、実装が計画されているか、無関係であるか実装されていないのかが示されます。

技術マップに基づく意思決定

マップを調べた後、社内の従業員の役割 (開発マネージャー、製品マネージャー、開発者、またはテスター) に応じて、いくつかのアクションを実行できます。

• 実際の製品またはプロジェクトにどの段階が欠けているかを理解し、それらの実装の必要性を評価します。
• 複数の部門が異なる段階で作業する場合は、その部門間の責任範囲を区切ります。
• ステージの入り口と出口で契約に同意する。
• 作業段階を開発プロセス全体に統合します。
• 各段階を提供するリソースの必要性をより正確に評価します。

上記のすべてを要約すると、

ルーティングは多用途で拡張可能で、保守が簡単です。 この形式でプロセスの記述を開発および維持することは、厳密な学術的な IDEF0 モデルよりもはるかに簡単です。 さらに、表形式の説明は、機能モデルよりもシンプルで親しみやすく、構造的に優れています。

ステップの技術的な実装のために、CI システム、サービス、インフラストラクチャ間のレイヤー ツールである特別な内部ツール CrossBuilder を使用しています。 開発者は自転車を切断する必要はありません。CI システムでは、CrossBuilder ツールのスクリプト (いわゆるタスク) の XNUMX つを実行するだけで十分です。これは、インフラストラクチャの機能を考慮して正しく実行されます。 。

結果

この記事はかなり長くなってしまいましたが、複雑なプロセスのモデリングを説明する場合、これは避けられません。 最後に、私たちの主要なアイデアを簡単に修正したいと思います。

• 当社で DevOps のアイデアを実装する目標は、定量的な観点 (工数またはマシン時間、vCPU、RAM、ディスク) で自社製品の生産とメンテナンスのコストを一貫して削減することです。
• 開発全体のコストを削減する方法は、典型的な連続タスク、つまり技術プロセスの段階とステップを実行するコストを最小限に抑えることです。
• 典型的なタスクとは、ソリューションが完全または部分的に自動化されており、実行者に困難を引き起こさず、多額の人件費を必要としないタスクです。
• 生産プロセスは複数の段階で構成されており、各段階は分割できないステップに分割されており、これらのステップはさまざまな規模と範囲の典型的なタスクです。
• 私たちは、異なる典型的なタスクから、機能的な IDEF0 モデルまたはより単純な技術マップで説明できる、複雑な技術チェーンと生産プロセスのマルチレベル モデルに到達しました。
• 技術マップは、生産プロセスの段階とステップを表形式で表現したものです。 最も重要なことは、マップを使用すると、プロセス全体を大きな部分で詳細に確認できることです。
• 技術マップに基づいて、特定の製品にステージを導入する必要性を評価し、責任範囲を明確にし、ステージのインプットとアウトプットで契約に合意し、リソースの必要性をより正確に評価することができます。

次の記事では、マップ上に特定の技術段階を実装するためにどのような技術ツールが使用されるかについて詳しく説明します。

記事の著者:

• アレクサンダー・パズドニコフ — Positive Technologies のオートメーション (DevOps) 責任者
• ティムール・ギルムリン - 副官Positive Technologies の自動化部門 (DevOps) 部門責任者

出所： habr.com