با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
Hostname و IP و OS ثبت شوند
نام میزبان باید در شبکه یکتا و قابل فهم باشد؛ نام تکراری میتواند در DNS، مدیریت دارایی و عضویت Domain سردرگمی بسازد نشانی IP هویت منطقی Interface در لایه شبکه است و باید همراه Prefix یا Subnet Mask تفسیر شود؛ Prefix مشخص میکند کدام بخش نشانی برای شبکه و کدام بخش برای Host استفاده میشود و همین موضوع تعیین میکند مقصد محلی است یا باید به Router فرستاده شود؛ در عیبیابی، فقط دیدن یک IP کافی نیست و باید Prefix، Gateway، DNS، روش دریافت تنظیمات، Route Table و احتمال وجود نشانی تکراری نیز بررسی شوند برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که اطلاعات محرمانه مانند Password و Recovery Key بهتر است از سند عمومی زیرساخت جدا و در مخزن امن مدیریت شوند؛ در سند اصلی میتوان محل نگهداری Credential و مسئول آن را ثبت کرد بدون افشای خود Secret؛ بعد از هر تغییر مهم، Update مستند باید بخشی از Closure کار باشد تا نسخه مستند با شبکه واقعی اختلاف پیدا نکند
Role و نرمافزار مشخص باشند
در فهرست Server فقط نام و IP کافی نیست؛ Role سرور و نرمافزارهای مهم آن را ثبت کن تا هنگام خرابی بدانیم چه سرویسهای کسبوکار تحت تأثیرند در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: اطلاعات محرمانه مانند Password و Recovery Key بهتر است از سند عمومی زیرساخت جدا و در مخزن امن مدیریت شوند؛ در سند اصلی میتوان محل نگهداری Credential و مسئول آن را ثبت کرد بدون افشای خود Secret؛ بعد از هر تغییر مهم، Update مستند باید بخشی از Closure کار باشد تا نسخه مستند با شبکه واقعی اختلاف پیدا نکند نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که سند خوب باید به یک نفر دیگر امکان بدهد محیط را بدون حدس زدن بفهمد؛ Diagram، Inventory، IP Plan، VLAN Plan، Server Roles، Backup Flow، Contactها و تاریخچه Change هر کدام هدف جدا دارند؛ سندی که همه چیز را در یک صفحه یا فقط در ذهن یک نفر نگه دارد در زمان خرابی کمک محدودی میکند برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی
مسئول فنی و کسبوکاری معلوم باشد
مسئول فنی کسی است که سرویس را نگهداری میکند و مسئول کسبوکاری کسی است که اثر سرویس بر کار سازمان را میشناسد؛ برای سرویس حیاتی هر دو باید مشخص باشند برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که اطلاعات محرمانه مانند Password و Recovery Key بهتر است از سند عمومی زیرساخت جدا و در مخزن امن مدیریت شوند؛ در سند اصلی میتوان محل نگهداری Credential و مسئول آن را ثبت کرد بدون افشای خود Secret؛ بعد از هر تغییر مهم، Update مستند باید بخشی از Closure کار باشد تا نسخه مستند با شبکه واقعی اختلاف پیدا نکند برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که سند خوب باید به یک نفر دیگر امکان بدهد محیط را بدون حدس زدن بفهمد؛ Diagram، Inventory، IP Plan، VLAN Plan، Server Roles، Backup Flow، Contactها و تاریخچه Change هر کدام هدف جدا دارند؛ سندی که همه چیز را در یک صفحه یا فقط در ذهن یک نفر نگه دارد در زمان خرابی کمک محدودی میکند
وابستگیها ثبت شوند
وابستگی یعنی یک سرویس یا برنامه برای کار کردن به جزء دیگری نیاز دارد؛ توقف جزء پایه میتواند چند سرویس ظاهراً نامرتبط را همزمان خراب کند نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که اطلاعات محرمانه مانند Password و Recovery Key بهتر است از سند عمومی زیرساخت جدا و در مخزن امن مدیریت شوند؛ در سند اصلی میتوان محل نگهداری Credential و مسئول آن را ثبت کرد بدون افشای خود Secret؛ بعد از هر تغییر مهم، Update مستند باید بخشی از Closure کار باشد تا نسخه مستند با شبکه واقعی اختلاف پیدا نکند در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: سند خوب باید به یک نفر دیگر امکان بدهد محیط را بدون حدس زدن بفهمد؛ Diagram، Inventory، IP Plan، VLAN Plan، Server Roles، Backup Flow، Contactها و تاریخچه Change هر کدام هدف جدا دارند؛ سندی که همه چیز را در یک صفحه یا فقط در ذهن یک نفر نگه دارد در زمان خرابی کمک محدودی میکند برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی
Backup و Maintenance قابل پیگیری باشند
Backup نسخهای جدا از داده اصلی برای بازیابی بعد از حذف، خرابی یا حادثه است؛ موفقیت Job، محل نگهداری، Retention و Test Restore را با هم ببین کپی روی همان Storage اصلی در برابر خرابی همان Storage محافظت کافی نمیدهد Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است
فرض کن در مستندات زیرساخت مشکلی گزارش شده و احتمال میدهی به فهرست Server و سرویسها مربوط باشد. قبل از تغییر، وضعیت فعلی را با Topology، Inventory، IP Plan و مستندات دسترسی بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- در فهرست Server فقط نام و IP کافی نیست؛ Role سرور و نرمافزارهای مهم آن را ثبت کن تا هنگام خرابی بدانیم چه سرویسهای کسبوکار تحت تأثیرند
- تغییر دادن تنظیمات مرتبط با فهرست Server و سرویسها قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره فهرست Server و سرویسها فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با فهرست Server و سرویسها، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با Topology، Inventory، IP Plan و مستندات دسترسی وضعیت مرتبط با فهرست Server و سرویسها را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با فهرست Server و سرویسها بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- Hostname و IP و OS ثبت شوند
- Role و نرمافزار مشخص باشند
- مسئول فنی و کسبوکاری معلوم باشد
- وابستگیها ثبت شوند
- Backup و Maintenance قابل پیگیری باشند
- Secretها را از مستند عمومی زیرساخت جدا نگه دار
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: Hostname و IP و OS ثبت شوند. بعد بگو در عمل چطور آن را بررسی میکنی.
نام میزبان باید در شبکه یکتا و قابل فهم باشد؛ نام تکراری میتواند در DNS، مدیریت دارایی و عضویت Domain سردرگمی بسازد
این نکته را با یک مثال توضیح بده: Role و نرمافزار مشخص باشند. بعد بگو در عمل چطور آن را بررسی میکنی.
در فهرست Server فقط نام و IP کافی نیست؛ Role سرور و نرمافزارهای مهم آن را ثبت کن تا هنگام خرابی بدانیم چه سرویسهای کسبوکار تحت تأثیرند
این نکته را با یک مثال توضیح بده: مسئول فنی و کسبوکاری معلوم باشد. بعد بگو در عمل چطور آن را بررسی میکنی.
مسئول فنی کسی است که سرویس را نگهداری میکند و مسئول کسبوکاری کسی است که اثر سرویس بر کار سازمان را میشناسد. برای سرویس حیاتی هر دو باید مشخص باشند
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
