اینسیدنتو سامانهای برای مدیریت حادثه و شیفت آنکال است. هشدار را به آدم درست میرساند، مسیر رسیدگی را از لحظهی شناسایی تا رفع ثبت میکند، و تا نوشتن پستمورتم رهایش نمیکند. وقتی سرویس شما میخوابد، معلوم است چهکسی بیدار است.
سرویس ابری و آمادهی استفاده؛ نه سروری میگیرید، نه پنل پیامکی میخرید، نه نگران بالا ماندن خودِ سامانهی هشدار میشوید.
زمان از شروع
00:17:42
زمان تا تأیید
00:01:12
حادثه ثبت شد
02:14:06خودکار، از وبهوک Alertmanager
هشدار به آنکال شیفت شب
02:14:09پیامرسان سازمانی، سپس پیامک
تأیید دریافت توسط مریم رضایی
02:15:18مالک حادثه مشخص شد
ریشهی مشکل: پر شدن استخر اتصال
02:31:47یادداشت بررسی ثبت شد
در انتظار: رفع نهایی و نوشتن پستمورتم
آنکال فعلی: مریم رضایی
22:00 → 08:00 · شیفت شب
نمونهای از یک حادثه؛ دادهها واقعی نیستند.
مسئله
بیشتر تیمها ابزار مانیتورینگ دارند. آنچه ندارند، فرایندی است که مشخص کند هشدار به کدام آدم میرسد، چهکسی مسئول است و بعدش چه اتفاقی میافتد.
هشدار در یک گروه پرترافیک گم میشود و ساعتها بعد، وقتی کاربر تماس میگیرد، تازه معلوم میشود سرویس از کار افتاده بود.
بدون شیفت مشخص، همه فرض میکنند یک نفر دیگر دارد رسیدگی میکند. یا برعکس، سه نفر موازی روی یک مشکل کار میکنند.
سه ماه بعد همان خرابی تکرار میشود و کسی یادش نیست بار قبل چهچیزی آن را حل کرد. دانش، در گفتوگوهای پاکشده باقی میماند.
چرخهی مدیریت حادثه
پنج مرحلهای که اینسیدنتو دنبال میکند. هیچ مرحلهای به حافظهی آدمها سپرده نمیشود.
حادثه را دستی ثبت میکنید یا ابزار مانیتورینگ با یک وبهوک آن را میسازد؛ همراه با شدت، سرویس مربوطه و منبع هشدار.
بر اساس شیفت آنکال و زنجیرهی اسکالیشن، هشدار روی کانالهای تعریفشده میرود و تا وقتی کسی تأیید نکند ادامه پیدا میکند.
هرکس تأیید کند مالک حادثه میشود. یادداشتها، افراد کمکی و مسیر بررسی همانجا کنار خط زمانی ثبت میشود.
وضعیت به «رفعشده» میرود، استتوسپیج بهروز میشود و ذینفعان بدون اینکه کسی خبر بدهد، خبردار میشوند.
گزارش نهایی، ریشهی مشکل و کارهای پیشگیرانه به همان حادثه میچسبد و ماهها بعد هم قابل جستوجو است.
امکانات
هدف، جایگزینی ابزار مانیتورینگ شما نیست. اینسیدنتو روی همان چیزی که دارید مینشیند و از هشدار به بعد را مدیریت میکند.
یک حادثه میتواند با تشخیص خود آدمها ثبت شود یا با هشداری که از سیستم مانیتورینگ میرسد ساخته شود. در هر دو حالت، مسیر بعدی یکی است: شدت، سرویس مربوطه، مالک و خط زمانی.
شیفتهای چرخشی روزانه، هفتگی یا سفارشی؛ با جانشین، پوشش موقت برای مرخصی و امکان جابهجایی شیفت بین دو نفر. همیشه معلوم است همین لحظه چهکسی آنکال است.
چرخهی این هفته — تیم زیرساخت
اگر در بازهای که خودتان تعیین میکنید کسی تأیید نکرد، هشدار به نفر بعد، تیم پشتیبان یا سطح مدیریتی بالاتر میرود.
هر تیم سرویسهای خودش را میبیند. نقشها مشخص میکنند چهکسی میتواند حادثه را ببندد، شیفت را عوض کند یا استتوسپیج را تغییر دهد.
یک صفحهی عمومی یا داخلی که وضعیت سرویسها، حادثههای جاری و سابقهی آپتایم را نشان میدهد.
قاعده بنویسید: اگر منبع هشدار فلان بود و شدت بحرانی، برچسب بزن، به این تیم بفرست، در کانال عمومی اعلام کن.
برای پیامک و تماس صوتی از سرویسهای ایرانی مثل کاوهنگار استفاده میکنیم. خرید پنل، شارژ اعتبار و کانفیگ سمت ماست؛ شما فقط شماره را وارد میکنید.
کانالهای هشدار
برای هر سطح از شدت و هر مرحله از اسکالیشن، کانال جدا تعریف کنید. اطلاعرسانی تا وقتی کسی تأیید نکند متوقف نمیشود.
برای پیامک و تماس صوتی به سرویسهای ایرانی مثل کاوهنگار وصل هستیم. لازم نیست پنل بخرید، اعتبار شارژ کنید، خط اختصاصی بگیرید یا با کانفیگ و تحویل پیام درگیر شوید؛ همهی اینها سمت ماست.
کانال روزمرهی تیم؛ برای هشدارهایی که در ساعت کاری میرسند.
وقتی اینترنت لرزان است، پیامک میرسد. پنل و اعتبارش را ما تأمین میکنیم.
برای ساعت سه بامداد؛ جایی که نوتیفیکیشن کافی نیست.
برای اطلاعرسانی به ذینفعان و خلاصهی دورهای حادثهها.
هر مقصد دیگری که خودتان دارید؛ ربات داخلی، سامانهی تیکت یا لاگ.
آنکال اول
پیامرسان سازمانی + پیامک
آنکال اول
تماس صوتی
آنکال دوم
تماس صوتی + پیامک
مسئول فنی تیم
تماس صوتی
عددها دقیقهی سپریشده از ثبت حادثه هستند و هرکدام قابل تغییرند.
اینتگریشن
اگر ابزار شما بتواند یک درخواست HTTP بفرستد، اتصالش کار چند دقیقه است. برای ابزارهای پرکاربرد هم اتصال آماده وجود دارد.
علاوه بر ورودی، خروجی هم دارید: با وبهوک خروجی میتوانید هر تغییر وضعیت حادثه را به سامانهی تیکت یا داشبورد داخلی خودتان بفرستید.
POST /api/v1/hooks/{token}
Content-Type: application/json
{
"title": "5xx error rate above 2%",
"service": "payments-api",
"severity": "critical",
"source": "alertmanager",
"fingerprint": "payments-5xx",
"details": {
"runbook": "https://wiki.internal/payments"
}
}استتوسپیج
وقتی وضعیت حادثه را عوض میکنید، استتوسپیج خودش بهروز میشود. میتوانید آن را عمومی روی دامنهی خودتان منتشر کنید یا فقط برای تیمهای داخلی بگذارید.
اتکاپذیری و استقرار
شما باید حواستان به آپتایم سرویس خودتان باشد، نه به آپتایم ابزاری که قرار است خبر خرابی را برساند.
اگر ابزاری که باید خبر خرابی را بدهد خودش خواب باشد، هیچکدام از این امکانات معنا ندارد. بالا ماندن اینسیدنتو، مسیرهای ارسال جایگزین و پایش خودِ سامانه، مسئلهی ماست نه شما.
لازم نیست سرور بگیرید، چیزی نصب کنید یا نگران بهروزرسانی و پشتیبانگیری باشید. حساب میسازید، سرویسها و شیفتها را تعریف میکنید و کار تمام است.
برای سازمانهایی که دادهی حادثهها و شماره تماس آدمها نباید از شبکهشان بیرون برود، امکان استقرار اختصاصی هم وجود دارد.
سوالات متداول
فاصلهی بین «سرویس خراب شد» و «یک آدم مشخص دارد رویش کار میکند». اینسیدنتو هشدار را به فرد آنکال میرساند، تا تأیید نشدن پیگیری میکند، و بعد از رفع، سابقه را نگه میدارد.
در گروه، هشدار به همه میرسد و در نتیجه به هیچکس. مسئولیت مشخص نیست، سابقهای نمیماند و اگر کسی پیام را نبیند هیچ اتفاق دیگری نمیافتد. اینسیدنتو شیفت، مالکیت، اسکالیشن و خط زمانی دارد.
نه. اینسیدنتو چیزی را اندازه نمیگیرد و سرویسی را چک نمیکند. کار مانیتورینگ را همان ابزار فعلی شما انجام میدهد؛ اینسیدنتو هشدارش را میگیرد و از آن به بعد را مدیریت میکند.
برای همین بیش از یک کانال وجود دارد. زنجیرهی اسکالیشن میتواند از پیامرسان شروع شود و به پیامک و تماس صوتی برسد؛ مسیرهایی که به اینترنت وابسته نیستند.
بله. حتی برای تیم سهنفره، مشخصبودن اینکه آخر هفته چهکسی جواب میدهد و سابقهی خرابیها کجا نوشته میشود ارزش دارد. پیچیدگی تنظیمات اختیاری است.
سامانه هنوز در حال ساخت است و مدل قیمتگذاری اعلام نشده. اگر علاقهمندید، در لیست انتظار تماس ثبتنام کنید تا وقتی آماده شد با شما حرف بزنیم.
اگر از چیزی که میبینید خوشتان آمده، مشخصاتتان را بگذارید. با شما تماس میگیریم.
در لیست انتظار تماس بمانید