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

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

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

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

Инциденти

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

1. Криптоминьор

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

Ако това събитие беше останало незабелязано, щеше да бъде засечено от автоматизиран инструмент, но в този случай, 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 Docs. Това би било полезно за задачи, свързани с инциденти по време на събитие, както и за обсъждане на събитията. И в двата случая може да се наложи множество участници да добавят нещо в реално време.
• Повече уеб куки за задачи. Възможността за вътрешно задействане на различни стъпки от работния процес на GitLab ще помогне за намаляване на зависимостта от Slack интеграции. Например, възможността за активиране на известия в PagerDuty чрез команда с наклонена черта в задача на GitLab.
  Заключение

SRE инженерите са изправени пред множество предизвикателства. Би било чудесно да видим повече продукти на GitLab, които решават тези проблеми. Вече работим върху някои допълнения към продукти, които ще опростят гореспоменатите работни процеси. Подробности са налични в Раздел „Визия за продукта на оперативните дейности“.

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

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