--- title: ITOpsのカオスエンジニアリング description: Chaos Engineeringの記事を読んで、ストレスの多い条件下で最高のアプリケーションパフォーマンスを実現するための5つのステップのフレームワークを学びましょう。 image: https://blog.opsramp.com/hubfs/Blog_images/Chaos_Engineering_blog_cover.png --- [![OpsRamp](https://blog.opsramp.com/hubfs/HPE_OpsRamp_Logo_Gray_Blue_RGB-0423.svg "OpsRamp")](https://www.opsramp.com/) [ Schedule a Demo ](https://info.opsramp.com/request-demo?hsLang=ja) [![English](https://blog.opsramp.com/hs-fs/hubfs/en-us.png?width=32&height=32&name=en-us.png)](http://www.opsramp.com) [![English](https://blog.opsramp.com/hs-fs/hubfs/ja.png?width=32&height=32&name=ja.png)](https://blog.opsramp.com/ja//ja/chaos-engineering?hsLang=ja)   # [ITOpsのカオスエンジニアリング](https://blog.opsramp.com/ja/chaos-engineering) [**](http://twitter.com/share?url=https://blog.opsramp.com/ja/chaos-engineering) ** [**](https://www.linkedin.com/shareArticle?mini=true&url=https://blog.opsramp.com/ja/chaos-engineering&summary=blog.opsramp.com&source=OpsRamp) [**](mailto:?Subject=Check%20Out%20This%20OpsRamp%20Blog%20Post&Body=I%20came%20across%20this%20post%20on%20the%20OpsRamp%20Blog%20and%20thought%20you'd%20like%20it.%20Check%20it%20out:%20https://blog.opsramp.com/ja/chaos-engineering) 1 Min Read | 9月 25, 2021 [![ITOpsのカオスエンジニアリング](https://blog.opsramp.com/hubfs/Blog_images/Chaos_Engineering_blog_cover.png) ](https://blog.opsramp.com/ja/chaos-engineering) ![](https://blog.opsramp.com/hs-fs/hubfs/Blog_images/Michael_Fisher.png?width=120&name=Michael_Fisher.png) By [Michael Fisher](https://blog.opsramp.com/ja/author/michael-fisher#author) ![SUBSCRIBE](https://no-cache.hubspot.com/cta/default/308166/89850b51-b95b-4330-9c88-2bdac48746b6.png) 以下が最初に登場しました [DevOps.com](https://devops.com/chaos-engineering-for-itops/)。 カオスエンジニアリング（CE）は [生産における乱流条件に耐えるシステムの能力に対する信頼を構築するために、システムで実験する規律](https://principlesofchaos.org/)。このアプローチは、ソフトウェア開発および運用（DevOps）の実践において一般的になりつつあります。しかし、そのアプリケーションはどのようにITOpsに拡張されるのでしょうか。 CE for ITOpsは、テクノロジープラットフォームのストレステストを行うための同様のフレームワークを提供し、大きなプレッシャーの下での弱点とパフォーマンスの落とし穴を理解します。 CEは、バグテスト中に主にDevOpsで使用される傾向があります。つまり、ピークトラフィックなどのさまざまな条件下でソフトウェアを実行するための実験を設定し、その機能とパフォーマンスを監視します。これは、極端な負荷応答を理解できないと、カスケード障害が暴走したり、さらに悪いことに、実際の作業を行わずにエラー状態を処理する何千もの余分なノードがスピンアップしたりする可能性があるクラウドベースのシステムでますます必要になります。 IT運用管理（ITOM）に適用されるこれらの同じ原則は、極端に達したときの定常状態と無秩序な出力の両方を明確にすることにより、機能ベースラインに加えてインフラストラクチャ、ポリシー、およびプロセスの許容範囲を定義するのに役立ちます。 ## **ITのアプリケーション** DevOpsのCEの理論は、物理インフラストラクチャから仮想インフラストラクチャに移行するにつれてNetflixで早期に注目を集め、AWSにそれを実装したチームが崩壊して形成されました[グレムリン](https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gremlin.com%2Fcommunity%2Ftutorials%2Fchaos-engineering-the-history-principles-and-practice%2F&data=02%7C01%7C%7C617f24935b174a18889108d724eec805%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637018480277954630&sdata=DpbCHqeMf%2FDcyVNUMPmQ4i1FLH9Mpynium9Dsu%2B%2BCn8%3D&reserved=0)。ただし、ITOMは歴史的に開発から分離されてきたため、CEは通常ITOpsでは使用されません（通常、ITはシステムダイナミクスを監視し、問題が発生すると、エンジニアリング変更管理またはITSMが問題を修正するために導入されます）。 今日のクラウドアプリケーションのコンテナ化の成長に伴い、ITインフラストラクチャは従来の多層アーキテクチャというよりも開発環境のように見えます。しかし、クラウドの無限の規模は、障害も無限になり得ることを意味します。マイクロサービスは、システムに許容範囲の限界までストレスをかけ、パブリッククラッシュの前に欠点を修正することで、弾力性とスケーラビリティ、データフロー、および弾力性をテストすることで十分に機能します。 ## **1、2、3…カオス** ITOMにカオスエンジニアリングを実装すると、マイクロサービスの世界の弱点を特定するための体系的なアプローチが提供されます。モノリシック環境では、マイクロサービスの設計で失われる可能性のあるパフォーマンスとイベントのメトリックを可視化できます。その結果、未知のワークロードにスケーリングする場合、運用上の洞察の必要性がさらに重要になります。 Netflixの [カオスモンキー](https://netflix.github.io/chaosmonkey/) 極端な複雑さを管理するための一般的な開発ツールの能力のギャップに対処することを目的とした、独自のクラウドネイティブコミュニティからのCE原則から生まれました。この方法論はインフラストラクチャに拡張可能であり、プラットフォームの動作全体にガードレールを設定するのに役立ちます。 この考え方をチームのITOMに取り入れるために、従うべき5つの基本的な手順を次に示します。 ## **現在の定常状態を定義する** ベースライン分析の実行は、キャパシティプランニング、アップグレード戦略、およびその他の影響の大きい機能の標準的な概念です。データに圧倒されたり、問題が発生した場合にビジネスに干渉したりしないように、比較的単純な（そして小さい）ものから始めます（セキュリティレッドチームなど）。たとえば、ITショップで一般的なボトルネックであるCPUとネットワークの使用率を監視します。 ## **最適な条件を定義する** システムが一般的にどのように動作するか、そしてどのように動作するかがあります。これらは通常、同じものではありません。 CPU使用率とネットワーク遅延は、アプリケーションの効率、ハードウェアの状態、およびその他の多くの要因によって常に影響を受けます。エンジニアが通常の日、簡単な日、非常に困難な日に何を期待すべきかを概説する標準を作成します。これらは対照群であり、極端な日は ストレステスト。 ## **仮説を立てる** システムはどこで壊れますか？これまでの最悪の日でも見られたピークトラフィックを2倍にするなどのアプリケーションシナリオを実行している場合、CPUは、可変制御グループのように最適な使用率を維持しますか（または、コンテナープロビジョニングエンジンが追加のノードをスムーズに展開します）、または負荷を管理するのに十分なメモリまたはネットワーク帯域幅が残っていないためにプロセスが停止するほど急激に急上昇しますか？ ## **実世界のイベントを実行します（ただし、爆風半径を含みます）** 1つのインターネットサービスプロバイダーへの接続を切断するファイアウォールを停止するなど、極端なことを行います。これにより、アプリケーションが繰り返し失敗する要求に応答しようとするため、アプリケーションが混乱し、デッドネットワークエンドポイントからエラーが返されるとCPUプロセスが増加します。ログイベントがマウントされ、データベースがいっぱいになり、バックボーンが飽和状態になります。 ## **仮説を検証する** どうしたの？テスト中に使用率とネットワークスループットを監視し、システムがどこで倒れたかを確認します。それはあなたが期待したことですか、それともこれまで考えられなかったことが起こったのですか？インフラストラクチャの亀裂から新しい混乱が発生しましたか？安定化、文書化、および修正します。 ## **恐れることをやめないでください** システムに絶対最大値まで、そしてもう少しストレスをかけて、どこで問題が発生するかを確認することで、定常状態の動作とエラー処理を理解できるため、新しい予期しない方法で問題が発生する前にシステムを修正できます。トラフィックの急増はどのように見えますか？実際のイベントとその組織への影響は何ですか？ CEはDevOpsだけのものではありません。これは、障害が発生するまでの（快適ゾーン外での）負荷テストの体系的な方法である必要があります。これは、マイクロサービスの導入以上の責任があり、IT組織内のあらゆる種類の分野に適用されます。 ## **次のステップ：** - 私たちをチェックしてください [新機能ページ](https://www.opsramp.com/the-opsramp-platform/platform-updates/) 2019年秋のリリースのハイライトについて。 - に関するDEJレポートを読む [トップパフォーマンスのIT運用組織になるためのロードマップ。](https://info.opsramp.com/digital-enterprise-journal?hsLang=ja) - [カスタムデモをスケジュールする](https://info.opsramp.com/request-demo?hsLang=ja) OpsRampソリューションの専門家と。 [![OpsRamp-Fall-2019_Release-webinar-CTA](https://blog.opsramp.com/hs-fs/hubfs/Blog_images/OpsRamp-Fall-2019_Release-webinar-CTA.jpg?width=1180&name=OpsRamp-Fall-2019_Release-webinar-CTA.jpg)](https://info.opsramp.com/fall-release-2019?hsLang=ja) [Tweet](https://twitter.com/share) [ Share](http://www.linkedin.com/shareArticle?mini=true&url=https://blog.opsramp.com/ja/chaos-engineering?latest1) [**](mailto:?Subject=Check%20Out%20This%20OpsRamp%20Blog%20Post&Body=I%20came%20across%20this%20post%20on%20the%20OpsRamp%20Blog%20and%20thought%20you'd%20like%20it.%20Check%20it%20out:%20https://blog.opsramp.com/ja/chaos-engineering) Share [Tweet](https://twitter.com/share) [ Share](http://www.linkedin.com/shareArticle?mini=true&url=https://blog.opsramp.com/ja/chaos-engineering?latest1) [** ](mailto:?Subject=Check%20Out%20This%20OpsRamp%20Blog%20Post&Body=I%20came%20across%20this%20post%20on%20the%20OpsRamp%20Blog%20and%20thought%20you'd%20like%20it.%20Check%20it%20out:%20https://blog.opsramp.com/ja/chaos-engineering) X --- ## Recommended posts [![可観測性はまだ初期段階ですか?](https://blog.opsramp.com/hubfs/Blog_Hero_Observability_Report_2024@2x-100.jpg)](https://blog.opsramp.com/ja/observability-early-days?hsLang=ja) [可観測性はまだ初期段階ですか?](https://blog.opsramp.com/ja/observability-early-days?hsLang=ja) [![ユニファイドサービスインテリジェンス：デジタルトランスフォーメーションのための秘密兵器](https://blog.opsramp.com/hubfs/Unified-Service-Intelligence-dashboard-preview.jpg)](https://blog.opsramp.com/ja/unified-service-intelligence?hsLang=ja) [ユニファイドサービスインテリジェンス：デジタルトランスフォーメーションのための秘密兵器](https://blog.opsramp.com/ja/unified-service-intelligence?hsLang=ja) [![「ガラスの単一ペイン」がIT運用の苦痛となっている5つの理由](https://blog.opsramp.com/hubfs/Blog_images/SPOG/SPOG-hero.jpg)](https://blog.opsramp.com/ja/single-pane-of-glass?hsLang=ja) [「ガラスの単一ペイン」がIT運用の苦痛となっている5つの理由](https://blog.opsramp.com/ja/single-pane-of-glass?hsLang=ja) ### Get our regular updates and news © 2026 OpsRamp, LLC. All rights reserved.  [Privacy](https://www.opsramp.com/privacy/) | [Accessibility](https://www.opsramp.com/accessibility) | [Terms of Use](https://www.opsramp.com/terms-of-use/) ![](https://dc.ads.linkedin.com/collect/?pid=342636&fmt=gif) ![](https://px.ads.linkedin.com/collect/?pid=342636&fmt=gif) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Michael Fisher", "url" : "https://blog.opsramp.com/ja/author/michael-fisher" }, "dateModified" : "2021-09-25T08:01:15.701Z", "datePublished" : "2021-09-25T08:01:15.000Z", "headline" : "ITOpsのカオスエンジニアリング", "image" : [ "https://blog.opsramp.com/hubfs/Blog_images/Chaos_Engineering_blog_cover.png" ], "mainEntityOfPage" : { "@id" : "https://blog.opsramp.com/ja/chaos-engineering", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.opsramp.com/hubfs/logo.png" }, "name" : "OpsRamp,Inc." } } ```