プロホスト > ブログ > 行政 > 継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化

今、DevOps の話題が誇倧広告になっおいたす。 継続的むンテグレヌションずデリバリヌパむプラむン CI / CD 誰もがそれを実践しおいたす。 しかし、ほずんどの䌁業は、CI/CD パむプラむンのさたざたな段階で情報システムの信頌性を確保するこずに垞に十分な泚意を払っおいるわけではありたせん。 この蚘事では、゜フトりェアの品質チェックを自動化し、その「自己修埩」のために考えられるシナリオを実装した私の経隓に぀いお話したいず思いたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化゜ヌス

私は䌁業のITサヌビス管理郚門で゚ンゞニアずしお働いおいたす。 「LANIT統合」。 私の䞻な専門分野は、さたざたなアプリケヌションのパフォヌマンスず可甚性を監芖するシステムの実装です。 私は、さたざたな垂堎セグメントの IT 顧客ず、IT サヌビスの品質の監芖に関する珟圚の問題に぀いお頻繁に連絡を取りたす。 䞻な目暙は、リリヌス サむクル タむムを最小限に抑え、リリヌスの頻床を増やすこずです。 もちろん、これはすべお良いこずです。より倚くのリリヌス - より倚くの新機胜 - より満足したナヌザヌ - より倚くの利益。 しかし珟実には、物事は必ずしもうたくいくずは限りたせん。 導入率が非垞に高いため、リリヌスの品質に぀いおの疑問がすぐに生じたす。 完党に自動化されたパむプラむンがあっおも、最倧の課題の XNUMX ぀は、アプリケヌションの皌働時間やナヌザヌ ゚クスペリ゚ンスに圱響を䞎えるこずなく、サヌビスをテストから実皌働環境に移行するこずです。

顧客ずの数倚くの䌚話の結果に基づいお、リリヌスの品質管理、アプリケヌションの信頌性の問題、および CI のさたざたな段階での「自己修埩」 (安定バヌゞョンぞのロヌルバックなど) の可胜性が重芁であるず蚀えたす。 /CD パむプラむンは、最も刺激的で関連性のあるトピックの XNUMX ぀です。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化
最近、私自身も顧客偎、぀たりオンラむン バンキング アプリケヌション ゜フトりェアのサポヌト サヌビスで働いおいたした。 私たちのアプリケヌションのアヌキテクチャでは、倚数の自己䜜成マむクロサヌビスを䜿甚したした。 最も悲しいこずは、すべおの開発者がハむペヌスな開発に察応できたわけではなく、䞀郚のマむクロサヌビスの品質が䜎䞋し、マむクロサヌビスずその䜜成者に面癜いあだ名が付けられたこずです。 これらの補品がどのような材料で䜜られおいるかに぀いおの話がありたした。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化

「問題の定匏化」

リリヌスの頻床が高く、マむクロサヌビスの数が倚いため、テスト段階でも運甚段階でも、アプリケヌション党䜓の動䜜を理解するこずが困難になりたす。 倉化は絶えず発生するため、優れた監芖ツヌルがなければ倉化を制埡するこずは非垞に困難です。 テスト段階ではすべおのチェックが成功しおいおも、開発者は倜のリリヌス埌、朝になるず火薬庫の䞊に座っお䜕も壊れないのを埅぀こずがよくありたす。

もうXNUMX点ありたす。 テスト段階では、アプリケヌションの䞻な機胜が実装されおいるか、゚ラヌがないかなど、゜フトりェアの機胜がチェックされたす。 定性的なパフォヌマンス評䟡が欠萜しおいるか、アプリケヌションず統合局のすべおの偎面が考慮されおいたせん。 䞀郚のメトリクスはたったくチェックされない堎合がありたす。 その結果、実皌働環境で障害が発生した堎合、テクニカル サポヌト郚門は、実際のナヌザヌが苊情を申し立お始めたずきにのみそのこずに気付きたす。 䜎品質の゜フトりェアが゚ンドナヌザヌに䞎える圱響を最小限に抑えたいず考えおいたす。

解決策の XNUMX ぀は、CI/CD パむプラむンのさたざたな段階で゜フトりェアの品質をチェックするプロセスを実装し、緊急時にシステムを埩元するためのさたざたなシナリオを远加するこずです。 DevOps があるこずも忘れたせん。 䌁業は、新補品をできるだけ早く受け取るこずを期埅しおいたす。 したがっお、すべおのチェックずスクリプトを自動化する必芁がありたす。

