DevOps для ДевоПсов

В каком порядке что изучать в девопсе? Популярных роадмапов куча, идеального нет. roadmap.sh/devops — самый полный по охвату, но это гигантская интерактивная карта без чёткого порядка: открываешь и тонешь в сотне тем. github.com/milanm/DevOps-Roadmap — выглядит всё очень уверенно и как будто свежее, но в реальности чел просто обновил заголовок на 2026 год, а внутри всё ещё лежит информация например про Puppet. devopsroadmap.io — интереснее по подходу: итеративное обучение через сквозной проект, GitOps и security подаются как база, есть ветки роста (SRE, Platform Engineering, MLOps). Но внутри скорее каркас со ссылками, чем полноценный контент. Сетей нет, Ansible нет, облако обзорно. Как навигатор сгодится. Что реально нужно в 2026 и чего нет ни в одном роадмапе целиком: GitOps (Argo CD/Flux), Platform Engineering, FinOps для больших, OpenTelemetry. Secrets management (Vault, External Secrets) — это вообще первое, что настраиваешь на проекте. Тему AI в пайплайне генераторы контента тоже пока не научились системно покрывать. Есть курс Яндекс Практикума PRO «DevOps для эксплуатации и разработки». Он хорошо закрывает ядро: Git с Git Flow, GitLab CI, Terraform, Ansible, Docker, Kubernetes, мониторинг (Prometheus + Grafana + Loki), CD с rollback и feature flags, DORA-метрики. Финальный проект в Yandex Cloud с фидбеком от эксперта. Чего курс не даст: обучение программированию, GitHub Actions, GitOps/Argo CD, Kustomize, облачный провайдер системно (AWS/Azure/GCP), supply chain security, тестирование как дисциплину. Это придётся добирать самостоятельно, как и фундаментальные знания по сетям (не знаю, почему к ним сейчас так мало внимания). Если нужна структура с менторством — курс + параллельно по roadmap.sh ходить в ширину и в глубину. Если умеете планировать обучение и пинать себя самостоятельно — документация, домашний кластер в minikube и реальные проекты на GitHub закроют 80% потребностей.

Health Score для PostgreSQL: один показатель вместо 150 метрик В традиционном мониторинге PostgreSQL сотни метрик, но нет ответа на вопрос «база здорова?». CPU 60%, connections 50%, idle in transaction 40% — ни один порог не пробит, но база тормозит. Health Score агрегирует пять категорий (Connections, Performance, Storage, Replication, Maintenance) в число от 0 до 100 с нелинейными штрафами за опасные комбинации и автодиагностикой: список проблем и готовые рекомендации. Для дежурного инженера это первый экран вместо десятков дашбордов. Система учитывает исторический baseline, поэтому аномалия определяется не по жёсткому порогу, а по отклонению от обычного поведения. Подробнее о формуле и внедрении — в статье: https://habr.com/ru/articles/1016288/

Распространенный миф о Kubernetes звучит так: платформа подходит только для работы с контейнерами. На самом деле, с ее помощью можно управлять сертификатами, DNS, сетями, хранилищами.

А ещё, по исследованиям, 74% компаний уже запускают stateful-нагрузки в Kubernetes. По сути, это универсальный оркестратор для инфраструктуры, а контейнеры — просто самый известный его use case.

Из этого следует неочевидный вывод: Виртуальные машины в Kubernetes — логичное расширение того, что платформа уже умеет. Павел Тишков, технический директор Deckhouse Virtualization Platform, на Deckhouse Conf покажет, как сделать ВМ надёжными, с живой миграцией и привычными абстракциями → [Зарегистрироваться] А остальные мифы про Kubernetes — в карточках к посту. Это #партнёрский пост

База

