PagerDuty یا چرا بخش عملیات نمی تواند در شب بخوابد

هرچه سیستم پیچیده تر باشد، بیشتر با انواع هشدارها مواجه می شود. و نیاز به واکنش به همین هشدارها، تجمیع و تجسم آنها وجود دارد. فکر می کنم این وضعیتی است که برای خیلی ها تا حد عصبی آشناست.

راه حلی که مورد بحث قرار خواهد گرفت غیرمنتظره ترین راه حلی نیست، اما جستجو مقاله کاملی را در مورد این موضوع باز نمی گرداند.

بنابراین، تصمیم گرفتم تجربه FunCorp را به اشتراک بگذارم و در مورد چگونگی ساختار فرآیند وظیفه، چه کسی تماس می گیرد، چرا و چگونه می توانید به همه آن نگاه کنید صحبت کنم.

PagerDuty چیست؟

بنابراین، برای حل همه این مشکلات، ما شروع به جستجوی یک ابزار مناسب کردیم. پس از کمی جستجو، PagerDuty را انتخاب کردیم. به نظر ما PD یک راه حل نسبتا کامل و مختصر با تعداد زیادی ادغام و تنظیمات است. او چگونه است؟

به طور خلاصه، PagerDuty یک پلت فرم پردازش حادثه است که می تواند حوادث دریافتی را از طریق ادغام های مختلف پردازش کند، دستورات وظیفه را تنظیم کند و سپس بسته به سطح حادثه (در سطح بالا - تماس، در سطح پایین -) به مهندس در حال انجام وظیفه هشدار دهد. یک فشار از برنامه / پیامک).

افسر وظیفه کیست؟

این احتمالاً اولین جایی است که شروع به تنظیم PD می کند.

در FunCorp، مانند سایر شرکت ها، موقعیت افتخاری افسر وظیفه وجود دارد. روزی یک بار از مهندس به مهندس دیگر منتقل می شود. یک خط به اصطلاح اول و دوم پاسخ به یک هشدار از طرف PagerDuty وجود دارد. فرض کنید یک هشدار با اولویت بالا می رسد و اگر 10 دقیقه پس از تماس با افسر وظیفه از خط اول هیچ واکنشی به آن نشان داده نمی شود (یعنی به وضعیت تایید یا حل و فصل منتقل نمی شود)، تماس به شماره دوم می رود. مهندس وظیفه این در خود PagerDuty از طریق Escalation Policies پیکربندی شده است.

اگر افسر وظیفه دوم پاسخ ندهد، اعلان به آن باز می گردد اصلی به افسر وظیفه

بنابراین، هر هشدار با اولویت بالا نمی تواند پردازش نشده باقی بماند. 

حال بیایید ببینیم که حوادث از کجا می توانند منشأ بگیرند.

از چه ادغام هایی استفاده می کنیم؟

PD بسیاری از حوادث مختلف را از خدمات مختلف دریافت می کند. ما در حال حاضر حدود 25 سرویس از این دست داریم و برای پردازش آنها از برخی ادغام های آماده استفاده می کنیم.

• تیتان فرزند پاپتوس

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

• پست الکترونیک (ایمیل)

اینجا هم فکر می کنم همه چیز از عنوان مشخص است. این ادغام برای ارسال اعلان ها از برخی اسکریپت های اجرا شده توسط cron استفاده می شود. PD آدرس خاصی را به شما می دهد که به آن نامه می فرستید. هنگام ایجاد یک سرویس با چنین ادغامی، می توانید اولویت ها را تعیین کنید، به ترتیبی که حوادث دریافتی پردازش می شوند، دقیقاً چگونه یک هشدار ایجاد کنید (برای هر نامه دریافتی، برای نامه دریافتی + یک قانون خاص و غیره).

• شل

به نظر من یک ادغام بسیار جالب است. مواقعی وجود دارد که اتفاقی می افتد اما تحت پوشش حوادث نیست. بنابراین، ما یکپارچه سازی را از Slack برای ایجاد یک حادثه اضافه کردیم. یعنی می توانید برای Slack شرکتی بنویسید /callofduty همه چیز کند است و به زودی خراب می شود و PD آن را پردازش کرده و حادثه را برای مهندس وظیفه ارسال می کند.

ما انجام می دهیم:

می بینیم:

• API

ادغام HTTP در واقع، هیچ چیز جالبی در اینجا وجود ندارد، فقط یک درخواست POST با یک بدنه در فرمت JSON. به عنوان مثال، یک چیز جالب: ما از آن برای نظارت خارجی استفاده می کنیم https://www.statuscake.com/. این سرویس دسترسی به سایت های ما را از نقاط مختلف جهان بررسی می کند. در صورتی که یک کد پاسخ غیرقابل قبول دریافت کنیم (مثلاً 502)، یک حادثه ایجاد می شود و سپس همه چیز از زنجیره ای که در بالا توضیح داده شد پیروی می کند. StatusCake خود توانایی نظارت بر URLهای داخلی، گواهینامه SSL یا انقضای دامنه را دارد.

• LibreNMS

این یکی دیگر از سیستم های نظارتی است که می توانید اطلاعات بیشتری در مورد آن در وب سایت آنها بخوانید https://www.librenms.org/. با کمک آن، رابط های شبکه و iDRAC را از سرورها نظارت می کنیم.

همچنین ادغام هایی مانند Datadog، CloudWatch وجود داشت. شما می توانید بیشتر در مورد آنچه برای آنها اتفاق افتاده است ببینید اینجا.

تجسم

سیستم اصلی گزارش دهی حادثه Slack است. تمام اتفاقاتی که به PD می آیند در یک چت ویژه نوشته می شوند و در صورت تغییر وضعیت آنها در چت نیز نمایش داده می شود.

هنگامی که فرصت نمایش داده های مفید بر روی صفحه نمایش مانیتورهای آویزان از سقف فراهم شد، ناگهان متوجه شدیم که ما (در بخش devops) چیزی برای نمایش روی آنها نداریم. یک Grafana فوق‌العاده وجود دارد، اما همه چیز را پوشش نمی‌دهد و کارکنان به هشدارها واکنش نشان می‌دهند، نه نمودارها.

پس از یک جستجوی کامل اما ناموفق در GitHub برای یک "تخته" مختصر و آموزنده برای PD، تصمیم گرفتیم خودمان را بنویسیم - فقط با آنچه نیاز داشتیم. اگرچه در ابتدا ایده ای برای نمایش رابط PD وجود داشت، اما حتی ناخوشایندتر به نظر می رسید.

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

صفحه نمایش حوادث باز فعلی، نام مهندس فعلی در حال انجام وظیفه را از برنامه انتخاب شده و زمان بدون حادثه با اولویت بالا نمایش می دهد (پانل دارای حادثه با اولویت بالا با رنگ قرمز برجسته می شود).

منابع این پیاده سازی را اینجا ببینید.

در نتیجه، ما یک داشبورد مناسب برای مشاهده تمام حوادث خود دریافت کردیم. خوشحال می شوم اگر برای برخی از شما تجربه ما مفید باشد.

منبع: www.habr.com