مدیریت تغییر: ارزیابی ریسک، بازگشت مجدد و پنجره تعمیر و نگهداری

سود:

• امکان پیش نویس درخواست تغییر، ارزیابی ریسک و طرح بازگشت با هوش مصنوعی و ایمن و قابل پیش بینی کردن تغییر
• امکان گسترش دامنه با اطلاعات وابستگی خاص خود، طبقه بندی قابلیت بازیابی و به دست آوردن توانایی برنامه ریزی استقرار تدریجی با قناری.
• توانایی درک اینکه این انسان است که تغییر را تأیید می کند، برنامه ریزی می کند و مسئولیت آن را بر عهده می گیرد و نظم و انضباط را برای عدم اجرای آن بدون معیارهای موفقیت و راه بازگشت به دست می آورد.

مدیریت تغییر: ارزیابی ریسک، بازگشت مجدد و پنجره تعمیر و نگهداری با هوش مصنوعی

اکثر فاجعه‌ها در سیستم‌های تولید نه از یک حمله، بلکه از یک تغییر ناشی می‌شوند: یک وصله، یک به‌روزرسانی پیکربندی، انتشار انتشار، یک اصلاح «جزئی». به همین دلیل است که هر سازمان بالغ دارای مدیریت تغییر است: فرآیند انضباطی برنامه ریزی یک تغییر تولید، ارزیابی ریسک آن، تایید آن، اجرای آن و در صورت لزوم بازگرداندن آن به عقب. هدف جلوگیری از تغییر نیست، بلکه ایمن و قابل پیش بینی کردن آن است. در اینجا، هوش مصنوعی یک دستیار قدرتمند در تهیه پیش‌نویس درخواست تغییر، فهرست کردن ریسک‌ها و سیستم‌های متاثر، ایجاد چارچوب طرح بازگشت و تهیه چک لیست استقرار است. اما قانون اساسی باقی می ماند: هوش مصنوعی طرحی را برای مستندسازی تغییرات و ریسک تولید می کند. شخصی که تغییر را تأیید می کند، برنامه ریزی می کند و مسئولیت آن را بر عهده می گیرد.

در این واحد مفاهیم درخواست تغییر، ارزیابی ریسک، طرح بازگشت، پنجره نگهداری، توزیع قناری/مرحله‌ای و CAB (تغییر هیئت مشورتی) شما یاد خواهید گرفت که چگونه تغییرات ایمن را با هوش مصنوعی برنامه ریزی کنید.

آناتومی یک درخواست تغییر خوب

یک تغییر کنترل نشده جمله "من این را به روز کردم" است. تغییر کنترل شده یک برنامه است. یک درخواست تغییر خوب به این سؤالات پاسخ می دهد: چه چیزی در حال تغییر است؟ (دامنه)، چرا؟ (توجیه)، کدام سیستم ها تحت تأثیر قرار می گیرند؟ (دامنه و وابستگی ها)، سطح ریسک چیست؟ (کم / متوسط ​​/ زیاد)، چه زمانی؟ (پنجره نگهداری)، چگونه درخواست کنیم؟ (مراحل)، چگونه تأیید کنیم؟ (معیار موفقیت)، اگر خراب شد چگونه آن را برگردانیم؟ (بازگشت)، چه کسی تایید می کند؟ (مرجع). هوش مصنوعی این اسکلت را به سرعت پر می کند - اما این شما هستید که واقعاً دامنه و خطر را می شناسید و سازمان را می شناسید. شما لیست هوش مصنوعی را با دانش وابستگی خود تکمیل می کنید.

نکته: دو بخش که اغلب نادیده گرفته می‌شوند، «طرح بازگشت» و «معیارهای تأیید موفقیت» هستند. اگر قبل از اجرای تغییر، پاسخ کتبی به سؤالات «اگر خراب شد با کدام دستور دقیقاً به کجا مراجعه کنم» و «چگونه موفقیت آمیز بودن آن را ثابت کنم» ندارید، آن تغییر هنوز آماده نیست.

بازگشت: دروازه خروج از هر تغییر

