ورود مهندسی قابلیت اطمینان (SRE) به سازمان‌ها؛ راهکاری هوشمند برای پایان دادن به مشکلات تکراری IT

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

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

کارشناسان و مدیران ارشد محصول و هوش مصنوعی در شرکت نرم‌افزاری لیک‌ساید (Lakeside Software) معتقدند که اتکای صرف به‌سرعت عمل، ریشه اصلی مشکلات را درمان نمی‌کند.

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

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

ورود اصول SRE به دستگاه‌های کاربران و نقاط پایانی

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

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

دستگاه‌ها، نرم‌افزارها و سرویس‌هایی که یک کارمند روزانه با آن‌ها سروکار دارد، به بخش جدایی‌ناپذیر سازوکار سازمان تبدیل شده‌اند و پایداری آن‌ها تأثیر مستقیمی بر توانایی افراد در انجام وظایف کاری‌شان دارد.

یکی از همکاران تجاری اخیراً این چالش را به‌زیبایی توصیف کرد و گفت: «خطرات نوظهور را در همان زمانی که هنوز در سطح ۰ تا ۲ درصد هستند به من گزارش دهید و شواهد کافی برای اولویت‌بندی در اختیارم بگذارید؛ زیرا وقتی انحراف سیستم به ۵ تا ۱۰ درصد بالاتر از خط مبنا برسد، مرکز پشتیبانی زیر بار حجم انبوه تماس‌ها و تیکت‌ها منفجر خواهد شد.»

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

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

برای نمونه، در یک شرکت بزرگ بیمه حاضر در فهرست Fortune 100، تیم فنی متوجه شد که نزدیک به ۲۵ درصد از زمان توقف و خرابی سیستم‌های مرکز تماس عملاً از دید بخش IT پنهان مانده بود. این سازمان با ترکیب داده‌های تله‌متری نقاط پایانی (دستگاه‌های کاربران) و اتوماسیون پیش‌دستانه، موفق شد حجم تیکت‌های پشتیبانی را طی یک سال ۳۵ درصد کاهش دهد و تنها با یک فرآیند اتوماسیون خودخدمت (Self-service)، از ثبت بیش از ۴۵٬۰۰۰ تیکت جلوگیری کند.

از الگوهای تکراری درس بگیرید

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

این سازمان با بهره‌گیری از داده‌های دستگاه‌های کاربران توانست عوامل این رخدادهای تکراری را ریشه‌یابی و رفع کند؛ اقدامی که سالانه نزدیک به ۵۰٬۰۰۰ مورد از تیکت‌ها را کاهش داد و صرفه‌جویی مالی تقریبی ۱٫۶ میلیون دلاری را به‌همراه داشت.

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

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

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

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

ارزیابی پایداری سیستم پس از رفع اختلال

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

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

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

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

هیچ‌کدام از این موارد منکر اهمیت مشاهده‌پذیری در لحظه، اتوماسیون یا یک میز خدمت کارآمد نیستند؛ سازمان‌ها به تمام این ابزارها نیاز دارند. سرعت واکنش تیم‌های IT و میزان کاهش کارهای دستی به‌کمک اتوماسیون همچنان اهمیتی کلیدی دارد.

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