با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
Configuration فعلی ذخیره شود
قبل از تغییر از Config یا مقدارهای فعلی خروجی بگیر تا هم مقایسه بعد از کار ممکن باشد و هم بازگشت امن فقط بر حافظه متکی نباشد Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است
Health قبل تغییر ثبت شود
بررسی قبل از تغییر باید سلامت سرویس و شاخصهای اصلی قبل از تغییر را ثبت کند؛ بدون وضعیت قبل، بعداً سخت میتوان فهمید یک خطا جدید است یا از قبل وجود داشته Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است
Capacity و وابستگی بررسی شود
وابستگی یعنی یک سرویس یا برنامه برای کار کردن به جزء دیگری نیاز دارد؛ توقف جزء پایه میتواند چند سرویس ظاهراً نامرتبط را همزمان خراب کند Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است
Backup قابل Restore باشد
Restore عمل بازگرداندن داده یا سیستم از Backup است و تنها راه اثبات قابل استفاده بودن Backup است؛ بهصورت دورهای Restore آزمایشی با سناریوی واقعی انجام بده صرف دیدن وضعیت موفق Job تضمین بازیابی نیست Backup نسخهای جدا از داده اصلی برای بازیابی بعد از حذف، خرابی یا حادثه است؛ موفقیت Job، محل نگهداری، Retention و Test Restore را با هم ببین کپی روی همان Storage اصلی در برابر خرابی همان Storage محافظت کافی نمیدهد Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است
بررسی قبل از تغییر مشکل قدیمی را از تغییر جدا میکند
بررسی قبل از تغییر وضعیت سلامت موجود را ثبت میکند تا بعداً معلوم باشد خطا از قبل وجود داشته یا بعد از تغییر ایجاد شده است Backup زمانی ارزش عملی دارد که بازیابی آن قابل انجام و آزموده شده باشد؛ RPO مشخص میکند چه مقدار از داده از نظر زمانی میتواند از دست برود و RTO مدت قابل قبول برای بازگرداندن سرویس را بیان میکند؛ برنامه Backup باید با این دو هدف، اهمیت سرویس، محل نگهداری نسخهها و تهدیدهایی مانند خرابی، خطای انسانی و باجافزار هماهنگ شود؛ آزمون Restore، ثبت نتیجه و نگهداری نسخهای جدا یا محافظتشده بخش مهم اطمینان از قابلیت بازیابی است روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود
فرض کن در یک تغییر برنامهریزیشده مشکلی گزارش شده و احتمال میدهی به بررسی قبل از تغییر و Backup قبل از تغییر مربوط باشد. قبل از تغییر، وضعیت فعلی را با Change Plan، ارزیابی ریسک، Backup و Rollback Plan بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با بررسی قبل از تغییر و Backup قبل از تغییر قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره بررسی قبل از تغییر و Backup قبل از تغییر فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با بررسی قبل از تغییر و Backup قبل از تغییر، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با Change Plan، ارزیابی ریسک، Backup و Rollback Plan وضعیت مرتبط با بررسی قبل از تغییر و Backup قبل از تغییر را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با بررسی قبل از تغییر و Backup قبل از تغییر بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- Configuration فعلی ذخیره شود
- Health قبل تغییر ثبت شود
- Capacity و وابستگی بررسی شود
- Backup قابل Restore باشد
- بررسی قبل از تغییر مشکل قدیمی را از تغییر جدا میکند
- هر Change باید زمان، ریسک، Backup و روش بازگشت مشخص داشته باشد
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: Configuration فعلی ذخیره شود. بعد بگو در عمل چطور آن را بررسی میکنی.
قبل از تغییر از Config یا مقدارهای فعلی خروجی بگیر تا هم مقایسه بعد از کار ممکن باشد و هم بازگشت امن فقط بر حافظه متکی نباشد
این نکته را با یک مثال توضیح بده: Health قبل تغییر ثبت شود. بعد بگو در عمل چطور آن را بررسی میکنی.
بررسی قبل از تغییر باید سلامت سرویس و شاخصهای اصلی قبل از تغییر را ثبت کند؛ بدون وضعیت قبل، بعداً سخت میتوان فهمید یک خطا جدید است یا از قبل وجود داشته
این نکته را با یک مثال توضیح بده: Capacity و وابستگی بررسی شود. بعد بگو در عمل چطور آن را بررسی میکنی.
وابستگی یعنی یک سرویس یا برنامه برای کار کردن به جزء دیگری نیاز دارد؛ توقف جزء پایه میتواند چند سرویس ظاهراً نامرتبط را همزمان خراب کند
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
