DevOps *

Павел Монин, ведущий DevOps- и ИИ-инженер и студент курса «Английский для ИТ» от Across, работает в израильском офисе американской компании Autofleet.

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

Привет, Хабр. Мы Марина и Михаил, и мы занимаемся оптимизацией внутренних процессов и автоматизацией управленческой и аналитической отчетности в ИС СКАП (Jira) в команде РСХБ.Цифра. В этой статье расскажем о тренде на демократизацию данных, о том, как мы внедрили принцип демократизации данных в ИТ-кластере банка, и о том, что планируем в будущем.

Раньше на рынке стандартом использования BI были высокотехнологичные, но при этом высокобюджетные системы SAP BI, Tableau. Разработка такой отчётности считалась эксклюзивной за счет дорогостоящего оборудования и сотрудников разработки. В них мы готовили отчёты только для топ-менеджмента. Кто бы тогда мог подумать, что в скором времени отчёты BI будут доступны любому сотруднику, а стоимость разработки отчетов снизится в несколько раз?

Cуть демократизации данных заключается в переходе от разрозненного ручного сбора информации к прозрачной и проверяемой системе, доступной всем участникам процесса. Очевидно, что тренд появился из-за проблемы традиционного подхода к данным. Раньше подход к работе с данными выглядел примерно так: все подразделения вели учёт в своих системах, а затем какое-то одно ответственное подразделение собирало эти данные со всех остальных в единый источник.

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

В этой статье расскажу, как мы построили отдельный модуль управления корпоративными чатами и каналами на Django, PostgreSQL и Telethon. Без привязки к нашей внутренней инфраструктуре — только архитектура, технические решения и несколько выводов, которые могут пригодиться при решении похожей задачи.

Когда количество рабочих Telegram-чатов у нас приблизилось к сотне, выяснилось, что проблема уже не в добавлении одного человека в одну группу. Проблема — доказуемо выполнить десятки однотипных действий и не пропустить единственный чат. При этом не допустить утечку ресурсов (ведь кому-то на это всё понадобится тратить время, а новых или уволенных сотрудников может быть больше одного).

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

Обо всём этом в статье!

Всем привет! Меня зовут Рома, я бэкенд-инженер в Банки.ру. Мы перевели мобильное API на KrakenD, и сейчас через него идёт весь трафик приложения.

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

Сегодня Kubernetes стал де-факто стандартом для развёртывания SaaS-приложений и сервисов. Практически каждый разработчик работает с ним ежедневно, но большая часть этой работы связана с установкой уже готовых компонентов и манифестов. Если базового функционала начинает не хватать, возникает потребность в расширении. И вот тут начинается путешествие в уникальный мир k8s-операторов.

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

Меня зовут Антон Железнов, я разработчик в команде Managed Kubernetes облака MWS Cloud Platform. И в этой статье я хочу рассказать о тестировании операторов не на абстрактных примерах, а на устройстве нашего решения. Итак, поехали! 

Казалось бы, учетная запись в GitLab — не самая удачная стартовая точка для инфраструктурного пентеста. Ни VPN в корпоративную сеть, ни доменного аккаунта, ни даже RDP на рабочую станцию, только креды рядового разработчика. Вряд ли в начале проекта заказчик ожидал серьезного импакта, но мы доказали, что при типовых настройках CI/CD такая учетка находится на расстоянии нескольких прыжков до контроля над облаком. 

Давайте вместе пройдем эту цепочку.

В первой части мы остановились на том, что Продуктовая аллея DevOpsConf 2026 показала рынок как поиск более зрелых эксплуатационных моделей. AppSec, observability и AIOps важны, потому что заставляют команды ответить на важные вопросы: где остаётся ответственность, кто владеет дефектом, с какого SLO начинается мониторинг и какие решения нельзя отдавать автоматизации без контроля.

