بهره‌گیری از روش RED برای ساده‌سازی تحلیل ریشه‌ای علت‌ها چگونه است؟

روش RED برای تحلیل ریشه‌ای علت‌ها چیست؟

روش RED حدود سال ۲۰۱۵ توسط مدیر ارشد فناوری Grafana، تام ویلکی، شکل گرفت؛ زمانی که او متوجه شد در فلسفه پایش، به‌ویژه در حوزه میکروسرویس‌ها، یک خلأ وجود دارد. از آن زمان تاکنون، این روش به یکی از ارکان اصلی رویکرد Grafana به مشاهده‌پذیری تبدیل شده است.

RED مخفف موارد زیر است:

• Rate

تعداد درخواست‌ها در ثانیه. سیستمی که نرخ درخواست بالایی در ثانیه دارد، معمولاً تجربه‌ای روان‌تر و پاسخ‌گوتر برای کاربران فراهم می‌کند، زیرا می‌تواند تعداد زیادی درخواست را به‌صورت مؤثر و سریع مدیریت کند.

• Error

تعداد درخواست‌هایی که با خطا مواجه می‌شوند. این مورد فقط شامل خطاهای واضحی مانند تایم‌اوت یا تراکنش‌های ناموفق نیست؛ بلکه می‌تواند نشانه‌ای از در دسترس نبودن جزئی یا کامل سرویس نیز باشد.

• Duration

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

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

چه زمانی باید از روش RED استفاده کرد؟

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

برای درک بهتر ارزش روش RED، بیایید به اهداف سطح سرویس (SLO) نگاه کنیم.

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

شاخص‌های سطح سرویس (SLI) معیارهایی هستند که برای سنجش تحقق SLA تعریف‌شده انتخاب می‌کنید.

ابزارهای روش RED

هنگامی که شروع به تعریف اهداف SLO می‌کنید و قصد دارید از روش RED استفاده کنید، ابزارهای متن‌باز متعددی وجود دارند که می‌توانند به شما کمک کنند. OpenTelemetry یا OTel مجموعه‌ای قدرتمند از پروتکل‌ها، کتابخانه‌های ابزارگذاری، عامل‌ها و یک کالکتور است که می‌توانید برای جمع‌آوری داده‌های تله‌متری از آن استفاده کنید. سپس می‌توانید این داده‌ها را با ابزاری مانند Grafana مصورسازی کنید.

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

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

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

Grafana Tempo ابزار مفید دیگری برای بهره‌گیری از روش RED است. این ابزار یک بک‌اند ردیابی توزیع‌شده، مقیاس‌پذیر و متن‌باز است که می‌تواند پروتکل‌های رایج ردیابی متن‌باز، از جمله Jaeger، Zipkin و OTel را دریافت کند.

برای روش RED، مولد شاخص‌های Grafana اهمیت ویژه‌ای دارد. این قابلیت از داده‌های موجود در Tempo استفاده می‌کند تا از روی تریس‌ها، شاخص تولید کند. این مولد دارای سه مجموعه پردازشگر مختلف است که یکی از آن‌ها پردازشگر شاخص‌های اسپن است. این پردازشگر مسئول تولید همان سه شاخصی است که پیش‌تر بررسی کردیم، برای هر ترکیب ممکن از ابعاد مختلف. این ابعاد شامل نام سرویس، عملیات، کد وضعیت و اساساً هر برچسب یا ویژگی موجود در اسپن می‌شود. (یک نکته کوتاه: هرچه ابعاد بیشتری در اسپن‌ها فعال کنید، کاردینالیتی شاخص‌های تولیدشده بالاتر می‌رود؛ بنابراین بهتر است چند مطلب درباره مدیریت کاردینالیتی به فهرست مطالعه خود اضافه کنید!)

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

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

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

بررسی روش RED در عمل

تصویر بالا پایش یک برنامه فرضی را نشان می‌دهد. داشبورد از پنل‌هایی تشکیل شده که بسیاری از شاخص‌هایی را که پیش‌تر بررسی کردیم، مصورسازی می‌کنند. در سمت چپ، بخش درخواست‌ها، افزایش یا کاهش ناگهانی حجم درخواست‌های HTTP را به تفکیک سرویس نمایش می‌دهد و دیدی جزئی‌نگر ارائه می‌کند.

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

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

مصورسازی تأخیر نیز بسیار مفید است. درک اینکه ۹۵٪ یا ۹۹٪ کاربران شما چه سطحی از عملکرد را تجربه می‌کنند، هم تأثیرگذار است و هم هنگام تعریف SLOها کمک‌کننده خواهد بود.

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

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

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

بردن مشاهده‌پذیری به آینده

می‌توان حتی فراتر از این هم به آینده مشاهده‌پذیری نگاه کرد؛ همان‌طور که در مثال یک برنامه اشتراک سفر می‌بینیم.

در اینجا مشاهده می‌کنید که منطقه us-east که عملکرد خوبی دارد، به‌عنوان خط مبنا برای مقایسه کنارهم با منطقه eu-north استفاده می‌شود؛ منطقه‌ای که مصرف CPU بسیار بیشتری دارد. این مقایسه امکان بررسی تفاوت‌های منطقه eu-north را فراهم می‌کند تا مشخص شود چه چیزی باعث این مصرف بالای CPU شده است.

این نوع مقایسه کنارهم می‌تواند برای اهداف مختلفی استفاده شود؛ از بررسی افزایش‌های ناگهانی گرفته تا مشاهده تفاوت میان دو قطعه کد. در این مثال، مصورسازی‌ها بلافاصله نشان می‌دهند که صف سفارش خودرو در منطقه eu-north بسیار طولانی‌تر از us-east است. بررسی داده‌ها از این منظر و روش‌های دیگر، بینش‌هایی فراهم می‌کند که به شما امکان می‌دهد کد خود را تا حد امکان بهینه کنید و تضمین نمایید همه کاربران از تجربه‌ای باکیفیت و یکسان بهره‌مند شوند.

آیا روش RED جایگزین روش USE می‌شود؟

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

از کجا شروع کنیم

اگر آماده‌اید کار با روش RED را آغاز کنید، مستندات Grafana جزئیات فراوانی درباره ابزارگذاری مطابق بهترین رویه‌ها از همان روز اول ارائه می‌دهد. علاوه بر این، در Grafana.com/dashboards یک کتابخانه کامل از داشبوردها وجود دارد که می‌توانید آن‌ها را دانلود کرده، استفاده کنید و متناسب با نیاز خود سفارشی‌سازی نمایید. راهکارهای سازمانی نیز در قالب مشاهده‌پذیری برنامه برای کاربران Grafana Cloud در دسترس هستند.