DevOps FM

DevOps FM празднует! 🎙Завтра, 22.11.25, исполняется 4 года с тех пор, как мы делимся с вами свежими релизами и подборками из мира DevOps и администрирования! Спасибо, что читаете нас, даёте обратную связь в комментариях, ставите реакции и репостите актуальные материалы 💟А мы продолжим совершенствоваться: делать посты еще полезнее и увлекательнее :) Мы всегда рады услышать ваше мнение: по всем пожеланиям и предложениям пишите в комментарии или напрямую → @b_vls. Cделаем DevOps FM лучше вместе 🤝

Сбой Cloudflare, EOL Ingress NGINX и релиз Sprout Свежий новостной дайджест от DevOps FM. ⏺Масштабный сбой в облаке – Cloudflare Cloudflare объявила, что сбой 18 ноября, из-за которого частично не работали ChatGPT, Claude, Spotify, X и другие сервисы, был вызван latent bug в компоненте, который отвечает за защиту от ботов. Пользователи по всему миру наблюдали ошибки 500 Internal Server Error при попытке зайти на сайт. Подробнее о проблеме здесь. ⏺Ingress NGINX уходит в прошлое: что нас ждёт В настоящий момент проект находится на best-effort-поддержке, а уже в марте 2026 года поддержка Ingress NGINX будет остановлена, дальнейшие релизы, исправление багов прекращаются. Репозитории GitHub сохранятся в режиме read-only. SIG Network и Security Response Committee рекомендуют всем пользователям немедленно начать миграцию на Gateway API или другой Ingress-контроллер. Почему – читайте здесь. ⏺Edera выпускает open-source версию Sprout Edera, компания известная своими решениями в области безопасности, такими как Protect Kubernetes, анонсировала выход open-source версии Sprout, загрузчика ОС на базе Rust. По словам Edera, Sprout обеспечивает высокий уровень безопасности, запуск системы за <50 мс и простой механизм управления для любой ОС, про особенности читайте здесь. #Cloudflare #Sprout #Rust #NGINX

Как работать с Docker Networking: концепции и применение 👩‍💻Автор статьи описывает классический случай из практики с Docker: разработчик запускает контейнер, подключается к нему через localhost и…возникает проблема. Веб-сервис развёрнут в одном контейнере, БД — в отдельном. Как настроить сетевое взаимодействие между ними? На деле Docker уже делает всю работу – ниже расскажем об основном, подробнее найдете в статье. 👀Почему проблема возникла? При установке Docker создает дефолтный сетевой мост (network-bridge), где он выстраивает коммуникацию по временным IP таким образом, что многоконтейнерные приложения становятся неудобными: разработчик не находит сервисы по имени, и каждый перезапуск меняет адреса контейнеров. ⏺Как решать? Для устранения проблемы автор предлагает использовать user-defined bridge сети. При создании такой сети Docker автоматически включает внутренний DNS, и контейнеры получают постоянные hostname. Всё, что потребуется от разработчика – запустить контейнеры и подключить их к одной сети, чтобы приложение могло обращаться к базе по имени к БД, независимо от IP и рестарта контейнера. Контейнеры с user-defined bridge

services:
  app2:
    image: nginx
    networks:
      - mybridge

  app3:
    image: alpine
    command: ["sh", "-c", "while true; do sleep 3600; done"]
    networks:
      - mybridge

networks:
  mybridge:
    driver: bridge

Контейнер со статическим IP и объявленная сеть Для выполнения данного решения разработчик создает пользовательскую bridge-сеть с объявленным пулом адресов (subnet) и назначением контейнеру фиксированного IPv4 через ipv4_address. Так, мы обеспечиваем предсказуемую адресацию, полезную для интеграции с системой, которая зависит от IP. При этом сеть сохраняет встроенный DNS Docker, позволяющий обращаться к контейнерам по имени.

services:
  app:
    image: nginx
    networks:
      custom_net:
        ipv4_address: 172.20.0.10

networks:
  custom_net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/24

🚀Вывод: для многоконтейнерных приложений не стоит использовать дефолтный bridge. Создавайте собственные сети или пользуйтесь Docker Compose, чтобы надёжно связать сервисы по их именам, а не по временным IP-адресам. #devops #docker #dockercompose #networking #containers

Как работать с Docker Networking: концепции и применение 👩‍💻Автор статьи описывает классический случай из практики с Docker: разработчик запускает контейнер, подключается к нему через localhost и…возникает проблема. Веб-сервис развёрнут в одном контейнере, БД — в отдельном. Как настроить сетевое взаимодействие между ними? На деле Docker уже делает всю работу – ниже расскажем об основном, подробнее найдете в статье. 👀Почему проблема возникла? При установке Docker создает дефолтный сетевой мост (network-bridge), где он выстраивает коммуникацию по временным IP таким образом, что многоконтейнерные приложения становятся неудобными: разработчик не находит сервисы по имени, и каждый перезапуск меняет адреса контейнеров. ⏺Как решать? Для устранения проблемы автор предлагает использовать user-defined bridge сети. При создании такой сети Docker автоматически включает внутренний DNS, и контейнеры получают постоянные hostname. Всё, что потребуется от разработчика – запустить контейнеры и подключить их к одной сети, чтобы приложение могло обращаться к базе по имени к БД, независимо от IP и рестарта контейнера. Контейнеры с user-defined bridge services: app2: image: nginx networks: - mybridge app3: image: alpine command: ["sh", "-c", "while true; do sleep 3600; done"] networks: - mybridge networks: mybridge: driver: bridge Контейнер со статическим IP и объявленная сеть Для выполнения данного решения разработчик создает пользовательскую bridge-сеть с объявленным пулом адресов (subnet) и назначением контейнеру фиксированного IPv4 через ipv4_address. Так, мы обеспечиваем предсказуемую адресацию, полезную для интеграции с системой, которая зависит от IP. При этом сеть сохраняет встроенный DNS Docker, позволяющий обращаться к контейнерам по имени. services: app: image: nginx networks: custom_net: ipv4_address: 172.20.0.10 networks: custom_net: driver: bridge ipam: config: - subnet: 172.20.0.0/24 🚀Главный вывод: для многоконтейнерных приложений не стоит использовать дефолтный bridge. Создавайте собственные сети или пользуйтесь Docker Compose, чтобы надёжно связать сервисы по их именам, а не по временным IP-адресам. #devops #docker #dockercompose #networking #containers

Пятничная подборка: Jupyter, оптимизация ИИ-нагрузок в Kubernetes и облачные тренды Сегодня в эфире подборка подкастов, в которых эксперты обсуждают эволюцию Project Jupyter, распределение расходов ИИ-сервисов в новой версии Kubernetes, тренды ИИ в облаке. ⏺DOP 324:Kubernetes Resource Right-Sizing and Scaling with Zesty Приглашенный гость Омар Хамерман, IT-архитектор Zesty.co, совместно с ведущими Дарином Поупом и Виктором Фарциком говорят о возможностях управления нагрузками ИИ в Kubernetes версии 1.33. Основное внимание уделяют автоматическому масштабированию. Послушать можно здесь. ⏺From Physics to the Future: Brian Granger on Project Jupyter in the Age of AI Брайн Грэнджер совместно с главным редактором издания The New Stack (TNS) рассмотрели развитие архитектуры Jupyter, построенной на модульных и расширяемых компонентах, роль ИИ-агентов в разработке приложения. Больше подробностей тут. ⏺The CloudCast: AI & Cloud Trends for October 2025 Брайн Грэйсли и Брэндон Уичард разобрали тренды за последний месяц: анонсы от провайдеров, изменения в экосистемах OpenAI и вопросы безопасности облачной инфраструктуры. Подробнее здесь. 🔈Желаем приятного прослушивания и дежурств без алертов! #kubernetes #jupyter #cloud #подкасты

