DevOps не горит

Коллеги, всем привет! =)

Открываю рубрику «Мама, твой сын вайб-кодер!» =)
У меня давно в голове крутилась идея сделать некоторого агента мониторинга, который бы периодически проверял «соседей» и сам им говорил, что с ним все ок
У вас может возникнуть резонный вопрос: а зачем все это?
Отвечая словами поэта - «Все переплетено»
Инфраструктурные домены, про которые я много раз рассказывал в своих докладах, ооочень сильно связаны друг с другом, и нам важно знать, что у соседей все хорошо =)
Причем важно знать это в обе стороны
Из этой проблемы/идеи и появился «Привет, сосед!» =)
«Привет, сосед!», или hello-neighbor, решает достаточно простую задачу — следит за тем, что с соседними инфраструктурными доменами все в порядке
Вы можете задать вопрос: у нас же есть blackbox-exporter, настрой его и не парься
И в некотором роде вы будете правы =)
Blackbox-exporter прекрасно отвечает на вопрос: «Могу ли Я достучаться до X?»
Но мне хотелось отвечать еще на один вопрос: «А может ли X достучаться до МЕНЯ?»
Потому что связность не всегда симметрична
Мы можем прекрасно ходить в соседний инфраструктурный домен, а он к нам — уже нет Где-нибудь поменяли ACL, настройки огнестенки, маршрутизацию — иии привет =)
Отсюда и появилась идея сделать проверку именно между соседями
Каждый hello-neighbor одновременно клиент и сервер: сам ходит к соседям и запоминает тех, кто приходит к нему
Причем для входящих соседей работает автоматическое обнаружение — достаточно, чтобы сосед хотя бы один раз пришел к нам, после чего мы его запомним и начнем следить, не пропал ли он
Получается примерно так:
domain-A → domain-B — работает
domain-B → domain-A — НЕ работает
И мы об этом узнаем =)
Ручная конфигурация тоже никуда не делась. Список соседей можно заполнить в любимом нами YAML-формате и раскатить при помощи GitOps хоть вообще на все инфраструктурные домены =)
На выходе получаем метрики в формате Prometheus и готовые алерты на всякие неприятные ситуации:
- сосед перестал ходить к нам;
- мы перестали ходить к соседу;
- связь стала асимметричной;
- изменился сетевой маршрут.
Ну и дополнительная КИЛЛЕР-ФИЧА — ICMP-диагностика =)
Кроме HTTP-проверок можно отдельно смотреть RTT, потерю пакетов и количество хопов до соседа
Причем HTTP и ICMP специально живут отдельно
ICMP может быть запрещен совершенно легально, поэтому его проблемы никак не делают соседа «мертвым»
А вот изменение количества хопов уже интереснее
Если вчера до соседа было 5 хопов, сегодня стало 9, а latency внезапно выросла — кажется, у нас появилась зацепка, куда смотреть =)
Можно включить и полноценный traceroute, чтобы посмотреть, как именно изменился путь.
Репозиторий доступен по ссылке

Enjoy =)

PS1 — пойду, что ли, разверну его где-нибудь =)
PS2 — с пожеланиями/предложениями приходите в репозиторий или приносите свой PR =)

Коллеги, всем привет! =)

Сегодня продолжаем записывать наш DevOops Podcast, внезапно! =)
В этот раз гостем будет Григорий Кошелев, который в прошлом году на DevOops рассказывал про Observability распределенных систем.
Иии тема мне особенно близка =)
Я тоже рассказывал про Observability распределенных систем, правда со своей стороны, своим опытом и своими граблями.
Поэтому сегодня предлагаю немного вернуться назад и поговорить о том, как вообще строится Observability больших распределенных систем и что происходит с красивыми архитектурными схемами после встречи с продом =)
Метрики, логи, трейсы, тысячи сервисов, алерты, инциденты — поговорим о том, как во всем этом не утонуть и действительно понимать, что происходит с системой.
Обсудим прошлый доклад Григория, что изменилось за прошедший год, какие решения действительно работают, а какие оказались не такими прекрасными, как казалось изначально.
Ну иии немного заглянем в будущее =)
На DevOops 2026 Григорий готовит новый доклад:
DORA metrics: a story of failure
Доклада еще не было, поэтому сегодня мы его немножечко поспойлерим =)
Поговорим о том, почему после попытки научиться измерять распределенные системы возникает желание измерить еще и эффективность инженерных процессов.
И почему с Kubernetes, кажется, иногда разобраться проще, чем с людьми и процессами =)
Так что сегодня будет много Observability, немного DORA и, надеюсь, много интересных инженерных историй.
Подключайтесь сегодня, 18 сентября, в 18:00 МСК к прямой трансляции на Youtube!
Иии конечно, задавайте вопросы прямо во время эфира =)