Во второй части мы поищем ответы на вопросы кто и на какой платформе будет сопровождать production через Kubernetes, инфраструктурные платформы, DevOps as a Service, облака, data-платформы и инструменты разработчика. Команды пытаются снять рутину эксплуатации, собрать внутренние платформы, автоматизировать инфраструктуру через API и Terraform, а заодно встроить AI и data-инструменты в SDLC так, чтобы они помогали разработчику, но не получали бесконтрольный доступ к критичным средам.

Недавно на Хабре вышла статья: автор показал систему для развёртывания собственной инфраструктуры — почта, файлы, сервисы, всё своё. В комментариях его слили. Код закрытый, цель непонятна, «очередная обёртка над docker‑compose».

Я читал и ловил странное чувство: он делал мою идею. И делал её неправильно.

Не потому что руки кривые. А потому что цель другая. Он прощупывал рынок. А рынок молчал. И в этот момент я наконец сформулировал, что строю сам.

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

Пока их двадцать, это терпимо. Когда приходит сорок первый клиент, ты открываешь кабинет и снова кликаешь: создать проверку, интервал, порог, теги, сохранить. Четыре раза. А потом кто-то спрашивает: «а почему у этого сайта порог два, а у соседнего три?» — и честный ответ звучит как «не помню».

Инфраструктуру мы описываем кодом уже лет десять. Мониторинг — почему-то нет. Хотя это ровно такая же конфигурация: её надо ревьюить, версионировать и уметь воспроизвести.

Я делаю внутреннего read-only LLM-агента для инфраструктурных расследований. Инженер задаёт вопрос обычным языком, а агент собирает доказательства из Kubernetes, метрик, логов, GitLab, Grafana и других эксплуатационных источников.

Один реальный кейс показал, почему «умного промпта» недостаточно: edge вернул 502, хотя приложение для того же request_id записало успешный редирект 302. Чтобы найти причину и не придумать удобное объяснение, агенту пришлось научиться связывать источники, удерживать время и scope, различать факты, гипотезы и отсутствующие данные.

В статье разбираю архитектуру агента на Go, DeepSeek, Qwen и MCP: планирование по evidence, контракты tools, память треда, подключение командных skills через n8n и evaluation на реальных сценариях. В последнем полном прогоне прошли 44 из 45 сценариев, включая все 29 обязательных.

Kubernetes незаметно стал платформой по умолчанию для ИИ и машинного обучения. Запускаете ли вы серверы notebook-ов для дата-сайентистов, планируете распределённые задачи обучения, настраиваете гиперпараметры или оркестрируете многоэтапные ML-пайплайны. Эти нагрузки всё чаще оказываются в кластере Kubernetes. Kubeflow — один из самых популярных способов собрать этот стек, причём Kubernetes-нативным путём: каждая возможность описана как CRD (Custom Resource Definition, описание пользовательского типа ресурса Kubernetes).

Такая архитектура подарок операторам кластера: ML-нагрузки можно наблюдать и управлять ими теми же примитивами, что и всем остальным в кластере. Но на практике специализированные ML-дашборды, которые поставляются с этими платформами, скрывают лежащий под ними слой Kubernetes. Когда notebook застревает или задача обучения падает, оператор часто вынужден откатываться к kubectl, чтобы выяснить, что на самом деле произошло на уровне Pod.

Команда VK Cloud перевела статью о плагине Headlamp Kubeflow, который закрывает этот разрыв и выводит пользовательские ресурсы Kubeflow прямо внутри универсального Kubernetes UI. Это проработанный пример паттерна, которому может следовать любая насыщенная CRD платформа: встречать операторов там, где они уже работают, и показывать им истину на уровне кластера.

Сам Headlamp это расширяемый веб-UI для Kubernetes, поддерживаемый в рамках Kubernetes SIG UI и лицензированный под Apache 2.0. Он работает как десктопное приложение или внутри кластера, а через систему плагинов кто угодно может добавить полноценные представления для пользовательских ресурсов.

Когда Atlassian объявила о завершении продаж Opsgenie, я сначала отреагировал как нормальный инженер: решил ничего не переписывать. Потом календарь напомнил, что нормальность имеет срок действия. Продажи Opsgenie прекратились 4 июня 2025 года, а поддержка завершится 5 апреля 2027 года. После этого сервис станет недоступен, а немигрированные данные будут удалены. Это не слух из рабочего чата, а официальная позиция Atlassian (условия и даты завершения Opsgenie).

