Overengineering, который медленно убивает ваш продукт

👉 Второй вебинар серии FinOps 25 июня в 17:00 мск

Overengineering замедляет разработку, тратит ресурсы и подрывает мораль команды в силу увеличения порога входа в продукт.

На вебинаре мы:

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

🔹 поговорим о причинах overengineering – от карго культа до CV driven development.

После просмотра вы получите solid понимание, как не надо делать, и советы, как не усложнять себе жизнь без строгой необходимости.

Занять место в один клик — через бота.

Когда упал Google — упало всё

12 июня Google провёл открытый мастер-класс: «Как одним null положить пол интернета».

Пострадали Gmail, Drive, Meet, Cloud, сторонние клиенты на API. Если вы внезапно не смогли отправить письмо или включить Spotify — знайте, это была null pointer exception где-то в датацентре Google. Да-да.

Что там произошло?

👉 Ещё в конце мая разработчики вкатили новую логику в Service Control — это такой центральный фильтр: проверяет, можно ли юзеру вообще стучаться к API, сколько ему можно, и кто за это заплатит. Все выкатилось нормально, НО!

👉 12 июня в конфиг летит новая «политика доступа» с дырой: в одном из полей — null. И всё. Service Control по всему миру начинает жестко падать при обработке этой политики, и не просто падать, а — в цикле: упал → перезапустился → опять на тот же null → опять упал. Ад на проде.

А теперь самое весёлое.

Service Control — штука глобальная. Квоты и авторизация идут всегда и везде через неё. Поэтому, как только она захлебнулась — всё остальное просто не могло работать.

А дальше по учебнику
• Через 2 минуты подлетела SRE-команда.
• За 10 минут нашли проблему.
• За 25 минут подготовили откат.
• Через 40 минут — пошёл откат по регионам.

Но проблема в том, что Google — не маленький стартап. У них есть такой регион, как us-central1 — и там всё пошло в разнос. Добро пожаловать в Spanner-ад.

Падающий Service Control начал долбиться в Spanner-базу без разбора. Ни тебе экспоненциального backoff, ни jitter, ни grace — просто тупо REST+LOOP. Всё умирало ещё сильнее. Восстановление us-central1 заняло почти три часа.

Самое абсурдное:
🔹 Нет фичефлагов. Да, в 2025 году. У Google.
🔹 Нет банальной проверки на null.
🔹 Нет защиты от лавины рестартов.
🔹 Конфиги распространяются по миру, вообще без sanity-чека.
🔹 Статус-страница легла вместе со всеми. Обновление появилось спустя час. Бинго!

Cloud-инжиниринг — будущее за облаками?

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

👉 Команда Слёрма сейчас работает над созданием курса «Cloud-инженер», и нам важно понять, как адаптировать теоретическое содержание под реальный опыт.

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

Встреча займет полчаса вашего времени, дату и время выберем вместе. Если вы хотите помочь нам создать классный курс, ориентированный на реальное положение вещей, напишите, пожалуйста, Лизе в личку или в комментарии под этим постом 👇

Спасибо!

Тихие алерты

Под одним из постов видел вопрос про тихие алерты — что это такое, зачем нужно и как работает. Давайте разбираться.

Вообще, если говорить в целом, в компаниях, где я работал, всегда старались делить алерты по уровням критичности. Их может быть разное количество, в зависимости от компании — в VK, например, мы выделяем disaster, critical, high и warning.

👉 Disaster alerts — это алерты, которые требуют молниеносной реакции, создания инцидента, подъема вообще всех людей, включая СТО и, соответственно, эскалации по всем уровням и быстрой починки.

👉 Critical alerts — это алерты, которые в целом важные, но не требуют создания инцидента. Возможно, один инженер дежурной команды может ASAP починить этот алерт, починить триггер, чтобы этот алерт больше не возникал.

👉 High alerts — это уже тихие алерты. Они могут быть отработаны на следующий день. Например, что-то сработало (например, места на диске осталось менее 20%), и мы понимаем, что по тренду за ночь оно, скорее всего, не сломается, и можно разобраться с ним утром.

Когда начинается рабочий день, мы приходим, смотрим алерт — почему сработал, как сработал, как сделать так, чтобы он больше никогда не стрелял, —и чиним его.

👉 Warning alert — алерты, которые можно посмотреть все вместе в конце недели и починить. Игнорировать их нельзя, потому что они отлично превращаются в high, critical и даже disaster, но можно отложить их починку на несколько дней.

❗️ Самое важное: тихие алерты, такие как high и warning, не будят дежурных. Это неназойливый канал сообщений, например, рабочий чат, в который приходят сообщения.

Остальные алерты, такие как critical и disaster, — это критичные, назойливые каналы сообщений, например, звонок на телефон, который нельзя пропустить.

