با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست
Window اجرا و Test و بازگشت امن را پوشش دهد
بازگشت امن، برنامه و اقدام بازگرداندن سیستم به وضعیت قبل از تغییر است؛ Trigger مشخص کن که چه زمانی باید تغییر را متوقف و برگردانی داشتن Backup بدون دانستن روش و زمان Restore، بازگشت امن کامل نیست Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: بعد از Change باید تفاوت بین «اجرا شد» و «موفق بود» را جدی بگیری؛ موفقیت زمانی است که سرویس مورد انتظار کار کند، Monitoring رفتار غیرعادی نشان ندهد و کاربر یا مالک سرویس در صورت نیاز تأیید کند؛ اگر نتیجه مطابق برنامه نیست، Rollback زودهنگام معمولاً امن‌تر از ادامه تغییرهای بداهه است
مسئول و کاربرها مطلع شوند
پیش از بازه نگهداری مسئول سرویس و کاربران تحت تأثیر را درباره زمان، اثر احتمالی و کانال اطلاع‌رسانی آگاه کن تا اختلال برنامه‌ریزی‌شده غافلگیرکننده نباشد Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: بعد از Change باید تفاوت بین «اجرا شد» و «موفق بود» را جدی بگیری؛ موفقیت زمانی است که سرویس مورد انتظار کار کند، Monitoring رفتار غیرعادی نشان ندهد و کاربر یا مالک سرویس در صورت نیاز تأیید کند؛ اگر نتیجه مطابق برنامه نیست، Rollback زودهنگام معمولاً امن‌تر از ادامه تغییرهای بداهه است برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
تغییر هم‌زمان زیاد نشود
تا حد امکان تغییرهای مستقل را هم‌زمان انجام نده؛ اگر چند تغییر با هم اجرا شوند تشخیص علت در صورت خرابی و بازگشت امن دشوارتر می‌شود Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: بعد از Change باید تفاوت بین «اجرا شد» و «موفق بود» را جدی بگیری؛ موفقیت زمانی است که سرویس مورد انتظار کار کند، Monitoring رفتار غیرعادی نشان ندهد و کاربر یا مالک سرویس در صورت نیاز تأیید کند؛ اگر نتیجه مطابق برنامه نیست، Rollback زودهنگام معمولاً امن‌تر از ادامه تغییرهای بداهه است اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
Contact افراد کلیدی معلوم باشد
در بازه نگهداری بدان چه کسی اجرا می‌کند، چه کسی تأیید کسب‌وکار می‌دهد و در صورت مشکل چه Vendor یا مدیر فنی باید در دسترس باشد Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
زمان کافی برای برگشت بماند
Window را طوری برنامه‌ریزی کن که بعد از اجرا زمان برای Test و در صورت شکست زمان برای بازگشت امن باقی بماند؛ شروع دیرهنگام تغییر ریسک را زیاد می‌کند Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است نکته‌ای که هنگام پشتیبانی نباید از آن عبور کنی این است که مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
فرض کن در یک تغییر برنامه‌ریزی‌شده مشکلی گزارش شده و احتمال می‌دهی به بازه نگهداری و هماهنگی مربوط باشد. قبل از تغییر، وضعیت فعلی را با Change Plan، ارزیابی ریسک، Backup و Rollback Plan بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباه‌ها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با بازه نگهداری و هماهنگی قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجه‌گیری درباره بازه نگهداری و هماهنگی فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با بازه نگهداری و هماهنگی، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
- با Change Plan، ارزیابی ریسک، Backup و Rollback Plan وضعیت مرتبط با بازه نگهداری و هماهنگی را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
- یک خطای فرضی مرتبط با بازه نگهداری و هماهنگی بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند
نکته‌هایی که باید با خودت ببری
- Window اجرا و Test و بازگشت امن را پوشش دهد
- مسئول و کاربرها مطلع شوند
- تغییر هم‌زمان زیاد نشود
- Contact افراد کلیدی معلوم باشد
- زمان کافی برای برگشت بماند
- هر Change باید زمان، ریسک، Backup و روش بازگشت مشخص داشته باشد
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: Window اجرا و Test و بازگشت امن را پوشش دهد. بعد بگو در عمل چطور آن را بررسی می‌کنی.
بازگشت امن، برنامه و اقدام بازگرداندن سیستم به وضعیت قبل از تغییر است؛ Trigger مشخص کن که چه زمانی باید تغییر را متوقف و برگردانی
این نکته را با یک مثال توضیح بده: مسئول و کاربرها مطلع شوند. بعد بگو در عمل چطور آن را بررسی می‌کنی.
پیش از بازه نگهداری مسئول سرویس و کاربران تحت تأثیر را درباره زمان، اثر احتمالی و کانال اطلاع‌رسانی آگاه کن تا اختلال برنامه‌ریزی‌شده غافلگیرکننده نباشد
این نکته را با یک مثال توضیح بده: تغییر هم‌زمان زیاد نشود. بعد بگو در عمل چطور آن را بررسی می‌کنی.
تا حد امکان تغییرهای مستقل را هم‌زمان انجام نده؛ اگر چند تغییر با هم اجرا شوند تشخیص علت در صورت خرابی و بازگشت امن دشوارتر می‌شود
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود
