🔐 Всем пятничный DevOps! Сегодня делимся небольшой подборкой репозиториев с интересными отчетами.

– Annual Security Reports. Ежегодные отчеты по кибербезопасности от крупнейших ИТ компаний.
– Phishing campaigns. Репозиторий, где собраны разборы о фишинговых кампаниях с примерами писем и описанием инструментов, с помощью которых осуществлялась рассылка.
– Hackerone Reports. Подборка отчетов от Hacker One, которые включают примеры найденных уязвимостей, их описание и влияние на систему

#devops #security #репозиторий

Хотим рассказать про митап для DevOps-инженеров в Новосибирске!

♾️ DevOps-митап 2ГИС ♾️

Три истории и афтепати.

Паша Гладких из 2ГИС расскажет, как собрать продакшен-кластер с GPU из обычных десктопов, когда бюджет диктует архитектуру.

Пётр Рукин из Nixys порассуждает, что там с KeyDB и стоит ли использовать DragonflyDB и Redis в современных реалиях.

Андрей Морозов из 2ГИС поделится опытом, где стоит применять Helmfile, а где — нет.

🟢24 сентября, Новосибирск, офис 2ГИС.

Бесплатно, регистрация обязательна.

🔵Пятничная подборка подкастов: Octopus Deploy, Wing Cloud и AI в командах

На этой неделе делимся записью выступления Team Lead-а Nixys Петра Рукина на DevOps-митапе в офисе 2ГИС— теперь её можно посмотреть на YouTube и RuTube, а пока ловите три истории о развитии инструментов, рождении стартапов и испытании идей об AI в командах.

Octopus Deploy и взгляд изнутри от Azure & DevOps Podcast
Джон Бристоу делится опытом более чем за два десятка лет. В его багаже Microsoft, Progress, роль в HashiCorp Ambassador и участие в сообществе Octopus Deploy. В выпуске подкаста он рассказывает о практиках управления, общении с сообществом и том, как сохранять интерес в индустрии без пафоса и лишних слов.
Уроки стартапа Wing Cloud от Packet Pushers
Элад Бен-Израэль вспоминает запуск Wing Cloud, разработку языка Winglang и выводы, которые он сделал о создании и закрытии стартапа. Разговор о рисках, смелости и технологиях, которые появляются, когда инженеры решают пойти своим путём.
AI: ожидания и реальность. Цифры от Лауры Тачо, CTO DX от Agentic DevOps
Лаура Тачо, CTO DX, рассказывает, как команды внедряют AI и агентов в повседневную разработку. В выпуске обсуждают цифры, как показатели успехов и неудач таких подходов, и представляют фреймворк для оценки влияния AI на жизненный цикл продукта. Лаура Тачо рассказывает, где автоматизация поддерживает процессы, а где превращается в лишний груз.

🙂Хороших выходных и спокойных дежурств тем, кто в смене!

#devops #подкаст #пятничный_devops

🌐Автоматизируем увеличение EBS-объёма без даунтайма

Всем DevOps! Сегодня разберём, как упростить жизнь, если диск внезапно “упирается” в предел.

Когда EBS-том на AWS почти заполняется, большинство команд обновляют размер вручную — через консоль или CLI. Это рутинно, медленно и иногда приводит к задержкам в проде. Автор одного из свежих гайдов показал, как полностью автоматизировать процесс расширения.

Вот ключевые шаги, которые он предлагает:

• Использовать CloudWatch для отслеживания порогового заполнения тома
• С помощью Lambda вызывать скрипт, который увеличивает EBS-объём
• Прописать событие в EventBridge для регулярной проверки
• После изменения размера инициировать расширение на уровне файловой системы
• Настроить уведомления (SNS), чтобы команда знала о срабатывании

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

🗄Если хотите внедрить у себя:
• Не полагайтесь на device names — используйте VolumeId. CloudWatch его не даёт, поэтому лучше резолвить через SSM.
• Выберите один интеграционный паттерн и настройте его корректно (например, Alarm → SNS → Lambda).
• Держите курс на безопасность: уберите “first volume” fallback, добавьте идемпотентность, чёткие алармы и логи.

