半管理VPN:ラベルは誰が当番かを語らない
ラベルはプロトコルでも分担率でもない。エンドポイント、共通設定、監視、インシデントの引き継ぎについて、作業ごとに担当者へ変えていく。
朝八時に接続が切れ、最初の問いは誰が直すべきかである。半管理VPNという言葉は、作業の分担ではなく商取引の取り決めに名前を付けたものなので、その問いには答えない。二人の事業者は同じ言葉を正反対の分担で使いえ、一方は顧客側の機器を保守し、他方は自社のゲートウェイだけを見ている。作業が書き出されるまで、ラベルは説明の衣装を着た推測にすぎない。
切れた接続から始める
応答をやめたエンドポイント、時刻、そして壊れたときに利用者が何をしていたかを名指しする。次にその経路上の構成要素として、ノートパソコン、局所回線、顧客側ゲートウェイ、事業者ゲートウェイ、その背後のリソースを並べる。どれも契約上の担当者がいるか、空白があるかのどちらかだ。並べ替えは十分で終わり、次の三時間を決める。
複数の利用者に共通する症状は共有部品を指し、一台のノートパソコンに付き従う症状はクライアントを指す。その区別が、誰かが設定を開く前にチケットを正しい待ち行列へ入れる。
設定より先に二つの端点を決める
顧客側ゲートウェイを誰が持ち、遠い側の端点を誰が持つかを決める。この二つが決まれば、どちらの側も何を調べられ、何を求めねばならないかを知る。取り決めの残りはそこから楽になる。
事業者は自社ゲートウェイを監視でき、顧客は地域の回線、ディレクトリサービス、宛先アプリケーションの責任を負い続ける。顧客が所有する機器でも事業者の保守契約の下に置けるので、所有権と箱を誰が保守するかは別の問いである。更新の話が食い違うのはたいてい二つ目なので、端点ごとに両方の答えを書く。
共有物の持ち主はちょうど一人
識別子、資格情報、保護された前置、提案、戻り経路の取り決めは共有物であり、共有物は最も速く腐る。双方が一つを変えられるなら双方が変え、合意した流れが壊れる一方で、どの変更も局所的には正しく見える。すべての共有物に一人の持ち主と一つの変更手続きを与え、変更が入る前に相手へ知らせることを必須にする。そうしなければ、変更履歴は同じ機械のそれぞれ別の半分を直す二人のように読める。
典型的な故障は、同じ週に片側でセレクタを変え、もう片側でNATを変えることだ。どちらの技術者も間違っていないのに、トンネルはアプリケーションを運ぶのをやめた。
最初の通報は誰が受けるか
最初に誰を呼ぶか、どちらの側が何を読めるか、どこで案件が手を変えるかを前もって決める。端点、試行時刻、許可された流れを渡し、双方が同じ事象を突き合わせられるようにする。
狭い状態要約は、編集されていない設定よりたいてい役に立ち、秘密も漏らさない。監視は部品の持ち主のものでありロゴの持ち主のものではないので、トンネルの状態を見るのはどちらか、アプリケーションを見るのはどちらか、各警報が誰を起こすのかを尋ねる。時間外の経路を各警報の隣に置くのは、誰も当番していないダッシュボードが文書にすぎないからだ。
変更の権限も同じ注意深さで定める。事業者がセレクタを編集し、同時に顧客がNATを編集すれば、どちらのローカル設定ももっともらしく見え、トンネルはやはり失敗する。
ラベルが決して教えないこと
ソフトウェアの保守、資格情報の更新、設定の承認済みバックアップ、復旧の経路を実際の契約に書き込む。共有責任モデルの一例として、AWSが公開するモデルは、サービス間で分担がどこまで動きうるかを示し、あなたの供給者の条件を定義するものではなく一例にすぎない。半管理という言葉から何かを推し量ることが、更新の会話で空白が見つかる理由である。
範囲には、通常の運用担当者と、依存関係ごとのエスカレーション経路を書くべきだ。見積りがそのサービスを何と呼ぼうと、実際に意味するのはその一覧である。