5.3自動化ワークフローの読解

本試験で問われるのは「Ansibleとは何か」ではなく、目の前のplaybookやスクリプトが結局何をするのかです。コードは書けなくても読めなければ、レビューも障害対応もできません。この節では、Ansible playbook・Python・bashの3種を「登場する要素（対象・モジュール・ループ・条件）」から読み解き、冪等な設定配布なのか、情報収集なのか、バックアップなのか、そして危険な操作が混じっていないかを判断できるようにします。

5.3.1Ansible playbookを読む

• playbookの骨格はhosts:（対象グループ）→ tasks:（順に実行する作業）。各taskはモジュール名で何をするかが決まる：ios_config＝設定を投入、ios_command＝コマンド実行して出力取得、ios_facts＝機器情報収集。name:はその作業の説明ラベルなので、まずモジュール名を読むのが要点。
• ios_configにbackup: yesがあれば、設定変更の前に現行構成をバックアップ保存してから適用する意図。loop:やwith_items:があれば複数のVLAN/IF/機器へ同じ作業を繰り返す。多くのモジュールは冪等で、既に望む状態ならchanged: falseと報告し二重適用しない。
• when: は条件付き実行（例：when: ansible_net_version is version('17.3', '<') なら古いIOS-XEだけに適用）。危険な操作の有無も読む：無条件のsave_when: alwaysや機器のreloadが入っていれば、書き込みや再起動という不可逆/影響大の操作が含まれるので、レビューで特に注意する。

5.3.2Python（requests/SDK）を読む

• HTTPメソッドで意図を読む：requests.get(...)＝情報取得（読み取り専用・安全）、requests.post(...)＝作成、requests.put(...)＝置換、requests.delete(...)＝削除。for device in devices:のループで複数機器に同じ呼び出しを回しているなら、機器横断の一括処理と分かる。
• 応答処理から成否の扱いを読む：resp.raise_for_status()やif resp.status_code 200:があればエラー処理を意識している。resp.json()で受けた結果を集計・出力していれば収集/レポート系、bodyを組み立ててpost/putしていれば変更系のスクリプトだと判断できる。

5.3.3bashスクリプトを読む

• bashは繰り返し＋外部コマンドが読みどころ：for ip in $(cat devices.txt); do ... doneで一覧の各機器に対して処理を回す。中でsshやscpを使い、show runの出力をファイルに落としていれば構成バックアップ、ping結果を集めていれば死活監視/収集と判断する。
• リダイレクトと日付で成果物を読む：> backup-$(date +%F).cfgは日付付きバックアップファイルの生成。crontabで定期実行されていれば定時バックアップの運用。破壊的な兆候（rm -rf、>での既存ファイル上書き）が無いかも併せて確認する。

同僚から次のAnsible playbookのレビューを頼まれました：- hosts: access_switches に対し tasks: が2つあり、1つ目は name: Configure guest VLAN で ios_config モジュールに lines:（vlan 30 / name GUEST）を与え backup: yes 付き、loop: で対象VLANの一覧を回しています。2つ目は name: Save if changed で ios_config の結果を受け save_when: changed としています。まずこのplaybookが何を自動化するかを読むと、「アクセススイッチ群に対し、ゲスト用VLANを標準化して冪等に配布し、変更が起きた場合のみ設定を保存する。適用前に現行構成をバックアップする」ワークフローだと分かります。ios_configは冪等なので、既にVLAN30が正しく存在する機器ではchanged: falseとなり保存もされません——これは安全な設計です。ここで同僚が「念のため2つ目をsave_when: alwaysにして毎回必ず保存し、ついでにreloadも足そう」と言ってきたら、レビュアーとして止めるべき判断です。save_when: alwaysは変更が無くても毎回書き込みを走らせて冪等性の利点（無変更なら何もしない）を損ない、無条件のreloadは全アクセススイッチの再起動という影響甚大かつ不可逆な操作を、VLAN追加という本来無停止で済む変更に混ぜ込むからです。読解のポイントは、hosts（誰に）・モジュール名（何を）・backup/loop/when/save_when（どのように・どんな条件で）を順に押さえ、このコードの正味の効果と、混ざり込んだ危険を言語化できることです。もしこれがPythonならgetかpost/putかで読み取り/変更を、bashならfor＋sshで一括バックアップか収集かを、同じ枠組みで読み解けます。

5.3.4この節のまとめ

• Ansible playbookはhosts（対象）＋tasksのモジュール名（ios_config=配布/ios_command=取得/ios_facts=収集）で意図を読み、backup/loop/when/save_whenで「どのように」を掴む
• 冪等なモジュールは望む状態ならchanged: falseで正常終了（失敗ではない）。無変更を失敗と誤読しない
• Pythonはget=読み取り/post・put=変更、bashはfor＋ssh/scpで一括バックアップ/収集。無条件のsave_when: alwaysやreloadなど影響大の操作をレビューで見抜く