Автор: Сергей Петренко · HighLoad++ 2022

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

В докладе Сергея Петренко команда Tarantool пробует сочетать оба режима: использовать Raft и синхронную репликацию, но сохранять возможность вручную ослабить ограничения во время аварии. CAP-теорему такая настройка не отменяет. Она лишь переносит последствия решения на тот момент, когда связь восстановится и две части кластера попытаются снова работать вместе.

Кому смотреть: инженерам, которые проектируют failover, настраивают кворумы или составляют инструкции на случай потери связи между ЦОДами.

Из этого можно взять в работу: дополнить процедуру аварийного снижения кворума планом последующего восстановления — как обнаружить расхождение, сохранить обе ветви и выбрать правильную историю.

Авторы: Ирина Блажина и Николай Зайцев · HighLoad Channel

В X5 Tech несколько продуктов использовали собственные системы аутентификации. Пользователям приходилось заново входить в разные сервисы и получать дополнительные SMS, а команды независимо поддерживали код, связанный с безопасностью. Единый SSO должен был решить обе проблемы.

Основой системы стал Keycloak. Его возможностей хватало для обработки входов, но при росте аудитории команда столкнулась с другим ограничением: время запуска зависело от количества сохранённых сессий. Так задача масштабирования SSO превратилась в разбор кэшей, rolling updates, PostgreSQL и устройства самого Keycloak.

Кому смотреть: командам, которые внедряют централизованную аутентификацию, расширяют Keycloak собственными providers или готовят SSO к большой аудитории.

Из этого можно взять в работу: проверять identity-сервис не только под потоком входов, но и при полном перезапуске кластера с реальным объёмом пользовательских сессий.

Автор: Eugene Suleimanov · Proselyte

Почти двухчасовой курс от автора Eugene Suleimanov показывает Keycloak не как «готовую страницу входа», а как отдельную платформу, которой приложение передаёт значительную часть работы с аутентификацией и авторизацией.

Полностью пересказать такой материал в одном дайджесте невозможно. Автор последовательно проходит от realm, clients, scopes и roles до OAuth 2.0, OpenID Connect, SAML, федерации пользователей и межсервисного доступа. Затем собирает практическую систему с двумя приложениями, PostgreSQL и Keycloak, подключает внешние Identity Providers и защищает вызовы между сервисами.

Главная мысль курса — у приложения не одна граница входа. Пользователь может приходить напрямую или через GitHub, учётная запись может храниться в LDAP, а один сервис должен обращаться к другому без участия человека. Keycloak даёт общую точку, где эти сценарии можно описывать и контролировать.

Кому смотреть: разработчикам и архитекторам, которые выбирают между собственной подсистемой доступа и отдельной identity-платформой.

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

Автор: Listen IT · YouTube · статья Nixys

При входе через SAML приложение не получает пароль пользователя. Вместо него оно получает XML-документ, в котором Identity Provider утверждает, что пользователь прошёл аутентификацию. Теперь безопасность зависит от того, насколько строго приложение проверяет это утверждение.

Ролик Listen IT объясняет основные роли SAML. Service Provider представляет приложение, Identity Provider проверяет пользователя, а браузер переносит SAML-запросы и ответы между ними. Благодаря установленному доверию один вход у IdP может открыть доступ к нескольким независимым приложениям.

Это хорошее введение в SAML SSO, но реальный протокол сложнее показанной схемы. Недостаточно найти в ответе имя пользователя: Service Provider должен проверить цифровую подпись, отправителя, получателя, срок действия и другие ограничения assertion.

Кому смотреть: разработчикам, которым предстоит впервые подключать корпоративный SAML-вход и нужно понять роли IdP, SP и браузера.

Из этого можно взять в работу: перед интеграцией перечислить все проверки SAML response, которые выполняет выбранная библиотека, и убедиться, что они не отключены ради успешного первого входа.

Автор: Listen IT · YouTube · статья Nixys

Single Sign-On часто объясняют как «один пароль для всех приложений». Но главное изменение происходит не в пароле: приложения перестают самостоятельно проверять учётные данные и начинают доверять результату аутентификации в другой системе.

Ролик Listen IT показывает базовый сценарий SSO. Пользователь открывает приложение, перенаправляется к Identity Provider, проходит аутентификацию и возвращается с подтверждением личности. После этого другие приложения, включённые в ту же систему доверия, могут не запрашивать пароль повторно.

SSO при этом не является отдельным протоколом. Это желаемое поведение системы, которое можно реализовать через SAML или OpenID Connect. LDAP, Active Directory Domain Services и Active Directory Federation Services тоже появляются рядом с SSO, но решают задачи другого уровня: хранят пользователей, предоставляют доступ к каталогу или организуют федерацию.

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

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

Автор: Дмитрий Емельянов (Altenar) · Видео с мероприятий {speach!}

В 39-минутном докладе Дмитрий Емельянов, тимлид группы разработки в Altenar, рассказывает об аварии, которая началась почти как анекдот: команда настраивала новый бэкап Kafka — и именно в этот момент потеряла Kafka. Но самое интересное случилось не во время аварии, а после, когда кластер уже удалось восстановить.

