OrangeDevOps

Мидл - это не три года опыта Вторая статья про грейды. Начинается с истории, которую видел каждый: два инженера, стаж и стек в резюме совпадают до строчки, а офферы - "мидл, 200" и "сеньор, 300". Разница 100 тысяч в месяц при неотличимых резюме. Рынок не сошёл с ума, он меряет не то, что написано в резюме. Внутри: • почему традиционная рамка "годы, стек, самостоятельность" стоит на трёх гнилых ногах • грейд как тип ответственности: "делаю надёжно", "проектирую и обосновываю", "управляю рисками и экономикой" • один тикет "переехать на новый registry" глазами мидла, сеньора и руководителя - три разные работы под одной формулировкой • три вопроса, чтобы найти свой реальный уровень. Спойлер: профиль почти у всех неровный, и это карта роста, а не диагноз. Вэлком в комментарии на Хабре: тема из тех, где у каждого есть история про несовпадение грейда и человека. Коллекцию пополняйте там. https://habr.com/ru/articles/1068538/

Успех «вайб-кодинга» сложных проектов, по мнению Бауыржана, заключается не в автоматической генерации всего подряд, а в роли человека как архитектора и QA-инженера. Разработчик задает точные спецификации, проводит ревью планов ИИ, синхронизирует контекст и утверждает или откатывает изменения https://youtu.be/BPF0MA8-OSQ?si=mf4v_vHeDoylXp5_&t=3652 #ai https://youtu.be/BPF0MA8-OSQ?t=3710 #ai

Интервью от fouderа компании Relog. Было интересно посмотреть ту часть видео в котором говорится про используемые им модели llm и прядок подготовки проекта перед генерацией кода ai. 1. Используемые LLM: использует комбинированный подход, подбирая конкретные модели под определенные задачи. Модели семейства Claude от Anthropic : Для каких задач: Написание сложного бэкенд-кода, проектирование архитектуры и системный дизайн. Причины: считает Claude (в частности версию Opus) невероятно крутым инженером, который глубоко понимает технические нюансы, алгоритмы и архитектуру. Модель показывает наивысшие результаты в программировании по бенчмарку SWE-bench Verified и отлично справляется с задачами на длинном горизонте планирования (Long Horizon Tasks), где требуется непрерывное "обдумывание" сложных задач (до 30 часов). Кроме того, Claude даёт больше точности и меньше лишнего текста по сравнению с конкурентами. Модели семейства GPT от OpenAI: Для каких задач: Генерация детализированных технических заданий (PRD — Product Requirements Document), текстовых описаний проекта и инструкций для ИИ-инженера. Причины: Бауыржан отмечает, что для работы с текстом и детального продумывания спецификаций модели GPT подходят лучше, чем Claude. GPT более эффективно расписывает подробные инструкции, которые затем передаются кодинг-агентам. Lovable: Для каких задач: Быстрое создание пользовательских интерфейсов (frontend), посадочных страниц (landing pages) и визуальной части проектов. Причины: Позволяет моментально генерировать UI по текстовому описанию без необходимости писать код вручную, модель сама подбирает стили и цвета. Бауыржан также упоминает тестирование других моделей, например, Gemini DeepSync от Google, но отмечает, что для задач программирования она уступает топовым моделям OpenAI и Anthropic. 2. Методология предварительной подготовки и планирования (Workflow) Бауыржан подчеркивает, что без понимания архитектуры и правильной постановки задач ИИ создаст лишь нерабочий прототип, а не масштабируемый продукт ( для production). Этот подход называется Specs Driven Development (Разработка на основе спецификаций). Процесс планирования до генерации кода выглядит следующим образом: Этап 1: Создание детального PRD (Product Requirements Document) До написания единой строчки кода Бауыржан тратит время (иногда дни) на создание подробного ТЗ. Он описывает ИИ изначальную идею и просит модель (обычно GPT) исправить ошибки в логике и улучшить описание: "fix the errors if any and improve me this project description". Для сложных проектов он просит GPT сгенерировать детальную инструкцию. Этап 2: Инициализация файла контекста (cloud.md или cursor.md) В редакторе кода Cursor он создает минимальный базовый markdown-файл, в котором зафиксированы идея проекта, архитектура и основные правила. Этот файл становится "единым источником истины". Бауыржан не перегружает ИИ огромным количеством жестких правил (чтобы не засорять контекст), а позволяет модели самой принимать решения, опираясь на этот базовый документ. Этап 3: Режим планирования (Plan Mode) и уточняющие вопросы Бауыржан не просит агента сразу генерировать код. Он загружает PRD в агента (Claude Code) и запускает режим Plan Mode. В этом режиме ИИ-агент задает уточняющие вопросы (например, про выбор стека, деталей интерфейса и логики), после чего пишет пошаговый план реализации. Бауыржан вручную проводит ревью (проверку) этого плана, и только если он его устраивает, дает команду на реализацию (implementation). Этап 4: Синхронизация и поддержка актуальности (Sync) После внесения важных изменений Бауыржан заставляет ИИ-агента обновить главный файл документации (команда «update cloud md файл»), чтобы агент не "забыл" архитектуру. Периодически он просит ИИ сделать summary (краткую выжимку): "расскажи мне очень ёмко о проекте, чем мы занимаемся, какие фичи реализовали". Это позволяет убедиться, что ИИ правильно понимает текущее состояние проекта и не сбился с курса.

https://books.yandex.ru/books/CwYBL9nR?utm_source=direct_link&utm_campaign=users_referral&utm_medium=referral Готовимся к выходу на работу) Рекомендую. Вроде очевидно, но разложено по полочкам и без воды.

KISS имеет смысл, когда: 🔹У вас менее 500 сред. Размер команды — от небольшого до среднего (< 50 инженеров). 🔹Частота изменений низкая (инфраструктура в основном стабильна после первоначального развертывания). 🔹Оперативная ясность имеет решающее значение (регулируемые отрасли). 🔹В команде работают специалисты с разным уровнем опыта (в основном системные администраторы, а не разработчики). 🔹Скорость устранения неполадок важнее элегантности кода. Использование метода DRY имеет смысл в следующих случаях: 🔹У вас действительно масштабная система (более 1000 сред с взаимозависимостями). 🔹Ваша команда состоит в основном из инженеров-платформеров, хорошо разбирающихся в абстракциях. 🔹У вас есть специальная команда, занимающаяся поддержкой платформы и инструментарием. 🔹Настройки среды содержат сложную общую логику, которая часто меняется. 🔹Вы создаёте инфраструктуру как продукт, рассчитанный на множество потребителей. 🔹Для обеспечения соответствия требованиям необходимо внедрять единые шаблоны во всех развертываниях.

Автор рассматривает два принципа DRY и KISS в контексте написания кода IaC. Самая опасная ловушка в работе над инфраструктурой — это полюбить инструмент, а не решать саму проблему. Когда команды тратят месяцы на создание сложных иерархий с динамической генерацией и замысловатыми моделями наследования, они часто решают проблемы, связанные с эстетикой кода, а не с потребностями бизнеса. В центре внимания оказывается инфраструктура, а не то, что она позволяет делать. Качественная разработка инфраструктуры незаметна. Она позволяет другим командам быстро внедрять новые продукты, не задумываясь о базовых платформах. Для внесения простых изменений не требуются специальные знания. Она не становится узким местом или предметом гордости, она просто существует, работает и незаметно обеспечивает функционирование бизнеса. С этим надо смириться. «Умное» решение, демонстрирующее инженерное мастерство, часто оказывается неправильным для бизнеса. «Скучное» решение, которое любой может понять и модифицировать, часто оказывается правильным. https://rosesecurity.dev/2025/11/14/kiss-versus-dry-iac.html

