Автор: Лёша Королёв · Яндекс для разработчиков

Лёша Королёв — техлид команды observability в Яндекс Go. В этом докладе он показывает, как команда строит единый дашборд для платформы, в которой больше тысячи микросервисов, тысячи подов, базы данных, балансировщики, очереди и сотни изменений в проде каждый день. Когда происходит мажорный инцидент, проблема не в том, что у команды нет метрик. Проблема в том, что среди этого масштаба нужно быстро найти короткий путь к причине.

Дальше он разбирает, как устроен единый дашборд платформы такси и какие требования к нему предъявляет команда. Его задача — не показать всё на одном экране, а помочь ответить на два вопроса: в какой части платформы проблема и как такси чувствует себя прямо сейчас.

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

Из этого можно взять в работу: начните с бизнес-метрик. Если представить путь заказа как…

Автор: Алексей Мерсон · Код Желтый

Алексей Мерсон работает в Sage — внутренней observability-платформе Т-Банка. Доклад открывает конференцию по надёжности и наблюдаемости, организованную той же командой: это намеренно вводный разговор — синхронизировать понятия, прежде чем идти глубже.

Центральная структура доклада — пирамида качества: в основании надёжность, выше опыт пользователя. Это не абстракция: если система ненадёжна, весь разговор про UX и satisfaction теряет смысл. Надёжность Мерсон определяет через SRE-буки Google — вероятность выполнить требуемые функции без отказов за заданный период. Из этого вырастают SLI (конкретная метрика, связанная с пользовательским опытом), SLO (целевое значение) и бюджет ошибок — то время, которое система может «лечь», не нарушив SLO. Ключевые метрики для оптимизации — MTBF (среднее время между отказами) и MTTR (среднее время восстановления): чем больше первое и меньше второе, тем лучше используется бюджет ошибок. Наблюдаемость нужна именно для того, чтобы обе величины…

Автор: Иван Ямщиков · Podlodka Podcast

Иван Ямщиков работает в Pleias — компании, которая строит открытые языковые модели. Во время записи выпуска Podlodka #468 вышла новость о партнёрстве Pleias с Nvidia в рамках проекта Nemotron. Это не случайный контекст: Ямщиков находится внутри процесса, а не смотрит на него снаружи.

Центральный вопрос выпуска — не технический, а стратегический: что произойдёт, если весь рынок AI окончательно сконцентрируется вокруг нескольких закрытых облачных провайдеров? Ямщиков формулирует это как инженерную проблему: зависимость от GPT-4 API — это зависимость от одного вендора с непрозрачной политикой изменений, ценообразования и доступа к данным. Маленькие открытые модели — это не «дешёвая альтернатива большим», это инструмент сохранения контроля над инфраструктурой. Модель на 7 миллиардов параметров, которая умещается на одной GPU и работает локально, даёт то, что никакое API не даёт: полную воспроизводимость, отсутствие утечки данных и независимость от апстрима.

Кому смотреть: разра…

Автор: Максим Денушев (Точка) · Golang Channel

Максим Денушев работает в банке Точка. Доклад с GolangConf 2024, 31 минута. API Gateway — компонент, через который проходит весь трафик платформы. Переписать его — значит заменить двигатель у летящего самолёта: система должна оставаться доступной, а пользователи не должны заметить, что что-то происходит.

Главная сложность такой задачи не техническая, а операционная. Выбрать новый стек и написать код — это меньшая часть работы. Настоящий вызов — как организовать переход так, чтобы в каждый момент времени система работала корректно для всех клиентов. Денушев разбирает подход, который команда применила: постепенное перемещение трафика через новый Gateway параллельно со старым, профилирование под реальной нагрузкой, работа с проблемами обратной совместимости, которые обнаруживаются только когда через систему идут реальные данные. Это не история успеха без шрамов — доклад честный о том, с какими проблемами они столкнулись и что их не предусмотрели заранее.

Кому смотреть:…

Автор: Дмитрий Самохвалов · HighLoad++ Channel

