DevOps *

Однажды я зашёл в компанию через неделю после крупного падения и попросил показать постмортем. Мне показали — с гордостью. Таймлайн поминутно, five whys, аккуратный список action items, owner напротив каждого, разослано по всем спискам. Красиво. «Видите, мы серьёзно подошли».

Я задал один вопрос: а постмортем по прошлому такому же падению — где? Нашли. Открыли. Те же action items. Слово в слово. С прошлого раза не закрыт ни один.

То есть полгода назад уже собирались, уже всё проанализировали, уже назначили ответственных — и ничего не сделали. А потом упало снова, по той же причине, и они снова собрались, снова проанализировали, снова назначили. С тем же результатом, который будет и в следующий раз.

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

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

Привет! Меня зовут Евгений, я работаю в БКС Мир инвестиций владельцем сервиса «Портфель».

Если объяснять просто, «Портфель» — это раздел, где клиент смотрит свои активы: деньги, ценные бумаги, валюту, фонды, облигации, фьючерсы, финансовый результат и общую картину по инвестициям.

Для клиента это обычный экран в приложении или личном кабинете. Открыл, посмотрел, что происходит с деньгами, принял какое‑то решение.

Но внутри компании за этим экраном стоит много всего. Backend‑сервисы, frontend, интеграции, биржевые данные, банковские продукты, сетевой путь, мониторинги, SLA, обращения клиентов в контактный центр, поддержка, аналитика, релизы и ожидания бизнеса.

На стыке всего этого и появляется роль Service Owner.

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

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

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

Несколько месяцев назад в публичном пространстве появилась история, которую в engineering-сообществе стали называть поучительной. Команда AWS использовала внутренний AI-инструмент Kira для ускорения работы. Kira предложила джуниорам сценарий: переразверни продакшн-слой. Инженеры согласились. Следующие шесть часов весь AWS не работал. После разбора полётов компания объявила новое правило: финальный апрув на изменения, предложенные агентом, должен давать сениор-инженер.

На первый взгляд, решение логичное. На второй, уже менее. Если агент генерирует изменения в темпе, к которому люди не привыкли, один сениор превращается в бутылочное горлышко для бесконечного потока PR. Это не решение проблемы. Это антипаттерн, оформленный как процесс.

История AWS точно формулирует главный вызов 2025-2026 годов: AI научился быстро писать код, но индустрия пока не научилась с такой же скоростью его доставлять, проверять и принимать решения о нём. Данные, собранные в рамках масштабного исследования State of AI4SDLC, это подтверждают.

Хотели избежать копирования данных, придумали свою служебную разметку, а потом обнаружили: она занимает почти столько же места, сколько сам исходный текст. Мы перестали гадать, посмотрели на реальные данные и применили простые, но эффективные подходы: числа переменной длины, отказ от double в пользу целых типов и умные if-else вместо switch. 

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

Инфраструктура обычно ломается не в одном месте. За «просто поправить деплой» быстро подтягиваются лимиты Linux, настройки контейнеров, CI/CD, безопасность, маршрутизация, Kubernetes, базы данных и сети ЦОД. Чем больше сервисов и команд, тем важнее видеть не только отдельные инструменты, но и связи между ними.

В этом дайджесте собрали открытые уроки, статьи и курсы по Linux, Docker, Kubernetes, CI, PostgreSQL, сетям и безопасности. Подборка будет полезна тем, кто отвечает за стабильность сервисов и хочет системно закрывать инфраструктурные пробелы.

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

Пользователи облачных версий — Jira Cloud, Confluence Cloud, Trello — получили уведомления об отключении аккаунтов ещё в августе 2023 года. Серверные инсталляции оказались в другом положении: систему снаружи не заблокируешь, но глобальная поддержка Server-продуктов прекратилась 15 февраля 2024 года — система осталась без обновлений, патчей безопасности и технической помощи. Часть компаний успела зафиксировать лицензию до дедлайна и продолжила работать именно в таком режиме. Другие перешли на серые ключи — физически встречались с людьми, которые передавали активационные коды, лишь бы не останавливать сотни проектов в Jira. Ещё часть просто перестала платить и работает как есть.

Отдельную группу давления создаёт глобальный EOL для Data Center: с марта 2026 года Atlassian прекратил продажу новых лицензий Data Center, в 2028 году закроет продление существующих, а полная поддержка завершится в 2029-м. Для российских компаний, которые после ухода вендора перешли именно на Data Center как на «безопасную» замену Server, это означает, что мигрировать всё таки придётся.

Привет! Меня зовут Руслан Мамлеев, я эксперт курса «Архитектор ПО» в Практикуме и технический директор (CTO) в GetFloorPlan. 

Недавно на фоне кризиса и сокращения бюджетов у нас ушёл DevOps. А вместе с ним исчезла и целостная картина инфраструктуры — только он понимал, какие серверы, домены и прокси у нас есть, где что живёт, какие доступы выданы, что мониторится, а что нет. Два месяца провели в хаосе. 

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

Схема входящего траффика в кластер Kubernetes простая: web → Envoy Gateway → Ingress Nginx → backend. За Ingress Nginx, помимо обычного HTTP, живут долгоживущие WebSocket-соединения. Штатная нагрузка - около 100 RPS. Ничего экзотического.

В один прекрасный день всё в кластере легло. Клиенты получают 503/500. В логах Envoy - флаг UF и upstream_reset_before_response_started{connection_timeout}. То есть ingress-nginx просто перестал отвечать.

Дальше - два часа разбора и довольно красивая цепочка причин, которая началась с банального reload, а закончилась на том, как ядро считает лимит потоков при старте виртуалки.

Как держать несколько проектов на одном VPS так, чтобы каждый работал на своём домене с HTTPS, а все порты были закрыты снаружи — без Kubernetes и ручных конфигов Nginx. Nginx Proxy Manager, Docker-сети и три реальных проекта на практике.

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

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

Привет, Хабр! Я Руслан Боярский, 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 она выражена слабее: язык структурный, понятный, неплохо защищён по умолчанию. Но это не индульгенция. Разберём, что такое уязвимость и откуда она берётся, пройдёмся по типичным классам проблем на живых примерах с продакшена, посмотрим на инструменты локального анализа кода и обсудим, как выстроить продуктивные отношения с командой безопасности.