Ответ на мини-задачу

Вижу, что многие ответили правильно, и это не может не радовать.

👉 Правильный ответ: 2, автоматический rollback.

Почему:
• Сокращает время восстановления до минут/секунд (ключевая цель MTTR).
• Устраняет зависимость от ручных действий (риск ошибок и задержек).
• Балансирует между реактивностью и стабильностью (в отличие от «шумных» алертов или полного отключения мониторинга).

⭐️ Дополнительные меры для снижения MTTR:
• Использование Canary-развертываний для минимизации риска.
• Настройка SLO/SLA-метрик для триггеров автоматических решений.
• Практика Chaos Engineering для упреждающего тестирования отказоустойчивости.

Overengineering, который медленно убивает ваш продукт: вебинар через 5 минут!

Со спикером Виталием Лихачевым:

🔹 Разберём разные кейсы: от раздутых пайплайнов до излишнего увлечения надежностью
🔹 Поговорим о причинах overengineering – от карго культа до CV driven development.
🔹 Выясним, как неусложнять себе жизнь без строгой необходимости.

Присоединиться к вебинару ➡️ по ссылке

Как DevOps-инженеру сэкономить часы работы и избежать ошибок с помощью AI-инструментов

👉 воркшоп с Виктором Чаплыгиным, Senior Engineer в международном GameDev холдинге.

Казалось бы, при чем тут SRE? А при том, что навыки использования AI для решения технических задач всегда можно адаптировать под себя и использовать в работе. Так что с радостью делюсь с вами — будет интересно.

Что будет на воркшопе:

Теория: кратко о том, как работают LLM в контексте разработки и эксплуатации. Обзор Cursor IDE — AI-интегрированная IDE с поддержкой кода и терминала.

Практика:

🔹 Настройка Cursor IDE — подготовка среды для продуктивной работы с AI;
🔹 Создание и отладка IaC (Kubernetes YAML, Ansible) с помощью AI-ассистентов: выявление и исправление ошибок;
🔹 Генерация понятной и структурированной документации к проектам с помощью AI;
🔹 Разбор реальных кейсов и работа с командной строкой: исправление, пояснение, улучшение команд и манифестов.

А ещё — личный опыт и лучшие практики применения GPT-ассистентов для повседневных DevOps-задач, от написания инфраструктуры до исправления ошибок и генерации документации.

Когда: в субботу, 5 июля

Узнать подробности и занять место на воркшопе — по ссылке.

Дайджест материалов канала

Подумал, что классно будет периодически собирать в одном посте ссылки на самые «мясные материалы канала». Сегодня — подборка за май и июнь.

1️⃣ Как я провалил собеседование

2️⃣ Что такое зомби процессы и чем они опасны?

3️⃣ Как работает fork/exec в Linux?

4️⃣ Как масштабировать сервис под высокой нагрузкой?

5️⃣ Метастабильные сбои в распределённых системах: когда система сама себя ломает

6️⃣ Будни SRE

7️⃣ Какие вопросы задать потенциальному работодателю?

8️⃣ Тихие алерты

Что хотите разобрать дальше?

Когда надёжность становится дорогой ошибкой?

Отпуск закончился, и я возвращаюсь в привычный рабочий ритм 💪🏼

Напоминаю, что в четверг мы встречаемся в 18:00 на канале Вячеслава Федосеева, чтобы разобрать вакансии.

А завтра в 17:00 мск — третий вебинар серии FinOps, на котором я буду спикером.

Что будет на вебинаре:

🪩 разбор кейса: как не допустить избыточной работы SRE;
🪩 как гонка за 100% uptime съедает бюджет;
🪩 почему стремление к 100% аптайму может навредить бизнесу;
🪩 как SRE помогает найти баланс между стабильностью и развитием.

➡️ Занять место и получить ссылку на вебинар — в боте-помощнике.

Когда надежность становится дорогой ошибкой?

👉 Вебинар через 15 минут!

Сегодня встречаюсь с Александром Крыловым, CPO Штурвал, Лаборатория числитель. Будем обсудить, как не допустить избыточной работы SRE, как 100% аптайма вредит бюджету и бизнесу, и как найти баланс между стабильностью и развитием.

Ссылка на трансляцию 👉 VK Видео

Подключайтесь!

#Задача для настоящих SRE!

👉 Контекст
Каждую ночь ровно с 02:00 до 03:00 ваш сервис начинает отвечать на запросы в 3 раза медленнее, хотя нагрузка падает почти до нуля.

👉 Данные
В мониторинге CPU, RAM, диска — аномалий нет. Запросы становятся медленнее только к одной конкретной БД (остальные работают нормально). В это же время увеличивается количество established-подключений к этой БД.

❔Почему сервис тормозит именно ночью, если нагрузка минимальна?

