ビッグデータプラットフォーム 赤と青の対決 ~剣を研ぎ、兵士を鍛えよ!| JDクラウド技術チーム

1. 背景

現在の主要なプロモーションの一般的な準備タスク: 特別なストレス テスト (フルリンク ストレス テスト、内部ストレス テスト)、災害復旧訓練、ダウングレード訓練、電流制限、検査 (モニタリング、アプリケーションの健全性)、カオス訓練 (赤と青の対決)、以下に示すように。プラットフォームビジネスが複雑化するにつれ、赤青対決の役割はますます明確になっており、今回のダブルイレブンプロモーションに向けて、ビッグデータプラットフォームがどのように赤青対決を行ったのかについて詳しく紹介する。

図 1. 大規模なプロモーションを準備するための一般的な作業手順
 

まず、赤青対決とは何なのか、そしてその利点は何なのかを理解しましょう。

2. 赤青対決の紹介

赤と青の対決は、ネットワーク セキュリティの分野で一般的な敵対的訓練手法であり、プラットフォーム セキュリティの脅威監視機能、緊急対応機能、保護機能を統合し、実際のネットワーク環境で実際の部隊と赤と青の対決訓練を実施することを指します。セキュリティ保護技術と管理システムを改善および改善します。

青い面が攻撃側、赤い面が防御側を表します。赤と青の対立では、制御された環境で実際のネットワーク攻撃と防御プロセスをシミュレートし、青側は赤側を攻撃するためのさまざまな脅威と攻撃方法をシミュレートして、その防御能力とシステムの高可用性をテストします。レッド チームは、防御と対応、システムの問題の発見と修正、攻撃者に関する情報の収集を担当します。

図 2. 赤と青の対立

3. 赤青対決のメリット

1. 監視アラームの有効性を確保する

赤と青の対立は、業界や研究機関がアラーム設定の監視の有効性、通知の適時性、情報の正確性を検証するのに役立ちます。

2. システムの信頼性の向上

赤と青の対立は、システム内でエラーを引き起こす可能性のある潜在的な問題を特定することで、システムの信頼性を向上させるのに役立ちます。

3. リスクを軽減する

赤と青の対策は、悪意のある攻撃者によって悪用される可能性のある潜在的な弱点を特定することで、オンラインの問題に関連するリスクを軽減します。

4. 費用対効果の高いテスト

赤と青の対立は、実稼働環境のシナリオをシミュレートしますが、実稼働環境にリスクを引き起こすことはなく、テストの観点からシステムの品質を保証します。

図 3. 赤と青の対立の利点

4. 赤青対決練習

赤青対決訓練の実践は主に、訓練発表、要員の指名と任務の割り当て、訓練前のシナリオレビュー、赤青対決プロセス、訓練結果の収集、訓練レビューの6つの部分で構成されます。

図 4. 赤青対決の練習には主に 6 つの部分が含まれます

4.1 演習の発表

主に次の 2 つの部分で構成されます。

まず、この赤青対決の責任者は、対決訓練キックオフ会議を組織し、対決訓練の時間範囲を決定し、リアルタイム/オフライン訓練インターフェース担当者を指名します。

第二に、リアルタイム/オフライン製品は、電子メール/社内アプリを介してビジネス ユーザーに赤青対決訓練が実施されることを事前に通知します。

図5. 赤青対決訓練のお知らせ

4.2 人員の指名と任務の割り当て

まず、この赤青対決の担当者を指名します。計画の策定、訓練対決文書の実施、シナリオ収集の通知とレビュー、攻撃側の開始と防御側の防御プロセスの整理、訓練レビュー作業など、赤と青の対立訓練全体の総合調整を担当します。

次に、リアルタイムとオフラインの準備インターフェイス担当者をそれぞれ指定します。青色の攻撃者は主にドリル攻撃のシナリオを指定し、システム攻撃を開始します。

ここでも、リアルタイムとオフラインのバックアップ要員をそれぞれ指定します。一般に、彼らは中核的な研究開発要員であり、攻撃を開始する具体的な時間が不確実であるため、青チームが攻撃を開始した後、さまざまな特別な理由により赤チームが障害に対処できず、通常のシステムに影響を与えることを避けるために、オンライン ビジネスでは、バックアップ担当者がシステムを迅速に復元できます。

最後に、ライブ側とオフライン側のエクササイズ モニターを個別に割り当てます。通常、彼らはテスターであり、主に訓練中に発行された警報情報(mdc、ump)の記録と訓練記録文書のレビューを担当します。

図 6. 赤と青の対立要員の指定とタスクの割り当て

4.3 演習前のシナリオ収集

この部分は訓練前の最も重要なリンクであり、主に訓練の適用範囲の決定と攻撃者の訓練シナリオの決定が含まれます。

4.3.1 訓練の適用範囲の決定

