フランスの現場で使う障害対応ツール、SSHタイムアウトを短縮したら復旧が早まった

パリ郊外の小規模チームで、障害対応用の踏み台サーバー（Ubuntu 20.04）から各ホストへSSHする運用をしていた。監視アラートが鳴ってから最初のログインまでに平均90秒かかり、原因の特定に遅れが出ていた。サーバー台数は約40台、1台あたりのログ量は多くないが、障害時は複数ホストに同時ログインする必要があった。

まず、踏み台サーバーの/etc/ssh/ssh_configに以下を追加した。

Host *
  ServerAliveInterval 5
  ServerAliveCountMax 2
  ConnectTimeout 5
  TCPKeepAlive no

これで無応答のホストを待たずに次のホストへ移れる。次に、障害対応用のシェル関数を.bashrcに定義した。

ssh_t() {
  local host="$1"
  timeout 10 ssh -o BatchMode=yes -o ConnectTimeout=5 "$host" "$2"
}

BatchMode=yesでパスワードプロンプトを無効化し、timeoutでコマンド全体を10秒で打ち切る。ログイン後の操作は別途行うが、初動の疎通確認はこれで十分だった。

なぜ効いたか。SSHのデフォルトは接続試行に約2分待つことがあり、障害時に複数ホストへ順番に試すと待ち時間が積み上がる。タイムアウトを短くすることで、応答しないホストを早期に切り捨て、生きているホストの調査にリソースを割ける。ただし、ネットワークが遅い環境では5秒では足りない場合がある。実際、VPN経由のホストではConnectTimeout 10に個別調整した。また、ServerAliveIntervalを短くしすぎると、負荷の高いホストでセッションが切れやすくなる。本番の重い処理中は一時的に元の設定に戻す運用にした。

この変更で初動のログイン完了までの中央値は約30秒に短縮された。ただし、根本的な原因調査にはログの集約やメトリクスの整備が別途必要で、SSH設定はあくまで初動の足を速くするだけだ。

同じような踏み台運用をしているチームで、タイムアウト値をどう決めているか、あるいは障害時に同時ログインをどう捌いているか知りたい。