Enjoy =)

DevOops 2026

Коллеги, всем привет! =)
Возможно, вы знаете, что я член программного комитета DevOops Conf
Ииии мы готовы! =)
Конференция пройдет 12–13 октября в Санкт-Петербурге
Мы подготовили для вас крутейшие доклады: от AI для инженеров до жидкостного охлаждения GPU, от Kafka в k8s до мок-собеседований
Мои ребята, которым я помогал в подготовке, будут рассказывать про Kafka в Kubernetes со Strimzi: от хаоса к контролю, Сломаться или стать сильнее? Зарисовки инцидентов c K8s в инфре MWS Cloud , Каскадный деплой в GitOps: два подхода на FluxCD
Привет, Ваня, Дима, Кирилл =)
А еще мы с Серегой проведем Fails Talks, который в прошлом сезоне всем ооочень понравился =)
Приходите, будет интересно =)
Enjoy =)
ЗЫ — за билетами по специальным условиям можно прийти в лс к @cherry_tok =)

Обновление k8s 1.33⇒1.34
Коллеги, всем привет! =)
По старой доброй традиции раз в квартал мы с коллегами обновляем наши k8s-кластеры.
Третий квартал не стал исключением. Обновлялись мы с версии 1.33 до 1.34.1.
Проверили совместимость при помощи Pluto, проблем не обнаружили.
К слову, обновление прошло гладко.
Правда, через небольшое количество времени заметили, что метрики PV испарились.
Оооочень неприятная история, так как у нас есть некоторое количество stateful-сервисов.
Пошли разбираться и нашли вот такое issue на GitHub
Если вкратце — ну пропало и пропало, метрики в альфа-версии =)
Метрики вернули в версии 1.34.2.
НО, когда мы обратились в саппорт с вопросом: «Как бы нам обновиться до 1.34.2, потому что метрики PV нам важны?»
Ответ был в духе: «Обновляйтесь до 1.35, там всё работает».
Решили не рисковать и перед обновлением проверили issues для 1.35.
И нашли очередной прикол, связанный с exec-пробами.
Проблема в том, что когда pod завершается, его пробы с типом exec перестают работать, и это напрямую влияет на graceful shutdown.
Мы решили перестраховаться и накидали простенький bash-скрипт для поиска сервисов с exec-пробами.
По итогу получили список, который почти полностью состоял из вспомогательных сервисов, напрямую не оказывающих влияния на бизнес.
Решили обновиться, так как метрики PV нам важнее.
Обновились также без проблем.
И за месяц на 1.35 проблем не обнаружили =)
Мораль сей басни — перед обновлением уточняйте, на какую конкретно версию вы обновляетесь, в том числе патч-версию.
Глазами или при помощи ИИ-агента проверьте открытые issues для этой версии — это определённо будет не лишним =)

Enjoy =)

PS — Ииии нас уже более 500, чему я очень рад! Пора придумать какую-нибудь активность =)

Коллеги, всем привет! =)
На подходе очередной выпуск DevOops Podcast, к слову, пятый по счёту =)
Подкаст пройдет 28.08.2026 в 18-00 МСК
На подкасте мы встретимся с Дмитрием Баскаковым и обсудим его прошлогодний доклад «Kafka в K8s — это просто!»
Также к нам присоединится Кирилл Протопопов и немного поспойлерит свой доклад в этом сезоне — «Kafka в Kubernetes со Strimzi: от хаоса к контролю».

О чём будет подкаст, или чуть больше деталей:

