DevOps *

Представьте: вы работаете в крупной компании с федеральной сетью. У вас более 300 баз данных Microsoft SQL Server, сотни тысяч объектов — таблиц, процедур, функций, триггеров. Значительная часть бизнес-логики реализована с использованием cross-database references и распределённых запросов через linked servers, что создаёт сложные зависимости между объектами на разных базах и даже серверах.

А теперь представьте, что все изменения в схему вносятся напрямую в production — через SSMS, без версионирования, без ревью, без возможности отката.

Звучит как кошмар? Но именно так работала наша команда более 10 лет.
«Так исторически сложилось» — и это было нормой. Такой подход неизбежно порождал инциденты: от локальных нарушений целостности данных до масштабных простоев, напрямую влияющих на выручку и репутацию компании.

Мы поняли: нужно внедрять CI/CD. Но главная проблема оказалась не в технологиях — а в людях.

Для меня tmux - это не просто терминальный мультиплексор, это центр моей консоли: чтобы я не намеревался сделать - открытие новой панели будет моей стартовой точкой, особенно когда дело касается Kubernetes.

И вот однажды, в момент очередного использования kubectl config current-context появилась идея - "а не научить ли tmux показывать мой контекст?"

Так появился небольшой tmux-плагинчик, а так же сама эта статья, в которой я покажу и расскажу как это просто - написать плагин для tmux, надеюсь будет увлекательно.

Мой мозг работает не так, как у большинства. Он не сломан — он просто собран по другой схеме. Годы на стимуляторах перепрошили нейронные связи. Теперь, чтобы функционировать в "нормальном" режиме, приходится принимать седативы. Парадокс: успокоители — чтобы думать. Потому что без них мысли несутся со скоростью, которую невозможно контролировать.

Если верить вакансиям, DevOps — это человек-оркестр: он пишет пайплайны, чинит Kubernetes, настраивает облака, знает Linux на уровне ядра, умеет в безопасность, автоматизацию, мониторинг и, на всякий случай, может заменить бэкендера, когда тот ушёл в отпуск. Желательно за зарплату джуна и с готовностью выходить на алерты в три часа ночи. Реальность, к счастью, чуть менее драматична. Но и чуть более сложна, чем рассказывают на вводных курсах (привет тем, кто решился вкатится по быстрому). В этой статье разберёмся, кто такой DevOps на самом деле, почему от него действительно ждут «всего и сразу» и где заканчивается адекватное ожидание, и начинается фантазия работодателя.

Введение в использование Docker для автоматизированного тестирования программного обеспечения. Статья объясняет, как контейнеризация помогает упростить создание изолированных тестовых сред, устранить проблемы с несовместимостью окружений и ускорить процесс тестирования.

10 лет назад мы запустили проект под названием dapp. Сегодня он известен как werf. За это время — тысячи коммитов, сотни релизов, переход на Go, Helm, CNCF, Nelm…

Собрали всю историю в одной статье — от первого Ruby-скрипта до экосистемы Open Source-инструментов.

Цель статьи: Показать на практическом примере, как использовать один Load Balancer для приёма TLS-соединений и маршрутизации бинарного трафика к разным backend‑приложениям с терминацией (расшифровкой) TLS на Gateway — например, к Redis и другим TCP‑сервисам.

Как это работает:

Как я построил систему мониторинга LLM-приложений и научил AI анализировать собственные ошибки

AI-ассистенты в IDE стали незаменимыми помощниками разработчиков, но остаются чёрными ящиками. Мы не видим что они делают "под капотом", сколько это стоит и где теряется время. В статье покажу как построить системуobservability для AI-агентов: от Cursor IDE до production, с AI-анализом трейсов и открытым исходным кодом.

Когда заходит речь о запуске виртуальных машин в Kubernetes через KubeVirt, первый вопрос, который возникает у инженеров: «А какой там оверхед?» Давайте разберём этот вопрос детально, рассмотрев каждую подсистему отдельно: вычисления, хранилище и сеть.

Статья основана на обсуждении в профессиональном сообществе.

Разбираем, что такое PNETLab, как он работает и чем отличается от других сетевых эмуляторов. Простое объяснение для инженеров, администраторов и студентов.

Современные комплексы бизнес-приложений отличаются высокой сложностью, из-за чего могут происходить сбои - сообщения теряются, consumer’ы падают, очереди переполняются. Поделимся реальным кейсом, в котором Eventual Consistency удалось обеспечить без серьезной переработки существующих систем.

Обеспечение Eventual Consistency в сложных системах

Уже давно стандартом де-факто стали микросервисы, поэтому практически любая система представляет собой набор компонентов, взаимодействующих между собой как синхронно (например, по REST), так и асинхронно — через шины сообщений (RabbitMQ, Kafka).

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

Где именно все может сломаться

Предположим, у нас две системы:

В выпуске CrossCheck обсуждали безопасную разработку, DevSecOps и то, почему внезапно все заговорили про контейнеры, секреты и «свои базовые образы».

Привет, Хабр! Импортозамещение в ИТ — это не просто смена вендоров или технологий. Это сложнейшая хирургическая операция на живом организме бизнес-процессов компании. Привет, Хабр! Я Станислав Тульчинский, руководитель блока кредитного корпоративного бизнеса РСХБ.Цифра. В этой статье расскажу про наш проект по замене информационной системы управления жизненным циклом залогов и договоров залога (и это не одно и тоже) по кредитам юридических лиц в банке.

Стандартный мониторинг часто пропускает «тихих убийц» — запросы, которые по отдельности кажутся нормальными, но в сумме создают аномальную нагрузку на СУБД. В итоге система живет в хрупкой идиллии до первого аврала.

В статье — описание универсального способа контроля качества кода и нагрузки на базу без выделенного DBA. Пошагово разберем поиск неоптимальных запросов с помощью pgBadger на живом кейсе.

Нагрузочный тест показывает «в среднем 800 мс», а распределённый трейс приложения упорно говорит «300 мс» — и начинается традиционная игра в ручную корреляцию. В этой статье разбираем, как связать нагрузку и наблюдаемость: запускать Locust с OpenTelemetry так, чтобы каждый запрос теста оставлял трейсы и метрики, продолжал Trace ID в сервисах и давал картину транзакции «от генератора до базы». А заодно, почему самый важный кусок времени часто прячется ещё до входа в приложение.

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

В инфраструктурных задачах этот «парадокс посудомойки» преследует нас постоянно. Когда нужно мигрировать пару виртуальных машин, инженеру проще и быстрее сделать всё руками, чем настраивать сложные паплайны. Но сегодня, на фоне массового импортозамещения, смены гипервизоров (привет, VMware!) и курса на построение гибридных сред, масштаб задач изменился. В условиях миграции сотен ВМ привычка полагаться на ручной труд становится непозволительной роскошью.

В идеальном мире миграция — это «черный ящик»: нажал кнопку, и всё переехало. Но в условиях фрагментированного отечественного рынка виртуализации мы сталкиваемся с разной степенью зрелости API. Под катом попробуем разобраться, как устроены решения для миграции и какие функции берет на себя агент на стороне-приемнике.

Управление жизненным циклом узлов в Kubernetes легко превращается в марафон ручной настройки — от подготовки окружения в облачных сетапах до регулярного обновления скриптов и корректного удаления узлов. В Deckhouse Kubernetes Platform мы автоматизировали этот процесс, и неважно, работаете вы в облаке или в собственном дата-центре.

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

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

Хватит воевать с Makefile: как я написал свой таск-раннер на Rust

Устали от табов, .PHONY и bash-лапши? Я тоже. Поэтому написал Nest — декларативный таск-раннер с иерархией, типами и понятным синтаксисом. Рассказываю, как это было и почему вам стоит попробовать.

Привет, Хабр!

Каждый человек рано или поздно сталкивается с выбором, какой ingress‑контроллер использовать для маршрутизации трафика. Помнится, раньше многие думали, что достаточно взять Nginx и не париться. Но реальность, как это обычно бывает, сложнее. Есть по меньшей мере три мощных игрока: NGINX, Traefik и HAProxy. И у каждого свои фичи и проблема.