10 億レベルの Web システムに対する高度な耐障害性の実践_html/css_WEB-ITnose

10億レベルのWebシステムの高耐障害性実践

背景紹介

3年ほど前、私はTencentでイベント運営システムを担当していました。ビジネストラフィックの規模が増大したためです。当時、私は開発者として24時間365日アラームに対応しており、週末や早朝にオンラインになることが多く、疲れ果てていました。その後、当時のリーダーが「いつも「消防団長」の役割を果たせるわけではない。問題の根本原因をシステム全体から考えて、解決を進めなければならない。」と言いました。

私は突然、「火」は決して消すことができず、システムが自動的に「火を消す」ことを可能にすることが問題を解決する正しい方向であることに気づきました。つまり、システムの異常は常に「人」に頼って復旧できるわけではなく、根本的な解決策はシステム自体を「フォールトトレラント」にすることです。 3 年以上が経過しましたが、私はまだこのシステムを担当していますが、毎日数百万件のリクエストがある小規模な Web システムから、ピーク時の 1 日あたり 8 億件のリクエストがあるプラットフォーム レベルのシステムまで徐々に成長してきました。忘れられない技術的な旅。

フォールト トレランスは、実際にはシステムの堅牢性を示す重要な指標の 1 つであり、この記事では主に「フォールト トレランス」機能の実践に焦点を当て、技術系の学生にインスピレーションを与え、役立つことを願っています。 (注: QQ 会員アクティビティ運営プラットフォーム、以下 AMS と呼びます)

1. リトライ機構

人々が考える最も簡単で単純なフォールトトレラント方法は、当然のことながら「失敗リトライ」です。シンプルで粗雑です！シンプルとは、その実装が通常非常に単純であることを意味し、ラフとは、再試行はバックエンド サービスに対する二重リクエストを意味するため、不適切な使用によりシステムの「雪崩」のリスクがもたらされる可能性があることを意味します。

1. 単純な再試行

サービスをリクエストし、サービスリクエストが失敗した場合は再試行します。このサービスの通常の条件では成功率が 99.9% であると仮定します。特定のボラティリティ異常により、成功率は 95% に低下します。再試行メカニズムがあれば、成功率はおそらく 99.75% に留まります。単純な再試行の欠点も明らかであり、サービスに問題がある場合、二重トラフィックが発生し、サービス システムに影響を及ぼし、サービスを直接過負荷にする可能性があります。実際のビジネス シナリオでは、機能が利用できない場合、ユーザーが「繰り返しクリック」する可能性が高く、むしろトラフィックへの影響が大きくなります。サービスの成功率が比較的低いのに比べ、システムが直接影響を受けて「ハング」した場合の影響は明らかに深刻です。

単純な再試行は、適切なシナリオで使用する必要があります。または、サービスの成功率を事前に計算し、成功率が低すぎる場合は、過剰なトラフィックへの影響を避けるために再試行しないでください。

2. アクティブ サービスとスタンバイ サービスの自動切り替え

単一のサービスを再試行すると、サイトに二重のトラフィック影響が生じ、最終的にはより深刻な結果につながる可能性があるため、シナリオをアクティブとスタンバイに変更することも考えられます。サービスの自動再試行または切り替え。たとえば、openid を取得するために 2 つのサービス セットを構築しました。サービス A がそれを取得できなかった場合、サービス B から取得しようとします。再試行のリクエストプレッシャーがサービス B にかかるため、通常、サービス A は再試行によってトラフィックが二重に影響を受けることはありません。

この再試行メカニズムはより使いやすくなっているように見えますが、実際にはいくつかの問題があります:
(1) 通常、「リソースの無駄」という問題があります。バックアップ サービス システムは長時間アイドル状態になる可能性が高いため、メイン サービスに異常が発生した場合にのみそのリソースがフルに使用されます。ただし、コア サービス ビジネス (コア データや収益関連など) に対して同様の展開を実行すると、マシンのコストと予算が多少増加しますが、通常はその努力に見合う価値があります。
(2) 再試行メカニズムをトリガーすると、ユーザーのリクエストにかかる時間が必然的に増加します。メイン サービスのリクエストが失敗し、バックアップ サービスのリクエストが行われた場合、メイン サービスに接続タイムアウトがあると仮定すると、このリンクでのリクエスト時間は少なくとも 2 倍になり、時間の消費は大幅に増加します。通常の状況では、サービスはデータを取得するのに 50 ミリ秒しか必要とせず、サービスのタイムアウトは通常 500 ～ 1000 ミリ秒、またはそれ以上に設定されます。タイムアウトの再試行が発生すると、必然的にリクエスト時間が大幅に増加する可能性があります。ユーザーエクスペリエンスに重大な影響を与えます。
(3) アクティブ サービスとバックアップ サービスは両方とも例外に該当します。過剰なトラフィックによってメイン サービスが異常になった場合、バックアップ サービスはこのレベルのトラフィックに耐えられずにハングアップする可能性があります。
AMS では再試行フォールト トレランス メカニズムが使用されますが、メイン サービスとバックアップ サービスの信頼性がまだ十分ではないと考えられるため、比較的まれです。

2. 異常なマシンを動的に排除または復元します

AMS では、バックエンドに何百ものさまざまなサービスが関与し、オペレーティング システム全体の通常の動作をサポートします。すべてのバックエンド サービスまたはストレージは、まずステートレスな方法でサービスを提供するために展開され (通常、1 つのサービスには多数のマシンが関与します)、その後、社内のパブリック インテリジェント ルーティング サービス L5 を通じて AMS に組み込まれます。
(1) すべてのサービスとストレージ、ステートレス ルーティング。これの主な目的は、単一リスク点を回避すること、つまり、特定のサービス ノードがクラッシュしてサービス全体が麻痺することを防ぐことです。実際、アクティブおよびバックアップの性質を持つ一部のアクセス サービス (メイン マシンがハングアップし、バックアップ マシンへの切り替えをサポートする) であっても、十分な信頼性がありません。結局のところ、マシンは 2 台しかなく、すべてがハングする可能性があります。上。通常、バックエンド サービスはマシンのグループの形式で提供され、相互に状態関係はなく、リクエストのランダムな割り当てをサポートします。

(2) 並列拡張をサポートします。大規模なトラフィック シナリオが発生した場合、容量を拡張するためにマシンを追加することがサポートされます。

(3) 異常なマシンを自動的に排除します。当社のルーティング サービスは、サービス マシンの異常 (成功率が 50% 未満) を検出すると、そのマシンを自動的に削除し、再度追加する前に正常に戻ることを確認するための暫定的なリクエストを発行します。サービスマシングループに戻ります。

たとえば、サービスのグループに 4 つのサービス マシン (ABCD) がある場合、マシン A のサービスが何らかの未知の理由で完全に利用できなくなったとします。この時点で、L5 サービスはサービスからマシン A を積極的に削除します。グループでは、外部サービスを提供するために 3 台の BCD マシンのみが保持されます。フォローアップでは、マシン A が例外から回復すると、L5 が率先してマシン A を追加し、最終的に 4 台のマシン ABCD で外部サービスを提供します。

過去 3 年間、私たちは、ハードコーディングされた IP リストやアクティブおよびバックアップ ステータスのサービスから L5 モード サービスまで、AMS のすべてのサービスを段階的にアップグレードおよび最適化し、AMS フォールト トレランスの自律性を徐々に実現してきました。少なくとも、特定のマシンのソフトウェアまたはハードウェアの障害により手動で介入しなければならない状況に遭遇したことはほとんどありません。私たちは警報に対処するという困難からも徐々に解放されつつあります。

3. タイムアウト

1. サービスとストレージの適切なタイムアウトを設定します

サービスまたはストレージを呼び出すとき、適切なタイムアウト (サービスを要求するときに最も長い時間待機するのはタイムアウトです) が非常に重要です。 , この点は見落とされがちです。通常、Webシステムとバックエンドサービス間の通信方式は同期待ちモードです。このモードでは多くの問題が発生します。

