DevOps *

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

Москва говорит, что rbc.ru открывается за 47 мс. Из Новосибирска — за 594 мс. Это не баг сервера, а реальность Рунета — и из одной точки мониторинга вы её не увидите. Прогнал 27 ресурсов с двух проб в Москве и Новосибирске за 5 суток, разобрал 278 эпизодов расхождений между ними, нашёл живые трёхчасовые блоки telegram.org из Сибири. С графиками, цифрами и Naruto-метафорой внутри.

Мы искали уязвимости в RAG-платформе с десятками тысяч пользователей — а нашли доступ ко всей инфраструктуре и API-ключам с бюджетом в сотни тысяч долларов. Две недели мы строили сложные цепочки: SSRF через LangChain, инъекции в промпты, HTTP smuggling, CVE в десериализации. Ни одна не дала результата. А потом мы сделали один curl к открытому порту — и получили все ключи за 5 минут.

Эта статья — не гайд по взлому. Это разбор того, почему LLM-инфраструктура создаёт принципиально новые риски, какие ошибки мы раз за разом видим в AI-стартапах, и на что стоит обратить внимание, если вы строите что-то похожее.

Когда сервис поднимается по 8-15 минут, команда почти всегда начинает крутить одни и те же ручки: увеличивает initialDelaySeconds, добавляет startupProbe, поднимает progressDeadlineSeconds, иногда переносит миграцию в initContainer и считает, что стало «по-кубернетесному». Обычно это не лечение. Это способ аккуратнее завернуть проблему в YAML. Если тяжёлая миграция живёт внутри старта приложения, вы связали жизненный цикл Pod, rollout Deployment и поведение базы в один общий узел. А такие узлы в проде рвутся не там, где их ждут.

Обобщение знаний и опыта для базового использования Docker, которые накопились за время использования.

Пятница, 23:40, прод лежит. Дежурный поднимает сервис за сорок минут: перезапустил контейнер, всё заработало. Инцидент закрыт, MTTR красивый, все спать.

Через десять дней то же самое: тот же сервис, та же ошибка в логах. Снова подняли и снова закрыли.

Представьте типичный разговор на ретроспективе: команда обсуждает, стоит ли переходить с Ansible на Terraform, нужен ли Backstage или хватит самописного портала, пора ли внедрять Chaos Engineering или это ещё «не для нас». Каждый приводит аргументы, ссылается на прочитанные статьи, и в итоге решение принимается по принципу «кто громче убедил». Знакомо?

Проблема чаще всего в отсутствии общего ориентира. Именно для этого существует технологический радар: инструмент, который переводит разговор о технологиях с уровня личных предпочтений на уровень коллективной экспертизы.

Всем привет от Петра Третьяка, который за 10 лет в управлении проектами ни разу не видел, чтобы крупный релиз вышел ровно в ту дату, которую назвали на старте. Ни разу. При этом все на старте в эту дату верили: и заказчик, и команда, и я сам.

DevSecOps по-прежнему часто сводят к подключению сканеров в CI/CD. Дальше сценарий предсказуем: пайплайн замедляется, отчёты копятся, команда теряет к ним интерес. Проблема обычно не в инструментах, а в том, что их внедряют поверх неизменённых процессов.

В статье — о том, как подойти к DevSecOps как к системному изменению: с чего начать, как выбрать пилот, какие цели ставить и где чаще всего всё идёт не так.

Каждый, кто активно пользуется GitLab CI/CD, знаком с ситуацией: вы пушите изменения, ждёте минуту-другую, а пайплайн падает из-за мелкой ошибки линтера или отсутствующей зависимости. Исправляете, снова пушите, снова ждёте… Цикл может быть утомительным.

Но ведь GitLab Runner сам запускает ваши джобы в Docker-контейнерах. Почему бы не сделать то же самое локально? Это сокращает время обратной связи с нескольких минут до десятков секунд.

В этой статье я покажу, как в точности воспроизвести выполнение любой CI-джобы у себя на машине, отладить её и только потом отправлять изменения в репозиторий.

Однажды мне понадобился быстрый способ получить мониторинг SIP-трафика в Prometheus — без установки агентов на серверы, без настройки SPAN на коммутаторе, без привязки к конкретному софту — просто подключиться к сетевому интерфейсу и видеть всё, что происходит. Причём с минимальной задержкой и без влияния на производительность самой телефонии — мониторинг не должен становиться источником проблем.

В этой статье — как я решил данную задачу мониторинга SIP-телефонии с помощью eBPF: от захвата пакетов в ядре Linux до метрик RFC 6076 с разбивкой по источникам трафика и типам устройств в Prometheus/VictoriaMetrics.

Помните момент, когда сервис работал нормально, но после рассылки, рекламной кампании или наплыва пользователей начал тормозить?

В такие секунды и выясняется, что без нагрузочного тестирования команда на самом деле не знает, где у системы потолок, как проседает производительность и в какой точке критично растёт время отклика. Хорошо настроенное нагрузочное тестирование на Python помогает опираться на цифры: сколько запросов выдерживает API, как ведут себя ключевые бизнес‑сценарии и когда инфраструктура начинает деградировать.

