[オンラインを守る] リスク管理の予防と調査への道 | JD Cloud テクニカル チーム

序文

プロジェクトの研究開発の過程では、要件レビュー、開発レビュー、コード作成、テストケースレビュー、プロジェクトテスト、製品やUIの承認といった一連のプロセスを経験し、多くの人的資源とエネルギーが投入されてきました。

しかし、最終的なローンチ段階では常に多くの不確実性と変動性があり、テスト段階では N 回テストしても問題ないことも多く、オンラインになった瞬間にバグが発生します (これは単なるマーフィーの法則の呪いです)。 。

長年にわたる残酷な教訓の要約の経験を経て、私たちは各プロジェクトの立ち上げが確実かつ確実かつスムーズに行えることを願い、これらの既知のリスクポイントまたは潜在的なリスクポイントを詳細に整理しました。

この記事では、「運用予防」「二重投稿と自己点検」「監視と警報」の3つの側面からオンラインリスクを防ぎます。

1. 使用上の注意事項

これには主に、研究開発防止、構成防止、運用保守防止、承認防止の 4 つのカテゴリの防止が含まれます。

1.1 研究開発の防止

1.1.1 一般層

1. 読み込み・確認の統一標準化

2. エラーページ/スケルトン画面/データ無し/ネットワーク例外仕様

3. アナウンスおよびポップアップウィンドウの仕様

1.1.2 コード層

1. https を使用し、非 JD ソースを禁止し、外部ネットワークが利用可能であることを確認します。

2. 環境切り替えはシステム変数によって区別されます

3. コミット仕様

▪ 独立した関数コードの単一提出

▪ コーディングのために提出されたすべての研究開発コード

4. 統合IDEとスキャフォールディング

5. 開発環境node.js、npm、joyer、taro等のバージョンを統一

6. 共通コンポーネントの統一

▪没入型 ナビゲーション

▪共有 コンポーネント、検出バージョンのサポート、およびフォールトトレラント処理

▪はしご コンポーネント

▪暗号化 アンチスワイプ: AKS、AAR

▪ リスク管理機器の指紋

▪埋もれた特異点

▪evokeコンポーネントをダウンロード

▪ コンポーネントとゴールデンパスワードを共有

7. データ処理

▪ リクエストの無限ループを回避するためのページロード

▪ゲートウェイ 層のエラーコード処理

▪サーバー インターフェイス層のエラーコード処理

▪ メイン関数インターフェースの例外として、エラーページへのジャンプ/ポップアップウィンドウのリトライなどの必要な処理が含まれます。

▪ベーシック プラン

1.1.3 UI层

1. ダイナミックな効果はありますか

2. 音声とビデオに互換性があるかどうか

3. パフォーマンスの遅れはありますか?

1.1.4 セキュリティ層

1. コーディングの問題: eslint を渡すかどうか

2. 互換性の問題: コーディング構文の処理、メソッド属性、コンポーネント ライブラリの最小サポート バージョンなど。

3. ロジック機能: コードのロジックが期待される機能と一致しているかどうか

4. 異常状態: ダウングレード/フォールト トレランス/タイムアウトなどの異常状態を考慮するかどうか

5. ユーザー エクスペリエンス: 新しい機能または変更された機能が、パフォーマンスやエクスペリエンスに関してユーザー エクスペリエンスに悪影響を及ぼしているかどうか

6. セキュリティ: 暗号文の送信、ブラシ防止、スクリプトインジェクションなど。

7. モック：モックデータの表示が正しく処理されているか

8. 機密データ：データ処理における潜在的な顧客からの苦情リスクの有無など。

1.2 構成防御

1.2.1 研究開発体制

1. コンテンツの構成 プラットフォームの構成 オンラインに影響を与えないように注意して、オンライン構成を再度操作する必要があります。新しい構成を追加してみてください。

2. 設定データ型は時間制御をサポートしておらず、時間やタイムスタンプなどのデータを設定することは禁止されています

3. 設定前のデータ検証 (例: リンク形式が正しいかどうか、データ長を制限する必要があるかどうかなど)

4. データフォールトトレラント処理は、重要なデータの場合、必須項目として設定する必要があります。 "required": true;

1.2.2 動作構成

1. イベントがライブになる前に、すべての本番構成を完了する必要があります

2. すでに発売されている構成の場合、再稼働については製品と研究開発に確認する必要があり、稼働中に二重に確認する必要があります。