ドリル アプリケーションの場合は、ビジネス ニーズに基づいて選択できるアプリケーション レベル L0 および L1 のアプリケーションを優先することをお勧めします。さらに、JD.com では次の 2 つの方法で、対応するアプリケーションをすばやくクエリできます。

http://XXX.jd.com/dashboard/4/node/XXX

http://XXX.jd.com/health

詳細なドリル アプリケーション リストは、リアルタイム/オフライン インターフェイス担当者によって提供されます (C3 リーダーによってレビューおよび承認されます) 出力: 攻撃者によるバッチ インジェクション シナリオのコレクション。

図 7. ドリルの適用範囲

4.3.2 ドリル失敗シナリオの収集

Jdos アプリケーションは主に、次のドリル シナリオを使用して、フォールト インジェクションに [Chaos Engineering] プラットフォームを使用します。

高 CPU 使用率、高メモリ使用率、高ディスク使用率、ネットワーク遅延、ネットワーク パケット損失、プロセス終了、mysql リクエスト遅延例外、jimdb リクエスト遅延例外など。

基盤となるクラスターでは、運用および保守担当者が主にスクリプトやコマンドなどを使用してフォールト挿入を実行します。主に次の訓練シナリオが含まれます。

データベース インスタンスの CPU が高い、hdfs キューがいっぱい、コンピューティング タスクが保留中、RSS クラスターがビジー、zk ノードが異常にダウンしているなど。

4.4 赤青対立プロセス

訓練シナリオを準備し、製品が訓練通知メールを送信すると、赤と青の対決を開始できます。ここで注意すべき点がいくつかあります。

① 具体的な攻撃時間は青チームに「開示」することはできません。

② オンラインの問題をできるだけ現実的にシミュレートするために、攻撃用に実稼働環境のアプリケーションまたはクラスターを選択することをお勧めします。

4.4.1 【主任】訓練前の連絡

青攻撃者の公式訓練前に、担当者が事前にグループにメッセージを送信します。テンプレートは次のとおりです。

@全体成员  
【重要通知】
今天17:30~21:30大数据平台(实时+离线)进行红蓝对抗演练,不定时进行故障突袭。请各位同学将跟进处理过程在本群进行同步。分三个阶段:问题发现、原因分析诊断、故障处理。
每个环节(问题发现、故障诊断、故障处理)确定后立马发消息,不要最后发总结!
每个环节(问题发现、故障诊断、故障处理)确定后立马发消息,不要最后发总结!




1、问题发现
【问题发现】
产品-服务名称:
(1)收到电话/咚咚告警,告警内容xxx  
或
(2)雷达大屏飘红,截图xx  开始排查处理


2、原因分析
【故障诊断】
产品-服务名称:xx问题原因已查到,原因概要描述。


3、故障处理
【故障处理】
产品-服务名称::xx问题已处理,已恢复,并给出告警恢复/监控截图。

4.4.2 [青チーム] 演習タスクの作成と実行

カオス エンジニアリング プラットフォーム上で、Blue チームは、以前に収集した訓練シナリオに基づいて訓練タスクを作成するか、バッチで訓練タスクを作成します。以下に示すように:

図 8. 青チームがタスクを作成する

次の点を説明します。

① 基盤となるクラスターへの攻撃は主にコマンドとスクリプトを通じて実行されますが、ここでは詳しく説明しません。

② ネットワーク遅延やパケットロスによりドリルが失敗する場合があります 理由は、ネットワーク障害ドリルが制限されている(ホストカーネルのバージョンに既知のバグがあるためドリルできない)「4.18.0-80.11.2.el8_0.x86_64」です。

③ メモリ使用率が 100% のシナリオでは、Linux メモリがいっぱいになると oom kill がトリガーされるため、90% に設定することをお勧めします。

④ ドリル継続時間は 5 分以上を推奨します 理由:一部のアプリケーションで設定されている MDC アラーム周期範囲は 5 分以内となっており、ドリル継続時間が 5 分未満の場合、アラームを受信できない可能性があります。

4.4.3 [レッドチーム] 防御修復エラー

青チームが攻撃を開始すると、赤チームは社内アプリからアラームを受信し、確立された計画に従って障害を修復します。いくつかのスクリーンショットは次のとおりです。

図 9 および 10. 社内アプリのアラーム表示

4.4.4 [レッドチーム] システムの回復

一部の訓練シナリオ (プロセスの終了) は自動的には回復しないため、レッド チームはシステム アプリケーション サービスを手動で再起動して、運用アプリケーション サービスが正常であることを確認する必要があります。

4.4.5 [赤チーム + 青チーム] 訓練終了

赤と青の対決訓練の後、赤と青の両方の側が「赤と青の対決訓練シナリオ」文書に記入し、青側がカオスタスクリンク、カオスドリルシナリオ、訓練ステータス、カオスドリル実行開始時間、を記入します。カオスドリルの実行終了時刻。赤いボックスに記入します: トラブルシューティングツール、アラーム情報、根本原因、原因のトラブルシューティングにかかる​​時間、トラブルシューティング プロセスの説明 (トラブルシューティング プロセス、ツールの使用、補助的な意思決定と判断を含む)、計画された解決策と緊急計画、および推定処理時間に影響を与えます。以下に示すように:

