آنچه معماری می تواند در مورد سیستم های خود درمانی به ما بیاموزد

بازنشر افلاطون

دنبال: 0

تیم‌های DevOps و مهندسین قابلیت اطمینان سایت (SRE) روزانه با کد سروکار دارند. انجام این کار به آنها می آموزد که دنیای خود را دقیق بررسی کنند، مشاهدات زیرکانه انجام دهند و ارتباطات غیرمنتظره ایجاد کنند. به هر حال، اگرچه ماهیت بسیار منطقی و ریاضی دارد، توسعه نرم‌افزار حداقل تا حدی شکل هنری است.

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

به یاد داشته باشید، الهام در همه جا وجود دارد - تا زمانی که بدانید به کجا نگاه کنید. در اینجا چند درس است که مهندسان نرم افزار می توانند از تجلیات معماری در طول قرن ها بیاموزند، به ویژه در مورد آینده سیستم های خود ترمیم شونده.

درس 1: موارد لبه همیشه از آسیب پذیری های سیستم سوء استفاده می کنند

برج Citicorp - که اکنون 601 Lexington نامیده می شود - ساخت و ساز را در شهر نیویورک در سال 1977 به پایان رساند و در آن زمان هفتمین ساختمان بلند جهان بود. طراحی پیشرفته این آسمان خراش شامل سه پایه 100 فوتی بود. این یک شگفتی در تکمیل بود. با این حال، یک دانشجوی لیسانس به زودی متوجه یک چیز وحشتناک شد: بادهای شدید می تواند یکپارچگی ساختمان را به خطر بیندازد. به طور خاص، اگر بادهای قوی به گوشه های برج سیتیکورپ برخورد کند، سازه در معرض فروریختن قرار می گیرد - به معنای واقعی کلمه. مورد لبه.

این برج هر سال یک در 16 شانس فروریختن داشت. این شانس‌ها ممکن است کسی را که پشت میز قمار نشسته است ترغیب کند، اما چشم‌انداز برای معماران و مهندسان سازه پشت برج سیتیکورپ بد بود. خوشبختانه، تکنسین ها توانستند اتصالات پیچ شده ساختمان را تقویت کنند. از فاجعه جلوگیری شد.

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

برای کاهش میانگین زمان بازیابی (MTTR) / میانگین زمان شناسایی (MTTD)، تیم‌های DevOps باید احتمال بالای موارد لبه را بپذیرند و برای استقرار راه‌حل‌های خودآموز پیشگیرانه تلاش کنند. این درس بسیار طولانی است، زیرا آینده نگری در مهندسی بسیار مهم است.

درس 2: "ساخت هواپیما در حالی که پرواز می کند" یک چرخه بی پایان ایجاد می کند

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

در بسیاری از صنایع - از جمله هوانوردی - هیچ راهی برای تست استرس جامع یک محصول وجود ندارد. همانطور که قبلا ذکر شد، موارد لبه اجتناب ناپذیر هستند. بزرگترین نکته در اینجا این است که مهندسان نرم افزار باید به آسیب پذیری های سیستم خود هنگام معرفی خود توجه کنند. از آنجا باید به مصلحت به آنها رسیدگی کنند. انجام این کار به دو چیز نیاز دارد: (1) شناسایی و ردیابی شاخص های عملکرد کلیدی مناسب (KPI) و (2) سرمایه گذاری زمان و منابع برای بهبود سیستم ها بر اساس معیارهای مربوطه.

تیم مهندسی متوسط روی 16 تا 40 ابزار نظارتی سرمایه‌گذاری می‌کنند، با این حال اغلب علامتی را که معیارها موفقیت را نشان می‌دهند، از دست می‌دهند. کمتر از 15٪ از تیم ها MTTD را دنبال می کنند، بنابراین 66٪ از چرخه عمر حادثه را از دست می دهند. و یک چهارم تیم ها گزارش می دهند از دست دادن قراردادهای سطح خدمات خود (SLA) با وجود سرمایه گذاری قابل توجه در ردیابی در دسترس بودن. این به ما می‌گوید که جمع‌آوری داده‌ها به تجزیه و تحلیل دقیق و سیستماتیک نیاز دارد تا راه‌حل‌های نقطه‌ای دیگر کافی نیستند.

مهندسان نرم‌افزار، تیم‌های DevOps و SREها باید فرآیندها و ابزارهایی را که ارزش را از مقادیر بسیار زیاد اطلاعات در مورد در دسترس بودن استخراج می‌کنند، اولویت‌بندی کنند. به جای مشاهده ساده یک خطای بحرانی، آنها باید یک صفحه از کتاب یک مهندس هوانوردی را بردارند و سریع تصمیمات حیاتی بگیرند. راز انجام این کار در هوش مصنوعی نهفته است.

درس 3: هوش مصنوعی یک بلوک اساسی برای سیستم های خود ترمیم کننده است

یک سیستم کاملاً مستقل، کاملاً عملکردی و خود ترمیم شونده برای هر مهندس نرم افزار ایده آل است. سیستم‌هایی که خود را وصله می‌کنند برای رضایت مشتری خوب هستند، زیرا زمان خرابی پرهزینه مصرف‌کننده را حذف می‌کنند. علاوه بر این، آنها برای عملکردهای مدیریت خدمات فناوری اطلاعات (ITSM) بسیار سودمند هستند، زیرا به طور قابل توجهی نیاز به مدیریت بلیط خسته کننده را کاهش می دهند. ساخت چنین سیستمی به اجزای متعددی نیاز دارد که بسیاری از آنها در حال حاضر دور از دسترس هستند. اما ما بیشتر از آن چیزی که برخی تصور می کنند به یک واقعیت خوددرمانی نزدیک شده ایم.

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

مسئله این است که ابزارهای AIOps مبتنی بر قوانین، تعاملات بین راه حل های نقطه ای متفاوت را تجزیه و تحلیل می کنند و احتمالاً می توانند خطاهای رایج داده را شناسایی کنند. اما سیستم‌های مبتنی بر اتوماسیون نمی‌توانند تکامل خطاهای کاملاً جدید را در طول زمان پردازش کنند و همچنین نمی‌توانند نقص‌های جدید در داده‌ها را پیش‌بینی کنند. به این دلیل است که مدیران انسانی که این توابع را کدنویسی می‌کنند از سیستم می‌خواهند که یک را دنبال کند اگر این، پس آن الگوی منطقی ابزارهای AIOps واقعاً کارآمد، خطاهایی را که در هر چهار نقطه کلاسیک تله‌متری ایجاد می‌شوند - از تشخیص تا وضوح - با طبقه‌بندی الگوهای جدید و مشکل‌ساز قبل از اینکه تکنسین‌های انسانی حتی از وجود آنها آگاه شوند، کاهش می‌دهند.

در حالی که ما منتظر هستیم موج سوم قریب الوقوع هوش مصنوعی، این نسخه از AIOps نزدیکترین نسخه ما به سیستم های خود درمانی است. ردیابی اینکه چگونه برنامه‌های AIOps فعلی به آینده هوش مصنوعی نفوذ می‌کنند، جالب خواهد بود، که شامل اتوماسیون کاملاً تحقق یافته و امکانات تفکر مستقل است. شاید در آن صورت مهندسان سازه نیز از مزایای یک سیستم خودترمیمی مبتنی بر هوش مصنوعی بهره مند شوند.