با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
فقط Step تأییدشده اجرا شود
در حین تغییر از Plan تأییدشده خارج نشو مگر طبق فرایند اضطراری و با ثبت دلیل؛ تغییر بداهه زیر فشار میتواند محدوده و خطر را بدون اطلاع تیم افزایش دهد Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
انحراف ثبت شود
اگر حین اجرا از Plan خارج شدی دلیل و اقدام جدید را ثبت کن؛ تغییر ثبتنشده بعداً تحلیل رخداد و بازگشت امن را سخت میکند Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: بعد از Change باید تفاوت بین «اجرا شد» و «موفق بود» را جدی بگیری؛ موفقیت زمانی است که سرویس مورد انتظار کار کند، Monitoring رفتار غیرعادی نشان ندهد و کاربر یا مالک سرویس در صورت نیاز تأیید کند؛ اگر نتیجه مطابق برنامه نیست، Rollback زودهنگام معمولاً امنتر از ادامه تغییرهای بداهه است برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
Health Check فنی اجرا شود
بعد از تغییر فقط Ping کافی نیست؛ Health Check باید سرویس اصلی، وابستگی و سناریوی واقعی کاربر را بر اساس معیار موفقیت تست کند Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، بعد از Change باید تفاوت بین «اجرا شد» و «موفق بود» را جدی بگیری؛ موفقیت زمانی است که سرویس مورد انتظار کار کند، Monitoring رفتار غیرعادی نشان ندهد و کاربر یا مالک سرویس در صورت نیاز تأیید کند؛ اگر نتیجه مطابق برنامه نیست، Rollback زودهنگام معمولاً امنتر از ادامه تغییرهای بداهه است برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
سرویس کسبوکار هم تست شود
بعد از تغییر علاوه بر تست فنی، سناریوی اصلی کسبوکار را هم آزمایش کن؛ مثلاً کاربر واقعاً بتواند وارد نرمافزار شود یا فایل را باز کند Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که مدیریت تغییر برای کند کردن کار نیست؛ هدف این است که ریسک شناخته و کنترل شود؛ Scope، وابستگی، زمان مناسب، مسئول اجرا، Backup یا Rollback، معیار موفقیت و روش Validation قبل از شروع مشخص شوند؛ سطح کنترل باید با ریسک تغییر متناسب باشد و تغییر اضطراری نیز همچنان نیاز به ثبت و بازبینی پس از اجرا دارد
Monitoring بعد تغییر ادامه یابد
Monitoring Metric و وضعیت سرویس را در طول زمان جمع میکند تا خرابی و روند ظرفیت زودتر دیده شود؛ وضعیت پایه عادی را بشناس تا Alert معنی داشته باشد فقط در دسترس/از دسترس خارج کافی نیست؛ تجربه واقعی سرویس هم مهم است پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است
فرض کن در یک تغییر برنامهریزیشده مشکلی گزارش شده و احتمال میدهی به اجرای تغییر و بررسی نهایی مربوط باشد. قبل از تغییر، وضعیت فعلی را با Change Plan، ارزیابی ریسک، Backup و Rollback Plan بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- بعد از تغییر فقط Ping کافی نیست؛ Health Check باید سرویس اصلی، وابستگی و سناریوی واقعی کاربر را بر اساس معیار موفقیت تست کند
- فقط در دسترس/از دسترس خارج کافی نیست؛ تجربه واقعی سرویس هم مهم است
- تغییر دادن تنظیمات مرتبط با اجرای تغییر و بررسی نهایی قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با اجرای تغییر و بررسی نهایی، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با Change Plan، ارزیابی ریسک، Backup و Rollback Plan وضعیت مرتبط با اجرای تغییر و بررسی نهایی را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با اجرای تغییر و بررسی نهایی بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- فقط Step تأییدشده اجرا شود
- انحراف ثبت شود
- Health Check فنی اجرا شود
- سرویس کسبوکار هم تست شود
- Monitoring بعد تغییر ادامه یابد
- هر Change باید زمان، ریسک، Backup و روش بازگشت مشخص داشته باشد
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: فقط Step تأییدشده اجرا شود. بعد بگو در عمل چطور آن را بررسی میکنی.
در حین تغییر از Plan تأییدشده خارج نشو مگر طبق فرایند اضطراری و با ثبت دلیل. تغییر بداهه زیر فشار میتواند محدوده و خطر را بدون اطلاع تیم افزایش دهد
این نکته را با یک مثال توضیح بده: انحراف ثبت شود. بعد بگو در عمل چطور آن را بررسی میکنی.
اگر حین اجرا از Plan خارج شدی دلیل و اقدام جدید را ثبت کن؛ تغییر ثبتنشده بعداً تحلیل رخداد و بازگشت امن را سخت میکند
این نکته را با یک مثال توضیح بده: Health Check فنی اجرا شود. بعد بگو در عمل چطور آن را بررسی میکنی.
بعد از تغییر فقط Ping کافی نیست؛ Health Check باید سرویس اصلی، وابستگی و سناریوی واقعی کاربر را بر اساس معیار موفقیت تست کند
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