3. リリース前の環境検証、データと制作が一貫していること (賞品の種類、クーポンの種類、スキルタイム、タスクの種類など)

4. 報酬、クーポン、またはタスクは、フロントエンドで構成および表示される前に、検証され、正常に発行または受信できるかどうかを確認する必要があります。

5. イベントから他のイベントページへ特典ポイントを使用するには、二次イベントページでの特典ポイントの使用が正常であることを確認する必要があります

1.2.3 環境設定

1. すべての新しいプロジェクトは Joyer Scaffold で初期化されます

2. 統一されたコマンド、ローカル環境、パッケージ化、公開環境など。

3. vconsole、アノテーションなどは非運用パッケージでのみ構成されます

4. 各プロジェクトには模擬環境が必要です。コードを変更したり注釈を付けたりするのではなく、模擬データを使用してさまざまな状況を検証します。

5. 旧プロジェクトがwebpackとvue-cliの統一仕様を採用しているか

1.3 運用保守の予防

1.3.1 ドメイン名解決操作

1. アプリケーションの下に IP が存在しません

2. インスタンス上にアクセス可能な項目があるかどうか

3. プロジェクトがアクセス可能かどうかを確認するために、運営および保守との協力を求めます

4. 運用および保守の作業指示が受け入れられ、開発者に時間内に確認するよう通知されることを確認します。

1.3.2 CDNの運用

1. ソースサイトのドメイン名と高速化されたドメイン名のドメイン名が一致していないことを確認します。

2. アップロードされた高速コンテンツが配信方法 (画像、大きなファイル、ビデオ、ライブ ストリーム) と一致していることを確認します。

3. アクセラレーションされたドメイン名の下にあるファイルが静的リソースであることを確認します (動的と静的な分離が必要かどうかを検討してください)。

4. ソースサイトのIPが正しいことを確認してください

5. アクセス申請後はCDNが完了しただけであり、DNS解決変更の設定も必要です

6. ドメイン名をクエリして入力し、解決策が国内のすべての地域で有効かどうかを確認します。

1.3.3 HSTSの動作

1. クライアントまたはアプリケーションが https であること、または https ストロング ジャンプに問題があるかどうかを確認します。

2. VIP 下の複数のアプリケーションまたはドメイン名については、影響があるかどうかを確認するためにすべての関係者に通知する必要があります。

1.3.4 http2 の操作

開く前にドメイン名が https であることを確認してください

1.3.5 DDOS操作

CDN ドメイン名が一時的に利用できなくなりました

1.3.6 拡張操作

1. マシンの承認が完了し、実行結果がすべて成功であることを確認します

2. 新しい拡張マシンの構成とプロジェクトの展開を確実に行う

3. ハイブリッド展開の場合、複数のアプリケーションがある場合、すべてのアプリケーションを展開して検証する必要があります（運用と保守が連携できるようにする）

4. アプリケーションの混合展開により、各アプリケーションは多重化された作業指示を確実に実行する必要があります。

5. 拡張作業が完了したら、必ずマシンの動作を再起動してください。

1.3.7 縮小操作

1. CDN ドメイン名がイントラネット VIP に解決されることを確認します (リップの場合は、VIP 変更作業指示プロセスを実行する必要があります)。

2. 混合デプロイでは、各アプリケーションが作業指示書を確実に実行する必要があります。

3. 事前に発行されたマシンは、事前に発行されたドメイン名のリバース プロキシ変更作業指示を補足する必要があります。

1.3.8 オフライン操作

1. オフラインのマシンがオンライン (プロジェクトの独立した展開) に影響を与えるかどうかを確認します。

2. トラフィックを収集する手順 (オフラインにする前にマシンを収集するなどの手順) に注意してください。

1.3.9 ロールバック操作

1. JDOS を使用してロールバック操作をクリックします。

2. 選択したパッケージをロールバックするには、それが最後のオンラインパッケージであるかどうかを慎重に確認します。

1.3.10 バスティオンマシンの操作

1. コンテナは正常に起動する必要があります

2. dockerfile によって構築されたイメージは root 権限のみを適用でき、ポート 22 を開く必要があります。

3. 公開イメージの場合、root 権限のみを申請でき、ポート 22 が開いている必要があります。

1.4 承認上の注意事項

1. テストノードで承認されているかどうか

2. リーダーによるレビューが行われているかどうか

3. 開発権限と承認権限が分離されているか





 