Инфраструктура для ИИ-сервисов: Linkerd получает MCP, Европа — свою LLM, GitHub — центр управления агентами Всем DevOps! По традиции, делимся новостями. В прошлый раз у нас сработал алерт: часть источников устарела. Починили, обновили, задеплоили новую срединедельную подборку — свежие релизы и актуальные данные. ⏺Linkerd — поддержка MCP Buoyant (BTI) объявила о планах добавить в Linkerd поддержку протокола MCP, чтобы сервис-меш управлял агентским ИИ трафиком: обеспечивал наблюдаемость (метрики использования ресурсов, инструментов и запросов), детальную политику авторизации для всех вызовов MCP, и защиту через идентификаторов рабочей нагрузки. По словам компании, это снизит потребность в отдельных прокси и инструментах мониторинга, а больше деталей об анонсе можете найти здесь. ⏺EuroLLM: шаг ЕС к независимой цифровой среде В Европе появился EuroLLM — открытая языковая модель многоязычной (multilingual) LLM, рассчитанная на 24 официальные языка ЕС. EuroLLM подходит для локальных экспериментов, кастомизации и повышенной прозрачности, необходимых в рамках политики повышения цифровой автономности. Подробнее об особенностях здесь. ⏺Agent HQ от GitHub: единый инструмент для работы с ИИ-агентами GitHub запустил Agent HQ – инструмент для работы с ИИ-агентами. Идея проста: вместо работы с каждым агентом отдельно, теперь можно назначать задачи, отслеживать их выполнение и управлять поведением ИИ из одного интерфейса. В ближайшие месяцы на GitHub станут доступны агенты от OpenAI, Google, Anthropic, Cognition и других, всё это в рамках подписки Copilot Pro+. Про формат подписки здесь. #Linkerd #EuroLLM #AgentHQ #DevOps

В гостях хорошо, а дома Astra Linux ⌨️Мир меняется, и мы уже наблюдаем переход с зарубежного софта на российские программные разработки. Сегодня поговорим об одной из альтернатив: отечественная ОС Astra Linux. В чём особенность? Astra Linux – первая в топ-5 ОС по результатам рейтинга cnews. Из параметров оценки у Астры высокое количество партнерских совместимых программных продуктов, максимальный уровень безопасности (ФСТЭК, встроенные СЗИ), что обеспечивает стабильность работы ИТ-структур. ❔В каких вариантах представлена? ⁃ Astra Linux Common Edition, ОС общего пользования, доступная для физических лиц, неактуальна, не получает обновления. Более подробную информацию по установке и настройке читайте здесь ⁃ Astra Linux Special Edition, ОС специального назначения, подходит для различных процессорных архитектур: Х86-64, ARM, «Эльбрус». Для желающих узнать об установке, настройке и сопровождении – справочная здесь. Ниже речь пойдет именно об этом варианте ОС. ⬇️Как установить? Перед началом работы потребуется компьютер для загрузки ISO-образа и записи технологического диска на USB-накопитель. ⁃ Подключите USB-накопитель к компьютеру ⁃ Скопируйте ISO-образ технологического диска на USB Для Astra Linux используйте команду: sudo dd if=<имя_ISO-образа> of=/dev/<имя_накопителя> ⚙️Как настроить Astra Linux? ⁃ Войдите в сессию администратора с высоким уровнем целостности. ⁃ Подключите USB-накопитель с ISO-образом технологического диска. ⁃ Примонтируйте накопитель: sudo mount /dev/sdb1 /mnt ⁃ Выполняйте сценарии настройки (USB-накопитель примонтирован в /mnt) 📎Что дальше? Как осуществить индивидуальную настройку пользователей читайте тут Данные о настройке модельного подключения найдёте здесь Что думаете об отечественных ОС? Насколько интересны обзоры Альта, Ред ОС и ОСновы?

Когда стоит внедрять mypy в Python-проект? 👤В продолжении темы поста о типизации и контроле скриптов, публикуем обсуждение на Reddit: имеет ли смысл подключать type hints и mypy или проще с самого начала выбрать язык со статической типизацией? Что говорят коллеги?

