DevOps *

В конце октября 2025 Anysphere представила Cursor 2.0 — крупное обновление AI-IDE с параллельными агентами и новой моделью Composer. Идея проста: вы ставите цели, а агенты пишут и проверяют код, тестируют и готовят диффы, а разработчик смещается к роли менеджера ИИ-процесса. В статье разбираемся, что именно появилось, на чем это работает и какие ограничения важно учесть.

Здравствуйте, меня зовут Юрий Юшкевич, я руководитель ИТ-разработки/CTO. В этой статье я расскажу о процессе замены APM-решения в крупной финтех-компании: почему мы ушли с Instana, как выбирали альтернативу и что изменилось после внедрения Proto Observability Platform.

Концепция “Инфраструктура как код” (IaC) стала неотъемлемой частью методологии DevOps. С помощью IaC мы можем без труда развернуть в облаке нужную инфраструктуру. При этом, мы можем развернуть абсолютно идентичные инфраструктуры как для среды разработки, так и для тестирования и для продуктивной среды.

На просторах сети можно встретить большое количество публикаций, посвященных использованию «иностранных» облаков, таких как Amazon, Google и Microsoft. Однако, в текущих условиях использование данных провайдеров практически невозможно. Между тем на российском рынке также есть много интересных игроков. В рамках данной статьи мы посмотрим использование Яндекс Облака. Но для начала давайте разберемся с тем как в принципе реализуется IaC.

Когда в вашем ИТ-ландшафте есть «маленькая шлюпка», представляющая собой один контейнер, — это понятная и легко управляемая история. Если же речь идет о «Титанике», множестве контейнеров, то все уже не так просто, как хотелось бы.  Когда же вы вырастаете до целой флотилии, где каждый корабль — это отдельный кластер Kubernetes, то здесь возникают нюансы.

В статье я поделюсь опытом, как подойти к этой проблеме системно: внедрить DevOps as a Service так, чтобы он стал не «еще одной модной практикой», а реально работающим сервисом внутри enterprise. Разберем, какие сложности чаще всего встречаются на пути, какие метрики помогают понять, что вы движетесь правильно, и как справляться с сопротивлением команд.

Мониторинг процессов на сервере — ключевой элемент для безопасности и стабильности работы всей системы. Даже если на сервере всего несколько процессов, бывает очень критично вовремя узнавать об их сбоях и недоступности, чтобы своевременно восстановить доступ. Для автоматического отслеживания удобно использовать специализированный под эти задачи сервис, такой как Monit — лёгкий, но при этом мощный инструмент, позволяющий не только отслеживать работу процессов (например, nginx, apache, mysql, postgres, redis, node, java) и перезапускать их автоматически, но и направлять уведомления об этом (например, в Telegram).

Новая версия Debian 13 и релиз Proxmox VE 9.0 пришли почти одновременно, вызвав ажиотаж у клиентов. В статье рассказываем, как команда HOSTKEY адаптировала свои процессы, автоматизировала деплой и подготовила инфраструктуру под свежие релизы.

При работе с распределенными хранилищами на базе Ceph иногда возникает необходимость временно или окончательно исключить узел из кластера. Это может понадобиться при обновлении оборудования, обслуживании инфраструктуры или перераспределении ресурсов. Вместе с тем если узел, подлежащий выводу, одновременно исполняет роли MON (Monitor), MGR (Manager Daemon) и MDS (Metadata Server), задача превращается в настоящий квест hard-уровня. Но при должном подходе и с такими кейсами можно справиться. 

Меня зовут Алексей Косов. Я старший инженер доступности отдела интеграции и сопровождения облачных решений в команде VK Tech. СХД Ceph — это часть поставки нашего продукта для построения частного облака в ЦОДе заказчика VK Private Cloud. В этой статье я пошагово покажу, как можно вывести узел с полным комплектом сервисов Ceph из кластера, чтобы кластер и остальные узлы не пострадали.

Привет, коллеги! Год продолжает радовать нас мощными апдейтами!) Делимся подборкой самого интересного, что случилось в мире DevOps-инструментов недавно.

Динамическое обновление ресурсов Pod и Kubernetes

Одна из самых крутых фич, которая стала стабильной в Kubernetes 1.33, - это возможность изменять запросы и лимиты CPU/памяти у работающих подов без их перезапуска.

БигДата всегда звучит красиво — пока не нужно по ним искать и за нее платить.

Когда данные перестают влезать в индекс, а поиск тормозит — дело не в БД, а в архитектуре.Рассказываю, как мы перестроили систему на связке PostGIS + OpenSearch и добились отклика в десятки миллисекунд.

Началось все весьма прозаично, клиент позвонить к нам в техподдержку и спросил «а как бы мне поставить ваш софт но в другую схему БД». Собственно вопрос проще некуда — мы писали на спринге, а значит лезем в application.yml и ставим схему. Но, клиент не из тупых и уже это попробовал — не сработало.

Начинаем разбираться что сломалось и кто виноват. Первым делом ДевОпс повторяет кульбиты клиента и выдает простой вердикт: «В 151 миграции лажа». Я открываю и: «батюшки родный, да это же лосенок явное указание схемы!»

Я уволился из своей первой работы SRE‑инженером после особенно тяжелой недели дежурства. Семь ночей подряд я просыпался от PagerDuty. Семь ночей подряд я чинил одну и ту же проблему с памятью, которую никто не хотел исправлять «по‑настоящему», потому что «горячий фикс же работает». На восьмое утро я пришел в офис и положил заявление на стол.

Это было пять лет назад. С тех пор я прошел через четыре компании, построил on‑call процессы с нуля в двух из них, и научился главному: дежурства не должны убивать людей. Физически и морально. Давайте поговорим о том, как построить on‑call ротацию, которая не приведет к массовым увольнениям.

