با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست
نتیجه Success یا Failed ثبت شود
نتیجه تغییر را صریح ثبت کن: موفق، ناموفق یا موفق با مسئله باقی‌مانده؛ وضعیت مبهم باعث می‌شود تیم بعدی نداند بازگشت امن یا پیگیری لازم است Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
زمان واقعی با Plan مقایسه شود
مقایسه زمان واقعی با برنامه برای تغییرهای بعدی کمک می‌کند Window واقع‌بینانه‌تر تعیین شود و Stepهای کند یا پرخطا پیدا شوند Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که بعد از Change باید تفاوت بین «اجرا شد» و «موفق بود» را جدی بگیری؛ موفقیت زمانی است که سرویس مورد انتظار کار کند، Monitoring رفتار غیرعادی نشان ندهد و کاربر یا مالک سرویس در صورت نیاز تأیید کند؛ اگر نتیجه مطابق برنامه نیست، Rollback زودهنگام معمولاً امن‌تر از ادامه تغییرهای بداهه است در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
Documentation به‌روز شود
اگر IP، VLAN، Rule، Version یا Topology عوض شد، تغییر زمانی کامل است که مستند مرتبط هم به‌روزرسانی شود مستندسازی زیرساخت باید آن‌قدر دقیق باشد که وضعیت فعلی را بدون تکیه به حافظه افراد بازسازی کند؛ Inventory دارایی‌ها، Diagram ارتباطات، IP Plan، VLANها، نقش Serverها، مسیر Backup، وابستگی سرویس‌ها و تاریخچه تغییرات هر کدام بخشی از تصویر هستند؛ اطلاعات Credential بهتر است در محل امن و جدا از سند عمومی زیرساخت نگهداری شود؛ هر تغییر مهم نیز باید بعد از اجرا در مستندات منعکس شود تا سند با محیط واقعی فاصله نگیرد Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است نکته‌ای که هنگام پشتیبانی نباید از آن عبور کنی این است که مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
خرابی نیاز RCA دارد
اگر تغییر باعث رخداد مهم شد بعد از تثبیت سرویس RCA انجام بده تا نقص Plan، Test، تأیید یا اجرا مشخص و برای تغییر بعدی اصلاح شود اگر تغییر باعث رخداد مهم شد بعد از تثبیت سرویس بررسی کن مشکل از Plan، Test، اجرا، تأیید یا وابستگی ناشناخته بوده تا تکرار نشود Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
Lesson Learned برای تغییر بعدی ثبت شود
درس‌آموخته فقط گزارش اشتباه نیست؛ زمان واقعی، Stepهای مبهم، تست ناقص و وابستگی‌های تازه پیدا شده را ثبت کن و Template تغییر بعدی را بهتر کن Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، بعد از Change باید تفاوت بین «اجرا شد» و «موفق بود» را جدی بگیری؛ موفقیت زمانی است که سرویس مورد انتظار کار کند، Monitoring رفتار غیرعادی نشان ندهد و کاربر یا مالک سرویس در صورت نیاز تأیید کند؛ اگر نتیجه مطابق برنامه نیست، Rollback زودهنگام معمولاً امن‌تر از ادامه تغییرهای بداهه است نکته‌ای که هنگام پشتیبانی نباید از آن عبور کنی این است که مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
فرض کن در یک تغییر برنامه‌ریزی‌شده مشکلی گزارش شده و احتمال می‌دهی به بازبینی پس از تغییر مربوط باشد. قبل از تغییر، وضعیت فعلی را با Change Plan، ارزیابی ریسک، Backup و Rollback Plan بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباه‌ها را تکرار نکن
- درس‌آموخته فقط گزارش اشتباه نیست؛ زمان واقعی، Stepهای مبهم، تست ناقص و وابستگی‌های تازه پیدا شده را ثبت کن و Template تغییر بعدی را بهتر کن
- تغییر دادن تنظیمات مرتبط با بازبینی پس از تغییر قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجه‌گیری درباره بازبینی پس از تغییر فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با بازبینی پس از تغییر، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
- با Change Plan، ارزیابی ریسک، Backup و Rollback Plan وضعیت مرتبط با بازبینی پس از تغییر را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
- یک خطای فرضی مرتبط با بازبینی پس از تغییر بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند
نکته‌هایی که باید با خودت ببری
- نتیجه Success یا Failed ثبت شود
- زمان واقعی با Plan مقایسه شود
- Documentation به‌روز شود
- خرابی نیاز RCA دارد
- Lesson Learned برای تغییر بعدی ثبت شود
- هر Change باید زمان، ریسک، Backup و روش بازگشت مشخص داشته باشد
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: نتیجه Success یا Failed ثبت شود. بعد بگو در عمل چطور آن را بررسی می‌کنی.
نتیجه تغییر را صریح ثبت کن: موفق، ناموفق یا موفق با مسئله باقی‌مانده؛ وضعیت مبهم باعث می‌شود تیم بعدی نداند بازگشت امن یا پیگیری لازم است
این نکته را با یک مثال توضیح بده: زمان واقعی با Plan مقایسه شود. بعد بگو در عمل چطور آن را بررسی می‌کنی.
مقایسه زمان واقعی با برنامه برای تغییرهای بعدی کمک می‌کند Window واقع‌بینانه‌تر تعیین شود و Stepهای کند یا پرخطا پیدا شوند
این نکته را با یک مثال توضیح بده: Documentation به‌روز شود. بعد بگو در عمل چطور آن را بررسی می‌کنی.
اگر IP، VLAN، Rule، Version یا Topology عوض شد، تغییر زمانی کامل است که مستند مرتبط هم به‌روزرسانی شود
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود
