Код Меркури

Давайте немного поговорим о главном холиваре в мире IaC: OpenTofu vs Terraform. Ну и что использовать в 2025 для описания инфраструктуры. Почему все так сложно? Контекст драмы - 2023: HashiCorp перевел Terraform на BSL-лицензию, запретив коммерческое использование в конкурентных продуктах. Сообщество взорвалось — так родился OpenTofu (форк Terraform под MPL 2.0). - 2024: OpenTofu набрал хайп, но… внезапно заблокировал доступ для пользователей из России и удалил российские облака из реестра. Теперь оба инструмента стали проблемными для многих команд и проектов. 👉 Если коротко имеем следующую картину: Terraform = стабильность, но BSL и зависимость от HashiCorp/IBM. OpenTofu = open-source, но без российских провайдеров и с политическими ограничениями. К сожалению, подобное происходит не только с Terraform, и подробнее об этом можно прочитать здесь. Ну а пока мы с вами разберемся, что же выбрать для нового проекта в 2025 году. 🔥 Ключевые различия: 1️⃣ Лицензия и открытость 🔹 OpenTofu — полностью open-source (MPL 2.0), управляется сообществом, решения принимаются коллективно, без полного контроля одной компании. 🔹 Terraform — изначально open-source, но теперь использует BSL, что вводит ограничения на коммерческое использование. Развивается HashiCorp (а теперь и IBM). 2️⃣ Функциональность 🔹 Оба инструмента работают по декларативному принципу: вы описываете желаемое состояние инфраструктуры, а система сама приводит её в нужное состояние. 🔹 OpenTofu уже предлагает дополнительные возможности, например: - Шифрование state-файлов из коробки - Ранняя обработка переменных - Улучшения в планировании изменений 🔹Terraform выигрывает в стабильности, интеграциях и зрелости экосистемы. 3️⃣ Экосистема и сообщество 🔹 Terraform существует дольше (7+ лет развития), у него зрелая экосистема, HashiCorp активно поддерживает экосистему плагинов и Terraform Cloud. Помимо этого, Terraform обладает огромной базой пользователей. 🔹 OpenTofu растёт быстрыми темпами, за ним стоят крупные игроки, но его сообщество пока не такое зрелое и сформированное 4️⃣ Ограничения для российских пользователей 🔹Terraform заблокировал доступ к реестру провайдеров ещё в 2022 году, но не удалял существующие провайдеры. 🔹 OpenTofu полностью заблокировал пользователей из России и удалил российских облачных провайдеров вызвал этим длительную дискуссию в сообществе. На данный момент, отсуствие провайдеров в официальном реестре делает его непригодным для работы с российскими облаками. В любом случае, для обхода блокировки реества вам в обоих случаях понадобятся зеркала. Для Terraform их существует достаточно много, а вот для OpenTofu пока ни одного. Про настройку зеркалов вы можете прочитать здесь.

🚀 Kubernetes — новый язык для разработки инфраструктуры? Раньше инфраструктура была просто средой для запуска приложений. Сегодня Kubernetes (K8S) изменил правила игры: теперь инфраструктура — это код, который нужно писать, версионировать и управлять как программным продуктом. Почему Kubernetes стал де-факто "языком инфраструктуры"? 🔹 Декларативный подход — манифесты YAML описывают желаемое состояние системы, а K8s сам обеспечивает его выполнение. Это как сказать системе: «Хочу, чтобы было вот так» — и она сделает всё за вас. 🔹 Композиция — как код состоит из модулей и функций, так и инфраструктура в Kubernetes собирается из Deployments, Services, Ingress и других объектов. Это как LEGO для взрослых — собирай, что нужно, и не изобретай велосипед. 🔹 Абстракции — Разработчикам больше не нужно заботиться о физических серверах, балансировке и автошкаллировании. Всё это управляется на уровне кластера. Вы просто говорите: «Мне нужно 10 подов» — и Kubernetes делает это (но помните, только в случае managed решения). 🔹 Расширяемость — С помощью Custom Resource Definitions (CRD) и Custom API servers можно создавать собственные объекты и управлять ими как встроенными ресурсами. Это как добавить в язык программирования свои ключевые слова. Инфраструктурные инженеры → DevOps-разработчики Если раньше инфраструктура настраивалась вручную или с помощью bash-скриптов, то теперь: ✅ Helm-чарты = пакетные менеджеры ✅ Kustomize = управление конфигурациями без дублирования кода ✅ Operators и CRD = объектно-ориентированное программирование в инфраструктуре ✅ GitOps (ArgoCD, FluxCD) = версионирование и автоматизация развертывания К чему мы идем? Мы движемся к тому, чтобы заранее, на понятном языке, декларировать, что мы хотим от системы. Это понимание должно быть одинаково глубоко на уровне DevOps инженеров и разработчиков. Но почему мы говорим только про K8S? Terraform и подобные инструменты хороши, но они, в первую очередь, описывают облачные ресурсы, что ближе к инфраструктурным инженерам, чем к разработчикам. Kubernetes, напротив, представляет собой более высокоуровневую абстракцию, которая позволяет сосредоточиться на архитектуре приложения и его управлении, без глубокой привязки к конкретным облачным провайдерам и их ресурсам. 💡 Вывод Kubernetes — это не просто оркестратор контейнеров, а новый язык разработки инфраструктуры, который требует от инженеров понимания концепций, аналогичных программированию. А как у вас? Kubernetes — удобный инструмент или сложный барьер для входа? Используете ли вы GitOps, Operators или другие продвинутые практики? Считаете ли вы, что K8S действительно стал «языком инфраструктуры»? PS: Если вам интересно послушать про мой опыт разработки операторов, кастомных планировщиков или подготовку к CKA/CKAD, пишите в комментариях 👇 Сделаю отдельный пост с лайфхаками и советами!

1️⃣ Навигация по первому дню андерхуда — DevOps: философия, а не просто набор инструментов — Почему DevOps обязан уметь программировать — Jenkins: жив или мёртв? — Актуальные инструменты CI/CD — Kubernetes повсюду

"Айсберг K8S технологий"

📌 И напоследок… Kubernetes — это не просто инструмент, это целая экосистема, которая требует глубокого понимания. Если вы думаете, что можно просто «поставить куб и забыть», то вы сильно ошибаетесь. В приложении к посту есть картинка от компании Flant (из доклада «Как правильно сделать Kubernetes» Дмитрия Столярова), которая показывает, насколько глубоким является айсберг Kubernetes. А как вы оцениваете свой уровень владения K8S? Не бесит ли вас, когда кто-то говорит, что умеет с ним работать, но по факту не разбирается дальше создания Deployment? 😅🚀 PS: Как бонус - отличная статья про куб на хабре https://habr.com/ru/companies/h3llo_cloud/articles/902188/

Kubernetes уже у всех, верно? 🤔 Кажется, что так. Иногда разработчики удивляются, когда я не предлагаю K8S для нового проекта. В последнее время у многих сложился майндсет: «Поставил куб — и дальше оно как-нибудь само», вплоть до выписывания TLS сертификатов и автоматического создания DNS-записей. Ну, в целом, конечно, можно накидать YAML'ов и посмотреть, что будет. Но ни одно коробочное решение (вроде CozeStack, DeckHouse или OpenShift) не сделает всё за вас. Kubernetes — это не волшебная таблетка, а сложный инструмент, который требует глубокого понимания. 🚀 Давайте посмотрим, что вам нужно понимать с технической точки зрения , когда вы онбордите Kubernetes. 🔹 Базовый уровень (уровень сертификации CKAD) Это минимум, без которого лучше вообще не лезть в Kubernetes: ✅ Управление подами. Как создавать, удалять и масштабировать поды. ✅ Sidecars и init-контейнеры ✅ PVC/PV. Как хранить данные в Kubernetes и не потерять их при пересоздании подов. ✅ Service / Ingress. Как прокинуть трафик из кластера наружу ✅ Helm / Kustomize. Как управлять конфигурациями через темплейты. 🔹 Средний уровень (уровень сертификации CKA) ✅ Что такое SMI/CNI/etc. Как сети работают в Kubernetes и почему это важно. ✅ Траблшутинг кластера. Как читать логи, смотреть события через kubectl get events и находить корень проблемы. ✅ Разные CNI-плагины и их особенности. Calico, Flannel, Cilium — чем они отличаются и какой выбрать. ✅ Архитектура Kubernetes (правда ли, что куб это всего 5 бинарей?). Как работают kubelet, API-сервер, etcd и другие компоненты. ✅ Service Mesh. Зачем он нужен и как выбрать между Istio, Linkerd и другими. ✅ Автоматизация сертификатов. Как использовать cert-manager или встроенные возможности Istio. ✅ Тюнинг системных компонентов. Например, как оптимизировать etcd для высокой нагрузки. ✅ Генерация YAML'ов через kubectl. Как не писать их вручную и не допускать ошибок. ✅ Работа с секретами. Как безопасно их хранить и управлять ими. ✅ Логирование и мониторинг. Настройка Prometheus, Loki, OpenTelemetry в Kubernetes. ✅ GitOps. Внедрение ArgoCD или FluxCD для управления конфигурациями. ✅ kubernetes-the-hard-way. Если вы прошли этот гайд, то уже понимаете, как всё устроено под капотом. 🔹 Высокий уровень (beyond CKA/CKS) ✅ Kubernetes и eBPF. Как они связаны и что можно сделать с помощью eBPF для улучшения производительности и безопасности. ✅ Кастомные контроллеры. Создание CRD (Custom Resource Definitions) и разработка операторов. ✅ Мультикластерные решения. Как управлять несколькими кластерами и синхронизировать их. Как собрать федерацию. ✅ Безопасность. Использование OPA, Kyverno, Falco для защиты кластера. ✅ Производительность. Как понять, что API-сервер или etcd не справляются с нагрузкой, и что с этим делать.

И сам пример Jenkins Job описанной на Groovy в ту эпоху:

package jobdsl.build.jobs

import com.kvendingoldo.jdcl.core.Functions

class UdcPreCommit {
    static job(dslFactory, jobConfig) {
        dslFactory.job(Functions.generateJobName(jobConfig)) {
            description(jobConfig.job.description)
            label(jobConfig.job.label)
            concurrentBuild()
            logRotator(jobConfig.job.daysToKeepBuilds, jobConfig.job.maxOfBuildsToKeep)
            environmentVariables {
                env('GENERATED_VERSION_TYPE', jobConfig.job.generatedVersionType)
                overrideBuildParameters(true)
            }
            wrappers {
                colorizeOutput()
                timestamps()
                preBuildCleanup()
            }
            scm {
                git {
                    remote {
                        credentials(jobConfig.job.credentials.github)
                        github(jobConfig.job.repository, 'ssh')
                        refspec('+refs/pull/*:refs/remotes/origin/pr/*')
                    }
                    branch('${sha1}')
                    extensions {
                        wipeOutWorkspace()
                        submoduleOptions {
                            recursive()
                        }
                    }
                }
            }
            triggers {
                githubPullRequest {
                    cron('*/1 * * * *')
                    permitAll()
                }
            }
            steps {
                gitHubSetCommitStatusBuilder {
                    statusMessage {
                        content('building...')
                    }
                }
                shell(dslFactory.readFileFromWorkspace('jobdsl/common/bash/emailValidator.sh'))
                shell('gcloud docker -a')
                shell(dslFactory.readFileFromWorkspace(jobConfig.job.variablesGeneratorScript))
                shell(dslFactory.readFileFromWorkspace(jobConfig.job.versionGeneratorScript))
                envInjectBuilder {
                    propertiesFilePath('variables.txt')
                    propertiesContent('')
                }
                buildNameUpdater {
                    fromFile(false)
                    buildName('${VERSION}')
                    fromMacro(true)
                    macroTemplate('${VERSION}')
                    macroFirst(false)
                }
                maven {
                    goals('clean install')
                    goals('-B')
                    goals('-C')
                    goals('-q')
                    goals(' -Pimage')
                    goals('-Ddocker.registry.host=gcr.io')
                }
            }
            publishers {
                gitHubCommitNotifier {
                    resultOnFailure('fail')
                    statusMessage {
                        content('build is completed')
                    }
                }
            }
        }
    }
}

