22 Azar
پسامرتم - ۲۲ آذر - اینگرسکنترلر c18
تایملاین
-
از کی مشکل داشتیم؟
-
تیکت صبح ساعت ۱۳: SRE-5007
-
۱۶:۴۵: امیرحسین پیگیر مشکل شد
اقدامات شناسایی
-
ریپرودوس: با curl که گیر میکرد
-
ریکوئست مستقیم به pod ip: فهمیدیم بعضی پادهای traefik فقط مشکل دارن بقیه اوکین
-
نودهای اون پادها رو کوردون کردیم
-
اعمال تغییرات منابعی: اصلاح req/limit، جابجا کردن نودها، و تغییر رپلیکا، افزایش منابع نود
-
تغییرات موازی: vmagent و اینها
علّت بروز مشکل
-
شروع مشکل از کجا بوده؟
- شواهد: افزایش نرخ درخواست sentry (قطعی نیست به نظر)
-
علّت ریشهای مشخّص نشده
چی خوب پیش رفت؟
چی بد پیش رفت؟
-
(تقریباً هیچ) الرتی نداشتیم
-
متریکی که مشخّص کنه عمق فاجعه چقدره نداشتیم
-
اقدامات موازی داشتیم که باعث میشد نتونیم تأثیر کار رو ارزیابی کنیم/تصمیم اعمال تغییرات هماهنگ پیش نمیرفت
-
روی failure خود سرویسهامون الرت نداشتیم
-
یه سری OOM دیده بودیم و کاری نکرده بودیم
-
به علّت فلان چنلهای ارتباطیمون (راکت، جیرا) مختل نشد
کجا شانس آوردیم؟
-
کلاستر حسّاستری نبود
-
کاربرها کار خیلی حیاتیای نداشتن اون لحظه
-
جمع شد!
-
پادهای دیگه داشتن اذیت نمیکردن
اقدامات بعدی
-
متریک/الرت مناسبی برای «همین» اینسیدنت داشته باشیم
-
دراپ ناگهانی در ریکوئستهای traefik
-
یه ظرفیت مشخصی برای لودبالانسر تعیین کرده باشیم: مثلاً بگیم این کلاستر تا 10krps هندل میکنه
-
متریکی داشته باشیم که نشون بده چقدر از ظرفیت لودبالانسر پر شده
-
داشبورد سلامت لودبالانسر
-
اینسیدنت کامندر داشته باشیم!
-
برای سرویسهای critical ریکوئست/لیمیتها مساوی بشه، تارگت تراتل پایینتر باشه
-
الرت و اقدام روی کرش و افت کیفیت سرویس (مثلاً تراتل شدن) موردی پادهای critical داشته باشیم
-
لودبالانسر sentry رو جدا کنیم
-
لودبالانسر ابزارهای داخلی همروش رو جدا کنیم (فایدهی جانبی: تسهیل اعمال ملاحظات امنیتی مضاعف)
-
ابزار perf رو آماده داشته باشیم روی نودها برای دیباگ
-
کامپوننت critical: چیزی که dataplane هست و حتّی اختلال لحظهایش هم ریکوئستهای end-user رو تحت تأثیر قرار میده: traefik و coredns و haproxy و frigate