サーバーにとって、より大きな影響を与える問題は、システムのスループット レートに深刻な影響を与えることです。サービス マシンの 1 つで、リクエストの処理に 100 のワーカーが有効になっており、ワーカーのタイムアウトが 5 秒に設定されており、1 つのワーカーが 1 つのタスクを処理する平均処理時間は 100 ミリ秒であると仮定します。この場合、ワークは 5 秒間で 50 件のユーザー要求を処理できますが、ネットワークまたはサービスが時々異常になり、応答がタイムアウトになると、この処理の次の 5 秒間でタイムアウトになった失敗したタスクは 1 つの待機のみ処理されます。このタイプのタイムアウト例外が高確率で発生すると、システムのスループット レートが大幅に低下し、すべてのワーカーが枯渇する可能性があります (リソースが占有され、すべて待機状態になり、5 秒のタイムアウトまで解放されません)。利用可能なワーカーが存在しないため、例外状態にのみ陥る可能性があります。

ネットワーク通信やその他のリンクに費やした時間を含めると、ユーザーは 5 秒以上待つ必要があり、最終的には異常な結果が得られ、ユーザーの気分は通常壊れます。

この問題を解決する方法は、適切なタイムアウトを設定することです。たとえば、上記の例に戻ると、平均処理時間は 100 ミリ秒であるため、タイムアウトを 5 秒から 500 ミリ秒に短縮することもできます。直感的には、スループットの低下とユーザーの長い待ち時間の問題が解決されます。しかし、そうすること自体が新たな問題を引き起こす可能性が高く、つまりサービスの成功率の低下を引き起こすことになります。ただし、平均消費時間は 100 ミリ秒であるため、一部のビジネス リクエスト自体に時間がかかり、ほとんどのリクエストは 500 ミリ秒を超えます。たとえば、サーバーが特定のリクエストを処理するのに 600 ミリ秒かかります。このとき、クライアントは 500 ミリ秒以上待機して切断されたと考えます。このような処理に時間がかかるビジネスリクエストは大きな影響を受けます。

2. タイムアウト設定が短すぎると成功率が低下します

タイムアウトの設定が短すぎると、本来は正常に処理されていた多くのリクエストがサービスタイムアウトとして処理されるため、サービスの成功率が低下します。すべてのビジネス サービスに画一的な方法でタイムアウト期間を設定することはお勧めできません。最適化手法を 2 つの方向に分けます。
(1) 高速と低速の分離
実際のビジネスの次元に応じて、差別化された方法で各ビジネス サービスに異なるタイムアウトを設定すると同時に、それらのデプロイメント サービスを分離することが最善です。たとえば、Tiantian Kupao のクエリ サービスには通常 100 ミリ秒かかるため、タイムアウトを 1 秒に設定します。新しい携帯電話のクエリ サービスには通常 700 ミリ秒かかるため、5 秒に設定します。この場合、システム全体の成功率には大きな影響はありません。

(2) 同期ブロック待機の解決
「高速と低速の分離」により、システムの同期待機の問題は改善されますが、時間がかかる一部のサービスでは、システムのプロセス/スレッド リソースが同期を待機したままになります。このプロセスでは、他の新しいリクエストに応答できず、そのリソースは依然として占有されており、システム全体のスループット レートは大幅に低下します。

もちろん、解決策は I/O 多重化を使用し、非同期コールバックを使用して同期待機中のリソースの無駄を解決することです。 AMS の一部のコア サービスは「コルーチン」 (「マイクロスレッド」とも呼ばれます) を使用します。簡単に言うと、従来の非同期プログラム コードに複数の関数コールバックがネストされており、コルーチンは記述が複雑です。同期コード、非同期コールバック プログラムを作成して、同期待機の問題を解決します。非同期処理を簡単に説明すると、プロセスは I/O ネットワークの輻輳に遭遇したときに、シーンを保持し、すぐに次のビジネス リクエストの処理に切り替えます。さらに、プロセスはネットワークの待機のためにビジネスの処理を停止しません。システムのスループット レートは、ネットワーク待機時間が長すぎるシナリオでも、通常は比較的高いレベルに維持できます。

非同期処理はシステムのスループットの問題を解決するだけであり、ユーザー エクスペリエンスの問題は改善されず、ユーザーの待ち時間は短縮されないことを付け加えておきます。
3. 再エントリーと重複発送の防止
先ほども述べたように、比較的「妥当なタイムアウト」、つまり比較的短いタイムアウトを設定しています。データ書き込みシナリオでは、当社の AMS システムに関する限り、出荷シナリオで新たな問題が発生します。配信リクエストがタイムアウトになった場合、現時点ではさらに問題について考える必要があります。