Итог: автоматизация EBS через алармы работает стабильно. Если правильно продумать интеграцию и добавить защитные проверки, у решения нет минусов — только ускорение и предсказуемость.

#devops #aws #infrastructure

Legacy vs прогресс: как работать с системами прошлого

👤На Reddit обсудили боль DevOps-инженеров: как работать с системами, которые устарели пять лет назад и блокируют внедрение новых решений.
Каждое обновление с Legacy-системами превращается в квест: старые решения не интегрируются с современными процессами, руководство действует по правилу "не чини, если не сломано", инженеры тратят силы на сопровождение устаревшей инфраструктуры вместо развития.

Что предлагают коллеги?

jbandinixx:если не можешь уничтожить, заставь их работать на тебя. Оберни в API, автоматизируй рутину и устраняй проблемы по частям. Для повторяющихся задач (ввод данных, создание аккаунтов, планирование и т.д.) инструменты вроде Cyberdesk реально помогают снять часть нагрузки.

sysadmintemp: старое редко умирает, потому что всё ещё используется, а новое ПО не покрывает все сценарии. Автоматизируй процессы. У нас была C++ .exe программа, мы обернули её в Python API и загрузили рабочую версию в артефакт-репозиторий. Это позволило разворачивать ПО с актуальным Python-кодом и часто обновлять хост.

elucify: мне понадобилось 3 года, чтобы убедить руководство поменять систему. Менеджменту не нужны проблемы, им нужны решения с цифрами.

sschueller: по-нашему “модернизация” — это упаковать умирающий сервер в Docker и кинуть его в облако.

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

С какими сложностями вы сталкиваетесь при работе с legacy системами?

#devops #reddit #legacy

👩‍💻 Автоматическое восстановление служб в Kubernetes — контроль, прозрачность и спокойный сон

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

Что внедрить первым?
- Экспорт метрик и базовые алерты в тестовом namespace.
- Оператор расширения дискового пространства в dry-run с трассировкой действий.
- Сценарии отказов в staging: full-disk, failed-resize, node-failure.

🤝После базовой настройки включаем контроль.
Что проверить?
- Snapshots перед изменениями.
- Ограничение параллельных операций.
- Метрики эффективности: MTTR, число автопочиненных инцидентов, вмешательств оператора.

📎 Совет: встраивайте автоматизацию с runbooks и audit-логами рядом — так автоматические действия остаются прозрачными и воспроизводимыми. Читайте весь гайд по ссылке.

👩‍💻 Делимся репозиториями:
• Draino — оператор от Planet Labs, который автоматически изолирует и очищает (cordon/drain) узлы Kubernetes, когда они переходят в неработоспособное состояние.
• Volume Expander Operator — проект от Red Hat COP для автоматического расширения Persistent Volumes при достижении порога заполнения.

#devops #kubernetes #storage #autoremediation

Привет! Вы в DevOps FM 🚀
Канал про DevOps, администрирование и людей, которые это совершенствуют👍

Наши рубрики:
- Понедельник — Познавательные (#tools #opensource)
- Среда — Информационные дайджесты (#kubernetes #docker)
- Пятница — Развлекательное / пятничное чтиво (#debugging #podcasts)
- Каждые 2 недели — «Партнёр недели» (#партнёрский_пост)

💡 Совет: используйте хештеги для поиска по интересующим темам.
Например, #postgresql, #security, #architecture

Авто-ресурсы в Kubernetes, Pulumi NEO и Google MCP: инфраструктура на автопилоте

🔔Всем срединедельный DevOps! Обсудим свежие апдейты авто-выделения ресурсов в K8s и инструментов GitOps. Полезно тем, кто хочет меньше крутить кластеры вручную.

🟡 Kubernetes 1.34 и динамическое выделение ресурсов
В версии Kubernetes 1.34 кластер сам подбирает ресурсы GPU, CPU и I/O под конкретные задачи — без необходимости заранее прописывать лимиты в PodSpec. Теперь через API можно запрашивать устройства с нужными параметрами (тип GPU, версия CUDA, объём памяти) — и Kubernetes подберёт подходящее оборудование.
Это снижает долю простаивающих ресурсов, особенно при ML- и AI-нагрузках, где требования к железу меняются на лету.

⚫️ Pulumi NEO упрощает GitOps
Pulumi NEO читает IaC-код, сам формирует план изменений инфраструктуры, проверяет его через Policy as Code и применяет. Он понимает зависимости, окружения и может откатывать изменения без ручного kubectl apply. Полезен, когда GitOps-потоки разрастаются, а ручное управление окружениями тормозит релизы.

🟡 Google MCP для баз данных
Google представил MCP Toolbox — серверный набор инструментов, который реализует MCP для безопасной автоматизации доступа к базам данных. SQL-операции задаются декларативно в tools.yaml , а MCP управляет подключениями, пулами и правами доступа. Поддерживает Cloud SQL, AlloyDB, Spanner, PostgreSQL и MySQL. Система следит за нагрузкой, масштабирует кластеры и перестраивает схемы без ручного вмешательства DBA. Ещё один шаг к инфраструктуре, где всё крутится само.

#DevOps #Kubernetes #SRE

5 мифов о DevSecOps, из-за которых теряется скорость релизов и контроль над безопасностью

🤝Сегодня обсудим, почему DevSecOps — не про замедление, бюрократию и ещё один набор инструментов. Разберём 5 мифов, которые мешают это увидеть.

💬DevSecOps замедляет разработку
Миф: проверки безопасности добавляют фрикцию — значит, релизы будут идти медленнее.
Реальность: скорость падает не из-за DevSecOps, а из-за ручных и разрозненных проверок.
Когда безопасность встроена в CI/CD-поток (например, через автоматические SAST-, SCA- и DAST-сканеры), разработчики получают обратную связь в момент сборки или при коммите — ещё до ревью. Такая интеграция позволяет исправлять уязвимости до того, как они попадут в прод. Например, по данным Veracode, клиенты, использующие Veracode Fix, сокращают время устранения уязвимостей примерно на 92 % по сравнению с ручными подходами.

💬DevSecOps — это просто ещё один набор инструментов
Миф: купим несколько сканеров, включим проверки — и у нас DevSecOps.
Реальность: сами инструменты ничего не дают без культуры взаимодействия между разработчиками, DevOps и специалистами по безопасности. Если сканеры не интегрированы с CI/CD, issue-трекерами (например, Jira, GitLab Issues) или IDE, безопасность превращается в хаос уведомлений, которые никто не успевает обработать.

💬Разработчики должны быть экспертами по безопасности
Миф: разработчик должен стать специалистом по кибербезопасности для внедрения DevSecOps.
Реальность: грамотно выстроенный DevSecOps-процесс автоматизирует рутину и даёт понятные подсказки там, где работает разработчик — в IDE (VS Code, IntelliJ), в pull-requestах или пайплайне CI. Безопасность становится частью привычного цикла: написал код → прогнал тесты → получил подсказку по уязвимости → исправил.

💬DevSecOps не подходит малому бизнесу
Миф: DevSecOps — это история для корпораций с большими бюджетами.
Реальность: DevSecOps можно начать с малого и масштабировать по мере роста.
Даже небольшие команды могут настроить:
- SAST-проверку через бесплатные инструменты — Semgrep, SonarQube Community, Bandit;
- SCA-анализ с помощью OWASP Dependency-Check, Snyk Open Source или GitHub Dependabot.
Малый бизнес выигрывают за счёт гибкости процессов: меньше согласований, быстрее адаптация.

💬DevSecOps — это только защита от внешних атак
Миф: DevSecOps нужен только для защиты от хакеров и DDoS.
Реальность: DevSecOps охватывает всю цепочку безопасности — от конфигураций инфраструктуры до зависимостей и прав доступа.

#DevSecOps #Security #CICD #Automation

Kubernetes под микроскопом: как SPO видит действия пользователей

👩‍💻Всем DevOps! Сегодня поговорим о том, как отслеживать, что происходит внутри контейнеров в Kubernetes. В стандартной конфигурации Kubernetes аудит фиксирует только действия на уровне API: кто применил kubectl exec или kubectl debug. Что именно происходило внутри pod’а после входа в контейнер увидеть нельзя. Эту проблему решает Security Profiles Operator (SPO) — отслеживайте действия пользователей и процессов внутри pod’ов и на узлах.

🔄Принцип работы
SPO использует системные источники данных — например, /var/log/audit/audit.log и /proc/<pid>. Каждое событие записывается в JSON-формате, а JSON Enricher связывает его с соответствующим API-запросом через request UID. Это позволяет восстановить полную цепочку: API-запрос → контейнер → процесс → результат

🔓Как включить Security Profiles Operator?
- Установите cert-manager
Он нужен для автоматического управления сертификатами, используемыми SPO.
- Разверните Security Profiles Operator
Используйте официальный манифест из подборки репозиториев.
- Настройте хранение логов
SPO может сохранять логи: локально на узле (по умолчанию в /var/log/security-profiles-operator/ ), в общем томе (PVC), или выводить в stdout — удобно для интеграции с системами сбора логов вроде Loki или Elasticsearch;
- Включите JSON Enricher
Он обогащает события дополнительной информацией о процессе.
- Настройте seccomp-профиль для отслеживания системных вызовов
Он фиксирует вызовы вроде execve и clone, а объект ProfileBinding применяет профиль ко всем pod’ам в выбранном пространстве имён ( namespace ).

📎Репозитории с инструкциями по установке:
audit-logging-guide — описывает, как включить аудит действий внутри pod’ов и узлов через Security Profiles Operator.
installation-usage — показывает, как установить Security Profiles Operator и применить seccomp-профили к pod’ам.

С SPO вы поймете, что произошло, почему и кем было сделано — без лишней нагрузки и сложных интеграций.

#devops #kubernetes #spo

Инфраструктура на автопилоте: Java 2025 и новые инструменты

🔄В середине этой недели обсудим релизы в экосистеме Java — Jakarta Query стандартизирует работу с данными, Spring AI учится общаться через MCP, а Open Liberty получает автозависимости и патчи. Если в проектах не хватает автоматизации — самое время взглянуть на новые инструменты Java 2025.

🟡 Jakarta Query: единый язык запросов для Java-приложений
Jakarta EE готовится к включению нового Jakarta Query — стандартизированного языка запросов, который объединяет Jakarta Persistence Query Language (JPQL) и Jakarta Data Query Language (JDQL). Разработчик теперь может описывать запросы на уровне объектов, а платформа сама преобразует их в SQL или другой язык конкретного хранилища. Это делает код переносимым и позволяет писать запросы единообразно — независимо от используемой базы данных.

⚫️ Spring AI 1.1: протокол MCP и интеграция с облачными памятью и БД
Spring AI получил обновление с поддержкой Model Context Protocol (MCP) — теперь приложения могут безопасно делиться контекстом между AI-модулями, сервисами и хранилищами. Добавлены интеграции с Azure Cosmos DB и GemFire, улучшено управление метаданными и обработкой чатов.

🟡 Open Liberty 25.0.0.10: управление зависимостями и патчи безопасности
В новой версии Open Liberty появилась поддержка JDK 25 и настройка overrideLibraryRef, что позволяет библиотекам перекрывать классы приложения.
Это упрощает изоляцию и обновление зависимостей без перекомпиляции приложений — полезно при CI/CD-потоках с микросервисами. Исправлена уязвимость CVE-2020-36732 в библиотеке crypto-js, улучшена работа с Node-зависимостями и класс-лоадером.

🚀Java 2025 всё больше похожа на инфраструктуру, которая управляется через код:
запросы — декларативно, интеграции — модульно, обновления — без боли

Дайте знать, что думаете об инструментах Java в комментариях💬

#Java #SpringAI #JakartaEE #OpenLiberty

Пятничная подборка подкастов: от 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 #лидерство

Макросы в коде: что стоит учитывать при ревью и 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

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

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

От 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

Какие призраки прячутся в 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

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