تیم مهندسی داده Miro اخیراً در مورد چگونگی سیستم‌بندی هشدارها و مدیریت حوادث بحث کرده است. همراه با استانداردسازی معیارهای مشاهده پذیری و تعاریف هشدارها، تیم شروع به استفاده از OpsGenie برای مدیریت حوادث کرد. این به تیم کمک کرد تا چالش‌های مربوط به مقیاس‌بندی مانند فرمت استاندارد برای برچسب‌گذاری متریک، تعاریف هشدار، وظایف حین تماس و غیره را برطرف کند.
گونچالو کاستا و ریکاردو سوزا، مهندسان داده در Miro، با ارسال پستی در وبلاگ مدیوم، سفر تیم را با ورود Miro به حالت “رشد فوق العاده” توصیف کردند. کوستا و سوزا در مورد معماری و اجزای سازنده در Miro توضیح دادند: زیرساخت و پردازش داده ها در AWS Stack اجرا شد، پرومتئوس معیارها را از اجزای مختلف به گیرندگان مختلف از طریق Alertmanager منتقل کرد و Grafana برای نشان دادن داشبورد بصری معیارهای Prometheus استفاده شد و هشدارهای مربوط به ناهنجاری ها به کانالی در Slack هدایت شدند.
سه معیار وجود داشت که تیم ابتدا از طریق Prometheus مشاهده کردند: System، Middleware و Application. این معیارها دارای برچسب‌هایی بودند که اطلاعات خود را ارائه می‌کردند، مانند اینکه از کجا آمده‌اند، چه کسی مالک آنهاست، و غیره. تیم با استفاده از برچسب‌گذاری مجدد، برچسب‌های دریافتی را به اطلاعات قابل فهم در تعاریف هشدار و داشبورد تبدیل کرد.
مدیر هشدار، هشدارها را به Slack هدایت کرد. با این حال، با افزایش اندازه تیم، چالش‌هایی مانند تعیین برنامه‌های آماده‌سازی، حوادث از دست رفته، و غیره نیز افزایش یافت. برای رسیدگی به این چالش ها، تیم سطوح اولویت برای اجزای مختلف و اهمیت هشدار برای این اجزا را ارائه کرد.
در مرحله بعدی، تیم یک پیام واضح و قابل اجرا ایجاد کرد که عملکرد مؤلفه تحت تأثیر و منابع مرتبط را مشخص می کرد. با کمک Site Reliability Engineers (SREs)، تیم مهندسی داده مجموعه استانداردی از برچسب ها را برای معیارهای موجود Prometheus تعریف کرد. چند نمونه عبارتند از:
- miro_environment: محیط مرتبط با کامپوننت
- miro_service: سرویسی که توسط هشدار برجسته می شود
- miro_owner: تیمی که معیار را در اختیار دارد
- miro_function: تابع مولفه مربوط به متریک
- [component]_id: شناسه کامپوننت
برای مدیریت مقدار اطلاعات مربوط به یک متریک، تیم مجموعه ای از مراحل را برای نوشتن یک تعریف هشدار استاندارد تعریف کرد. این موضوع به درک جزئیات مربوط به مؤلفه‌ها کمک کرد، زیرا شامل تعاریف نام متریک، توضیحات آن، مقادیر آستانه برای راه‌اندازی هشدارها، سطوح اهمیت، پر کردن runbook و غیره بود.
برای رفع خرابی اجزای مهم، تیم مهندسی داده OpsGenie را به عنوان پلتفرم مدیریت حادثه خود انتخاب کرد. با استفاده از OpsGenie، تیم می‌تواند یک برنامه زمان‌بندی تماس پشتیبانی شده از چرخش چندگانه و لغو تنظیمات را پیکربندی کند. در اخبار مرتبط، می بینیم که انتقال از کانال های Slack به ابزارهایی مانند OpsGenie یا PagerDuty کمک می کند تا تمرین SRE به شیوه ای چابک به بلوغ برسد.
با برچسب‌گذاری و تعاریف استاندارد متریک، شناسایی هشدارها آسان شد و باعث شد تیم در مقابله با حوادث پاسخگوتر باشد. برخلاف روش‌های قبلی کار، تیم شروع به نگهداری یک کتابچه کرد که عیب‌یابی را تسریع می‌کرد.
به عنوان یک طرف، شاهدیم که Data Observability جایگاه خود را در چرخه Hype 2022 Gartner تثبیت می کند. گارتنر OpenTelemetry را به عنوان استانداردی برای نحوه استخراج گزارش‌ها، ردیابی‌ها و داده‌های متریک از سرورها، زیرساخت‌ها و برنامه‌ها تعریف می‌کند.
تغییر رویکرد با قابلیت مشاهده به تیم مهندسی داده Miro کمک کرده است تا خرابی اجزای حیاتی را شناسایی کرده و برای کاهش سریع، برنامه ریزی کند. این تیم اذعان می کند که با ادامه رشد حجم داده ها، تنوع و سرعت در Miro هنوز چیزهای زیادی برای بهبود وجود دارد.
