DevOps *

Когда проектов в GitLab становится много, довольно быстро появляется одна и та же задача: найти, где используется конкретный API, URL, env-переменная или конфигурационный параметр.

Пока репозиториев мало, всё просто: открыл поиск, ввел строку, получил результат. Но когда проектов уже больше сотни, а нужные вхождения лежат не только в коде, но и в YAML-конфигах, Helm-чартах, .env и JSON-файлах, жизнь становится менее романтичной.

Первый лобовой вариант — просто скачать все проекты локально и искать по ним через grep, ripgrep или IDE. Работает, но тащить 100+ репозиториев на локальную машину ради одной проверки — идея так себе. Ноутбук, скорее всего, энтузиазма не разделит.

Мне хотелось искать прямо поверх GitLab, без локального зеркала всей группы репозиториев. Я начал с просмотра готовых вариантов, а в итоге пришёл к своему гибридному краулеру: код ищется через GitLab API, а конфиги добираются отдельным глубоким обходом файлов. В результате поиск по 100+ проектам сократился с часов до нескольких минут.

Использовали Cloud DNS, всё работало штатно.

В марте 2026 года мы столкнулись с неприятной ситуацией: в облачном DNS, который использовался для одной из наших публичных зон, начался резкий всплеск публичных авторитетных DNS‑запросов, причём основную массу составляли ответы NXDOMAIN.

На практике это привело сразу к двум проблемам:

Меня зовут Андрей Трегубов, я руковожу группой DevOps в Ви.Tech, IT‑дочке ВсеИнструменты.ру. Недавно мы записали подкаст с Александром Крыловым, директором по развитию продукта «Штурвал», и обсудили, где у DevOps заканчивается роль «ребят, которые иногда помогают разработке» и начинается сервисная модель с понятным входом, приоритетами и правилами игры. В этой статье я собрал из нашего разговора самое практичное: когда DevOps уже пора выстраивать как сервис, почему на росте перестает работать героизм, как не утонуть в поддержке, что делать с зоопарком технологий и где в этой истории нужны Enabling Team, безопасность и ИИ.

Можно долго спорить о терминах, но на практике все очень приземленно. Есть команда, к ней приходят с запросами, она что‑то делает, где‑то автоматизирует, где‑то чинит, где‑то вытаскивает всех из пожара. И какое‑то время это даже выглядит нормально. Проблема в том, что «нормально» и «масштабируется» далеко не одно и то же.

Pusk — self-hosted сервер алертов на 16 МБ. Один бинарник, без внешних сервисов, частично совместим с Telegram Bot API (13 методов из 80+).

Типичная ситуация: несколько серверов, Zabbix собирает метрики, Python‑боты шлют алерты в Telegram. У кого‑то это веб‑проект, у кого‑то видеонаблюдение, у кого‑то живые эфиры, где 2 минут без алерта = зрители видят чёрный экран. Работало годами.

А потом канал до API отвалился. Причина неважна — лимиты, блокировки, авария на стороне провайдера. Алерты встали. Нужен был свой канал доставки, который не зависит от внешних сервисов.

TL;DR: Затем, что с ним код чище, читаемее и предсказуемее ;)

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

Один AI-агент на базе Claude Sonnet закрывает 100% моих DevSecOps-задач. Без фреймворков, без оркестраторов, без векторных баз. Только LLM, операционная система и markdown-файлы. Рассказываю архитектуру, которая за этим стоит.

У меня нет макбука. Но два моих приложения лежат в App Store. Рассказываю весь путь: регистрация Apple Developer из России, сертификаты без Xcode, автоматическая сборка через GitHub Actions. Три варианта: для вайбкодеров, программистов без мака и хардкорщиков.

TL;DR: В этой статье мы возьмем новейшую Gemma 4 31B, которая в оригинале весит 62 ГБ, и заставим её работать и выгружаться на бесплатном Kaggle с лимитом диска в 57 ГБ. Спойлер: нам придется удалять исходники прямо во время работы Python-скрипта.

Логическая репликация в Postgres редко ломает прод внезапно — чаще она долго и методично копит проблему, пока replication slot удерживает всё больше WAL, потребитель отстаёт, а свободное место на диске начинает таять. В этой статье разбирается именно такая зона риска: как устроена работа replication slots, почему одних базовых настроек здесь недостаточно и какие практики реально помогают держать под контролем WAL, публикации, heartbeats, failover и мониторинг. Материал особенно полезен тем, кто работает с CDC, Debezium и production-инстансами Postgres, где цена ошибки измеряется уже не теорией, а стабильностью системы.

Я не собирался делать этот проект.
Просто однажды сломал систему — и понял, что rollback на ext4 не такая простая вещь, как кажется.

В итоге собрал своё решение на rsync: быстрый и предсказуемый откат без смены файловой системы.

Кода тут минимум — он на GitHub. В статье — про сам подход: проблему, попытки решения и итог.

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

Мы решили объединить безопасность и удобство в одном решении. Взяли идею кворума и привычный инженерному сообществу способ аудита изменений — коммиты в Git. Что получилось — читайте под катом. Cпойлер: вы сможете использовать это решение бесплатно.

На скрине показано 40 минут графиков с балансировки некоторого эндпоинта. На выделенном участке видно 129.01 рпс успехов и 7.27 ошибок 4xx, которые являлись 429 от рпс-лимитера. Настройка рпс-лимитера находилась на уровне “не более 150 запросов с интервалом в 1 секунду”. Не странно ли видеть такое уверенный и постоянный фон ошибок про превышение лимита?

Сейчас многие компании внедряют ИИ-агентов в свои процессы. И сталкиваются с проблемами. Классический пример: ИИ-агент по продажам самостоятельно пообещал клиенту скидку 50% на которую ему никто не давал разрешения. Явный провал разработчиков ИИ-агентов, хотя на прошлой неделе в демо всё работало идеально.

Мир явно разделился: одни говорят, что агенты готовы к продакшену, другие кричат что это не работает и работать не будет. Энтузиасты показывают впечатляющие демо. Чистые данные, правильные API, никаких сюрпризов. Но продакшен это другой зверь. Отчёт MIT показал, что 95% пилотов генеративного ИИ не достигают ожидаемых результатов. Модели не тупые. Инфраструктура вокруг них не готова.

Я это понял на собственном опыте, строя своего агента на базе OpenClaw, который отчитывается мне ежедневно в Telegram. Все здесь крайне интересно, но реальные области использования нащупать сложно.

Время вялого вайбкодинга и медленных пайплайнов заканчивается.

И пока большинство CI/CD инструментов помогают вам деплоить. GitCrab заставляет вас бороться.

Привет, я давно не заходил. Лет десять (или даже пятнадцать...) прошло с того момента, как я написал статьи о парсинге бинарных документов, типа doc, pdf или rtf, ради получения текста (кстати, я недавно обновил репозитории, немного пересобрал старые проекты, можете глянуть). Вы бы знали сколько воды с тех пор утекло, но это всё ностальгия и былое - давайте к серьёзному.

С пару недель назад я возвращался домой на метро и в голову пришла идея, которую не возможно было отбросить. А что если есть неуверенные люди (а они есть)? А что если есть неуверенные люди, которым нужен толчок свыше? А что если эти неуверенные люди среди нас, в разработке - на бэкэнде, в devops или среди продактов? А что если им всем помочь?..

И родился проект Deploy Tarot. Да, это расклады таро на успех деплоя. Что если я, техлид, сегодня задеплою новую версию API? Нет проблем, карты расскажут. А что если наш бизнес аналитик захочет обновить документацию? Арканы помогут понять. А вдруг наш CTO возьмётся за старое, вспомнит про порох в этих самых и... сделает масштабный рефактор (ИИ, ну вы знаете)? Колода определённо знает. А если наша офис-леди?.. Ну, вы поняли.

Всем привет! Меня зовут Александр Барыков, я руковожу платформенной командой DevOps и являюсь лидером DevOps-комьюнити в нашей компании.

Сегодня хочу поделиться опытом, который мы накопили за последние четыре года. Речь пойдет о достаточно специфической, но знакомой многим теме – организации процесса скачивания и проверки внешних артефактов для размещения во внутреннем закрытом контуре. Эта статья будет полезна разработчикам, DevOps-инженерам и архитекторам, которые сталкиваются с необходимостью соблюдения строгих требований безопасности без потери темпа разработки, особенно в финансовом секторе, где есть регуляторные требования.

Transform processor в OpenTelemetry часто воспринимается как «универсальный костыль» на случай, когда стандартных процессоров уже не хватает. В итоге в конфигурации появляются OTTL-инструкции, которые вроде бы корректны, но ведут себя непредсказуемо: условия не срабатывают, поля не меняются, данные теряются без явных ошибок.

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

Если вы уже имели опыт написания Ul-тестов для проверки страниц и форм, то, вероятно, задумывались: "Почему бы не протестировать весь сценарий целиком?" Так родилась идея делиться опытом, как мы внедрили подобный подход: начиная с первых шагов, объясняя, почему объединили UI, АРІ и SSH в единый интеграционный контур, и какие инструменты используем.

Знаете, что общего между щенком лабрадора и корпоративным AI-проектом? Оба сначала кажутся милыми и недорогими, а через полгода жрут столько, что хочется плакать. Только щенок хотя бы ласкается, а нейронка просто молча выставляет счет за GPU. В этой статье мы вместе с Александром Меркушевым (AI-консультант, архитектор облачных и AI решений, руководитель экспертной группы по внедрению ИИ в Яндексе) разбираемся, как AI меняет структуру инфраструктурных затрат, что с этим делать уже сейчас и, главное, поможет ли тут FinOps.

Присоединяйтесь к нашему сообществу «Практики FinOps» в Telegram.

AI ассистенты уже просто вошли в процессы разработки кода, но что на счет DevOps задач и CI/CD в частности? Думаю здесь их полезность может оказаться не чуть не меньше.

Как часто к вам или вы прибегали с круглыми глазами и просьбами помочь с упавшим пайплайном?

Как бы получить ответ быстро не заставляя никого заниматься скучной однообразной работой? Изучать логи джобы и искать в описании пайплайна ошибку, сравнивать что успели сломать с последнего коммита и так далее.

К счастью теперь за нас это могут нейросети и давать дельные советы (не все, но могут)