– Просто ли «катать» сотни Kafka-кластеров в K8s
– Самые большие вызовы, с которыми столкнулись команда и компания
– Kafka в Kubernetes — зачем вообще? Где профит, а где дополнительная боль?
– Как стандартизировать сотни кластеров и при этом не превратить платформу в монстра
– Strimzi: что он действительно упрощает, а что всё равно приходится делать самим
– Обновление Kafka-кластеров без боли и страданий
– ZooKeeper → KRaft: насколько страшна миграция в реальной жизни
– Как жить с разными размерами и профилями нагрузки Kafka-кластеров
– Как мониторить Kafka и понимать, что с ней действительно всё хорошо
– Факапы, грабли и ситуации из серии «на стенде всё работало» =)

Трансляция будет доступна по ссылке: Youtube

Добавляйте событие себе в календарь, будет интересно =)

Коллеги, всем привет! =)

В продолжение темы про обновление Harbor и про хранение артефактов в целом.
Бороздя просторы GitHub, наткнулся на два весьма интересных проекта.
Nora — минималистичная хранилка артефактов: поддержка кучи форматов пакетов, проксирование/кеширование пакетов из удалённых хранилок, развёртывается одним бинарём. Неплохой вариант, если инсталляция небольшая.
Artifact Keeper — а вот тут уже заявка на полноценный энтерпрайз со всеми вытекающими. Модульная архитектура, хранение артефактов в S3, поддержка множества форматов, резервирование из коробки иии нативный механизм миграции из JFrog Artifactory =)
Выглядит вкусно, если нужно большое и масштабируемое хранилище =)
Коллеги, !!!заранее обратите внимание!!!: проекты достаточно молодые. О крупных инсталляциях или конкретных кейсах эксплуатации я не слышал, поэтому, если решите стать первопроходцами, учитывайте риски.

Enjoy =)

Коллеги, всем привет! =)

6 мая 2026 случилось поистине великое событие (да-да, пишу очень вовремя) — вышел релиз Harbor 2.15.1.
Ну обновился Harbor и обновился, а прикол-то в чем? Как будто бы вполне ризонный вопрос — а что такого великого в этом релизе?
Как по мне, всю историю существования Harbor в нем была одна серьезная проблема.
А именно: если образ в проксируемом реджестри по какой-то причине становился недоступен или сам реджестри становился недоступным — проксируемый образ из Harbor мы получить уже не могли.
Даже если Harbor его до этого успешно скачал и он физически лежал в кеше.
Был хак, когда образ из Harbor можно было получить по его хэш-сумме, но это долго и неудобно.
В 2.15.1, а если точнее — тут, эту проблему наконец-то пофиксили.
Теперь, если образ или сам реджестри недоступны, но образ уже есть в кеше — его можно получить из Harbor.
Ииии это ровно то поведение, которого лично я ждал от Proxy Cache =)
Свой Harbor мы обновляли с версии 2.12.XX, с проверками на каждом этапе.
Обновляться стоит по порядку и точно не забывать про резервное копирование PostgreSQL, потому что с каждым обновлением проходят новые миграции БД.
Enjoy =)

Коллеги, всем привет! =)

Ранее я рассказывал про BSA-модель, к которой я часто обращаюсь в своих докладах.
Оригинальный пост вы можете найти по ссылке.
Иии 13 марта мы с коллегами из Flant провели вебинар, на котором подробно разобрали, как устроена модель, её плюсы и как она ложится на инфраструктуру.
Не забыли подсветить особенности и корнер-кейсы =)
Запись вебинара доступна тут: Youtube, Rutube, Dzen, VKvideo
Enjoy =)

ЗЫ1 — про DevOops Podcast: отдельный пост про то, где можно посмотреть запись, делать не буду — запись доступна по тем же ссылкам =)
ЗЫ2 — про DevOops Podcast: готовим следующие выпуски, stay tuned =)

Коллеги, всем привет! =)

Пришло время прервать молчание и начать писать посты регулярно. Как и обещал… ага-ага =)
За прошедшие 6–7 месяцев много чего произошло, и, кажется, пришло время обо всём этом рассказать.
Возможно, вы знаете, что я являюсь членом программного комитета DevOops Conf.
Ииии… мы с коллегами запустили небольшой подкаст =)
В подкаст мы приглашаем спикеров конференции, обсуждаем их доклады с DevOops Conf 2025, задаём неудобные вопросы, смотрим, что изменилось почти за год, и думаем, куда движемся дальше.

Мы уже провели три подкаста:
* DevOops Podcast #1 // «Битва кодовых ассистентов»
* DevOops Podcast #2 // Инженер: куда уж дальше? Есть ли жизнь после сеньора?
* DevOops Podcast #3 // Смерть классического IDP и восстание машин

Тема следующего подкаста:
Day 2 Operations: Как ломалась и крепла архитектура MWS Cloud на базе K8s и SaltStack

О чём поговорим?
* 💀 Смерть Immutable Infrastructure? (Боль идеалиста)
* 🔨 K8s как молоток, а весь мир — гвоздь (Истинная цена «дешёвой» инфраструктуры)
* ⚡ Некромантия или прагматизм: почему SaltStack?
* 💥 Blast Radius (радиус поражения) и ночные кошмары
* 🏗️ Platform Engineering и внутренний заказчик
* 🐤 Факапы и мёртвые канарейки

Подкаст состоится уже в эту пятницу, 07.08.2026, начало в 18:00 МСК.
В онлайне вы сможете пообщаться с членами ПК и спикером =)
Трансляция будет доступна здесь: Youtube, VK Видео

Добавляйте в свои календари =)

Ссылку на запись выложу немного позже ^_^

Коллеги, всех с прошедшими праздниками! ^_^

Хотел написать данный пост ещё в понедельник, но руки дошли только сейчас.
Начало года — всегда самая любимая пора,
потому что это всегда обновление каких-нибудь сертификатов и всякое такое, регулярно, но нечасто.
Самое весёлое в этом сезоне — это то, что EdgeCDN перестаёт предоставлять услуги CDN для Yandex Cloud, и всех просят мигрировать на Yandex CDN, коим мы сейчас и занимаемся.
Инструкция облака в целом исчерпывающая, а если у вас инфраструктура как код, то проблем возникнуть не должно.
Единственный момент — это как проверить работоспособность нового CDN?
А сделать можно это следующим образом.
Если вы шли строго по инструкции, клонировали ранее созданный CDN для своего доменного имени, вы получили CNAME нового CDN.
Там будет что-то вида 123123abcd.topology.gslb.yccdn.ru
После этого вам нужно узнать IP-адрес этого CDN, в этом нам поможет dig.

dig +short 123123abcd.topology.gslb.yccdn.ru

После того как мы получим IP-адрес (представим, что это 1.2.3.4), мы сможем собрать примерно вот такой curl:

curl -vvv --resolve my-awesome-service.ololo.ru:443:1.2.3.4 https://my-awesome-service.ololo.ru/

После его выполнения вы сможете проверить работоспособность нового CDN.
Enjoy и всем лёгкой первой трудовой недели ^_^
PS - а зачем проверять то? Инструкция от облака описывает чуть-ли не автомиграцию
"прЕкол" заключается в том, что замена CDN подразумевает замена CNAME для основого домена ради которого CDN и поднимается/настраивается
Любые работы с DNS, особенно в проде, несут ряд рисков и определенно стоит проверить все заранее
PPS - новый CDN будет "не прогретый", то есть в нем не будет кэша, по этому в моменте вы получите увеличение нагрузки на сервис за CDN до момента пока кэш "не прогреется"

BSA-модель

Коллеги, всем привет! =)
В своих докладах я довольно часто делаю отсылку к модели BSA (base-service-app), и порой меня спрашивают: «Откуда она вообще взялась?»

Впервые я познакомился с этой моделью в 2019 или 2020 году, когда трудился в E42 (кто знает — тот знает).

Модель BSA хороша тем, что она достаточно явно описывает связь «условного» бизнес-сервиса с необходимыми зависимостями (БД, кэши, очереди и т. д.) и инфраструктурой.

Как говорил классик: «Всё переплетено».

Давайте по порядку.

Базовый слой — это слой инфраструктуры, и именно тут разворачивается наше приложение. Это не просто условная ВМ или кластер Kubernetes — это ещё и необходимая инфраструктура: мониторинг, логирование, трейсинг и дополнительные компоненты.

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

