SRE-инженер – стажант
За да започна, позволете да се представя. Аз съм , фронтенд инженер в групата на GitLab. Миналата седмица имах честта да бъда стажант на един от нашите дежурни SRE-инженери. Целта беше ежедневно наблюдение на реакцията на дежурния при инциденти и получаване на реален опит в работата. Бихме искали нашите инженери да разбират по-добре нуждите на потребителите Monitor::Health.
През седмицата трябваше да следя SRE-инженера навсякъде. Тоест присъствах на предаване на дежурство, наблюдавах същите канали за уведомяване и реагирах на инциденти, когато и ако се случват.
Инциденти
През седмицата се случиха 2 инцидента.
1. Криптомайнер
В сряда на GitLab.com беше регистриран скок в използването на ‘а, предизвикан от опити за използване на минутите на runner’а за копаене на криптовалута. С инцидента се справихме с помощта на нашия инструмент за неутрализиране на нарушения, който спира заданията на runner’а и премахва свързаните с него проект и акаунт.
Ако това събитие не беше забелязано, автоматизиран инструмент щеше да го улови, но в този случай SRE-инженерът забеляза нарушението първи. Беше създадена задача за инцидента, но информацията по нея е конфиденциална.
2. Деградация на производителността на приложенията Canary и Main
Инцидентът беше предизвикан от забавяния и увеличена честота на грешки в canary и main уеб приложенията на GitLab.com. Няколко стойности на Apdex бяха нарушени.
Отворена задача по инцидента:
Ключови изводи
Ето няколко момента, които осъзнах през седмицата на дежурство.
1. Уведомленията са най-полезни, когато улавят отклонения от нормата.
Уведомленията могат да се разделят на няколко типа:
- Уведомления, основани на определен праг, например „назад 10 5хх грешки в секунда“.
- Уведомления, при които прагът е процентно значение, например „честота на 5хх грешки на 10% от общия обем заявки в даден период“.
- Уведомления, основани на историческа средна стойност, например „5хх грешки в 90-ия процентил“.
Говорейки общо, 2-ят и 3-ят тип са по-полезни за дежурните SRE, тъй като разкриват отклонения от нормата в процеса.
2. Много уведомления не ескалират до инциденти
SRE-инженерите се справят с постоянен поток от уведомления, много от които всъщност не са критични.
Защо да не ограничим известията само до наистина важните? С такъв подход обаче може да не разпознаем ранните симптоми, които ще се развият в реален проблем, заплашващ с големи щети.
Задачата на дежурния SRE е да определи кои известия наистина сигнализират за нещо сериозно и дали трябва да се ескалират и да се започне разследване. Подозрявам, че това е причинено и от нееластичността на известията: би било по-добре, ако се въведат няколко нива или 'умни' начини за конфигуриране на известията според описаната по-горе ситуация.
Предложение за функция:
3. Нашите дежурни SRE използват много инструменти
Вътрешни:
- GitLab infra project: тук живеят Runbook-ите, предаване на дежурството за смяна/седмица, задачи за отговор на инциденти.
- GitLab issues: разследвания, анализи и поддръжка също се проследяват в задачите.
- GitLab labels: задачите за автоматизация се стартират по определени етикети, след които ботът проследява активността на задачите.
Външни:
- PagerDuty: известия
- Slack: тук се насочва потокът от съобщения от PagerDuty/AlertManager. Интеграция със слеш-командите за изпълнение на разнообразни задачи, като например: затваряне на известие или ескалиране до инцидент.
- Grafana: визуализация на метрики с фокус върху дългосрочните тенденции.
- Kibana: осигурява визуализация/търсене в дневниците, възможност за задълбочаване в определени събития.
- Zoom: има постоянна 'стая за обсъждане' в Zoom. Това позволява на SRE инженерите бързо да обсъждат събития, без да губят ценно време за създаване на стая и линкове за участниците.
И още много, много други.
4. Наблюдение на GitLab.com чрез GitLab — това е единична точка на отказ
Ако на GitLab.com възникне голям отказ на услугите, не бихме искали това да повлияе на нашата способност да разрешим проблема. Може да бъде локализиран, стартирайки втори инстанс на GitLab за управление на GitLab.com. Всъщност, това вече работи за нас: .
5. Няколко функции, които следва да се разгледат за добавяне в GitLab
- подобно на Google Docs. Това би помогнало при справяне с инциденти по време на събития и при анализа. В двата случая няколко участници биха могли незабавно да добавят нещо в реално време.
- Повече уебхуков за задачи. Възможността да стартирате различни стъпки на работния процес на GitLab отвътре ще помогне за намаляване на зависимостта от интеграции със Slack. Например, опцията да разрешите уведомяването в PagerDuty чрез слеш команда в задачата на GitLab.
Заключение
СRE инженерите имат много предизвикателства. Беше чудесно да видим повече продукти на GitLab в решаването на тези проблеми. Вече работим върху някои добавки към продукта, които ще улеснят споменатите по-горе работни процеси. Подробности можете да намерите в .
През 2020 г. разширяваме екипа, за да съберем всички тези страхотни функции. Ако ви интересува, моля, запознайте се с , и не се колебайте да се свържете с някой от нашия екип за въпроси.
Източник: habr.com