Tinche_: Невозможно свести всё к одному аргументу — слишком много переменных. Python — не только про динамическую типизация. Был у меня случай, руководил крупным проектом с десятками миллионов долларов прибыли. В ходе работы я мигрировал от неаннотированного кода к почти полной типизации на уровне аннотаций с mypy. Получил с этого плюшки, но для такого перехода опыт и план обязательны IWasGettingThePaper: Типы не устраняют баги навсегда и не заменяют тесты. MyPy помогает выявить часть ошибок, не так много, как хотелось бы, и улучшает читаемость кода, но статическая проверка — не серебряная пуля DadAndDominant: Как человек не рождается взрослым, так и компании развиваются постепенно. На старте важнее всего быстрое прототипирование, пусть даже что-то работает лишь в 90% случаев — это всё равно позволяет выпускать продукт. Когда проект разрастается, увеличивается кодовая база, нанимаются новые люди, а технический долг начинает съедать время разработчиков, приходят автоматические тесты, гайды по стилю и mypy — без них уже сложнее нормально релизить. Ну и есть другие факторы при выборе языка, так что всё зависит от контекста.

💬Итак, никаких категоричных решений, только прагматичный подход: продолжайте использовать Python из-за широкой экосистемы и доступности специалистов, а type hints и mypy внедряйте по случаю, когда проект масштабируется, растёт команда и требуется предсказуемость. На каких этапах вы внедряете type hints и mypy? #Python #mypy #reddit

Что нового в релизах и инструментах: Vitess, Copilot и Monarch 🚀Традиционно публикуем срединедельный дайджест новостей, чтобы оставаться в курсе важных обновлений. ⚫️ Vitess 23.0.0 — операционная наблюдаемость и стабильное масштабирование Команда Vitess представила новую основную версию популярного CNCF-проекта для масштабируемых MySQL-кластеров. Релиз Vitess 23.0.0 продолжает линию версии 22 и направлен на упрощение развертывания, повышение стабильности и наблюдаемости в больших инфраструктурах: переход на MySQL 8.4.6; TransactionsProcessed для VTGate, SkippedRecoveries для VTOrc. Подробности обновления читайте в статье блога CNCF. 🟡 GitHub Copilot CLI: ускорение работы с репозиториями В Copilot добавлена поддержка CLI с доступом к репозиториям, возможностью редактировать файлы, запускать команды и интеграцией с GitHub через учётную запись. Параллельно представлены Copilot Spaces Copilot Spaces — контекстные «пространства» с документацией, примерами и задачами, которые дают агенту релевантный контекст для команды и ускоряют онбординг; CLI и Spaces поддерживают MCP-серверы и смену модели. Всё про GitHub Copilot CLI и Spaces здесь. ⚫️ PyTorch — Monarch упрощает разработку распределённых ML-программ PyTorch представила Monarch — фреймворк для распределённого программирования, который позволяет работать с целыми кластерами GPU. Monarch упрощает разработку распределённых ML-программ: код остаётся похожим на обычный Python/PyTorch-скрипт, при этом масштабируется на тысячи GPU, облегчая написание распределённых алгоритмов, обработку сбоев и управление ресурсами. Читайте статью здесь. Стабильных кластеров и эффективного онбординга команды!🤝 #Vitess #Observability #Copilot

Приглашаем на IT-link 2025 — крупнейшую региональную конференцию 💬Эксперты из бигтеха на площадке IT-link 2025 расскажут о передовых практиках, трендах и решениях в IT-индустрии. В рамках программы коллеги поделятся деталями кейсов по следующим направлениям: ➖ Analytics — Big Data, DWH, аналитика данных и системный анализ; ➖ Product & Design — product-management, Product Design, UX / исследования; ➖ Development — frontend-разработка; ➖ Информационная безопасность Особенно актуально для сезона высоких нагрузок — доклады по HighLoad. 📅 Когда: 8 ноября, 09:30 📍Где: Театр юного зрителя им. Михаила Сеспеля, г. Чебоксары 👤Формат: офлайн Регистрация открыта — участие бесплатно (места ограничены)🚀 Организатор конференции: компания Лайм Эйч Ди #партнёрский_пост

