Позвали менеджера, QA и дизайнера оценить мерч, который мы подготовили для команды. В первой части: модные сережки, слишком маленький коврик для Руслана и распределяющая панама.

Какую оценку ставим?

#team

Помните Скрепыша из Windows 97? Так вот… он вернулся и не просто так, а в роли ИИ-помощника 🤖

Прокаченный Скрепыш — теперь ИИ-помощник, который умеет запускать нейросети вроде Gemma, LLaMA и Qwen, работает оффлайн, без установки и самое главное — бесплатно.

Интерфейс всё такой же ностальгично-пиксельный, но теперь внутри — целая нейронка 🤖

Посмотреть можно тут 👈

Как пройти в финал собесов в Google, Amazon и Netflix?

Парень, который это сделал, поделился своими главными лайфхаками из своего резюме. Кратко и по делу👇

- Пишите как историю. Не просто «делал то-то», а покажите путь: что решили, чему научились, где взяли на себя больше, чем ожидали.

- «Что изменилось благодаря вам?». Каждый пункт должен отвечать на этот вопрос. Так ваш вклад будет очевидным и значимым.

- Только одна страница. У вас есть меньше 10 секунд, чтобы рекрутер захотел читать дальше. Уместите главное, отрежьте лишнее.

- GitHub — не витрина, а кейс. Если вы технарь — добавьте пару реальных проектов. Они скажут о вас больше, чем любые фразы.

- Чистый и чёткий формат. Без декоративных шрифтов и креатива ради креатива. Резюме должно быть простым, аккуратным и логичным.

🧠 У 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
    }