2. 二重投稿と自己検査

オンラインに移行する前の 2 回の自己検査は、当社が策定した標準プロセスです。研究開発担当者は、オンラインになる前に以下のリストに従う必要があり、プロジェクト コードを確認するために他の同僚の協力を求める必要があります (当局は執着しており、傍観者は明らかです)。

2.1 フロントエンド

2.1.1 環境検査

1. ドメイン名が CDN に接続されているかどうか

2. jen設定が一貫しているかどうか

3. ジェンはすべてオンラインですか

4. gzipを有効にするかどうか

5. 導入されたマシンの数は予想と一致していますか?

2.1.2 共通コンポーネント

1. AARにアクセスするかどうか

2.AKS にアクセスするかどうか

3. リスク管理へのアクセスの有無

4. SGM監視を追加するかどうか

2.1.3 要件のチェック

1. このオンライン リソースには、この製品要件を反復しないコンテンツが含まれていますか?

2. ページ内で紹介されているリソースが今回のオンラインコンテンツの全てかどうか

3. 今回のオンライン リソースはプレリリースのテスト済みバージョンですか?

2.1.4 コード検査

1. サードパーティのコードインジェクションがあるかどうか

2. 機密性の高いフィールドがあるかどうか

3. log/mock/Vconsole などのデバッグツールを削除するかどうか

4. プロジェクトに http ドメイン名リソースがあるかどうか

5. サーバーインターフェースがオンラインかどうか

6. すべてのリソース ドメイン名がオンライン ドメイン名およびエクストラネット ドメイン名であるかどうかを検出します。

7. パッケージリソースファイルのハッシュが本番環境でデプロイされているかどうか

8. 倉庫マスターコードが最新かどうか

9. ハイブリッド展開アプリケーションの場合、この起動は現在のアプリケーション コードを更新するだけですか?

10. Babel カスタム コンポーネントの場合、この変更は下位バージョンを考慮するかどうか、また他のプロジェクトで参照されているテンプレートに影響するかどうか

2.1.5 回帰チェック

1. 4G/5G 認証を使用する

2. オンラインにした後、CDN リソースがオンラインで最新であるかどうかを確認します

3. オンラインになった後の検証。混合デプロイメント プロジェクトの場合、最新のブランチがマスターにマージされるかどうか

2.1.6 作業指示の処理

1. 二重投稿検査合格確認

2. UI ウォークスルーが通過して確認される

3. リスク管理の受け入れが合格および確認される

4. セキュリティ テスト作業指示書を送信して完了します。

2.2 サーバー

2.2.1 チェックポイントの監視

1. 業務監視

◦注文 _

◦ ログ例外

◦ SQL 例外

◦ SQL に時間がかかる

◦業務 に時間がかかる監視

◦業務 状態の異常監視

◦ 異常プロセスの監視

2. 基本的なモニタリング

◦ 1 番目のタイプの運用と保守: アプリケーション システムが依存するハードウェア、仮想マシン、ネットワークなど

◦ 2 番目のタイプの運用と保守: CPU、メモリ、ハードディスク、IO などのオペレーティング システム レベル。

◦ 3 番目のタイプの運用と保守: データベース、キャッシュ、Tomcat、ningx などのミドルウェア レベル。

◦ 4 番目のタイプの運用と保守: JVM 監視、ログ収集などのアプリケーション自体。

◦ 運用保守の5つ目：新機能のオンライン運用と日常の緊急訓練

2.2.2 一般的なセルフチェックポイント

1. オンライン注文クラス

◦ 複数の内部アプリケーションがオンラインにあり、依存関係とオンライン順序が考慮されているかどうか

◦ アプリケーションをオンラインにする前に、関連するテーブル構造を作成し、mq、rpc、およびその他の操作を登録する必要がありますか?

◦ この バージョンはオンラインであるか、外部アプリケーションが関与しているかどうか、連携するために他のモジュールが必要かどうか、オンラインのシーケンス要件があるかどうか

2. セキュリティカテゴリ

◦ SQL インジェクション、XSS 攻撃、機密情報の暗号化、アカウント ブラストなどの外部ネットワークのセキュリティ問題を考慮するかどうか。

◦ インターフェース通信のセキュリティ問題、署名検証、秘密鍵管理などを考慮するかどうか。

◦ さまざまな訪問に対してホワイトリスト、証明書、または SMS の追加を検討するかどうか

◦ データベースの機密フィールドが暗号化されているかどうか

3. 耐ブラッシング、耐重度

◦ ステートとシナリオがオーダーを繰り返し送信できる重複防止メカニズム

◦同じ秒間に複数の同じ注文を受け入れることに制限はありますか

◦ プラットフォームの固有ID生成が重複する可能性があるかどうか

◦ すべてのリクエスト エントリ、タイマー、および API リクエストにオプティミスティック ロックを使用するかどうか。同時処理や繰り返し処理の問題を考慮し、更新の影響を受ける項目数を判断する

4. 例外処理クラス

◦ 各事業の本店以外の異常支店の処理の有無

◦ 詳細な例外スタックを食べないでください。

◦ 三者間の対話が完了しているかどうか

▪ 処理のためにIOExceptionをキャッチする必要がある

▪ IOException は、アラームのトラブルシューティングを容易にするために URL を出力する必要があります。

▪ 接続タイムアウトと読み取りタイムアウトを設定する必要があります

▪ プロキシを介してオンラインに接続する必要があるかどうか

▪ ホワイトリストを再度追加する必要があるかどうか

▪ 三者間の最大数制限の有無

▪http接続数を適切に設定し、接続を閉じる

5. ログ仕様クラス

◦ ログの印刷には独自のビジネス仕様があり、ログの検査に役立ちますか

6. スケジュールされたタスク

◦ ビジネスタイマーにウェーブや繰り返し処理があるかどうか、および同時構成が false に設定されているかどうか

◦ スケジュールされたタスクで処理されるデータ量は、予想される実行サイズであるか、異常な状況では処理サイズがさらに増加するかどうか

7. SQLクラス

◦ 一意のインデックスが使用されているかどうか

◦ ユニークインデックスの使い方は正しいか? 例えば、結合ユニークインデックスとして複数のフィールドを使用している場合、フィールドがnullになるケースはないか

◦ update ステートメントと select ステートメントに予想される実行サイズがあるかどうか

◦ 複雑なSQLの使用を避けるかどうか

◦ SQL が実行計画をチェックしたかどうか、インデックスにヒットできるかどうか、一定期間のビジネスの成長中に SQL が遅くなる可能性があるかどうか

8. キャッシュの使用

◦ キャッシュの 使用量、タイムアウト期間を設定するかどうか、タイムアウト期間が正しく設定されているかどうか、秒単位かミリ秒単位か

キャッシュ同期の問題に対する解決策の評価(データベース悲観的ロック + トランザクション + ソート、redis 悲観的ロック、CAS)

◦redisの利用シナリオを明確にする

9. トランザクションの利用

◦ コードでトランザクションを使用する場合は、デッドロックのシナリオを考慮する必要があります

10. 経営背景

◦ バックグラウンドダウンロードやクエリの管理などの機能に数制限や頻度制限があるかどうか

11. 型変換

◦ 型変換が正しいかどうか、最初に空にしてから変換したかどうか

12. 接続数、スレッド数

◦ スレッドの作成はスレッド数に合理的に制限されていますか?

◦ 関連ミドルウェアの接続プール数が合理的に設定されているか

13. リターンコードの分析

◦ 解析応答コードが正しいかどうか、特にネットワーク例外、例外のキャッチ、およびそのような順序がない場合などの特殊な場合

◦応答 分析 - ネットワーク例外/順序が存在しない（ネットワーク例外とトランザクション以前のクエリが原因）、非特定の障害、障害を設定できない

14. システム設計の問題

◦ 非同期から同期。バックエンドの非同期コンポーネントが停止または再起動された場合、同期ディスパッチ データは一貫してブロックされます。

◦ノードは 1 つありますか

◦ 分散展開をサポートするかどうか

◦ 楽観的ロックは同時変更を防止し、悲観的ロックは同時変更を防止します。

15. タイムアウト設定

◦ HTTP、Redis、データベースなどの RPC 呼び出し場所で接続タイムアウトと応答タイムアウトを設定するかどうか。

16. 財務的属性

会計 機能は、同時条件下で残高と損失が正確であるかどうかを考慮する必要がある

◦金額 単位、精度は正しいか

◦金額 タイプの変換が正しい

17. 時間の書き込み

◦ 時刻 形式、精度に問題があるかどうか、データベースへの書き込み後に丸めが発生してクエリの不一致が発生するかどうか