Слой приложения — это уже само бизнес-приложение.

Благодаря такому разделению удобно работать с зависимостями. Например, мы так выставляли priority class для базового слоя.

Enjoy! =)

Коллеги, всем привет!=)
У DevOps Conf 2026 идет call for papers
А это значит, что если у вас есть о чем рассказать - самое время подать заявку
Ссылка на CFP - https://cfp.devopsconf.io/
Прием заявок до 24 ноября 2025!!!
Ключевые темы:
— Эксплуатация LLM
— AI-Driven Engineering: практики, риски и трансформация разработки
— Как сократить косты на инфраструктуру?
— Цифровые иммунные системы и инженерия надёжности (это SRE и новый термин оттуда)
— Про разработку для системных инженеров
— Требования регуляторов на простом русском
— Базовые практики работы и про то, почему они по-прежнему важны
Буду ли я подаваться с докладом? Да еще не решил, надо бы подумать, вдруг в закромах найдется что-то интересное =)

Как я стал фронтендером vol.2
Коллеги, всем привет! =)
Ранее я писал о том, как при помощи ИИ «заводил» техрадар (ссылка на первый пост: https://t.me/devops_not_burn/111).
Чем мне помог ИИ???
Начнём с того, что я ни разу не фронтендер, и иногда мне бывает сложновато сформулировать запрос.
Задача была достаточно простой — используя какое-то мейнстримовое решение, завести свой техрадар.
Первый ИИ — ChatGPT 5 с платной подпиской.
В целом, он помог всё базово запустить. На всё про всё ушло порядка часа.
Плюсы:
— быстрые ответы;
— хорошие базовые рекомендации.
Минусы:
— половина рекомендаций — мимо;
— ChatGPT 5 «не видит», что происходит на фронте.
Далее я воспользовался Claude Sonnet 4 в режиме агента — и вот тут стало гораздо интереснее.
Claude Sonnet 4 в режиме агента самостоятельно всё верстал и проверял.
Плюсы:
— всё сделано более-менее (всё-таки есть некоторое количество вопросов к решениям).
Минусы:
— сразу держите в голове, что вы общаетесь с джуном.
Если с фронтом ИИ-агент всё накручивал, то с инфрой я несколько раз его останавливал, потому что он творил откровенную дичь.
Какие выводы я могу сделать?
Для быстрого старта — вполне ок.
НО, как я уже не раз говорил в кулуарах:
«Если вы совершенно не шарите в теме, в которой просите помощи у ИИ — скорее всего, вам стоит приготовиться к страданиям и дебагу».
Я не противник ИИ. Я человек, который относится к нему как к помогатору, а не как к замене «кожаных мешков».
Enjoy =)

Как “сломать” всю команду в пятницу?
Коллеги, всем хорошей пятнички! =)
Как сломать всю команду в пятничку?
Достаточно скинуть во внутренний чатик вот эту ссылку https://floor796.com/ 😂😂😂
Этаж 796 - здоровнннннная гифка с каким то невероятным количеством отсылок к фильмам, играм, мемам и всякое такое
Enjoy, а найденные отсылки вы можете скидывать в чатик =)
ЗЫ - уже встречал эту гифку давно, и не давно накнулс в канале Макса и заностальгировал

Как я стал фронтендером
Коллеги, всем привет! =)
Приперло тут нам построить свой внутренний тех радар. Думаю никому не нужно объяснять, что это такое и какие задачи/вопросы он решает
Отправился я искать какой то фреймворк на котором можно быстро простроить тех радар с квадрантами, уровнями, преферансом и джунами
В ходу есть два варианта, это thougtworks tech radar и zalando tech radar
Ухххх, пока я все это добро “заводил” страдали строе: я, ChatGPT 5 Plus, Claude Sonnet 4
Проблема thougtworks заключается в том, что нужно не слабо так упороться, что бы из корня открывался твой радар и тебе не нужно было “волшебным” путем подсовывать адрес твоего радара для визуализации. Через N попыток, я сдался и отправился смотреть тех радар от Zalando.
Иии Zalando Tech Radar оказался куда более удобным и практичным. Единственная проблема которую пришлось порешать, это масштабирования радара.
На все про все у меня ушел примерно час.
Ну а болванка тех радара, если она вам потребуется доступна тут
Сэкономлю вам немного времени, вдруг пригодится =)
ЗЫ - если у вас что-то поедет в верстке - ну соррян, я не "фронтовик" =)
ЗЫЫ - надо бы пост что ли написать про то как я юзал Claude Sonnet 4 в качестве ИИ агента, спойлер - было весело =)

