💨

TeraTerm文化からAnsible文化へ ― ネットワーク運用の現実解

に公開

1. はじめに

ネットワーク運用の現場では、いまだに TeraTermでコンフィグを流し込む文化 が根強く残っています。AnsibleやIaCが話題になっても、「ウチはまだTeraTermだよ」という声は少なくありません。この記事では、TeraTerm文化の強みと限界を整理しつつ、Ansible+Gitによる移行の現実解を考えます。


2. TeraTerm文化の強みと限界

強み

  • 学習コストが低く、誰でもすぐ使える
  • 少数台・小規模変更なら最速
  • 長年の慣れで現場に浸透

限界

  • スペルミス/空白ズレ → 即エラー、投入が止まる
  • マクロが属人化 → TeraTerm職人に依存
  • ファイル名管理の地獄config_20230801_a.txt, config_final_v4.txt など
  • 差分管理ができない → 誰がいつ何を変えたのか分からない

3. Ansible文化とは何か

  • YAMLで可読性が高い(ネットワーク担当以外でも読める)
  • モジュール化された操作(例: ios_config, fortios_firewall_policy
  • Git管理が前提 → 差分確認、レビュー、ロールバックが容易
  • idempotent(冪等性) → 再実行しても正しい状態に収束
  • 大規模拠点や本社のような重要拠点で特に有効:機器台数が多いほど作業時間がかかるため、通信断時間を短くしつつ、作業ミスを減らせるのが強み

4. TeraTerm文化 vs Ansible文化

観点 TeraTerm文化 Ansible文化
入門コスト 低い(即使える) Git/YAML習得が必要
スペル/空白ミス 人力で注意 構文チェック&差分適用
属人化 マクロ職人頼み Playbookをチームで共有
履歴管理 _v1, _v2 ファイル名 Git log & diff
大量投入 手間増・ミス増 serial/差分で安全に投入
定期バックアップ 手動/スクリプト依存 Playbookで一括自動化
通信断時間 個々に投入で長くなりがち 並列制御・差分投入で短縮

5. 段階的な導入ステップ

  1. バックアップ自動化から始める

    • まずは show running-config をAnsibleで吸い上げる
  2. 小さなタスクの自動化

    • 例: ACL追加、アドレスオブジェクト登録
  3. 投入量が多いタスクを移行

    • serial で段階的に投入、--check --diff で差分確認
    • 大規模拠点では特に効果的(通信断時間の短縮&作業精度向上)
  4. Gitレビュー文化を定着

    • PRレビューで「この変更を適用して良いか?」を確認

6. 現場でよくある誤解と対策

  • 「一括誤配信が怖い」serialmax_fail_percentage、ロールバックで対策
  • 「TeraTermの方が楽」 → 台数が10台を超えると逆にAnsibleが楽
  • 「Ansibleは難しい」 → 実際は YAML + Git さえ覚えれば十分
  • 「想定外の事象に弱い?」 → Ansibleは計画的な一括処理に強いが、当日トラブル対応や即応が必要なときにはTeraTermで直接CLIを叩く方が迅速。TeraTermを完全否定する意図はなく、役割分担が重要

7. 実例:TeraTermマクロ vs Ansibleタスク

TeraTermマクロ例

; インタフェースに説明を付ける
sendln "configure terminal"
sendln "interface GigabitEthernet0/1"
sendln "description Uplink to ISP"
sendln "end"

Ansibleタスク例

- hosts: ios
  gather_facts: no
  tasks:
    - name: Configure interface description
      cisco.ios.ios_config:
        lines:
          - description Uplink to ISP
        parents: interface GigabitEthernet0/1

👉 読みやすさ・再利用性・レビューのしやすさが段違いです。


8. まとめ

  • TeraTerm文化は悪ではない:小規模・少数台にはまだ有効、緊急時の即応にも活躍
  • ただし**「量」や「履歴管理」や「重要拠点の通信断短縮」には耐えられない**
  • Ansible+Gitは「みんなで使える・安全に進められる自動化」
  • 最適解は TeraTermとAnsibleの併用 → 段階的移行

9. おわりに

TeraTermマクロ職人に依存する運用から、誰でも読める・直せるGit+Ansible文化への移行は、長期的な保守性と安全性に直結します。
特に大規模拠点では「通信断を短くする」「ヒューマンエラーを減らす」ために必須です。
ただし、作業当日の想定外トラブルに即応するために、TeraTermを手放す必要もありません。計画的な作業はAnsible、緊急時はTeraTermという役割分担が現実解です。
「config_20230801_v4.txt」で苦しむ日々を卒業して、レビュー可能な自動化基盤に一歩踏み出しませんか?

Discussion