図 11. 演習後の書類記入。

 

4.5 訓練結果の収集担当者は訓練結果を検討し、分離訓練の問題点を整理し、赤側と青側ができるだけ早く改善できるようにします。主な問題点は以下の通り

1) 問題をタイムリーに処理できなかった: アラームを受信した後、レッド チームはさまざまな理由 (会議、仕事の欠席など) により、問題をタイムリーに処理できませんでした。

2) 不完全な処理: レッド チームが ns 障害の問題を処理した後、失敗したタスクを処理するようにユーザーに通知しませんでした。

3) アラームは受信されませんでした:

① アラームルールが設定されていません。たとえば、mdc または ump プラットフォームはアラームを設定しません。

② アラーム閾値が発動しない。たとえば、青のチームが攻撃する場合、CPU 使用率は 90% ですが、mdc アラーム ルールは 95% に設定されています。

③ mdc プラットフォームはアラームを無効にします。たとえば、mdc は、テンプレート センターでの MDC の監視とアラームを一時的に無効にします。

図 12. ドリルの問題点

4.6 演習の復習

担当者が赤青対決検討会を開催し、訓練結果と課題リストを提供、リアルタイムアーキテクトとオフラインアーキテクトが参加し、訓練プロセスや訓練効果などの観点から訓練の評価や提案を行います。 。

① 警報レベルの自己点検と修正が必要です。現在、一部のアラームレベルが低く設定されており、CPU使用率が90%を超える場合は「警告」が報告されますので、「緊急」に変更することをお勧めします。

②アタックタイムを延長する。攻撃時間が 30 分以上のアプリケーションをいくつか見つけて、防御側が実際にトラフィックを収集しているかどうかを確認します。

③カオスドリルを常態化する。これは、カオス エンジニアリング プラットフォームである通常の訓練を通じて実行でき、任務スケジュールと組み合わせて、戦争を通じて軍隊を訓練するための訓練の頻度を増やすことができます。

④ [警報]と[緊急]のシナリオを段階的に練習します。第一段階では10分以内に【警告】が発生する場面を攻撃し、第二段階では10分以内に【緊急】が発生する場面を攻撃します。

⑤ Java メソッドの例外と遅延のシナリオは実践されていません。将来的には、テスターは Forcebot ストレス テストを通じてトラフィックの流入をサポートすることが期待されます。

Chaos プラットフォームのサポートを期待します:

① カオス エンジニアリング プラットフォームは、カオス ドリル タスクを作成、開始、停止するための複数のアプリケーションの一括選択をサポートします。現在のドリルタスク一括作成機能では、アプリケーションを1つずつ追加して作成するしかありません。

②カオスエンジニアリングプラットフォームは正規化されたカオスドリルAPIを提供します。ユーザーにとって、正規化されたドリル タスクをカスタマイズおよび作成するのに便利です。

③ カオス エンジニアリング プラットフォームは、プラットフォーム内での mdc および ump アラームの表示をサポートします。ユーザーが複数のプラットフォーム システム間を行ったり来たりする手間を減らします。

5. まとめ

この赤青対決訓練を通じて、ビッグデータプラットフォームシステムアプリケーションのリスク対策能力を効果的に強化し、実稼働環境のシステム障害の可能性を低減しただけでなく、研究開発担当者の問題や障害を解決する能力も大幅に向上しました。豊富な経験も蓄積しており、迅速かつ効率的な訓練計画を立てることができます。

最後に、Chaos Engineering Platform の強力なサポートに感謝します。

著者: JD Retail インウェイ

出典:JD Cloud Developer Community 転載の際は出典を明記してください

 

Microsoft、新しい「Windowsアプリ」 .NET 8を正式にGAリリース、最新LTSバージョン XiaomiはXiaomi Velaが完全にオープンソースであり、基盤となるカーネルはNuttXであることを正式に発表 Alibaba Cloud 11.12 障害の原因が明らかに:Access Key Service(アクセスKey) 例外 Vite 5 が正式にリリースされた GitHub レポート : TypeScript が Java に取って代わり、3 番目に人気のある言語になる Rust で Prettier を書き換えるために数十万ドルの報酬を提供 オープンソース作者に「プロジェクトはまだ生きていますか?」と尋ねる 非常に失礼で、失礼な バイトダンス: AI を使用して Linux カーネル パラメータ 演算子を自動的に調整する 魔法の操作: バックグラウンドでネットワークを切断し、ブロードバンド アカウントを無効化し、ユーザーに光モデムの変更を強制する
{{名前}}
{{名前}}

おすすめ

転載: my.oschina.net/u/4090830/blog/10149308