Вебинар по Observability: «Grafana Stack — закрываем все современные потребности Observability» На вебинаре вы получите: 🔘 Обзор инструментов Grafana Labs: Alloy, Loki, Tempo, Grafana. 🔘 Разбор схем возможного масштабирования инструментов Alloy, Loki, Tempo, Grafana. 🔘 Практику: в виде построения наглядной системы мониторинга. Что вам даст вебинар: ⚡️Понимание, как Grafana Stack закрывает все три столпа Observability: метрики, логи и трассировки. ⚡️Навыки быстрой настройки и адаптации Grafana под свою инфраструктуру. ⚡️Практические советы по развертыванию инструментов Grafana Labs для полноценной Observability-платформы. ➡️ Для участия зарегистрируйтесь 📎Все участники вебинара получат специальные условия на полное обучение курса «Observability: мониторинг, логирование, трейсинг». На курсе от OTUS вы освоите инструменты, без которых не обходится ни один DevOps или системный администратор: Prometheus, Grafana, ELK, Tempo и другие. Вы научитесь выстраивать наблюдаемость под ключ — от сбора метрик до настройки алертов и визуализации данных. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

jsongrep — быстрее чем jq, jmespath, jsonpath-rust и jql? Студент вдохновился историей рипгрепа и сделал инструмент для поиска значений в JSON-документах. Концептуально он делает то же, что и grep для текста: скармливаете JSON, даёте паттерн, получаете все значения, пути к которым попадают под этот паттерн («достань мне все поля error из логов за сегодня»). Язык запросов выглядит как смесь JSONPath и регулярных выражений. Если вы когда-нибудь писали регулярки для путей в файловой системе или URL, то тут всё очень похоже, только вместо символов у вас ключи и индексы. Зачем это нужно Если вы работаете с большими JSON-файлами, то рано или поздно сталкиваетесь с задачей «достань мне все значения по такому-то пути». jq для этого подходит, но он тяжеловесный: это полноценный язык трансформации, интерпретатор, который на каждом шаге оценивает выражения, проверяет условия, рекурсивно обходит дерево. Для простого поиска это оверкилл. jsongrep сознательно ограничен: он не умеет трансформировать данные, нет арифметики, нет фильтров, нет строковой интерполяции. Зато за счёт этого он работает на порядок быстрее на больших документах, что подтверждают бенчмарки автора: на 190-мегабайтном GeoJSON файле он обходит jq в end-to-end тестах с внушительным отрывом. Кейсы применения — Анализ логов в JSON-формате. jsongrep с флагом -F делает рекурсивный поиск поля на любой глубине одной командой. — Работа с API-ответами. curl + jsongrep быстрее, чем открывать Postman или писать jq-ванлайнер для простой выборки. — GeoJSON и прочие большие структурированные файлы. Например для городских служб, геодезистов, GIS-специалистов, которым нужно быстро извлекать данные из таких файлов без загрузки всего документа в память. Почему так быстро Автор учил теорию автоматов, технические детали можно почитать в статье. Если упростить, нет никаких if-else цепочек, нет рекурсивного спуска с проверкой условий на каждом узле. Неподходящая ветка дерева отсекается за O(1) — просто нет перехода в таблице. Есть и цена за эту скорость: компиляция запроса в DFA занимает время. На маленьких документах jq может оказаться быстрее просто потому, что не тратит время на построение автомата. Но на документах от мегабайта и выше jsongrep начинает выигрывать. Инструмент новый, студенческий, в бою ещё не протестирован, но как минимум ставим лайк за научный подход. https://github.com/micahkepe/jsongrep

Вы знаете, сколько у вас уходит на облачную ИТ-инфраструктуру и как распределяются эти расходы? Шаблон первичного аудита от Клаудмастер за 5 минут помогает: — разложить расходы по структуре — проверить полноту данных — выявить точки экономии Подойдёт: — техническим директорам и системным администраторам — финансовым специалистам — менеджерам по продукту Скачать шаблон бесплатно ФинОпс (FinOps, от англ. Financial Operations, методология управления расходами на ИТ-инфраструктуру) позволяет связать расходы с командами, сервисами и продуктами и сделать их управляемыми. Сравните управляемость и прозрачность расходов до и после внедрения ФинОпс! Это #партнёрский пост