قلب مدیریت تغییر، طرح چرخش است. هر تغییری باید یک مسیر بازگشت داشته باشد: وصله برگشتی، بازیابی تنظیمات قبلی، نسخه برگشتی به نسخه قبلی، بازگشت از عکس فوری. تمایز اساسی این است: برخی از تغییرات به راحتی قابل بازگرداندن هستند (یک خط پیکربندی)، برخی غیرقابل برگشت یا بسیار دشوار هستند (یک تغییر طرح پایگاه داده، یک حذف داده). تغییرات برگشت ناپذیر بالاترین کلاس خطر هستند و به بیشترین توجه، بیشترین پشتیبان گیری، باریک ترین پنجره نگهداری نیاز دارند. از هوش مصنوعی بپرسید "آیا می توان این تغییر را برگرداند، و اگر نه، چه اقدامات امنیتی اضافی باید انجام دهم؟"

پنجره تعمیر و نگهداری و استقرار مرحله ای

پنجره تعمیر و نگهداری یک دوره زمانی از پیش اعلام شده است که در طی آن تغییر کمترین تعداد کاربران را تحت تأثیر قرار می دهد - معمولاً در شب یا در تعطیلات آخر هفته که ترافیک کم است. اما انتخاب خوب زمان کافی نیست. ایجاد تدریجی تغییر، خطر را بیشتر کاهش می دهد. استقرار قناری بدین صورت است که ابتدا تغییر را در بخش کوچکی (یک سرور، 5 درصد کاربران) اعمال کنید، آن را نظارت کنید و در صورت عدم وجود مشکل، آن را منتشر کنید. به این ترتیب، یک باگ کل ناوگان را تحت تأثیر قرار نمی دهد، بلکه بخش کوچکی از آن را تحت تأثیر قرار می دهد و زودهنگام تشخیص داده می شود. می‌توانید از هوش مصنوعی یک طرح استقرار مرحله‌ای و معیارهایی برای ردیابی در هر مرحله بخواهید.

گام به گام: تغییر به کمک هوش مصنوعی

1. پیش نویس درخواست تغییر را با هوش مصنوعی در عناوین بالا مستند کنید.
2. تاثیر را گسترش دهید. لیست سیستم های آسیب دیده هوش مصنوعی را با نقشه وابستگی خود تکمیل کنید. "چه چیز دیگری به این سرویس متصل است؟"
3. ریسک را طبقه بندی کنید. کم/متوسط/بالا و برگشت پذیر؟ این نیاز به سخت ترین فرآیند دارد که بالا و غیر قابل برگشت است.
4. یک بازگشت بنویسید و آن را تست کنید. مراحل بازگشت را یادداشت کنید و سعی کنید در صورت امکان در یک محیط آزمایشی به عقب برگردید - "طرح برگشتی" که قابل برگشت نیست به عنوان یک برنامه حساب نمی شود.
5. پنجره ها و سطوح را برنامه ریزی کنید. مراحل پنجره نگهداری و قناری و معیارهایی که باید در هر مرحله نظارت شوند را تعریف کنید.
6. تایید و ارتباط. دریافت تاییدیه مرجع (CAB در صورت لزوم)، اطلاع رسانی به افراد تحت تاثیر، اجرا، نظارت، تایید.

سه کیف کوچک

مورد 1 - طرح بازگشتی شب را نجات داد. یک تیم یک پچ وب سرور را اعمال کرد. پچ به طور غیرمنتظره ای یک وابستگی را شکست و سایت شروع به دادن خطای 500 کرد. اما یک مرحله بازگشت واضح با هوش مصنوعی در درخواست تغییر وجود داشت: "پچ را حذف کنید، بسته قبلی را بازیابی کنید، سرویس را دوباره بارگیری کنید." تیم در 6 دقیقه برگشت. بدون طرح بازگشت، قطعی برای ساعت‌ها طول می‌کشید و در نیمه‌شب به دنبال علت اصلی بود.

مورد 2 - قناری یک باگ را در 5٪ گرفتار کرد. نسخه جدید توزیع خواهد شد. این تیم از هوش مصنوعی یک طرح استقرار پلکانی درخواست کرد: ابتدا 1 سرور، ساعت، سپس 25 درصد، سپس همه. زمان پاسخگویی در سرور قناری دو برابر شد. توزیع متوقف شده است این اشکال فقط در یک سرور وجود داشت و 95 درصد از کاربران تحت تأثیر قرار نگرفتند. اگر به یکباره گسترش یافته بود، کل سرویس از بین می رفت.