Последний пост про Jenkins на сегодня. Страшно представить, но когда-то, в 2017 или 2018 году, я сам пытался построить свой IAC-фреймворк для создания Jenkins Jobs — на тогда ещё новомодном JobDSL. Сейчас это выглядит перегруженно и дико, но тогда казалось настоящим прорывом: автоматизация в виде кода вместо ручного накликивания джоб. Если вам интересна археология, вот те самые репозитории: 🔗Сам фреймворк: https://github.com/kvendingoldo/JDCL 🔗Пример описания Jenkins Jobs: https://github.com/kvendingoldo/udc-jobdsl А раз уж сегодня говорили о важности программирования для DevOps, вот вам фрагмент «страшного» кода того времени — для автоматизированного создания Jenkins Jobs:

  def processConfig(String jcPath) {
        def jc

        if (this.type == 'LOCAL') {
            jc = new Yaml().load(new File(jcPath).getText('UTF-8'))
        } else if (this.type == 'JENKINS') {
            jc = new Yaml().load(this.dslFactory.readFileFromWorkspace(jcPath))
        }

        if (jc.containsKey('imports')) {
            def jcChild = jc.findAll { key, _ -> !(key in ['imports']) }

            (jc.imports).each { jcImport ->
                def jcParent = processConfig("${this.importDirectory}/${jcImport}")
                if (jcChild.job!=null) {
                    jcChild = merge(jcChild, jcParent)
                } else {
                    jcChild.findAll { key, _ -> !(key in ['job']) }.each { key, value ->
                        jcChild."${key}" = merge(jcChild."${key}", jcParent)
                    }
                }
            }
            return jcChild
        } else {
            return jc
        }
    }

    private def merge(def config, def object) {
        object?.each { key, value ->
            if (config."${key}" == null || (!config.containsKey(key))) {
                config."${key}" = value
            } else {
                if (!(config."${key}" instanceof String)) {
                    config."${key}" = merge(config."${key}", value)
                }
            }
        }
        return config
    }

💡 Итоги Jenkins — это легенда, но мир движется вперёд. Современные инструменты предлагают простоту, скорость и безопасность, которые Jenkins уже не может обеспечить в полной мере. Однако он всё ещё остаётся мощным решением для сложных сценариев и легаси-проектов. Стоит ли выбирать Jenkins? Скорее всего, нет. Сейчас есть более простые, удобные и масштабируемые альтернативы, которые позволяют быстрее достигать результата. А как у вас? Вы до сих пор на Jenkins или уже перешли на что-то более удобное? Делитесь опытом в комментариях! 🤔👇 PS: В качестве бонуса можете посмотреть выступление с последнего DevOpsConf, на котором снова заговорили про Jenkins: https://www.youtube.com/watch?v=OlD25Cbig_U PSS: Две недавние статьи, где авторы придерживаются примерно тех же мыслей: - https://medium.com/@osomudeyazudonu/stop-using-jenkins-4dcb7e4f0e53 - https://habr.com/ru/articles/902300/

