مهندس SRE - کارآموز
اول، اجازه دهید خودم را معرفی کنم. من ... هستم. ، مهندس رابط کاربری در گروه GitLab. هفته گذشته، افتخار کارآموزی نزد یکی از مهندسان SRE حاضر در محل را داشتم. هدف این بود که مشاهده کنم مهندس حاضر در محل چگونه روزانه به حوادث پاسخ میدهد و تجربه دنیای واقعی کسب کنم. ما دوست داریم مهندسان ما نیازهای کاربران را بهتر درک کنند. مانیتور::سلامت.
من وظیفه داشتم به مدت یک هفته مهندس SRE را زیر نظر داشته باشم. این به آن معنا بود که در زمان تحویل حضور داشتم، همان کانالهای هشدار را رصد میکردم و در صورت وقوع حوادث، به آنها پاسخ میدادم.
حوادث
در عرض یک هفته ۲ حادثه رخ داد.
۱. کریپتوماینر
GitLab.com روز چهارشنبه شاهد افزایش ناگهانی استفاده بود. یک نقض امنیتی ناشی از تلاش برای استفاده از دقایق اجرای برنامه برای استخراج ارز دیجیتال گزارش شد. این حادثه با استفاده از ابزار کاهش خطرات خودمان که وظایف اجرای برنامه را خاتمه میدهد و پروژه و حساب مرتبط را حذف میکند، برطرف شد.
اگر این رویداد مورد توجه قرار نمیگرفت، توسط یک ابزار خودکار شناسایی میشد، اما در این مورد، مهندس SRE ابتدا متوجه تخلف شد. وظیفهای برای این حادثه ایجاد شد، اما اطلاعات مربوط به آن مهر و موم شد.
۲. افت عملکرد برنامههای Canary و Main
این حادثه به دلیل کاهش سرعت و افزایش نرخ خطا در برنامههای وب canary و main در Gitlab.com رخ داد. چندین مقدار Apdex نقض شدند.
وظیفه باز برای این حادثه:
یافته های کلیدی
در اینجا چند نکتهای که در طول هفتهی کاریام یاد گرفتم را مینویسم.
۱. هشدارها زمانی بیشترین فایده را دارند که انحراف از هنجار را تشخیص دهند.
اعلانها را میتوان به چند نوع تقسیم کرد:
- هشدارها بر اساس یک آستانه خاص، مانند "۱۰ خطای ۵xx در هر ثانیه رخ داده است."
- هشدارهایی که آستانه آنها یک مقدار درصدی است، مانند «میزان خطاهای 5xx به ازای 10٪ از کل حجم درخواست در یک زمان معین».
- هشدارها بر اساس میانگین تاریخی مانند «خطاهای 5xx در صدک 90».
به طور کلی، انواع ۲ و ۳ برای SRE های در حال آماده باش مفیدتر هستند زیرا انحراف از حالت عادی را در این فرآیند آشکار میکنند.
۲. بسیاری از هشدارها هرگز به حادثه تبدیل نمیشوند
مهندسان SR با جریان مداومی از هشدارها سروکار دارند که بسیاری از آنها در واقع حیاتی نیستند.
پس چرا هشدارها را فقط به مواردی که واقعاً مهم هستند محدود نکنیم؟ با این حال، این رویکرد میتواند علائم هشدار اولیه را که میتوانند به یک مشکل واقعی تبدیل شوند و خسارات عمدهای را تهدید کنند، از دست بدهد.
وظیفه SRE در حال انجام وظیفه این است که مشخص کند کدام هشدارها واقعاً جدی هستند و آیا نیاز به بررسی و رسیدگی دارند یا خیر. من گمان میکنم این موضوع به دلیل سختگیری در نحوه هشداردهی نیز هست: بهتر است سطوح چندگانه یا روشهای «هوشمندانهای» برای پیکربندی هشدارها مطابق با موقعیتی که در بالا توضیح داده شد، معرفی شود.
پیشنهاد ویژگی:
۳. کارشناسان پشتیبانی تلفنی ما از ابزارهای زیادی استفاده میکنند
داخلی:
- پروژه GitLab infra: محل ثبت سوابق کاری، تحویل شیفت/وظایف هفتگی و وظایف پاسخ به حوادث.
- مشکلات GitLab: تحقیقات، بررسیها و نگهداری نیز در وظایف پیگیری میشوند.
- برچسبهای GitLab: وظایف اتوماسیون توسط برچسبهای خاصی فعال میشوند که رباتها از آنها برای ردیابی فعالیت وظایف استفاده میکنند.
خارجی:
- پیجر دیوتی: هشدارها
- Slack: اینجاست که پیامهای PagerDuty/AlertManager ارسال میشوند. ادغام با دستورات اسلش امکان انجام وظایف مختلفی مانند رد کردن یک هشدار یا تبدیل آن به یک حادثه را فراهم میکند.
- گرافانا: مصورسازی معیارها با تمرکز بر روندهای بلندمدت.
- کیبانا: امکان تجسم/جستجوی لاگ و امکان بررسی عمیقتر رویدادهای خاص را فراهم میکند.
- زوم: زوم یک «اتاق گفتگوی آزاد» دائمی دارد. این به مهندسان SRE اجازه میدهد تا بدون اتلاف وقت گرانبها برای ایجاد یک اتاق و به اشتراک گذاشتن لینک با شرکتکنندگان، به سرعت در مورد رویدادها بحث کنند.
و خیلی خیلی بیشتر.
۴. نظارت بر GitLab.com با GitLab یک نقطه شکست واحد است
اگر GitLab.com دچار قطعی عمده سرویس شود، ما نمیخواهیم که این قطعی بر توانایی ما در حل مشکل تأثیر بگذارد. این مشکل را میتوان با راهاندازی یک نمونه دوم GitLab برای مدیریت GitLab.com کاهش داد. در واقع، این روش همین الان هم برای ما جواب میدهد: .
۵. چند ویژگی که باید به GitLab اضافه کنید
- مشابه Google Docs. این قابلیت برای وظایف مبتنی بر حادثه در طول یک رویداد و همچنین برای جلسات توجیهی مفید خواهد بود. در هر دو مورد، ممکن است چندین شرکتکننده نیاز به اضافه کردن چیزی در لحظه داشته باشند.
- وبهوکهای بیشتر برای وظایف. امکان فعالسازی مراحل مختلف گردش کار GitLab به صورت داخلی، به کاهش وابستگی به ادغامهای Slack کمک خواهد کرد. به عنوان مثال، امکان فعالسازی اعلانها در PagerDuty از طریق یک دستور اسلش در یک وظیفه GitLab.
نتیجه
مهندسان SRE با چالشهای زیادی روبرو هستند. دیدن محصولات بیشتر GitLab که به این مشکلات میپردازند، بسیار عالی خواهد بود. ما در حال حاضر روی برخی از محصولات اضافی کار میکنیم که گردشهای کاری ذکر شده در بالا را سادهتر میکند. جزئیات در ... موجود است. .
در سال ۲۰۲۰، ما تیم خود را گسترش میدهیم تا همه این ویژگیهای عالی را گرد هم آوریم. اگر علاقهمند هستید، لطفاً بررسی کنید و در صورت داشتن هرگونه سوال با هر یک از اعضای تیم ما تماس بگیرید.
منبع: www.habr.com