Всем привет! С Вами на связи Евгений Листраткин, ведущий инженер команды администрирования клиентских сервисов. Мы предоставляем услуги DevOps as a Service как в дата-центрах Selectel, так и на любых других площадках.

Под задачи клиентов мы держим значительную часть сервисов в Kubernetes-кластерах, используя managed‑решения нашей компании. При этом не участвуем в разработке и технической поддержке самого продукта, а выступаем исключительно в роли его пользователей — как внутренних, так и внешних.

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

Рано или поздно каждый Android‑разработчик сталкивается с задачей «одно приложение — много сборок»: white‑label‑решения, региональные версии, отдельные сборки для разных магазинов приложений, демо для клиентов, внутренние окружения.

Встроенный механизм product flavors в Android Gradle Plugin отлично справляется со своей задачей — пока количество вариантов умещается в голове и в паре экранов build.gradle.kts.

В этой статье я разберу подход, при котором конфигурация flavors строится динамически: список вариантов и их параметры живут вне build.gradle.kts.

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

Я на своём опыте расскажу, как выбрать LLM и ИИ-агента, как его настроить и калибровать, а также поделюсь полезными техниками промпт-инжиниринга. 

Прывітаначкі, похоже с одной стороны сегодня программистов нужно меньше чем раньше, с другой стороны — благодаря LLM действительно можно делать задачи на порядок быстрее. Предполагаю, что в ручную этого бота я бы делал месяц, через Codex gpt-5.5 xhigh — часа три.

В Evernote у меня записано много идей. Хорошо бы то, хорошо бы это. И таки некоторый прогресс в их реализации есть. И вот недавно — открываю официальное приложение Evernote на iPhone, а заметки не загружаются. У меня самый дорогой премиум аккаунт. Вот так стало понятно — надо делать.

Про другие неофициальные клиенты:

Я мантейнер Geeknote — неофициальный CLI на Питоне, он внутри моего бота.

NixNote на C++

CliNote на Go — недавно заархивирован — feel free to форкнуть и починить.

И вот теперь я сделал Телеграм бота https://gitlab.com/vitaly‑zdanevich/bot_telegram_evernote

На Питоне — хотя я предпочитаю Go — но Geeknote зависимость на нём, так что для единообразия.

30 часов хронологии того, как агент Cursor, Railway API и индустрия, которая продаёт безопасность быстрее, чем её реализует, положили малый бизнес, обслуживающий прокатные компании по всей стране.

Меня зовут Джер Крейн, я основатель PocketOS. Мы делаем ПО для прокатного бизнеса — в первую очередь для аренды автомобилей: бронирования, платежи, управление клиентами, отслеживание транспортных средств. Некоторые наши клиенты с нами уже больше 5 лет и они буквально не могут работать без нас.

Вчера днём ИИ‑агент на базе Cursor с Claude Opus 4.6 от Anthropic удалил нашу продакшн‑базу данных и все резервные копии на уровне тома одним API‑вызовом к Railway, нашему инфраструктурному провайдеру.

На это ушло 9 секунд.

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

В последнее время происходит фундаментальный сдвиг парадигмы от управления изменениями (проектами) к управлению ценностью (продуктами). Жесткие границы проектов (начало → конец) размываются, уступая место непрерывному потоку операционного производства (DevOps, продуктовая модель).

Если цель в классической модели ЖЦ - создать целевой продукт за конечное время, используя выделенные ресурсы, то в операционной деятельности - это постоянная и непрерывная поставка новый функциональности, добавляющей ценность заказчику от ее использования в ИТ-продукте. То есть стираются явные временные границы производства, “нарезанного” на проекты. Но это не значит, что прекращается измерение конечного успеха производства, просто диагностирование смещается из плоскости проектной деятельности в плоскость достижения бизнес-метрик. Что в свою очередь заставляет менять организацию производства, в частности: подходы к планированию и распределению бюджета (от фиксированных к периодическим), принципы формирования команд (от временных проектных к постоянным кросс-функциональным потоковым). Эти модели мы рассматривали ранее в “Части 2. Варианты организации производства”.

По существу, производство переходит после первого этапа внедрения минимальной функциональности (иногда MVP) в операционную деятельность, переплетаясь с процессами сопровождения. Зачастую операционка начинается еще до окончания формального конца проекта.

Заказчики все реже соглашаются на чистый Fixed Price (классический проект). Растет доля:

Привет, Хабр! К написанию статьи меня подтолкнуло знакомство с механизмом socket activation в Linux, на который я случайно наткнулся и не смог пройти мимо. Технология старая, но заслуживает большого внимания, а моя статья раскрывает одно из множества потенциальных практических применений — создание SSH-туннеля по требованию.

Привет, меня зовут Дмитрий Синявский. Я инженер по надёжности сервиса в Ви.Tech и одна из моих любимых тем SLI/SLO. Сегодня разберемся с «скоростью расхода бюджета ошибок».

Недавно я провел опрос в канале сообщества ALLSLO, в котором спрашивал вызывает ли понимание термина Error budget burn rate сложности. В опросе верный ответ отсутствовал и был вариант «нет верного ответа», однако более 40% выбрало неверный ответ. Потому давайте разберемся, что же это такое Error budget burn rate.