📊 А что с классическим Jenkins? Несмотря на всё вышесказанное, Jenkins всё ещё жив и активно используется. Взглянем на цифры за 2024 год (stats.jenkins.io): 📌 Активные jobs: 82 000 000+ 📌 Подключенные nodes: 1 000 000+ 📌 Коммиты: 51 000+ 📌 Релизы: 13 LTS, 50 Weekly 📌 Pull Requests: 6000+ 📌 GitHub Stars: 23 000+ 📌 Контрибьюторы: 3000+ 📌 Компании-использователи: 39 000+ Как видите, Jenkins по-прежнему используется в крупных компаниях, включая FAANG по следующим причинам: 🔹 Гибкость и мощность — он остаётся универсальным инструментом для действительно сложных пайплайнов. Кастомизировать можно все, что угодно. 🔹 Легаси-инфраструктура — многие проекты исторически зависят от Jenkins, и миграция может быть очень затратной. 🔹 Расширяемость — тысячи плагинов позволяют адаптировать Jenkins под любые нужды.

🛠️Что используют сегодня для CICD? ✅ GitHub Actions — встроенные CI/CD-пайплайны в экосистему GitHub. Простая настройка, бесплатный тариф для open-source, активное развитие. ✅ GitLab CI/CD — монолитное решение, встроенное в GitLab. Поддерживает автоматизацию тестирования, сборки и деплоя, имеет удобную YAML-конфигурацию. ✅ ArgoCD + Kubernetes — идеальный вариант для GitOps, декларативного управления деплоями в Kubernetes. ✅ CircleCI, Drone, Tekton — мощные CI/CD-инструменты для различных сценариев, особенно в облачных и контейнерных средах. ✅ Jenkins X — попытка адаптации к современным реалиям, облачная версия, ориентированная на Kubernetes и GitOps. Однако его популярность остаётся низкой, а переход на него требует значительных усилий.

Поговорим про всеми любимый Jenkins! Когда-то данный тул был стандартом де-факто для CI/CD и топ-1 инструментом для DevOps в резюме. Гибкость, тысячи плагинов, возможность кастомизации под любые задачи — всё это сделало его мощным инструментом. Но времена меняются, и сегодня Jenkins уже не выглядит таким удобным, современным и безопасным, как раньше 🚨Почему Jenkins теряет позиции? Все чаще встречаются проекты, работающие исключительно на GitHub / GitLab CI/CD, и многие инженеры адже не видели Jenkins вживую. Давайте разберёмся, почему это происходит. 1️⃣ Сложная настройка и поддержка Jenkins требует выделенных серверов, своевременных обновлений, управления зависимостями и постоянного администрирования. В эпоху облачных решений, где всё работает «из коробки», это выглядит как избыточная сложность. Современные инструменты позволяют настраивать пайплайны за минуты, а не тратить часы на настройку Jenkins. 2️⃣ Устаревший подход Современные CI/CD-инструменты используют декларативные конфигурации в YAML, которые просты, понятны и легко читаются. А что у Jenkins? Groovy-скрипты, сложные pipeline-декларации и необходимость писать кастомные плагины. Если вы когда-нибудь пробовали это делать, то знаете: Groovy + Java = боль. 3️⃣ Более быстрые и простые альтернативы Облачные CI/CD-решения позволяют настраивать пайплайны за минуты, а не часы. Они легко интегрируются с современными DevOps-практиками, такими как GitOps и Kubernetes. Jenkins пытается догонять конкурентов, но время уходит, и разрыв только увеличивается. 4️⃣ Высокий уровень уязвимостей Jenkins известен своими уязвимостями. Многие из них имеют статус high или даже critical, особенно в плагинах. А ещё есть небезопасное выполнение (не)изолированного Groovy-кода, что делает систему мишенью для атак. В эпоху, когда безопасность стоит на первом месте, это серьёзный минус.