Подъехал обзор по Trivy с инструкциями https://tproger.ru/articles/ataki-na-trivy--kak-skaner-uyazvimostej-stal-vektorom-ataki-i-chto Псам предлагаю проверить, всё ли вы учли и обновили А пёсикам разобраться, что вообще происходит 🥺

Линуксоид с гигантским стажем решил волевым усилием поломать свои привычки и заменить coreutils на фэнси тулзы. В комментарии набежали холиварить про надёжность vs эргономичность, но сначала вот пять замен, которые коллективно сочли достойными: cat → bat ибо встроенная подсветка синтаксиса, нумерация строк и адекватный пейджинг; ls → eza, потому что позволь себе уже полюбить цветовое кодирование и иконки; find → fd за интуитивный синтаксис и быструю выдачу; grep → ripgrep опять же из-за скорости; top → btop для комплексного мониторинга ресурсов, хоть btop и перегружен визуально. Дальше на ночь пятничная сказка про холивар. Базовый набор GNU coreutils создавался в эпоху, когда деревья в файловых системах были маленькими, а ресурсов не хватало ни на что лишнее. Синтаксис классического find до сих пор вызывает нервный тик, а чтение логов через cat без подсветки пора признать формой легкого мазохизма. Современный подход предлагает инструменты, которые написаны преимущественно на Rust и делают ровно то же самое, но с человеческим лицом. А ещё они работают быстрее и прямо из коробки понимают правила .gitignore. В подобных обсуждениях всегда появляется Суровый Системный Администратор Старой Школы и настаивает, что все эти цветастые игрушки абсолютно бесполезны при заходе по SSH на боевой сервер. Там тебя встретит голый bash и девственно чистый vi. В ответ на это в него кидаются терраформами и ансиблами и спрашивают, а зачем мол вообще в наше время ходить на продакшен по ssh?

Пожалуй, единственное здравое правило, которое можно вынести из этого противостояния: как только дело доходит до автоматизации и bash-скриптов, надо возвращаться к POSIX-совместимым конструкциям и классическим coreutils, иначе автоматизация сломается на первой же машине.

Вообще этот нудный пост о старой статье был ради подводки к ещё более старому мему

Тут снова всплыла та самая статья про исход из облаков от создателя Ruby on Rails. Если не читали, основная мысль сводится к тому, что для компаний среднего размера со стабильным ростом аренда чужих серверов обходится неоправданно дорого. По логике Дэвида облако незаменимо только в двух случаях: — либо ты делаешь стартап с нулевой базой и тебе критически важна скорость запуска без возни с инфраструктурой; — либо у тебя случаются дикие непредсказуемые скачки нагрузки, как у них было на старте HEY с наплывом сотен тысяч пользователей. В остальных ситуациях компания просто оплачивает маржинальность провайдера в районе тридцати процентов, покупая «страховку от землетрясения» в регионе, где их никогда не бывает, и продолжает поддерживать штат своих инженеров. Дак вот, статья продолжает всплывать на протяжении 3+ лет, потому что проблемы-то никуда не делись. Конечно, никто не хоронит облака окончательно, но как будто бы иллюзия того, что передача инфраструктуры на аутсорс решит все технические проблемы, развеивается для всё большего количества людей.

22 апреля в Москве пройдет конференция по искусственному интеллекту «MLечный путь» Это мероприятие от облачного провайдера Selectel для тех, кто не просто следит за хайпом вокруг ИИ, а внедряет модели в продакшн или управляет этим процессом. Программа разделена на два трека: для бизнеса и для технических специалистов. В техническом блоке доклады про: — Выбор серверного железа под разные типы ИИ-нагрузок. — Особенности SDLC для вероятностных систем. — Безопасность при использовании генеративных технологий в рабочих процессах. — Как сочетать инференс классических моделей и LLM на одной платформе. В бизнес-треке — темы про окупаемость, риски и дорожные карты внедрения. Участие бесплатное, но количество мест ограничено.Подробная программа и регистрация — на сайте мероприятия. Это #партнёрский пост

