VPNのヘルスチェックとアプリケーションのヘルスチェックを分ける
トンネルプロセスが動いていても保護された接続が使えないことはあり、保護ルート、DNS、宛先はそれぞれ独立に失敗し得る。各チェックが自分の層と、それが引き起こすアクションを名乗るようにする。
トンネルプロセスが動いていても保護された接続が使えないことはあり、Webページが失敗することはトンネルが壊れた証拠ではない。ひとつのプローブがすべてを代表すると、再起動ポリシーは間違ったコンポーネントを再起動し、それを自動化と呼ぶ。以下の各チェックは、観測する層、その失敗が引き起こすアクション、そしてアクションが効いた証拠を明示する。最後のステップで、この一式を深夜三時に誰かがたどれるページにする。
ステップ 1:各チェックが観測する層を名付ける
どれかを書く前に、各プローブが実際に何を見えるかを問う。生存性はデーモンが動いていることを、ハンドシェイクやピア一覧は関係が存在することを、ルーティングされた要求は配信を、名前解決は解決を証明する。それらはその順に失敗し、どれも次を意味しない。緑のプロセスチェックが死んだトンネルの隣にあるのは正常なケースであり、矛盾ではない。
四つのチェックをその順に書き、それぞれ正確なコマンドと期待される出力を添える。期待される出力を言えないプローブは、アラートを見る運用者ごとに違う読み方をされる。同じ一覧をランブックだけでなくアラート本文にも入れ、夜中に起こされた人が症状より先に層に出会えるようにする。どのコマンドも実行するホスト上でコピーできる状態に保つ。
次に、アプリケーションのチェックを五番目の独立した項目として加える。アカウントサービスが落ちているページは、トンネルの再起動を正当化しない。
ステップ 2:各失敗をひとつのアクションに結びつける
各チェックについて、何を再起動し、何を遮断したままにし、何が人を呼ぶかを決める。トンネル層の失敗はトンネルの再起動を正当化し得て、リゾルバの失敗はクライアントのDNS統合を指し、アプリケーション層の失敗はトンネルにほとんど触れるべきではない。
危険な既定値は許す側なので、失敗がしてはならないことを書く。トンネルを静かに迂回するフォールバックはトンネルが存在する理由を消すため、不健全な状態が直接のアプリケーショントラフィックの許可になっては決してならない。アクションも狭め、ひとつの宛先が遅いからと共有コンポーネントを再起動すれば、局所的な問題がフリート全体の問題になる。それは原因を突き止めるための証拠も壊してしまう。
ステップ 3:プローブを無害で安価に保つ
小さな読み取り専用の要求(静的リソース、自分の依存関係を報告するヘルスエンドポイント、管理下のポートへのTCP接続)を使い、資格情報やプライベートブラウジング、間隔ごとに状態を変えるものは避ける。書き込むプローブはスケジュールされた負荷試験だからだ。
各プローブについて、宛先、ルートの期待値、タイムアウトを記録する。ルートの期待値は人が落としがちな項目であり、後でアラートを読むときにトンネルの失敗とルーティングの誤りを分けるのはこれだ。間隔と失敗しきい値は約束する復旧時間から導き、タイムアウトは間隔より短く保つ。次のプローブが始まっても走っているプローブは、ひとつの失敗を二度報告し、フラップのように見える。
ステップ 4:各層を壊し、正しいプローブが赤くなるのを見る
トンネルプロセスを止め、DNSがまだキャッシュから応答し得る間にプロセスチェックが失敗することを確かめる。ルートを変え、プロセスとハンドシェイクが健全なままルーティングされた要求が失敗することを確かめる。DNSだけを壊し、アプリケーションのチェックがトンネルエラーではなく解決を報告することを確かめる。二つのプローブがいつも一緒に動くなら、思っているよりチェックが少ない。
復旧の方向も同じ規律で試す。層を戻したあと、プローブは手動の再起動なしに消えるべきであり、発火したアクションは抜け道を残してはならない。緑の状態を信じる前に完全なサイクルをひとつ観察するのは、手でしか消えないプローブが壊れた復旧経路を隠すからだ。
ステップ 5:ランブックをアラートが指す場所に置く
五つの行を持つ一枚のページが、層、コマンド、期待結果、失敗時のアクション、所有者という設計のすべてを担う。各プローブについて、意図的に試さないことを一行で添える。その一行が、すべてを測って何も区別しない六番目のチェックを次の人が足すのを止める。インシデントの最中に誰も開かないので、アラート本文からページをリンクする。
コンテナ配備では、依存条件が起動を形づくるだけで、それ以上ではない。Compose の起動順序とヘルス条件についてのドキュメントは、準備状態がサービス起動の順序をどう左右するかを説明しており、そのいずれも、その後に外向きのポリシーを強制するものではなく、トンネルが落ちたときに閉じた状態で失敗するものでもない。継続的な強制には独自のポリシーと独自のプローブが必要で、同じページに書くべきだ。
ランブックは、正しい層が復旧し、誰も利用できないWebサイトを壊れたトンネルと読まないときに完成する。それはトンネルではなく文書を試している。