1. システムの安定性の判断基準
安定性保証について話す前に、業界でよく言われる SLA という言葉について話しましょう。業界では、システムの安定性を測定するために SLA (サービス レベル アグリーメント、正式名: サービス レベル アグリーメント) を使用することが好まれており、インターネット企業にとっては、Web サイトとユーザーの間で定義される相互承認の契約です。
インターネット企業がスローガンを唱えているのをよく見かけますが、今年はスリーナイン、フォーナイン、すなわち99.9％、99.99％、さらにはファイブナイン、すなわち99.999％を達成しなければなりません。
年間を通じてサービスの利用可能時間を表す9が大きいほど、時間が長いほどサービスの信頼性が高くなります。標準の 99.99% を例にとると、ダウンタイムは 52.6 分で、1 週間あたりの平均ダウンタイムはわずか約 1 分です。これは、ネットワークのジッターの時間がなくなる可能性があることを意味します。
サービス安定性の計算基準は一般に、リクエストの総数 - 失敗の数 / リクエストの総数 (100-5/100 = 95% など) であり、対応するいくつかのダウンタイムを以下に示します。
1年 = 365天 = 8760小时
3个9 99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
4个9 99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
5个9 99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟2. システムの安定性向上の意義
これは非常に重要な質問だと思いますが、これほど多くの資源、時間、エネルギーを費やす目的は何でしょうか、システムの安定性を明らかにすることにどのような意義があるのでしょうか。
- 会社がより多くのお金を稼ぐことではなく、会社が損失を減らすことが重要です。(電子商取引、取引システム)
- ユーザーのシステム利用体験を向上させ、ユーザーの流出を減らす（ユーザー評価：スムーズ、ゴミ、また使う、競合製品を使う）
3. システムの安定性向上の本質
- MTTF（Mean Time To Failure）とは、システムが故障せずに動作するまでの平均時間を指し、システムが正常に動作し始めてから故障が発生するまでのすべての時間を平均した値です。MTTF =∑T1/N
- MTTR (平均修復時間) は、システムに障害が発生してから修復が完了するまでの時間の平均値を指します。MTTR =∑(T2+T3)/N
- MTBF (平均故障間隔) は、2 つのシステム故障の間の時間の平均値を指します。MTBF =∑(T2+T3+T1)/N
- 信頼性: この指標は平均故障間隔 (MTBF)、つまりコンポーネントが故障して修理が必要になるまでの時間です。信頼性の向上では、システム障害の数を減らすこと、つまり障害をまったく発生させないか、障害をできるだけ少なくすること、つまり MTTF 時間を増やすことに重点を置く必要があります。
- 可用性: 定量的な指標は、期間中にシステムが障害なく稼働する合計時間 (MTTF) です。可用性を向上するには、災害からの回復時間の短縮、つまり MTTR 時間の短縮に重点を置く必要があります。
システムの安定性の本質は、信頼性と可用性を向上させ、故障間隔 (MTTF) を延長し、故障回復時間 (MTTR) を短縮してビジネスの継続性を確保し、ビジネス損失を軽減することです。
4. システム安定性の認知トラップを改善する
このセクションでは、システムを維持するときによくある落とし穴と、認知レベルを向上させる方法について簡単に説明します。
落とし穴 1: 私のシステムは一度も事故を起こしたことがない、故障してはいけない
継続的思考:通常、人々は過去、現在、未来は連続していると考えますが、現実世界は不連続であり、連続性は単なる認知上の仮定にすぎません。人間のデフォルトの考え方は帰納法であり、その適用範囲は同じ曲線内にあり、突然変異はありません。私たちのシステムは変化するシステムであり、前提条件が確立されないと、過去から未来を一般化することはもはや有効ではありません。
認知力のアップグレード：連続的思考の限界を認識し、非連続的思考に変更し、思考の固定化を解決する
罠 2: ネットワークに問題がある、インフラに問題がある、どうしようもない、私のせいではない
失敗に備えた設計: 私たちのシステムは、ハードウェアやオペレーティング システムなどのインフラストラクチャに基づいて構築されており、ミドルウェア、データベース、ネットワーク、サードパーティ システムに依存しています。これらはすべて失敗する可能性があります。これらの依存関係に依存する必要があります。失敗に備えた設計。
コグニティブ アップグレード: すべてが失敗する可能性があり、失敗シナリオを考慮する必要があります
罠 3: 私はこれらの異常なシナリオを考慮して特別な設計を行ったので、問題ないはずです
フォールトドリル検証: すべての設計が有効かどうか、物理学や化学と同様に検証される必要があり、検証されていないものは検証されません。
信用できない。故障シナリオをシミュレーションし、発生確率、危険度、結果に応じた信頼性設計検証、ユーザビリティ設計検証を実施し、期待通りに動作することを証明する必要があります。
コグニティブ アップグレード: 設計が効果的かどうかは、フォールト ドリルによってテストする必要があります。
トラップ 4: この障害シナリオは発生する可能性が非常に低いです。
マーフィーの法則:主に 4 つの側面があります。
- 見た目ほど単純なことはありません。
- すべてが予想よりも時間がかかります。
- うまくいかない可能性のあるものは、常にうまくいきません。
- 何かが起こるのではないかと心配していると、それが起こる可能性が高くなります。
マーフィーの法則の基本的な内容は、あらゆる出来事を指します。確率がゼロより大きい限り、それが起こらないということはあり得ません。
認知機能のアップグレード:遅かれ早かれ何が起こるかを心配し、まぐれ精神に終止符を打ちましょう
罠 5: 最近はアラームがたくさんありますが、ユーザーからのフィードバックはありません。それについては数日後に話しましょう
ヘインの法則:危険な事故はすべて防ぐことができます。ヘインの法則は、航空業界における飛行の安全に関する法律です。ヘインの法則は次のように指摘しています。すべての重大な事故の背後には、29 件の軽微な事故、300 件の未遂の前兆、および 1,000 件の事故の危険があるはずです。
ヘインの法則の分析によれば、重大な事故が発生した場合、事故そのものへの対応と同時に、同様の問題を抱えた「事故」にも速やかに対処しなければなりません。
「症状」や「事故の予兆」を調査・対処し、同様の問題の再発防止、重大事故の隠れた危険性をタイムリーに解決し、問題の芽を解決します。
ヘインの法則は、第一に、事故の発生は量の蓄積の結果であること、第二に、技術がどれほど優れていても、規制がどれほど完璧であっても、実際の運用レベルでは代替できないという 2 つの点を強調しています。人自身の資質と責任感の向上
：量的なものから質的なものへ、油断するな
5. システムの安定性を向上させるための具体的な方法
上記は定番かつ意味のあるものが多く、以下は乾物ですが、自分なりの視点でまとめてみたつもりです。
6. まとめ
システムは高速で走行する車のようなものです。いつでも新しい要件や新しい問題が私たちを待っています。問題を解決するためにこの高速の車を停止させることはできません。したがって、問題を修正できるのは問題が発生したときにのみです。実行中、これは非常に危険な操作であるため、失敗しないようにあらゆる面で適切な作業を行う必要があります。システムの安定性の向上は一夜にして起こるものではなく、長期的なプロセスであるため、リラックスせずに時間内に問題を解決してください。
こちらは裏山の方で、私は目の前のお客様です。酔ってジンゲの本の半分を踊り、井戸に座って空の広大さについて話します。汚い文章ですみません！