В системе Altenar некоторые топики были не просто транспортом между микросервисами, а единственным источником истины. При запуске сервисы перечитывали их, собирали состояние в памяти и затем продолжали работать с ним. Kafka реплицировалась между брокерами, а раз в сутки её файлы дополнительно копировали с одного диска на другой. Восстановление этих копий не проверяли: для этого пришлось бы останавливать stage, мешать работе QA и откладывать бизнес-фичи.

Когда Kafka исчезла, после восстановления из свежего бэкапа в ней не хватало части партиций. Копия двухдневной давности поднялась успешно: топики на месте, сервисы запускаются, объём данных выглядит правдоподобно. Казалось бы, инцидент закончен. На самом деле система только что раскололась во времени: база осталась в настоящем, а Kafka вернулась на два дня назад.

Кому смотреть: разработчикам и архитекторам, у которых Kafka хранит состояние системы, а рядом существуют базы, кэши или другие независимо восстанавливаемые хранилища.

Из этого можно взять в работу: проверять не только то, поднимается ли Kafka из копии, но и то, сможет ли после отката продолжить работу вся система. Особенно важно заранее понимать, как устранять рассинхронизацию между хранилищами, восстановленными на разные моменты времени.

Автор: Антон Алексеев · HighLoad++ 2024

Доклад с HighLoad++ 2024 о том, как Selectel собирал инференс-платформу на базе open source-сервера NVIDIA Triton и Kubernetes. Triton решает базовую задачу: позволяет обслуживать ML-модели в продакшне без написания отдельного сервиса для каждой модели с нуля.

Сценарий типичный: модель сначала заворачивают в FastAPI, а затем обвязка постепенно обрастает batching, управлением инстансами, распределением GPU-ресурсов, обновлением версий и маршрутизацией трафика. Triton закрывает существенную часть этой базовой работы: умеет динамический batching, поддерживает модели в форматах PyTorch, TensorFlow, ONNX и TensorRT, а ensemble позволяет собрать цепочку моделей внутри одной ноды с одной GPU.

Но production-инференс начинается там, где заканчивается сам сервер моделей. Канареечное распределение трафика в платформе сделано через Istio, графы моделей на нескольких нодах — через Ray, а автоскейлинг GPU-ресурсов — средствами Kubernetes и дополнительными компонентами. Важная деталь: на момент доклада платформа Selectel ещё находилась в beta, поэтому это не история про «готовое решение из одной коробки», а разбор того, как такую систему собирают на практике.

Кому смотреть: ML-инженерам, MLOps- и DevOps-командам, которые обслуживают несколько моделей на GPU и хотят понять границу между возможностями inference-сервера и задачами всей платформы.

Из этого можно взять в работу: при внедрении Triton заранее разделите требования на две группы — что должен делать сам сервер моделей, а что потребует Kubernetes, service mesh, автоскейлинга, GPU-оператора или отдельного control plane.

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

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

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

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

Из этого можно взять в работу: начните с бизнес-метрик. Если представить путь заказа как последовательность статусов, то бизнес- и техническая воронки быстро показывают, на каком участке возник сбой. А дальше ссылки должны вести от агрегированной картины к конкретному сервису и его логам.

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

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

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

Кому смотреть: инженерам и тимлидам, которые слышали слова SLO, observability и MTTR в разных контекстах, но хотят разложить их по полочкам и понять, как они связаны между собой — до того как разбираться с конкретными инструментами.

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

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

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

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

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

Из этого можно взять в работу: если вы сейчас используете закрытый API для задачи, которая не требует GPT-4-уровня рассуждений (классификация, извлечение структуры, генерация по шаблону) — попробуйте запустить Mistral 7B или Phi-3 локально на той же задаче. Разрыв в качестве окажется меньше, чем вы ожидаете.

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

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

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

Кому смотреть: backend-инженерам и архитекторам, которые стоят перед задачей замены критического инфраструктурного компонента — не только 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-инженерам, занимающимся миграцией на Kubernetes в организациях с существующей инфраструктурой — особенно там, где legacy не уйдёт в ближайшие годы.

Из этого можно взять в работу: если у вас поды Kubernetes обращаются к legacy-сервисам через ExternalName Service или захардкоженные IP — это временное решение, которое не масштабируется и не обеспечивает failover. Доклад показывает, как это сделать правильно.

Автор: Listen IT · Listen IT

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

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

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

Из этого можно взять в работу: посмотрите на последний релиз в вашей системе. Сколько времени заняло бы обнаружение проблемы, если бы она появилась? Если больше 15 минут — у вас нет canary, и риск каждого релиза выше, чем должен быть.

Автор: Дмитрий Евдокимов · 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), как писать операторы, и почему правильно понятый KRM убирает необходимость в отдельных инструментах управления конфигурацией для многих сценариев.

Кому смотреть: platform engineering командам и SRE, которые уже используют Kubernetes и думают о расширении его за пределы стандартных ресурсов — управление инфраструктурой, политиками, секретами через единый API.

Из этого можно взять в работу: посмотри, какие операции ты делаешь через скрипты или сторонние инструменты, которые по сути управляют состоянием системы. Можно ли выразить это как Kubernetes-ресурс с оператором? Если да — ты получаешь GitOps, аудит и версионирование бесплатно.

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

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

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

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

Из этого можно взять в работу: определи три метрики, которые лучше всего описывают здоровье твоего продукта (p95 latency, error rate, длина очереди задач). Настрой алерты только на них — всё остальное потом. Три правильных алерта лучше, чем 300 шумящих.