راینو

در پایان این درس باید بتوانی

Ad-hoc Command و Playbook را از پایه توضیح بدهی
Command Output و Register را در یک سناریوی واقعی تحلیل کنی
Idempotent Configuration را با روش کنترل‌شده پیاده‌سازی کنی
Check Mode، Diff و Batch Rollout را با Evidence بررسی کنی
Troubleshooting Partial Failure را مرحله‌به‌مرحله عیب‌یابی کنی

Ad-hoc Command و Playbook

Ad-hoc Command برای Query سریع مفید است، اما Playbook برای Workflow تکرارپذیر، Version Control و چند Task مناسب‌تر است. اجرای show روی کل Fleet Risk نسبتاً پایین دارد، اما Commandهای تغییر State باید از Change Process عبور کنند.

برای فهم این مفهوم باید مرز آن با فناوری‌های مجاور روشن باشد. در شبکه واقعی، یک علامت مشابه می‌تواند از چند لایه ایجاد شود؛ بنابراین تعریف دقیق باعث می‌شود از تغییر Configuration نامرتبط جلوگیری شود.

Ad-hoc concept

ansible switches -m cisco.ios.ios_command -a "commands=show clock"

برای اجرای Command با Ansible، Idempotency و Validation، فهم Ad-hoc Command و Playbook باید همراه با مرزبندی دقیق انجام شود. قبل از هر تصمیم، مشخص کن این مفهوم در کدام لایه یا بخش از مسیر قرار دارد، چه Stateی ایجاد می‌کند و چه چیزی خارج از مسئولیت آن است. بسیاری از خطاهای عملی از اینجا شروع می‌شوند که یک علامت مشترک به فناوری اشتباه نسبت داده می‌شود. اگر بتوانی بگویی «این بخش دقیقاً چه چیزی را ثابت می‌کند و چه چیزی را ثابت نمی‌کند»، هنگام Incident به‌جای حدس زدن، Failure Domain را کوچک می‌کنی. در محیط واقعی همیشه فناوری مجاور، مسیر برگشت و Policyهای بین راه را هم در ذهن نگه دار.

Command Output و Register

Output Task را می‌توان register کرد و با شرط/Assertion بررسی کرد. به‌جای اعلام Success صرفاً بر اساس Exit Code، مثلاً Assert کن NTP Association یا Interface State مطابق انتظار است. Automation بدون Validation فقط اجرای سریع Command است.

جریان را از دید Packet یا State دنبال کن، نه فقط از دید Command. هر مرحله باید Input، تصمیم و Output مشخص داشته باشد و بتوانی بگویی شکست در آن مرحله چه علامتی تولید می‌کند.

Validation concept

register: result
assert expected state from result

برای تحلیل عملی Command Output و Register یک Flow Card کوچک بساز: Source، Destination، Protocol یا Service، Interface/VLAN/Prefix مرتبط و Timestamp. سپس Packet یا State را از یک Boundary به Boundary بعدی دنبال کن. این روش در اجرای Command با Ansible، Idempotency و Validation کمک می‌کند تفاوت میان Configuration موجود و رفتار واقعی شبکه دیده شود. اگر یک مرحله سالم است، همان مرحله را دوباره تغییر نده؛ Boundary بعدی را آزمایش کن. اگر مرحله‌ای شکست می‌خورد، خروجی و Counter همان نقطه را ثبت کن. این عادت ساده باعث می‌شود Troubleshooting حتی در شبکه‌ای با چند Switch، Router، Security Policy و Server قابل تکرار و قابل توضیح باشد.

Idempotent Configuration

Configuration Module می‌تواند Desired Lineها را مدیریت کند و اگر State از قبل صحیح باشد Change گزارش نکند. Idempotency Drift را کم می‌کند، اما Commandهای غیرIdempotent یا Side Effect هنوز احتیاط می‌خواهند.

Configuration باید بعد از Baseline و با Scope مشخص انجام شود. نمونه دستور برای Lab است و Syntax یا Capability دقیق می‌تواند با Platform و IOS XE Release تفاوت داشته باشد؛ Contextual Help و مستندات همان Device مرجع نهایی‌اند.

Idempotency

Desired config == actual config -> no change

پیاده‌سازی Idempotent Configuration در شبکه شرکت باید به سه فاز Pre-check، Change و Post-check تقسیم شود. در Pre-check وضعیت فعلی، Dependencyها و مسیر مدیریت را ذخیره کن؛ در Change فقط Scope لازم را تغییر بده؛ در Post-check هم State فنی و هم سرویس کاربر را Verify کن. برای Changeهایی که ممکن است Access مدیریت، Routing یا Security را تحت تأثیر قرار دهند، Rollback را قبل از اجرای دستور بنویس و مسیر Recovery را مشخص کن. هدف این نیست که Configuration فقط از نظر Syntax پذیرفته شود؛ Desired State باید با Design، مستندات، Address Plan و Security Policy سازمان سازگار بماند.

Check Mode، Diff و Batch Rollout

Check Mode/Diff در Moduleهای پشتیبانی‌شده، Pilot Host Limit و serial batch اندازه Blast Radius را کنترل می‌کنند. Post-check هر Batch قبل از ادامه Rollout اهمیت دارد. Maintenance Window و Rollback نیز باید Automation-aware باشند.

Verification یعنی مقایسه State عملیاتی با Intent. وجود خط Configuration فقط Desired State را نشان می‌دهد؛ Counter، Table، Log یا Test End-to-End ثابت می‌کند Feature واقعاً چگونه کار می‌کند.

