DevOps *

Разбор межфайловой дедупликации на версионных данных: почему обычная упаковка упирается в потолок и что меняется на CPython, Go и Node.js.

ИИ не заменяет людей — люди просто больше работают. Так давайте хотя бы ночью пусть работает ИИ.

Как мы сделали Авто‑Кодера, выжимая максимум из нашей подписки на LLM!

Вы уверены, что ваш “случайный” пароль действительно случайный?

Я тоже так думал — пока не полез разбираться, как Python на самом деле генерирует случайные значения. Оказалось, что привычный random — это не про безопасность вообще. Это генератор, который только выглядит случайным, но при определённых условиях может быть воспроизведён. Что даст нам возможность предсказать все будущие пароли и прошлые.

В статье я последовательно разбираю:

• почему классическая “энтропия пароля” часто вводит в заблуждение;

• как устроен Mersenne Twister и в чём его фундаментальная проблема;

• почему даже хороший seed (через os.urandom) не делает random безопасным;

• и что на практике можно (и нельзя) восстановить, имея время генерации, код и несколько паролей.

Я попытался воспроизвести реальную атаку: восстановить seed по временной метке и набору сгенерированных паролей. Спойлер — всё оказалось сложнее, чем кажется.

Отдельно показываю, где проходит граница между «кажется надёжным» и «действительно криптостойким», и почему secrets — это не просто «рекомендованный модуль», а принципиально другой класс генерации.

LLM-агенты отлично решают алгоритмические задачи. Но что произойдет, если поместить их в реальную инфраструктуру – с CI/CD, branch protection и security-политиками?

Я провел эксперимент: дал агентам простую задачу – внести изменение в репозиторий и замерджить его в main, соблюдая все правила. При этом у них был доступ к тем же инструментам, что и у разработчика, включая GitHub CLI и админский токен.

Результат оказался немного неожиданным. Практически все модели успешно выполнили задачу, но ни одна так, как я ожидал.

В статье — не просто список инструментов, а как они сочетаются, какие подводные камни ждут при развёртывании, какие цифры можно ожидать по производительности и как обойти ограничения Llama 8B без облачных кредитов.

Когда проектов в 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: быстрый и предсказуемый rollback без смены файловой системы.

Кода тут минимум — он на GitHub.
В статье же не столько про код, сколько про подход: где ломаются готовые решения и как собрать рабочий rollback из базовых инструментов Linux.

При управлении доступом в 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 возьмётся за старое, вспомнит про порох в этих самых и... сделает масштабный рефактор (ИИ, ну вы знаете)? Колода определённо знает. А если наша офис-леди?.. Ну, вы поняли.