DevOops 2025
Коллеги, всем привет! =)
16-17 сентября в Питере прошел DevOops Conf. Это был юбилейный, десятый DevOops.
Иииии, я там тоже был, НО в этот раз не как спикер, а как член программного коммитета!!!
Что я имею по этому поводу сказать:
1 - это совершенно другой опыт, так как в обычной жизни ты готовишь один доклад, но тут ты помогаешь аж с 4 докладами
2 - на участие в ПК уходит горрраздо больше сил, но это определенно того стоило =)
А еще с мы Сергеем Киселевым (у него кстати есть свой канал "Буду погроммистом!") запустили новую активность “Fail Talks”.
Fail Talks приследовал несколько целей:
— дать возможность людям пообщаться при это не загоняя их в сверх жесткие рамки
— создать обстановку в которой не страшно рассказать про свои фейлы, даже если они “позорные”
Иииии мы справились, для разгона этой активности было 2 специально подготовленных “случайных” доклада, к концу докладов было уже 15
Коллеги, записывались, рассказывали, травили шутейки за 300, в какой то момент мне показалось, что в зале было человек под 80, что было супер круто =)
В общем и целом - мне все понравилось, быть бОльшей частью комьюнити и помогать другим спикерам готовиться
Дима, Даша, Ваня, Макарий - бесконечно благодарен вам за ваши доклады =)
Алена - сЫпасибо за супер координацию всего процесса =)
ЗЫ - а еще мы запускаем/достаем из закрамов еще одну DevOops активность, о ней я напишу позже =)
ЗЫЫ - немного фотокарточек в комментариях

Yandex Neuro Scale
Коллеги, всем привет! =)
Прошел Yandex Neuro Scale, ииии там я тоже отметился с докладом "Балансировка на грани: как мы распределяем нагрузку в Kubernetes-кластерах"
Как я и говорил в самом выступлении, я много “покапитанил” и в целом не рассказал ничего особо нового. Многие вещи, про которые я говорил, все уже давно используют у себя в проде.
Основная цель моего доклада — рассказать про наши приключения с повышением отказоустойчивости: мы хотим “жить” даже если потенциально, в моменте, одна зона доступности может испариться.
25 минут доклада на земле равняются 2 кварталам работы 4х инженерных команд =)
Так что всё это приключение точно было не из лёгких =)
ЗЫ — в кулуарах был вопрос: “А как там выживать, если есть ноды/нод-группы с тейнтами?”. Ответил, что “у нас такого нет, и проблем тоже нет =)”. В целом мой ответ валиден. Если посмотреть на него более детально, то нод-группы с тейнтами не особо-то и отличаются от обычных нод-групп. Нод-группы с тейнтами мы просто дублируем между зонами и в случае проблем эвакуируем нагрузку в другую зону.
ЗЫЫ — Yandex Neuro Scale персонально для меня — achievement unlocked👨‍🦯
ЗЫЫЫ — Да, отказоустойчивость, да, мы максимально живучие в случае больших инфра-проблем, но ценой чего? Мы тут запустили небольшой трек по оценке: “А всегда и везде нам нужна такая отказоустойчивость?”. По результатам вернусь =)

Big Tech Night - “послесловие”
Коллеги, всем привет! =)
BTN прошел, а мое выступление вы можете найти тут
Продолжаем “затаскивать”, боремся с сайд эффектами, решаем вопросики
Никто же нам не говорил что в платформе все будет просто! =)
Enjoy!
ЗЫ - надеюсь, что в ближайшее время, контента станет побольше =)
ЗЫЫ - не ну масштаб у BTN конечно был грандиозный, мы с ребятами успели побывать только в офисах Ламода, Т-банка и Яндекса =)