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

Для начала позвольте представиться. Я — @tristan.read, фронтэнд-инженер в группе Monitor::Health GitLab'а. На прошлой неделе мне выпала честь побыть стажером у одного из наших дежурных SRE-инженеров. Целью было ежедневное наблюдение за тем, как дежурный реагирует на инциденты, и получение реального опыта работы. Нам бы хотелось, чтобы наши инженеры лучше понимали потребности пользователей функций Monitor::Health.

Мне предстояло неделю всюду следовать за SRE-инженером. То есть я присутствовал на передаче дежурства, наблюдал за теми же каналами оповещений и реагировал на инциденты, если и когда таковые имели место.

Инциденты

За неделю произошло 2 инцидента.

1. Криптомайнер

В среду на GitLab.com зафиксировали скачок в использовании GitLab Runner'а, вызванный попытками использовать минуты runner'а для майнинга криптовалюты. С инцидентом разобрались с помощью собственного инструмента нейтрализации нарушений, который останавливает задачи runner'а и удаляет связанные с ним проект и аккаунт.

Если бы это событие не заметили, его отловил бы автоматизированный инструмент, но в этом случае SRE-инженер заметил нарушение первым. Была создана задача по инциденту, однако информация по ней закрыта.

2. Деградация производительности приложений Canary и Main

Инцидент спровоцировали замедления и возросшая частота ошибок в canary и main веб-приложениях на Gitlab.com. Было нарушено несколько значений Apdex.

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

Ключевые выводы

Вот несколько моментов, которые я уяснил за неделю дежурства.

1. Оповещения наиболее полезны, когда засекают отклонения от нормы.

Оповещения можно разделить на несколько типов:

• Оповещения, основанные на определенном пороговом значении, типа "произошло 10 5хх ошибок в секунду".
• Оповещения, в которых порог — это процентное значение типа "частота 5хх ошибок на 10% общего объема запросов в заданное время".
• Оповещения, основанные на историческом среднем значении типа "5хх ошибок в 90-й процентили".

Если говорить в общем, то 2-й и 3-й типы полезнее для дежурных SRE, поскольку вскрывают отклонения от нормы в процессе.

2. Многие оповещения так и не эскалируются до инцидентов

SR-инженеры имеют дело с постоянным потоком оповещений, многие из которых на самом деле не критичны.

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

Задача дежурного SRE в том и состоит, чтобы определять, какие оповещения действительно говорят о чем-то серьезном, и надо ли их эскалировать и начинать разбираться. Подозреваю, это вызвано еще и негибкостью оповещений: было бы лучше, если бы ввели несколько уровней или "умные" способы настройки оповещений в соответствии с описанной выше ситуацией.

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

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. На самом деле это уже работает у нас: https://ops.gitlab.net/.

5. Несколько функций, которые следует рассмотреть к добавлению в GitLab

• Многопользовательское редактирование задач, аналогичное Google Docs. Это помогло бы в задачах по инцидентам в ходе события, а также в задачах по разборам. В обоих случаях сразу нескольким участникам может понадобиться добавить что-нибудь в реальном времени.
• Больше вебхуков для задач. Возможность запускать различные шаги рабочего процесса GitLab изнутри поможет снизить зависимость от интеграций Slack. Например, возможность разрешить оповещение в PagerDuty через слэш-команду в задаче GitLab.
  Заключение

SRE-инженерам приходится нелегко с множеством сложностей. Было бы здорово увидеть больше продуктов GitLab в решении этих проблем. Мы уже работаем над некоторыми добавлениями к продукту, которые облегчат упомянутые выше рабочие процессы. Детали доступны в разделе Ops Product Vision.

В 2020 году мы расширяем команду, чтобы собрать все эти замечательные функции. Если интересно, ознакомьтесь, пожалуйста, с вакансиями, и не стесняйтесь связываться с кем-нибудь из нашей команды по любым вопросам.