Жду ваши варианты в комментариях.

Наткнулся на одну интересную вакансию.

Она уже не активна, но отлично подходит для разбора и понимания, с чего вообще можно начать путь в SRE.

👉 Может ли SRE быть джуном?
Коротко — да, но с нюансами.

SRE — это не просто админ или девопс, это инженер, который пишет код, автоматизирует и отвечает за надёжность систем. Поэтому джун в SRE чаще всего — это не прям «настоящий» SRE, а первая ступенька на этом пути.

Такие вакансии часто ближе к Junior SysOps/DevOps, просто с наклейкой SRE — и это нормальный вход в профессию.

Что в этой вакансии?
🔸Ночные смены (21:00–09:00, график 2/2)
🔸Мониторинг, инциденты, тикеты
🔸Поддержка серверов, приложений, баз
🔸Взаимодействие с другими инженерами и эскалации

На деле это больше похоже на L1/L2 поддержку — вы первые встречаете проблему, но не обязательно её решаешь. Такой себе «боевой пост».

Что важно понимать:

👉 Это не чистый SRE — вы не будете внедрять SLO/SLI или заниматься хаос-инжинирингом.

👉 Это не про девелопмент — автоматизация может появиться позже, если будете в это вкладываться.

👉 Ночные смены — это тяжело. Не всем подходит, подумайте заранее.
Но если хотите расти в SRE и готовы учиться на проде — такая позиция может стать хорошим стартом.

Что важнее: SLA или SLO?

Если коротко, важнее SLO. А теперь по порядку:

👉 SLA (Service Level Agreement) — это договор, обычно с заказчиком. В нём прописано, что обещаем: доступность, время реакции, компенсации. SLA — это про внешнюю сторону бизнеса.

👉 SLO (Service Level Objective) — это цель, которую вы ставите внутри команды. На основе SLI (метрик) определяем, чего хотим достичь: например, 99.95% аптайма или 200 мс P95 latency.

Ключевой момент: SLO формирует реальные ожидания от системы и даёт основу для инженерных решений. SLA — это бумажка, которая пригодится, если всё пошло не так.

Пример:

Вы держите API с 99.9% SLA — значит, по договору можно лежать ~43 минуты в месяц. Но внутри ставите себе SLO в 99.95% — это уже ~22 минуты. Если начали часто превышать SLO — это сигнал: надо искать причину, рефакторить, усиливать мониторинг.

Если не следить за SLO, можно однажды получить «по SLA вы не тянете, платите неустойку».

Почему SLO и SLA часто путают?

Потому что и там, и там — проценты, uptime, цифры. Но:

🔹SLA — для бизнеса
🔹SLO — для инженеров

Так что если вы SRE или DevOps и вас просят «выполнить SLA», а при этом нет ни одного SLO — это красный флаг. Без SLO не видно, как близко вы к провалу, и заранее никак не подстраховаться.

SLO — основа. SLA — фасад.
Без первого второй быстро треснет. Настоящая работа по надёжности начинается с реалистичных, измеримых SLO, а уже потом — SLA на их основе.

Позже расскажу, как правильно ставить SLO, и какие ошибки делают новички. 🔥, кому актуально!

Как справляться с лавиной алертов

На DevOps Conf'2025 выступал с докладом про это, хочу дать вам краткую выдержку.

⚡️Проблема: тысячи алертов в секунду превращают мониторинг в хаос. Люди начинают их игнорировать, и даже критичные сигналы теряются в шуме.

Alert fatigue — не просто раздражение, а психологическое притупление чувствительности. В медицинской практике зафиксированы случаи, когда из-за перебора сигналов допускались смертельные ошибки.

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

1️⃣ Классификация по приоритету
• Disaster — инцидент, требует мгновенной реакции (чат, звонок)
• Critical — важная, но без паники
• High — важно, но можно отложить до утра
• Warning — не срочно, но требует регулярного разбора

2️⃣ Каналы доставки
• Назойливые сигналы — звонок (через Grafana OnCall)
• Менее критичные — корпоративные чаты
• Отсутствие звонков и эскалации — выгорание

3️⃣ Ответственность
• Алерт без владельца — бесполезен
• Каждый сервис имеет дежурного по расписанию
• Функционал «взять в работу» фиксирует реакцию, все остальные уровни отключаются

Итоги и лайфхаки:
▶️ Алерты — как код: пересматривайте, ревьюьте, удаляйте
▶️ Контекст в уведомлениях: понятный текст и инструкции нужны даже ночью
▶️ Автоматизация: звонки, эскалации, интеграция с CMDB/Jira снижают рутинную нагрузку

А как вы справляетесь с лавиной алертов?

Всех с пятницей!

Объявляю мемную перекличку. Я начну 👇