(1) 配信待機がタイムアウトになり、配信サービスが配信を実行できませんでした。このシナリオは大きな問題ではありません。後続のユーザーはもう一度受信ボタンをクリックして、次の再配信をトリガーできます。

(2) 配信待機がタイムアウトになり、後で配信サービスが実際に配信を正常に実行します。これを「タイムアウト成功」と呼びます。さらに厄介なシナリオは、配信が毎回タイムアウトになることですが、実際には配信は成功しています。システムが適切に設計されていないと、ユーザーがギフト パッケージを無制限に受け取ることになり、最終的にはイベント運営事故が発生する可能性があります。

2 番目のシナリオでは、さらに厄介な問題が発生します。これが適切に処理されずにユーザーが再度クリックすると、2 回目の「追加」出荷がトリガーされます。

たとえば、ある配送サービスのタイムアウトが 6 秒に設定されているとします。ユーザーがリクエストを受信した後、6 秒待ってから配送サービスに商品の配送を要求します。応答がありません。ユーザーに「受け取りに失敗しました」というメッセージが表示されますが、実際には、配送サービスは 8 秒以内に配送を正常に実行し、ギフトパッケージがユーザーのアカウントに到着しました。ユーザーが「受信できませんでした」と表示されると、もう一度ボタンをクリックすると、最終的に「追加の」ギフト パッケージがユーザーに送信されます。

例のシーケンスとフローチャートは大まかに次のとおりです:

ここでアンチリエントランシーについて説明します。簡単に言えば、ユーザーが何度クレームボタンをクリックしても、確実にクレームが存在することを確認する方法です。期待される結果は 1 つだけです。つまり、ギフト パッケージをユーザーに 1 回だけ送信し、繰り返しの発送は発生しません。当社の AMS イベント運営プラットフォームは年間 4,000 件を超えるイベントを立ち上げており、さまざまな種類や異なるビジネス システムの数万のギフト パッケージの配送を伴い、ビジネス コミュニケーション シナリオは比較的複雑です。さまざまなビジネス シナリオに合わせて、さまざまなソリューションを作成しました:

(1) ビジネス レベルの制限。ギフト パッケージに単一ユーザー制限を設定します。配信サーバーの送信元では、ユーザーが受け取れるギフトパッケージは最大 1 つだけであるように設定されており、重複した発行を直接回避します。ただし、この種のビジネス制限は、すべてのビジネス シナリオに共通するものではなく、制限機能を備えた社内のビジネス配信システムにのみ限定されます。また、一部のギフト パッケージ自体は複数回受信できるため、これは適用されません。

(2) 注文番号の仕組み。ユーザーからの適格な出荷リクエストごとに、それに対応する注文番号が生成されます。これにより、1 つの注文番号は 1 回のみ出荷されることが保証されます。このソリューションは比較的完成度が高いですが、「注文番号の配送状況の更新」を行うには配送サービス当事者の協力が必要であり、そのすべてが「注文番号の更新」シナリオをサポートできるわけではありません。

(3) 自動再試行付きの非同期配信モード。ユーザーがギフト パッケージを受け取るボタンをクリックすると、Web クライアントは直接成功を返し、ギフト パッケージが 30 分以内に到着することを通知します。バックグラウンドでは、出荷は出荷キューまたは保管庫に入れられ、出荷サービスによる非同期出荷を待ちます。非同期で処理されるため、出荷が成功するまで出荷再試行操作を複数回実行できます。同時に、非同期配信では比較的長いタイムアウト待ち時間を設定することができます。通常、「タイムアウト成功」シナリオはなく、フロントエンド応答の場合、バックグラウンド配信ステータスが返されるのを待つ必要はありません。ただし、このモデルはユーザーに比較的悪いエクスペリエンスをもたらします。つまり、リアルタイムのフィードバックがなく、ユーザーはギフトパッケージが到着したかどうかをすぐに知ることができません。

