99.9%のアップタイム保証は、1年あたり約8.76時間のダウンタイムを許容します。99.99%の場合、52.56分しかありません。この約束は、測定ウィンドウ、ダウンタイムの式、除外事項を知っている場合にのみ意味があります。ヘッダーの単純なパーセンテージだけでは、ユーザーが経験することについて何も教えてくれません。
通常、問題がすでに発生しているのを見てから、ダウンタイムの原因を調べます。ライブアップデートがリリースされない、サポートが各地域から同じ苦情を受け始める、そしてチームの誰かが、ベンダーのSLAがダウンタイムをカバーするか、プレゼンテーション用のスライドにしか見えないかどうかを尋ねることがあります。
目次
- ライブアップデートプラットフォーム向けアップタイム保証の重要性
- 可用性階層の背後にあるアップタイムの計算
- SLAの細かい部分を読む:実際に重要な要素
- ライブアップデートプラットフォーム向けの実用的なアップタイム目標
- 監視と可観測性のベストプラクティス
- Capgoのアーキテクチャが高可用性をサポートする方法
ライブアップデートプラットフォーム向けの高可用性保証の重要性
金曜日の午後、セキュリティ修正が必要な時、更新パスが利用できないと発見すると、最悪の時です。アプリはまだユーザーの手の中にあり、問題はまだ発生中、そして修正が必要な人々は修正を受け取ることができません。そのため、高可用性保証は 実際の運用、理論的な運用ではなく、モバイルチームがJavaScript、CSS、config、またはアセット修正をライブアップデートプラットフォームを通じて配信する場合に不可欠です。 IT専門家が頭を抱えているストレスのある男性の姿が表示される。彼のラップトップ画面に表示されているデータベース接続エラーの画面。
実用的なルール:
ユーザーが安全、法的、または機能的に安全に更新を必要とする場合、更新チャネルはクリティカルパスにあります。 __CAPGO_KEEP_0__のアーキテクチャが高可用性をサポートする方法
このことはなぜ大切なのかは、ライブアップデートプラットフォームがリリースとユーザーとの橋渡しをしているからです。 その橋が故障すると、便利さを失うだけではありません。 事件ループを閉じる能力を失うことになります。 これは、ストアレビューの遅延がすでにあなたを遅らせている場合に特に痛いです。 その理由は、ライブアップデートの目的は遅延を減らすことであり、代わりに別のボトルネックを置くことではないからです。 休止プレイブックは、配信パスが到達可能な限り、しか動作しません。 したがって、チームは、インシデント回復計画とプラットフォームの可用性を紐づけるべきです。 例えば、インシデント対応ガイドのようなものです。 強力なSLAは、シンプルな運用上の質問に答えるべきです。 プラットフォームは、チームがそれを必要とするときに修正を提供できるか、または、プロバイダーのダウンタイムの定義に外れた場合に、約束が消滅するのか? その区別は、保証がアプリケーションをサポートするか、単に契約を装飾するだけかを決定します。.
可用性階層の裏側にあるアップタイムの数学を理解する
99.9%のアップタイム
約8時間80分 1年あたり約52分54秒 99.99%のアップタイム 約5時間20分 1年あたり約55分12秒 99.99% 99.999%のアップタイム 約0時間5分35秒1年あたり約5分35秒 99.999% 年間ダウンタイムは約 5.26 分 月間予算は約 43.8 分, 4.38 分、そして 26 秒 （それぞれ「アップタイム保証の計算方法」参照）1 つの追加の 9 は運用モデルを変えるだけでなく、Marketing コピーを変えるだけです。差は線形ではありません
多くのチームが「4 つの 9」に耳を傾けると、3 つの 9 よりもわずかに改善されたと考えていますが、実際にはそうではありません。月間ダウンタイム予算は約
4.38 分から約 43.8分 99.9%の範囲で約 4.38分 99.99%の範囲で。 これは、通常はより良いホスティングで耐えることができるダウンタイムの10倍に近い。 これには、冗長性、速い検出、そしてシステムがすでに負荷がかかっている状態でも機能するフェイルオーバーが必要です。
データセンターの階層ベンチマークでも同じパターンが見られます。 Tier I ダウンタイムや 99.671% 年間約28.8時間 Tier II と Tier III は 99.741% そしてについて 22時間, Tier III と 99.982% そしておおよそ 1.6時間, そして Tier IV と 99.995%, これはほぼ 26.3分 年間 (データセンター階層ベンチマークTier IIIからTier IVへのジャンプは、ダウンタイムを時間から分に変えるような大きな変化です。
| 稼動率 | 月間ダウンタイム | 年間ダウンタイム | Tierレベル |
|---|---|---|---|
| 99.9% | 43.8分 | 8.76時間 | 標準基準 |
| 99.99% | 4.38分 | 52.56分 | 高可用性 |
| 99.995% | 26秒 | 5.26分 | 極度の可用性 |
ライブアップデートプラットフォームでは、その計算は重要です。リリースウィンドウは短く、緊急性が高いため、サービスが10分遅れてデプロイメントウィンドウを逃した場合、ユーザーが最も修正が必要な時期に修正を提供できない可能性があります。チームは、ロールアウトの健康と同じ規律で、数値を接続する必要があります。 アプリケーションヘルスモニタリング.
読み間違いしないSLAの重要な要素
2つのプロバイダーが同じアップタイムパーセンテージを発表しても、実際の生産環境では非常に異なる結果を生み出す可能性があります。契約は、ホームページではなく、約束の場所にあります。 uptimeガارانティが意味をなすには、3つの要素が一致する必要があります。測定ウィンドウ、ダウンタイムの式、除外事項。 測定ウィンドウから始めましょう サービスは、プロバイダーが粗い期間を隠すようにウィンドウを選択した場合、紙上では信頼できるように見えるかもしれません。1つのSLAの例では、uptimeを1年間で測定します。
ダウンタイムの式
サービスは、ダウンタイムの式を選択することで、ダウンタイムの期間を制御できます。ダウンタイムの式は、サービスがどれだけの時間をダウンタイムに費やすかを決定します。 90日間のローリングベース 利用している独立した合成監視ツールを使用して、利用可能性を評価し、より正確なコミットメントを提示します。SLAの例と測定ルールメトリックの測定方法を明らかにしない場合、パーセンテージを信頼するのは難しいです。
ウィンドウは重要です。ダウンタイムは月単位で報告され、請求も月単位で行われます。ダウンタイムは長期間にわたって平均化される場合もあります。サービスが月末に更新サービスが失敗し、翌月の初めに復旧した場合、SLAの報告方法はダウンタイムの表示方法を変える可能性があります。契約では、数字を操作するための余地を排除したいと思います。
ダウンタイムの定義を確認してください。
利用可能な数値は、ダウンタイムの式にしかるべきです。あるSLAでは、サービスが利用可能な分数を月の合計分数で割り、重要なリクエストまたはコア機能に影響を与えるダウンタイムのみをサービスダウンタイムとしてカウントします。このような定義では、すべての小さな一時的なエラーを完全なダウンタイムとしてカウントしないように避けますが、サインする前に「重要」な意味を知る必要があります。最も高価なSLAの間違いは、サービス提供者のダウンタイムの概念が自分のダウンタイムの概念と一致していないことを想定することです。
除外は約束を消去します。
実際の契約では、予定されたメンテナンス、顧客側のエラー、強制的な出来事、あるいは第三者のダウンタイムが除外されることがよくあります。
SLAの間違いは、サービス提供者のダウンタイムの概念が自分のダウンタイムの概念と一致していないことを想定することです。SLAの例と測定ルールSLAが悪くなるのではなく、SLAが具体的になるのです。問題は、チームが数字を買うのではなく、その数字が何をカウントするのかを理解していない場合、実際に発生するような障害の際に、保証が適用されないことが発生することです。
SLAの意味合いSLAの指針サービスレベルアgreementの指針
契約書が障害の回復方法を説明していない場合、信頼性を購入しているのではなく、ラベルを購入していることになります。 Capgo’s multi-region deployment approach __CAPGO_KEEP_0__のマルチリージョン展開アプローチ
ライブアップデートプラットフォームのためのリアリティなアップタイム目標
ライブアップデートプラットフォームの場合、正しい目標は、重要な修正を頻繁にリリースし、ユーザーが許容できる障害の度合いに応じて異なります。 3つの9 低リスクのワークフローでは、3つの9は許容可能ですが、更新がインシデント対応、顧客信頼、または規制業務に含まれる場合、快適ではありません。修正が急務なほど、プラットフォームは容認できません。
Three nines はよく誤解されるデフォルト
99.9% と 99.99% の間の差は、偶発的な障害を吸収できるプラットフォームと、意図的に耐性を確保する必要があるプラットフォームの差です。実際の差は、月間ダウンタイムの予算で明らかです、約 43 分 versus 4 分 (可用性階層の計算リリースプロセスが狭い時間枠に依存している場合、下位階層は過度に強い道具になります。
特に、既に発生しているインシデントの場合、耐障害時間が数分しかない配信プラットフォームは、ロールバック、ホットフィックス、または構成変更が実行できる時刻を逃す可能性があります。その場合、SLA は運用上の耐性を反映すべきであり、提供者の最安値のサポート階層を反映すべきではありません。
見落とされやすいヘッドラインのコミットメントを探してください。
最近の SLA の作成の傾向は、ローリング ウィンドウ、月間報告、比例サービス クレジット、責任上限などです。これは、買い手がより具体的な運用上の保証を求めていることを示しています。SLA の作成の傾向に関するコメントSLA の作成の傾向
契約の重大性も、失敗後のパスを示します。クレジットはロールアウトが破損した場合に元に戻すものではありませんが、サービス動作の測定可能な行動に補償を結び付けるかどうかを明らかにします。企業レベルでは、インシデントをサポートするプラットフォームと、インシデントの一部になるプラットフォームの差は、よくあります。
アーキテクチャを評価するチームにとって、この決定の際に、多地域配信は設計要件として扱う価値があります。理由は単純です。システムが冗長性を設計するほど近い場合、各ローカルな失敗は重要性が低くなります。これは、多地域展開の論理と同じです。 多地域展開.
決定テスト: 緊急リリース中にダウンタイムが手動ワークアラウンドを必要とする場合、uptime目標は確かに低すぎます。
監視と可観測性のベストプラクティス
uptime保証 uptime保証は、外部から検証できる場合にのみ意味があります。プロバイダーのダッシュボードは役立ちますが、独自の監視はより難しい質問に答える必要があります。ユーザーが更新を受け取ることができるか、ロールアウトの試行が完了することができるか、回復が進むことができるか、途中で止まらないか? 最強の監視設定では、サービス利用可能性と顧客の影響を一緒に表示します。インシデントは、サポートバックログに変化する前に、明らかになります。 セキュリティ専門家が、グローバルサーバー状態、ネットワークトラフィック、リアルタイムシステムパフォーマンスデータを表示する複数の画面を監視しています。
Verify from the outside, not just inside your network
内部の健康チェックでは、ユーザー側の視点を提供することができない。内部のチェックでは、自分のシステムが生きていることを確認できるが、更新パスが実際のデバイスからアクセス可能であることを証明することはできない。 そのギャップは重要である。サービスステータスが正常であると報告できるプロバイダーは、顧客にとって配信パスが失敗している可能性がある。
各デバイスのログ、バージョン履歴、採用、失敗メトリクスを追跡して、更新がのみ公開されたか受信されたかを判断できるようにする。チャンネルガードレールも重要である、特にベータ、ステージング、プロダクション、または顧客固有のストリームにプッシュしている場合。 その制御は、意図されたグループを超えて広がる前に悪いリリースを止めるのに役立つ。
回復を測定するだけでは十分ではない。
利用可能な数値は単独で隠すことが多い。 速い回復を実現できるプロバイダーは、粗いアップタイムパーセンテージが似ている場合でも、ビジネスへの影響を制限できる。 したがって、MTTRはダッシュボードに並べるべきである。 それが検出速度と修復速度が、スライド上のきれいなパーセンテージよりも多くの場合に重要であるためである。
実用的なルール: サービスが稼動していることを監視のみで知る場合、リリースオペレーションでは十分ではない。
サポートにフラッシュする前に、クリーンなアラート設定は配信失敗、ロールアウトが止まっている、採用が異常に低下しているなど、サービス全体のダウンタイムのみを監視するのではなく、監視するべき点を観察する必要がある。 .tightな運用モデルを望むチームにとって アプリケーション観測性 は、一般的なアップタイムバッジよりも有用である。
Capgoのアーキテクチャは高uptimeをサポートする
アーキテクチャはuptimeの約束が現実的かどうかを決める。Capgoの配信モデルは、300以上の都市で展開されたグローバルエッジネットワークを使用し、 地域に依存しないようにし、更新トラフィックをユーザーに近づける変更されたファイルのみを差し替えることで、リリースはパッケージ全体を送信するのではなく、データの移動が少なくなる。自動ロールバック保護も、リリースが不正行為を起こした場合にチームが安全に回復できるようにする。
実際の利点は、運用上のものであり、外観上のものではない。署名されたウェブパッケージは、JavaScript、CSS、コピー、設定、資産の修正を、ストアのレビューの遅延を待たずに、チームが配信することができる。型付きのTypeScript APIとCI/CDの統合も、リリース作業がダウンタイム中に遅延するのを防ぐ。
監視の利点もある。Capgoのデバイスごとのログ、採用メトリック、失敗の追跡、バージョン履歴、チャンネルガードレールは、サポートとエンジニアに、ロールアウトが成功しているか、立ち往生しているかを判断できる証拠を提供する。そうした視覚化は、不明瞭な「アップデートは出ているか？」の質問を実行可能なものに変える。
回復の話も重要だ。 __CAPGO_KEEP_0__の災害復旧ガイド は、自身のアーキテクチャと組み合わせる価値があります。なぜなら、高可用性は、デプロイメントが失敗した場合の対応計画も必要だからです。以下の動画は、プラットフォームをその背景で紹介しています。デプロイメントパスとその周辺の運用コントロールを関連付けるのに役立ちます。
現在、SLA交渉中ですか? その場合、プロバイダーの約束を、実際のデリバリーパス、リカバリツール、インシデント発生時の可視性と比較してください。Capgoは、ライブアップデート、ロールバック制御、リリース監視を1つのシステムで提供するチーム向けのオプションであり、製品詳細を確認するには Capgo を参照してください。デリバリーパスとインシデント対応フローに合致するかどうかを確認してください。
ライブアップデートを実施するチームは、パーセンテージがデッキで良く見えるものに甘くしないでください。SLAを確認し、モニタリングをテストし、ホットフィックスをユーザーが必要とするときにキャリーできるデリバリーアーキテクチャを選択してください。
