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