Доклад с HighLoad++ 2024, 49 минут. Kubernetes великолепно работает внутри себя. Проблемы начинаются на границе: когда поды должны обращаться к legacy-сервисам вне кластера, а legacy-системы — к подам. Эта граница существует у большинства компаний, которые переходят на Kubernetes постепенно, а не заново строят всё с нуля.

Самохвалов разбирает конкретные конфигурации и паттерны: как работает сетевая модель Kubernetes (flat network, каждый под получает IP) и почему она не совпадает с тем, чего ждёт legacy-окружение; как CNI-плагины (Calico, Cilium, Flannel) по-разному решают задачу связности; как настроить BGP-пиринг между кластером и существующей сетевой инфраструктурой; почему NodePort и LoadBalancer — это не решение, а костыль, который работает до определённого масштаба. Это доклад не про «установите Kubernetes», а про то, что происходит когда старая и новая инфраструктура должны сосуществовать в одной сети.

Кому смотреть: DevOps- и SRE-инженерам, занимающимся…

Автор: Listen IT · Listen IT

Видео Listen IT, 9 минут. Canary deployment и Blue-Green — две стратегии выката, которые решают одну задачу разными способами: как выпускать новые версии без того, чтобы весь трафик сразу шёл на непроверенный код.

Canary deployment — это постепенный выкат: сначала 1–5% пользователей получают новую версию, остальные работают со старой. За это время смотрят на метрики: error rate, latency, конверсии. Если всё хорошо — процент растёт. Если что-то ломается — откатить стоит секунд, а не часов. Название идёт от шахтёрской практики: канарейки чувствовали токсичный газ раньше людей. Небольшой процент пользователей — первые, кто обнаруживает проблему, пока большинство ещё на безопасном коде. Это принципиально другой разговор о надёжности: не “как сделать, чтобы не сломалось”, а “как сделать, чтобы поломка затронула минимум людей и откатилась быстро”.

Кому смотреть: разработчикам и DevOps-инженерам, у которых релиз — это страшное событие раз в неделю с ручным smoke-тестингом. И тем, кто хочет…

Автор: Дмитрий Евдокимов · VK Cloud

Дмитрий Евдокимов — CTO Luntry, платформы безопасности для Kubernetes. Luntry строится поверх Kubernetes API, поэтому понимание KRM у него не теоретическое — это основа продукта. Доклад с VK Kubernetes Conference.

Kubernetes Resource Model — это абстракция, которую легко пропустить за привычными деплойментами и сервисами. Суть в том, что Kubernetes — это не оркестратор контейнеров, а universal control plane для управления любыми ресурсами. Всё, что можно описать как «желаемое состояние + текущее состояние + reconciler», может стать Kubernetes-ресурсом. Это означает, что KRM применима не только к подам, но и к облачным ресурсам, сетевым политикам, конфигурациям безопасности и вообще к любому объекту с жизненным циклом. Everything-as-Code здесь не лозунг, а архитектурное следствие: если ресурс существует в Kubernetes API, он автоматически версионируем, аудируем, управляем через GitOps.

Евдокимов объясняет, как устроены CRD (Custom Resource Definitions), как писать операторы, и…

Автор: Олег Казаков · Spectr

Олег Казаков — CTO в Spectr, выступал на митапе Spectr в сентябре 2025 года. Spectr — продуктовая IT-компания, и Казаков рассказывает о внедрении observability изнутри: не как консультант, а как человек, который жил с проблемой и решал её в работающем продукте.

«Тушение пожаров» — это диагноз: команда реагирует на инциденты после того, как они случились, вместо того чтобы видеть деградацию заранее. Observability меняет режим работы с реактивного на проактивный. Казаков разбирает, как это сделать без enterprise-бюджета: стек Prometheus + Loki, который покрывает 90% потребностей продуктовой команды, и подход к внедрению в существующий продукт без остановки разработки. Центральный тезис: не нужен Datadog за сотни тысяч долларов в год. Нужны правильные метрики, алерты, которые срабатывают до того как пользователи пишут в поддержку, и процесс, который команда реально использует.

Кому смотреть: CTO и техлидам продуктовых компаний, у которых observability — это «когда-нибудь потом» или…