«Зачем учиться писать код, если можно просто спросить у ChatGPT?» 🤖💬 И правда — казалось бы, зачем? Открыл ChatGPT или Cursor, написал «сделай мне модуль» — и готово. AI сам всё сделает: 🧩 шаблон наклепает 🔤 переменные придумает 📄 документацию сгенерирует Но есть нюанс: чтобы понять, он выдал рабочий код или полную чушь, ты должен уметь его прочитать, понять и оценить. 👉 Это синтаксически валидно? 👉 Это безопасно? 👉 Это вообще работает, или просто похоже на правду? Ты смотришь: "Хмм… что-то странно" — идёшь уточняешь, меняешь запрос, и в итоге приходишь к чему-то нормальному. Вот для этого и нужен практический опыт, который касается любого языка на котором ведется разработка. Вывод: AI — это ускоритель, но не замена головы. Чтобы эффективно пользоваться умными тулзами — надо уметь писать код руками 🛠️🧠

Мы уже говорили про университет и образование,но давайте по-честному — айтишник без кода — как бариста без кофе ☕🧑‍💻 В универе у меня была монорепа —туда летело всё: эксперименты, кривые скрипты, тестовые проекты. Сейчас она уже мертва и задепрекейчена 🪦, но пока я писал этот пост, то зашел в нее чтобы посмотреть статистику и она оказалось очень даже не скучная 📊 💡Вывод простой: Неважно, кто ты — QA, DevOps, Java-разработчик — программируй много и часто. Спустя 2, 4, 5 или 10 лет тебе точно не понравится свой старый код, но и не должен был писать его красиво —ты писал его, чтобы набить руку 🛠️ и прокачаться.

Продолжаем холивары 🔥 Часто можно услышать, что DevOps — это «админ, который автоматизирует». Но это миф. Хороший DevOps-инженер — это не просто человек, который пишет скрипты для рутины, а специалист, находящийся на стыке инфраструктуры и разработки. Без навыков программирования здесь далеко не уйти. Почему важно уметь программировать? 🔹 Автоматизация — это код, а не костыли - Вся суть DevOps — в устранении ручных действий. Без кода и понимания структур данных автоматизация превращается в набор костылей - Infrastructure as Code (Terraform, Pulumi) требует знания синтаксиса и логики. - K8S Operators — это по сути программы на Go, управляющие объектами в K8S кластере. Jenkins plugins? Да, их тоже пишут на Groovy. 🔹 CI/CD это полноценные конвееры доставки Работа с CI/CD — это не просто «настройка пайплайнов». Это разработка сложных сценариев: - Взаимодействие с API (GitHub, AWS, Slack). - Написание проверок: «Почему деплой упал?» → Анализ логов через Python-скрипты. - Автоматизация rollback-стратегий: если новая версия сломалась, система сама откатывается. Без знания Bash, Python, Go и понимания YAML/JSON сложно создать эффективный пайплайн. 🔹 Отладка и оптимизация Когда приложение падает, DevOps должен понимать, почему оно упало: - Читать код, чтобы найти например утечку памяти. - Анализировать стектрейсы на Java/Python. - Находить узкие места в производительности (например, медленные SQL-запросы). - Понимать какие функции нагрузают CPU 👉 Без навыков программирования вы станете тем, кто просто перезапускает контейнеры и надеется на лучшее. 🔹 Создание инструментов Хороший DevOps — это инженер, а не просто администратор. В реальных задачах часто приходится писать утилиты для деплоя, операторы для Kubernetes, плагины для Terraform, парсеры логов, а иногда и бэкенд для внутренних сервисов DevOps-команды. Python и Go — одни из лучших языков для этих задач. 🔹 Диагностика и поиск узких мест DevOps-инженер нередко занимается профилированием и поиском проблем: 📌 Почему контейнер использует 2 ГБ памяти вместо 200 МБ? 📌 Где узкое место в производительности базы? 📌 Почему HTTP-запросы стали медленнее? 📌 Как устранить утечки памяти в JVM-приложении? Без понимания кода вы будете строить гипотезы, но не находить точных причин. 🔧 Какие еще хард-скиллы нужны DevOps? ✅ Языки программирования: Python, Go, Bash (скрипты, API-интеграции, инструменты). ✅ IaC (Infrastructure as Code): Terraform, Ansible, Pulumi, CloudFormation. ✅ Контейнеризация и оркестрация: Docker, Kubernetes, Helm. ✅ CI/CD: GitHub Actions, GitLab CI/CD, Jenkins, ArgoCD. ✅ Облака: AWS, GCP, Azure. ✅ Мониторинг и логирование: Prometheus, Grafana, ELK, Loki, OpenTelemetry. ✅ Сетевые и операционные системы: Linux, TCP/IP, DNS, безопасность. ✅ Диагностика производительности: профилирование JVM, анализ логов, трассировка запросов. 💡 Вывод Программирование — не просто «полезный навык», а одна из ключевых компетенций DevOps-инженера. Без него автоматизация превращается в хаос из скриптов, CI/CD работает «как придется», а поиск проблем — в бесконечные гипотезы без точных выводов и гадание на кофейной гуще. 🔥 А как часто вам приходится программировать на позиции DevOps? 🤔 Давайте ломать стереотипы в комментах! 👇

