مهندس SRE - کارآموز
برای شروع، اجازه دهید خودم را معرفی کنم. من - ، مهندس جلویی در گروه GitLab. هفته گذشته، من این امتیاز را داشتم که با یکی از مهندسان SRE وظیفه خود کارآموز باشم. هدف مشاهده روزانه نحوه واکنش افسر وظیفه به حوادث و کسب تجربه واقعی کار بود. ما می خواهیم مهندسان ما نیازهای کاربران را بهتر درک کنند مانیتور::سلامتی.
من مجبور شدم یک هفته SRE را دنبال کنم. یعنی من در زمان انتقال وظیفه حضور داشتم، همان کانال های هشدار را رصد می کردم و در صورت وقوع و زمانی به حوادث پاسخ می دادم.
حوادث
در یک هفته 2 حادثه رخ داد.
1. کریپتومینر
GitLab.com جهشی در استفاده در روز چهارشنبه ثبت کرد a، ناشی از تلاش برای استفاده از دقیقه های دونده برای استخراج ارزهای دیجیتال. این حادثه با استفاده از یک ابزار کاهش سفارشی که وظایف دونده را متوقف می کند و پروژه و حساب مرتبط با آن را حذف می کند مرتب شد.
اگر این رویداد مورد توجه قرار نمی گرفت، یک ابزار خودکار آن را می گرفت، اما در این مورد، مهندس SRE ابتدا متوجه تخلف شد. یک کار حادثه ایجاد شد، اما اطلاعات مربوط به آن بسته است.
2. کاهش عملکرد برنامه های کاربردی قناری و اصلی
این حادثه به دلیل کاهش سرعت و افزایش نرخ خطا در برنامه های کاربردی وب اصلی و قناری در Gitlab.com ایجاد شد. چندین مقدار Apdex نقض شد.
باز کردن کار بر حسب حادثه:
یافته های کلیدی
چند نکته ای که در هفته وظیفه یاد گرفتم در اینجا آمده است.
1. هشدارها هنگام تشخیص انحراف از هنجار بسیار مفید هستند.
اعلان ها را می توان به چند نوع تقسیم کرد:
- هشدارهایی بر اساس یک آستانه خاص، مانند "10 خطای 5xx در هر ثانیه رخ داده است."
- هشدارهایی که در آن آستانه یک مقدار درصد است مانند "نرخ خطا 5xx به ازای هر 10٪ از کل درخواست ها در یک زمان معین".
- هشدارهای مبتنی بر میانگین تاریخی مانند "5xx خطا در صدک 90".
به طور کلی، انواع 2 و 3 برای SRE های در حال کار مفیدتر هستند، زیرا آنها ناهنجاری ها را در فرآیند آشکار می کنند.
2. بسیاری از هشدارها هرگز به حوادث تبدیل نمی شوند
مهندسان SR با یک جریان ثابت از هشدارها سروکار دارند که بسیاری از آنها واقعاً حیاتی نیستند.
پس چرا هشدارها را فقط به موارد بسیار مهم محدود نکنید؟ با این حال، با این رویکرد، علائم اولیه از آنچه که گلوله برفی را به یک مشکل واقعی تبدیل می‌کند که آسیب بزرگی را تهدید می‌کند، ممکن است نادیده گرفته شود.
وظیفه SRE در حال انجام این است که تعیین کند کدام هشدارها واقعاً معنای جدی دارند و آیا باید تشدید شوند و شروع به مرتب سازی کنند. من گمان می کنم که این نیز به دلیل انعطاف ناپذیری هشدارها باشد: بهتر است آنها چندین سطح یا روش های "هوشمند" را برای سفارشی کردن هشدارها مطابق با وضعیت توصیف شده در بالا معرفی کنند.
پیشنهاد ویژگی:
3. SRE های ما از ابزارهای زیادی استفاده می کنند
درونی؛ داخلی:
- پروژه زیرساخت GitLab: ران بوک ها در اینجا زندگی می کنند، تحویل شیفت/هفته، وظایف واکنش به حادثه.
- مسائل GitLab: بررسی، بررسی، و نگهداری نیز در مسائل پیگیری می شود.
- برچسب‌های GitLab: وظایف اتوماسیون توسط برچسب‌های خاصی فعال می‌شوند که ربات‌ها از آنها برای ردیابی فعالیت کار استفاده می‌کنند.
خارجی:
- هشدارهای PagerDuty
- Slack: اینجا جایی است که جریان پیام PagerDuty/AlertManager می رود. ادغام با دستورات اسلش برای انجام انواع وظایف، مانند بستن هشدار یا تشدید به یک حادثه.
- گرافانا: تجسم معیارها با تمرکز بر روندهای بلند مدت.
- Kibana: جستجوی تجسم/log، توانایی کاوش عمیق تر در رویدادهای خاص را می دهد.
- زوم: یک "اتاق برک آوت" دائمی در زوم وجود دارد. این به SRE ها اجازه می دهد تا بدون اتلاف وقت گرانبها برای ایجاد اتاق و پیوند اعضا، به سرعت درباره رویدادها بحث کنند.
و بسیاری بسیار دیگر.
4. نظارت بر GitLab.com با GitLab یک نقطه شکست است
اگر GitLab.com با یک قطع سرویس بزرگ مواجه شد، نمی‌خواهیم این مشکل بر توانایی ما برای حل مشکل تأثیر بگذارد. با اجرای نمونه دوم GitLab برای مدیریت GitLab.com می توان آن را متوقف کرد. در واقع، این قبلاً برای ما کار می کند: .
5. چند ویژگی که باید به GitLab اضافه کنید
- ، مشابه Google Docs. این به وظایف حادثه در طول رویداد و همچنین در انجام وظایف گزارش کمک می کند. در هر دو مورد، چندین شرکت کننده ممکن است نیاز داشته باشند چیزی را در زمان واقعی اضافه کنند.
- وب هوک های بیشتر برای وظایف. توانایی اجرای مراحل مختلف گردش کار GitLab از درون به کاهش وابستگی شما به ادغام های Slack کمک می کند. به عنوان مثال، امکان فعال کردن هشدار در PagerDuty از طریق دستور اسلش در یک مشکل GitLab.
نتیجه
مهندسان SRE با پیچیدگی‌های بسیار مشکل دارند. بسیار خوب است که محصولات GitLab بیشتری به این مشکلات رسیدگی کنند. ما در حال حاضر در حال کار بر روی برخی از موارد اضافه شده به محصول هستیم که گردش کار ذکر شده در بالا را آسان تر می کند. قطعات موجود در .
در سال 2020، ما در حال گسترش تیم هستیم تا همه این ویژگی های عالی را گرد هم بیاوریم. اگر علاقه مند هستید، لطفا بررسی کنید و در صورت هرگونه سوال با فردی از تیم ما تماس بگیرید.
منبع: www.habr.com