DevOps *

Чтобы стать «мидлом, недостаточно выучить десяток новых инструментов и отсидеть пару лет на проекте. На деле тимлиды смотрят не на стек инженера, а на то, как он мыслит: закрывает ли задачу в вакууме или видит, как решение повлияет на всю систему. 

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

Привет, Хабр! Я Руслан Боярский, SRE-инженер в Т-Банке, где мы строим и поддерживаем Sage — внутреннюю платформу наблюдаемости для 7 000+ инженеров. У нас собираются миллионы метрик в секунду, работают десятки тысяч алертов, и на нас завязаны решения о стабильности критически важных сервисов.

В какой-то момент мы задались вопросом: насколько на самом деле надежна наша платформа? У нас были SLA, но не было уверенности, что они отражают реальные ожидания пользователей.

В статье по мотивам моего доклада на DevOpsConf 2025 — наш путь от гипотез и «галлюцинаций» до рабочих SLO: как мы с помощью глубинных интервью с клиентами перестали гадать о надежности и начали измерять ее по-настоящему.

От CRUD на FastAPI до видеоплатформы: история одного pet-проекта

История о том, как учебный CRUD-проект на FastAPI постепенно превратился в стенд с микросервисами, мониторингом, Kubernetes.

Если вы в 2026 году запускаете LLM в продакшене, то почти наверняка больше всего денег тратите на инференс. Одна неоптимизированная модель размером 70B может сжигать десятки долларов в час на нескольких A100, тогда как грамотно оптимизированный стек дает сопоставимый результат за сравнительно меньшую сумму. При активном продакшене это выливается в тысячи долларов в месяц разницы только за счет настройки инференса.

Но как это сделать?

Недавно я наткнулся на подробный гайд по оптимизации инференса на JobsByCulture. Внутри — перевод статьи + мои наблюдения и мысли поверх.

Приветики-пистолетики! Это Кирилл из Neuromed и сегодня я хотел бы затронуть вопрос деперсонализации. Да, этот тренд возможно уже уходящий, т к все кто хотел реализовать - уже имеют свой успех, но я понимаю- что использование локальных ИИ в качестве инструмента гибкой деперсонализации - это искусство не имеющее граней, поэтому как творческий человек, я решил объяснить на пальчиках для новичков все аспекты работы деперсонализатора, как удовлетворять законам и как получить качественный деперсонализатор в проде у каждого. Садимся, берем чай-кофе и поехали!

Подняли DeepSeek‑V4‑Flash на двух GB10, упёрлись в потолок consumer Blackwell, прошли три тупика со спекулятивным декодингом — и в итоге получили параллельную работу ресёрч-агента и длинной генерации без очереди. Цифры из Grafana.

Чуть больше месяца назад я впервые рассказал об IncidentRelay, open-source и self-hosted системе для дежурств, маршрутизации алертов и эскалаций.

В первой версии основная цепочка уже работала:

Monitoring -> Route -> On-call -> Notification -> ACK / Resolve

С тех пор проект добрался до v1.0.21-beta. Цепочка стала длиннее, но пользоваться системой стало проще. В отличие от некоторых корпоративных процессов, здесь усложнение действительно пошло на пользу.

Не буду пересказывать весь changelog. Расскажу о нескольких изменениях, которые сильнее всего повлияли на продукт.

Valkey (форк Redis под крылом Linux Foundation) в релизном цикле 9.1 отдал ИИ-агентам рутину мейнтенанса: бэкпорт-агент сам раскатывает фиксы по веткам 7.2/8.0/8.1/9.0, отдельный агент сканирует provenance кода на конфликт с нынешней лицензией Redis (чтобы в форк случайно не затёк несовместимый код родителя), а агентский поиск багов наткнулся на ещё закрытую CVE. Разбираю не «ИИ заменяет мейнтейнеров», а как это сделали по уму: по словам Мэделин Олсон из AWS, агентов посадили на ограниченный, проверяемый слой (CI + ревью + человек на мерже) — «using AI agents without losing control». Главный вывод для своих проектов: сажать агентов на toil, а не на дизайн.

Хочу рассказать про несколько новых возможностей AWS Elastic Container Registry (ECR), о которых, как мне кажеться, знают немногие.

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

Тёмная сторона есть, наверное, у каждого языка. У Go она выражена слабее: язык структурный, понятный, неплохо защищён по умолчанию. Но это не индульгенция. Разберём, что такое уязвимость и откуда она берётся, пройдёмся по типичным классам проблем на живых примерах с продакшена, посмотрим на инструменты локального анализа кода и обсудим, как выстроить продуктивные отношения с командой безопасности.

Сайты под управлением ИИ: что это на самом деле и сколько стоит. Часть 1

Это вторая часть из трёх. В первой мы разбирались с концепцией: что такое сайт под управлением ИИ на самом деле, чем он не является, сколько стоит, есть ли инференс в рантайме (спойлер: для посетителя — нет). Если читали — отлично. Если нет — здесь будет понятно и без неё, потому что речь пойдёт про другое: про механику.

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

В SOC реальная атака редко приходит с табличкой «срочно расследовать»: чаще она маскируется под очередное ложное срабатывание, которое уже сотни раз закрывали на автопилоте.

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

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

В российском вебе за неделю сломалось две вещи. 13 июня GlobalSign начал массовый отзыв сертификатов у российских компаний — до 20 000 доменов второго уровня под ударом. Let’s Encrypt 4 июня формализовал санкционные ограничения в новой редакции пользовательского соглашения. Я держу около десятка сайтов, все на Let’s Encrypt; сел и прошёл их по списку — какой issuer у каждого, кому грозит и в каком порядке, какие альтернативы реально работают в 2026 году. Внутри: пайплайн инвентаризации через openssl и crt.sh, конфиг Caddy с двумя issuer-ами в fallback, разбор Google Trust Services, НУЦ Минцифры и тех, кто уже выбыл (Buypass) или присоединился к ограничениям (ZeroSSL).

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

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

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

В прошлой статье мы завершили настройку нашего стенда РБПО: подготовили GitLab и GitLab Runner, настроили Nexus, Vault, DefectDojo и Dependency-Track, а также создали все необходимые учетные записи, роли и переменные для будущего конвейера безопасной разработки.

Теперь настало время собрать все эти инструменты в единый пайплайн. В этой статье напишем GitLab CI/CD-конвейер, который автоматизирует сборку приложения, проверки безопасности, генерацию SBOM и публикацию результатов в настроенные ранее сервисы.

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

Block (Square, Cash App, Tidal) рассказала, как у неё устроена разработка: внутренний Builderbot делает 200 000+ операций в день, мержит ~1500 PR в неделю и отвечает за ~15% всех изменений прод-кода. Фон невесёлый — всё это после сокращения ~4000 человек. Разбираю, что реально под капотом (Builderbot — control plane поверх открытого фреймворка Goose: Slack-тред → ветка → PR → CI-петля), и главное — что из этого может украсть обычная команда без своего фреймворка. Острый угол: на масштабе кодинг-агент — это не про модель, а про обвязку (CI, права, аудит, очереди PR), то есть чистый DevOps. Плюс честно про маркетинг в их цифрах и про 4000 человек за кадром.

Экран, в котором я живу 4 месяца. Не открываю IDE — всю god crm пишу внутри god crm.

Всё на скрине — строки одной postgres-таблицы. заметка, тикет, агент — одна сущность. поэтому заменило мне ноушн, обсидиан и мессенджер сразу.

Код открыт, mit: github.com/holetron/godcrm

Я больше года не пишу код руками — всё пишет ИИ. Но я не вайбкодер, и это две разные профессии. Рассказываю, в чём разница, почему она скоро будет стоить компаниям дорого, и при чём тут Git-клиент, который я написал, чтобы пройти корпоративную ИБ.