🎯 Итог: DevOps — это не просто тренд / тайтл DevOps — это не должность, не технология и даже не команда. Это образ мышления и совокупность практик, которые позволяют создавать устойчивые, масштабируемые и надёжные системы. 🚀 А как у вас в компании? DevOps — это реальная практика или просто модный термин? 🤔👇

📚 Как лучше понять DevOps? Если хотите не просто разобраться в инструментах, но и вникнуть в DevOps как в культуру, рекомендую прочитать «Проект Феникс» (The Phoenix Project). Это не учебник, а бизнес-роман, который показывает реальные проблемы IT-команд: долгие релизы, завалы тикетов, хаотичные процессы. Книга объясняет DevOps не через технологии, а через мышление и процессы. После неё стоит прочитать: 📖 «The Unicorn Project» — продолжение «Феникса» с фокусом на разработчиков и DevOps-подход в их работе. 📖 «Accelerate» — научный разбор принципов DevOps и их влияния на бизнес, основанный на исследованиях. 📖 «Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale» — детально раскрывает культурные аспекты DevOps: как построить сильную команду, наладить процессы и избежать хаоса при масштабировании. 📖 SRE Book (Site Reliability Engineering) — культовый гайд от Google по SRE-подходу (развитие идей DevOps в сторону чётких метрик и надёжности систем). Обязательно к прочтению для любого инженера, связанного с эксплуатацией.

🔍 Что же такое DevOps на самом деле? Часто DevOps воспринимают исключительно как набор инструментов — CI/CD, Kubernetes, Terraform, Ansible... Но это лишь вершина айсберга. DevOps — это культурная трансформация, а не просто технологии. 🔹 От разделения к сотрудничеству Раньше компании жили по принципу «Разработчики создают приложения — админы страдают». DevOps меняет парадигму: ✅ Разработчики и администраторы работают вместе ✅ Ответственность за продукт разделяется между всеми ✅ Меньше конфликтов, больше эффективности 🔹 Автоматизация как необходимость В современном мире ручные процессы — враги скорости и стабильности. DevOps убирает человеческий фактор, внедряя: ⚙️ Инфраструктуру как код (IaC) – Terraform, Pulumi, SDK 🔄 Автотестирование – Unit, Integration, E2E 📈 Мониторинг и логирование – Prometheus, ELK, Grafana 🤖 CI/CD пайплайны – GitHub Actions, GitLab CI/CD, ArgoCD DevOps опирается на итеративный подход: 🔹 Маленькие и частые релизы вместо редких, но рискованных 🔹 Постоянный мониторинг — ошибки исправляются сразу 🔹 Обратная связь от пользователей → продукт улучшается в реальном времени Таким образом, DevOps делает бизнес более гибким, а IT-инфраструктуру — стабильной и предсказуемой.