با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست
تاریخ و اجراکننده و دلیل تغییر ثبت شود
گزارش تغییرات باید حداقل زمان، اجراکننده، دلیل، موارد تغییرکرده و نتیجه را ثبت کند تا هنگام رخداد بتوان ارتباط زمانی بین تغییر و مشکل را بررسی کرد Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است نکته‌ای که هنگام پشتیبانی نباید از آن عبور کنی این است که اطلاعات محرمانه مانند Password و Recovery Key بهتر است از سند عمومی زیرساخت جدا و در مخزن امن مدیریت شوند؛ در سند اصلی می‌توان محل نگهداری Credential و مسئول آن را ثبت کرد بدون افشای خود Secret؛ بعد از هر تغییر مهم، Update مستند باید بخشی از Closure کار باشد تا نسخه مستند با شبکه واقعی اختلاف پیدا نکند
Before و After مهم است
در گزارش تغییرات مقدار یا وضعیت قبل و بعد از تغییر را ثبت کن تا هم بازگشت امن روشن باشد و هم نفر بعدی دقیق بداند چه چیزی عوض شده است Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که سند خوب باید به یک نفر دیگر امکان بدهد محیط را بدون حدس زدن بفهمد؛ Diagram، Inventory، IP Plan، VLAN Plan، Server Roles، Backup Flow، Contactها و تاریخچه Change هر کدام هدف جدا دارند؛ سندی که همه چیز را در یک صفحه یا فقط در ذهن یک نفر نگه دارد در زمان خرابی کمک محدودی می‌کند
Ticket یا تأیید Reference شود
اگر تغییر از Ticket یا تأیید رسمی آمده است شماره یا مرجع آن را در گزارش تغییرات بگذار تا تصمیم، مجوز و سابقه فنی به هم متصل بمانند Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، سند خوب باید به یک نفر دیگر امکان بدهد محیط را بدون حدس زدن بفهمد؛ Diagram، Inventory، IP Plan، VLAN Plan، Server Roles، Backup Flow، Contactها و تاریخچه Change هر کدام هدف جدا دارند؛ سندی که همه چیز را در یک صفحه یا فقط در ذهن یک نفر نگه دارد در زمان خرابی کمک محدودی می‌کند
بازگشت امن ثبت شود
بازگشت امن، برنامه و اقدام بازگرداندن سیستم به وضعیت قبل از تغییر است؛ Trigger مشخص کن که چه زمانی باید تغییر را متوقف و برگردانی داشتن Backup بدون دانستن روش و زمان Restore، بازگشت امن کامل نیست Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: سند خوب باید به یک نفر دیگر امکان بدهد محیط را بدون حدس زدن بفهمد؛ Diagram، Inventory، IP Plan، VLAN Plan، Server Roles، Backup Flow، Contactها و تاریخچه Change هر کدام هدف جدا دارند؛ سندی که همه چیز را در یک صفحه یا فقط در ذهن یک نفر نگه دارد در زمان خرابی کمک محدودی می‌کند
گزارش تغییرات در RCA مفید است
گزارش تغییر ثبت می‌کند چه چیزی، چه زمانی، توسط چه کسی و چرا تغییر کرده است؛ هنگام رخداد Timeline تغییرها می‌تواند سریعاً سرنخ بدهد ثبت «تنظیمات اصلاح شد» بدون جزئیات قابل استفاده نیست گزارش رویداد ثبت زمانی اتفاق‌ها و خطاهای سیستم است و برای ساختن Timeline کمک می‌کند؛ زمان گزارش کاربر را با Log همان بازه مقایسه کن هر خطای ثبت‌شده علت اصلی نیست و باید با نشانه مرتبط شود Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که سند خوب باید به یک نفر دیگر امکان بدهد محیط را بدون حدس زدن بفهمد؛ Diagram، Inventory، IP Plan، VLAN Plan، Server Roles، Backup Flow، Contactها و تاریخچه Change هر کدام هدف جدا دارند؛ سندی که همه چیز را در یک صفحه یا فقط در ذهن یک نفر نگه دارد در زمان خرابی کمک محدودی می‌کند
فرض کن در مستندات زیرساخت مشکلی گزارش شده و احتمال می‌دهی به گزارش تغییرات مربوط باشد. قبل از تغییر، وضعیت فعلی را با Topology، Inventory، IP Plan و مستندات دسترسی بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباه‌ها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با گزارش تغییرات قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجه‌گیری درباره گزارش تغییرات فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با گزارش تغییرات، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
- با Topology، Inventory، IP Plan و مستندات دسترسی وضعیت مرتبط با گزارش تغییرات را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
- یک خطای فرضی مرتبط با گزارش تغییرات بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند
نکته‌هایی که باید با خودت ببری
- تاریخ و اجراکننده و دلیل تغییر ثبت شود
- Before و After مهم است
- Ticket یا تأیید Reference شود
- بازگشت امن ثبت شود
- گزارش تغییرات در RCA مفید است
- Secretها را از مستند عمومی زیرساخت جدا نگه دار
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: تاریخ و اجراکننده و دلیل تغییر ثبت شود. بعد بگو در عمل چطور آن را بررسی می‌کنی.
گزارش تغییرات باید حداقل زمان، اجراکننده، دلیل، موارد تغییرکرده و نتیجه را ثبت کند تا هنگام رخداد بتوان ارتباط زمانی بین تغییر و مشکل را بررسی کرد
این نکته را با یک مثال توضیح بده: Before و After مهم است. بعد بگو در عمل چطور آن را بررسی می‌کنی.
در گزارش تغییرات مقدار یا وضعیت قبل و بعد از تغییر را ثبت کن تا هم بازگشت امن روشن باشد و هم نفر بعدی دقیق بداند چه چیزی عوض شده است
این نکته را با یک مثال توضیح بده: Ticket یا تأیید Reference شود. بعد بگو در عمل چطور آن را بررسی می‌کنی.
اگر تغییر از Ticket یا تأیید رسمی آمده است شماره یا مرجع آن را در گزارش تغییرات بگذار تا تصمیم، مجوز و سابقه فنی به هم متصل بمانند
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود
