DevOps *

v1.1.0: убрали HTTP-костыль для sink’ов, закрыли /metrics, Teams в UI, trusted clusters. Про v1.0.3 и типичный «pairing failed» на Docker — внутри. Продолжение серии.

Надоело каждое утро вручную обходить 5+ площадок — написал агрегатор на Python. Собирает вакансии с HH, Habr Career, GeekJob и Telegram-каналов, убирает дубли, присылает в Telegram. Код открытый.

Практический dev-story о том, почему AI-агент для реальной работы - это не чат с моделью, а система из задач, браузеров, проверок, журналов, ограничений и внешних интеграций. На примере публикационного пайплайна: сайты, CMS, соцсети, cron, browser sessions, anti-false-success, CRM, нейросеть, видео контент и SEO-грабли. От настройки до практического применения.

В последнее время становится все более популярным локальный запуск LLM. У каждогг свои причины, но основные это: проблемы с западными сервисами, нестабильный интернет и утечка данных в открытый доступ (преценденты уже были).

В этой статье я расскажу как запускал LLM локально на майнинговом железе, какие тонкости есть при запуске. Расскажу архитектуру моей сборки и примерную стоимость железа. Также протестирую скорость работы с некоторыми наиболее популярными MoE LLM, включая модели от гугла и ChatGPT. По поводу целесообразности подобных сборок решение каждый примет сам исходя из своих задач и финансовых ресурсов.

Команда VK Cloud перевела разбор запуска self-hosted (размещаемого на собственных мощностях), read-only ИИ-агента внутри кластера Kubernetes, где всю цепочку CI/CD обслуживают GitHub Actions и Argo CD Image Updater. Никакие данные не покидают кластер, облачные ИИ-провайдеры не задействованы.

Серия: redb ecosystem / redb.Route redb.Tsak

Есть у интеграционного кода одна неприятная особенность. Написать пару маршрутов — «принял HTTP, положил в базу, отдал обратно» — дело на полчаса. А вот довести это до состояния, когда оно крутится в проде, само поднимается, показывает метрики, умеет останавливать/запускать отдельные куски руками и разворачивается без пересборки — это обычно совсем другая история и совсем другой стек.

В этой статье я покажу, что в связке redb.Route + redb.Tsak это буквально один и тот же код. Мы:

Проблема
Мне как бэкэнд-разработчику приходится работать с деплоем своих проектов, каждый раз одна и та же рутина: настройка сервера, nginx, ssl, безопасность сервера(fail2ban, user), CD и многое другое. Это отнимает очень много времени.

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

Когда серверы bare-metal, гипервизоры, облачные решения и десятки Kubernetes-кластеров живут вместе, навести порядок в ИТ-инфраструктуре становится задачей со звёздочкой. К тому же к гибридной инфраструктуре добавляется организационный слой: десятки автономных команд — backend, UI, data engineering, ML, platform — и у каждой свой бэкграунд, уровень зрелости и разный подход к описанию инфраструктуры через код (IaC).

Кто-то всегда пишет на HCL, кто-то предпочитает Python и JS, а кто-то привык работать с docker compose up –d. Задача инженера платформы в такой обстановке не в том, чтобы навязать «серебряную пулю», а в том, чтобы найти инструмент, который обеспечит контроль над состоянием инфраструктуры, позволит стандартизировать базовые паттерны, предсказуемо реагировать на изменения, которые внесли вручную, а еще не будет ломать уже существующие процессы.

Привет, Хабр! Меня зовут Вячеслав Швецов, я архитектор в команде MWS B2B Store. Это первый материал из цикла о построении инженерной платформы в гетерогенной среде. Мы будем разбирать инструменты, антипаттерны и ограничения при эксплуатации. В этом выпуске сравним подходы Terraform и Pulumi, а также рассмотрим управление состоянием, детекцию дрейфа инфраструктуры и практику управления инфраструктурой как кодом.

Представьте ситуацию: вы приходите к руководству с четким техническим обоснованием миграции в облако: оборудование устаревает, вычислительных мощностей не хватает, риски простоев растут. Рассказываете, как облако поможет быстрее запускать новые сервисы, масштабировать инфраструктуру и снизить нагрузку на команду. А в ответ слышите: «Бюджет не согласован. Живите с тем, что есть».

Знакомая ситуация? Проблема не в качестве ваших аргументов. Проблема в том, что ИТ и бизнес говорят на разных языках. Вы говорите на языке технологий, а CFO – на языке финансов. У вас даже KPI разные: для вас важны аптайм, время восстановления, скорость развертывания сред, в то время как для финансового директора – только деньги.

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

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

Всем привет! Это первая публикация из цикла статей про распределение сервисов в кластере виртуализации. В статье будет описан один из подходов к решению задачи от определения проблемы до результатов тестов с демонстрацией работы готового решения.

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

Привет, Хабр! Меня зовут Никита Трунов, я — разработчик команды инфраструктурных сервисов K2 Cloud. Сегодня расскажу вам о нашем новом облачном сервисе управления ключами KMS и как он помогает с шифрованием данных в облаке. В этом материале мы разберемся, какие данные приходится защищать, какие существуют модели доверия к облачному провайдеру и как устроена архитектура современного сервиса управления ключами.

Привет, Habr! Меня зовут Валентин, я DevOps-инженер команды Platform V Kintsugi. Мы занимаемся развитием облачного сервиса и на практике регулярно сталкиваемся как с архитектурными задачами построения распределённых систем, так и с вопросами обеспечения их безопасности.

В предыдущей части мы подробно разобрали механизм делегирования TLS-соединения на уровень Service Mesh и показали, как Egress Gateway может выступать полноценным участником PostgreSQL handshake. Однако этот сценарий рассматривался в упрощённой конфигурации — один сервис, один сертификат, одно подключение.

Думаю начну с начала. Я занимаюсь разработкой одного артхаузного проекта с названием "Attempt to Survive" и работая над ним , имел одну важную цель. Сделать высокую оптимизацию для работы со многими старыми системами, с устаревшим железом на текущие реалии. При этом имея достойную картинку.

Для этого даже сделал небольшую сборку тестового пк с i7 6700k процом, картой gtx950 8 гигами оперы и материнкой с соответстующим сокетом. Многое уже имел от старого железа в коробках, так что собрать сложности не было.

«У нас тридцать два кластера». Руководитель команды platform engineering произнес это как на исповеди. Тридцать два. В компании с девятью продуктовыми командами. По шесть окружений на каждую. Никто не планировал такого — оно просто росло по одному кластеру за раз, каждый раз, когда команде требовалось что-то чуть иное, а самым простым ответом было «подними новый».

Я слышала ту или иную версию этой фразы почти в каждой компании, достигшей определенного размера. Цифра меняется — иногда двенадцать, иногда шестьдесят, — но динамика всегда одна. Kubernetes легко позволяет создавать кластеры, никто намеренно не решал, когда их использовать совместно, а когда нет, и в какой-то момент кто-то смотрит на счет за облако и ротацию дежурств — и понимает, что управление десятками кластеров медленно пожирает платформенную команду заживо.

Multitenancy — ответ на эту проблему. Kubernetes не был спроектирован для multitenancy из коробки, и, чтобы построить его правильно, требуются реальные инженерные инвестиции, но именно так зрелые команды platform engineering решают эту задачу в 2026 году — со все более удобным инструментарием и все лучше понятыми паттернами.

Команда VK Cloud перевела статью, охватывающую все, что автор узнал о Kubernetes multitenancy в нескольких продакшен-окружениях: какие модели существуют, где каждая из них дает сбой, как выстроить слои изоляции, которые действительно защищают тенантов друг от друга, какие инструменты стоят вашего времени и как выглядит хорошо управляемый общий кластер на практике.

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

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

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

Классическая ловушка при проектировании отказоустойчивости — разрыв между ожиданиями бизнеса и возможностями инфраструктуры. На бумаге в SLA может быть зафиксировано RTO в 4 часа, но если терабайтный бэкап PostgreSQL физически разворачивается 8 часов из-за лимитов дисковой подсистемы, такой SLA не выдержит первого серьезного инцидента.

На практике планы Disaster Recovery (DR) часто пишутся «для галочки» и в полном отрыве от реальной архитектуры. Под катом — техническая изнанка проектирования отказоустойчивости: как приземлить RTO и RPO на реальную инфраструктуру, связать их со стоимостью простоя и взять эти метрики под контроль с помощью правильных инженерных подходов. Также в статью включены практические инструменты: пошаговый чек-лист для безопасного проведения DR-учений и перечень ключевых параметров, которые необходимо непрерывно мониторить для контроля рисков.

Доменные имена не резолвятся, страницы висят, а по IP всё доступно. В логах DNS‑сервера при этом чисто, BIND запущен, конфигурация на первый взгляд выглядит рабочей.

Разбираемся, как одна ошибка в forwarders может отправить DNS‑запросы по кругу и превратить обычный резолвинг в цепочку таймаутов.

TL;DR. Я выбирал Timeweb не из-за цены, а из-за «имени» и обещанной надёжности. За май–июнь 2026 года зона ams-1 (Амстердам, дата-центр Qupra) пережила шесть крупных аварий с суммарным окном недоступности около 46 часов — причём последняя авария на момент написания этих строк всё ещё не закрыта и идёт уже более 15 часов. Хостер на своём сайте обещает Tier III и аптайм 99,98 % — это 1 час 45 минут простоя в год. За два месяца факт превысил годовой лимит этого обещания примерно в 26 раз. Все цифры ниже — не мои домыслы и не «жалобы в чате», а сообщения из официального канала статусов самого Timeweb.

Когда сверху прилетает задачка запустить FinOps, чаще всего она звучит так, как будто речь идет про кнопку. Нажал - и косты порезались сами собой, инженеры в тот же миг стали гипер-ответственными, а финансы перестали дышать в затылок. Вот только никакой кнопки, само собой, нет. Есть только точка ноль - тот самый момент, когда ты сидишь с этой задачей и тупо не знаешь, с какой стороны вообще подходить к ее решению.

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

Кстати, все это мы в свое время обсуждали (да и сейчас продолжаем) в канале Практики FinOps в Telegram. Там сидят те, кто проходил этот путь раньше, - иногда один вопрос в чате экономит неделю собственных экспериментов. Залетайте, если тоже на старте.