هدف
میخواهیم پایداری و کیفیت خدمات پروداکتی که ساخته ایم را مانیتور کنیم.
معمولا پروداکت ها در طول زمان رشد می کنند ولی در زمانی که تعداد زیادی پروداکت را توسعه داده ایم، ممکن است از پایداری بلادرنگ آنها غافل شویم یا نیاز باشد مثل مادر یک نوزاد، در ابتدای رشد، حواسمان به شاخص های حیات این موجود باشد.
وقتی یک متریک حیاتی مرتبط با پروداکت ما از محدوه خاصی تجاوز کرد، باید توجه ما و اعضای تیم به این موضوع با اخطار جلب شود.
مثال:
با مشاهده و زوم روی تعدادی از تجربه های منفی، متوجه نارضایتی بیماران بیمارستانی از قطعی های سرور های نوبت دهی مراکز شده ایم.
میخواهیم کیفیت دریافت نوبت بیماران بیمارستانی را مانیتور کرده و ارتقال دهیم.
چه متریکی انتخاب کنم؟
در تشخیص متریک مورد نظرمان این ویژگی ها اهمیت دارند:
- به core service journey کاربر پروداکت نزدیک باشد. مثلا متریکی که در حاشیه خدمت اصلی هست و قطع شدن آن اهمیت پایین تری دارد را انتخاب نکنیم. (یا در درجه دوم انتخاب قرار دهیم)
- ترجیحا به متریک های رشد نمایی Exponential Metrics نزدیک تر باشد. در این لینک میتوانید این متریک ها را ببینید. (البته دقت کنید که نباید عین متریک مطرح شده در این رفرنس بیاید، بلکه متریکی که بلادرنگ، شروع به ضربه به نتورک می کند را باید رصد کنیم)
- از نوع Leading indicators باشد. یعنی به محض بروز تغییر در تجربه کاربر، متوجه شویم نه اینکه مثلا بعد از چند روز متوجه شویم که یک سرویس قطع شده.
- شفاف و مشخص باشد
در مثال بالا، متریک مورد نظر ما میشود دریافت بیش از 30 بار خطای 29 در وب سرویس اولین نوبت خالی به ازای سرور مرکز درمانی در 6 ساعت گذشته.
دیزاین و ارسال اونت
- دیزاین اونت: بر اساس متریک و پیشبینی نیازهای آینده مان، دیتایی که باید به اسپلانک ارسال شود را طراحی میکنیم. ساختار اونتهای قبلی به دیزاین درست کمک میکنند.
- پیاده سازی اونت : با کمک تیم فنی یا ابزار low-code مثل tag manager متریکی که مد نظرمان هست را به عنوان event به اسپلانک ارسال و تست کنیم.
در این مثال، در event پاسخ freeturn این دیتا (اطلاعات خطا، اطلاعات پزشک، مرکز، سرور، کاربر را دریافت میکنیم)
نتیجه تست که مطمئن شویم دیتای مورد نیازمان به اسپلانک ارسال می شود:
جستجوی معادل را در اسپلانک بسازیم
بر اساس نیازمان، یک جستجو در اسپلانک دیزاین میکنیم.
در این مثال میخواهیم به ازای هر سرور، تعدا خطا و کاربر درگیر در خطا در 6 ساعت گذشته را دریافت کنیم.
توضیح عمکلرد بخش های لیبل خورده این اسکرین شات:
- تمامی event های خطای 29 اولین نوبت خالی را برگردان
- اگر نام سرور خالی بود با نامشخص جایگزین کن
- تعداد کاربر درگیر در خطا و تعدا خطا را به تفکیک هر سرور بر اساس داده های داخل هر اونت نمایش بده (به ترتیب: با data.terminal_id و count و data.server_name (
- عنوان ستون نام سرور را عوض کن
- فقط اگر به ازای هر سرور بیش زا 30 نتیجه بر میگشت نمایش بده.
- بر اساس سروری که بیشترین کاربر درگیر درخطا را داشته مرتب کن.
یک alert جدید بسازید
برای ارسال رخداد، از جستجوی قبلی یک alert میسازیم.
توضیح عمکلرد بخش های لیبل خورده این اسکرین شات:
- در لحظه و بلادرنگ این جستجو تکرار شود یا در راس زمان های مشخص.
- جستجو برای 6 ساعت قبل انجام شود.
- راس دقیقه 10 ام ساعت 7 و 12 و 19 هر روز اجرا شود . (مثلا 7:10 و یا 19:10)
- لاگ سابقه ارسال ها تا 24 ساعت قابل دسترسی باشد.
- وقتی اخطار ارسال شود که نتیجه جستجو، حداقل یک نتیجه یا بیشتر داشته باشد.
- به ازای هر کدام از نتایج (هر ردیف از نتایج جستجوی مرحله قبل) یک بار اجرا شود.
- نوع اخطار از نوع پیام تلگرامی باشد. و مشخصات ربات و گروه مرتبط را اعلام می کنیم.
چند نکته پایانی
- هم تیمی فنی را سورپرایز نکنیم! : پس از تنظیم و تست، تیم زیرساخت و فنی مرتبط با حل این مسئله را نسبت به نحوه کار و استفاده از این الرت آنبورد کنیم.
- در متن اخطار user centric دیزاین کنید : اثر این اختلال در کاربر نهایی باید در پیام مشخص باشد. مثلا 3 بیمار بیش از 13 بار با خطای قطع ارتباط روبرو شده اند.
- قانون less is more: تعداد زیاد خطا و متریک به معنی عدم توجه یا اهمیت آنهاست. پس یک متریک انتخاب کنید ولی مثل ناموس از آن مراقبت کنید!