mypy в Python: типизация и контроль скриптов 👩‍💻Сегодня обсудим, как встроить ad-hoc скрипты из ~/bin в предсказуемую и проверяемую автоматизацию. В статье Simple Thread Джо Понд дал руководство по снижению риска ошибок. В чем кроется проблема? • Скрипт удобен, но непредсказуем: ошибки типов проявляются только во время выполнения. • Без явных контрактов функций рефакторинг становится рискованным, растёт технический долг. • Чем больше людей правят код, тем выше риск регресса и скрытых багов в проде. Какие решения? Пошаговое улучшение надежности кода: добавьте статическую типизацию через mypy, управляйте зависимостями через Poetry и запускайте проверки в CI. Так, вы постепенно укрепляете код и минимизируете риски, когда проект расширяется и подключаются новые разработчики. Как внедрить? Проверка типов на старте — один файл за раз • Добавьте в dev-dependencies:

poetry add --group dev mypy

• Запустите проверку для конкретного файла:

poetry run mypy main.py

Так, вы находите баги до запуска и спокойно приступаете к следующему шагу. Добавьте mypy в CI/CD • Создайте окружение через Poetry и проверьте проект mypy

poetry run mypy .

Типы проверяются в пайплайне: ошибки останавливают merge и защищают main branch от багов. Мигрируйте постепенно • Переносите типизацию модуль за модулем, начинайте с ключевых утилит и точек входа. • Нет необходимости переписывать весь проект сразу — можно внедрять статическую проверку там, где она реально нужна. Для желающих узнать историю развития Python рекомендуем прочесть статью здесь 👈 Делимся подборкой репозиториев: 👩‍💻python/mypy — анализирует типы для Python, реализует PEP 484. Нужен как эталонный инструмент для проверки контрактов и постепенной типизации кода. 👩‍💻 tsuyoshicho/action-mypy — готовая GitHub Action для запуска mypy в CI; поддерживает вывод в формате JSON, удобно для интеграции с reviewdog и системами агрегации ошибок #devops #python #mypy

Какие призраки прячутся в API? В прошлом мы рассказывали о зомби-ресурсах, сегодня поговорим о приведениях. 👻Призрачные API — это эндпоинты, о которых команда уже не помнит: устаревшие версии API, тестовые и предрелизные окружения, временные debug -эндпоинты, внутренние маршруты, неиспользуемые SDK-колбэки или микросервисы без владельца. Такие точки входа остаются живыми, но не попадают в мониторинг и тесты — поэтому злоумышленники ищут их в первую очередь. Как обнаружить: • анализ кода и скрытых маршрутов; • перебор и сравнение версий API; • следы в логах, документации и старых тестах. Как изгнать: • Инвентаризация: централизованный каталог API (Swagger/OpenAPI, Postman). • Политика «Убей, не прячь»: полностью удаляйте ненужные маршруты, не переименовывайте. • Владение: у каждого эндпойнта — владелец и SLA; без владельца — автоматическое выключение. 👀Подробности читайте в статье Medium Делимся подборкой инструментов-охотников: Pluto — CLI-утилита для обнаружения устаревших/удалённых версий API в Kubernetes-манифестах или кластере Kubent — аналогично Pluto, CLI-инструмент для K8s. Проверяет кластер и исходники на использование Ghost=deprecated API 👻Пусть ваши релизы проходят без мёртвого кода и призрачных эндпойнтов #DevOps #Security #API

От Talos до Vault: обзор обновлений инфраструктуры и секретов Срединедельный DevOps! Публикуем дайджест релизов и новостей. ⚫️ Talos OS и Kubernetes: операционная выгода и риски SNCF разворачивает Kubernetes с Talos OS в OpenStack, чтобы повысить безопасность узлов, стандартизировать образы и упростить автоматизированное развертывание. Переход потребовал создания новых облачных команд и внедрения практик GitOps с неизменяемой инфраструктурой. Подробнее в статье. 🟡 Разбираем Vault 1.21 — SPIFFE, VSO и granular recovery в действии Vault 1.21 добавил SPIFFE-аутентификацию для рабочих нагрузок без участия инженеров, детализированное восстановление секретов (granular secret recovery), настройку TOTP и защищённую выдачу секретов через VSO — доставку данных в поды без сохранения в etcd. Среди улучшений — движение к сертификации FIPS 140-3 уровня 1. Разбираем, как Vault 1.21 меняет подход к управлению идентичностями и секретами. ⚫️ Корпоративная почта — быстрый техобзор и что проверить Обновлённое руководство: читаем зачем бизнесу доменная почта, как выбрать между облачным сервисом, хостингом и собственным сервером, а также какие настройки помогают избежать попадания писем в спам. Для DevOps-специалистов полезно с точки зрения конфигурации DNS, контроля безопасности и стабильности почтовой инфраструктуры. Что проверить – в статье. 🔓Безопасных запусков и прозрачного управления секретами #DevOps #Vault #TLS #EmailSecurity

