Разработчик в команду алертинга

Алертинг — сервис, рассчитывающий пользовательские PromQL-подобные выражения (алерты) поверх метрик и нотифицирующий пользователей через различные средства уведомлений. Алертинг входит в состав платформы Observability Яндекса, которая позволяет легко и быстро получить однозначный ответ о состоянии систем в любой момент времени. Практически все команды Яндекса пользуются возможностями платформы для мониторинга состояния своих сервисов — как внешних, так и внутренних. Кроме этого, сервис доступен пользователям Yandex Cloud.

Алертинг в числах:

• 16М алертов, рассчитываемых каждую минуту
• 2М+ RPS на чтение временных рядов и обслуживание пользовательских запросов
• 258 серверов
• 4К CPU
• 17TB RAM

Вызовы, которые перед нами стоят:

• Упрощение для пользователя заведения типовых алертов. Не каждый может с первого раза написать алерт, например на падение трафика, при этом чтобы он не флапал. Ещё сложнее писать алерты на отклонение, тренды и т. д.
• Рекомендательная система алертов и, как следствие, снижение количества инцидентов у пользователей. При использовании библиотеки или менедж-сервисов пользователи часто не задумываются, как правильно их мониторить и что предпринимать. А если за чем-то не следить, то оно рано или поздно сломается и уронит пользователю прод.
• Обеспечение масштабирования системы. Ежегодный рост составляет свыше 50%, поэтому решения, принятые ранее, могут переставать работать. К примеру, перед нами стоят такие задачи: как балансировать выполнения алертов по кластеру, что делать, если пользовательский проект перестал помещаться в один хост.
• Обеспечение отказоустойчивости системы. Если не работает алертинг, наши пользователи не знают о состоянии своего продакшна. Если пользователь не знает о проблемах в его системе, это может привести к крупным инцидентам, а также к финансовым и репутационным потерям. Нам предстоит решить, как при отказе 1/3 кластера, продолжить считать алерты, не создав DDOS на лежащие ниже системы.

Автоматическое партиционирование выполнения алертов и балансировка по кластеру
От года к году нагрузка растёт более чем на 50%, технические решения, принятые ранее, перестают работать. Например, случайное размазывание алертов по кластеру для ровной утилизации на большом объёме алертов начинает плохо работать, так как не все алерты одинаковые. Алерт-убийца может положить весь кластер, невозможно эффективно реализовать кеширование. Вам предстоит решить, как наиболее эффективно партиционировать выполнение алертов и размазать их по кластеру для утилизации.

Проработка технических и продуктовых решений для пользовательских сценариев
Наши пользователи — это такие же разработчики, как и мы сами. Проблемы, с которыми сталкиваются пользователи, актуальны и для нас. Поэтому разработчики всегда принимают участие в обсуждении и проработке не только технических решений, но и продуктовых. Например: как должны выглядеть SLO-алерты, как сделать так, чтобы пользователю было понятно, что такое good events и bad events, и как в этой парадигме создать SLO-алерт на тайминги.

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

Реализация отказоустойчивости алертинга
Если не работает алертинг, пользователи остаются без приборов по своему продакшну и могут пропустить проблему, которая приведёт к серьёзному инциденту. Поэтому необходимо, чтобы алерт успевал просчитывать все алерты и был отказоустойчив. Вам предстоит реализовать hot-standby-режим работы в балансировщике, при этом так, чтобы во время отказа стойки или модуля в дата-центре мы не потеряли обе реплики. Помимо этого, нужна изоляция проектов друг от друга, чтобы проблемы одного проекта не влияли на другие проекты.

• Умеете писать и понимаете многопоточный код: весь алертинг работает асинхронно с использованием акторной модели
• Понимаете ключевые аспекты построения отказоустойчивых распределённых систем