🧠 У ChatGPT теперь можно просить ревью кода прямо из GitHub

Новая фича — Deep Research по репозиториям. Отправляете бота в своё GitHub-репо, а он возвращается с:
- анализом кода
- комментами к PR’ам
- прожаркой архитектуры
- ссылками на конкретные строки и участки

Поддержка уже прилетает всем на платных планах.

Swift Regex прокачали — теперь с дебаггером

Писать и проверять регулярки стало намного проще: в Swift Regex теперь есть дебаггер, который шаг за шагом показывает, как работает ваше выражение.

А ещё разработчики собрали в репозитории классную практику:
🧠 объяснения человеческим языком
🧪 примеры на каждый кейс
🤓 задачки для закрепления

Мощная база по регэкспам — вот тут

Если вы давно откладывали знакомство с регулярками в Swift — самое время закрыть этот гештальт.

🧠 Уже 20–21 мая в Маунтин-Вью стартует Google I/O

Ждём пачку громких анонсов:
- Android 16: новый дизайн Material 3 Expressive, виджеты на локскрине, улучшенные уведомления и поддержка Auracast
- Gemini Ultra: свежая версия топовой AI-модели + слухи о подписках Premium Plus и Pro
- Astra и Mariner — ИИ-агенты, которые умеют понимать мир в реальном времени и даже «гулять» по интернету за вас
- Утечка намекает на генератор видеообзоров на базе Veo 2 и апдейт NotebookLM

Также обещают сессии по Chrome, Google Cloud, Wear OS, Android XR и новой открытой AI-коллекции Gemma.

Паша о том, как оказался в нашей команде 🪐

#team

Всем привет! С вами снова Александр Шаров. В этом посте мы поговорим про мою специализацию — DevOps.

Наверное, многие, кто работает в энтерпрайзе, сталкивались с DevOps-командами или отдельными специалистами с таким тайтлом. Но что на самом деле скрывается за этим термином?

📜 Немного истории
DevOps как концепция родился в 2009 году, когда Патрик Дебуа (Patrick Debois) организовал первую конференцию DevOpsDays. Но корни движения уходят в 2000-е, когда компании вроде Google и Amazon осознали, что стены между разработкой и администрированием мешают инновациям.

До этого мир жил по принципу «Dev vs. Ops»:
✅ Разработчики пишут код → отправляют его в продакшен
✅ Администраторы и инженеры обеспечивают его стабильную работу
💥 Проблемы? → Каждый винит друг друга -> сроки релиза бесконечно сдвигаются

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-инфраструктуру — стабильной и предсказуемой.

📚 Как лучше понять 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 — это не должность, не технология и даже не команда. Это образ мышления и совокупность практик, которые позволяют создавать устойчивые, масштабируемые и надёжные системы.

🚀 А как у вас в компании? DevOps — это реальная практика или просто модный термин? 🤔👇

Продолжаем холивары 🔥
Часто можно услышать, что 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? 🤔 Давайте ломать стереотипы в комментах! 👇

Мы уже говорили про университет и образование,но давайте по-честному — айтишник без кода — как бариста без кофе ☕🧑‍💻

В универе у меня была монорепа —туда летело всё: эксперименты, кривые скрипты, тестовые проекты. Сейчас она уже мертва и задепрекейчена 🪦, но пока я писал этот пост, то зашел в нее чтобы посмотреть статистику и она оказалось очень даже не скучная 📊

💡Вывод простой:
Неважно, кто ты — QA, DevOps, Java-разработчик — программируй много и часто. Спустя 2, 4, 5 или 10 лет тебе точно не понравится свой старый код, но и не должен был писать его красиво —ты писал его, чтобы набить руку 🛠️ и прокачаться.

«Зачем учиться писать код, если можно просто спросить у ChatGPT?» 🤖💬

И правда — казалось бы, зачем?
Открыл ChatGPT или Cursor, написал «сделай мне модуль» — и готово. AI сам всё сделает:
🧩 шаблон наклепает
🔤 переменные придумает
📄 документацию сгенерирует

Но есть нюанс:
чтобы понять, он выдал рабочий код или полную чушь, ты должен уметь его прочитать, понять и оценить.
👉 Это синтаксически валидно?
👉 Это безопасно?
👉 Это вообще работает, или просто похоже на правду?

Ты смотришь:
"Хмм… что-то странно" — идёшь уточняешь, меняешь запрос,
и в итоге приходишь к чему-то нормальному.
Вот для этого и нужен практический опыт, который касается любого языка на котором ведется разработка.

Вывод:
AI — это ускоритель, но не замена головы. Чтобы эффективно пользоваться умными тулзами — надо уметь писать код руками 🛠️🧠

Поговорим про всеми любимый 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-кода, что делает систему мишенью для атак. В эпоху, когда безопасность стоит на первом месте, это серьёзный минус.

🛠️Что используют сегодня для 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?

Несмотря на всё вышесказанное, 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 под любые нужды.

💡 Итоги
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 на сегодня. Страшно представить, но когда-то, в 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 Job описанной на Groovy в ту эпоху:

package jobdsl.build.jobs

import com.kvendingoldo.jdcl.core.Functions

class UdcPreCommit {
    static job(dslFactory, jobConfig) {
        dslFactory.job(Functions.generateJobName(jobConfig)) {
            denoscription(jobConfig.job.denoscription)
            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')
                    }
                }
            }
        }
    }
}

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 не справляются с нагрузкой, и что с этим делать.

📌 И напоследок…

Kubernetes — это не просто инструмент, это целая экосистема, которая требует глубокого понимания. Если вы думаете, что можно просто «поставить куб и забыть», то вы сильно ошибаетесь.

В приложении к посту есть картинка от компании Flant (из доклада «Как правильно сделать Kubernetes» Дмитрия Столярова), которая показывает, насколько глубоким является айсберг Kubernetes.


А как вы оцениваете свой уровень владения K8S? Не бесит ли вас, когда кто-то говорит, что умеет с ним работать, но по факту не разбирается дальше создания Deployment? 😅🚀

PS: Как бонус - отличная статья про куб на хабре https://habr.com/ru/companies/h3llo_cloud/articles/902188/