Приглашаем на вебинар коллег из «Экспресс 42»: State of DevOps Russia 2025 ☝️31 октября в 12:00 онлайн состоится разбор результатов исследования российского DevOps-рынка, основанного на опросе более 4000 специалистов. Эксперты представят актуальные тенденции и данные, влияющие на эффективность разработки и опыт специалистов при работе с инфраструктурой. ➖Developer Experience и эффективность команд. Какие практики повышают продуктивность разработки. ➖ИИ и DevOps. Реальные области применения ИИ-инструментов. ➖Информационная безопасность. Методы интеграции ИБ в процессы разработки. ➖Внутренние платформы и Kubernetes. Цели развития и подходы к платформенной инженерии. ➖Рынок труда. Изменения в ролях специалистов и динамика зарплат за год. ⏺ Регистрация открыта Увидимся на вебинаре 🚀 #партнёрский_пост

Docker vs. Kubernetes — от изолированных контейнеров к единой среде 🔄Сегодня разбираем, почему одного контейнера недостаточно для обмена данными между процессами внутри Pod. Контейнер запускает приложение как отдельный процесс: отдельный сетевой стек (IP, интерфейсы и маршруты), своё PID-пространство и управление ресурсами через cgroups (CPU и память). Эти механизмы изолируют и сохраняют предсказуемость работы — один процесс, один контейнер. На практике несколько процессов работают параллельно, обмениваются данными и используют общие ресурсы. Например, основной контейнер выполняет приложение, а вспомогательный (sidecar) собирает логи, проксирует трафик или ведёт метрики. 📱В статье от iximiuz Labs дан подробный разбор того, как Kubernetes реализует Pods на уровне Linux и можно ли воспроизвести функциональность Pod в чистом Docker. Спойлер: можно, если вручную подключить сетевые и IPC namespace, но не всё получится — UTS, например, остаётся изолированным. Полный разбор здесь ⬅️, а ниже — практика от iximiuz Labs • Run a Sidecar Container in the Namespace of Another Container— проверь, как контейнеры делят namespace, как в Pod. • Limit CPU and Memory Usage of a Docker Compose Application — узнай, как задать лимиты CPU и памяти через cgroups. #devops #kubernetes #containers #pods

Helm исполнилось 10 лет! 🔅Это повод вспомнить, как всё начиналось. Идея родилась во время хакатона: за полтора дня Мэтт Бутчер создал CLI-утилиту для взаимодействия с Kubernetes, Джэк Норман разработал серверный прототип менеджера пакетов k8space, а Римантас Моцевичюс подготовил первый чарт — набор шаблонов YAML. 19 октября 2015 года был сделан первый коммит. Так появился внутренний проект Helm Classic, который объединили с Google Deployment Manager. После этого появился Helm, знакомый нам сегодня. За десять лет инструмент прошёл путь от прототипа до полноценной экосистемы с поддержкой: • чартов (пакетов с шаблонами YAML) • системы репозиториев и версионирования • шаблонизации и параметров конфигурации • управления релизами и откатами • интеграции в CI/CD В 2018 году проект вошёл в состав CNCF и продолжил развиваться как одно из ключевых решений для cloud-native инфраструктур. О названии. 🖼️Выбор был сделан не случайно: helm – «штурвал». Kubernetes казался штормовым морем, а инструмент – помощником в управлении. Для тех, кто любит погружаться в историю – советуем прочесть очерк сооснователя, путь от альфы до v4 Beta Glory. Хороших выходных и спокойного дежурства! ⚓️ #devops #kubernetes #helm