مورد 3 - اندازه گیری اضافی تغییر برگشت ناپذیر. انتقال طرح پایگاه داده برنامه ریزی شده بود - تغییری که بازگرداندن آن بسیار دشوار است. مهندس از هوش مصنوعی در مورد خطر پرسید. YZ اظهار داشت که این تغییر غیرقابل برگشت است و یک نسخه پشتیبان کامل، اجرای آزمایشی جداگانه و پنجره باریک را توصیه کرد. تیم درست قبل از مهاجرت یک نسخه پشتیبان کامل گرفت، ابتدا آن را روی یک کپی امتحان کرد. در حین انتقال مشکلی وجود داشت، اما به لطف پشتیبان گیری، سازگاری در عرض 20 دقیقه بازیابی شد.

چهار قالب قابل کپی

1) تغییر پیش نویس درخواست:

نقش شما: متخصص مدیریت تغییر. یک درخواست تغییر برای تغییر زیر پیش نویس کنید: [تغییر]. عناوین: چه چیزی/چرا، سیستم‌ها و وابستگی‌ها، سطح ریسک (کم/متوسط/بالا + توجیه)، آیا بازگشت، مراحل پیاده‌سازی، معیارهای تأیید موفقیت، مراحل بازگشت، توصیه پنجره تعمیر و نگهداری، تأییدیه مورد نیاز. وابستگی را که از آن مطمئن نیستید به عنوان "تأیید" علامت گذاری کنید.

2) ارزیابی ریسک و تاثیر:

تغییر زیر را از نظر ریسک ارزیابی کنید: [تغییر]. (1) فهرست سیستم هایی که ممکن است به طور مستقیم و غیرمستقیم تحت تأثیر قرار گیرند، (2) بدترین سناریو چیست، (3) آیا قابل برگشت است، اگر نه، چه اقدامات اضافی باید انجام دهم، (4) سطح خطر را توجیه می کند. توضیح دهید که این یک ارزیابی اولیه است و تصمیم با من است.

3) ایجاد یک طرح بازگشت:

یک طرح بازگشتی گام به گام برای [تغییر] بنویسید. مطمئن شوید که هر مرحله قابل کپی و تأیید است. اگر بخش‌های برگشت‌ناپذیری از تغییر وجود دارد، آن را به وضوح بیان کنید و بنویسید که کدام نسخه پشتیبان باید برای آنها تهیه کنم. نحوه تأیید موفقیت Rollback را اضافه کنید.

4) طرح توزیع مرحله ای (قناری):

یک طرح مرحله‌ای [استقرار] برای استقرار زیر پیشنهاد دهید: کدام فازها (به عنوان مثال 1 سرور -> 25٪ -> همه)، چه مدت باید در هر مرحله منتظر بمانم، و چه معیارهایی را باید ردیابی کنم (زمان پاسخ، میزان خطا، و غیره)؟ در صورت فراتر رفتن از چه آستانه ای باید استقرار را متوقف کنم و به عقب برگردانم؟ نکات تصمیم خود را به وضوح بنویسید.

اعلان ضعیف / اعلان قوی

اعلان ضعیف:

آیا باید این پچ را اعمال کنم؟

بدون زمینه، بدون تأثیر، بدون افزونگی، بدون پنجره. هوش مصنوعی نه سیستم شما را می شناسد و نه خطر شما را. "بله/نه" که می دهد یک حدس غیر مسئولانه است.

اعلان قدرتمند:

نقش شما: متخصص مدیریت تغییر. من یک پچ امنیتی را برای ناوگانی از وب سرورهای در حال تولید اعمال خواهم کرد (8 سرور، پشت یک متعادل کننده بار). به من بدهید: (1) یک پیش نویس درخواست تغییر برای این تغییر، (2) وابستگی هایی که ممکن است تحت تأثیر قرار گیرند (من تأیید خواهم کرد)، (3) مراحل بازگشت، (4) طرح قناری به عنوان 1 سرور -> 25٪ -> همه و معیارهایی که در هر مرحله نظارت خواهم کرد. سطح ریسک را توجیه کنید. تایید می کنم و تصمیم می گیرم.

تغییر ویژگی

کم خطر

ریسک بالا

برگشت پذیری

برگشت آسان

غیر قابل برگشت / مشکل

دامنه

یک وعده، ایزوله

چند سرویس، زنجیره وابستگی

توزیع

می تواند مستقیم باشد

قناری اجباری + پنجره باریک

تایید

درون تیم

CAB / تایید بالا

یدکی

استاندارد

بک آپ کامل اضافی + اجرای آزمایشی

اشتباهات رایج

• اجرا بدون طرح بازگشت. تغییر یک قمار است اگر راه بازگشت نوشته نشود.
• محدود نگه داشتن حوزه نفوذ دور زدن وابستگی های پنهان متصل به یک سرویس منجر به وقفه های جانبی غیرمنتظره می شود.
• اشتباه گرفتن تغییر غیرقابل برگشت با عادی تغییراتی مانند انتقال طرحواره و حذف داده ها نیازمند سخت ترین فرآیند و پشتیبان گیری کامل است.
• پخش آن به کل ناوگان به یکباره. بدون قناری، یک باگ به یکباره به همه کاربران آسیب می رساند.
• عدم تعریف معیارهای موفقیت اگر معنای "موفق" نوشته نشده باشد، ممکن است تغییر شکسته را با "کامل" اشتباه بگیرید.

توجه: لیست سیستم های آسیب دیده تولید شده توسط هوش مصنوعی یک لیست مقدماتی است نه یک لیست کامل. هوش مصنوعی وابستگی های سازمان شما را نمی شناسد. پاسخ دقیق به این سوال که "اگر این سرویس از کار بیفتد، چه چیز دیگری از کار خواهد افتاد؟" در دانش شرکت شما نهفته است. لیست هوش مصنوعی را ناقص فرض کنید و آن را گسترش دهید.

به طور خلاصه

اکثر بلایای تولید از تغییر ناشی می شوند نه حمله. مدیریت تغییر مانع از تغییر نمی شود، آن را ایمن و قابل پیش بینی می کند. هوش مصنوعی به سرعت پیش نویس درخواست های تغییر، ارزیابی ریسک، برنامه های بازگشت، و چک لیست های استقرار مرحله ای را تهیه می کند. اما دامنه را با دانش وابستگی واقعی خود گسترش دهید، برگشت پذیری را طبقه بندی کنید، برگشت بنویسید و در صورت امکان آن را آزمایش کنید، ریسک را با پنجره نگهداری و قناری توزیع کنید، معیارهای موفقیت را تعریف کنید. این انسان است که تغییر را تأیید می کند، برنامه ریزی می کند و مسئولیت آن را بر عهده می گیرد. هوش مصنوعی شریکی است که برنامه را تسریع می کند.

وظیفه کاربردی

تغییر تولیدی را که قصد دارید به زودی انجام دهید (یا اخیراً ایجاد کرده اید) را انتخاب کنید. از هوش مصنوعی بخواهید یک درخواست تغییر کامل را با الگوی «تغییر پیش‌نویس درخواست» در بالا آماده کند. فهرست «سیستم‌های متاثر» را که هوش مصنوعی تولید می‌کند با اطلاعات وابستگی خود، حداقل با دو مورد افزایش دهید. مراحل بازگشت را با الگوی «ایجاد طرح برگشتی» چاپ کنید و تعیین کنید که آیا بخشی از تغییر وجود دارد که قابل برگشت نیست. بالاخره یک طرح قناری بیایید. کل طرح را در 6 نقطه خلاصه کنید و توجه داشته باشید که کدام مصوبات مورد نیاز است.

چک لیست

• [ ] آیا درخواستی برای تغییر آماده کرده ام که شامل چیستی/چرا، تأثیر، ریسک، مراحل، تأیید و بازگشت است؟
• [ ] آیا فهرست سیستم های تحت تاثیر هوش مصنوعی را با اطلاعات وابستگی خودم گسترش داده ام؟
• [ ] آیا من طبقه بندی کرده ام که آیا تغییر برگشت پذیر است یا غیرقابل برگشت؟
• [ ] من مراحل برگشت را نوشتم و در محیط تست امتحان کردم، در صورت امکان؟
• [ ] آیا من طرح استقرار پنجره نگهداری و قناری و معیارهای نظارت را برای هر فاز تعیین کرده ام؟
• [ ] آیا معیارهای تایید موفقیت را تعریف کرده و تاییدیه های لازم را دریافت کرده ام؟