خانه / اخبار تکنولوژی / قطع سرویس Kafka در PagerDuty باعث خاموش شدن هشدارها برای هزاران شرکت شد

قطع سرویس Kafka در PagerDuty باعث خاموش شدن هشدارها برای هزاران شرکت شد

قطع سرویس Kafka در PagerDuty باعث خاموش شدن هشدارها برای هزاران شرکت شد

نویسنده:

انتشار:

به‌روزرسانی:

تعداد نظرات: 0

زمان مطالعه: 3 دقیقه
👀 خبر در یک نگاه:

در ۲۸ آگوست ۲۰۲۵، پلتفرم مدیریت رخداد PagerDuty با قطعی جدی مواجه شد که بیش از ۹ ساعت طول کشید و باعث از کار افتادن هشدارها برای هزاران سازمان شد. علت مشکل، باگ در پیاده‌سازی Kafka بود که منجر به مصرف بی‌رویه منابع و خرابی زنجیره‌ای سرویس‌ها شد.

شرکت PagerDuty، پلتفرم مدیریت رخداد (Incident Management) که هزاران سازمان برای دریافت هشدار از آن استفاده می‌کنند، در ۲۸ آگوست ۲۰۲۵ خود دچار یک اختلال بزرگ شد. جزئیات مشکل، تاثیر روی مشتریان و اقدامات پیشگیرانه آینده در گزارش جامع این قطعی توضیح داده شده است.

جزییات خطا

این رخداد باعث اختلال یا تأخیر در پردازش رویدادهای ورودی برای مشتریان در منطقه خدمات ایالات متحده PagerDuty شد. این اختلال بیش از ۹ ساعت موجب افت شدید سرویس شد. در اوج حادثه، حدود ۹۵٪ از رویدادها به مدت ۳۸ دقیقه رد شدند و ۱۸٪ از درخواست‌های ایجاد (Create Requests) طی ۱۳۰ دقیقه با خطا مواجه شدند.

ریشه‌یابی خطا

طبق این گزارش قطعی، علت مشکل یک باگ در قابلیت جدیدی که منتشر شد، بود. این فیچر، برای بهبود لاگینگ در استفاده از API و کلیدها در حال انتشار بود. با گذشت زمان از انتشار این قابلیت، مصرف روی کلاسترهای Kafka در PagerDuty، فراتر از ظرفیت سیستم افزایش یافت.

این مورد در گزارش قطعی، به این شکل توضیح داده شد:

«به دلیل یک خطای منطقی در این قابلیت، برای هر درخواست API یک Kafka producer جدید ساخته می‌شد، درحالی‌که باید از یک Kafka producer مشترک، برای تولید همه پیام‌ها استفاده می‌شد.»

گزارش توضیح می‌دهد که برداشت PagerDuty از نحوه استفاده از کتابخانه pekko-connectors-kafka در زبان Scala باعث این خطای کدنویسی شد. اسکوپ بار اضافی نیز مشخص شد: «Kafka در اوج بار، مجبور شد تقریبا ۴.۲ میلیون Producer اضافی در هر ساعت ردیابی کند؛ یعنی ۸۴ برابر بیشتر از حالت عادی.» در ادامه توضیح داده شده که این وضعیت باعث Thrashing در Kafka و سپس مصرف کامل حافظه JVM heap شد که در نهایت منجر به خرابی زنجیره‌ای کلاستر شد.

عواقب از دسترس خارج شدن سرویس

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

بی‌خبری و خطاهای دیگر

طنز تلخ‌تر ماجرا اینجا بود که این اختلال که یکی از پلتفرم‌های پیشرو مدیریت رخداد را تحت تأثیر قرار داده بود، حتی باعث تأخیر در ارتباطات خارجی شد؛ چرا که آپدیت‌هایی که توسط تیم PagerDuty نوشته می‌شد، در صفحه وضعیت عمومی نمایش داده نمی‌شد. این «meta-failure» باعث سردرگمی بیشتر مشتریان شد، چون نمی‌توانستند در جریان وضعیت قرار بگیرند.

البته PagerDuty تنها پلتفرم مدیریت رخداد نیست که در سال‌های اخیر با قطعی طولانی مواجه شده؛ مشتریان Opsgenie هم در سال ۲۰۲۲ یک قطعی ۱۴ روزه را تجربه کردند.

واکنش کاربران مختلف

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

«امروز قرار بود یه روز مهم توی کار باشه. اما به‌جاش فقط مشتری‌هایی که عصبانی بودن، سرمون داد زدن؛ چون PagerDuty از کار افتاد… تا حالا شده آن‌کال باشی و حس کنی کاملا کوری؟»

کاربر دیگه‌ای به اسم Vimda پیشنهاد داد که همه سیستم‌ها باید یک پلن دوم هم داشته باشن:

«همیشه یه سیستم پشتیبان برای هشداردهی داشته باش؛ حتی اگه دستی باشه.»

کاربر Twirrim هم این موضوع رو پررنگ‌تر کرد و با نگاهی عمیق گفت که خود ابزارهای مانیتورینگ هم نیاز به مانیتورینگ دارن:

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

جمع‌بندی

در کنار گزارش دقیق از خطا و زمان‌بندی اتفاقات، PagerDuty برنامه‌هایی برای بهبود آینده هم منتشر کرد تا از تکرار چنین سناریویی جلوگیری شود. این بهبودها شامل گسترش مانیتورینگ داخلی (به‌ویژه روی JVM و Kafka) و ایجاد قوانین سخت‌گیرانه‌تر در مدیریت تغییرات بود تا مهندس‌ها همچنان سریع ولی با ایمنی بیشتر کار کنند.

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

فرهنگ یادگیری مداوم PagerDuty باعث می‌شود از دل چنین رخدادهایی قوی‌تر بیرون بیان؛ هم از نظر فناوری و هم خود تیم.

منبع: infoq.com

فرصت‌های شغلی

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

دیدگاه‌ها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *