アップタイムトラッキング

1）なぜモニターの稼働時間

稼働時間-サービスがユーザーに利用可能な時間の共有。これは観測の「第一線」です。即座にアクセス不能、ネットワーク上の劣化、DNS/TLS障害、ルーティングまたはCDNの問題に気づきます。高負荷で規制されたシステム（フィンテック、iGaming）の場合、アップタイムは収益、SLAパフォーマンス、ペナルティリスクに直接影響します。

2）用語と数式

可用性SLI： 'SLI=（成功チェック/すべてのチェック）× 100％'。

SLO： ウィンドウごとの目標可用性（通常は28-30日）、例えば99。9%.

SLA：外部の義務；常に内部SLOを≤します。
MTBF/MTTR：故障/平均回復時間の平均時間。

99.0％→~ 432分が利用できません

99.9％→~ 43分

99.99% → ~4.3分

99.999％→~ 26秒

3）どのチェックが必要ですか（ブラックボックス）

「クライアントの目を通して」サービスを見るために外部ポイント（異なる地域/プロバイダー）から開始しました。

1.ICMP （ping）-基本的なネットワーク/ノードの可用性。早いが、ビジネスの成功を反映していない。
2.TCP接続-ポートリスニング？ブローカー/DB/SMTPに便利です。
3.HTTP/HTTPS-ステータスコード、ヘッダー、サイズ、リダイレクト、最初のバイトへの時間。
4.TLS/証明書-有効期間、チェーン、アルゴリズム、SNI、プロトコル。
5.DNS-A/AAAA/CNAME、 NS-health、 DNSSEC。
6.gRPC-コールステータス、締め切り、メタデータ。
7.WebSocket/SSE-ハンドシェイク、接続メンテナンス、エコーメッセージ。
8.プロキシ/ルーティング/CDN-異なるPoP、キャッシュハッシュ、ジオバリアント。
9.トランザクション合成シナリオ（クリック/フォーム）：「login→search→deposit （sandbox）」。
10.ハートビート/クロンモニタリング-サービスは「パルス」する必要があります（N分ごとに1回フック）。信号なし-アラーム。

• 実際のUXに近いタイムアウトを設定します（例えば、TTFB ≤ 300ミリ秒、合計≤ 2秒）。
• コンテンツアセット（キーワード/JSONフィールド）をチェックして、エラーのある「200 OK」が成功と見なされないようにします。
• 独立したプロバイダとネットワーク（マルチホップ、異なるASN）による重複チェック。

4）ホワイトボックスと健康サービス

オーケストレーターのためのLiveness/Readinessテスト（プロセスは生きていますか？トラフィックを受信する準備はできていますか？）。
依存性健全：DB、キャッシュ、イベントブローカー、外部API （payment/KYC/AML）。
フィーチャーのフラグ/劣化：問題が発生した場合は、クリティカルでないパスを穏やかに無効にします。

ホワイトサンプルは外部チェックを置き換えるものではありません。サービスは「内部が健全」である可能性がありますが、DNS/TLS/routeのためユーザーには利用できません。

5）地理と複数の地域性

主要なトラフィックリージョンおよび重要な依存関係プロバイダの近くから合成を実行します。
クォーラム：≥ N領域（例えば、3のうち2）で局所異常を遮断できなかった場合、インシデントが記録されます。
コホートによる閾値：重要なセグメント（国、VIP、キャリア）のSLI/SLOを分離します。

6）アラートポリシー（騒音最小）

Multi-region+multi-probe：一貫した障害（HTTPとTLSの同時、≥ 2つのリージョン）の場合のみpager。
Debowns：ページング前にN連続故障または2-3分間のウィンドウ。

• L1：オンコール（生産サービス）。
• 障害署名に基づくL2ネットワーク/プラットフォーム/セキュリティ。
• 自動閉じる：安定したMの成功した点検の後。
• 静かな時間/譲歩：重要でない内部サービスの場合-チケットのみ、ページャーなし。

7）ステータスページとコミュニケーション

公開（クライアント）および非公開（内部）ステータスページ。
合成からの自動インシデント+手動注釈。
メッセージテンプレート：検出された-識別された-影響-回避策-ETA-解決-ポストモデム。
計画されたウィンドウ：事前に発表し、SLOとは別に例外を考慮してください。

