DevOps *

Когда серверы 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. Там сидят те, кто проходил этот путь раньше, - иногда один вопрос в чате экономит неделю собственных экспериментов. Залетайте, если тоже на старте.

Привет, Хаброжители! Сегодня мы поделимся с вами отрывком из книги: «Современная бизнес‑аналитика. Увеличьте ценность данных с помощью Python и R».

Статья посвящена ModelOps — набору практик для эффективного развертывания и эксплуатации моделей машинного обучения. Вы узнаете, как организовать полный жизненный цикл модели: от оценки и мониторинга до переобучения. В материале приведены практические примеры создания приложений для пакетной и онлайн‑оценки с помощью R Shiny и Python Streamlit, а также дашборда для мониторинга производительности в реальном времени.

При работе с Apache Kafka рано или поздно возникает необходимость быстро проверить топик, прочитать сообщения или посмотреть состояние группы потребителей (consumer group). Можно применять стандартные инструменты Kafka. Однако на практике они часто оказываются не самыми удобными для повседневной работы. Многие команды получаются длинными, каждый раз требуют передачи параметров подключения и нуждаются в различных CLI-утилитах.

Есть и более легкие решения — например, kcat, который хорошо знаком многим инженерам и часто используется для диагностики Kafka. Но существует и вариант поудобнее — kafkactl.

Привет, Хабр! Меня зовут Сергей Кардапольцев, я технический писатель в Selectel. В этой статье мы познакомимся с kafkactl — CLI-инструментом для работы с Kafka. Посмотрим, чем он отличается от стандартных Kafka-утилит и kcat, а также разберем базовые сценарии работы на примере кластера.

Миграция — риск даже для небольших инфраструктур. А когда у вас больше миллиарда пользователей и петабайт данных, права на ошибку нет вообще. Но выход всё равно один — грамотно спланировать переезд и... взять и сделать.

В статье — о том, как Reddit перешёл на Kubernetes: почему они отказались от Amazon EC2, какие ограничения им пришлось учитывать и чем их опыт может быть полезен в других проектах.

Достаточно часто приходится проводить интервью на должность разработчика, технического лидера проекта. Обязательной частью интервью является валидировать понимание работы с распределенными событийными моделями. Тут начинается аномалия. Не смотря на то, что все кандидаты заявляют об опыте с Kafka, многие теряются в рассуждениях на тему что это и как организовано.

Для того, чтобы коллегам было комфортнее на техническом интервью, а так же для желающих понять работу Kafka без Zookeper предлагаю статью. Понимаю, что мы все не любим длинные тексты, поэтому вложил максимум деталей в схемы и краткие формулировки.

Александр Либкинд, руководитель направления развития сервисов управления затратами и эксперт Практики FinOps, поделился материалом о том, почему ручная инвентаризация инфраструктуры редко приводит к устойчивой экономии и как перейти от разовых проверок к управляемой модели.

Поводом могут быть GPU-инстансы, тестовые окружения, неиспользуемые диски, свободные IP-адреса или любые другие ресурсы, которые продолжают потреблять бюджет после завершения задачи. Но проблема почти всегда шире, чем один тип инфраструктуры.

Если у ресурса нет владельца, команды, среды и приложения, компания не управляет затратами. Она просто периодически пытается разобраться, что можно отключить без последствий.

Две недели назад я отдал разработку живого продукта автономному ИИ-пайплайну: люди пишут в бота «что поменять», а код пишется, тестируется, ревьюится и выкатывается в прод без единого человеческого взгляда на дифф.

Итог двух недель: 178 релизов, 1.4 млрд токенов, 0 строк кода, прочитанных человеком перед мержем. И неожиданный вывод — я не перестал быть программистом, а стал кем-то вроде бухгалтера, который отложил счёты и осваивает Excel.

Я поставил череду экспериментов: по очереди убирал куски «обвязки» вокруг модели и смотрел, что сломается. Один эксперимент чуть не похоронил репозиторий за одну задачу: +25 зависимостей и +6000 строк на ровном месте. Рассказываю, что выяснилось.

Привет, Хабр! Меня зовут Максим Теплых, эксперт по тестированию на проникновение в ИТ-компании Innostage. В этой статье я хочу рассмотреть тему, которая с годами становится все более актуальной — тестирование систем, использующих ГОСТ TLS. Кратко расскажу о самой технологии, а также покажу подходы и наработки, которые применяем на практике. 

Заранее приношу извинения за объемное и несколько затянутое введение. Хотя изложение начинается не с динозавров и не с истории древней Руси, тему все же необходимо раскрыть с некоторой предыстории.