私はリスクの予防と管理が大好きなLeyangです。以前は、0から1までAnt Glocalサイトの建設と高可用性の構築に参加し、現在はAntSecurityの高可用性の構築に参加しています。ドメイン、BG、サイトのいずれであっても、スコープは大小、オブジェクトは異なりますが、高可用性の概念は同じです。今日は高可用性について考え、まとめます[nPRT式]シェアみんなと一緒に。
この記事では、「高可用性とは何か、なぜ高可用性であるのか、その方法、なぜそれを行うのか、そしてソフトウェアのリスクはどこにあるのか」という論理を紹介します。
高可用性はリスクを制御する能力です
高可用性は、システムがリスクを制御し、より高い可用性を提供できるようにするリスク指向の設計です。
第二に、なぜ高可用性なのか
企業にとって、「高可用性が必要な理由」は、「企業が（システム）高可用性を必要とする理由」として完全に理解できます。会社を対象として、内部からは人、ソフトウェア（モノ）、ハードウェア（モノ）、外部からは顧客、株主、社会、独自の観点からは以下が含まれます。 ： 会社。
高可用性の大前提：すべてが100％信頼できるわけではありません
- すべてが変わります（唯一の定数は変化です）。
- すべての変更が100％信頼できるわけではありません。
- 結論：すべてが100％信頼できるわけではありません。
内部原因：人や物は100％信頼できるわけではありません
- 人間のレベルから：人々は間違いを犯す可能性があります。
- ソフトウェアレベルから：ソフトウェアにはBUGがある可能性があります。
- ハードウェアレベルから：ハードウェアが壊れている可能性があります。
確率論的な観点から、エラーの可能性がある場合、変更の数が十分に多い限り、エラーの確率は最終的に無限に1になる傾向があります。
外部の原因：高可用性がなく、外部からの影響が大きい
- 顧客の観点から：高可用性がないと、顧客サービスが中断される可能性があります。
- 株主レベルから：高可用性がなければ、株価が下落する可能性があります。
- 社会的観点から：高可用性がなければ、社会秩序が影響を受ける可能性があります。
根本原因（必須）：リスクの管理
会社自身の観点から：リスクを管理し、会社の価値を保護し、ファンダメンタルズを傷つけないようにします。
高可用性を実現する3つの方法
高可用性を実現する方法は、本質的にはリスクを制御する方法です。
1リスク関連の概念
- リスク：将来的に危害が発生する可能性を指しますが、実際には発生しておらず、rとして記録されています。
- 失敗：ハザードが発生した、または発生しているという事実を指し、リスクが現実のものになった結果です。
- リスク確率：リスクが失敗する確率を指します。これを使用して、リスクを失敗としてトリガーすることの難しさをP（r）で表します。
- 故障の影響範囲：単位時間内の故障によって引き起こされる危険な衝撃を指し、R（r）で表されます。
- 障害の影響期間：T（r）で表される障害の期間を指します。
- 断層影響面：断層影響範囲に断層影響時間を掛けた合計を指します。ここでは、断層衝突面を使用して、F（r）で表される断層の総損傷度を表します。
- リスクの期待：各リスクが失敗する確率に、失敗後の各リスクの影響の合計を掛けたものを指します。ここでは、リスクの期待値を使用して、リスクの潜在的な危害の程度を表し、E（r）で表されます。
2リスク予測の公式
前のセクションの定義によれば、リスク期待の式は次のように導き出すことができます。
rはリスクを表し、各リスクのリスクnおよびP、R、Tの数が減少すると、リスクの期待値は減少します。これは、nPRT式と呼ばれます。
注：式を引用する場合は、出典を示してください。
3リスクを管理する4つの要素（nPRT）
リスクの数を減らす、n
ソースからのリスクに近づかないようにして、リスクキャリアに接続または関連しないようにします。リスク確率は0であり、リスク発生後の障害の影響が大きいか小さいかは関係ありません。まったく気にしません。
- 例：主要な休日のイベントの場合、ネットワークのサイト全体の閉鎖を実装すると、変更の数が大幅に減少します。これは、リスクの数の一般的な減少です。
- 例：システムAはOracleにまったく依存していないため、システムAはOracleのリスクを気にする必要はありません。米国大統領が突然かつ緊急にOracleの中国での使用を禁止すると発表したとしても、システムAは関係ありません。
- たとえば、最近の新しい王冠の大流行、人から人への感染はひどいものです。今日仕事に行かないことを選択した場合、今日外の歩行者や同僚に感染することを心配する必要はありません。
リスクが失敗する可能性を減らす（つまり、リスクが失敗する可能性を高める）、P
リスクをオブジェクトとして扱い、さまざまなレベルでカードを設定して、リスクが失敗するしきい値と難易度を上げます。「誤ってスペースや文字を追加すると、システムがハングする」という悲劇が簡単に発生しないようにしてください。
- 例：個人BがシステムCに変更を加えたい。個人Bに変更認定試験を追加し、変更されたコンテンツのオフライン（またはシミュレーション）テストを要求し、変更されたコンテンツのCRを要求できます。システムCはプレビュー機能を提供します。変更の影響（監視モードや試用操作と同様）、Bさんが悪意を持って変更して破壊したい場合は、家族以外のレビューを追加したり、システムCで保護のためのエラー防止設計を追加したりできます。
- たとえば、新しいクラウンを例にとると、マスクを着用し、頻繁に手を洗い、換気を増やすことで、新しいクラウンが収縮する可能性を減らすことができます。
障害の影響の範囲を縮小します、R
全体をN個の小さな個体に分け、それぞれを隔離し、一人の個体に問題が発生した場合、一人の個体だけが影響を受け、小さくて美しいものを実現します。
- たとえば、分散アーキテクチャはこのモデルであり、集中アーキテクチャはすべてを失い、分散アーキテクチャはN損失の一部を失います。
- 例：新しい王冠を例にとると、グリッド管理、州または都市の流れの制限、州間の核酸+ 14日間の分離、新しい王冠の広がりの効果的な制御。
障害の影響の期間を短くする、T
断層衝突の持続時間は、断層発見時間と断層止血時間によって決まるため、早期発見と早期止血が必要です。
検出方法は、プレアラームとポストアラームに分けられます。可能な限り早期の警告を出し、止血のための時間を購入し、クレードルのリスクをなくすようにしてください。
止血方法は、切り替え、ロールバック、拡張、ダウングレードまたは電流制限、BUG修復などに分けられます。障害が発生した場合、最優先の原則は急速な止血（切り替え、ロールバック、拡張など）であり、根本原因を特定することは固く禁じられています。出血をすばやく止めることができない場合、2番目の優先原則は出血を減らすことです。ダウングレードやフロー制限など。
止血効率：自動対手動;ワンキー対マルチステップ操作。手動操作の代わりに可能な限り自動化を使用してください。手動操作を実行する場合は、止血の速度を向上させるためにワンキー操作を実現するようにしてください。
- 例：容量水位については、早期警戒線の前に早期警戒線を引いて、早期警戒を行い、落ち着いて対応することができます。
- 例：分散アプリケーションクラスターでは、いずれかのアプリケーションサーバーに問題がある場合、ロードバランサーはハートビートチェックによって問題のあるアプリケーションサーバーを自動的に削除し、要求を他の（ホットな）冗長サーバーに転送します。
- 例：新しい王冠を例にとると、それぞれの人生は独特であるため、切り替える方法、ロールバックする方法、ダウングレード（人道主義を含む）はなく、適切な薬だけをゆっくりと治療することができます。
4高可用性アーキテクチャ設計の7つのコア原則
nPRTの公式によると、高可用性アーキテクチャを設計する場合、次の7つのコア原則があります。
依存度が低いという原則：独立できる人は、できるだけ依存しないでください。依存度が低いほど良いです（n）
すべてが100％信頼できるわけではないので、2つのものが関係していると、お互いに影響を及ぼし、お互いにリスクを伴い、一方の問題が他方に影響を与える可能性があります。ここでは、依存関係を一律に使用して「関係」を参照します。
- 例：Oracle、Mysql、OBの3つのリレーショナルデータベースに同時に依存するシステムの場合、依存度を下げる原則は、OracleとMysqlではなく、最も成熟した安定したOBのみに依存することです。
どのシナリオが複数依存に適していますか？
依存関係の導入（nが大きくなる）により、1つ以上のPRTが減少し、E（r）が全体として減少する可能性があります。
- 例：DBリスクを解決するために、分散キャッシュが導入されました。2つが同時に存在しない限り、それは引き続き使用可能です。
弱い依存の原則：依存している必要があり、可能な限り弱いほど、弱いほど良い（P）
物事は物事bに強く依存し、bに問題が発生すると、aに問題が発生し、すべてが失われます。
したがって、強い依存関係は可能な限り弱い依存関係に変換する必要があります。これにより、問題の可能性を直接減らすことができます。
- 例：トランザクションコアリンクは、トランザクションが成功した後、ユーザーにポイント権限を発行する必要があります。トランザクションコアシステムは、ポイント権限システムに依存する必要があります。弱い依存関係を使用し、非同期メソッドを使用することをお勧めします。権利システムが利用できない、高い可能性がありますコアトランザクションリンクに影響を与えません。
分散の原則：エッグインザバスケットに入れないで、リスクを分散させます（R）
分割してNの部分に分割します。全体的な状況が1つの部分にすぎないようにします。そうしないと、問題が発生した場合の影響範囲は100％になります。
- 例：すべてのトランザクションデータは、同じライブラリの同じテーブルに配置されます。ライブラリがダウンしている場合、この時点ですべてのトランザクションが影響を受けます。
- たとえば、同じ株を全額で購入する場合、その株がLeEcoであると悲惨なことになります。
均衡の原則：リスクを均等に分散し、不均衡を回避する（R）
N個のシェアのそれぞれのバランスをとることが最善です。大きすぎる特定のシェアは避けてください。そうしないと、大きすぎるシェアに問題がある場合に影響範囲が大きくなりすぎます。
- 例：1000 xxのアプリケーションクラスターがありますが、排水コンポーネントのBUGにより、すべてのトラフィックが100に導かれ、負荷の深刻な不均衡が発生し、最終的に負荷によって完全に崩壊します。同様の大きな障害が何度も発生しています。
- 例：私はすべてのお金で10株を購入し、そのうちの1株が99％を占めました。この株がLeEcoであるとしたら悲惨です。
隔離の原則：拡大せず、拡大せずにリスクを管理する（R）
各コピーは互いに分離されています。他のコピーに影響を与える問題があるコピーを回避することにも問題があり、影響の範囲が広がります。
- 例：トランザクションデータは10個のデータベースと100個のテーブルに分割されますが、同じ物理マシンにデプロイされます。特定のテーブルの大きなSQLがネットワークカードをいっぱいにすると、10個のデータベースと100個のテーブルが影響を受けます。
- 例：私はすべてのお金を分割して10株を購入し、それぞれが10％を占めましたが、10株はすべてLeTVからのものでした。
- 例：古代のちびの戦いは典型的な否定的な例です。鎖でつながれた船によって引き起こされた孤立は破壊され、80wの軍隊は大火事で焼かれました。
分離のレベルがあります。分離レベルが高いほど、リスクを分散するのが難しくなり、災害耐性が強化されます。
- 例：アプリケーションクラスターはN台のサーバーで構成され、同じ物理マシン、同じコンピュータールームの異なる物理マシン、同じ都市の異なるコンピュータールーム、または異なる都市に展開され、異なる展開は異なる災害を表します公差機能。
- 例：人間は同じ地球の異なる大陸に住む無数の人々で構成されています。これは、人間が惑星レベルで孤立する能力を持っていないことを意味します。地球が壊滅的な影響を与えるとき、人間は能力がありません。耐災害性。
分離の原則は非常に重要な原則であり、前の4つの原則の前提です。適切に分離しないと、最初の4つの原則はすべて脆弱であり、リスクは簡単に広がり、最初の4つの原則の影響を破壊する可能性があります。実際のシステム障害の多くは、分離が不十分なために発生します。たとえば、オフラインはオンラインに影響し、オフラインはオンラインに影響し、プレリリースは本番環境に影響し、SQLの破損はデータベース全体（またはクラスター全体）に影響します。
分散化、バランス、および分離は、リスクの範囲を制御するための3つのコア原則です。N個の部分に分割して分割し、各部分は互いにバランスが取れて分離され、1つの部分は問題があり、影響範囲は1 / Nです。
シングルポイントの原則はありません：（T）を返す方法があるように、冗長性または他のバージョンが必要です
ブリーディングを停止する簡単な方法は、切り替え、ロールバック、拡張などです。ロールバックと拡張は特別な切り替えです。ロールバックとは特定のバージョンへの切り替えを指し、拡張とは新しく拡張されたマシンへのトラフィックの切り替えを指します。
切り替えにはそれをカットする場所が必要であるため、単一のポイントは存在できず（ここでは、特に強い依存関係を持つ単一のポイントを指し、弱い依存関係はダウングレードできます）、冗長バックアップまたは他のバージョンが必要です。単一のポイント全体的な信頼性が制限されます。
シングルポイントの信頼性を99.99％とすると、99.999％に上げるのは非常に難しいですが、シングルポイントがなく、2つに頼っている場合（電話を切っても、電話を切らない限り関係ありません）。同時にハングアップ）、全体的な信頼性セックスは99.999999％であり、質的な改善があります。
単一障害点では、出血をすばやく止められず、止血時間が長くなります。単一障害点に到達することは非常に重要です。ここでの1つのポイントは、システムノードだけでなく、アラームをサブスクライブする人や緊急要員などの担当者も含みます。
（重要な）データノードの場合、単一ポイントがないという原則を満たす必要があります。そうしないと、極端な条件によって永続的なデータ損失が発生し、復元できなくなります。（重要な）データノードが単一ポイントなしの原則を満たした後は、データの整合性が向上します。可用性要件よりも重要です。
- 例：マーチャントは、通常のシングルポイントである1つの支払いチャネルのみをサポートします。この支払いチャネルがハングアップすると、支払いができなくなります。
- 例：家族のすべての収入は、1人の父親の給与収入のみに依存します。父親が病気になった場合、収入はありません。
シングルポイントの原則と分散型の原則に違いはありません。
- ノードがステートレスの場合、ノードは分割されてN個の部分に分割されます。各部分は同じ機能を持ち、互いに冗長です。つまり、ノードがステートレスの場合、分散化の原則と単一点がないという原則です。同等であり、1つは満足しています。
- ノードに状態がある場合、ノードは分割されてN個の部分に分割されます。各部分は異なります。各部分は冗長ではありません。各部分に対して冗長性を作成する必要があります。つまり、ノードが状態にある場合、両方が満たされます。分散の原理は、単一点の原理を満たす必要があります。
自己防衛の原則：流血を減らし、一方の部分を犠牲にし、もう一方の部分を保護する（P＆R＆T）
外部入力は100％信頼できるわけではなく、意図しないエラーである場合もあれば、悪意のある損傷である場合もあるため、外部入力にはエラー防止設計が必要であり、保護を強化する必要があります。
極端な場合、出血を（迅速に）止めることができない場合があります。出血を減らし、一方の部分を犠牲にしてもう一方の部分を保護することを検討できます。例：電流制限、ダウングレードなど。
- たとえば、プロモーションのピーク期間中は、多くの機能が事前にダウングレードされるのが一般的ですが、同時に現在の制限は、主にピーク時のほとんどの人のトランザクション支払いエクスペリエンスを保護するためです。
- たとえば、人体が失血したり痛みを感じたりすると、ショックが引き起こされます。これは、典型的な自己防衛メカニズムでもあります。
ソフトウェアのリスクはどこにありますか？
リスクを管理する方法は以前に紹介されましたが、ソフトウェアシステムの分野に戻ると、リスクはどこにありますか？
ソフトウェアシステムをオブジェクトとして、内部からはコンピューティングシステムとストレージシステム、外部からは人員、ハードウェア、アップストリームシステム、ダウンストリームシステム、および（暗黙の）時間が含まれます。
各オブジェクトは他のオブジェクトで構成されているため、各オブジェクトをさらに分解することができます（理論的には無期限に分解できます）。上記の分解方法は、主に理解を簡単にするためのものです。
1ソフトウェアシステムのリスクの原因
リスクは（危険な）変化から生じ、オブジェクトのリスクはそれに関連するすべてのオブジェクトの（危険な）変化から生じます。したがって、ソフトウェアシステムのリスクの原因は、次の7つのカテゴリに分類されます。
計算システムの変更：動作が遅い、動作エラー
システムが依存するサーバーリソース（CPU、MEM、IOなど）の負荷、アプリケーションリソース（RPCスレッドの数、DB接続の数など）、ビジネスリソース（ビジネスIDがいっぱい、バランスが不十分、不十分なビジネスクォータなど）システムの運用に影響を与えるリスクの予想。
ストレージシステムの変更：動作の遅延、動作エラー、データエラー
システムが依存するサーバーリソース（CPU、MEM、IOなど）、ストレージリソース（同時実行性など）、データリソース（単一のライブラリ容量、単一のテーブル容量など）の負荷とデータの一貫性が影響しますストレージシステムの運用リスクの予想。
人間の変化：変化の誤り
変更担当者の数、安全意識、習熟度、変更の数、変更の方法などはすべて、変更のリスク期待に影響を与えます。
変化する人の数と変化の数が多いため、変化はアリの失敗のすべての原因の中でトップ1になりました。そのため、「3軸の変化」は非常に有名です。
「3つの軸を変更する」の正しい順序は「グレースケール、監視可能、および緊急」である必要があります。グレースケールはRを表し、監視可能および緊急対応はTを表します。
思考：3つの軸を変更して別の軸を追加する場合、それはどうあるべきだと思いますか？
ハードウェアの変更：破損
ハードウェアの量、品質、耐用年数、メンテナンスなどは、ハードウェアのリスク予想に影響を与え、ハードウェアの損傷は、上位のソフトウェアシステムが使用できなくなることに影響を与えます。
上流の変更：リクエストが大きくなる
リクエストは、ネットワークトラフィック（無数のAPIで構成）、API（無数のKEYリクエストで構成）、およびKEYの3つの次元に分けられます。
- 過剰なネットワークトラフィックはネットワークの輻輳を引き起こし、ネットワークチャネル内のすべてのネットワークトラフィック要求に影響を与えます。
- APIリクエストが多すぎると、対応するサービスクラスターが過負荷になり、サービスマシン全体のすべてのAPIリクエストに影響し、さらには分散します。
- 過剰なKEY要求（一般に「ホットKEY」として知られている）は、単一のマシンを過負荷にし、単一のマシン上のすべてのKEY要求に影響を与え、さらには分散させます。
したがって、保護を促進するときは、コアAPIの容量保証だけでなく、ネットワークトラフィックとホットスポットKEYも考慮する必要があります。
ダウンストリームの変更：応答が遅い、応答が間違っている
ダウンストリームサービスの数、サービスレベル、サービスの可用性などは、ダウンストリームサービスのリスクの期待に影響を与えます。ダウンストリーム応答が遅いとアップストリームが遅くなる可能性があり、ダウンストリーム応答エラーがアップストリームの動作結果に影響を与える可能性があります。
時間の変更：時間切れ
時間の有効期限は見過ごされがちですが、突然でグローバルに破壊されることがよくあります。期限が切れて障害が発生すると、非常に受動的になるため、事前に特定し、キーの有効期限、証明書の有効期限、コストの有効期限、クロスタイムゾーン、クロス年、クロス月、クロス日など。
- 例：2019年、日本のオペレーターであるソフトバンクは、証明書の有効期限が切れたため、3000wユーザーに対して4時間の通信中断を引き起こしました。
上記の主要なタイプのリスクはそれぞれ、nPRT式に基づいて1つずつ分析および処理できます。
2リスクの数：1つの人生に3つ、すべてのものに3つ
あらゆるものは他のもので構成されているだけでなく、他のものの構成要素でもあり、無限に循環します。1つの生命3、3つの生命すべてのもの、リスクの数は無限大です。
内面を見ると、内容は無限に小さい可能性があります。原子粒子サイズの問題が広がると、100ナノメートルの新しいコロナウイルスが人体の使いやすさに影響を与えるのと同じように、ソフトウェアシステムの使いやすにも影響を与える可能性があります。
外を見ると、外があり、それは無期限に続く可能性があります。太陽系が破壊されると、ソフトウェアシステムの可用性は自然に存在しなくなります。
リスクは無限大ですが、リスクをよりよく理解し、リスク管理のいくつかの概念と原則に基づいている限り、リスクの期待をより適切に減らすことができます。
畏怖の心について話す：
- 私たちの世界に関する知識は限られているため、恐れは少なくなりますが、畏怖の念を起こさせることも少なくなります。
- 私たちが本当に恐れたいのは、罰則ではなく、私たちが知らないこと、そして私たちが知らないこと、私たちが知らないことです。
5つの結論
- すべてが変わる。
- 100％信頼できるものはありません。
- したがって、リスクがあります。リスクは見えませんが、障害は見えます。
- リスクは光を排除することはできませんが、それを遠ざけて減らすことはできます。
- 故障は避けられませんが、延期、衝突範囲の縮小、衝突時間の短縮が可能です。
nPRTの公式は、ソフトウェアシステムのリスクだけでなく、他のリスク領域にも適用できます。すべての人に役立つことを願っています。
この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。