DevOps Deflope News

Linux Foundation с помощью CNCF выпустил два бесплатных курса про документацию. • LFC111 — Open Source Technical Documentation Essentials Тут основы. Как структурировать, писать и поддерживать техническую документацию в Open Source-проектах. • LFC112 — Creating Effective Documentation for Developers А здесь уже больше практики. Документация API, туториалы, гайды, всё, что мы пишем регулярно. Оба курса рассчитаны на разработчиков, инженеров, PM’ов и технических писателей с базовым пониманием разработки. Обучение занимает 3-4 часа, можно проходить уроки в своём темпе. Нас с вами, коллеги, особо никто не учил писать документацию, а жаль. Конечно, эти курсы не заменят практику и живые задачи. Но они могут дать хорошую базу, чтобы вашей документацией действительно пользовались. Бесплатно, без подписок и смс. Круто же)

Дочитал «Настоящий SRE» Дэвида Бланк-Эдельмана. Это третий пост из серии, я Алексей Крылов, менеджер продукта. Итоговые впечатления. Главная фишка книги — иерархия надёжности Дикерсона. Пирамида, построенная по той же логике, что и пирамида Маслоу. В основании лежат мониторинг и наблюдаемость. Дальше идут реагирование на инциденты, разбор последствий без поиска виноватых, тестирование и релизы, планирование ресурсов, разработка. На самом верху — проектирование продукта с учётом надёжности с самого начала. Нельзя перейти на следующий уровень, не отстроив предыдущий. Для тех, кто только начинает, это честная дорожная карта. Важный нюанс в том, что движение по этой пирамиде нелинейное. Команда может быть на высоком уровне зрелости и внезапно вернуться в режим «пожарных» из-за крупного инцидента. Это нормально, и книга честно об этом предупреждает. Книга отвечает на вопрос «с чего начать», а не просто описывает, как всё устроено в Google. Структура позволяет читать нелинейно: первая часть про менталитет обязательна, а дальше можно выбирать — вторая часть про личный карьерный путь, третья про внедрение в организацию. Автор так и говорит, выберите своё приключение. Он собрал опыт множества практиков, добавил реальные истории, здоровый юмор и неожиданно много внимания уделил человеческому фактору: этике, эмпатии, выгоранию. Для технической книги редкость. Из слабых мест: иерархия Дикерсона при всей полезности неполна, и сам автор это признаёт. В ней нет места для роли SRE-инженера в проектировании архитектуры на ранних стадиях и нет борьбы с рутиной как отдельного уровня. Местами книга перегружена сносками, а центральная метафора с дайвингом к концу, по словам самого автора, становится «всё более громоздкой». Но есть кое-что интереснее формальных недостатков книги. Ловушка самого подхода. Если система работает слишком хорошо и никогда не падает, все вокруг расслабляются и перестают готовиться к сбоям. Когда инцидент всё же случается — последствия непропорционально тяжёлые, потому что никто не ждал. Книга об этом честно предупреждает. Кому рекомендую: инженерам, которые хотят взглянуть на свою работу с точки зрения влияния на компанию. Тем, кто чувствует, что просто тушит пожары, но хочет понять, как выстроить систему, в которой пожаров становится меньше. P.S. Редакция канала благодарит издательство Питер за предоставленную физическую версию книги :)

Все внедрили ИИ. Все давно в облаке, все Cloud Native, все успешны. Так выглядит любая конференция. А что на самом деле? Наши коллеги из Ассоциации облачно-ориентированных технологий решили выяснить и запустили исследование состояния Cloud Native в России 2026, которое выросло из всем знакомого State of DevOps Russia. Как всегда, опрос подробный, а отчёт с выводами будет открытым для всех. Чем больше людей пройдут опрос, тем точнее будет отчёт и тем интереснее будет сверить себя с рынком. Может, окажется, что всё не так плохо. А может — наоборот)) И это тоже полезно знать. Пройти опрос →

Broadcom передала Velero в CNCF. Velero — это инструмент для бэкапа и восстановления Kubernetes-кластеров. Бэкапит не диски, а объекты: деплойменты, права доступа, тома, то есть, всё, что нужно, чтобы поднять приложение заново или перенести его в другой кластер. У проекта длинная история: он начинался как Heptio Ark, затем после покупки Heptio стал частью VMware, а после сделки VMware/Broadcom оказался в зоне влияния Broadcom. При этом Velero давно используется в проде многими командами и сейчас имеет около 10 тысяч звёзд на GitHub. Несмотря на популярность, вокруг Velero оставался вопрос лицензии и регулирования. После резких изменений в VMware-лицензировании часть рынка стала осторожнее относиться ко всему, что находится под контролем Broadcom. Для Open Source это особенно чувствительно. Сегодня вендор активно развивает проект, завтра меняет стратегию, и пользователям приходится жить с последствиями. Переход в CNCF этот аргумент снимает, и теперь ни один вендор не может в одностороннем порядке закрыть проект или резко сменить направление. Релизы, состав мейнтейнеров, роадмапы — всё это теперь решается коллегиально, по правилам CNCF Важно не путать. Переход в CNCF не упрощает эксплуатацию. Object storage, IAM-учётки, живой целевой кластер никуда не делись, это по-прежнему требует инженерного внимания. Изменилось только то, кто принимает решения по проекту. В общем, этот анонс — хороший повод снова посмотреть на Velero тем, кто давно не смотрел. Один весомый аргумент против теперь снят.

Как гарантированно похоронить SRE в своей компании На связи Алексей, читаю «Настоящий SRE» Бланк-Эдельмана. В книге разбирают, как SRE приживается в компаниях, и почему чаще всего не приживается. Сценарии, судя по всему, везде одни и те же. Вот вредные советы, что сделать, чтобы и у вас не прижился. Самый быстрый способ — переименовать должности. Был «системный администратор», стал «SRE-инженер». Обязанности те же, культура та же, приоритеты те же. Через полгода организация разочаруется и скажет, что SRE не работает. Второй вариант — превратить команду в службу поддержки третьего уровня. Все сложные тикеты, которые не смогли разобрать другие, летят к SRE-инженерам. Они разгребают, тушат пожары, ни на что другое времени не остаётся. Никаких петель обратной связи, никакого роста надёжности. Третий вариант — дать команде роль привратника с правом блокировать любой деплой во имя надёжности. Звучит разумно, но на практике другие команды начинают искать способы обойти контроль, и в итоге проигрывают все. Четвёртый — изолировать команду SRE, посадить их подальше от владельцев продукта. Когда чтобы обсудить приоритеты нужно подняться на несколько уровней иерархии, взаимодействие замедляется настолько, что SRE просто перестаёт влиять на то, что происходит. Ещё один сценарий, который автор называет «смертью от успеха»: команда растёт, ей передают всё новые сервисы, а право говорить «нет» при этом никто не даёт. Инженеры тонут в операционке, выгорают и уходят. Ну и классика — культура поиска виноватых. SRE как дисциплина держится на обучении из ошибок. Если за сбои наказывают, инженеры скрывают сигналы о проблемах, и учиться становится просто не на чем. И отдельный антипаттерн, который выглядит невинно — скопировать практики Google один в один. Взять книжку, внедрить всё по инструкции, и получить результат, который не работает, потому что у вашей организации другая культура, другие ценности и другой контекст. Все эти истории заканчиваются одинаково. SRE перестаёт быть инженерной дисциплиной и превращается в новое название для старых методов эксплуатации.

