- Desired State و Repository را از پایه توضیح بدهی
- Branch، Commit و Pull Request را در یک سناریوی واقعی تحلیل کنی
- Lint، Test و Pre-Deployment Validation را با روش کنترلشده پیادهسازی کنی
- Deploy، Verify و Rollback را با Evidence بررسی کنی
- Configuration Drift و Reconciliation را مرحلهبهمرحله عیبیابی کنی
Desired State و Repository
Repository باید Source of Truth یا بخشی از آن باشد و ساختار Site/Device/Role روشن داشته باشد. Secretها نباید Plaintext داخل Git باشند. Desired State باید آنقدر مشخص باشد که Tool بتواند Difference با Actual State را محاسبه کند.
برای فهم این مفهوم باید مرز آن با فناوریهای مجاور روشن باشد. در شبکه واقعی، یک علامت مشابه میتواند از چند لایه ایجاد شود؛ بنابراین تعریف دقیق باعث میشود از تغییر Configuration نامرتبط جلوگیری شود.
IaC lifecyclerepository desired state -> review -> test -> deploy -> verifyبرای Infrastructure as Code، Git و چرخه Change، فهم Desired State و Repository باید همراه با مرزبندی دقیق انجام شود. قبل از هر تصمیم، مشخص کن این مفهوم در کدام لایه یا بخش از مسیر قرار دارد، چه Stateی ایجاد میکند و چه چیزی خارج از مسئولیت آن است. بسیاری از خطاهای عملی از اینجا شروع میشوند که یک علامت مشترک به فناوری اشتباه نسبت داده میشود. اگر بتوانی بگویی «این بخش دقیقاً چه چیزی را ثابت میکند و چه چیزی را ثابت نمیکند»، هنگام Incident بهجای حدس زدن، Failure Domain را کوچک میکنی. در محیط واقعی همیشه فناوری مجاور، مسیر برگشت و Policyهای بین راه را هم در ذهن نگه دار.
Branch، Commit و Pull Request
Engineer Change را در Branch انجام میدهد، Commit معنیدار میسازد و Pull Request برای Review باز میکند. Reviewer باید Intent، Impact، Security و Rollback را بررسی کند، نه فقط Syntax. History کمک میکند بفهمیم چه کسی، چرا و چه زمانی Change را پیشنهاد داده است.
جریان را از دید Packet یا State دنبال کن، نه فقط از دید Command. هر مرحله باید Input، تصمیم و Output مشخص داشته باشد و بتوانی بگویی شکست در آن مرحله چه علامتی تولید میکند.
Git workflowbranch -> commit -> pull request -> review -> mergeبرای تحلیل عملی Branch، Commit و Pull Request یک Flow Card کوچک بساز: Source، Destination، Protocol یا Service، Interface/VLAN/Prefix مرتبط و Timestamp. سپس Packet یا State را از یک Boundary به Boundary بعدی دنبال کن. این روش در Infrastructure as Code، Git و چرخه Change کمک میکند تفاوت میان Configuration موجود و رفتار واقعی شبکه دیده شود. اگر یک مرحله سالم است، همان مرحله را دوباره تغییر نده؛ Boundary بعدی را آزمایش کن. اگر مرحلهای شکست میخورد، خروجی و Counter همان نقطه را ثبت کن. این عادت ساده باعث میشود Troubleshooting حتی در شبکهای با چند Switch، Router، Security Policy و Server قابل تکرار و قابل توضیح باشد.
Lint، Test و Pre-Deployment Validation
Lint Syntax، Schema Validation، Unit/Test Logic و Lab/Simulation میتوانند خطا را قبل از Device واقعی بگیرند. برای ACL، Test Flowهای Permit/Deny و برای Routing، Reachability/Route expectation را میتوان خودکار کرد.
Configuration باید بعد از Baseline و با Scope مشخص انجام شود. نمونه دستور برای Lab است و Syntax یا Capability دقیق میتواند با Platform و IOS XE Release تفاوت داشته باشد؛ Contextual Help و مستندات همان Device مرجع نهاییاند.
Pre-deploy gateslint + schema + policy tests + lab validationپیادهسازی Lint، Test و Pre-Deployment Validation در شبکه شرکت باید به سه فاز 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 سازمان سازگار بماند.
Deploy، Verify و Rollback
Deploy باید Batch و Approval مناسب داشته باشد و Post-check Desired vs Actual را Verify کند. Rollback میتواند Revert Commit و Deploy Version قبلی باشد، اما باید با State واقعی Device سازگار باشد؛ Git Revert بهتنهایی Packet Forwarding را برنمیگرداند تا Deploy انجام شود.
Verification یعنی مقایسه State عملیاتی با Intent. وجود خط Configuration فقط Desired State را نشان میدهد؛ Counter، Table، Log یا Test End-to-End ثابت میکند Feature واقعاً چگونه کار میکند.
Deploymentdeploy batch -> post-check -> rollback/revert if neededدر Verification مربوط به Deploy، Verify و Rollback، خروجی Command را بهصورت «Expected در برابر Actual» بخوان. وجود یک Line در Running Configuration فقط Intent را نشان میدهد؛ Table، Neighbor State، Counter، Log یا Test End-to-End نشان میدهد Feature واقعاً چه میکند. اگر Counter وجود دارد، مقدار مطلق را تنها معیار نگذار؛ قبل و بعد از Test به Delta توجه کن. اگر Log وجود دارد، Timestamp و Source را با Flow آزمایشی تطبیق بده. در Infrastructure as Code، Git و چرخه Change بهتر است حداقل یک Positive Test و، هرجا Security مطرح است، یک Negative Test نیز داشته باشی تا هم Availability و هم Policy درست اثبات شوند.
Configuration Drift و Reconciliation
Drift زمانی است که Actual Config با Repository متفاوت شود؛ مثلاً Emergency CLI Change ثبت نشده باشد. Reconciliation باید Drift را Detect، علت را مشخص و تصمیم بگیرد Actual Change وارد Source of Truth شود یا Desired State دوباره Apply گردد.
در Troubleshooting ابتدا Scope و Flow را ثبت کن، سپس کمهزینهترین Test را اجرا کن که یک فرضیه را تأیید یا رد میکند. قبل از Clear، Reload یا Disable کردن Feature، Evidence را جمع کن تا Root Cause از بین نرود.
Driftdesired state != actual state -> drift -> reconcileمسیر Troubleshooting Configuration Drift و Reconciliation را با کمهزینهترین Test شروع کن که بیشترین اطلاعات را میدهد. ابتدا Scope و آخرین وضعیت سالم را مشخص کن، سپس نزدیکترین Boundary سالم به کاربر یا Source را پیدا کن و قدمبهقدم جلو برو. هر Test باید یک Hypothesis را رد یا تأیید کند؛ اگر نتیجه فرضیه را رد کرد، همان Configuration را بیدلیل دستکاری نکن. قبل از Reload، Clear State یا Disable کردن Feature، Evidence را ذخیره کن چون این عملیات میتوانند سرنخ Root Cause را پاک کنند. بعد از Fix نیز تست اولیه را تکرار و Preventive Action را در Documentation ثبت کن.
در Incident مهندس موقتاً ACL را CLI تغییر میدهد اما Repository Update نمیشود. شب Automation Desired State قدیمی را دوباره اعمال و Fix را برمیگرداند. Root Cause فقط Automation نیست؛ Emergency Change وارد Source of Truth نشده بود.
اشتباههای رایج و علت آنها
- تغییر Infrastructure as Code، Git و چرخه Change بدون Baseline و Scope مشخص
- قضاوت درباره Infrastructure as Code، Git و چرخه Change فقط از روی وجود Configuration
- نادیده گرفتن Dependencyها و مسیر واقعی Packet/State
- انجام Clear/Disable گسترده قبل از جمعآوری Evidence
تمرین عملی
- یک Diagram یا State Flow برای Infrastructure as Code، Git و چرخه Change رسم کن
- نمونه Configuration/Policy Infrastructure as Code، Git و چرخه Change را در Lab بررسی کن
- خروجی Verification را قبل و بعد از یک Test مقایسه کن
- یک Failure عمدی بساز و Root Cause را با Runbook پیدا کن
نکتههایی که باید با خودت ببری
- Repository باید Source of Truth یا بخشی از آن باشد و ساختار Site/Device/Role روشن داشته باشد
- Engineer Change را در Branch انجام میدهد، Commit معنیدار میسازد و Pull Request برای Review باز میکند
- Lint Syntax، Schema Validation، Unit/Test Logic و Lab/Simulation میتوانند خطا را قبل از Device واقعی بگیرند
- Deploy باید Batch و Approval مناسب داشته باشد و Post-check Desired vs Actual را Verify کند
- Drift زمانی است که Actual Config با Repository متفاوت شود؛ مثلاً Emergency CLI Change ثبت نشده باشد
خودسنجی
Desired State و Repository چه مسئلهای را حل یا توضیح میدهد؟
Repository باید Source of Truth یا بخشی از آن باشد و ساختار Site/Device/Role روشن داشته باشد.
در Branch، Commit و Pull Request مهمترین State یا جریان چیست؟
Engineer Change را در Branch انجام میدهد، Commit معنیدار میسازد و Pull Request برای Review باز میکند.
قبل از Lint، Test و Pre-Deployment Validation چه کاری ضروری است؟
Baseline، Scope و Rollback مشخص شود.
اصل کلیدی Configuration Drift و Reconciliation چیست؟
هر Test باید یک فرضیه را با Evidence تأیید یا رد کند.
منابع مرجع این درس
برای ذخیره پیشرفت وارد حساب شو
حساب کاربری برای آزمون و ثبت مرحلهها استفاده میشود
