راینو

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

Key/Value، Object و List را از پایه توضیح بدهی
JSON Syntax و Data Type را در یک سناریوی واقعی تحلیل کنی
YAML Syntax و Indentation را با روش کنترل‌شده پیاده‌سازی کنی
Mapping داده شبکه به ساختار را با Evidence بررسی کنی
Troubleshooting Parsing و Schema را مرحله‌به‌مرحله عیب‌یابی کنی

Key/Value، Object و List

Object مجموعه Key/Value و List مجموعه مرتب چند Item است. Inventory یک Site می‌تواند Objectی با Name، Location و List Deviceها باشد. String، Number، Boolean و Null نوع داده‌اند و Toolها ممکن است تفاوت "۱۰" با ۱۰ را جدی بگیرند.

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

JSON example

{
  "hostname": "SW1",
  "vlans": [10, 20],
  "enabled": true
}

برای JSON، YAML و نمایش داده در Automation شبکه، فهم Key/Value، Object و List باید همراه با مرزبندی دقیق انجام شود. قبل از هر تصمیم، مشخص کن این مفهوم در کدام لایه یا بخش از مسیر قرار دارد، چه Stateی ایجاد می‌کند و چه چیزی خارج از مسئولیت آن است. بسیاری از خطاهای عملی از اینجا شروع می‌شوند که یک علامت مشترک به فناوری اشتباه نسبت داده می‌شود. اگر بتوانی بگویی «این بخش دقیقاً چه چیزی را ثابت می‌کند و چه چیزی را ثابت نمی‌کند»، هنگام Incident به‌جای حدس زدن، Failure Domain را کوچک می‌کنی. در محیط واقعی همیشه فناوری مجاور، مسیر برگشت و Policyهای بین راه را هم در ذهن نگه دار.

JSON Syntax و Data Type

JSON از {} برای Object و [] برای Array استفاده می‌کند، Keyها و Stringها معمولاً در Double Quote هستند و Trailing Comma مجاز نیست. API Response اغلب JSON است و Status Code/Schema مشخص می‌کند کدام Fieldها وجود دارند.

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

JSON nested object

{
  "interfaces": [{"name":"Gi1/0/1","mode":"access","vlan":10}]
}

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

YAML Syntax و Indentation

YAML بیشتر بر Indentation تکیه دارد و - برای List Item رایج است. Tab/Space یا Indentation اشتباه می‌تواند Parsing را خراب کند. Valueهایی مثل yes/no یا تاریخ ممکن است توسط Parser به Type خاص تبدیل شوند؛ در Configuration حساس Explicit String کمک می‌کند.

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

YAML example

hostname: SW1
vlans:
  - 10
  - 20
enabled: true

پیاده‌سازی YAML Syntax و Indentation در شبکه شرکت باید به سه فاز 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 سازمان سازگار بماند.

Mapping داده شبکه به ساختار

Network Data را می‌توان به Interface Object، VLAN List، Device Inventory یا Desired State تبدیل کرد. ساختار باید Consistent باشد تا Automation بتواند روی صدها Device Loop بزند. Schema Validation خطای Typo یا Missing Field را قبل از Change واقعی پیدا می‌کند.

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

Data model

site -> devices[] -> interfaces[] -> desired attributes

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

Troubleshooting Parsing و Schema

اگر Parser Error است، Line/Column، Quote، Comma و Indentation را بررسی کن. اگر Parse موفق ولی Automation رفتار غلط دارد، Data Type و Schema را ببین. Secret را داخل فایل Plaintext Repository قرار نده؛ Secret Management جدا لازم است.

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

Troubleshooting

Parse error -> syntax
Wrong behavior -> type/schema/value

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

سناریوی عملی

Playbook YAML بدون اجرا Fail می‌شود. خطا Line 12 را نشان می‌دهد؛ یک Task با Tab و Indentation نامعتبر نوشته شده است. پس از اصلاح Syntax، Check Mode اجرا می‌شود. هیچ SSH یا ACL شبکه‌ای مشکل نداشت.

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

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

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

تمرین عملی

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

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

Object مجموعه Key/Value و List مجموعه مرتب چند Item است
JSON از {} برای Object و [] برای Array استفاده می‌کند، Keyها و Stringها معمولاً در Double Quote هستند و Trailing Comma مجاز نیست
YAML بیشتر بر Indentation تکیه دارد و - برای List Item رایج است
Network Data را می‌توان به Interface Object، VLAN List، Device Inventory یا Desired State تبدیل کرد
اگر Parser Error است، Line/Column، Quote، Comma و Indentation را بررسی کن

خودسنجی

Key/Value، Object و List چه مسئله‌ای را حل یا توضیح می‌دهد؟

Object مجموعه Key/Value و List مجموعه مرتب چند Item است.

در JSON Syntax و Data Type مهم‌ترین State یا جریان چیست؟

JSON از {} برای Object و [] برای Array استفاده می‌کند، Keyها و Stringها معمولاً در Double Quote هستند و Trailing Comma مجاز نیست.

قبل از YAML Syntax و Indentation چه کاری ضروری است؟

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

اصل کلیدی Troubleshooting Parsing و Schema چیست؟

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

منابع رسمی

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

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

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

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

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

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