Мы тут наткнулись на новость, которая одновременно и грустная, и очень показательная. pgBackRest закрывают. Дэвид Стил, автор pgBackRest, объявил о завершении жизненного цикла проекта, который он поддерживал 13 лет. Причины не из серии устал или поссорился, а скорее структурные. Crunchy Data была для него источником рабочего времени на поддержку проекта. После продажи компании эта опора исчезла, и продолжать pgBackRest на прежнем уровне стало просто не на что. Спонсорства или новой роли, которая бы закрыла эту дыру, не нашлось,чтобы продолжать поддержку на нормальном уровне. Делать кое как он не захотел и просто остановился. К сожалению, практически типичный паттерн для инфраструктурного Open Source :( Есть инфраструктурный Open Source проект, который реально используется в продакшене, ловит редкие баги и неприятные edge-case’ы, а держится на одном человеке или маленькой команде. Пока есть корпоративные деньги, всё выглядит более-менее стабильно. Деньги исчезают, и у мейнтейнера остаётся выбор без хороших вариантов. Либо делать хуже, либо закрывать. Здесь выбрали закрыть. Да, Open Source можно форкнуть и поддерживать дальше. В этом его сила, но есть нюанс. Все почему-то забывают, что форк не возникает из воздуха, на него нужны люди, время, ответственность и деньги. Неплохой такой стресс-тест. Если никто не подхватил, значит проект либо не так нужен сообществу, либо всем нужен, но никто никто не готов вкладываться временем и ресурсами. Проблема в том, что многие компании годами используют такие проекты как основу своих продуктов и сервисов, но инвестируют в поддержку по минимуму. Проект держится на небольшом запасе прочности, и при любом внешнем событии вроде смены работодателя, продажи компании или прекращения спонсорства этот запас заканчивается. Дальше начинает сыпаться именно поддержка, скорость реакции на баги и уверенность пользователей, что завтра это всё ещё будет работать. И важный вывод тут в том, что pgBackRest закрылся не из-за качества кода. Он закрылся из-за того, как была устроена поддержка. В статье ещё отдельно поднимается тема CloudNativePG и CNCF. Когда проект находится под нейтральным управлением, его сложнее выключить одним решением внутри компании, а риски внезапного исчезновения ниже. Но есть нюанс. Одна только структура не делает проект живым. Без людей, которые пишут код, делают ревью и отвечают за релизы, никакая модель управления не спасёт. В общем, вывод неприятный, но честный. Open Source можно скачать бесплатно, а поддержка всегда оплачивается деньгами, инженерами, контрактами или временем. Если это перестаёт происходить, проект рано или поздно заканчивается, даже если технически он был отличным.

Многие считают, что DevOps и SRE просто разные названия одной роли. Это не так. Меня зовут Алексей, я инженер с 25+ лет опыта, по совместительству — менеджер продукта во Фланте, и мы развиваем экосистему продуктов Deckhouse. Недавно начал читать «Настоящий SRE» Дэвида Бланк-Эдельмана, и первое, с чем разбирается книга, это именно этот вопрос. Хочу с вами поделиться. По книге DevOps-инженер смотрит на путь кода от ноутбука разработчика до прода. CI/CD в центре, главный вопрос — как быстрее довезти. SRE-инженер начинает с самого прода и смотрит назад: что нужно сделать, чтобы там всё не рассыпалось? Оба могут работать с одними инструментами, мониторингом, теми же пайплайнами, но с разными целями. DevOps как практика ускоряет поток. SRE как дисциплина выстраивает петли обратной связи и меряет успех через SLI/SLO и бюджеты на ошибки. SRE-инженера при этом не интересует, как система должна работать по документации. Его интересует, как она работает в реальности, со всеми неявными зависимостями, состояниями отказа и сюрпризами, которые прод преподносит ночью в пятницу. В книге выделяется ещё одно важное отличие. Для SRE ошибка — это не что-то, что нужно быстро исправить, а, скорее, сигнал, из которого можно узнать что-то новое о системе. И ответственность за сбой лежит не на конкретном человеке, а на системе в целом. В здоровой организации эти роли не конкурируют. DevOps-инженеры ускоряют выпуск, SRE-инженеры следят, чтобы выпущенное доехало до пользователя целым. Одни везут, другие следят, чтобы машина не сломалась по дороге. Компании нужны и те, и другие — это разные люди с разным фокусом. На практике все сильно зависит от компании: от отрасли, от оргструктуры компании и ее инженерной зрелости. Отрасль накладывает регуляторные ограничения и требования, например в финтехе практикуется разделение зон ответственности на change (разработка и devops) и run (сопровождение и SRE). Там, где нет регуляций, ситуация более интересная. Один и тот же инженер в разные моменты думает то как DevOps, то как SRE, в зависимости от того, горит ли прод или надо выкатить фичу. А у вас в командах эти роли разделены или один человек делает всё?

В феврале вышел Gateway API 1.5, а недавно — статья про него в блоге Kubernetes. Решили посмотреть и вам показать) Весь релиз про шесть фич, которые переехали из experimental в stable. Новых возможностей практически нет. Всё это уже было, просто теперь официально «готово к проду». Во-первых, ListenerSet. Раньше все listener'ы нужно было описывать прямо внутри Gateway. Для небольших конфигов нормально, а вот в multi-tenant окружениях быстро начинается веселье. Разным командам нужно добавлять свои hostname и listener'ы, но для этого приходится трогать один общий Gateway. Теперь listener'ы можно описывать отдельно и прикреплять к общему Gateway. Инфраструктурная команда держит базовый Gateway, команды приложений добавляют свои ListenerSet, а контроллер уже сам всё объединяет. То есть делегировать владение listener'ами стало сильно проще. И, что тоже важно, через ListenerSet можно прикреплять к одному Gateway больше 64 listener'ов. Едем дальше. TLSRoute стал стабильным. Это маршрутизация TLS-трафика по SNI. Gateway смотрит на hostname, который клиент передаёт во время TLS-handshake, и отправляет поток в нужный backend. Следующий значимый кусок — про mTLS. Gateway теперь умеет проверять клиентский сертификат на входе и предъявлять свой сертификат бэкенду на выходе. Звучит как мелочь, но без этого полноценный zero-trust внутри кластера был неудобным. Тоже не новая идея, просто наконец стабильная. Но есть нюанс. Если у вас уже были старые experimental TLSRoute из v1alpha2, при переходе на v1.5 standard они сами по себе не подхватятся. Нужно либо оставаться на experimental, либо мигрировать их в v1. Ещё одна полезная штука, HTTPRoute CORS Filter. CORS теперь можно настраивать прямо в HTTPRoute, а не размазывать по приложению, ingress-аннотациям или особенностям конкретного контроллера. Можно задать разрешённые origin'ы, методы, заголовки, credentials и maxAge для preflight-запросов. То есть браузерная боль «почему фронт опять не ходит в API» становится чуть более стандартизированной. Ну и ReferenceGrant теперь v1. Это механизм для безопасных ссылок между namespace. Например, когда Gateway или Route из одного namespace должен сослаться на ресурс в другом. ReferenceGrant работает как явное разрешение от владельца namespace. Да, этому ресурсу можно ссылаться на Secret, Service или другой объект. Ресурс больше года не менялся, поэтому его перевели в стандарт и под GA API contract. То есть без внезапных breaking changes. Отдельно интересно, что проект перешёл на release train. Теперь в релиз попадает то, что готово к feature freeze. Причём готовность не только про код, но и про документацию. Если документация не готова, функция тоже не готова. Звучит скучно, но для проекта уровня Gateway API это хороший знак. Меньше хаоса, больше предсказуемости. В общем, Gateway API 1.5 выглядит как релиз про взросление. Не «вот вам пачка экспериментальных фич, разбирайтесь», а скорее «мы с вами всё обкатали, теперь это будет частью стабильной версии». Итог. Для тех, кто уже на Gateway API, хорошая новость, можно обновляться. Для тех, кто ещё не перешёл, не повод :) Подробнее на kubernetes.io

