معرفی

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

SRE: یک نمای کلی

اولین بار، با توجه به نیاز گوگل به عملکرد کارآمد و قابل اطمینان در مقیاس بزرگ، “مهندسی SRE” به عنوان یک رشته قوی و پایدار به وجود آمده است. امروزه برای بسیاری از سازمان هایی که در تلاش برای ترکیب تکنیک های مهندسی نرم افزار با چالش های عملیاتی هستند، SRE به یک اصل راهنما تبدیل شده است. طبق نظرسنجیCatchpoint، بیش از ۵۴ درصد از شرکت‌ها در حال برنامه‌ریزی برای اجرای روش‌های SRE هستند یا قبلاً آن را پیاده‌سازی کرده‌اند، که محبوبیت رو به رشد این رویکرد را برجسته می‌کند. SRE با اصول مهمی که با اصول DevOps همسو هستند مشخص می شود:

·     تعین اهداف سطح سرویس (SLO) برای خدمات و محصولات: به تیم‌های فنی کمک می‌کند تا عملکرد خود را اندازه‌گیری و بهبود بخشند.

·         حفظ بودجه خطا(error budget): به تیم‌ها کمک می‌کند تا از منابع خود برای رفع خطاها در حد بودجه استفاده کنند.

·     حذف کارهای تکراری و خسته‌کننده: به تیم‌ها کمک می‌کند تا زمان و انرژی خود را صرف فعالیت‌های ارزشمندتر کنند.

·         پذیرش ریسک: به تیم‌ها کمک می‌کند تا فرصت‌های جدید را کشف و از آنها بهره ببرند.

·     نظارت بر سیستم‌های توزیع‌شده: به تیم‌ها کمک می‌کند تا عملکرد و سلامت این سیستم‌ها را کنترل و مدیریت کنند.

·         ساده‌سازی امور: به تیم‌ها کمک می‌کند تا فرآیندها و راه‌حل‌های خود را کارآمدتر کنند.

تکامل هوش مصنوعی در عملیات فناوری و پتانسیل آن در SRE

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

LLM ها می توانند به حل چالش های SRE کمک کنند

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

۱-   کارهای تکراری و خسته کننده انجام نشده (اصل: حذف کارهای تکراری)

بیان مشکل: اگرچه اتوماسیون یک اصل کلیدی SRE است، برخی از وظایف و فرآیندهای تکراری هنوز وجود دارند که به صورت دستی انجام می شود و زمان و منابع ارزشمندی را مصرف می کند. این کارها معمولاً به دلیل پیچیدگی فنی، سیستم های قدیمی، یا کمبود منابع است که منجر به بازده (ROI) پایین منابع مصرف شده می شود. تکرار دستی نه تنها وقت گیر است بلکه پرهزینه هم است.

مطالعه انجام شده در دانشگاه کالیفرنیا نشان داد که کارکنان، پس از یک وقفه مانند پرداختن به یک کار دستی ، به طور متوسط ۲۳ دقیقه طول می کشد تا ریکاور شوند که  جریان کار راهبردی و خلاقانه را مختل می کند و بر بهره وری تاثیر می گذارد.

مشارکت LLM:

مهندسان SRE می توانند از LLM برای تولید اسکریپت اتوماسیون در یک زبان مانند پایتون بر اساس وظیفه مورد نیاز استفاده کنند. آنها باید اطمینان حاصل کنند که فرمان های صحیح درLLM برای مطالعه و بررسی نیازمندی ایجاد شده است. پس از تولید، حتی می توان از LLM درخواست کرد تا کد نوشته شده را بهینه کند. سناریوی دیگری که در آن LLM ها می توانند کمک کنند، وظیفه مهم اما وقت گیر ایجاد گزارش های “پس از حادثه”، بعد از یک واقعه است. با استفاده از GPT، می‌توانیم کل فرآیند را با چند مرحله خودکار کنیم.

۱)    یکپارچه سازی داده ها: استفاده از الگوریتم های استخراج یا APIs برای جمع آوری داده های تصادفی از منابعی مانند لاگ ها، ابزارهای مدیریت سرویس آی تی(ITSM) یا کانال های Slack . این داده ها نیاز به پیش پردازش با استفاده از توکن سازی، رمزگذاری، یا نرمال سازی برای تبدیل آن به فرمتی که GPT می تواند پردازش کند، دارند.

۲)    استفاده از مدل: برای استفاده از LLM از پیش آموزش دیده، مدل باید بر روی مجموعه داده گزارش های پس از حادثه موجود، به خوبی تنظیم شده باشد. برای این کار، از یادگیری نظارت شده استفاده کنید، بنابراین GPT ساختار و سبک این گزارش ها را یاد می گیرد. سپس، سیستمی بسازید که داده های از پیش پردازش شده حادثه را به GPT وارد می کند و پیش نویس گزارش پس از حادثه را دریافت می کند. این کار شامل فرآیندهایی مانند تولید توکن و تکمیل توالی است.

۳)    مکانیسم بررسی: هنگامی که پیش نویس اولیه تولید شد، مهندس SRE باید یک بررسی دستی انجام دهد تا صحت چهارچوب را بررسی کرده و مطابق با آن اصلاح کند. الگوریتم های بازخورد یا تکنیک های  تقویت یادگیری را می توان برای گنجاندن بازخورد در مدل، بهبود دقت و کیفیت خروجی های آینده استفاده کرد.

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

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

از آنجایی که این در مجموعه ابزارهای بهره وری ۳۶۵  Microsoftتعبیه شده است، می تواند برای مواردی استفاده شود که گزارش های پس از حادثه (به منظور شناسایی علت حادثه) به عنوان اسناد Microsoft Word ساخته می شوند.

Copilot می‌تواند محتوای سند را بیشتر اصلاح کند و با پیشبینی الگو آنالیز علت ریشه ای(RCA:Root Cause Analysis) بر اساس منابع داده سازمانی، کمک کند.

۲-    نشت هزینه در ابر (اصل: پذیرش ریسک، حذف کارهای تکراری)

بیان مشکل: علیرغم معرفی عملیات مالی ابری (FinOps)برای کنترل هزینه های ابر، یک سیستم بهینه نشده می تواند باعث افزایش قابل توجه هزینه های ابر شود. SLOs باید برای این کار تنظیم شوند و توسط SRE مورد بررسی قرار گیرند. علاوه بر این، در حالی که تست عملکرد و مهندسی  آشوب می تواند نقاط ضعفی را که ممکن است بر هزینه ابر تأثیر بگذارد را آشکار می کند، بسیاری از سازمان‌ها به دلیل هزینه‌ها و تاخیر در عرضه ویژگی‌ها، از اجرای آن اجتناب می‌کنند.

طبق آمار مرکز مهندسی آشوب گرملین(Gremlin)، در سال ۲۰۲۱، تنها ۳۴ درصد از ۴۰۰ پاسخ دهنده، آزمایش مهندسی آشوب را روی تولید انجام می دهند.

مشارکت LLM: LLM هایی مانند GPT می توانند برای آنالیز داده های ابری و برنامه کاربردی، برای بهینه سازی پلت فرم ابری به کار گرفته شوند. در غیر این صورت نیاز به تلاش دستی مهندس SRE دارد تا داده ها و روندهای مشاهده شده را بر اساس الگوهای بهره وری تفسیر کند. به عنوان مثال، برنامه ای که گزارش‌های بیش از حد تولید می کند می‌تواند نشان دهنده اقدامات زائد یا ناکارآمد روش های گزارش گیری باشد که منجر به هزینه‌های ذخیره سازی غیر ضروری می‌شود. یکLLM  می‌تواند نویز را غربال کند، ورودی‌ لاگ های رایج یا مکرر را شناسایی کند و بهینه‌سازی‌هایی را برای کاهش حجم لاگ پیشنهاد دهد. برای انجام این کار با استفاده از GPT، یک مهندس SRE مراحل زیر را دنبال می کند:

۱)    استخراج داده‌های لاگ: لاگ‌ها باید با استفاده از خط لوله داده (Data Pipeline) یا API که با سیستم ثبت گزارش ارتباط  دارند از برنامه واکشی(برداشته) شوند. به طور کلی، ما از ابزارهایی مانند Logstash یا Splunk برای کمک به زمینه سازی و متمرکز کردن داده های لاگ از منابع مختلف استفاده می کنیم.

۲)    پیش پردازش داده ها: داده ها باید در قالبی پیش پردازش شوند که GPT بتواند آن را درک کند، مانند تبدیل فرمت های تاریخ و زمان، نشانه‌گذاری متن و حذف ورودی‌های لاگ نامربوط.

۳)    تشخیص الگو با GPT: GPT می‌تواند خلاصه‌ای از لاگ‌های دریافت شده ایجاد کند و اطلاعات را فشرده کند و الگوهای مکرر را که ممکن است نشان دهنده افزونگی یا ثبت بیش از حد باشد، برجسته کند.

۴)    توصیه ها و پیاده سازی قابل اجرا: خروجی GPT با استناد فراوانی عبارات لاگ، تعداد توکن‌ها و خلاصه ی آن می‌تواند برای شناسایی رویدادهایی که ممکن است به صورت غیرضروری اضافی باشند، استفاده شود. اگر اطلاعات نشان دهنده خطا در کد برنامه باشد، می توان از آن برای رفع مشکل استفاده کرد. در غیر این صورت، افزونگی لاگ‌ها را می‌توان کاهش داد تا در رویدادهای لاگ و هزینه‌های ذخیره‌سازی صرفه‌جویی شود.

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

در چنین مواردی، LLMمی تواند معیارهای برنامه را از یکپارچه سازی ابزار نظارت بر عملکرد برنامه(Application Performance Monitoring: APM) و الگوهای استفاده از منابع ابری آنالیز کند تا پیشرفت هایی مانند بهینه سازی کد یا استفاده بهتر از حافظه پنهان را نشان دهد.

نمونه ای از سرویس هایی که با این روش ارائه می شود در runnel.ai است و SRE as a Service را ارائه می کند.

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

۳-    همبستگی داشبورد Dashboard Correlation

(اصل: نظارت بر سیستم های توزیع شده)

در استقرار یک ابر هیبریدی، سیستم‌ها توزیع می‌شوند که به تلاش قابل توجهی برای تریاژ و عیب‌یابی از طرف مهندسین SRE نیاز دارند. این کار شامل بررسی داده‌های مربوط بهtrace ، مرتبط کردن رویدادها و تجزیه و تحلیل داشبورد است. به عنوان مثال، در محیط یک ابری هیبریدی که در آن یک پایگاه داده حیاتی درون سازمانی است (op-premises) و میکرو سرویس و برنامه‌های دیگر در ابر عمومی قرار دارند، مهندسان SRE باید ردیابی ها را از لایه میکرو سرویس ها  با تماس های پایگاه داده و وضعیت سلامتی هماهنگ  کنند. این موضوع می تواند پیچیده و زمان بر باشد و مهندسان SRE ممکن است سیگنال های خاص را از دست بدهند.

مشارکت LLM: LLM ها می توانند با دریافت داده های Telemetry بزرگ و پاسخ دادن به سوالاتی که به عیب یابی کمک می کند، به مهندسان SRE کمک کنند. این موضوع می تواند در زمان و تلاش دستی مهندسان SRE برای پیمایش دستی داشبورد های مختلف و فیلترهای لاگ روی محصولاتی مانند Logstash  صرفه جویی کند.

در زیر نمونه ای آورده شده است که نشان می دهد چگونه این نوع راه حل را می توان پیاده سازی کرد و همان اصل را برای استفاده از هر نوع LLM دیگر مانند GPT یا Bard Enterprise اعمال کرد.

۱)    جذب داده: داده ها باید از هر دو سیستم نظارت بر پایگاه داده درون سازمانی و ابر عمومی مبتنی بر پلتفرم مشاهده‌پذیری از طریق APIها یا عامل‌های پلتفرم ابری که می‌توانند در میزبان‌های پایگاه داده باشند، جمع آوری شوند.

۲)    پیش پردازش و نرمال سازی: داده های خام باید به یک فرمت متنی سازگار تبدیل شوند که LLM می تواند پردازش کند. این باید به صورت مکالمه یا گفتگو باشد، زیرا GPT برای مدیریت داده های مکالمه طراحی شده است. برای مثال، یک عبارت ورودی ایده‌آل به این صورت است: “ ChatGP، من متوجه الگوهای زیر شدم. آیا می توانی کمک کنی و آنها را تحلیل کنی؟» به دنبال آن داده‌های تله‌متری می آید، «در ساعت ۲۲:۳۰، پایگاه داده داخلی Oracle استفاده از CPU   بالای ۹۲%  را تجربه کرده است.»

۳)    تجزیه و تحلیل و تولید پاسخ:  ChatGPT  یک پاسخ بر اساس داده های ورودی ایجاد خواهد کرد. سپس شما اطلاعات مربوطه را با استفاده از روش های پس پردازش یا با طراحی پیام برای وارد کردن ورودی های اولیه توسط کاربر، از خروجی استخراج می کنید و برای هدایت مدل برای تولید خروجی مورد نظر استفاده می کنید.

۴)    پس پردازش و هشدار: بسته به نوع تجزیه و تحلیل دریافت شده توسطGPT، سیستم می تواند هشدار دهد یا اقدامات مناسبی مانند تشخیص خودکار یا اصلاح بیشتر را انجام دهد.

۵)    حلقه بازخورد پیوسته: در صورت امکان، می‌توانیم یک حلقه بازخورد راه‌اندازی کنیم که نتایج حاصل از خروجی ChatGPT می تواند برای بهبود پاسخ های آینده استفاده شود.

۴-    ناهماهنگی فرهنگی (اصول: ساده نگه داشتن کارها، حفظ بودجه خطا)

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

مشارکت : LLM یکی از دلایل اصلی ناهماهنگی فرهنگی، ارتباط نامناسب است. این مورد بیشتر در مورد کمبود ابزار برای تسهیل نیست، بلکه بیشتر در مورد این واقعیت است که هر فردی پیام ها را از طریق این محصولات، متفاوت تفسیر می کند. یک LLM مانند Bing Chat Enterprise می تواند در زمینه های زیر کمک کند:

۱)    ارتباط معنادار: اصطلاحات فنی از داشبوردهای قابلیت اندازه گیری وضعیت فعلی سیستم نشان می دهد که SLO و نقض های بودجه خطا را می توان به زبانی قابل فهم برای سهامداران مختلف ترجمه کرد. به عنوان مثال، LLMمی تواند توضیحی در مورد اینکه چگونه بودجه های خطای بیش از حد، ممکن است بر قابلیت اطمینان سیستم در زمینه محصول مربوطه، کمک به صاحبان محصول و کاربران تجاری در تصمیم گیری آگاهانه، تاثیر بگذارد.

۲)    هشدارها و اعلان ها‌:  LLMsمی‌توانند داده‌ها را از ابزارهای مشاهده‌پذیری پردازش کنند و هشدارهای معنی‌دارتر و مرتبط تولید کنند. آنها می توانند زمینه های نگرانی کلیدی را برجسته کنند، به خصوص اگر مشکل شناسایی شده به کد زیربنایی مرتبط باشد. این مورد باعث صرفه جویی در تلاش مهندس SRE در توضیح مشکلات مربوط به ویژگی های توسعه یافته برای هر یک از توسعه دهندگان می شود.

۳)    مدیریت دانش: اگر LLM بر روی مجموعه داده های پس از حادثه آموزش داده شود، می توان از آن به عنوان یک مرکز متمرکز دانش محور استفاده کرد. فراتر از داده‌های پس از حادثه، می‌تواند گزارشات جلسه و مستندات سیستم را استفاده کند تا منابع خود را غنی کند. مهندسین SRE، توسعه دهندگان، صاحبان محصول و سایر ذینفعان می توانند با استفاده از پروفایل های یکتا، کوئری ها را به LLM ارسال کنند، و پاسخ هایی که دریافت می کنند به روشی ارائه می شود که  درک آن برای آنها آسان است.

۴)    آموزش و راهنمایی:LLMs می توانند سناریوها یا مطالعات موردی را بر اساس داده های گذشته برای آموزش توسعه دهندگان و مهندسان SRE در مورد بهترین شیوه ها، SLOs و بودجه خطا، ایجاد کنند. از این سناریوها می توان در تمرین های جهت گیری گروهی مشترک استفاده کرد تا همه نقش ها در اکوسیستم بتوانند در مورد مفاهیم و پیاده سازی های عملی به روشی که آنها درک می کنند، یاد بگیرند.

۵)    حل تعارض: با ارائه گزارش های عینی و مبتنی بر داده ها و هشدارها، LLMs  می توانند به وساطت بین تیم های مختلف کمک کنند .آن‌ها می‌توانند زمان و مکان نقض بودجه‌های خطا را مشخص کنند که می‌تواند منجر به بحث های سازنده در مورد تخصیص منابع، سلامت سیستم و سرعت استقرار شود.

به طور کلی، هدف استفاده از LLM به عنوان تسهیل کننده ارتباطات و تفاهم برای همسو کردن همه به سوی هدف مشترک قابلیت اطمینان و پایداری سیستم، است.

۵-    کاهش وابستگی به متخصص موضوع(Subject Matter Expert-SME)  (اصل: رفع زحمت)

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

اعضای تیم عملیات می‌توانند برای مشاوره تخصصی عیب یابی یک حادثه خاص با مهندسین SRE از سیستم دیگری مشورت بگیرند. مهندسین SRE  با استعداد به راحتی در دسترس نیستند و استخدام آنها دشوار است.

مشارکت LLMs: LLMمی توانند به SMEs کمک کنند تا محتوا را سریعتر تولید کنند، یک پایگاه دانش جامع ایجاد کنند و به ذینفعان از نظر پشتیبانی سلف سرویس کمک کنند. این امر می تواند به پاسخگویی به اکثر پرس و جو های داخلی یا خارجی و کاهش وابستگی SME  کمک کند.GPT  همچنین می تواند به ارائه محتوای آموزشی به کارکنان کمک کند، بنابراین مشارکت SME  در آموزش و معارفه کارمندان کاهش می یابد.

موارد زیر روش‌های خاصی است که یک LLM می‌تواند به همه اعضا تیم کمک کند و مهندسان SRE را از طریق بهبود کارایی، افزایش به اشتراک گذاری دانش و دقت بیشتر بهره مند کند.

۱. پایگاه دانش خودکار: LLMs می توانند اسناد و سایر منابع دانش ایجاد شده توسط مهندسین SRE را جذب کنند و به عنوان یک ابزار جستجوی پیچیده خدمت کنند. بوسیله تعامل با  LLM، سایر تیم ها می توانند اطلاعات مورد نیاز خود را بدون ایجاد وقفه در کار مهندسین SRE دریافت کنند و زمان صرف شده برای پاسخگویی به سوالات معمول آنها را کاهش دهند.

با فرض استفاده از ChatGPT، یک رابط مانند ربات چت یا نوار جستجو می تواند ارائه شود تا کاربران بتوانند سؤال بپرسند، و LLM  که اکنون با مجموعه داده های آموزش دیده به خوبی تنظیم شده است، می تواند به سبکی متناسب با درخواست کننده به آنها پاسخ دهد.

۲. مستند سازی پویا: برای کمک به مستند سازی، می‌توان سیستمی ساخت که به مهندسان SRE اجازه وارد کردن اطلاعات خام  را میدهد و ChatGPT می‌تواند محتوای واضح و خواناتری تولید کند. مثلا،ChatGPT با در نظر گرفتن یک قطعه کد، ممکن است بتواند توضیحی قابل خواندن برای انسان در مورد کد ارائه دهد.

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

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

پس از این، درخواست‌ کننده می ‌تواند به پرسیدن «معمولاً چگونه مشکلات را در ماژول A اشکال زدایی کنیم؟» ادامه دهد.

که LLM ممکن است با راهنمای اشکال زدایی گام به گام بر اساس اشکال زدایی قبلی و گزارشات حادثه مربوط به ماژول، پاسخ دهد. راهنمایی ها را می توان بیشتر شرح داد و موشکافی کرد و در هر مرحله، درخواست کننده پاسخ های مفصل، دقیق و متنی را دریافت می کند که در غیر این صورت و عدم وجود این امکان، توجه ویژه مهندسان SRE را نیاز داشت.

۶-    تعریف شاخص سطح خدمات (Service Level Indicator(SLI) )

(اصل: پیاده سازی SLO)

تعریف  SLIs خوب برای مهندسان SRE چالش برانگیز است زیرا آنها باید “عملکرد فنی” و “انتظارات تجاری” را بالانس کنند. حد نرمال حفظ حداکثر سه SLI در هر تجربه کاربر، این را حتی دشوار تر می کند. در حالی که برخی از محصولات فراهم کننده قابلیت مشاهده (observability productsشامل ابزارهایی مانند مانیتورینگ، لاگینگ، تریسینگ )  می‌توانند به تعریف و حتی پیشنهاد SLI به صورت خودکار کمک کنند، اما فاقد محتوا و موضوع هستند.

مهندسان SRE هنوز باید نمودارهای توالی مسیر(Sequence Diagram) استفاده کاربر از سایت را بررسی کنند تا یکی را که می تواند زمان بر باشد، مشخص کنند. پس از تعریف، چالش بعدی اطمینان از تنظیم صحیح هدف SLO است. این کار میتواند  توسط جستجوی داده‌های گذشته یا «مشاهده و صبر کن» انجام شود، اما هر دو روش زمان‌ بر هستند.

مشارکت : LLM به عنوان مثال ai. SLOGPT از شرکت Nobl9 می تواند از اسکرین شات های موجود نمودارهای ابزار نظارت برای شناسایی SLOs کمک کند.

– با این حال، این خروجی فاقد زمینه مشتری است. آنچه در زیر آمده موارد استفاده ای است که LLMs می توانند پتانسیل یک SRE را در اجرای SLI افزایش دهند:

۱. تعریف: SLI LLMs  می توانند به ارائه پیشنهادات SLI بر اساس داده های متنی کمک کنند. به عنوان مثال، پس از آماده سازی (Priming) LLM  با اطلاعاتی در مورد معماری برنامه، می توان در رابط کاربری، با استفاده از prompts، مسیرهای مشتری را در سیستم های مختلف مشخص کرد.

یک LLM مانندChatGPT، می تواند نقش یک مهندس SRE را بر عهده بگیرد و سه SLI  برتر را بر اساس انواع خاص SLI (مثلاً تأخیر) در مقابل مدل “۴ سیگنال طلایی ” یا هر مدل دیگری پیشنهاد دهد.

پس از انجام، می‌توان خواست تا هر SLI را با جزئیات تعریف کند و همچنین درباره دلایل انتخاب آن سوال کرد.

۲. تعریف : SLOهنگامی که لیست  SLIsبالقوه به دست آمد و اصلاح شد، یک مهندس SRE می تواند از ChatGPT  برای پیشنهاد  SLOsمناسب استفاده کند.

به عنوان مثال، اعلانی مانند:“ SLOما برای نرخ خطای سرویس Aچیست؟” می تواند پرسیده شود ChatGPT. ممکن است یک SLO مانند «نرخ خطای سرویس A باید کمتر از ۰.۱٪ در هر ۵ دقیقه پیمایش باشد»  را پیشنهاد دهد.

این مدل می تواند پیشنهاد خود را بر اساس استانداردهای صنعت، بهترین شیوه‌ها و داده‌های عملکرد گذشته سرویس که در طول آموزش دریافت کرده است، ارائه دهد.

با این حال، اگر مستندات طراحی دقیق که الزامات غیر عملکردی( Non-Functional Requirements (NFRs))   را پوشش می‌دهند، وجود داشته باشند، زمینه و اعتبار بهتری را در برابر  SLOs پیشنهادی ارائه می دهند.

۳. تنظیم مداوم: با تکامل سیستم و جمع آوری داده های عملکرد، مهندسان SRE می توانند از GPTبرای پیشنهاد تنظیمات SLI و SLO استفاده کنند. به عنوان مثال، اگر سرویس A به طور مداوم با SLO خود با مارجین زیادی روبرو می شود، یک مهندس SRE ممکن است از ChatGPT  بپرسد که آیا باید SLO  سختگیرانه تر باشد یا خیر.

اگر سرویس به طور مداوم بهSLO  خود دست نیابد ، مهندس SRE می تواند بپرسد که آیا SLO  باید آسان گیر شود یا چه تغییراتی باید در سرویس ایجاد شود تا به آن کمک کند تا SLO را برآورده کند.

۷-    ایمیل ها (اصول: حذف زحمت، ساده نگه داشتن کارها)

با وجود ابزار ثبت تیکت ITSM، بسیاری از مشتریان و سایر تیم ها هنوز ترجیح می دهند از ایمیل برای ارتباط استفاده کنند. اوضاع وقتی بدتر میشود که انتظار می رود که به این موارد فورا پاسخ داده شود، در نتیجه منجر به تغییر قابل توجه موضوع کاری و مدیریت سخت آن‌ها میشود. علاوه بر این، سنجش نظرات مشتری تنها بر اساس ایمیل‌ها، می‌تواند دشوار باشد. در حالی که SREs بر جنبه فنی تمرکز دارند، مدیریت ارائه خدمات باید عملکرد خدمات ارائه شده توسط تیم ها را درک کند و به چیزی بیشتر از SLOs نیاز است.

مشارکت: LLM LLM می تواند محتوای کل متن ایمیل و ارتباطات ابزار همکاری را آنالیز کند.

(به عنوان مثال، مکالمات Slack) برای شناسایی درخواست و استفاده از سایر عناصر بدنه ایمیل برای تعیین نظرات و احساسات مشتری .به عنوان مثال، Bing Chat Enterprise می تواند به پردازش، دسته بندی، اولویت بندی، خلاصه کردن و حتی پاسخ به ایمیل ها کمک کند.

۱.تریاژ (اولویت بندی) ایمیل: از LLMs می توان برای مرتب کردن ایمیل ها در دسته های مختلف بر اساس محتوای آنها استفاده کرد. برای مثال، آنها می‌توانند ایمیل‌ها را با عناوین: اطلاعاتی، درخواست‌های اقدام، گزارش‌های خطا یا درخواست‌های عمومی، شناسایی و برچسب گذاری کنند. این کار به SREs کمک می کند تا مشخص کنند چه چیزی به توجه آنها نیاز دارد و فعالیت های خود را به سرعت بر اساس آن اولویت بندی کنند. برای انجام این کار، ابتدا باید دسته بندی موضوعی ایمیل تعریف شوند. سپس مدل می تواند با مثال های مختلفی تغذیه شود که هر دسته را برای آموزش نشان می دهد.

پس از تنظیم دقیق، LLM اکنون باید بتواند ایمیل های دریافتی جدید را بر اساس محتوا دسته بندی کند.

۲.پاسخ های خودکار:  LLM می تواند برای برخی از انواع ایمیل ها پاسخ خودکار ایجاد کند. این کار می تواند برای درخواست های استاندارد یا سوالات رایج مورد استفاده قرار گیرد. این مدل ها می توانند پاسخ های دقیق و منسجمی را برای  پرداختن به پرس و جو ایجاد کنند. مانند دسته بندی ایمیل، مدل باید در مورد انواع سؤالات رایج و پاسخ های مربوطه آموزش داده شود. سپس، می تواند از این الگوها برای ایجاد پاسخ برای پرس و جو های مشابه در آینده استفاده کند.

۳. تجزیه و تحلیل نظرات: از LLMs می توان برای درک نظرات افراد در مضمون ایمیل ها استفاده کرد. آنها می توانند تشخیص دهند که این نظرات مثبت، منفی یا خنثی است و یک امتیاز کلی ارائه می دهد. این کار می تواند بطور ویژه برای درک حالت یا لحن کلی ارتباطات کاربران، توسعه دهندگان یا تیم های دیگر مفید باشد .

این کار مستلزم یک مجموعه داده برچسب ‌دار حاوی متنی با برچسب‌های نظرات مرتبط (مثلاً مثبت، منفی، خنثی) است. یک مدل آموزش دیده بر روی این داده ها، اکنون می تواند با ایمیل های دریافتی تغذیه شود و سپس نظرات پشت متن ایمیل را پیش بینی کند. ابزار مبتنی بر GPT مانند ChatGPT نمی تواند نظرات را به طور مستقل تجزیه و تحلیل کند چون هدفش این نیست. در عوض،  ChatGPTرا می توان در یک خط لوله شامل مدل های دیگر، مانند (Bidirectional Encoder Representations from Transformers)BERT که زمینه را هم از سمت چپ و هم از سمت راست در نظر می گیرد، (به عنوان مثال، دو طرفه)، استفاده کرد  که منجر به درک دقیق تری از معناشناسی زبان می شود.

۴. خلاصه سازی: برای ایمیل های طولانی تر، LLMs می توانند خلاصه ای از نکات اصلی را ارائه دهند. برایSREs  که نیاز به درک سریع محتوای ایمیل بدون خواندن کل متن دارند، خلاصه سازی می تواند مفید باشد. علاوه بر این، با ایمیل های بیشتری که توسط LLM خوانده می شود، می تواند تاریخچه ای از مکالمات مرتبط را حفظ کرده و محتوای مرتبط را ارائه دهد. برای پیاده سازی این حالت، می توان از مجموعه داده هایی با متن طولانی و خلاصه های کوتاه متناظر با آن، برای آموزش LLM استفاده کرد. پس از آموزش مدل روی چنین داده‌هایی، مدل می‌تواند هر متن طولانی را بگیرد و خلاصه‌ای را با دقت تولید کند.

۵. استخراج نگرش و رویکرد: در طول زمان، با تجزیه و تحلیل محتوا و نظرات ایمیل ها، LLMs می توانند نگرش ارزشمندی در مورد مسائل تکرار شونده، مشکلات متداول، زمینه های بهسازی، و رضایت کلی کاربر ارائه دهند. این نگرش ها می تواند تصمیم گیری استراتژیک را هدایت کند و به بهبود خدمات و عملیات SRE کمک کند. با این حال، برای انجام این کار، مدل نیاز به تجزیه و تحلیل ایمیل های طبقه بندی شده و نظرات مرتبط، در یک دوره زمانی دارد تا موضوعات یا مسائل تکراری را شناسایی کنید.

در تمام این موارد، LLM باید یک جریان ورودی ثابت از محتوای ایمیل دریافت کند که می تواند از طریق API استخراج شود.

یک LLM باید قبل از استفاده، با مجموعه داده های آموزشی مناسب برای هر سناریو تنظیم شود. دامنه گسترده درک زبان می تواند به GPT در تجزیه و تحلیل نظرات در زبان های مختلف کمک کند. شایان ذکر است در حالی که مدلی مانند ChatGPT را می توان برای مطالعه داده های نوشته شده به زبان های مختلف استفاده کرد، اما در زبان انگلیسی بسیار ماهرتر است. دقت و نتایج تفسیر زبان‌های غیرانگلیسی بر اساس نمایش آن در مجموعه داده آموزشی، متفاوت خواهد بود.

۸-    خستگی هشدار(Alert fatigue) (اصول: اجرای SLO، حذف زحمت)

حجم زیاد هشدارهای سیستم می تواند چالش مهمی برای مهندسین SRE باشد. مطابق مقاله Forbes ، «تیم‌هایی که برنامه‌ها و فرآیندهای متعدد را نظارت می‌کنند، نسبت به هشدارها حساسیت زدایی می شوند و به توانایی آنها در عملکرد موثر یا اولویت بندی مناسب مسائل آسیب رسانده می شود». فراتر از این، سیل هشدار همچنین آنالیز سببی ( causal analysis) را پیچیده می کند و تریاژ (اولویت بندی) حادثه( incident triaging)، به طور قابل توجهی روند را به تاخیر می اندازد. در پلتفرم‌های ابری توزیع‌شده، میزان هشدارها تنها از آن زمان افزایش می‌یابد که ما جریان های داده های تله متری (telemetry data)   زیادی داریم که می توانند هشدارها را شروع کنند. چالش مبرم در اینجا این است که کمیت (تعداد) هشدار را کاهش و کیفیت آنها را افزایش دهیم که این کار آنها را معنادار تر و کاربردی تر می کند.

مشارکت LLMs: LLM می توانند برای توسعه سیستم های مدیریت هوشمند هشدار که در سیستم خط لوله اطلاع رسانی(notification pipeline) تعبیه شده، استفاده شوند. این سیستم ها از قابلیت های پردازش زبان طبیعی LLM برای خواندن و فهمیدن محتوای هر هشدار استفاده می کنند. سپس می تواند هشدارها را بر اساس شدت، علت احتمالی اصلی، خدمات تحت تأثیر، کاهش حجم هشدارها با حذف تکرار اعلان‌های مشابه و فیلتر کردن موارد غیر بحرانی طبقه بندی کند. به این ترتیب، مهندسان SRE می توانند بر روی هشدارهای مهم تمرکز کنند.

۱.    اولویت بندی هشدار و طبقه بندی LLMs: را می توان آموزش داد تا تفاوت های ظریف هشدارهای مختلف را درک کنند و آنها را قادر می سازد تا به طور خودکار هشدارها را بر اساس محتوا، شدت و زمینه آنها طبقه بندی کنند. به عنوان مثال، هشدارها را می توان به دسته های “بحرانی”، “هشدار”، “اطلاعاتی” و غیره طبقه بندی کرد .این دسته بندی خودکار به مهندسان SRE کمک می کند بر روی هشدارهایی که نیاز به توجه فوری دارند، تمرکز کنند. برای انجام این کار، مجموعه داده ای از هشدارها باید جمع آوری شود، که هر کدام در دسته بندی صحیح خود برچسب گذاری شده اند. در مرحله بعد، مدل باید در این مجموعه داده ها آموزش داده شود تا یاد بگیرد که گروه هشدار ورودی را بر اساس محتوای آن پیش بینی کند. پس از آموزش، می توان آن را با خط لوله سیستم هشدار یکپارچه کرد تا هشدارها را همانطور که تولید می شوند به صورت خودکار طبقه بندی کند .

۲.    حذف هشدارهای تکراری: چندین هشدار اغلب توسط یک حادثه ایجاد می شود و رگباری از اعلان ها را برای مشکل یکسان ایجاد می کند. LLMs می توانند هشدارهای مشابه را شناسایی و گروه بندی کنند و یک دید تلفیقی از حادثه و کاهش نویز را به مهندسان SRE ارائه دهند. مجموعه داده های گذشته از هشدارها و حوادث با گروه بندی مناسب، برای آموزش مدل مورد نیاز است.  مدلی مانند GPT می تواند شباهت های بین هشدارهای متنی مشابه را شناسایی کند.

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

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

۴.    خلاصه سازی هشدارها: هنگامی که هشدارها طبقه بندی و مرتبط شدند و موارد تکراری حذف شد، LLM می تواند خلاصه های مختصری از گروه های هشدار تولید کند این کار به درک سریع موقعیت و زمان سریعتر پاسخ کمک می کند. باز هم، مجموعه داده های گذشته مورد نیاز است. با این حال، مسئله حصول اطمینان از محتوای کافی داده های آموزشی در هشدار یا حادثه برای خلاصه سازی توسط مدلی مانند GPT است. برای این کار ابتدا باید مهندس SRE جزئیات کافی در هشدارها را از طریق پلتفرم مشاهده پذیری، ایجاد کند. مجموعه داده ها می تواند خلاصه های کوتاهی در ارتباط با هر هشدار برای آموزش مدل برای خلاصه سازی دقیق تر داشته باشد. پس از تنظیم دقیق، درست مانند سناریوهای دیگر، مدل را می توان در سیستم خط لوله اعلان هشدار پیاده سازی کرد.

۵.    پیشنهادات حل مشکلات وقایع ناگوار: با مرتبط کردن هشدارها با مشکلات و راه حل های شناخته شده در پایگاه دانش موجود، LLMs  می توانند راه حل ها یا مراحل کاهش بالقوه مشکل را به مهندسان SRE پیشنهاد دهند. با فرض یک پایگاه داده دانش مناسب یا یک پایگاه داده خطای شناخته شده با محتوای کافی در مورد مراحل قبلی رفع خطا و طبقه بندی هشدارها ؛ داشتن اطلاعات علت ریشه ای مشکل باعث می شود نتایج استفاده از LLM در این خط لوله بهبود یابد.

این راه حل ها را می توان با اتخاذ SLOs به اندازه کافی بهبود داد تا هشدارهایی را بر اساس نرخ سوخت (SLO burn rate) یا نقض SLO به جای نقض آستانه، در سطح مانیتور ایجاد کند. برای افزایش بیشتر این مقدار، ادغام سیستم مدیریت تغییر با سیستم مدیریت هشدار به LLM کمک خواهد کرد تا برخی از این هشدارها را با استقرار مداوم(ongoing deployments) شناسایی و مرتبط کند. اگر هشدارهای تولید شده برای جلوگیری از شکست قریب الوقوع کل سیستم، واقعی و مهم باشد، یک مهندس SRE می تواند  ویژگی های Rollback خودکار از استقرار سیستم را پیش ببرد.

  نتیجه گیری و جهت گیری آینده

در این مقاله، ما چالش‌های مهم در قلمرو SRE، مانند کارهای دستی، خستگی هشدار و وظیفه پیچیده حفظ  SLOsدقیق را روشن کرده‌ایم. ما همچنین نقش تحول آفرین LLMs هایی مانندGPT  را در مهندسی SRE به عنوان یک ابزار تکمیلی که در نهایت برای مهندسان محوری خواهد شد، پوشش دادیم.

یکی از مشاهدات کلیدی این است که یک LLM را نمی توان خارج از چهارچوب مشخص استفاده کرد (به عنوان مثال، از طریق ChatGPT) و انتظار نتایج دقیق را در هر خط لوله ای که اجرا شده داشت.

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

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

در مقابل، یک مقاله در سال ۲۰۲۱ از DevOps.com نشان می دهد که تنها ۷.۵٪ از مهندسان SRE، AIOps را به عنوان یک محصول با “ارزش بالا” در نظر دارند. در حالی که استفاده از LLM نمی‌تواند با موفقیت جایگزین مهندسان SRE شود یا تمام مشکلات را حذف کند، استفاده از LLM در عملکرد سیستم می تواند پذیرش AIOps را بهبود بخشد. با ارائه یوزکیس ها( use cases ، ابزاری برای تعریف تعاملات مورد نیاز کاربر در سیستم ) ، ممکن است شاهد بهبود نرخ های پذیرش باشیم.

خوشبختانه، با سیستم‌هایی مانند Microsoft 365 Copilot، Google Bard وOpenAI ChatGPT ، عملیات افزوده با فناوری AIOps آسان تر و جذاب تر شده است.

با در نظر گرفتن این موضوع، عصر آینده ی SRE  شاهد تکامل LLMs از دستیارانی که وظایف معمول را انجام می دهند به شرکای استراتژیک که در فرآیندهای تصمیم گیری در SRE مشارکت دارند ، خواهد بود. با بهره گیری از LLM، تیم های SRE  می توانند کارهای دستی را کاهش دهند و تخصص ارزشمند انسانی را برای کارهای پیچیده تر و با ارزش تر آزاد کنند.

تکامل راه حل های LLM در عملکرد استراتژیک کسب و کار، به ناچار منجر به چالش های مربوط به هزینه و ROI (Return on Investment  معیاری به منظور ارزیابی کارایی یا سودآوری یک سرمایه‌گذاری یا مقایسه کارایی چندین سرمایه‌گذاری مختلف است) خواهد شد. در حالی که بسیاری از سناریوهای ذکر شده را می توان با استفاده از LLM حل کرد، یک مهندس SRE هنوز باید یک مطالعه امکان سنجی برای شناسایی، کمیت و اندازه گیری بازده سرمایه گذاری، قبل از اجرای چنین راه حل هایی انجام دهد. این مرحله برای جلوگیری از هزینه بیش از حد در مناطقی که بازدهی قابل توجه کمتری را فراهم می کند، بسیار مهم است.

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