با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
Device و Server و سرویسها را پیدا کن
در شروع ارزیابی نهایی Inventory را از واقعیت محیط بساز: دستگاهها، سرورها، سرویسها و ارتباطهای مهم را پیدا و با مستند موجود مقایسه کن؛ چیز ناشناخته را حدس نزن مستندسازی زیرساخت باید آنقدر دقیق باشد که وضعیت فعلی را بدون تکیه به حافظه افراد بازسازی کند؛ Inventory داراییها، Diagram ارتباطات، IP Plan، VLANها، نقش Serverها، مسیر Backup، وابستگی سرویسها و تاریخچه تغییرات هر کدام بخشی از تصویر هستند؛ اطلاعات Credential بهتر است در محل امن و جدا از سند عمومی زیرساخت نگهداری شود؛ هر تغییر مهم نیز باید بعد از اجرا در مستندات منعکس شود تا سند با محیط واقعی فاصله نگیرد برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که وقتی چند مشکل همزمان ارائه میشوند، اولویت را بر اساس اثر کسبوکار، امنیت و گستره خرابی تعیین کن؛ سپس کار را به واحدهای قابل کنترل تقسیم کن؛ پس از رفع هر مورد، Validation و Closure انجام بده و اگر Fix موقت است آن را صریح ثبت کن تا بهعنوان حل دائمی فراموش نشود
IP و VLAN و Uplink ثبت شوند
VLAN یک Broadcast Domain منطقی جدا روی زیرساخت Switch میسازد؛ کاربران دو VLAN برای ارتباط به Routing نیاز دارند VLAN امنیت کامل نیست؛ Policy بین VLANها هم مهم است نشانی IP هویت منطقی Interface در لایه شبکه است و باید همراه Prefix یا Subnet Mask تفسیر شود؛ Prefix مشخص میکند کدام بخش نشانی برای شبکه و کدام بخش برای Host استفاده میشود و همین موضوع تعیین میکند مقصد محلی است یا باید به Router فرستاده شود؛ در عیبیابی، فقط دیدن یک IP کافی نیست و باید Prefix، Gateway، DNS، روش دریافت تنظیمات، Route Table و احتمال وجود نشانی تکراری نیز بررسی شوند VLAN یک Broadcast Domain منطقی ایجاد میکند و به سازمان اجازه میدهد جداسازی شبکه را مستقل از محل فیزیکی کاربران انجام دهد؛ Access Port معمولاً ترافیک یک VLAN را برای End Device حمل میکند و Trunk چند VLAN را با Tag ۸۰۲.۱Q بین تجهیزات منتقل میکند؛ برای عیبیابی باید VLAN ID در دو سر لینک، وضعیت Tag و Untag، Native VLAN در صورت استفاده و عضویت پورتها با طراحی شبکه مقایسه شوند؛ برای این بخش، تمرکز عملی روی «IP و VLAN و Uplink ثبت شوند» است و باید بتوانی آن را از مفاهیم نزدیک در درس «کشف زیرساخت و Inventory اولیه» جدا تشخیص بدهی
وابستگی سرویسها مشخص شود
وابستگی یعنی یک سرویس یا برنامه برای کار کردن به جزء دیگری نیاز دارد؛ توقف جزء پایه میتواند چند سرویس ظاهراً نامرتبط را همزمان خراب کند مستندسازی زیرساخت باید آنقدر دقیق باشد که وضعیت فعلی را بدون تکیه به حافظه افراد بازسازی کند؛ Inventory داراییها، Diagram ارتباطات، IP Plan، VLANها، نقش Serverها، مسیر Backup، وابستگی سرویسها و تاریخچه تغییرات هر کدام بخشی از تصویر هستند؛ اطلاعات Credential بهتر است در محل امن و جدا از سند عمومی زیرساخت نگهداری شود؛ هر تغییر مهم نیز باید بعد از اجرا در مستندات منعکس شود تا سند با محیط واقعی فاصله نگیرد برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که در آزمون نهایی باید همان مدل کاری محیط واقعی را بهکار ببری: Asset و Dependency را بشناس، Scope رخداد را محدود کن، Evidence جمع کن، فرضیه بساز، Test کمریسک انجام بده و نتیجه را مستند کن؛ پاسخ درست فقط رسیدن اتفاقی به Fix نیست و باید بتوانی توضیح دهی چرا آن اقدام با شواهد سازگار بود
Backup و Monitoring بررسی شوند
Monitoring Metric و وضعیت سرویس را در طول زمان جمع میکند تا خرابی و روند ظرفیت زودتر دیده شود؛ وضعیت پایه عادی را بشناس تا Alert معنی داشته باشد فقط در دسترس/از دسترس خارج کافی نیست؛ تجربه واقعی سرویس هم مهم است Backup نسخهای جدا از داده اصلی برای بازیابی بعد از حذف، خرابی یا حادثه است؛ موفقیت Job، محل نگهداری، Retention و Test Restore را با هم ببین کپی روی همان Storage اصلی در برابر خرابی همان Storage محافظت کافی نمیدهد Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که وقتی چند مشکل همزمان ارائه میشوند، اولویت را بر اساس اثر کسبوکار، امنیت و گستره خرابی تعیین کن؛ سپس کار را به واحدهای قابل کنترل تقسیم کن؛ پس از رفع هر مورد، Validation و Closure انجام بده و اگر Fix موقت است آن را صریح ثبت کن تا بهعنوان حل دائمی فراموش نشود
Inventory و Diagram اولیه تحویل بده
Inventory فهرست کنترلشده تجهیزات و اطلاعاتی مانند مدل، Serial، محل، مسئول و وضعیت است؛ شناسه یکتا و تاریخ تغییر کمک میکند دستگاه را اشتباه نگیری فایل قدیمی و بدون مالک میتواند از نداشتن Inventory بدتر باشد RAM فضای کاری موقت سیستم برای دادهها و کدهای در حال استفاده است و با ذخیرهسازی دائمی تفاوت دارد؛ وقتی حافظه آزاد کم میشود، سیستمعامل ناچار میشود بخشی از دادههای کماستفاده را به حافظه مجازی منتقل کند و همین موضوع میتواند تأخیر را بیشتر کند؛ در بررسی عملی، ظرفیت نصبشده، ظرفیت قابل استفاده، مصرف هر Process، خطاهای سختافزاری و سازگاری نسل و مشخصات ماژولها باید کنار هم دیده شوند مستندسازی زیرساخت باید آنقدر دقیق باشد که وضعیت فعلی را بدون تکیه به حافظه افراد بازسازی کند؛ Inventory داراییها، Diagram ارتباطات، IP Plan، VLANها، نقش Serverها، مسیر Backup، وابستگی سرویسها و تاریخچه تغییرات هر کدام بخشی از تصویر هستند؛ اطلاعات Credential بهتر است در محل امن و جدا از سند عمومی زیرساخت نگهداری شود؛ هر تغییر مهم نیز باید بعد از اجرا در مستندات منعکس شود تا سند با محیط واقعی فاصله نگیرد
فرض کن در شرکت مجازی آزمون نهایی مشکلی گزارش شده و احتمال میدهی به کشف زیرساخت و Inventory اولیه مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارها و روشهای کل دوره بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- فقط در دسترس/از دسترس خارج کافی نیست؛ تجربه واقعی سرویس هم مهم است
- Inventory فهرست کنترلشده تجهیزات و اطلاعاتی مانند مدل، Serial، محل، مسئول و وضعیت است؛ شناسه یکتا و تاریخ تغییر کمک میکند دستگاه را اشتباه نگیری
- تغییر دادن تنظیمات مرتبط با کشف زیرساخت و Inventory اولیه قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با کشف زیرساخت و Inventory اولیه، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با ابزارها و روشهای کل دوره وضعیت مرتبط با کشف زیرساخت و Inventory اولیه را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با کشف زیرساخت و Inventory اولیه بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- Device و Server و سرویسها را پیدا کن
- IP و VLAN و Uplink ثبت شوند
- وابستگی سرویسها مشخص شود
- Backup و Monitoring بررسی شوند
- Inventory و Diagram اولیه تحویل بده
- هیچ اقدام پرریسک بدون شواهد، Backup یا روش بازگشت قابل قبول نیست
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید Device و Server و سرویسها را پیدا کنی و از کجا میفهمی نتیجه درست است؟
در شروع ارزیابی نهایی Inventory را از واقعیت محیط بساز: دستگاهها، سرورها، سرویسها و ارتباطهای مهم را پیدا و با مستند موجود مقایسه کن؛ چیز ناشناخته را حدس نزن
این نکته را با یک مثال توضیح بده: IP و VLAN و Uplink ثبت شوند. بعد بگو در عمل چطور آن را بررسی میکنی.
VLAN یک Broadcast Domain منطقی جدا روی زیرساخت Switch میسازد؛ کاربران دو VLAN برای ارتباط به Routing نیاز دارند
این نکته را با یک مثال توضیح بده: وابستگی سرویسها مشخص شود. بعد بگو در عمل چطور آن را بررسی میکنی.
وابستگی یعنی یک سرویس یا برنامه برای کار کردن به جزء دیگری نیاز دارد؛ توقف جزء پایه میتواند چند سرویس ظاهراً نامرتبط را همزمان خراب کند
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