Мы тут наткнулись на статью про ИИ-слоп. Хотим поделиться с вами мыслями. Похоже, Open Source столкнулся с проблемой. Раньше, чтобы отправить PR, нужно было хотя бы разобраться в коде. А теперь будто достаточно прогнать issue через ИИ и нажать Submit. Короче, порог входа упал почти до нуля. Снаружи это выглядит как рост активности. Больше людей, больше вкладов, больше движения. Но раньше этот рост работал иначе. То есть Open Source держался на том, что вклад стоил усилий, нужно было разобраться в коде, воспроизвести проблему, аккуратно внести изменения и быть готовым за них отвечать. Это создавало естественный фильтр качества и заодно ответственность. С появлением ИИ этот фильтр почти исчез. Сгенерировать PR стало дёшево. А вот проверить его — нет. И вот вам цифры из статьи: по оценке одного из разработчиков, ревьюер тратит на разбор и исправление одного ИИ-PR в 12 раз больше времени, чем его автор — на генерацию. Получается, мейнтейнеры получают поток вкладов, которые нужно разбирать, перепроверять и часто отклонять. И это бьёт особенно больно, ведь почти 60 % мейнтейнеров — неоплачиваемые волонтёры. Вот пруф. По сути, это меняет саму механику Open Source. Модель «больше участников → больше пользы» перестаёт работать, когда количество растёт, а доля некачественных вкладов заглушает адекватные решения. Проблема в том, что ИИ практически убрал необходимость разбираться, но не добавил ответственности за результат. А Open Source всегда держался именно на этом балансе. Отсюда и ответные меры: более жёсткие правила, фильтры, ограничения на PR, попытки ввести репутацию и верификацию. Некоторые проекты идут дальше — например, Jazzband был вынужден полностью прекратить существование, потому что поток спама из ИИ-PR и issues сделал его неустойчивым. cURL закрыл bug-bounty-программу после того, как за восемь часов получил 16 submissions, ни один из которых не содержал реальной уязвимости. Но давайте посмотрим с вами шире. Тут ломается не только поток PR, а вся воронка контроля качества. На каждом этапе этой воронки раньше происходил отсев сначала, ведь само участие просто стоило усилий, потом автоматические проверки, тесты и затем уже ревью человеком. Схема была простой: linter (automation) → unit-tests (automation) → review (human) Сейчас этого уже недостаточно. Ручное ревью просто не масштабируется :) Поэтому должен случиться ещё один этап проверки. В оптимизированном мире цепочка станет такой: linter (automation) → unit-tests (automation) → robot_review (LLM) → review (human) Иными словами, если мы не хотим погрязнуть в «спаме PR’ов от LLM», нам теперь необходимо «вышибать клин клином»: меч (PR LLM) vs щит (review LLM). На техническом языке это может называться LLM-as-a-judge или LLM/agent review. Пусть тогда ИИ фильтрует вклад ИИ. А вообще, главный риск тут не в перегруженных ревью. Если вклад становится дешёвым, а проверка — дорогой, система постепенно перестаёт отличать осмысленную работу от шума и начинает деградировать. Возможно, мы сейчас как раз в этой точке. Ну давайте честно: ИИ сам по себе тут ни при чём. Молоток не виноват, когда им забивают саморезы. Проблема не в инструменте, а в том, что культура ответственности не успела за скоростью развития технологии. Раньше, чтобы контрибьютить, нужно было хорошенько разобраться. Сейчас этого барьера нет, и выяснилось, что без него часть людей просто не заморачивается. Это не проблема ИИ. Это проблема нас.

Если вам нравится то, что мы пишем здесь, значит, 9 апреля вам есть куда пойти. Вся редакция канала, эксперты Фланта и Э42, собираются в одном месте — на Deckhouse Conf 2026, Москва. А ещё там наверняка будут люди, которые решали те же проблемы, что и вы. Иногда один разговор в перерыве стоит больше, чем часы поисков или звонков в Зуме (или в чём вы там общаетесь сейчас). В программе доклады от тех, кто реально эксплуатирует то, о чём рассказывает. Например: • Путь к SDN: чего не хватает в классической сети Kubernetes Стандартная сетевая модель Kubernetes продумана, но не для всех сценариев. Некоторые она просто не покрывает) Андрей Половов разберёт, где именно классика не справляется и чем это закрывать. • Когда готовое не подходит — делаем своё: control plane для Software-Defined Storage LINSTOR казался разумным выбором, пока команда не собрала все ямы. Александр Зимин расскажет, почему пришлось писать замену с нуля и что из этого вышло. • Налог на безопасность: чем мы платим за защиту Kubernetes и как сделать «налоговый вычет» За защиту контейнерной среды компании платят не только деньгами. Никита Ладошкин из Positive Technologies объяснит, чем именно, и стоит ли оно того. • Как не нужно рисовать дашборды Дашборд, который горит зелёным — это не полноценный мониторинг. Владимир Гурьянов покажет, как делать инструменты, которые реально работают, на основе 8 лет практики нашей команды. Участие бесплатное, трансляции не будет. Приходите, если будете в Москве 9 апреля. Рега обязательна — deckhouseconf.ru

Вспомнили, что не делали пост с выпусками последнего сезона подкаста. Решили исправиться: 55 — DevOps и AI: личный опыт 56 — Свой или готовый K8s? 57 — Не выпускай пет-проекты из дома 58 — Никому не нужное Observability 59 — Что такое DevOps: человек-пароход или культура и подход? 60 — Зачем нам безопасная разработка А вообще все-все выпуски подкаста доступны на сайте, там же можно выбрать удобную для прослушивания площадку. На всякий случай оставим ссылку на наш ВК.

Вспомнили, что не делали пост с выпусками последнего сезона подкаста. Решили исправиться: 55 — DevOps и AI: личный опыт 56 — Свой или готовый K8s? 57 — Не выпускай пет-проекты из дома 58 — Никому не нужное Observability 59 — Что такое DevOps: человек-пароход или культура и подход? 60 — Зачем нам безопасная разработка А вообще все-все выпуски подкаста доступны на сайте, там же можно выбрать удобную для прослушивания площадку. На всякий случай оставим ссылку на наш ВК.

Ревью книги "Solution Architect: архитектура и проектирование ИТ-решений" — взгляд DevOps Deflope Привет! Меня зовут Анатолий, я инженер архитектурных решений из Фланта и часть редакции DevOps Deflope. Прочитал "Solution Architect" и хочу поделиться мыслями. Общее впечатление Книга производит смешанное впечатление: она хорошо структурирована и читается легко, но местами страдает от обобщённости и неравномерной проработки глав. Адресована для широкого круга, джун узнает много нового, мидл и сеньор причешут свои знания. Главная фишка в том, что у неё уклон в сторону облачных архитектур, хотя по названию это не скажешь. Первые главы лучше читать последовательно, потом можно нелинейно. Язык вполне простой и читаемый для российской айти-аудитории. Что зашло • Раздел о паттернах облачной архитектуры — один из лучших. Системное описание подходов к надёжным и масштабируемым системам, понятные схемы и пояснения дают хорошую базу для начинающих архитекторов. • Глава о миграции в облако также сильная. Этапы перехода, риски и способы их минимизации изложены чётко, как практическое руководство. Ссылка на репозиторий с готовыми чек-листами была бы очень полезна. Что не зашло • В части о безопасности автор ссылается на европейские документы, регулирующие проектирование приложений. Ссылки на российские федеральные законы или отраслевые нормативные документы сделали бы материал более полезным даже в виде сносок. • Большинство примеров построено вокруг AWS, что удобно для пользователей этой платформы, но ограничивает аудиторию. В главах с AWS-сервисами на схемах часто не хватает понятных примеров по внедрению, не привязанных к этой экосистеме. • Раздел про архитектуру DevOps слабоват — привычной перевёрнутой восьмёрки (DevOps lifecycle) нигде не увидел. • Ещё момент. "Архитектура решения" звучит как-то не по-русски везде в первых главах. Если сравнивать, есть книжка System Design — там уклон в сторону прохождения интервью и дизайна именно программных решений. В части проработки этой темы она выигрывает, в части архитектурных решений в облаке конечно "Solution Architect" выглядит интереснее. Возможно, было бы круто взять один пример проекта и протащить его по всем главам от корки до корки. Тогда было бы гораздо проще найти прикладное применение паттернам в реальной жизни. Итого "Solution Architect" вполне подойдёт для упорядочивания знаний по облачной архитектуре, но не является ни Библией, ни источником в последней инстанции. Для глубокого погружения лучше дополнить другими материалами. Физическую версию нам прислало издательство «Питер» :) в начало обзора ↑

AI-инференс станет новым двигателем cloud-native. Так считает глава CNCF На мероприятии в честь 10-летия CNCF Джонатан Брайс, исполнительный директор фонда, заявил, что AI-инференс превратит Kubernetes-кластеры в центр притяжения для всей AI-инфраструктуры. Давайте разберём, почему это не просто красивые слова. Логика такая: открытые фундаментальные модели становятся лучше → компании начинают делать на их основе маленькие специализированные модели, заточенные под более узкий круг задач → эти модели нужно где-то запускать → и вот они уже крутятся на инференс-движках поверх Kubernetes-кластеров. То есть куб из «штуки для деплоя микросервисов» превращается в «штуку, на которой живёт AI». И тут начинается самое интересное. Это меняет всю картину для cloud-native проектов. Брайс считает, что AI-агенты постепенно станут основным способом вызова бэкенд-сервисов вместо привычных графических интерфейсов. То есть CNCF-проекты превращаются в headless-сервисы, которые вызывают агенты, а не люди через UI. Но есть нюанс (куда без него). Существующие CI/CD-пайплайны и процессы code review уже не справляются с темпом, который задают AI-инструменты для написания кода. При этом качество этого кода оставляет желать лучшего, что только увеличивает нагрузку на мейнтейнеров Open Source-проектов. Брайс использовал термин «Eternal September» — как поток первокурсников, которые каждую осень приходят в универ и не знают вообще ничего о процессах. Только здесь этот поток не заканчивается. В итоге получается, что AI генерирует больше кода, чем люди успевают ревьюить, а качество этого кода... ну, скажем так, оставляет простор для роста. При этом роль инженера никуда не исчезает, а трансформируется в сторону platform engineering. Люди будут отвечать за архитектуру и качество, а агенты возьмут на себя рутину. CNCF сейчас курирует больше 240 проектов. Какие из них останутся актуальными в эпоху AI — пока открытый вопрос. Интересные времена, короче. А вы уже думаете о том, как ваш стек будет выглядеть, когда основным «пользователем» ваших сервисов станет агент, а не человек? Источник: cloudnativenow.com

Ну что, с возвращением! Мы в январе притворялись, что отдыхаем (спойлер: не получилось), и запилили вам сайт: devopsdeflope.ru Внутри — новый сезон подкаста и архив старых выпусков (да-да, те самые легендарные). Можно выбрать площадку для прослушивания, которая вам удобна, — «Яндекс Музыка», Spotify, Apple Podcasts, VK. Всё в одном месте. Заходите, смотрите. И да, если найдёте баги — пишите, допилим.

2025 год был... интересным. AI прилетел во все возможные продукты (и невозможные тоже), Kubernetes продолжал внедряться в работу с завидной настойчивостью, а количество инструментов для мониторинга выросло настолько, что теперь нужен мониторинг для мониторинга мониторинга. Вы весь год тушили пожары в production, разбирались с упавшими подами в 3 часа ночи, оптимизировали то, что «и так работает», и объясняли разработчикам, почему нельзя просто «добавить больше памяти». И знаете что? Вы молодцы. Серьёзно. Что мы вам желаем на 2026 год: • Чтобы ваши дашборды всегда были зелёными. Ну или хотя бы желтыми. Красный — только для новогодних украшений. • Чтобы CI/CD pipeline не падал, ни до merge, ни после. Потому что находить баги в production — это не та адреналиновая активность, которую мы выбирали. • Чтобы документация была актуальной. Комментарий здесь мы даже не смогли придумать. • Чтобы технический долг рос медленнее, чем зарплата. Хотя бы процентов на 10. Желаем вам классных проектов, где можно применить то, что давно хотелось попробовать. Спасибо, что читаете нас. P.S. Не забудьте проверить бэкапы перед праздниками. Нет, серьёзно. Проверьте. — Редакция

Когда игровой планировщик оказался лучше для серверов Meta Meta запустила на своих production-серверах планировщик SCX-LAVD. Казалось бы, ну планировщик и планировщик. Но фишка в том, что его изначально разрабатывали для портативной игровой консоли Valve Steam Deck. То есть штука для карманного девайса теперь управляет дата-центрами одной из крупнейших IT-компаний мира. SCX-LAVD — планировщик с учётом критичности задержек. Его создала консалтинговая компания Igalia по контракту с Valve специально для Steam Deck. Инженеры Meta решили протестировать его на больших серверах. Результат оказался настолько хорошим, что Meta сделала SCX_LAVD планировщиком по умолчанию для своего парка серверов, который работает с различным оборудованием и сценариями использования. Оказалось, что даже на серверах с большим количеством CPU и памяти, LAVD прекрасно справляется с балансировкой нагрузки между CCX/LLC. На конференции Linux Plumbers Conference в Токио инженеры Meta выступили с презентацией «Как заставить планировщик Steam Deck работать на больших серверах». История показывает важный принцип в инфраструктурной разработке — не стоит сразу отметать решения из-за их происхождения. То, что планировщик создавался для игровой консоли, не делает его автоматически непригодным для серверов :) Оптимизация под низкие задержки и эффективное распределение нагрузки — универсальные задачи, независимо от масштаба железа. Возможно, стоит чаще смотреть на решения из смежных областей, а не только на классические enterprise-инструменты. Иногда лучший инструмент приходит оттуда, откуда его совсем не ждали. Источник: phoronix.com

Kuber Conf уже завтра, но вы успеваете запрыгнуть. Смотрите, программа там реально насыщенная. Мы пробежались по докладам и выбрали то, что зашло: • Как мы строили платформу деплоя в Т. Послушаем про опыт построения универсальной платформы деплоя на базе OAM и KubeVela. Основная идея — вынести сложность конфигурации инфраструктуры и взаимодействия с Kubernetes на сторону платформы, а разработчикам дать простой и удобный интерфейс для описания приложений. Отдельный плюс: платформа берёт на себя вопросы EoL и миграций, снижая необходимость в бесконечных согласованиях и ручных договорённостях с командами. • Vitastor и Kubernetes: есть ли жизнь на Марсе. Посмотрим, как интегрировать распределённую СХД через CSI и что там с производительностью в реальных условиях. • Обучаем LLM по клику: платформа распределённого обучения на HGX. Доклад про то, как в Avito строили MLOps-инфраструктуру для обучения LLM на множестве узлов в рамках платформы Aviflow. Нам расскажут, чем обучение LLM отличается от «обычного» ML, какие технологии нужны для распределённого обучения, и как обернуть это в удобный сценарий. А также и о самом железе (HGX), и его нюансах эксплуатации. Ещё два доклада будут от нас: • А вы точно уверены в SLA своего кластера Kubernetes? Владимир Гурьянов из Deckhouse Observability разберёт, почему метрики в состоянии покоя не показывают реальную картину и как правильно тестировать доступность кластера. Плюс практический чеклист для измерения SLA. • Не Talos единым: как ограничения научили нас ставить Kubernetes поверх любой операционной системы. Денис Романенко из Deckhouse Core покажет, как автоматизировать развёртывание Kubernetes поверх любой ОС, когда современные K8s-дистрибутивы недоступны или не подходят. Днём слушаем доклады, вечером общаемся на афтерпати. Конфа уже послезавтра, наша редакция тоже там будет. Кстати, организаторы дали нам промокод на 20% для друзей канала: KUBERCONF20 Регистрация тут.

Нельзя так просто взять и спарсить 150 тысяч вакансий… Или можно? Можно. Именно это сделал автор проекта TrueIndex, чтобы составить альтернативный TIOBE рейтинг, который показывал бы картину спроса на технологии в России. Проблема того же TIOBE в том, что он считает поисковые запросы в Google. Люди могут искать что угодно из любопытства, для учёбы, для решения legacy-проблем. Но это не показывает, что реально нужно работодателям прямо сейчас. TrueIndex пошёл от обратного и взял не запросы, а вакансии. Парсер собирает данные с HeadHunter и Habr Career, анализируя сотни тысяч объявлений. На их основе он считает статистику по языкам, фреймворкам, базам данных и другим технологиям, которые упоминаются в требованиях. Первый же срез данных показал неожиданную картину. Технологии, специфичные для российского рынка (например, 1С), оказываются в топе по спросу, хотя в TIOBE их вообще нет, потому что за границей о них не знают. Языки, которые все считают устаревшими, спокойно держатся в топ-10 по количеству вакансий. А что-то вроде Fortran и Assembly из международных рейтингов в массовом найме практически не встречается. Сейчас TrueIndex собирает данные с HeadHunter и Habr Career, ежемесячно обновляет рейтинг и постепенно расширяет набор метрик. Зачем это всё? Если ты джун, рейтинг помогает увидеть, какие технологии дают больше всего «входных билетов» в профессию и где спрос не ограничивается одиночными вакансиями. Если ты мидл или сеньор — это удобный способ понять, в какой стек имеет смысл вкладываться, чтобы оставаться востребованным на российском рынке. Ну а дальше можно просто зайти на trueindex.ru и посмотреть на актуальный рейтинг своими глазами.

ConfigHub официально запустился — это стартап от Brian Grant (оригинальный архитектор Kubernetes), Alexis Richardson (основатель RabbitMQ и Weaveworks) и Jesper Joergensen (бывший продуктовый лид Heroku и топ Twilio). Летом 2024 они были в режиме стелса и только набирали команду, теперь вышли с готовым продуктом. Проблема, за которую они взялись: управление конфигурациями в облачных системах превратилось в хаос. Настройки разбросаны по десяткам мест от Git-репозиториев и YAML-файлов до облачных сервисов и систем управления секретами. Чем больше мест, где всё это хранится, тем выше риск что-то сломать при изменениях. ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе. Продукт уже работает для пользователей Kubernetes, Helm и GitOps. Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит. Источник — пост Alexis Richardson на LinkedIn.