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