Тренды облачной инфраструктуры 2025: ИИ, безопасность и зрелость платформенной инженерии 🌐Облачная экосистема развивается неравномерно: компании активно внедряют ИИ и контейнеры, но сталкиваются с нехваткой зрелых практик защиты и управления. С Bell Integrator разобрали данные опроса F5 NGINX 2025, в котором приняли участие специалисты в области ИТ, безопасности и разработки ПО. Ключевые тенденции вынесли в подборку выше ⬆️ 🚀Главный вывод F5: технологии для устойчивой, умной инфраструктуры уже существуют. Теперь важно не добавлять новые инструменты, а научиться управлять теми, что есть — с фокусом на безопасность, наблюдаемость и зрелые инженерные процессы. Больше о трендах узнаете в Bell Integrator. Как вы видите развитие облачной инфраструктуры к 2025 году? #DevOps #CloudNative #AI

Макросы в коде: что стоит учитывать при ревью и CI/CD 👩‍💻Линус Торвальдс прошёлся по коду, где был предложен макрос make_u32_from_two_u16()— инструмент для объединения двух 16-битных чисел в одно 32-битное. На первый взгляд, решение удобно, но Линус назвал реализацию "мусорной": такая абстракция усложняет понимание и сопровождение кода. Как улучшить код и ревью ⏺Используйте явную запись Прямое выражение показывает порядок и логику:

((uint32_t)a << 16) | (uint32_t)b

⏺Добавляйте абстракции только при необходимости Макросы и функции избавляют от дублирования или повышают безопасность, а не просто «упаковывают» очевидные выражения. ⏺Следите за переносимостью Добавляйте приведения типов и маскирование, чтобы избежать ошибок на разных архитектурах:

#define MAKE_U32_FROM_TWO_U16(high, low) \
    (((uint32_t)(high) << 16) | ((uint32_t)(low) & 0xFFFF))

⏺Сохраняйте ясность и локальность изменений Если нужна общая утилита — поместите её в отдельный модуль и документируйте назначение. Так, вы снижаете вероятность конфликтов и улучшаете читаемость кода. ⏺Используйте ИИ-инструменты осознанно Генераторы кода (ChatGPT, Gemini и пр.) могут предложить готовое решение, но итоговый вариант важно проверять: читаемость, переносимость, соответствие стилю проекта — всё это остаётся задачей разработчика. Даже небольшие абстракции требуют осознанного подхода. Если операция проста, прозрачна и понятна, лучше записать её явно. Так, код становится надёжнее, ревью — быстрее, а CI/CD-процессы — стабильнее. #DevOps #Linux #CICD

Пятничная подборка подкастов: от AI в инфраструктуре до архитектурных решений 🗣В эту пятницу будет, что послушать DevOps-инженеру. Делимся свежей подборкой подкастов. ⏺Готова ли инфраструктура к AI? Разбираем на практике — DevOps Paradox #319 Ведущие Дарин Поуп и Виктор Фарчик подчеркивают, разницу между ожиданиями разработчиков AI-платформ и реальностью на примере кейсов. Главным барьером в работе они называют отсутствие опыта взаимодействия с агентами и векторными базами данных. ⏺Workload identity: меньше ручного контроля, больше прозрачности — Day Two DevOps #284 Ведущий Нед Беллаванс и гость Кристиан Поста обсуждают, как сервисы и агенты взаимодействуют между собой без участия человека. Разбирают, как работают workload identities — цифровые удостоверения, по которым системы подтверждают подлинность и права доступа друг к другу. ⏺Лидерство и инженерные решения — Azure & DevOps Podcast Джимас Стейли беседует с Джонатаном Джей Тауэром, Microsoft MVP и основателем Trailhead Technology Partners о том, как техническим лидерам принимать осознанные решения, исходя из целей продукта. Говорят о кейсе, в котором отказ от микросервисов в пользу простой архитектуры ускорил релизы и снизил затраты на поддержку. 👍Пусть сервисы не падают, а кофе не заканчивается! Хороших выходных и приятного прослушивания. #devops #подкаст #AI #лидерство