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