۴ مرحله برای بهبود تجزیه و تحلیل علت اصلی

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

هنگامی که یک اختلال یا مشکل عملکرد سیستم وجود دارد، تیم‌های فناوری اطلاعات به کمک می‌آیند تا خدمات را در سریع‌ترین زمان ممکن بازیابی کنند. برخی از سازمان‌های فناوری اطلاعات از مدیریت خدمات فناوری اطلاعات (ITSM) مدیریت حوادث< /a> برای بازیابی سرویس، روش‌های مدیریت مشکل را برای انجام تجزیه و تحلیل علت اصلی (RCA) دنبال کنید. سازمان‌های پیشرفته‌تر ممکن است از مهندسان قابلیت اطمینان سایت (SRE) درگیر در مدیریت حوادث و مشکلات استفاده کنند، اما مسئولیت اصلی آنها انجام اقدامات پیشگیرانه‌تر برای کاهش نرخ خطا و بهبود اهداف سطح خدمات.

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

در اینجا چند نمونه آورده شده است:

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

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

پیدا کردن علت اصلی مشکلات عملکرد پراکنده

به‌عنوان یک توسعه‌دهنده در دوران جوانی‌ام و بعداً به‌عنوان CIO، مشکلات زیادی را تجربه کرده‌ام، و یافتن علت اصلی می‌تواند زمان‌بر و مستعد خطا باشد.

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

نحوه انجام تجزیه و تحلیل علت ریشه (RCA) 

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

1. مشاهده پذیری را به عنوان یک محصول مدیریت کنید
2. برنامه ریزی برای تجزیه و تحلیل از بالا به پایین و پایین به بالا
3. تعیین کنید که آیا مشکل شبکه است
4. در علل ریشه ای همکاری و مثلث کنید

مرحله ۱: قابلیت مشاهده را به عنوان یک محصول مدیریت کنید

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

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

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

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

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

آصاف ییگال، یکی از همکاران، می‌گوید: «تغییر به یک ذهنیت تحلیل داده‌های هدفمندتر و بی‌درنگ در روش مشاهده‌پذیری یک شرکت، مهندسان را قادر می‌سازد تا به طور فعال داده‌ها را جستجو کنند و بینش‌های مورد نیاز برای حل گیج‌کننده‌ترین مسائل عملکرد برنامه را به دست آورند. بنیانگذار و مدیر ارشد فناوری Logz.io. “برای دستیابی به علت اصلی و حل مشکلات عملکرد حیاتی سیستم‌های سنگین میکروسرویس مدرن، راه‌حل کارآمدتری مورد نیاز است که داده‌ها را با استفاده از اتوماسیون قطع می‌کند و پاسخ پیشگیرانه به جای واکنشی را ممکن می‌سازد.”

داشتن ذهنیت بهبود مستمر و استراتژی انتشار تدریجی مطابق با استانداردهای مشاهده‌پذیری مهم است. از آنجایی که NOC ها، SOC ها و SRE ها با مشکلات جدیدی مواجه می شوند، تیم های توسعه دهنده باید از بازخورد برای بهبود جمع آوری داده ها استفاده کنند.

مرحله ۲: برنامه ریزی برای تجزیه و تحلیل از بالا به پایین و پایین به بالا

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

Grant Fritchey، مدافع توسعه‌دهنده در نرم‌افزار Redgate، نمونه‌ای از درخواستی را به اشتراک می‌گذارد که سریع اجرا می‌شد. ، به طور متوسط ​​حدود ۶ میلی ثانیه است. از نقطه نظر اندازه‌گیری عملکرد، این یک جستار بی‌اهمیت بود، تا زمانی که تعداد اجراها را دیدید و متوجه شدید که این پرس‌وجو هزاران بار در دقیقه فراخوانی می‌شود. حتی در ۶ میلی ثانیه، به اندازه کافی سریع کار نمی کرد. این امر بر نیاز به یکپارچه‌سازی ابزارهای نظارتی و نظارتی پایگاه داده برای دستیابی به درک جامع و دقیق از عملکرد سیستم تأکید می‌کند.»

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

مرحله ۳: تعیین کنید که آیا مشکل شبکه است

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

نیکلاس وایبرت از Isovalent. Cloud-native و لایه‌های متعدد مجازی‌سازی و انتزاع شبکه ناشی از کانتینری‌سازی، ارتباط شبکه را به‌عنوان علت اصلی مشکل‌تر می‌کند.

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

Eileen Haggerty، AVP بازاریابی محصول و راه‌حل‌ها در NETSCOUT. «اما هر دامنه و مکان باید دارای تجزیه و تحلیل، هوش و سطح دید یکسان باشد، صرف نظر از اینکه حجم کاری، برنامه‌ها و سرویس‌ها در کجا اجرا می‌شوند. یک رویکرد اندازه‌گیری منسجم در هر محیط میزبانی، تعیین آسان‌تر و سریع‌تر علت اصلی و مکان مشکلات عملکرد برای برنامه‌ها در هر زیرساخت شبکه را ممکن می‌سازد.»

مرحله ۴: همکاری و مثلث سازی در مورد علل ریشه ای

دو توصیه دیگر بر نحوه همکاری تیم ها برای حل و فصل حوادث و انجام تجزیه و تحلیل علت اصلی تمرکز دارد. من بیش از سهم من در تماس‌های پل و اتاق‌ها برای یافتن و رفع مشکلات انجام داده‌ام، که می‌تواند در طول یک قطعی بزرگ یک آسیب ضروری باشد. با این حال، این رویکردها هنگام حل مسائل عملکرد پراکنده که نیاز به همبستگی داده ها از ابزارهای متعدد و منابع داده قابل مشاهده دارند، بسیار کمتر موثر هستند. بسیاری از این مسائل نیاز به یک تیم بین رشته‌ای برای همکاری، به اشتراک گذاشتن دانش، و همکاری مؤثر با یکدیگر در صورت نیاز به RCA دارند.

کریس هندریچ، معاون مدیر ارشد فناوری در SADA. “تجزیه این سیلوهای از هم گسیخته می تواند به شرکت ها کمک کند تا توانایی خود را در انجام تجزیه و تحلیل علل ریشه ای بهبود بخشند.”

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

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