プロキシのサービスレベル契約：約束と監視

SLAで定めるもの

SLAはサービスの約束を測定可能にします。対象サービス、必要な性能水準、検証方法、違反時の対応を定めます。製品に適用する公開文書、利用条件の一部、個別顧客との契約などの形があります。

「信頼できるプロキシ」だけでは、提供義務はほとんど分かりません。可用性の約束は、対象部分、利用不能の判定、評価期間を定めて初めて意味を持ちます。サポートも同じです。応答期限には起算点、何を応答とするか、対応時間帯が必要です。

技術的上限とSLAの目的は違います。接続上限は利用者がかけられる負荷を、SLAは条件下で約束する水準を示します。製品仕様や過去の稼働率グラフが、自動的にSLAの約束になるわけではありません。

事業者が約束できる項目

可用性は一般的な対象です。サポート応答時間も対象になり得ます。復旧期限や性能のしきい値は、明示的に含めた場合だけ追加の約束になります。

プロキシでは約束の対象が重要です。ゲートウェイ、個別IP、プールを測る場合があります。ゲートウェイに届くだけでは、背後の全サーバーや端末の動作は証明できません。プール単位の約束には、一部だけの障害の扱いも必要です。

性能測定にも注意が必要です。プロキシへの接続時間と、その先のページのダウンロード時間は違います。後者には経路のより広い部分やサイトの応答も含まれます。どちらの測定への約束かを明記する必要があります。

24時間サポートは対応する時間帯、初回応答の約束は返答までの時間、復旧の約束は再び使える期限です。別々の義務であり、1つが他を自動的に含むわけではありません。

約束した水準を維持する方法

SLAを満たすには、動くインフラと組織的な障害対応が必要です。以下は維持方法の説明であり、全事業者が必ず備える機能の一覧ではありません。

冗長サーバーや回線は、機器・回線故障時の代わりになります。予備が役立つには、故障部品へ全面依存していてはいけません。同じ故障ネットワーク機器を通る複数サーバーは、一緒に使えなくなる場合があります。

通信管理は、新接続を正常サーバーへ送り、故障ノードへの割り当てを止めます。ローテーションプールでは、利用できないプロキシサーバーや端末を選択対象から外す場合もあります。固定一覧なら交換アドレスでアクセスを戻せても、元のIPは保持しません。そのため、動作維持の約束を、全アドレスや進行中セッションの保持保証と読まないでください。

容量計画は、需要変化や機器故障への余裕を確保します。残るサーバーが満杯なら、故障側から移す通信でそこも過負荷になります。事業者は使用量を監視し、持続的なボトルネックになる前に拡張や再分配をします。接続数・リクエスト上限も、負荷を運用条件内に保ちます。

保守やソフト変更も計画が必要です。保守前の通信移動、限定範囲の更新テスト、問題のある変更を戻す手段を用意できます。通常作業が大きな中断を起こす可能性を減らします。

警告に対応できる人も必要です。責任分担、対象システムへの権限、ネットワークやデータセンター専門家を呼ぶ手順が、復旧速度を左右します。

履行の測定方法

監視には、発生中の障害検出と、長期評価用の測定保存という2つの役割があります。技術者を呼び出すアラートと月次の可用性レポートは、同じ観測結果を使うことがあっても、答える問いは異なります。

内部監視は、プロセス、資源使用、接続エラー、ネットワーク状態など、自社システムを追います。接続容量の消尽など、全体が応答停止する前の問題を発見できます。

外部チェックは、利用者が実際にできる操作を試します。認証し、プロキシ経由で管理下の接続先へつなぎ、期待した応答を確認できます。開いたポートを見つけるだけでは、経路の多くが未確認です。管理下の接続先なら、無関係なサイト故障との混同も避けやすくなります。

観測には、対象アドレスやゲートウェイ、時刻、結果、エラーなど、インシデントを特定できる詳細が必要です。観測範囲は間隔に左右されます。長い間隔は短い停止を見落とし、1ネットワークからだけでは他の経路問題を見落とします。一部アドレスの検査を、大規模プールの全IPが継続動作した証明として示すべきではありません。

契約が観測の数え方を定めます。定義により、対象サービス時間か対象リクエストから可用性を計算できます。評価期間、一部障害、除外条件は、その計算と対応する必要があります。規則なしの百分率だけでは測定を十分説明できません。

利用者も、事業者の報告とあわせて自分の測定を保存できます。公開状態ページはサービス全体の障害に、アカウント報告や個別確認は狭い問題に役立ちます。SLAは申請の評価記録と、利用者が出す情報を明確にするべきです。

サービス障害への対応

自動確認や利用者の報告で障害を知ります。事業者は、1アドレス、地域、認証、ゲートウェイ、全体のどれに影響するかを確認します。適切な担当への振り分けと優先順位に役立ちます。

まず使える状態を復旧します。プロセス再起動、通信移動、変更の取り消し、ネットワーク運営者との協力などを行います。根本原因の発見・除去はアクセス復旧より長くかかる場合があります。一時復旧と恒久修復は別段階です。

利用者への連絡にも担当が必要です。広域障害では、技術者が復旧し、サポートが報告収集と更新情報の公開を行う場合があります。更新間隔やエスカレーション期限をSLAで定めたなら、修復とは別に検証できる約束です。

復旧の確認も必要です。対象接続の再動作を確認し、エラー再発を監視します。報告がある場合、期間、対象サービス、対処、再発防止策を含められます。利用者に開示する詳細は条件次第です。

約束の適用範囲

失敗したリクエストだけでは原因は分かりません。認証情報の誤り、期限切れ、接続上限、サイトの拒否、サーバー故障はどれも中断を生みますが、対象部分は異なります。

SLAは、そのどの部分を引き受けるかを定めます。プロキシ接続の維持は、独立したサイトがIPを受け入れ、必要内容を返す自動的な保証ではありません。利用者側のネットワーク問題と、事業者内部の故障も違います。

計画保守などの除外にも条件が必要です。事前通知や指定時間帯を条件とする場合があります。作業しただけでは、停止をどう数えるかは決まりません。適用契約が規則を定めます。

依存先の扱いも明確にする必要があります。ホスティング、トランジット網、他の供給元を使う場合があります。その関係する中断が対象外かは契約次第です。外部委託というだけでは、利用者のSLA範囲は説明できません。

SLAを満たさない場合

復旧は技術的問題を解決し、SLAの救済は未履行の約束に対応します。サービスクレジットは、後の料金に充てる金額です。延長や返金の場合もありますが、適用文書が救済を定める必要があります。

計算には基準料金の定義が必要です。クレジットはアカウント全体でなく、対象サービスに関連付ける場合があります。障害の程度で金額が違い、上限もあり得ます。これらがSLAの内容です。約束の未達だけで、中断した作業による全損失が補填されるわけではありません。

指定期間内の申請が必要な場合があります。対象サービス、タイムゾーン付き時刻、接続エラー記録などが必要です。SLAの手順と証拠に従い評価されます。

通常の購入返金方針とは別です。返金期間は購入代金を戻す条件、SLA救済は利用中に明確なサービス約束を満たさなかったことを扱います。