Rollout

pilot -> serial batch -> validate -> next batch

در Verification مربوط به Check Mode، Diff و Batch Rollout، خروجی Command را به‌صورت «Expected در برابر Actual» بخوان. وجود یک Line در Running Configuration فقط Intent را نشان می‌دهد؛ Table، Neighbor State، Counter، Log یا Test End-to-End نشان می‌دهد Feature واقعاً چه می‌کند. اگر Counter وجود دارد، مقدار مطلق را تنها معیار نگذار؛ قبل و بعد از Test به Delta توجه کن. اگر Log وجود دارد، Timestamp و Source را با Flow آزمایشی تطبیق بده. در اجرای Command با Ansible، Idempotency و Validation بهتر است حداقل یک Positive Test و، هرجا Security مطرح است، یک Negative Test نیز داشته باشی تا هم Availability و هم Policy درست اثبات شوند.

Troubleshooting Partial Failure

در Partial Failure مشخص کن کدام Host تغییر کرده و کدام نه. State نیمه‌اعمال‌شده را قبل از Retry بشناس. Job Report، Device Config Diff و Post-check را هم‌بسته کن. Retry کور می‌تواند Task غیرIdempotent را دوبار اجرا کند.

در Troubleshooting ابتدا Scope و Flow را ثبت کن، سپس کم‌هزینه‌ترین Test را اجرا کن که یک فرضیه را تأیید یا رد می‌کند. قبل از Clear، Reload یا Disable کردن Feature، Evidence را جمع کن تا Root Cause از بین نرود.

Partial failure

Host status: ok/changed/failed/unreachable -> reconcile actual state

مسیر Troubleshooting Troubleshooting Partial Failure را با کم‌هزینه‌ترین Test شروع کن که بیشترین اطلاعات را می‌دهد. ابتدا Scope و آخرین وضعیت سالم را مشخص کن، سپس نزدیک‌ترین Boundary سالم به کاربر یا Source را پیدا کن و قدم‌به‌قدم جلو برو. هر Test باید یک Hypothesis را رد یا تأیید کند؛ اگر نتیجه فرضیه را رد کرد، همان Configuration را بی‌دلیل دست‌کاری نکن. قبل از Reload، Clear State یا Disable کردن Feature، Evidence را ذخیره کن چون این عملیات می‌توانند سرنخ Root Cause را پاک کنند. بعد از Fix نیز تست اولیه را تکرار و Preventive Action را در Documentation ثبت کن.

سناریوی عملی

Automation VLAN Description را روی 50 Switch تغییر می‌دهد و در Batch دوم دو Switch Auth Fail می‌شوند. Workflow متوقف می‌شود، State 20 Device تغییرکرده و 30 Device تغییرنکرده ثبت می‌شود. Credential مشکل‌دار اصلاح و سپس فقط Targetهای باقی‌مانده اجرا می‌شوند.

اشتباهات رایج

اشتباه‌های رایج و علت آن‌ها

تغییر اجرای Command با Ansible، Idempotency و Validation بدون Baseline و Scope مشخص
قضاوت درباره اجرای Command با Ansible، Idempotency و Validation فقط از روی وجود Configuration
نادیده گرفتن Dependencyها و مسیر واقعی Packet/State
انجام Clear/Disable گسترده قبل از جمع‌آوری Evidence

تمرین عملی

یک Diagram یا State Flow برای اجرای Command با Ansible، Idempotency و Validation رسم کن
نمونه Configuration/Policy اجرای Command با Ansible، Idempotency و Validation را در Lab بررسی کن
خروجی Verification را قبل و بعد از یک Test مقایسه کن
یک Failure عمدی بساز و Root Cause را با Runbook پیدا کن

نکته‌هایی که باید با خودت ببری

Ad-hoc Command برای Query سریع مفید است، اما Playbook برای Workflow تکرارپذیر، Version Control و چند Task مناسب‌تر است
Output Task را می‌توان register کرد و با شرط/Assertion بررسی کرد
Configuration Module می‌تواند Desired Lineها را مدیریت کند و اگر State از قبل صحیح باشد Change گزارش نکند
Check Mode/Diff در Moduleهای پشتیبانی‌شده، Pilot Host Limit و serial batch اندازه Blast Radius را کنترل می‌کنند
در Partial Failure مشخص کن کدام Host تغییر کرده و کدام نه

خودسنجی

Ad-hoc Command و Playbook چه مسئله‌ای را حل یا توضیح می‌دهد؟

Ad-hoc Command برای Query سریع مفید است، اما Playbook برای Workflow تکرارپذیر، Version Control و چند Task مناسب‌تر است.

در Command Output و Register مهم‌ترین State یا جریان چیست؟

Output Task را می‌توان register کرد و با شرط/Assertion بررسی کرد.

قبل از Idempotent Configuration چه کاری ضروری است؟

Baseline، Scope و Rollback مشخص شود.

اصل کلیدی Troubleshooting Partial Failure چیست؟

هر Test باید یک فرضیه را با Evidence تأیید یا رد کند.

منابع رسمی

منابع مرجع این درس

مطالعه همیشه آزاد است

برای ذخیره پیشرفت وارد حساب شو

حساب کاربری برای آزمون و ثبت مرحله‌ها استفاده می‌شود

ورود یا ثبت‌نام

بازگشت به صفحه دوره CCNA