8）外部依存関係の検討

各プロバイダ（支払い、KYC、郵送、CDN、クラウド）-いくつかの地域からの独自のチェック。
フェイルオーバールート：合成信号を使用して代替プロバイダに自動切り替えます。
プロバイダレベルと統合e2e-SLOでSLOを分離します。
プロバイダとSLAに同意します（ステータスWebフック、サポート優先度）。

9）ダッシュボードとキーウィジェット

チェックのステータスを持つワールドマップ（タイプ別：HTTP、 DNS、 TLS）。
リリース/フラグ注釈を持つインシデントのタイムライン。
地域ごとにTTFB/TTL/レイテンシーをP50/P95/P99します。
コホート（国/プロバイダ/デバイス）による可用性。
MTTR/MTBF、月間の可用性の予算の「アイドル分」と「バーンダウン」の傾向。
障害の主な理由（TLS期限切れ、DNS解決、5xx、タイムアウト）。

10）インシデント処理（過渡シナリオ）

1.マルチリージョン/マルチタイプアラートがトリガーされます。
2.担当官が確認し、解放の凍結をオンにし、所有者に通知します。
3.クイック診断：DNS/TLS/CDNステータス、最新リリース、エラースケジュール。
4.バイパス：ルート変更、フォルバックコンテンツ/プロバイダ、劣化モードを有効にします。
5.回復：合成/実際のトラフィックが緑色であることを確認します。
6.ステータスページ上のコミュニケーション；事件を締めくくった。
7.RCAとアクションアイテム：修正、テスト、アラート、プレイブック。

11） SLA/SLOレポート

毎月のレポート：サービス/地域別のアップタイム、ダウンタイムの分、MTTR、理由。
SLAとの比較：クレジット/補償、該当する場合。
四半期ごとのレビュー：しきい値の更新、合成の分布、依存関係のリスト。

12）検査テンプレート（例）

• 方法：'GET/healthz/public'（秘密なし）。
• タイムアウト：2秒、再試行：1。
• 成功：'2xx'、ヘッダ'X-App-Version' present、 JSONフィールド'「status」：」 ok」。

• 用語>14日、有効なチェーン、プロトコル'TLS 1。2+'、正しいSNI。

• 応答時間≤ 100ミリ秒、A/AAAAレコードは予定どおり、SERVFAIL/REFECTEDはありません。

• Webhook '/beat/{ service} '5分ごと；行に2つの信号がない-L2アラート（バックグラウンドタスク/ETL）。

13）実装チェックリスト

• マルチリージョン外部チェック（HTTP/TCP/DNS/TLS/deepスクリプト）。
• オーケストレーターのための白い準備/livenessサンプル。
• クリティカル/非クリティカルパスの分離、劣化フラグ。
• アラート、エスカレーション、オートクローズでのクォーラムとデビット。
• パブリックステータスページと内部ステータスページ、メッセージテンプレート。
• 外部プロバイダの個別のチェックとSLO+自動フェイルオーバー。
• ダッシュボード：マップ、タイムライン、パーセンタイル、アイドル分、MTTR/MTBF。
• 通常のSLA/SLOレポートと事後RCA。

14）頻繁なエラー

HTTP/contentのないping/portのみが実際に利用できない場合は緑色になります。
1つのモニタリングポイント-誤った肯定的/否定的な結論。
TLS/DNS制御なし-遅延/設定ミスによる突然の停止。
エキストラノイズ：同じリージョン/チェックタイプの1つの障害に対するアラート。
変更との接続はありません-ダッシュボードにリリースとフラグの注釈はありません。
カウントされていない依存関係-決済プロバイダが低下し、全体のステータスは「緑」です。

15）ボトムライン

アップタイムトラッキングは、単に"ピーク時のURLだけではありません。"これは、実際の地域からの合成チェック、ノイズのない合理的なアラート、ステータスページを通じた透過的なコミュニケーション、外部依存関係の会計処理、厳密な報告のシステムです。適切に構築されたアップタイム監視により、MTTRが削減され、SLAが保護され、ユーザーエクスペリエンスの予測可能性が維持されます。