Помню, как на собеседовании в одну крупную компанию мне задали вопрос: "Чем отличается observability от monitoring?" Я уверенно ответил что-то про "три столпа" и "unknown unknowns". Интервьюер кивнул, но потом спросил: "А зачем платить $100k в год за Datadog, если можно поставить бесплатный Prometheus?"

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

Знаете, что я делал вчера с 10 до 12 утра? Деплоил новую версию на production. Вручную. На 15 серверов. По SSH. В 2024 году. И это не самое грустное. Самое грустное — что я делаю это каждую неделю. И каждый раз обещаю себе, что вот на следующей неделе точно автоматизирую. Но следующая неделя наступает, и я снова сижу и копипащу команды в терминал.

Если вы узнали себя — добро пожаловать в клуб анонимных toil-оголиков. Давайте поговорим о том, почему мы все еще делаем руками то, что должны были автоматизировать еще вчера.

Всем привет! Я Алексей Босенко, DevOps-инженер в компании KTS. В этой статье я покажу, как комплексно настроить быструю и эффективную сборку проектов в Kubernetes с использованием BuildKit, которая учитывает не только производительность, но и стоимость ресурсов.

Под этой громкой фразой я подразумеваю целый комплекс решений: как создать и настроить экономичный кластер Kubernetes для сборок (ведь цена вопроса всегда важна), как настроить GitLab Runners и как сделать эффективное масштабирование сборок. Особый акцент будет на том, почему мы выбрали BuildKit, какие варианты использования он предлагает, и как непосредственно настроить один из них.

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

Истории из нашей практики: разные подходы к организации инфраструктуры и процессов DevOps. Первая статья из серии.

Кхм. Громковатый заголовок, но я всё объясню.

Итак, у меня был сервис. Обычная молотилка данных, каждый с такой хотя бы раз да сталкивался - что-то на входе, что-то на выходе, а внутри походы в базу, HTTP-вызовы, шаблоны, скриптовая логика... В общем, много всякого.

Ну, ладно, тут стоит сразу уточнить, что сервис с особенностями - молотилка данных устроена так, что пытается работать с разными форматами на входе и выходе, а внутри держать всё в одном представлении. Но вот из-за этой потребности работать с разным, внутреннее представление это - мапы, слайсы, мапы в слайсах, слайсы в мапах, да ещё и из всех щелей торчит куча метрик.

Поэтому вот такая картина потребления памяти меня до недавних пор особо не смущала:

Многие считают ITIL (Information Technology Infrastructure Library) устаревшим набором практик, которые не работают на современных процессах. Опыт «Петрович-ТЕХа» доказывает обратное.

Привет, Хабр! Меня зовут Антон Скутин и я business relationship & service level manager в «Петрович-ТЕХ». Вырос из специалиста техподдержки в лида направления качества и сервиса, в компании уже шесть лет, веду телеграм-канал BRM о своей работе. Расскажу про опыт, как мы в «Петрович-ТЕХ» внедрили ITIL и получили реальный профит. В процессе роста компании мы выделили три временных этапа внедрения ITIL-практик.

Статья написана по мотивам моего доклада для конференции DevOps Conf.

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

В тексте поделимся выгодами и недостатками каждого подхода, чтобы вы могли принять взвешенное решение. Сравнивать будем не с технической точки зрения, а со стороны бизнеса. Определим, какой вариант экономически выгоден в долгосрочной перспективе. Подробности под катом!

В 2025 году Kubernetes стал практически таким же распространенным решением, как и операционная система линукс. Действительно, с внедрением микросервисов и необходимостью управлять парком серверов нам нужна распределенная операционная система. Именно такой системой и является оркестратор Kubernetes. 

Не я один подметил это, этот факт подсвечен во многих материалах по K8s. Например, вот: 

Меня зовут Илья Куликов, я руковожу разработкой веб-терминалов в компании «Столото». Сегодня хочу рассказать, как мы превратили ручные релизы и вечные конфликты в почти автономный CI/CD. За почти 10 лет в компании я прошёл путь от бэкенд-разработчика до руководителя направления, в «Столото» же за это время родился и вырос целый продукт — веб-терминал для агентов розничной сети. Изначально у нас был парк дорогих аппаратных терминалов, установленных у агентов. Но как расширить сеть и снизить входной порог? Возникла идея: а что, если сделать аналогичное приложение в браузере? Тогда любой желающий мог бы стать агентом — достаточно старого ноутбука и договора с нами. Так появился полноценный веб-аналог аппаратного терминала со всеми необходимыми функциями для продажи лотерей.

Но вместе с ростом продукта росла и боль: релизы занимали часы, всё постоянно ломалось на проде, а после каждого деплоя команда судорожно грепала логи в поисках причины падения. Мы поняли: без серьёзной перестройки процессов дальше — только хуже. И тогда решили кардинально пересмотреть наш подход к CI/CD. Отказались от классического GitFlow в пользу trunk-based development, полностью перестроили пайплайны в GitLab и внедрили автоматизацию на всех этапах — от сборки и тестирования до деплоя и мониторинга.

В этой статье я делюсь реальным опытом:

- как мы ушли от ручных релизов к автоматическому деплою в прод;

- какие практики и инструменты позволили нам перестать бояться каждого коммита;

- как повысить качество кода и ускорить вывод фич на рынок без ущерба для стабильности.

Этот материал будет особенно полезен техлидам, инженерам DevOps, разработчикам и командам, которые всё ещё живут в мире ручных деплоев, боятся нажимать «мердж» в пятницу вечером. Если вы задумываетесь, как перейти от хаоса к предсказуемости в релизах — вы по адресу.

А как мы этого добились — читайте под катом!