Для начала позвольте представиться. Я — @tristan.read, фронтэнд-инженер в группе Monitor::Health GitLab'а. На прошлой неделе мне выпала честь побыть стажером у одного из наших дежурных SRE-инженеров. Целью было ежедневное наблюдение за тем, как дежурный реагирует на инциденты, и получение реального опыта работы. Нам бы хотелось, чтобы наши инженеры лучше понимали потребности пользователей функций Monitor::Health. Мне предстояло неделю всюду следовать за SRE-инженером. То есть я присутствовал на передаче дежурства, наблюдал за теми же каналами оповещений и реагировал на инциденты, если и когда таковые имели место. За неделю произошло 2 инцидента. В среду на GitLab.com зафиксировали скачок в использовании GitLab Runner'а, вызванный попытками использовать минуты runner'а для майнинга криптовалюты. С инцидентом разобрались с помощью собственного инструмента нейтрализации нарушений, который останавливает задачи runner'а и удаляет связанные с ним проект и аккаунт.  Если бы это событие не заметили, его отловил бы автоматизированный инструмент, но в этом случае SRE-инженер заметил нарушение первым. Была создана задача по инциденту, однако информация по ней закрыта. Инцидент спровоцировали замедления и возросшая частота ошибок в canary и main веб-приложениях на Gitlab.com. Было нарушено несколько значений Apdex. Открытая задача по инциденту: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442 Вот несколько моментов, которые я уяснил за неделю дежурства. Оповещения можно разделить на несколько типов: Если говорить в общем, то 2-й и 3-й типы полезнее для дежурных SRE, поскольку вскрывают отклонения от нормы в процессе. SR-инженеры имеют дело с постоянным потоком оповещений, многие из которых на самом деле не критичны. Так почему бы не ограничить оповещения только действительно важными? С таким подходом, однако, можно не распознать ранние симптомы того, что вырастет, как снежный ком, в реальную проблему, грозящую крупным ущербом. Задача дежурного SRE в том и состоит, чтобы определять, какие оповещения действительно говорят о чем-то серьезном, и надо ли их эскалировать и начинать разбираться. Подозреваю, это вызвано еще и негибкостью оповещений: было бы лучше, если бы ввели несколько уровней или "умные" способы настройки оповещений в соответствии с описанной выше ситуацией. Предложение по функции: https://gitlab.com/gitlab-org/gitlab/issues/42633 Внутренние: Внешние: И многое, многое другое. Если на GitLab.com произойдет крупный отказ сервисов, нам бы не хотелось, чтобы это повлияло на нашу способность разрешить проблему. Ее можно купировать, запустив второй инстанс GitLab для упарвления GitLab.com. На самом деле это уже работает у нас: https://ops.gitlab.net/. SRE-инженерам приходится нелегко с множеством сложностей. Было бы здорово увидеть больше продуктов GitLab в решении этих проблем. Мы уже работаем над некоторыми добавлениями к продукту, которые облегчат упомянутые выше рабочие процессы. Детали доступны в разделе Ops Product Vision. В 2020 году мы расширяем команду, чтобы собрать все эти замечательные функции. Если интересно, ознакомьтесь, пожалуйста, с вакансиями, и не стесняйтесь связываться с кем-нибудь из нашей команды по любым вопросам.