このタスクは XNUMX ぀のコンポヌネントに分かれおいたす。

  • テスト段階でのアセンブリの品質管理 (䜎品質アセンブリを怜出するプロセスを自動化するため)。
  • 実皌働環境での゜フトりェア品質管理 (問題を自動的に怜出するメカニズムず、その自己修埩のための考えられるシナリオ)。

メトリクスを監芖および収集するためのツヌル

蚭定された目暙を実珟するには、問題を怜出し、CI/CD パむプラむンのさたざたな段階で自動化システムに問題を転送できる監芖システムが必芁です。 たた、このシステムが開発、テスト、運甚などのさたざたなチヌムにずっお有甚な指暙を提䟛できれば、それはプラスになりたす。 それがビゞネスにも䜿えたら最高です。

メトリクスを収集するには、䞀連のさたざたなシステム (Prometheus、ELK Stack、Zabbix など) を䜿甚できたすが、私の意芋では、APM クラスの゜リュヌションがこれらのタスクに最適です (アプリケヌションパフォヌマンスの監芖、生掻を倧幅に簡玠化できたす。

サポヌト サヌビスでの仕事の䞀環ずしお、Dynatrace の APM クラス ゜リュヌションを䜿甚しお同様のプロゞェクトを開始したした。 珟圚、むンテグレヌタヌで働いおいる私は、監芖システム垂堎に぀いおよく知っおいたす。 私の䞻芳的な意芋: Dynatrace はそのような問題を解決するのに最適です。
Dynatrace は、コヌド実行レベルに至るたでの詳现なレベルで、あらゆるナヌザヌ操䜜を氎平方向に衚瀺したす。 Web およびモバむル アプリケヌションのフロント゚ンド レベル、バック゚ンド アプリケヌション サヌバヌ、統合バスからデヌタベヌスぞの特定の呌び出しに至るたで、さたざたな情報サヌビス間の察話のチェヌン党䜓を远跡できたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化゜ヌス。 システムコンポヌネント間のすべおの䟝存関係の自動構築

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化゜ヌス。 サヌビス運甚経路の自動怜出・構築

たた、さたざたな自動化ツヌルず統合する必芁があるこずも芚えおいたす。 この゜リュヌションには、さたざたなメトリクスやむベントを送受信できる䟿利な API が含たれおいたす。

次に、Dynatrace システムを䜿甚しおこれらの問題を解決する方法を詳しく芋おみたしょう。

タスク 1. テスト段階でのアセンブリの品質管理の自動化

最初の課題は、アプリケヌション配信パむプラむンでできるだけ早く問題を発芋するこずです。 「良奜な」コヌドビルドのみが実皌働環境に到達する必芁がありたす。 これを行うには、テスト段階のパむプラむンに、サヌビスの品質をチェックするための远加のモニタヌを含める必芁がありたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化

これを実装し、このプロセスを自動化する方法を段階的に芋おみたしょう。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化゜ヌス

次の図は、自動化された゜フトりェア品質テスト手順のフロヌを瀺しおいたす。

  1. 監芖システムの導入゚ヌゞェントのむンストヌル。
  2. ゜フトりェアの品質を評䟡するためのむベント (メトリクスずしきい倀) を特定し、それらを監芖システムに転送したす。
  3. 負荷テストずパフォヌマンステストの生成。
  4. 監芖システムでパフォヌマンスず可甚性のデヌタを収集する。
  5. ゜フトりェア品質評䟡むベントに基づくテスト デヌタを監芖システムから CI/CD システムに転送したす。 アセンブリの自動分析。

ステップ 1. 監芖システムの導入

たず、テスト環境に゚ヌゞェントをむンストヌルする必芁がありたす。 同時に、Dynatrace ゜リュヌションには優れた機胜がありたす。OS むンスタンス (Windows、Linux、AIX) にむンストヌルされるナニバヌサル ゚ヌゞェント OneAgent を䜿甚し、サヌビスを自動的に怜出し、それらの監芖デヌタの収集を開始したす。 プロセスごずに個別の゚ヌゞェントを構成する必芁はありたせん。 クラりド プラットフォヌムずコンテナ プラットフォヌムでも状況は同様になりたす。 同時に、゚ヌゞェントのむンストヌルプロセスを自動化するこずもできたす。 Dynatrace は、「コヌドずしおのむンフラストラクチャ」の抂念に完党に適合したす (コヌドたたは IaC ずしおのむンフラストラクチャ): すべおの䞀般的なプラットフォヌム甚の既補のスクリプトず手順が甚意されおいたす。 ゚ヌゞェントをサヌビスの構成に埋め蟌み、それをデプロむするず、すでに動䜜しおいる゚ヌゞェントを含む新しいサヌビスがすぐに提䟛されたす。

ステップ 2: ゜フトりェア品質むベントを定矩する

次に、サヌビスず業務運営のリストを決定する必芁がありたす。 サヌビスにずっおビゞネス䞊重芁なナヌザヌ操䜜を正確に考慮するこずが重芁です。 ここでは、ビゞネス アナリストやシステム アナリストに盞談するこずをお勧めしたす。

次に、各レベルのレビュヌにどの指暙を含めるかを決定する必芁がありたす。 たずえば、実行時間 (平均、䞭倮倀、パヌセンタむルなどに分割)、゚ラヌ (論理、サヌビス、むンフラストラクチャなど)、およびさたざたなむンフラストラクチャ メトリクス (メモリ ヒヌプ、ガベヌゞ コレクタヌ、スレッド数など) がこれに該圓したす。

DevOps チヌムによる自動化ず䜿いやすさを目的ずしお、「Monitoring as Code」ずいう抂念が登堎したした。 これが意味するのは、開発者/テスタヌは゜フトりェア品質保蚌メトリクスを定矩する単玔な JSON ファむルを䜜成できるずいうこずです。

このような JSON ファむルの䟋を芋おみたしょう。 Dynatrace API のオブゞェクトはキヌず倀のペアずしお䜿甚されたす (API の説明はここにありたす) ダむナトレヌス API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

ファむルは時系列定矩の配列です。

  • timeseriesId – チェックされるメトリック (応答時間、゚ラヌ数、䜿甚メモリなど)。  
  • aggregation - メトリクス集蚈のレベル。この堎合は avg ですが、必芁な倀 (avg、min、max、sum、count、percentile) を䜿甚できたす。
  • タグ – 監芖システム内のオブゞェクト タグ、たたは特定のオブゞェクト識別子を指定できたす。
  • 重倧および譊告 – これらの指暙はメトリクスのしきい倀を芏制したす。テスト倀が重倧なしきい倀を超えるず、ビルドは成功しなかったずマヌクされたす。

次の図は、このようなしきい倀の䜿甚䟋を瀺しおいたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化゜ヌス

ステップ 3: 負荷の生成

サヌビスの品質レベルを決定したら、テスト負荷を生成する必芁がありたす。 Jmeter、Selenium、Neotys、Gatling など、䜿い慣れたテスト ツヌルを䜿甚できたす。

Dynatrace の監芖システムを䜿甚するず、テストからさたざたなメタデヌタを取埗し、どのテストがどのリリヌス サむクルおよびどのサヌビスに属するかを認識できたす。 HTTP テストリク゚ストに远加のヘッダヌを远加するこずをお勧めしたす。

次の図は、远加ヘッダヌ X-Dynatrace-Test を䜿甚しお、このテストがカヌトに商品を远加する操䜜のテストに関連しおいるこずを瀺す䟋を瀺しおいたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化゜ヌス

各負荷テストを実行するずきは、CI/CD サヌバヌからむベント API を䜿甚しお远加のコンテキスト情報を Dynatrace に送信したす。 このようにしお、システムは異なるテストを区別できたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化゜ヌス。 負荷テストの開始に関する監芖システム内のむベント

ステップ4-5。 パフォヌマンス デヌタを収集し、CI/CD システムにデヌタを転送したす。

生成されたテストずずもに、サヌビス品質指暙のチェックに関するデヌタを収集する必芁性に関するむベントが監芖システムに送信されたす。 たた、䞻芁なメトリクスを定矩する JSON ファむルも指定したす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化監芖システムに送信するためにCI/CDサヌバヌ䞊で生成された゜フトりェアの品質をチェックする必芁があるこずに関するむベント

この䟋では、品質チェック むベントは次のように呌ばれたす。 perfSigDynatraceレポヌト (パフォヌマンス_眲名) - これで準備完了です プラグむン T-Systems Multimedia Solutions のスタッフによっお開発された Jenkins ずの統合甚です。 各テスト起動むベントには、サヌビス、ビルド番号、テスト時間に関する情報が含たれおいたす。 プラグむンはビルド時にパフォヌマンス倀を収集しお評䟡し、結果を以前のビルドおよび非機胜芁件ず比范したす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化ビルド品質チェックの開始に関する監芖システム内のむベント。 ゜ヌス

テストが完了するず、゜フトりェア品質を評䟡するためのすべおの指暙が継続的統合システム (Jenkins など) に転送され、結果に関するレポヌトが生成されたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化CI/CD サヌバヌ䞊のアセンブリに関する統蚈の結果。 ゜ヌス

個々のビルドに぀いお、テスト党䜓を通しお蚭定した各メトリクスの統蚈が衚瀺されたす。 たた、特定のしきい倀 (譊告および重倧なしきい倀) に違反があったかどうかも確認したす。 集蚈メトリクスに基づいお、ビルド党䜓が安定、䞍安定、たたは倱敗ずしおマヌクされたす。 たた、䟿宜䞊、珟圚のビルドず以前のビルドを比范するむンゞケヌタヌをレポヌトに远加できたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化CI/CD サヌバヌ䞊のアセンブリに関する詳现な統蚈を衚瀺したす。 ゜ヌス

XNUMX ぀のアセンブリの詳现な比范

必芁に応じお、Dynatrace むンタヌフェむスに移動するず、各ビルドの統蚈をより詳现に衚瀺し、盞互に比范できたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化Dynatrace でのビルド統蚈の比范。 ゜ヌス
 
所芋

その結果、継続的統合パむプラむンで自動化された「サヌビスずしおの監芖」サヌビスが埗られたす。 開発者たたはテスタヌは、JSON ファむルでメトリクスのリストを定矩するだけで枈み、その他の䜜業はすべお自動的に行われたす。 私たちはリリヌスの透明性のある品質管理、぀たりパフォヌマンス、リ゜ヌス消費、たたはアヌキテクチャのリグレッションに関するすべおの通知を受け取りたす。

タスク 2. 実皌働環境での゜フトりェア品質管理の自動化

これで、Pipeline のテスト段階での監芖プロセスをどのように自動化するかずいう問題が解決されたした。 このようにしお、実皌働環境に到達する䜎品質アセンブリの割合を最小限に抑えたす。

しかし、悪い゜フトりェアが販売されおしたったり、䜕かが壊れおしたったらどうすればよいでしょうか。 ナヌトピアの堎合、問題を自動的に怜出するメカニズムず、可胜であれば少なくずも倜間にシステム自䜓の機胜を回埩するメカニズムが必芁でした。

これを行うには、前のセクションず同様に、運甚環境での自動゜フトりェア品質チェックを提䟛し、システムの自己修埩のシナリオに基づいお行う必芁がありたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化
コヌドずしおの自動修正

ほずんどの䌁業は、さたざたな皮類の䞀般的な問題に関する蓄積された知識ベヌスず、それらを修正するためのアクションのリスト (プロセスの再起動、リ゜ヌスのクリヌンアップ、バヌゞョンのロヌルバック、無効な構成倉曎の埩元、コンポヌネントの数の増枛など) をすでに持っおいたす。クラスタヌ、青たたは緑のアりトラむンの切り替えなど。

これらのナヌスケヌスは、私が話を聞いおいる倚くのチヌムで䜕幎も前から知られおいたしたが、自動化に぀いお考えたり、自動化に投資したりした人はほずんどいたせんでした。

考えおみるず、アプリケヌションのパフォヌマンスを自己修埩するためのプロセスを実装するのにそれほど耇雑なこずはありたせん。管理者の既知の䜜業シナリオをコヌド スクリプトの圢匏で提瀺する必芁がありたす (「コヌドずしお自動修正」の抂念)。 、具䜓的なケヌスごずに事前に曞いたものです。 自動修埩スクリプトは、問題の根本原因を排陀するこずを目的ずしおいる必芁がありたす。 むンシデントに察応するための正しい行動はあなた自身が決定したす。

監芖システムからのメトリクスは、スクリプトを起動するトリガヌずしお機胜したす。重芁なのは、生産的な環境では誀怜知が発生するこずを望たないため、これらのメトリクスがすべおが䞍良であるこずを正確に刀断するこずです。

Prometheus、ELK Stack、Zabbix など、任意のシステムたたはシステムのセットを䜿甚できたす。 ただし、APM ゜リュヌションに基づいおいく぀かの䟋を瀺したす (Dynatrace が再び䟋になりたす)。これは、䜜業を容易にするのにも圹立ちたす。

たず、アプリケヌションの操䜜に関しおは、パフォヌマンスに関連するすべおのこずが挙げられたす。 この゜リュヌションは、トリガヌずしお䜿甚できるさたざたなレベルの数癟のメトリクスを提䟛したす。

  • ナヌザヌレベルブラりザ、モバむルアプリケヌション、IoTデバむス、ナヌザヌの行動、コンバヌゞョンなど。
  • サヌビスず操䜜のレベル (パフォヌマンス、可甚性、゚ラヌなど)。
  • アプリケヌション むンフラストラクチャ レベル (ホスト OS メトリクス、JMX、MQ、Web サヌバヌなど)。
  • プラットフォヌム レベル (仮想化、クラりド、コンテナなど)。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化Dynatrace のレベルの監芖。 ゜ヌス

次に、先ほども述べたように、Dynatrace にはオヌプン API があり、さたざたなサヌドパヌティ システムずの統合が非垞に簡単です。 たずえば、制埡パラメヌタを超えたずきにオヌトメヌション システムに通知を送信したす。

以䞋は、Ansible ず察話する䟋です。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化゜ヌス

以䞋に、どのような自動化が可胜なのか、いく぀かの䟋を瀺したす。 これはケヌスの䞀郚にすぎたせん。環境内のそれらのリストは、想像力ず監芖ツヌルの機胜によっおのみ制限できたす。

1. 䞍正なデプロむ - バヌゞョンのロヌルバック

テスト環境ですべおを非垞にうたくテストしたずしおも、新しいリリヌスによっお運甚環境でアプリケヌションが匷制終了される可胜性は䟝然ずしおありたす。 同じ人的芁因はキャンセルされおいたせん。

次の図では、サヌビス䞊の操䜜の実行時間が急激に増加しおいるこずがわかりたす。 このゞャンプの開始は、アプリケヌションぞのデプロむメントの時間ず䞀臎したす。 これらすべおの情報をむベントずしお自動化システムに送信したす。 蚭定した時間が経過しおもサヌビスのパフォヌマンスが通垞に戻らない堎合は、バヌゞョンを叀いバヌゞョンにロヌルバックするスクリプトが自動的に呌び出されたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化導入埌の運甚パフォヌマンスの䜎䞋。 ゜ヌス

2. リ゜ヌス負荷 100% - ルヌティングにノヌドを远加したす

次の䟋では、監芖システムは、コンポヌネントの 100 ぀で XNUMX% の CPU 負荷が発生しおいるず刀断したす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化CPU負荷100%
 
このむベントにはいく぀かの異なるシナリオが考えられたす。 たずえば、監芖システムは、リ゜ヌスの䞍足がサヌビスの負荷の増加に関連しおいるかどうかをさらにチェックしたす。 存圚する堎合は、ルヌティングにノヌドを自動的に远加するスクリプトが実行され、それによっおシステム党䜓の機胜が埩元されたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化むンシデント埌のスケヌリング

3. ハヌドドラむブの空き容量䞍足 - ディスクのクリヌニング

すでにこれらのプロセスを自動化しおいる人も倚いず思いたす。 APM を䜿甚するず、ディスク サブシステムの空き領域を監芖するこずもできたす。 スペヌスがない堎合、たたはディスクの動䜜が遅い堎合は、スクリプトを呌び出しおディスクをクリヌンアップするか、スペヌスを远加したす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化
継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化ディスク負荷100%
 
4. ナヌザヌアクティビティが䜎い、たたはコンバヌゞョンが䜎い - 青ず緑のブランチ間の切り替え

実皌働環境でアプリケヌションに XNUMX ぀のルヌプ (Blue-Green デプロむ) を䜿甚しおいるお客様をよく芋かけたす。 これにより、新しいリリヌスを配信するずきにブランチ間をすばやく切り替えるこずができたす。 倚くの堎合、展開埌に、すぐには気付かないような劇的な倉化が発生するこずがありたす。 この堎合、パフォヌマンスず可甚性の䜎䞋は芳察されない可胜性がありたす。 このような倉化に迅速に察応するには、ナヌザヌの行動セッション数ずナヌザヌアクション、コンバヌゞョン、盎垰率を反映するさたざたな指暙を䜿甚する方がよいでしょう。 次の図は、倉換率が䜎䞋したずきに゜フトりェア ブランチの切り替えが発生する䟋を瀺しおいたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化゜フトりェア ブランチ間を切り替えるず、コンバヌゞョン率が䜎䞋したす。 ゜ヌス

問題を自動怜出するメカニズム

最埌に、私が Dynatrace が最も奜きな理由をもう XNUMX ぀挙げおおきたす。

テスト環境でのアセンブリの品質チェックの自動化に関する私の話の䞀郚では、すべおのしきい倀を手動で決定したした。 これはテスト環境では正垞であり、負荷に応じお各テストの前にテスタヌ自身が指暙を決定したす。 実皌働環境では、さたざたなベヌスラむンメカニズムを考慮しお、問題が自動的に怜出されるこずが望たしいです。

Dynatrace には興味深い組み蟌みの人工知胜ツヌルがあり、異垞なメトリクス (ベヌスラむン化) を特定し、すべおのコンポヌネント間の盞互䜜甚のマップを構築し、むベントを盞互に比范および盞関させるためのメカニズムに基づいお、サヌビスの動䜜の異垞を刀断し、詳现な情報を提䟛したす。それぞれの問題ず根本原因に関する情報。

Dynatrace は、コンポヌネント間の䟝存関係を自動的に分析するこずで、問題のあるサヌビスが根本原因であるかどうかだけでなく、他のサヌビスぞの䟝存関係も刀断したす。 以䞋の䟋では、Dynatrace はトランザクション実行䞭の各サヌビスの健党性を自動的に監芖および評䟡し、根本原因ずしお Golang サヌビスを特定したす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化障害の根本原因を特定する䟋。 ゜ヌス

次の図は、むンシデントの開始からアプリケヌションの問題を監芖するプロセスを瀺しおいたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化すべおのコンポヌネントずコンポヌネント䞊のむベントを衚瀺する、新たな問題の芖芚化

監芖システムは、発生した問題に関連する出来事の完党な幎衚を収集したした。 タむムラむンの䞋のりィンドりに、各コンポヌネントのすべおの䞻芁なむベントが衚瀺されたす。 これらのむベントに基づいお、コヌドスクリプトの圢匏で自動修正の手順を蚭定できたす。

さらに、監芖システムをサヌビスデスクたたはバグトラッカヌず統合するこずをお勧めしたす。 問題が発生するず、開発者はすぐに完党な情報を受け取り、本番環境のコヌド レベルで分析できたす。

たずめ

その結果、Pipeline に自動゜フトりェア品質チェックが組み蟌たれた CI/CD パむプラむンが完成したした。 私たちは、䜎品質のアセンブリの数を最小限に抑え、システム党䜓の信頌性を高め、それでもシステムに障害が発生する堎合は、それを埩元するためのメカニズムを起動したす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化
゜フトりェア品質監芖の自動化に努力を投資する䟡倀は間違いなくあり、必ずしも迅速なプロセスではありたせんが、時間の経過ずずもに成果が埗られたす。 実皌働環境で新しいむンシデントを解決したら、悪いビルドが実皌働環境に入るのを避けるために、テスト環境でのチェックのためにどのモニタヌを远加するかをすぐに怜蚎し、これらの問題を自動的に修正するスクリプトを䜜成するこずをお勧めしたす。

私の䟋があなたの取り組みに圹立぀こずを願っおいたす。 自己修埩システムの実装に䜿甚されるメトリクスの䟋も芋おみたいず思いたす。

継続的モニタリング – CI/CD パむプラむンでの゜フトりェア品質チェックの自動化゜ヌス

出所 habr.com

コメントを远加したす