Как бях стажант SRE инженер за една седмица. Задължение през погледа на софтуерен инженер

SRE инженер - стажант

Като начало нека се представя. аз - @tristan.read, front-end инженер в групата Монитор::Здраве GitLab. Миналата седмица имах привилегията да бъда стажант при един от нашите дежурни SRE инженери. Целта беше ежедневно да се наблюдава как дежурният служител реагира при инциденти и да се натрупа реален работен опит. Бихме искали нашите инженери да разбират по-добре нуждите на потребителите функция Монитор::Здраве.

Трябваше да следвам SRE цяла седмица. Тоест присъствах на предаването на службата, наблюдавах същите сигнални канали и реагирах на инциденти, ако и когато са възникнали.

Инциденти

Имаше 2 инцидента за седмица.

1. Крипто копач

GitLab.com регистрира скок в използването в сряда GitLab Runner'a, причинено от опити за използване на минути на бегач за копаене на криптовалута. Инцидентът беше разрешен с помощта на собствен инструмент за смекчаване, който спира задачите на бегача и изтрива проекта и акаунта, свързани с него.

Ако това събитие не беше забелязано, автоматизиран инструмент щеше да го улови, но в този случай SRE инженерът пръв забеляза нарушението. Създадена е задача за инцидент, но информацията за нея е затворена.

2. Влошаване на производителността на приложенията Canary и Main

Инцидентът беше подхранван от забавяне и увеличен процент грешки в canary и основните уеб приложения на Gitlab.com. Няколко стойности на Apdex бяха нарушени.

Отворена задача по инцидент: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

Основни констатации

Ето няколко неща, които научих през седмицата на дежурство.

1. Сигналите са най-полезни при откриване на отклонения от нормата.

Известията могат да бъдат разделени на няколко вида:

• Сигнали въз основа на определен праг, като например „10 5xx грешки възникнаха в секунда“.
• Сигнали, при които прагът е процентна стойност, като например „процент на грешка 5xx на 10% от общите заявки в даден момент“.
• Сигнали, базирани на историческа средна стойност, като например „5xx грешки в 90-ия процентил“.

Най-общо казано, типове 2 и 3 са по-полезни за SRE на дежурство, тъй като разкриват аномалии в процеса.

2. Много сигнали никога не ескалират до инциденти

Инженерите на SR се справят с постоянен поток от сигнали, много от които не са наистина критични.

Така че защо не ограничите предупрежденията само до наистина важните? С този подход обаче ранните симптоми на това, което ще се превърне в истински проблем, който заплашва големи щети, могат да бъдат пренебрегнати.

Задачата на дежурния SRE е да определи кои сигнали наистина означават нещо сериозно и дали трябва да бъдат ескалирани и да започнат да се сортират. Подозирам, че това се дължи и на негъвкавостта на сигналите: би било по-добре, ако въведат няколко нива или „умни“ начини за персонализиране на сигналите според описаната по-горе ситуация.

Предложение за функция: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. Нашите SRE използват много инструменти

Вътрешни:

• Допълнителен проект на GitLab: Runbooks на живо тук, предаване на смени/седмици, задачи за реакция при инциденти.
• Проблеми с GitLab: Разследването, разборът и поддръжката също се проследяват в проблемите.
• Етикети на GitLab: Задачите за автоматизация се задействат от специфични етикети, които ботовете използват за проследяване на дейността на задачите.

Външен:

• Предупреждения за PagerDuty
• Slack: Това е мястото, където преминава потокът от съобщения PagerDuty/AlertManager. Интегриране с команди за наклонена черта за изпълнение на различни задачи, като затваряне на предупреждение или ескалиране до инцидент.
• Grafana: визуализация на метрики с фокус върху дългосрочните тенденции.
• Kibana: дава визуализация/търсене в журнал, възможност за по-дълбоко копаене в определени събития.
• Zoom: Има постоянна „стая за разбивка“ в Zoom. Това позволява на SRE бързо да обсъжда събития, без да губи ценно време за създаване на стая и свързване на членове.

И много много други.

4. Наблюдението на GitLab.com с GitLab е единствена точка на провал

Ако GitLab.com претърпи голямо прекъсване на услугата, ние не искаме това да повлияе на способността ни да разрешим проблема. Може да бъде спряно чрез стартиране на второ копие на GitLab за управление на GitLab.com. Всъщност това вече работи за нас: https://ops.gitlab.net/.

5. Няколко функции, които да обмислите да добавите към GitLab

• Редактиране на проблеми с много потребители, подобно на Google Документи. Това би помогнало при задачи за инциденти по време на събитието, както и при задачи за разбор. И в двата случая може да се наложи няколко участници да добавят нещо в реално време наведнъж.
• Още уеб кукички за задачи. Възможността да изпълнявате различни стъпки от работния процес на GitLab отвътре ще ви помогне да намалите зависимостта си от интеграции на Slack. Например възможността за активиране на предупреждение в PagerDuty чрез команда с наклонена черта в проблем на GitLab.
  Заключение

SRE инженерите имат трудности с много сложности. Би било чудесно да видим повече продукти на GitLab да се справят с тези проблеми. Вече работим върху някои допълнения към продукта, които ще улеснят работните процеси, споменати по-горе. Частите са налични в Раздел Ops Product Vision.

През 2020 г. разширяваме екипа, за да обединим всички тези страхотни функции. При интерес, моля, разгледайте свободни позиции, и не се колебайте да се свържете с някой от нашия екип с всякакви въпроси.

Източник: www.habr.com