◦ データベースの 時刻設定の問題、East Eighth District を設定するかどうか、アクティビティで時刻に East Eighth District 形式を使用するかどうか

18. 設定ファイル

◦ オンライン構成ファイルがオンライン パッケージから個別に抽出されるかどうか、および事前にプラットフォーム上で個別に構成されているかどうか

◦ 抽出できない設定ファイルがある場合、コードとともに提出された設定ファイルが正式環境の設定情報であるか確認されているか

2.2.3 リソースサポートアイテム

1. 運用バックグラウンドパラメータの設定など、運用に関する追加サポートを提供するかどうか

2. ネットワーク環境の構成、証明書キーの追加、ファイル ディレクトリの作成、jar パッケージの追加と削除など、運用とメンテナンスの追加サポートを提供しますか。

3. DBA に追加のサポート (データベース アクセス ホワイトリストを追加するための新しいモジュールの追加など) を提供してもらいますか?





 

3. 監視と警報

監視と警報は、発売後のリスク管理に必要な仕組みであり、警報が発生した場合には、できるだけ早く調査して解決し、顧客からのさらなる苦情を防ぐことができます。

1. RPC層の監視

◦タイムアウト 監視

◦例外 エラーのレポート

◦可用性 _

2. キャッシュ監視

◦ Redis 接続が異常です

◦ r2m 稼働率

◦ r2m 容量

◦ r2m マスター/スレーブ切り替え

3.MQ モニタリング

◦ MQ は重複を受信します

◦ MQ 送信に失敗しました

◦ MQ での処理が失敗しました

4. タスクの監視

◦ スケジュールされたタスクが実行されない

◦ 時間 指定タスクのタイムアウト

◦ スケジュールされたタスクの実行が異常である

5. ビジネス例外の監視

◦ ロック例外の取得

◦ AKS とアンチスワイプ失敗例外

◦ タスクの受領・受付などの異常なタスク

◦ 群衆には許可がありません

6. JVM監視

◦ fullGc ログとアラーム

◦ jvm 監視アラーム

7. コンテナの監視

◦ インスタンス の生存

◦ CPU の負荷と使用率

◦マシン メモリ

8. DB監視

◦ DB 層の CRUD 実行例外

◦ 賢いBDの遅いSQLの定期検査

◦ DB クエリ操作に時間がかかりすぎる

◦ オンライン環境（アプリケーション、データベース、設定など）の承認責任者が現在のリーダーであるかどうか

9. 関心点の監視

◦ マーケティング 報酬の失敗

◦ 在庫不足

◦ イベントが開始されていない/終了していない

◦ リスクに支配される

◦ 重複防止の失敗

◦ 1 人のユーザーが受け取った特典の数が、設定された警告ラインを超えています

◦ イベントの全体的な分布が、設定された警告ラインを超えています

◦ その他の 例外は失敗します

10. ビジネス応答コードの監視

可用性を監視するためのサード パーティインターフェイスの正常コードと異常コードの設定

11. 構成の検証

◦ 構成例外の取得

◦ 設定フィールドが設定に設定されていない

◦ 構成内のフィールド構成タイプが異常です

◦ 現在時刻に一致する設定はありません

◦ キャンペーンは終了しましたが、依然として多くのユーザーがアクセスしています。

◦ 複数の構成での時点の競合

設定 された報酬 ID/タスク ID などは、サードパーティのインターフェイスでは照会されません。

◦ 各 操作により構成が変更され、変更された項目はアラームを通じて研究開発に送信され、アラームは等級付けされます。

12. 活動資格の確認

◦ 検証警告を回避する

◦ 特典を受け取るのは古いユーザーである必要がありますが、新規ユーザーは事前認証を経て特典プロセスに入ります。



 

著者: フー・ジュン、JD Technology

出典: JD Cloud 開発者コミュニティによる転載。出典を明記してください

マルチ環境開発をサポートする国内初のIDE——CEC-IDE MicrosoftがPythonをExcelに統合、グイおじさんがフレームワーク策定に参加 中国プログラマーらギャンブルプログラム作成を拒否、歯14本抜かれ88%の身体損傷 オープンソースのSongフォントを模倣したPodman Desktop、 ダウンロード数50万件を突破 オープニング画面の広告を自動的に 無期限に更新停止 「Li Tiao Tiao」が スキップ Xiaomiがmios.cnウェブサイトのドメイン名を申請

{{名前}}

{{名前}}