Доброе утро!

ConfigHub официально запустился — это стартап от Brian Grant (оригинальный архитектор Kubernetes), Alexis Richardson (основатель RabbitMQ и Weaveworks) и Jesper Joergensen (бывший продуктовый лид Heroku и топ Twilio). Летом 2024 они были в режиме стелса и только набирали команду, теперь вышли с готовым продуктом. Проблема, за которую они взялись: управление конфигурациями в облачных системах превратилось в хаос. Настройки разбросаны по десяткам мест от Git-репозиториев и YAML-файлов до облачных сервисов и систем управления секретами. Чем больше мест, где всё это хранится, тем выше риск что-то сломать при изменениях. ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе. Продукт уже работает для пользователей Kubernetes, Helm и GitOps. Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит. Источник — пост Alexis Richardson на LinkedIn.

Понаблюдаем

Собираем образ сами #minio

Давно читал про это решение для упрощения разверывания сайтов на php - Wordops Вот дошли руки, так сказать на посмотреть. wget -qO wo wops.cc && sudo bash wo wo stack install Две команды автоматически разворачивают готовое окружение для статических или php (Wordpress) сайтов. Есть своя web админка. Еще одной командой развернул пустой сайт на Wordpress: wo site create site.com --wp Нравятся инструменты не ломающие конфиги устанавливаемых приложений, а просто помогающие настроить все как надо и быстро. Хочешь потом руками настраивай дальше. Альтернатива ansible или docker для быстрого развертывания. У меня была кстати репа для поднятия wordpress чере docker (давно ее не обновлял, но в целом чуть подправить и будет посвежее) P.S. Выдавал ошибки при установке стека из-за недоступности некоторых репозиториев Надо их закомментировать в файлах: /usr/share/ubuntu-release-upgrader/mirrors.cfg /usr/share/python-apt/templates/Ubuntu.mirrors /usr/share/python-apt/templates/Debian.mirrors и сделать wo maintenance после чего команда wo stack install отработает

Статья про ansible: чуток истории и краткий обзор всей экосистемы: - Ansible Navigator - Execution Environments - Ansible Builder - Ansible Creator - Ansible Lint - Molecule - AWX - Ansible VS Code Extension - Pulp 3 + Galaxy NG - Event Driven Ansible Иногда привыкаешь запускать ansible-playbook в cli , забывая что есть и более удобные инструменты. Добавил бы еще Semaphore и Rundeck. https://habr.com/ru/companies/astralinux/articles/943136/

#мазок

Очень зашло мок-интервью. Чувствуешь себя джуниором😂 https://youtu.be/gChx3JtZQPA?si=ryvUL-5etonNLV6v

Ты точно знаешь, сколько стоит твой опыт? DevOps-инженеры в одной компании могут получать +100% к зарплате коллег — просто потому, что знают рыночные цифры. Авторы канала Local Talent | Devops собирают анонимные данные о зарплатах в DevOps, чтобы ты мог: - Сравнить свою ЗП с коллегами в таких же компаниях - Узнать вилки для своего уровня (Junior/Middle/Senior) - Сравнить не только цифры, но и корпкультуру в разных компаниях Заполни опрос за 2 минуты →

Кстати сегодня Kubernetes Community Day идет. Кто еще не там го!!! 🚤 VK: Техно | Хардкор RuTube: Техно | Хардкор YouTube: Техно | Хардкор

Еще не отходя далеко от терраформа и иже с ним. Ко мне обратился автор интересной утилиты https://github.com/tofuutils/tenv — это менеджер версий для Terraform, OpenTofu, Terragrunt и Atmos. Установил. Описание хорошее. Скажу удобная штука, чтобы переключаться между версиями TF или просто поставить даже нужную версию. В условиях блокировок со стороны hashicorp можно так перед запуском: export TFENV_REMOTE=https://hashicorp-releases.yandexcloud.net #terraform