4. 非注文番号に対する特別なアンチスワイプメカニズム
一部の特別な協力シナリオでは、完全に分離された独立した外部配送インターフェイスなど、二者間で注文番号に同意する方法を使用できません。注文番号について当社と合意することはできません。このシナリオに基づいて、当社の AMS は読み取りタイムアウトの数を制限することにより、ブラッシング防止メカニズムを特別に設計しました。ただし、このソリューションは繰り返し出荷の問題を完全に解決するものではなく、スワイプのリスクを最小限に抑えることができるだけです。ネットワーク通信には通常、接続の確立 (接続)、データの書き込みとパケットの送信 (書き込み)、パケットの待機と読み取り (読み取り)、および切断 (クローズ) が含まれます。

通常、配信サービスで例外が発生すると、ほとんどの場合、接続ステップが失敗するかタイムアウトになります。返信パケット (読み取り) を待っている間にリクエストがタイムアウトした場合、サービスの反対側で何かが発生した可能性があります。 「タイムアウトしたが配信は成功した」というシナリオ。このとき、読み取りタイムアウトの発生回数を記録し、制限回数を設定する機能を提供します。 2 回に設定されている場合、ユーザーがギフト パッケージを初めて受信して読み取りタイムアウトが発生したときに、2 回目の読み取りタイムアウトが発生したときに、前に設定したしきい値 2 に達するまで再試行できるようになります。無事に発送されるかもしれないと考え、ユーザーの 3 回目の集荷リクエストは拒否されます。

このアプローチでは、配送サービスで多くの成功したタイムアウトがあると仮定すると、ユーザーは最大 2 回までギフト パッケージを引き換えることができるため (回数は構成可能)、無制限にギフト パッケージが引き換えられるというシナリオが回避されます。ただし、このソリューションは完全に信頼できるわけではないため、使用には注意が必要です。

配信シナリオでは、分散シナリオにおける CAP (一貫性、可用性、分割許容度) の問題も関係します。ただし、私たちのシステムは電子商取引サービスではないため、ほとんどの配信には強い一貫性がありません。したがって、一般に、可用性とパーティションのフォールト トレランスの保証を追求するために、一貫性の問題を弱めました (コア サービスは非同期再試行によって究極の一貫性を実現します)。

4. サービスの低下、非コア ブランチ例外を自動的にシールドする

ギフト パッケージの収集リクエストの場合、バックエンド CGI は、ギフト パッケージ構成の読み取りやギフト パッケージなど、10 を超えるリンクとサービスの論理的判断を実行します。制限チェック、ログイン状況確認、セキュリティ保護などこれらのサービスの中には、ギフトパッケージの構成を読み取るサービスなど、スキップできないコアリンクもあれば、データレポートなどの非コアリンクもあります。非コア リンクの場合、私たちのアプローチは比較的低いタイムアウトを設定することです。

たとえば、統計レポート サービスの 1 つに平均 3 ミリ秒かかる場合、タイムアウトになるとタイムアウトがバイパスされ、ビジネス プロセスは通常のロジックに従い続けます。

5. サービスの分離と物理的分離

ただし、サービスの設計はできる限り小さく、個別にデプロイする必要があることは誰もが知っています。この方法では、モジュールに問題が発生しても影響を受けるモジュールが少なくなります。耐性がさらに強くなります。しかし、設計の段階から各サービスを整然と細分化していくため、設計者には事業やシステムの開発形態を事前に認識できる高度な意識が求められます。製品戦略の変化に応じてビジネスの形も変化するため、ビジネスの成長は比較的遅いことが多いです。ビジネスの初期段階では、トラフィックが比較的少ないため、サービスを詳細にセグメント化するのに十分な人員とリソースがありません。 AMS は、1 日あたり 100 万レベルの Web システム リクエストから 10 億レベルのリクエストまで徐々に成長し、その過程でトラフィックの規模は 100 倍に増加し、サービスの結合によって生じる多くの苦痛を経験しました。