Предлагаемый путь ведёт прежде всего в Jira Service Management, причём Atlassian описывает автоматизированную миграцию данных и конфигурации (официальная страница миграции). Для многих компаний это разумный маршрут. В моём случае требование было другим: сохранить существующую self-hosted Jira, не превращать замену on-call инструмента в миграцию всей сервисной модели и получить контроль над данными, интеграциями и deployment.

Я посмотрел альтернативы. Ближе всего по общей идее оказался OpsKnight: проект позиционирует себя как open-source self-hosted платформу для incident response, on-call, routing и status pages (официальный сайт OpsKnight). На бумаге соседство было почти семейным. Но мой набор требований включал автоматическое создание задач именно в нашей Jira, Slack и eXpress, прозрачную передачу L2 в L3, русский и английский интерфейс, простое развёртывание и предсказуемое поведение в небольшом внутреннем контуре. В моём тестировании OpsKnight с этим набором не совпал и не дал нужной уверенности. Это не универсальный вердикт проекту, а описание моего опыта и моей планки риска.

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

Дальше начинается фольклор. «Ну это же рестарт, при рестарте всегда так». «Добавьте ретраи на клиенте». «Деплойтесь ночью». Самый частый вариант — на графики просто перестают смотреть в момент выката.

На самом деле rolling update умеет проходить вообще без потерь, и readiness-проба тут ни при чём — она отвечает за другую половину задачи. Потери происходят на выключении подов, и причина в том, что удаление пода — это не последовательность шагов, а гонка.

В небольших проектах инфраструктуру можно создать вручную через веб-интерфейс облачного провайдера. Но если серверов десятки, а окружений несколько (Development, Testing, Staging и Production), ручное управление становится медленным и приводит к ошибкам.

Поэтому часто в современной DevOps-практике используется Infrastructure as Code (IaC) — подход, при котором инфраструктура описывается в виде кода и может быть создана или изменена одной командой. Одним из самых популярных инструментов для этого является Terraform.

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

С момента как появился домашний сервер было желание сделать нормальный медиа сервер - чтобы по красоте смотреть фильмы и сериалы в 4K, без костылей.

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

ConfigMap, Secret, PersistentVolume, PersistentVolumeClaim, Minikube и kubectl — разбираем ключевые механизмы Kubernetes, которые необходимы каждому Junior DevOps. От хранения данных и конфигурации до развёртывания первого приложения.

Дома у меня три ноды kubeadm на мини-ПК. На них живёт медиасервер: Jellyfin, торрент-клиент и сервисы, которые сами находят фильмы и раскладывают их по папкам. Сверху Istio с mTLS, Jenkins, который всё это раскатывает, Prometheus с Grafana, свой Nexus и Vault.

Начиналось всё не с медиасервера. Начиналось с демо-магазина от Google — и полтора месяца я на него потратил, прежде чем понял, что учусь вхолостую.

Про это и статья.

В предыдущих статьях мы познакомились с Docker, научились создавать собственные образы, запускать контейнеры и объединять несколько сервисов с помощью Docker Compose. Теперь переходим к Kubernetes.

Привет от команды Яндекс Практикума! Приёмная кампания в онлайн-магистратуру «DevOps‑инженер облачных сервисов» ИТМО в партнёрстве с Практикумом уже идёт. Рассказываем, что входит в программу, что нужно, чтобы поступить в 2026 году и как устроено обучение. 

Opus 5 не делает Fable 5 ненужным: благодаря вдвое более низкой официальной цене за токен, управляемому effort и близкому уровню возможностей Opus подходит как модель по умолчанию для большинства сложных задач, а Fable — как уровень эскалации для длинных, неоднозначных и дорогих в случае ошибки сценариев. Статья сравнивает цену принятой задачи, публичные рейтинги, работу с данными, fallback и доступ из России, а затем предлагает проверяемую двухуровневую схему маршрутизации.