❓ Что же мне выбрать?
✅ Terraform стоит выбрать, если:
✔ Вам нужна зрелая экосистема и стабильность.
✔ Вы не создаёте конкурента Terraform Cloud или другие продукты, которые могут нарушать BSL.
✔ Вам не критично, что код частично закрыт, и вы доверяете HashiCorp/IBM.
✅ OpenTofu подходит, если:
✔ Вам нужен полностью open-source инструмент без ограничений BSL.
✔ Вы видите риски в использовании Terraform и хотите обезопасить себя от частично закрытых лицензий.
✔ Вы не работаете с российскими облачными платформами.
✔ Вам не нужно поддерживать большое количество legacy кода на Terraform
🚀 А стоит ли обновляться с Terraform 1.5.7? Он же все еще работает, и он MPL-2.0
Да, однозначно! В обоих проектах появилось множество новых фич.
Следить за актуальностью возможностей можно здесь 👉 cani.tf
🔍 Вывод:
🔹 OpenTofu
✔ Отличный выбор для новых проектов, где не используются российские облака.
✔ Подходит для тех, кто хочет участвовать в развитии сообщества и продвигать новые фичи.
✔ Рекомендуется, если ваш продукт потенциально конфликтует с лицензией BSL и Terraform Cloud.
🔹 Terraform
✔ Оптимален для типичных DevOps-проектов и CI/CD-инфраструктуры под AWS, GCP, Azure.
✔ Выбор для тех, кому важны стабильность, зрелая экосистема и поддержка HashiCorp.
✔ Подходит, если BSL-лицензия не критична, а доверие к HashiCorp выше благодаря опыту и корпоративному уровню решений.
🚀 Ну а если вам нужно быстро переключаться между версиями Terraform и OpenTofu, попробуйте 👉 tofuutils/tenv
🤔 А что используете вы? Terraform или OpenTofu? Делитесь мнением в комментариях!
✅ Terraform стоит выбрать, если:
✔ Вам нужна зрелая экосистема и стабильность.
✔ Вы не создаёте конкурента Terraform Cloud или другие продукты, которые могут нарушать BSL.
✔ Вам не критично, что код частично закрыт, и вы доверяете HashiCorp/IBM.
✅ OpenTofu подходит, если:
✔ Вам нужен полностью open-source инструмент без ограничений BSL.
✔ Вы видите риски в использовании Terraform и хотите обезопасить себя от частично закрытых лицензий.
✔ Вы не работаете с российскими облачными платформами.
✔ Вам не нужно поддерживать большое количество legacy кода на Terraform
🚀 А стоит ли обновляться с Terraform 1.5.7? Он же все еще работает, и он MPL-2.0
Да, однозначно! В обоих проектах появилось множество новых фич.
Следить за актуальностью возможностей можно здесь 👉 cani.tf
🔍 Вывод:
🔹 OpenTofu
✔ Отличный выбор для новых проектов, где не используются российские облака.
✔ Подходит для тех, кто хочет участвовать в развитии сообщества и продвигать новые фичи.
✔ Рекомендуется, если ваш продукт потенциально конфликтует с лицензией BSL и Terraform Cloud.
🔹 Terraform
✔ Оптимален для типичных DevOps-проектов и CI/CD-инфраструктуры под AWS, GCP, Azure.
✔ Выбор для тех, кому важны стабильность, зрелая экосистема и поддержка HashiCorp.
✔ Подходит, если BSL-лицензия не критична, а доверие к HashiCorp выше благодаря опыту и корпоративному уровню решений.
🚀 Ну а если вам нужно быстро переключаться между версиями Terraform и OpenTofu, попробуйте 👉 tofuutils/tenv
🤔 А что используете вы? Terraform или OpenTofu? Делитесь мнением в комментариях!
Лучшие инструменты для Terraform и OpenTofu в 2025 году 🚀
Infrastructure-as-Code (IaC) продолжает активно развиваться, а вместе с ним растёт и экосистема инструментов, облегчающих управление инфраструктурой. Многие из них изначально создавались для Terraform, но теперь полностью поддерживают и OpenTofu, что делает их универсальными помощниками для DevOps-инженеров и облачных архитекторов.
Этот пост - подборка самых полезных инструментов, которые сделают вашу работу с IaC быстрее, удобнее и безопаснее.
🛠 Управление версиями
🔹 tenv – лёгкий и быстрый менеджер версий для Terraform, OpenTofu, Terragrunt и Atmos. Поддерживает автоматический парсинг версий из конфигурационных файлов, проверку подписей (cosign, PGP), доступен как Go-пакет, а еще во всех популярных пакетных менеджерах и ОС (включая Windows). В отличие от asdf, не требует зависимостей, работает быстрее и оптимизирован для Terraform/OpenTofu-экосистемы. (🔗 GitHub)
🤖 Автоматизация и генерация IaC
🔹 Aiac – AI-инструмент для генерации Terraform-кода, CI/CD пайплайнов, OPA-политик и других IaC-конфигураций. Поддерживает OpenAI, Amazon Bedrock и Ollama. (🔗 aiac.dev)
🔹 Atmos – мощный фреймворк для структурирования инфраструктуры в Terraform/OpenTofu с YAML-конфигурациями. Упрощает управление модулями и окружениями. (🔗 GitHub)
🔹 Terramate – инструмент для автоматизации IaC-оркестрации, code generation и работы со стэками. (🔗 GitHub)
🏗 Улучшение работы с Terraform/OpenTofu
🔹 Terragrunt – обёртка над Terraform, сокращающая дублирование кода и упрощающая управление состоянием, зависимостями и окружениями. (🔗 terragrunt.io)
🔹 Atlantis – автоматизация Terraform в pull request'ах. Идеален для командной работы и интеграции с CI/CD. (🔗 runatlantis.io)
🔹 Burrito – Kubernetes-оператор для автоматизации Terraform, аналог ArgoCD для IaC. (🔗 GitHub)
🔍 Безопасность и анализ кода
🔹 Checkov – мощный инструмент статического анализа IaC, выявляющий уязвимости и ошибки конфигурации в Terraform/OpenTofu, Kubernetes, Docker и других платформах. (🔗 GitHub)
🔹 Trivy – универсальный сканер, находящий уязвимости в контейнерах, IaC, артефактах и облачных сервисах. (🔗 trivy.dev)
🔹 TFLint – продвинутый линтер для Terraform, предотвращающий ошибки в коде и проверяющий соответствие best practices. (🔗 GitHub)
💰 Контроль затрат и управление ресурсами
🔹 Infracost – оценка стоимости облачных ресурсов в Terraform/OpenTofu до их развертывания. Интеграция с CI/CD и GitHub PR. (🔗 GitHub)
🔹 Terratag – автоматическое добавление тегов в Terraform/OpenTofu-код, обеспечивающее лучшее управление ресурсами в AWS, GCP и Azure. (🔗 GitHub)
⚙️ Управление состоянием и миграции
🔹 Tfmigrate – инструмент для безопасных миграций Terraform/OpenTofu state с возможностью dry-run. (🔗 GitHub)
🔹 Tfmv – CLI-инструмент для автоматического переименования ресурсов Terraform/OpenTofu без потери состояния. (🔗 GitHub)
А какие инструменты используете вы? Делитесь опытом в комментариях! 🚀
Infrastructure-as-Code (IaC) продолжает активно развиваться, а вместе с ним растёт и экосистема инструментов, облегчающих управление инфраструктурой. Многие из них изначально создавались для Terraform, но теперь полностью поддерживают и OpenTofu, что делает их универсальными помощниками для DevOps-инженеров и облачных архитекторов.
Этот пост - подборка самых полезных инструментов, которые сделают вашу работу с IaC быстрее, удобнее и безопаснее.
🛠 Управление версиями
🔹 tenv – лёгкий и быстрый менеджер версий для Terraform, OpenTofu, Terragrunt и Atmos. Поддерживает автоматический парсинг версий из конфигурационных файлов, проверку подписей (cosign, PGP), доступен как Go-пакет, а еще во всех популярных пакетных менеджерах и ОС (включая Windows). В отличие от asdf, не требует зависимостей, работает быстрее и оптимизирован для Terraform/OpenTofu-экосистемы. (🔗 GitHub)
🤖 Автоматизация и генерация IaC
🔹 Aiac – AI-инструмент для генерации Terraform-кода, CI/CD пайплайнов, OPA-политик и других IaC-конфигураций. Поддерживает OpenAI, Amazon Bedrock и Ollama. (🔗 aiac.dev)
🔹 Atmos – мощный фреймворк для структурирования инфраструктуры в Terraform/OpenTofu с YAML-конфигурациями. Упрощает управление модулями и окружениями. (🔗 GitHub)
🔹 Terramate – инструмент для автоматизации IaC-оркестрации, code generation и работы со стэками. (🔗 GitHub)
🏗 Улучшение работы с Terraform/OpenTofu
🔹 Terragrunt – обёртка над Terraform, сокращающая дублирование кода и упрощающая управление состоянием, зависимостями и окружениями. (🔗 terragrunt.io)
🔹 Atlantis – автоматизация Terraform в pull request'ах. Идеален для командной работы и интеграции с CI/CD. (🔗 runatlantis.io)
🔹 Burrito – Kubernetes-оператор для автоматизации Terraform, аналог ArgoCD для IaC. (🔗 GitHub)
🔍 Безопасность и анализ кода
🔹 Checkov – мощный инструмент статического анализа IaC, выявляющий уязвимости и ошибки конфигурации в Terraform/OpenTofu, Kubernetes, Docker и других платформах. (🔗 GitHub)
🔹 Trivy – универсальный сканер, находящий уязвимости в контейнерах, IaC, артефактах и облачных сервисах. (🔗 trivy.dev)
🔹 TFLint – продвинутый линтер для Terraform, предотвращающий ошибки в коде и проверяющий соответствие best practices. (🔗 GitHub)
💰 Контроль затрат и управление ресурсами
🔹 Infracost – оценка стоимости облачных ресурсов в Terraform/OpenTofu до их развертывания. Интеграция с CI/CD и GitHub PR. (🔗 GitHub)
🔹 Terratag – автоматическое добавление тегов в Terraform/OpenTofu-код, обеспечивающее лучшее управление ресурсами в AWS, GCP и Azure. (🔗 GitHub)
⚙️ Управление состоянием и миграции
🔹 Tfmigrate – инструмент для безопасных миграций Terraform/OpenTofu state с возможностью dry-run. (🔗 GitHub)
🔹 Tfmv – CLI-инструмент для автоматического переименования ресурсов Terraform/OpenTofu без потери состояния. (🔗 GitHub)
А какие инструменты используете вы? Делитесь опытом в комментариях! 🚀
🚀 *Ops — в чём разница?
Современный IT-мир давно вышел за рамки простой разработки. Сегодня инженеры отвечают не только за код, но и за его тестирование, развертывание, безопасность, мониторинг и оптимизацию затрат. Пока все привыкали к DevOps, новые «ops» начали появляться повсюду, словно грибы после дождя. Давайте разберёмся, какие бывают «ops»-методологии и чем они отличаются между собой.
DevOps (Development + Operations)
Что это?
DevOps объединяет процессы непрерывной разработки, интеграции, тестирования, развертывания и мониторинга, способствуя инновациям, гибкости и масштабируемости.
Ключевые моменты:
🎯 Цель: ускорение релизов через тесное взаимодействие разработчиков и администраторов.
🛠 Инструменты: CI/CD (GitHub Actions, GitLab CI, Jenkins), Kubernetes, Terraform, Ansible, Go.
💡 Идея: Автоматизация и инфраструктура как код (IaC) позволяют обеспечивать быстрые и надёжные обновления без даунтайма.
DevSecOps (Development + Security + Operations)
Что это?
DevSecOps — это DevOps с интегрированной безопасностью. В отличие от традиционного подхода, где безопасность добавляется в конце разработки, здесь она встроена в каждый этап разработки, превращая её в общую ответственность команды.
Ключевые моменты:
🎯 Цель: встроить безопасность на всех этапах CI/CD процесса.
🛠 Инструменты: SAST/DAST (SonarQube, Snyk, OWASP ZAP), системы управления секретами (Vault, Sealed Secrets).
💡 Идея: Безопасность — это не отдельная проверка перед релизом, а часть всего процесса разработки.
MLOps (Machine Learning + Operations)
Что это?
MLOps — это DevOps для машинного обучения, обеспечивающий автоматизированное развертывание и управление ML-моделями в продакшене.
Ключевые моменты:
🎯 Цель: обеспечить непрерывную интеграцию, тестирование, развертывание и мониторинг ML-моделей.
🛠 Инструменты: MLflow, Kubeflow, TensorFlow Extended (TFX), Apache Airflow.
💡 Идея: Автоматизация и контроль качества жизненного цикла моделей критичны для успешного внедрения. ML — это не только тренировка модели, но и её продакшен.
Современный IT-мир давно вышел за рамки простой разработки. Сегодня инженеры отвечают не только за код, но и за его тестирование, развертывание, безопасность, мониторинг и оптимизацию затрат. Пока все привыкали к DevOps, новые «ops» начали появляться повсюду, словно грибы после дождя. Давайте разберёмся, какие бывают «ops»-методологии и чем они отличаются между собой.
DevOps (Development + Operations)
Что это?
DevOps объединяет процессы непрерывной разработки, интеграции, тестирования, развертывания и мониторинга, способствуя инновациям, гибкости и масштабируемости.
Ключевые моменты:
🎯 Цель: ускорение релизов через тесное взаимодействие разработчиков и администраторов.
🛠 Инструменты: CI/CD (GitHub Actions, GitLab CI, Jenkins), Kubernetes, Terraform, Ansible, Go.
💡 Идея: Автоматизация и инфраструктура как код (IaC) позволяют обеспечивать быстрые и надёжные обновления без даунтайма.
DevSecOps (Development + Security + Operations)
Что это?
DevSecOps — это DevOps с интегрированной безопасностью. В отличие от традиционного подхода, где безопасность добавляется в конце разработки, здесь она встроена в каждый этап разработки, превращая её в общую ответственность команды.
Ключевые моменты:
🎯 Цель: встроить безопасность на всех этапах CI/CD процесса.
🛠 Инструменты: SAST/DAST (SonarQube, Snyk, OWASP ZAP), системы управления секретами (Vault, Sealed Secrets).
💡 Идея: Безопасность — это не отдельная проверка перед релизом, а часть всего процесса разработки.
MLOps (Machine Learning + Operations)
Что это?
MLOps — это DevOps для машинного обучения, обеспечивающий автоматизированное развертывание и управление ML-моделями в продакшене.
Ключевые моменты:
🎯 Цель: обеспечить непрерывную интеграцию, тестирование, развертывание и мониторинг ML-моделей.
🛠 Инструменты: MLflow, Kubeflow, TensorFlow Extended (TFX), Apache Airflow.
💡 Идея: Автоматизация и контроль качества жизненного цикла моделей критичны для успешного внедрения. ML — это не только тренировка модели, но и её продакшен.
SecOps (Security Operations)
Что это?
SecOps интегрирует безопасность в повседневные IT-операции, снижая риски кибератак.
Ключевые моменты:
🎯 Цель: автоматизировать критически важные задачи по безопасности и быстро реагировать на угрозы.
💡 Идея: Безопасность должна быть встроенной в процессы
SaaSOps (SaaS Operations)
Что это?
SaaSOps занимается управлением и оптимизацией облачных приложений, предоставляемых по модели Software-as-a-Service.
Ключевые моменты:
🎯 Цель: улучшить управление доступом, обеспечить безопасность и повысить эффективность поддержки SaaS-приложений.
💡 Идея: Автоматизация процессов управления SaaS помогает повысить удовлетворённость пользователей и эффективность команд.
Что это?
SecOps интегрирует безопасность в повседневные IT-операции, снижая риски кибератак.
Ключевые моменты:
🎯 Цель: автоматизировать критически важные задачи по безопасности и быстро реагировать на угрозы.
💡 Идея: Безопасность должна быть встроенной в процессы
SaaSOps (SaaS Operations)
Что это?
SaaSOps занимается управлением и оптимизацией облачных приложений, предоставляемых по модели Software-as-a-Service.
Ключевые моменты:
🎯 Цель: улучшить управление доступом, обеспечить безопасность и повысить эффективность поддержки SaaS-приложений.
💡 Идея: Автоматизация процессов управления SaaS помогает повысить удовлетворённость пользователей и эффективность команд.
SRE (Site Reliability Engineering)
Что это?
SRE фокусируется на обеспечении стабильности и отказоустойчивости сервисов, объединяя инженерные подходы разработки и эксплуатации. SRE это в первую очередь про продакшен и мониторинг.
Ключевые моменты:
🎯 Цель: минимизация сбоев, повышение доступности и эффективное управление инцидентами.
🛠 Инструменты: Мониторинг (Prometheus, Grafana), хаос-тестирование (Chaos Monkey), метрики SLA/SLO/SLI.
💡 Идея: SRE — это DevOps с акцентом на надежность и управляемость продакшен систем.
GitOps
Что это?
GitOps - методология, котоаря использует Git как единственный источник правды для управления инфраструктурой.
Ключевые моменты:
🎯 Цель: стандартизировать процессы развертывания и обеспечить прозрачность изменений.
🛠 Инструменты: ArgoCD, Flux, Jenkins X
💡 Идея: Версионный контроль помогает быстро откатывать изменения и повышает безопасность обновлений.
AIOps (Artificial Intelligence for IT Operations)
Что это?
AIOps применяет машинное обучение и аналитику больших данных для автоматизации мониторинга и управления инцидентами.
Ключевые моменты:
🎯 Цель: автоматическое обнаружение и устранение проблем в реальном времени. Поиск аномалий.
💡Идея: AI помогает командам быстрее реагировать на сбои и снижать нагрузку на инженеров.
NoOps (No Operations)
Что это?
NoOps — концепция, при которой традиционные операционные команды становятся ненужными благодаря полной автоматизации в облаке.
Ключевые моменты:
🎯 Цель: максимальная автоматизация инфраструктуры. Минимизация операционных затрат.
🕒 Когда используется: в облачных средах (AWS Lambda, Google Cloud Run, FaaS)
💡Идея: Если всё управляется облаком, зачем нужны Ops-инженеры?
ChatOps
Что это?
ChatOps позволяет управлять процессами через чат-платформы, интегрируя DevOps-инструменты в мессенджеры.
Ключевые моменты:
🎯 Цель: автоматизация команд и управление через Slack, Microsoft Teams, Discord.
💡Идея: Рабочие процессы и мониторинг в одном месте делают командную работу эффективнее.
FinOps (Finance + Operations)
Что это?
FinOps помогает компаниям управлять облачными расходами, объединяя финансовые и инженерные команды.
Ключевые моменты:
🏗Фазы: Inform (осведомлённость и распределение затрат), Optimize (оптимизация расходов) и Operate (управление ROI).
💡 Идея: Совместное управление бюджетом и ресурсами повышает экономическую эффективность и прозрачность расходов.
DataOps (Data Operations)
Что это?
DataOps автоматизирует обработку данных, улучшая их качество и ускоряя аналитические процессы.
Ключевые моменты:
🎯 Цель: наладить работу между дата-инженерами и командами разработки.
💡 Идея: Автоматизация процессов обработки данных позволяет устранить повторяющиеся задачи и повысить точность результатов.
ContentOps (Content Operations)
Что это?
ContentOps отвечает за весь жизненный цикл цифрового контента: от создания и редактирования до публикации и архивирования.
Ключевые моменты:
🎯 Цель: обеспечить координацию между отделами и своевременность публикаций
💡 Идея: Автоматизация контент-процессов помогает быстрее создавать и публиковать материалы без дублирования и ошибок
ITOps (IT Operations)
Что это?
ITOps охватывает классические IT-операции, включая поддержку пользователей и администрирование инфраструктуры.
Ключевые моменты:
🎯 Цель: бесперебойная работа IT-сервисов.
💡 Идея: Классическое администрирование IT-инфраструктуры.
Что это?
SRE фокусируется на обеспечении стабильности и отказоустойчивости сервисов, объединяя инженерные подходы разработки и эксплуатации. SRE это в первую очередь про продакшен и мониторинг.
Ключевые моменты:
🎯 Цель: минимизация сбоев, повышение доступности и эффективное управление инцидентами.
🛠 Инструменты: Мониторинг (Prometheus, Grafana), хаос-тестирование (Chaos Monkey), метрики SLA/SLO/SLI.
💡 Идея: SRE — это DevOps с акцентом на надежность и управляемость продакшен систем.
GitOps
Что это?
GitOps - методология, котоаря использует Git как единственный источник правды для управления инфраструктурой.
Ключевые моменты:
🎯 Цель: стандартизировать процессы развертывания и обеспечить прозрачность изменений.
🛠 Инструменты: ArgoCD, Flux, Jenkins X
💡 Идея: Версионный контроль помогает быстро откатывать изменения и повышает безопасность обновлений.
AIOps (Artificial Intelligence for IT Operations)
Что это?
AIOps применяет машинное обучение и аналитику больших данных для автоматизации мониторинга и управления инцидентами.
Ключевые моменты:
🎯 Цель: автоматическое обнаружение и устранение проблем в реальном времени. Поиск аномалий.
💡Идея: AI помогает командам быстрее реагировать на сбои и снижать нагрузку на инженеров.
NoOps (No Operations)
Что это?
NoOps — концепция, при которой традиционные операционные команды становятся ненужными благодаря полной автоматизации в облаке.
Ключевые моменты:
🎯 Цель: максимальная автоматизация инфраструктуры. Минимизация операционных затрат.
🕒 Когда используется: в облачных средах (AWS Lambda, Google Cloud Run, FaaS)
💡Идея: Если всё управляется облаком, зачем нужны Ops-инженеры?
ChatOps
Что это?
ChatOps позволяет управлять процессами через чат-платформы, интегрируя DevOps-инструменты в мессенджеры.
Ключевые моменты:
🎯 Цель: автоматизация команд и управление через Slack, Microsoft Teams, Discord.
💡Идея: Рабочие процессы и мониторинг в одном месте делают командную работу эффективнее.
FinOps (Finance + Operations)
Что это?
FinOps помогает компаниям управлять облачными расходами, объединяя финансовые и инженерные команды.
Ключевые моменты:
🏗Фазы: Inform (осведомлённость и распределение затрат), Optimize (оптимизация расходов) и Operate (управление ROI).
💡 Идея: Совместное управление бюджетом и ресурсами повышает экономическую эффективность и прозрачность расходов.
DataOps (Data Operations)
Что это?
DataOps автоматизирует обработку данных, улучшая их качество и ускоряя аналитические процессы.
Ключевые моменты:
🎯 Цель: наладить работу между дата-инженерами и командами разработки.
💡 Идея: Автоматизация процессов обработки данных позволяет устранить повторяющиеся задачи и повысить точность результатов.
ContentOps (Content Operations)
Что это?
ContentOps отвечает за весь жизненный цикл цифрового контента: от создания и редактирования до публикации и архивирования.
Ключевые моменты:
🎯 Цель: обеспечить координацию между отделами и своевременность публикаций
💡 Идея: Автоматизация контент-процессов помогает быстрее создавать и публиковать материалы без дублирования и ошибок
ITOps (IT Operations)
Что это?
ITOps охватывает классические IT-операции, включая поддержку пользователей и администрирование инфраструктуры.
Ключевые моменты:
🎯 Цель: бесперебойная работа IT-сервисов.
💡 Идея: Классическое администрирование IT-инфраструктуры.
Вывод
IT-мир развивается, и «ops»-методологии адаптируются к новым вызовам:
✅ DevOps, NoOps, MLOps, DevSecOps, SRE ускоряют разработку и обеспечивают стабильность.
✅ FinOps, DataOps, GitOps, AIOps, ContentOps, ChatOps, ITOps, SecOps, SaaSOps помогают оптимизировать процессы, затраты и безопасность.
Вопрос не в том, какой подход выбрать, а как их комбинировать для максимальной эффективности. А какие «ops» знаете вы? 🤔👇
PS: Отличный доклад про это с DevOpsConf 2021: https://www.youtube.com/watch?v=Am84iPcVZlc
IT-мир развивается, и «ops»-методологии адаптируются к новым вызовам:
✅ DevOps, NoOps, MLOps, DevSecOps, SRE ускоряют разработку и обеспечивают стабильность.
✅ FinOps, DataOps, GitOps, AIOps, ContentOps, ChatOps, ITOps, SecOps, SaaSOps помогают оптимизировать процессы, затраты и безопасность.
Вопрос не в том, какой подход выбрать, а как их комбинировать для максимальной эффективности. А какие «ops» знаете вы? 🤔👇
PS: Отличный доклад про это с DevOpsConf 2021: https://www.youtube.com/watch?v=Am84iPcVZlc
YouTube
Несуществующие твари и где они обитают. Виды DevOps-инженеров / Кирилл Демченко, Владимир Утратенко
Приглашаем на DevOpsConf 2025, которая пройдет 7 и 8 апреля 2025 в Сколково в Москве.
Программа, подробности и билеты по ссылке: https://devopsconf.io/moscow/2025
---------
DevOpsConf 2021
Профессиональная конференция по интеграции процессов разработки…
Программа, подробности и билеты по ссылке: https://devopsconf.io/moscow/2025
---------
DevOpsConf 2021
Профессиональная конференция по интеграции процессов разработки…
2️⃣ Навигация по второму дню андерхуда
— Kubernetes — новый язык для разработки инфраструктуры?
— OpenTofu vs Terraform. Что использовать в 2025
— Лучшие инструменты для Terraform и OpenTofu в 2025 году
— *Ops — в чём разница?
— Kubernetes — новый язык для разработки инфраструктуры?
— OpenTofu vs Terraform. Что использовать в 2025
— Лучшие инструменты для Terraform и OpenTofu в 2025 году
— *Ops — в чём разница?
📜 Software Architecture Document: Что это такое и почему это необходимость для энтерпрайза и зло для стартапа
В IT архитектурная документация (Software Architecture Document, SAD) играет важную роль. Но в зависимости от контекста она может как помогать, так и тормозить процесс.
🔹 Что такое SAD?
SAD (грустная дока — это не только шутка, но и правда жизни) — это Software Architecture Document, документ, в котором описывается high-level архитектура системы. Обычно он разбит на разделы, каждый из которых охватывает одно ключевое архитектурное решение, связывающее бизнес-требования и техническую реализацию.
Альтернативные подходы к этим решениям часто выносятся в отдельный документ. В итоге SAD становится своего рода blueprint’ом проекта, с которого начинается имплементация.
Но всё не так радужно. Иногда такие документы раздуваются до 200–300 страниц, особенно если включают в себя C4-диаграммы, data flow, и прочие артефакты. Тут я могу только посоветовать учиться читать такие документы, а если на вашем проекте их нет — предложить архитектору или лиду заняться их написанием.
В IT архитектурная документация (Software Architecture Document, SAD) играет важную роль. Но в зависимости от контекста она может как помогать, так и тормозить процесс.
🔹 Что такое SAD?
SAD (грустная дока — это не только шутка, но и правда жизни) — это Software Architecture Document, документ, в котором описывается high-level архитектура системы. Обычно он разбит на разделы, каждый из которых охватывает одно ключевое архитектурное решение, связывающее бизнес-требования и техническую реализацию.
Альтернативные подходы к этим решениям часто выносятся в отдельный документ. В итоге SAD становится своего рода blueprint’ом проекта, с которого начинается имплементация.
Но всё не так радужно. Иногда такие документы раздуваются до 200–300 страниц, особенно если включают в себя C4-диаграммы, data flow, и прочие артефакты. Тут я могу только посоветовать учиться читать такие документы, а если на вашем проекте их нет — предложить архитектору или лиду заняться их написанием.
🔹 Почему энтерпрайзу нужен SAD?
✅ Сложные системы — нужна прозрачность
В корпоративных (enterprise) системах много команд, легаси-код, сложные интеграции. Без архитектурной документации разработчики просто не поймут, как всё работает.
✅ Безопасность и соответствие требованиям
Для банков, финтеха и госкомпаний документирование архитектуры необходимо для аудитов и сертификаций (SOC2, ISO 27001, PCI DSS, ГОСТ).
✅ Контроль и масштабируемость
В больших компаниях архитектурные решения принимаются годами. Документация фиксирует прошлые решения, чтобы не наступать на те же грабли.
🔹 Почему стартапам SAD вреден?
❌ Медленный процесс
На стартапах нельзя тратить время на бумажную работу. На этапе разработки MVP важнее быстро проверять гипотезы и выпускать продукт. Пока стартап пишет архитектуру, конкуренты уже пивотят свой продукт.
❌ Архитектура меняется слишком быстро
В стартапах архитектура и код переписываются каждые несколько месяцев. Писать документацию в таких условиях — значит тратить время на создание заранее устаревающего артефакта.
❌ Фокус должен быть на продукте
Вместо того чтобы писать длинные SAD, стартапу лучше фиксировать архитектурные решения в коротких ADR (Architecture Decision Records). Это более гибкий и быстрый формат. Многие ребята это делают прямо в Notion без особого формализма.
🔹 А что насчёт Open Source проектов?
Для Open Source проектов нет строгих стандартов, аналогичных SAD. Конечно, в больших проектах есть roadmap и подробное обсуждения фич, но общего документа, как правило, нет. Однако есть похожий формат — EP (Enhancement Proposal). EP - подробное описание одной фичи, часто схожее с SAD по духу. Хорошим примером являются KEP (Kubernetes Enhancement Proposals), которые могут быть полезными для изучения.
🔹 Что использую я?
Когда стартует новый проект или появляется большая фича, я предпочитаю писать документы в духе SAD — пусть и без фанатизма, но с описанием ключевых решений и архитектурных идей.
А вот для небольших проектов или на этапе раннего старта мне вполне хватает ADR-ов, зафиксированных в вики. Главное — чтобы команда всё это обсудила и была на одной волне.
А у вас на проекте есть SAD, или хватает быстрых записей и ADR? 🤔👇
✅ Сложные системы — нужна прозрачность
В корпоративных (enterprise) системах много команд, легаси-код, сложные интеграции. Без архитектурной документации разработчики просто не поймут, как всё работает.
✅ Безопасность и соответствие требованиям
Для банков, финтеха и госкомпаний документирование архитектуры необходимо для аудитов и сертификаций (SOC2, ISO 27001, PCI DSS, ГОСТ).
✅ Контроль и масштабируемость
В больших компаниях архитектурные решения принимаются годами. Документация фиксирует прошлые решения, чтобы не наступать на те же грабли.
🔹 Почему стартапам SAD вреден?
❌ Медленный процесс
На стартапах нельзя тратить время на бумажную работу. На этапе разработки MVP важнее быстро проверять гипотезы и выпускать продукт. Пока стартап пишет архитектуру, конкуренты уже пивотят свой продукт.
❌ Архитектура меняется слишком быстро
В стартапах архитектура и код переписываются каждые несколько месяцев. Писать документацию в таких условиях — значит тратить время на создание заранее устаревающего артефакта.
❌ Фокус должен быть на продукте
Вместо того чтобы писать длинные SAD, стартапу лучше фиксировать архитектурные решения в коротких ADR (Architecture Decision Records). Это более гибкий и быстрый формат. Многие ребята это делают прямо в Notion без особого формализма.
🔹 А что насчёт Open Source проектов?
Для Open Source проектов нет строгих стандартов, аналогичных SAD. Конечно, в больших проектах есть roadmap и подробное обсуждения фич, но общего документа, как правило, нет. Однако есть похожий формат — EP (Enhancement Proposal). EP - подробное описание одной фичи, часто схожее с SAD по духу. Хорошим примером являются KEP (Kubernetes Enhancement Proposals), которые могут быть полезными для изучения.
🔹 Что использую я?
Когда стартует новый проект или появляется большая фича, я предпочитаю писать документы в духе SAD — пусть и без фанатизма, но с описанием ключевых решений и архитектурных идей.
А вот для небольших проектов или на этапе раннего старта мне вполне хватает ADR-ов, зафиксированных в вики. Главное — чтобы команда всё это обсудила и была на одной волне.
А у вас на проекте есть SAD, или хватает быстрых записей и ADR? 🤔👇
Расскажу, как я настраиваю свой ноутбук
В течение последних 6-7 лет я использую только макбуки в качестве личного девайса, но этот подход, на мой взгляд, вполне работает и на Linux/Windows.
Так как же выглядит настройка моего компьютера?
У меня есть приватный репозиторий на GitHub для бустрапа окружения. Я просто закидываю его на новый ноутбук в виде Zip-архива, а затем запускаю скрипт
1️⃣Установка и настройка brew / nix
2️⃣Установка тяжеловесного софта — Java, Docker, Xcode и т.д.
3️⃣Установка и конфигурация zsh / oh-my-zsh
4️⃣Настройка терминала — tmux, alacritty, мои персональные алиасы
5️⃣Установка и настройка рядового софта — от Terraform до Chrome
6️⃣Настройка Git / VSCode / IntelliJ / SSH / Maven и создание привычных папок на компьютере
7️⃣ Настройка внешнего вида macOS через defaults
// На скриншоте - layout моего репозитория
В течение последних 6-7 лет я использую только макбуки в качестве личного девайса, но этот подход, на мой взгляд, вполне работает и на Linux/Windows.
Так как же выглядит настройка моего компьютера?
У меня есть приватный репозиторий на GitHub для бустрапа окружения. Я просто закидываю его на новый ноутбук в виде Zip-архива, а затем запускаю скрипт
init.sh. Этот скрипт делится на несколько частей:1️⃣Установка и настройка brew / nix
2️⃣Установка тяжеловесного софта — Java, Docker, Xcode и т.д.
3️⃣Установка и конфигурация zsh / oh-my-zsh
4️⃣Настройка терминала — tmux, alacritty, мои персональные алиасы
5️⃣Установка и настройка рядового софта — от Terraform до Chrome
6️⃣Настройка Git / VSCode / IntelliJ / SSH / Maven и создание привычных папок на компьютере
7️⃣ Настройка внешнего вида macOS через defaults
// На скриншоте - layout моего репозитория
Какие ещё “tips & tricks” я использую в своём сетапе?
- Храню все конфигурации в репозитории и линкую файлы на файловую систему. Так я не забываю обновлять репозиторий и не теряю новые конфигурации.
- Стараюсь гибко настраивать консольные тулы, такие как Git, AWS, Kubernetes и тд. Если вам интересно, могу поделиться классными алиасами или настройками в комментариях.
- Каждый раз, когда я запускаю свои скрипты, я замеряю, сколько мануальных действий мне нужно выполнить, и стараюсь сократить их количество. Сейчас это примерно три действия на весь сетап ноутбука. Естественно, это количество действий я пытаюсь сокращать.
- Периодически читаю чужие репозитории с "dotfiles" на GitHub, чтобы подрезать что-то полезное.
🔹 Вывод:
Автоматизировать настройку ноутбука — очень полезно. Вместо 5–6 часов ручной рутины вы переносите все привычные конфиги, алиасы и настройки буквально за пару минут (и один кофе-брейк).
📌А как вы подходите к автоматизации? Делитесь в комментариях своими скриптами, настройками и лайфхаками — будет интересно сравнить подходы.
- Храню все конфигурации в репозитории и линкую файлы на файловую систему. Так я не забываю обновлять репозиторий и не теряю новые конфигурации.
- Стараюсь гибко настраивать консольные тулы, такие как Git, AWS, Kubernetes и тд. Если вам интересно, могу поделиться классными алиасами или настройками в комментариях.
- Каждый раз, когда я запускаю свои скрипты, я замеряю, сколько мануальных действий мне нужно выполнить, и стараюсь сократить их количество. Сейчас это примерно три действия на весь сетап ноутбука. Естественно, это количество действий я пытаюсь сокращать.
- Периодически читаю чужие репозитории с "dotfiles" на GitHub, чтобы подрезать что-то полезное.
🔹 Вывод:
Автоматизировать настройку ноутбука — очень полезно. Вместо 5–6 часов ручной рутины вы переносите все привычные конфиги, алиасы и настройки буквально за пару минут (и один кофе-брейк).
📌А как вы подходите к автоматизации? Делитесь в комментариях своими скриптами, настройками и лайфхаками — будет интересно сравнить подходы.
💻 Почему стоит разделять работу и личную жизнь на два ноутбука?
Совмещать работу и личные дела на одном устройстве кажется удобным. Но на практике это создаёт массу проблем — частенько даже там, где вы их не видите.
1️⃣Безопасность данных
Рабочий ноутбук под корпоративными политиками: VPN, шифрование, мониторинг, ограниченный доступ к файлам. Загружая туда личные данные, вы рискуете их случайно потерять, нарушить корпоративные правила или даже попасть под санкции работодателя. А если вас уволят, то все личные файлы останутся на корпоративном ноутбуке. Аналогично и с личными компьютеров - нельзя мешать среду где вы скидываете друзьям котиков, и где у вас есть доступ к продакшен базе данных клиента.
2️⃣Баланс между работой и отдыхом
Когда всё в одном месте, границы стираются: сложно полноценно отдыхать, если в браузере открыта Jira, а уведомления Slack всплывают даже в выходные. И наоборот — личные дела могут отвлекать во время работы. Представьте, что вы бронируете себе дорогие авиабилеты, а в этот момент приходит срочный (как вам кажется в моменте) алерт из продакшена. Что будете делать?
3️⃣Конфликты софта и настроек
Корпоративный VPN может ломать доступ к вашим любимым сервисам, а политика безопасности может блокировать запуск нужных программ. Рабочие версии инструментов часто не совпадают с теми, что вам удобны лично. Git, ключи SSH, редакторы, контейнеры — всё может быть настроено по-разному и в итоге начнёт мешать друг другу. Как банальный пример - врядли вы захотите использовать корпоративную сборку VSCode для своих проектов.
4️⃣ Производительность и ресурсы
Рабочие процессы требуют стабильности. Личные эксперименты с софтом, обновления, кастомные настройки, игры и случайные загрузки могут вызвать неожиданные сбои, тормоза или даже полный отказ системы. Неудачный апдейт — и вы остаетесь без рабочего инструмента в критический момент. Что скажете на утреннем синке после такого? :)
5️⃣Чистота и порядок
Раздельные устройства = минимум хаоса. На рабочем ноуте — только рабочие файлы, на личном — всё остальное. Никакого Telegram на рабочем устройстве, никакого Slack на личном — и так со всем. Таким образом будет легче держать фокус и не путать важные данные.
6️⃣Данные на рабочем ноутбуке - собственность компании
Всё, что создаётся на рабочем ноутбуке, юридически принадлежит компании. Если вы делаете личные проекты на корпоративном устройстве, могут возникнуть проблемы: в некоторых случаях работодатель может заявить права на ваш код, файлы или наработки. Особенно это касается программного кода, дизайнов, исследовательских данных и других интеллектуальных активов.
7️⃣Конфиденциальность и защита данных
Если ты используешь личный ноут для работы, особенно с конфиденциальной информацией компании (персональные данные клиентов, финансы, внутренние документы), ты становишься уязвимым с точки зрения законодательства, например:
🔹 Закон о персональных данных (GDPR, 152-ФЗ и т.д.) требует защиты данных от утечек. Если данные слились с твоего личного ноутбука, ты можешь попасть под раздачу.
🔹Работодатель обязан обеспечивать безопасность данных, и для этого обычно используют управляемые устройства (MDM, шифрование, VPN и т.д.). На личном ноуте это сложно реализовать корректно.
💡 Вывод
Разделение ноутбуков помогает эффективно работать, безопасно хранить данные и лучше отдыхать. Если хотите минимизировать стрессы и технические проблемы — лучше сразу выбрать этот подход.
📌 А как у вас: один ноутбук на всё или чёткое разделение рабочих и личных дел? 🤔
Совмещать работу и личные дела на одном устройстве кажется удобным. Но на практике это создаёт массу проблем — частенько даже там, где вы их не видите.
1️⃣Безопасность данных
Рабочий ноутбук под корпоративными политиками: VPN, шифрование, мониторинг, ограниченный доступ к файлам. Загружая туда личные данные, вы рискуете их случайно потерять, нарушить корпоративные правила или даже попасть под санкции работодателя. А если вас уволят, то все личные файлы останутся на корпоративном ноутбуке. Аналогично и с личными компьютеров - нельзя мешать среду где вы скидываете друзьям котиков, и где у вас есть доступ к продакшен базе данных клиента.
2️⃣Баланс между работой и отдыхом
Когда всё в одном месте, границы стираются: сложно полноценно отдыхать, если в браузере открыта Jira, а уведомления Slack всплывают даже в выходные. И наоборот — личные дела могут отвлекать во время работы. Представьте, что вы бронируете себе дорогие авиабилеты, а в этот момент приходит срочный (как вам кажется в моменте) алерт из продакшена. Что будете делать?
3️⃣Конфликты софта и настроек
Корпоративный VPN может ломать доступ к вашим любимым сервисам, а политика безопасности может блокировать запуск нужных программ. Рабочие версии инструментов часто не совпадают с теми, что вам удобны лично. Git, ключи SSH, редакторы, контейнеры — всё может быть настроено по-разному и в итоге начнёт мешать друг другу. Как банальный пример - врядли вы захотите использовать корпоративную сборку VSCode для своих проектов.
4️⃣ Производительность и ресурсы
Рабочие процессы требуют стабильности. Личные эксперименты с софтом, обновления, кастомные настройки, игры и случайные загрузки могут вызвать неожиданные сбои, тормоза или даже полный отказ системы. Неудачный апдейт — и вы остаетесь без рабочего инструмента в критический момент. Что скажете на утреннем синке после такого? :)
5️⃣Чистота и порядок
Раздельные устройства = минимум хаоса. На рабочем ноуте — только рабочие файлы, на личном — всё остальное. Никакого Telegram на рабочем устройстве, никакого Slack на личном — и так со всем. Таким образом будет легче держать фокус и не путать важные данные.
6️⃣Данные на рабочем ноутбуке - собственность компании
Всё, что создаётся на рабочем ноутбуке, юридически принадлежит компании. Если вы делаете личные проекты на корпоративном устройстве, могут возникнуть проблемы: в некоторых случаях работодатель может заявить права на ваш код, файлы или наработки. Особенно это касается программного кода, дизайнов, исследовательских данных и других интеллектуальных активов.
7️⃣Конфиденциальность и защита данных
Если ты используешь личный ноут для работы, особенно с конфиденциальной информацией компании (персональные данные клиентов, финансы, внутренние документы), ты становишься уязвимым с точки зрения законодательства, например:
🔹 Закон о персональных данных (GDPR, 152-ФЗ и т.д.) требует защиты данных от утечек. Если данные слились с твоего личного ноутбука, ты можешь попасть под раздачу.
🔹Работодатель обязан обеспечивать безопасность данных, и для этого обычно используют управляемые устройства (MDM, шифрование, VPN и т.д.). На личном ноуте это сложно реализовать корректно.
💡 Вывод
Разделение ноутбуков помогает эффективно работать, безопасно хранить данные и лучше отдыхать. Если хотите минимизировать стрессы и технические проблемы — лучше сразу выбрать этот подход.
📌 А как у вас: один ноутбук на всё или чёткое разделение рабочих и личных дел? 🤔
Содержание второй части марафона с Александром Шаровым
День 1
— DevOps: философия, а не просто набор инструментов
— Почему DevOps обязан уметь программировать
— Jenkins: жив или мёртв?
— Актуальные инструменты CI/CD
— Kubernetes повсюду
День 2
— Kubernetes — новый язык для разработки инфраструктуры?
— OpenTofu vs Terraform. Что использовать в 2025
— Лучшие инструменты для Terraform и OpenTofu в 2025 году
— *Ops — в чём разница?
День 3
— Software Architecture Document: Что это такое и почему это необходимость для энтерпрайза и зло для стартапа.
— Как грамотно автоматизировать настройку ноутбука?
— Зачем разделять работу и личную жизнь на два ноутбука.
День 1
— DevOps: философия, а не просто набор инструментов
— Почему DevOps обязан уметь программировать
— Jenkins: жив или мёртв?
— Актуальные инструменты CI/CD
— Kubernetes повсюду
День 2
— Kubernetes — новый язык для разработки инфраструктуры?
— OpenTofu vs Terraform. Что использовать в 2025
— Лучшие инструменты для Terraform и OpenTofu в 2025 году
— *Ops — в чём разница?
День 3
— Software Architecture Document: Что это такое и почему это необходимость для энтерпрайза и зло для стартапа.
— Как грамотно автоматизировать настройку ноутбука?
— Зачем разделять работу и личную жизнь на два ноутбука.
This media is not supported in your browser
VIEW IN TELEGRAM
Пока мы андерхудили и не так активно следили за новостями, в Android 16 на смену Material You придет новая дизайн-система — Material 3 Expressive.
Появятся обновлённые динамические темы, адаптивные компоненты, возможность кастомизации быстрых настроек и аналог Live Activities под названием Live Updates.
#android
Появятся обновлённые динамические темы, адаптивные компоненты, возможность кастомизации быстрых настроек и аналог Live Activities под названием Live Updates.
#android
PayPal запустил собственный сервис бесконтактных платежей на iPhone
Вот это интересная новость!
Раньше на iPhone бесконтактные платежи были возможны только через Apple Pay из-за ограничения доступа к NFC-чипу для сторонних приложений.
Вступления в силу DMA в ЕС обязало Apple предоставить сторонним разработчикам доступ к NFC — PayPal стал одним из первых, кто воспользовался этой возможностью.
Важные нюансы:
– пока только для Германии;
– функция доступна в последней версии приложения PayPal для iPhone;
– платежи осуществляются на терминалах, поддерживающих Mastercard;
– для использования необходимо один раз разрешить приложению PayPal доступ к NFC в настройках iOS;
– чтобы быстро оплачивать через PayPal, нужно будет установить приложение в качестве стандартного для бесконтактных платежей.
Вот это интересная новость!
Раньше на iPhone бесконтактные платежи были возможны только через Apple Pay из-за ограничения доступа к NFC-чипу для сторонних приложений.
Вступления в силу DMA в ЕС обязало Apple предоставить сторонним разработчикам доступ к NFC — PayPal стал одним из первых, кто воспользовался этой возможностью.
Важные нюансы:
– пока только для Германии;
– функция доступна в последней версии приложения PayPal для iPhone;
– платежи осуществляются на терминалах, поддерживающих Mastercard;
– для использования необходимо один раз разрешить приложению PayPal доступ к NFC в настройках iOS;
– чтобы быстро оплачивать через PayPal, нужно будет установить приложение в качестве стандартного для бесконтактных платежей.
Media is too big
VIEW IN TELEGRAM
Коллеги, хантить кандидатов в тиндере: норм или стрём?
This media is not supported in your browser
VIEW IN TELEGRAM
Датчик LiDAR способен в буквальном смысле выжечь матрицу камеры
Пользователь хотел заснять автомобиль Volvo EX90 на свой iPhone 16 Pro Max, но во время съемки заметил разрастающиеся пятна в камере.
Пользователь хотел заснять автомобиль Volvo EX90 на свой iPhone 16 Pro Max, но во время съемки заметил разрастающиеся пятна в камере.