Оказывается, людей всё ещё просят инвертировать бинарные деревья на доске при найме на позиции DevOps или Platform Engineer. Видимо, мы в 2026 должны уметь поисковики с нуля писать. Хотя куда показательнее попросить написать скрипт для парсинга логов или сортировки тысяч файлов в S3 по бакетам. Уважаемые HR и нанимающие менеджеры, если хочется проверить экспертизу, обсуждайте архитектуру и траблшутинг: — Базовые принципы CAMS — Метрики DORA вроде Deployment Frequency и Change Failure Rate — Понимание подкапотной магии Ansible, Jenkins и Helm — Практичные паттерны: GitOps, Policy-as-code, стратегии релизов И вообще, в моём мире адекватное техническое интервью больше похоже на совместный разбор инцидента, а не на экзамен по академическому Computer Science.

Вебинар по Observability: «Поиск и устранение проблем в системе мониторинга Zabbix» На вебинаре вы узнаете: 🔘типичные проблемы и антипаттерны в Zabbix, которые ломают мониторинг; 🔘 как диагностировать ошибки конфигурации и находить узкие места; 🔘 практики настройки Zabbix для стабильной и предсказуемой работы; 🔘 как сделать мониторинг полезным инструментом, а не источником шума. Что вы получите: — понимание архитектуры и принципов работы Zabbix; — павык быстрого поиска и устранения проблем в системе мониторинга; — практические подходы, которые помогут избежать типичных ошибок. 📎 Для участия зарегистрируйтесь ⚡️ Все участники вебинара получат специальные условия на полное обучение курса «Observability: мониторинг, логирование, трейсинг» На курсе от OTUS вы освоите инструменты, без которых не обходится ни один DevOps или системный администратор: Prometheus, Grafana, ELK, Tempo и другие. Вы научитесь выстраивать наблюдаемость под ключ — от сбора метрик до настройки алертов и визуализации данных. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Реддитор проанализировал 1.6 миллиона Git-событий и показал, как бесконтрольное использование ИИ в разработке ломает привычные процессы и замедляет поставку продукта. Основные выводы: — ИИ увеличивает общий объем написанного кода примерно на 55%. — Без расширения штата QA чистая скорость доставки падает до 0,85 от изначальной, то есть команда работает медленнее, чем до внедрения ИИ. — Добавление всего одного выделенного тестировщика возвращает скорость к отметке 1,32 с окупаемостью 18 к 1. — Юнит-тесты показали самую низкую эффективность, так как ИИ часто просто переписывает их под свои же баги. Математическая модель автора показывает, что качество любого этапа проверки падает экспоненциально при росте объема кода. Когда на ревьюера сваливается постоянный поток пулл-реквестов, вдумчивая проверка быстро сменяется автоматическим одобрением, что в комментариях метко назвали ✨вероятностным продакшеном✨. Проблема сильно усугубляется отложенным эффектом. На первых этапах менеджмент видит только рост числа слитых веток и считает внедрение успешным, пока баги незаметно накапливаются в системе. Со временем исправление ошибок начинает отнимать абсолютно все ресурсы разработчиков, и проект сталкивается с серьезными сбоями под нагрузкой. Один из комментаторов поделился рабочим решением: — Сделать CI-пайплайн первым и главным ревьюером. — Внедрить property-based тесты и мутационное тестирование на критичных участках. — Добавить строгий статический анализ, который автоматически отклоняет пулл-реквесты со слишком большим охватом изменений. Такой подход отсеивает большую часть проблемного ИИ-кода до того, как он попадет к живому человеку. В результате объем ручной проверки снижается примерно на 60%, что позволяет ревьюерам сохранить фокус на сложной бизнес-логике и спасает от выгорания. Ссылка на обсуждение: https://www.reddit.com/r/devops/comments/1rrrj0v/i_analyzed_16m_git_events_to_measure_what_happens/ Само исследование с воспроизводимыми скриптами: https://zenodo.org/records/18971198

Как ML помогает тестировать то, что нельзя предсказать вручную? В новом материале — кейс о том, как спроектировать систему динамической генерации тестовых сценариев для транспортного проекта. За основу взято имитационное моделирование с элементами ML. В статье подробное описание архитектуры решения: — пайплайн из Great Expectations, Evidently AI, DVC и Airflow; — три слоя данных: продовые срезы, обезличенные профили и «мутации» аномалий от ML; — а еще швейцарский сыр. Как он там оказался, читайте в статье.

Архитектура, безопасность, импортозамещение — вам на какую тему доклад? Давайте честно, обычно на большую конференцию идут за одной-двумя темами, ради которых готовы потратить время. Остальные доклады идут фоном. На DeckhouseConf вы тоже можете выбрать для себя фаворитов и сходить только на них, но советуем успевать везде. Программа закроет основные боли DevOps-инженеров и архитекторов. Вот четыре основных трека: Сеть и виртуализация

Если вам когда-либо не хватало возможностей стандартной сети Kubernetes или вы задумывались, как запихнуть виртуальные машины в кластер и не сойти с ума, то вам на доклады «Путь к SDN», «Делаем нормальные виртуалки в K8s».

Безопасность и compliance

Если надоело платить «налог на безопасность» ресурсами и нервами, то вам на доклад Никиты Ладошкина, руководителя разработки PT Container Security в Positive Technologies.

Миграция и импортозамещение

Если перед вами стоит задача переехать на современную архитектуру без остановки процессов, то приглядитесь к докладу о миграции критической госсистемы с Oracle на Deckhouse.

Платформа и разработка

Если вы строите внутреннюю платформу и думаете, как ускорить разработку, не потеряв контроль над архитектурой. Доклады: про микросервисы и DDP.

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

Что сейчас происходит в сфере антифрода К 2026 году мошенники тоже освоили генеративный ИИ. Вместо физических подделок они синтезируют изображения на основе утекших данных пользователей, заваливая банки тысячами фальшивых документов разного качества, авось прокатит. И в ряде случаев действительно прокатывает, потому что системы защиты тоже несовершенны. Рынок пытается справиться с этими бедами: у нас на сайте вышел емкий разбор современных трендов антифрода. В статье разбирают, как эволюционировали подделки документов, из-за чего тормозится разработка средств защиты, а также какие модели считаются одними из самых прогрессивных. Если хотите чек-лист антифрода 2026, вам сюда: https://tprg.ru/NCku

Победителями премии Тпрогер 🐀становятся... Здесь играет барабанная дробь и интригующая музыка... Вам нужно только выждать драматическую паузу перед объявлением победителей — в каждой номинации он один, и определяется большинством голосов. Готовы? В номинации «Продукт года» золотая мышь достается компании: 🐀NetVision за платформу интеллектуального мониторинга СИМ. В номинации «Облачный продукт года» побеждает компания: 🐀Гравитон с паком виртуализации «Гелиус» Звание «IT-ивент года» вручается компании: 🐀Островок! за О!Хакатон И в категории «Дизайн года» первое место занимает компания: 🐀AcademiaDev за интерактивную инсталляцию. Каждый ваш лайк, голос влияли на исход премии. Давайте поддержим всех — ставьте 🏆участникам, которые хоть и не заняли призового места, но точно остались в сердечке. И 🔥, если хотите аналогичных активностей и готовы выбирать еще!

Микросервисы — это модно, но нужно ли это вам? Спор что лучше, монолит или микросервисы, уже набил оскомину. Поэтому поставим вопрос по-другому: когда микросервисы начинают окупаться? При каком размере команды, количестве сервисов и частоте релизов? Делитесь опытом: у кого был удачный (или провальный) переход? На конференции DeckhouseConf теме микросервисов уделены аж два кейса, можно будет узнать, как стандартизировать инфраструктуру, выстроить процессы CI/CD для разработки, повысить надёжность сервисов и снизить операционные трудозатраты. Приходите за подробностями.