مشاهدهپذیری یعنی فهمیدن رفتار سیستم در پروداکشن بدون ساخت بیلد خاص. تیم محصول به حداقل ابزار نیاز دارد که مشکل را سریع ببیند و به تغییر کد ربط دهد.
اهداف
- TTD (زمان تشخیص): دقیقهها، نه ساعتها.
- TTU (زمان فهم): یک داشبورد برای ساخت فرضیه کافی باشد.
- TTM (زمان رفع): امکان رولبک یا feature flag آماده.
سه سیگنال
- لاگ: ساختیافته، کوتاه و قابل کوئری؛ هر درخواست یک trace/span id دارد.
- متریک: تجمیع ارزان برای هشدار (SLI/SLO)؛ تاخیر، نرخ خطا، اشباع.
- تریس: مسیر کاربر تا سرویسهای پاییندست را وصل میکند.
برنامه حداقلی
- trace id را در ورودی (gateway) بسازید و با هدر منتقل کنید.
- لاگ ساختیافته با کانتکست (
userId,tenantId,featureFlag,version). - متریک RED/USE برای هر سرویس.
- نمونهبرداری هوشمند: ۱۰۰٪ برای خطاها، نرخ پایینتر برای ترافیک سالم.
هشدار بدون مزاحمت
- روی علائم هشدار دهید، نه جزئیات داخلی: خطای ۵xx، تأخیر بالا، checkout ناموفق.
- هشدارها runbook و مالک دارند؛ وقتی اثر کاربر واقعی است page کنید.
- هشدار SLO با پنجره و burn-rate چندگانه برای تعادل بین نویز و ریسک.
داشبورد که سریع جواب میدهد
- همهجا رخ میدهد یا یک منطقه/tenant؟
- آخرین deploy یا feature flag چه بوده؟
- کدام وابستگی کند یا خطا دارد؟
- کدام لاگ/تریس مسیر شکست را نشان میدهد؟
برای هر سرویس یک “golden dashboard” بسازید و از تکثیر بیهدف داشبوردها جلوگیری کنید.
نکات ابزاری
- استاندارد باز (OpenTelemetry) برای اجتناب از vendor lock-in.
- فیلدها و نام متریک را بین سرویسها استاندارد کنید.
- محیط محلی (docker-compose) برای تست اینسترومنتیشن قبل از مرج.
- بودجه ذخیرهسازی: داده با cardinality بالا (تریس/لاگ) retention کوتاهتری دارد.
چکلیست قبل از go-live
- کانتکست تریس در ورودی تولید میشود و در هر لاگ دیده میشود.
- بودجه خطا و SLO با محصول/اپس توافق شده.
- چک سنتتیک برای مسیرهای اصلی کاربر فعال است.
- لینک داشبوردها در runbook و در دسترس on-call.
مشاهدهپذیری یک فیچر محصول است: downtime را کم میکند، سرعت تیم را بالا میبرد و کاربران را راضی نگه میدارد.
ادامه مطالعه