1. サービスの分離、大きなサービスは複数の小さなサービスになる
卵は1つのカゴに盛ることはできないとよく言います。 AMS は以前は比較的小規模なシステムでした (毎日数百万件のリクエストがあり、Tencent 内ではまったく目立たない小規模な Web システムでした)。そのため、初期にはクエリや配信サービスなど、多くのサービスとストレージが一緒に導入されました。それらがすべて一緒になって、どれに問題があるとしても、それらは互いに影響を及ぼします。その後、これらのコアサービスとストレージを徐々に分離し、細かく分割して再配置しました。データ ストレージに関しては、当初の 3 ～ 5 個のストレージ サービスを、20 以上の独立して展開されたストレージ サービスに徐々に減らしました。

例えば、2015 年後半に、1 つのコアのストレージ データを 1 から 3 に分離しました。

これを行うと多くの利点がもたらされます:

(1) 元のメインストレージの圧力が分散されます。

(2) 安定性が向上し、そのうちの 1 つが大きなモジュール全体に影響を与える問題がなくなりました。

(3) ストレージは物理的に分離されており、サーバーのハードウェアに障害が発生しても、相互に影響を与えることはありません。
2. 軽重分離、物理的隔離
一方、一部のコア事業については「軽重分離」を実施しております。例えば、2016年「モバイルQQ春節紅包」活動プロジェクトのサービスクラスターをサポートしています。情報クエリと赤い封筒のギフト パッケージの配送を担当するクラスターは独立してデプロイされます。情報のクエリ サービスは比較的重要ではなく、ビジネス プロセスは比較的軽量ですが、赤い封筒のギフト パッケージの配送は非常にコアなビジネスであり、ビジネス プロセスは比較的重いです。 。

軽いタスクと重いタスクを分離するこの導入方法は、いくつかの利点をもたらします:

(1) クエリ クラスターに問題がある場合でも、配信クラスターには影響せず、ユーザーのコア機能が確実に維持されます。普通。

(2) 両側のマシンとデプロイされたサービスは基本的に同じであり、緊急時には、両側のクラスターが相互にサポートし、切り替えて災害復旧を実現します。

(3) 各クラスター内のマシンはコンピューター ルーム全体に展開されます。たとえば、サーバーは 3 つのコンピューター ルーム ABC に分散されていると仮定すると、コンピューター ルーム B のネットワーク全体に障害が発生すると、リバース プロキシ サービスはコンピューター ルーム B にリダイレクトします。マシンが撤去された後も、AC コンピュータ ルームに残っているサーバーは引き続き外部に通常どおりサービスを提供できます。

6. ビジネスレベルでのフォールトトレランス

システムアーキテクチャ設計レベルでの「フォールトトレランス」が完了したら、次のレベルのフォールトトレランスに進むには、実際のビジネスに基づいて行う必要があります。ビジネスが異なると、ビジネス ロジックの特性が異なるため、ビジネス レベルでさまざまな問題が発生する可能性があります。ビジネス レベルでのフォールト トレランスは、一言で言えば「人為的エラー」を回避します。どんなに慎重に慎重に物事を進めていても、うっかり「手が震える」「ミス」してしまうことは必ずあります。 AMS は、月に 400 以上のイベントを立ち上げるイベント運営プラットフォームであり、数千のイベント構成情報 (ギフト パッケージ、ルール、イベント参加ロジックなど) が含まれます。私たちのビジネスシーンでは、さまざまな理由による「ヒューマンエラー」が数多く発生します。

たとえば、ある運用学生は、ギフト パック配布の 1 日あたりの制限を読み間違え、もともと 1 日あたり 100 個のギフト パックのリリースしか許可されていなかったリソースを、1 日あたり 200 個に誤って設定してしまいました。この種のエラーは、テスト生が検出するのが困難です。実際にイベントが開始され、ギフト パックが 101 に配布されると、その日はリソース プールにリソースがないため、エラーが報告されます。当社のビジネスアラームシステムはこの異常を迅速に捕捉できますが（10分ごとをサイクルとして、各アクティビティの成功率、トラフィックの変動などを10以上の次元から監視および計算します）、しかしTencentのユーザーボリュームにとって、大規模では、たとえ 10 分以上の影響しかなかったとしても、大規模なトラフィック促進アクティビティの場合は、数十万のユーザーに影響を与える可能性もあります。この場合、重大な「ライブネットワーク事故」が発生しやすくなります。

完全な監視システムは問題を適時に検出し、影響のさらなる拡大や制御不能を防ぐことができますが、既存のネットワーク問題の発生を防ぐことはできません。もちろん、本当の解決策は、このシナリオの発生をソースから防ぐことです。上記の「日次制限設定エラー」のシナリオ例に戻りますが、ユーザーが内部管理側でアクティビティ設定を解放すると、操作担当者が直接その問題を解決します。この設定ルールは正しくありません。

業界では、設定パラメータの誤りによって引き起こされる重大な事故の例が数え切れないほどあり、業界ではほぼ困難な問題と言えます。この問題を解決または軽減する方法はありません。このようなエラーをすべて解決する万能のアプローチでは、特定のビジネスおよびシステムのシナリオに基づいて、サポートする検査メカニズムのプログラムまたはスクリプトをさらに段階的に構築する必要があります。

したがって、私たちは数十のビジネスマッチングチェックルールを統合した強力でインテリジェントな構成チェックシステムを構築しており、チェックルールの数は常に増加しています。ここでのルールには、ギフト パッケージの 1 日あたりの制限をチェックするなどの比較的単純なルールと、関連するさまざまな構成パラメータをチェックする比較的複雑なビジネス ロジック ルールが含まれます。

一方で、プロセスの実行は「口頭の合意」によって行うことはできず、たとえば、イベントを開始する前に、イベントを担当する同僚に確認を求めるなど、プラットフォームプログラムの一部として固める必要があります。 「ギフト パッケージ コレクション ロジック」。これが実際のギフト パックを入手します。ただし、これは単なる「口頭での合意」であり、実際には強制力はありません。イベントのギフト パッケージが多すぎるために同僚がギフト パッケージの 1 つを確認しなかった場合、このようなことが時々発生することがあります。これも「人為的ミス」の別のシナリオとみなされます。

この問題を解決するために、同僚の QQ 番号がすべてのギフトパッケージを確実に受け取ったことを確認するために、AMS の内部管理の手順を通じてこのプロセスが保証されています。方法は実際には非常に簡単です。アクティビティを担当する同僚にアクティビティを確認するための QQ 番号を設定させます。その後、プログラムがアクティビティを発送するときに、そのアクティビティの参加記録があるかどうかをプログラムが自動的にチェックします。各サブアクティビティ プロジェクトの QQ 番号。参加記録がある場合、この同僚はギフトパッケージをすべて全額受け取ったことになります。同時に、「口頭合意」ではなく、プログラムとプラットフォームを使用して、他のモジュールの検証とテストを確実に行います。

「人的エラー」を可能な限り防ぐために、プログラムやシステムを使用してビジネス ロジックとプロセスを確保します。

この種のビジネス構成チェッカーは、問題の発生を減らすだけでなく、実際にテストや検証作業の作業を削減し、人的資源を節約できます。しかし、業務構成チェックルールの構築は単純ではなく、誤って殺人を防ぐ必要があるため、ロジックが複雑になることも少なくありません。

7. まとめ

人であっても機械であっても「間違い」は起こりますが、一人の人間の場合、その発生確率は通常高くありません。ただし、システムに数百のサーバーがある場合、または仕事に数百人が関与する場合、そのような「間違い」が発生する確率は大幅に増加し、間違いが常態化する可能性があります。機械の障害は、システム自体によって可能な限り互換性があり、回復可能である必要があり、人的エラーはプログラムやシステムのプロセスを通じて可能な限り回避され、可能な限り「人から独立」する必要があります。

フォールトトレランスの核となる価値は、システムの堅牢性を高めることに加えて、技術者を解放することであり、アラームに対処するために朝早く起きたり、比較的普通の生活を享受したりする必要がなくなることだと思います。余暇の週末。私たちにとって、これを完全に達成するにはまだ長い道のりがあります。一緒に励ましましょう。

最新の Linux テクノロジ チュートリアル ブックを無料で提供し、オープン ソース テクノロジの愛好家のために、より良いものを提供できるよう努めます: http://www.linuxprobe.com/

posted @ 2016-05-10 13:07 これが、Linux が読み方を学ぶべき方法です (...) コメント (...) お気に入りを編集