Пост-заглавие

Всё никак не решался начать без этой записи, так что пора перерезать ленточку.

- - - - - - -
Я молодой человек из России. Это мой личный блог про бегство от иллюзорности мира труд в IT. Просто захотел чтобы было, как у всех. Назовём это гадким именем "личный бренд".

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

Мой чудесный сайт: sanch.pet

В этом замечательном месте есть все мои рабочие контакты и чуть более подробная информация про меня. А также там появляются все лонгриды в разделе "Blog". Сайт двуязычный, по умолчанию English, переключалка справа сверху.

В остальных местах меня можно искать по нику sanchpet. Даже там, где не следовало бы.
- - - - - - -

На этом всё. Будьте здоровы. Приятного чтения!

Я, как и многие, страдаю привычкой складывать полезные и зацепившие меня посты в "избранное" и потом к ним не возвращаться. Или возвращаться очень-очень редко.

Я не так давно сменил работу. А ещё на днях в избранных записях наткнулся на эту запись.

Это такая жиза. На проекте, в который я перешёл работать, незадолго до этого уволился последний DevOps. Компетенции худо-бедно раздали, разработчикам удалось рассказать мне, как делать релизы. Разумеется, нельзя за пару недель передать все инфраструктурные знания людям, которые в этой области не работали. И задокументировать всё тоже нереально, как бы ни хотелось.

В таких условиях уютного онбординга с чаем и печеньками не будет, надо как можно скорее включаться в боевые задачи, что мне уже представилась возможность сделать. Я иду по рабочему стэку как по айсбергу, снизу вверх. Порядок нажатия кнопок в CI/CD — это самый верх, я должен буду досконально знать, как работает билд и деплой, потому что рано или поздно туда потребуется вносить изменения. И я по чуть-чуть погружаюсь всё глубже.

Необходимо сделать лирическое отступление - почти все IT проекты полны странных решений. Мы все знаем best practices, но далеко не всегда можем им следовать. Где-то доступов нет, где-то нельзя использовать ту или иную технологию, где-то не было мощностей. Проекты развиваются годами, люди приходят и уходят, старые ограничения могут переставать действовать. Да только ресурсов перепилить легаси нет, вроде работает, люди заняты более насущными вопросами и почти все и забыли про эту штуку. Только человек, который может увидеть развитие продукта в масштабе всей его истории, может пояснять за такие моменты.

И вот я на новом проекте вижу странное решение, и мне начинает казаться, что до меня его ввёл в проект, мягко скажем, некомпетентный коллега. И начинается этот цикл "да я сейчас всё переделаю правильно!!!", описанный в статье по ссылке. Всегда, сталкиваясь со странным решением, я чувствую, что оно не вписывается в мою зону комфорта. Каждый запуск такого скрипта - как заноса в пальце. И я уже тихонечко про себя постанываю, "как же все кроме меня не шарят за настоящий DevOps!"

Вот тут и надо остановиться, пока не начал направо и налево всем кричать, что они ослы. Скорее всего, неправым окажусь именно я. Я для себя выделил несколько причин, почему это чаще всего ошибка:

1) Ты не знаешь всей последовательности развития проекта и предыдущих обстоятельств, и поэтому не можешь оценить корректность введённых решений.
2) Совершенно не факт, что твоё идеальное решение будет верным. Очевидно, ты тоже много раз ошибёшься, потому что ты человек. И следующий DevOps будет на тебя чертыхаться.
3) В свете предыдущих пунктов, отрицательные отзывы о предыдущих коллегах, скорее всего, тебя выставят в негативном ключе перед командой. С ними длительное время успешно работали, а ты ещё ничего не успел сделать, тогда почему ругаешься?
4) Раз производственный цикл у команды не встал колом, значит, все эти решения работают здесь и сейчас. Точно ли они нуждаются в переделке и в трате твоих дорогих трудочасов?

Если вплотную подойти к полотну художника и начать вглядываться в холст, ты увидишь только мазки кисти и струпья краски и решишь, что Ван Гог попусту тратил время. Это то, чем в первые месяцы на проекте занимаюсь я — вглядывюсь в детали, не видя всей картины.

Это не отменяет того факта, что легаси иногда надо улучшать. Часть из того, что стригернуло, действительно может вредить. В этом случае надо собрать информацию и по полочкам разложить лицам, принимающим решения, почему это требует переделки, в чём преимущества. Включить в план работ, поставить всех в известность, и взяться за дело.

В процессе всех этих работ главное стремление — упростить сложное. Если сделаю наоборот, то просто увеличу число точек отказа. Надо учиться адаптироваться и искать баланс между простотой и эффективностью. А о других людях плохо думать не надо: людей надо любить.

Назову это дзен-девопсизм. Если никто так раньше не выражался, запатентую эту фразу за собой.

Пятница, друзья мои. А это значит, можно под чашечку душистого чая почитать историю о том, как наиболее дурацким способом починить кластер кубера в Яндекс Облаке.
#k8s #yandexcloud #friday #debug

дисклеймер - возможны фейспалмы

В качестве очень краткой предыстории - проект потихоньку переезжает в Яндекс Облако. У меня коммерческого опыта в нём нет, только через Terraform поднимал там виртуалки и S3 хранилище в качестве учебного проекта на "пощупать". Всегда на работе до этого был собственный периметр, о чём честно сказал на собеседовании, помычав что-то отдалённо внятное про terraform plan, terraform apply (без какой-то осмысленной практики мало вещей запоминается). Тем не менее этого было достаточно. Я тешу себя мыслью, что блистал на вопросах про k8s и linux, поэтому в то, что я разберусь в облаке, быстро поверили.

Пишет мне разработчик: "Саш, у нас что-то в облаке кластер для нагрузочного тестирования не поднимается, посмотри, пожалуйста. Поды висят Pending".

Опустим ситуацию с тем, как ретроград Александр убил время на то, чтобы понять, как через клиент yc вытянуть себе iam-токен для kubectl. Оказывается, всё это необязательно, базовый дебаг можно делать прямо в консоли облака, в веб-интерфейсе кластер, как на ладони. Прикольно.

Поды в статусе ImagePullBackOff. Классика. Смотрим события (для анонимизации имена репозиториев искажены):

Events:
Type    Reason   Age                     From     Message
----    ------   ----                    ----     -------
Normal  Pulling  18m (x19 over 103m)     kubelet  Pulling image "cr.yandex/randomuid/image:1.337-stable-stress"
Normal  BackOff  3m34s (x382 over 103m)  kubelet  Back-off pulling image "cr.yandex/randomuid/image:1.337-stable-stress"

А теперь следите за моей логикой. Я не настраивал Yandex Container Registry, я с ним не работал, Managed k8s я тоже не разворачивал (набрали дилетантов). Я захожу на ноду и вижу, что до сервера registry таймаут. Я интуитивно полагаю, что в managed кластере интеграция с их же registry должна работать нативно, поэтому тут же накатываю тикет в поддержку (впервые в жизни писал в поддержку за советом по куберу, всю жизнь раньше работал по принципу сам отдебажу или умру, как под штангой 100кг в зале). Отвечают быстро, у нас же премиум.

Итог банальный: чтобы работал Container Registry, нужен доступ во внешний интернет. А у нас там на узлах нет внешних интерфейсов, маршрута тоже нет. Пишу разработчику: "а раньше-то развёртывание работало?", в ответ: "да, раньше всё было ок".

Задумался. Курю документацию: можно либо дать узлам публичный IP, либо настроить NAT - либо шлюзом для VPC, либо отдельным инстансом. Понимаю, что не очень понимаю, как сделать правильно и быстро (к тому же походу дела terraform на самом деле и не применялся, но это другой разговор). Публичный IP на каждый узел - точно плохая идея, а с NAT надо разбираться.

Ну ладно, наша задача проста - быстренько поднять это дело, чтобы тестировщики смогли продолжить нагружать стенд. Если у меня есть доступ во внешний интернет и до машин кластера, то я могу скачать образы и импортировать их, всё просто!

(продолжение ниже)

Импортируем образы
(продолжение поста)

Сначала образы надо скачать. Я, дубина, не сразу вспомнил про iam и не понимал, как авторизоваться в облаке. Но мне пришла гениальная мысль - на нодах managed k8s должны быть креды для авторизации в конфиге kubelet! Так и оказалось. Забрал, скачал образы. Далее следите за руками.

Проверяем, какой container runtime использует кластер:

➜  ~ k get nodes -o wide
NAME           STATUS   ROLES    AGE     VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
random-node    Ready    <none>   5d18h   v1.29.1   10.10.10.10    <none>        Ubuntu 20.04.6 LTS   5.4.0-216-generic   containerd://1.7.25

Ага, containerd. В него можно импортировать образы с помощью утилиты ctr, и чтобы их было видно через crictl, не забыть добавить namespace k8s.io:

sudo ctr -n k8s.io images import image.tar

Проверить наличие образа через crictl:

$ crictl images
IMAGE                         TAG                   IMAGE ID            SIZE
cr.yandex/randomuid/image     1.337-stable-stress   68a4c39f6107e       85.2MB

Импортировал так все нужные образы на все узлы (благо подов было немого). Сервисы завелись, тестирование продолжилось.

Я молодец и продолжаю в кратчайшие сроки осваивать курсы по Яндекс Облаку. Ну и будет ещё много постов про облако, потому что чувствую, я с ним повеселюсь ещё не раз.

Призываю в комменты экспертов по Яндекс Облаку - как по бест практисам надо настраивать связь кластеров из внутренней сети до внешнего регистри?

По мере изучения ремесла DevOps многим специалистам, пришедшим в профессию из эксплуатации и системного администрирования, по инерции свойственно сильнее углубляться в Ops, нежели в Dev (и я не исключение).

Чем больше ты узнаёшь, тем обширнее становится твоё столкновение с незнанием (парадокс познания, который описал Сократ своим «я знаю, что ничего не знаю»). Чем ближе подходишь к непосредственным продуктам, тем яснее понимаешь, что всё начинается с разработки (затем идёт продажа, а дальше всё остальное прекрасное - эксплуатация, тестирование, аналитика).

Не претендую на истину, и вообще, вряд ли я всё понимаю верно, опыта всё-таки пока не много.

Но вот что я понял для себя за последний год — зря я когда-то на 2-3 курсе универа полностью открестился от разработки в пользу эксплуатации. Потому что разработка это весело и важно. С другой стороны, всё бы тогда сложилось по-другому, поэтому имеем, что имеем.

Заново пытаюсь учить себя разработке, благо придумал себе пару практических задач. Сейчас устремил своё внимание на Go. Уверен, это хорошая технология для человека, знакомого с C, и поглядывающего на cloud-native подходы к разработке.

Поэтому здесь иногда будут заметки на тему изучения технологий программирования. И вот первая из них:

Читаю A Tour of Go и в сноске нашёл крутую статью. Как язык Go улучшает подход к синтаксису определения сущностей, который читается по-человечески, слева-направо! В отличие от языка C, для чтения деклараций в котором вам стоит использовать правило чтения по-спирали! Часто слышал, что Go создавался с оглядкой на C, и такие детали лучше позволяют понять мотивацию его создателей.
#go #c #programming #friday

Очень круто натыкаться на такие статьи, дающие понять логику технологии, а не только метод её применения. Особенно когда одна из таких статей старше тебя на 8 лет.

2/2

На всякий случай смотрю в консольку, и о чудо, кластер не удалился. Удалился только сервисный пользователь, под которым разработчики ходили в кафку. А не удалился потому, что в манифесте кафки есть такое:

resource "yandex_mdb_kafka_cluster" "kafka01" {
  ...
  deletion_protection = var.kafka_protect
  ...
}

В доке можно посмотреть про параметр, он есть у многих stateful-ресурсов в ЯО, он защищает ресурс от случайного удаления. Помимо того, что провайдеры могут создавать такие поля для своих ресурсов, в Terraform есть также встроенная настройка lifecycle.prevent_destroy для таких случаев. В общем, очень удачная вещь, чтобы ей пользоваться хотя бы от таких вредителей, как я.

Убедился, что кластер цел, смотрю дальше лог plan. Замечаю добавление ресурсов zookeeper. Смотрю в облако, вижу, что zookeeper нет. А он и не нужен, ведь там один брокер в кластере.

    zookeeper {
      resources {
        ...
      }
    }

Убираю конфиг для zookeeper, также ставлю ручное исполнение на apply. Коммит, план, всё окей, настройки обновились, пользователь создался заново, всё работает.

Ценные уроки из изученного материала:

1. CI/CD и GitOps предполагают, что после внесения изменений в репозиторий код должен где-то примениться. Не наоборот. Предположу, что кластер создавался вне Terraform, потом был добавлен в state, а конфигурацию копирнули с препрода и вставили пост-фактум, не применяя. Это выстрелило в таком сценарии, что zookeeper оказался там, где ему было не место.

2. Флаги для защиты от случайного удаления stateful ресурсов придумали не просто так, их стоит использовать. Тут они сэкономили время по восстановлению брокера. За это лайк.

3. Отдать с аутстафа TF-код, в котором apply применяется автоматом, - за гранью христианской морали. Я бы такую вещь вводил только, (1) когда пайплайн прогоняется очень часто, (2) когда окружение dev/stage. Тут же пайп из этой ветки запускался последний раз 2 месяца назад, и вот какая была беда в процессах, что код расходился с актуальным состоянием ресурсов. А я пробежался по пайплайнам, автоматический apply для всех окружений. Короче, подстава. Не рекомендую. Я за осторожность и ручные apply.

4. В идеале кластер должен делаться модулем, в котором будет переменная для zookeeper - вкл/выкл. А модуль уже вызывать из нашего проекта. Но это уже не в тему.

Всё закончилось хорошо, в 18:40 уже вышел из-за компа довольный, что удалось сделать что хотел, и почти ничего не сломать.

A URL to respond with when your boss says "But ChatGPT Said "
Article, Comments

Пригласили через моего коллегу и товарища по Inview @ch4t5ky в СПбИЭУ выступить с лекцией для студентов СПО на тему DevOps.

Хвастаюсь, будет моя первая лекция в жизни, очная, для студентов. В анонсе пишут:

Лекцию проведёт выпускник магистратуры ИТМО Александр Петров - настоящий профи в DevOps <...> Ждём тебя на самой интересной лекции этой осени!

Дистанционно обнимаю редакторов, много приятной похвалы заранее, надо будет выступить на соответствующем уровне!

Будем говорить о том, чем DevOps является, чем не является или является косвенно, какие боли решает DevOps-подход в организациях, немного о DevOps-практиках и о том, кто такой DevOps-инженер и как им можно стать.

Главный вопрос для присматривающего специалиста, конечно, "что такое DevOps?". А как вы для себя на него отвечаете? Хочу посмотреть на разные точки зрения для консолидации нашего опыта)

Уже декабрь, но ещё не вечер. На этой неделе заботимся о психическом здоровье.

#юморвпонедельник

Вчера во второй раз был на митапе нашего клуба Inview, и в первый раз в роли одного из организаторов. Я с ребятами с осени этого года, стараюсь постепенно включаться в работу.

Очень нравится такое полустуденческое-полупрофессиональное сообщество, где нам удаётся быть на стыке этих двух похожих, но разных миров. Кажется, что переход от "я студент, который несколько лет хорошо учился и готов к трудоустройству" до "я специалист с опытом работы в любимой сфере" один из самых сложных в жизни, как профессионально, так и психологически.

Нравится наше позиционирование себя, как клуба инфраструктуры. Хоть большинство из нас DevOps'ы, пытаемся не замыкаться в этой теме и давать больше свободы и себе, и участникам. Это очень интересно.

Один из наших первых проектов, который мы развиваем — репозиторий с кейсами из мира DevOps. В его оформлении я принимаю активное участие. Публикуем интересные задачки, принимаем решения от ребят через MR'ы, некоторые кейсы уже используются в качестве основы для лабораторных работ для студентов ИТМО. Материалы используем для воркшопов, на следующий год планируем очень активно наращивать базу кейсов и вводить геймификацию.

Очень хочу делиться здесь своим участием в жизни клуба, и в целом писать в блог гораздо чаще в 2026 году. Поэтому оставайтесь на связи, будем плодотворно работать :)

Долговато я тут помалкивал. Теперь есть что сказать. Последние 4 месяца наблюдаю некоторый культурный сдвиг, который имею острую необходимость прокомментировать.

- В DevOps-инфополе очень активно продвигается постановка вопроса "человек vs ИИ". Заменяет ли, отупляет ли, ломает ли системы - вопрос освещается с точки зрения противоборства двух сторон. Мокрые нейросетки радостно отмечают любую новость об очередной компании, слившей 500 млн. на ИИ, и грустно сочувствуют волнам "ИИ сокращений", не забывая злорадно напророчить оптимизаторам скорые бедствия и неминуемый откат к человеческому найму (хотя я всё чаще вижу здравые мысли, что сокращения идут не из-за ИИ истерии, а из-за охлаждения экономики IT-сектора, а ИИ просто стал удачным поводом - вместо признания собственных промахов в найме можно отмахнуться инновационностью; тот факт, что мы человека, знающего три команды в терминале, уже считаем инженером, людей начал смущать лишь совсем недавно). Так вот, я, конечно, не очень согласен с этим противопоставлением - пойдём об этом дальше.

- Я сейчас параллельно изучаю историю философии и это оказывается очень полезным делом, потому что после тщательного изучения развития философской мысли начинаешь замечать, что многие "откровения современной техноэволюции" озвучивались ещё две тысячи лет назад. Мне всегда нравилась мысль Максима Дорофеева: "со времён просветления Будды человечество ничего нового не придумало. Всё важное уже было сказано, правда почти никто не слушал, поэтому приходится постоянно повторять". Так вот, погружаясь в онтологический спор Аристотеля и Платона, можно найти метастратегию снятия вместо решения - перед поиском ответа надо проверять предпосылки, и это одно из наследий Метафизики. "Человек думает, а ии имитирует", "заменит или не заменит?", "это сделал я или ИИ?" - дву сущности, между которыми надо исхитриться найти мост, и это проблема, которую можно снять, выполнив переориентацию онтологии. Я присоединюсь к течению тех, кто утверждает - это не две вещи (человек + ИИ), а одна деятельность (мышление, создание, работы) - в которой человек и ИИ просто являются разными модусами участия в едином акте, акте создания систем. Можно разбить ложную дихотомию и вместо этого задаваться вопросами: а что был за акт, какие были в нём модусы участия, какую систему мы строим?

- Аристотелевский ход не сработает в местах, где остаётся реальное различение. Например, моральная ответственность и правовая субъектность задают категориальную разницу между этими понятиями. Человек всегда субъект ответственности - беря на себя роль "управляющего агентными системами", мы повышаем градус ответственности, и повышаем требования к себе, как к инженеру. Каждый может уже сегодня начать осознавать себя тимлидом, которому надо брать ответственность за коллективный труд.

- Ещё одна мысль - прогресс не откатывается назад. Бытует такое мнение - "щас навайбкодят, ИИ пузырь лопнет (ведь рано или поздно все одумаются), и нам потом это разгребать". Я что-то в это не верю. История показывает нам, что то, что когда-то было дорого и редко, через год-два становится доступно каждому за ноль рублей ноль копеек. Когда-то руководство IBM было уверено, что рынок массовых персональных компьютеров не взлетит, что их будет по пальцам посчитать на весь мир; сейчас уже компьютер это неотъемлемая часть нашей интеллектуальной инфраструктуры. Отбери у DevOps'а компьютер - он не сможет заработать себе на хлеб. Я не верю, что ИИ "заберут" - это уже новый способ работы, который с каждым годом будет доступнее.

- Как тогда быть человеку? Ну вот же придумали автомобиль, лифт, подъёмный кран - человек начал замечать, что если не работать самостоятельно, то его тело гниёт. Технология даёт преимущество в краткосрочной перспективе, но если полагаться на неё всегда, это губительно в долгосрок - просто смерть в 55 лет и всё. Поэтому последние 30 лет так развился фитнес, индустрия спортзалов, беговые клубы - раньше проблема стояла не так остро, у человека было (а) больше физического труда, (б) меньше свободного времени. Теперь этого времени стало больше (доехал на работу на автомобиле или на метро; вспахал поле трактором, а не мотыгой) - можно стратегически выделить себе 1 час ежедневного физического труда, чтобы вместо 55 лет прожить хотя бы до 70. Я ещё год назад об этом думал, да жаль, нигде не записал - с появлением ИИ человек осознает наконец, что ему нужен ментальный спортзал точно так же, как физический. Каждый день надо тренировать не только тело, но и мозг - если хочется жить долго и счастливо. ИИ ускоряет мышление и даёт сильнейшую локальную оптимизацию. Но если не развиваться самому, не нагружать себя когнитивной работой, то через 10 лет можно обнаружить себя в ситуации, когда работа сделана, но мышление не изменилось - и даже наоборот, стало в разы слабее. Как ноги офисного червя, десять лет катавшегося на лифте. И можно с рьяными возгласами ругаться на прогресс и ставить тротиловые шашки в шахты лифтов - а можно часик в день по утрам бегать. Вот и мозг надо тренировать точно так же - часик в день, а то и больше, убирать в сторону ИИ, брать качественное руководство по требуемому мастерству (или трансдисциплине) - и читать его медленным чтением, выполняя заметки, размышляя письмом о понятиях и удерживая на них внимание. Это должно быть на уровне гигиены, каждый день. Человек, который может себе объяснить, как функционирует его тело и мозг, не задаётся этими вопросами - он просто каждый день тренирует тело, тренирует мозг, а потом приступает к дневным делам.

- Что касается меня, то как вы могли догадаться, я включил ИИ в свою деятельность по созданию систем. Я сейчас применяю его не только для тривиальных задачек через отдельные промпты, я учусь использовать его как помощника построения моей системы развития. Вот шаблончик. Я использую Claude Code. Прямо сейчас изучаю внутренности работы агента (harness: доставка агенту тулов, context engineering, hooks + security и т. п.) по руководству. Потому что как когда-то от инженера начали требовать знание внутрянки kubernetes (нам всем уже смешно, когда мы видим пользователя, перекладывающего ямлы - это не уровень DevOps; теперь уже стало нормой знать принципы работы, разделение ответственности между бинарниками, принципы отказоустойчивости кластера и т. п.), так теперь оператору агента надо знать, как работает его harness (сбруя, упряжь - зовите как хотите). Хотя бы на базовом уровне понимать, что есть источник агентности, что есть источник знаний об окружении и протокол работы, как эти модусы сущности рождают агента (а не говорить, что, мол, я попробовал Codex вместо Claude или наоборот, и он умнее - всё это про устройтсво harness в "коробочном" виде - по факту сами модели +\- все умные, важна реализация harness под конкретную задачу или проект; но я не утверждаю этого наверняка, в тонкости бенчмакринга самих моделей я еще не успел погрузиться).

- За последние пару месяцев перестал писать код. Ну правда, это уже ощущается очень медленно - terragrunt-модули, gitlab-ci пайплайны, микросервисы с go+typescript - это всё тривиальные задачи, с которыми ИИ справляется очень быстро. Надо с сожалением признать, что в работе я пока действительно большую часть времени разруливаю такие тривиальные задачи - просто потому что уходит время на то, чтобы внедрить DevOps в платформенный монолит из 5+ систем, который 5+ лет до этого жил без него, на powershell-скриптах и ручных деплоях. Не буду на себя наговаривать и скажу, что нетривиальная работа там тоже есть - она как раз и заключается в многомесячной организации плавной миграции всех систем на DevOps'ный режим производства - с IaC, GitOps, GitFlow, pre-commit, 12-factor и другими баззвордами SoTA практик, всё как в лучших домах. Эта часть пока на человеке (на двух DevOps инженерах + лидах разработки), хотя не исключено, что грамотный оператор смог бы и это делегировать агентам. То есть прямо то, о чём я говорю - ИИ даёт локальную оптимизацию для задач "а давайте запилим terragrunt модуль" или "здесь надо обновить stage в пайплайне". Инженеру надо уметь управлять контекстом агента, поставить, задачу, проверить результат, верифицировать метод и бла бла бла - это без меня понятно. Оглядываясь назад, я могу сказать, что за 5 месяцев команда из двух человек с агентами смогла сделать объём работы, который без агентов пилился бы командой из 5 человек в течение года - я не шучу. Стали ли мы от этого более слабыми инженерами, построили ли колосса на глиняных ногах, заменят ли нас в ходе очередной оптимизации - честно сказать, я сомневаюсь. Но на самом деле - только время покажет.

P. S. дополняю тем, что забыл написать. В искусстве есть две разных традиции - традиция подражания и авангардизм. Весь ренессанс был построен на подражании, когда мастеру было важно уметь воспроизвести античные формы, не нарушив канона. 20ый век поставил прагматику на первое место и как бы провозгласил - назначение превыше формы (опять неясный мне дуализм). Вся книга Айн Рэнд "Источник" об этом. Так вот ИИ возвращает нас от авангарда в традицию подражания - всё творчество GenAI это подражание тому, что уже было сделано, это экстракция сжатого знания техноцивилизации. И на мой взгляд, в 95% задач это оправдано - там уже лучшее было придумано, кулибинствовать и строить велосипеды, это значит зря тратить время и вставать на грабли - такие задачи как будто не стыдно отдать на аутсорс агенту, потому что он точно справится по лучшим прикладным методам рынка. НО - чтобы узнать, что ИИ сымитировал лучшие прикладные методы, надо быть с ними знакомым - это и есть верификация метода. Нельзя проверить корректность применения GitOps, пока сам не разобрался с GitOps, если делать наоборт - это то место, когда ИИ стал протезом, а не экзоскелетом. Это первый момент - надо учить SoTA, чтобы ИИ ускорял работу. А второй момент - то, что в 5% случаев традиция подражания правда не сработает. Это когда мы работаем на фронтире. Тут вряд ли агент сможет помочь. Но в этом надо уметь убедиться - только зная SoTA, ты можешь быть уверен, что старые методы не подойдут, что надо придумать нечто новое. Так что учиться теперь надо ещё быстрее. Как-то так.

Последние несколько недель взялся за рефакторинг своей инфры в homelab (формально это и не хоумлаба вовсе, там всё в облаках - но выбрал такой канонический вариант) и GitOps-раскладкой репозитория через FluxCD. Флюкс выбрал исторически еще где-то год назад, когда впервые познавал GitOps - с ArgoCD был опыт, хотелось попробовать что-то новое, тем более Flux вроде использует cozystack, а они крутые ребята. В итоге за последний год на работе получил огромный опыт с Argo, так что возня с Flux в личной инфре очень помогает разнообразию.

Выбрал немного наркоманскую, но очень рабочую для моих кейсов раскладку (многое позаимствовал из уже существующих паттернов, конечно). 4 слоя - CRD, Infra, Config, Apps настраиваются поочередно через bundles. Кластер описывается через cluster-vars для параметризации бандлов и через сами бандлы. Подробнее внутри.

Надоело ставить flux руками через CLI. Задумался - а какой сейчас SoTA для декларативной доставки Flux в кластер? Интуитивно смотрел в сторону Terraform и не прогадал - только рекомендация ставить сразу Flux Operator, потому что просто установка Flux вела к раздвоению ownership у некоторых объектов. Почему я так смело утверждаю - вот буквально статья из блога Flux от ментейнера, датированная апрелем 2026.

Преимущества:
- TF создает NS, временный RBAC и k8s job который устанавливает оператор;
- TF plan не показывает diff без изменений модуля
- Рекомендуется использовать общий GitOps-репо, так можно instance_yaml передать локальным файлом
- В стейте не остается ни одного секрета
- Не нужен PAT и доступ контроллера в репо, он ничего не пишет; ставится из OCI через TF и потом читает состояние (если репо публичный)

Вот сам модуль, довольно свеженький, всего 15 звездочек. Забирайте себе. А вот пример d2-fleet от авторов - как управлять "флотом" кластеров через Flux Operator и "Gitless GitOps". Кстати, в репо есть контрибьюты с Claude, то есть люди свои :))

Вот так получилось поставиться у меня. Всё заехало, кластер работает.

#flux #gitops #sota #tf

Рубрика "смешной нейрослоп про k8s"

Или как идея на собесе предложить назвать как можно больше ошибок, которые могут случиться между kubectl apply и запущенным подом

В защиту LLM скажу, что я ронял продакшен ещё до появления нейронок

Сказ о луддитах, тормозящих развитие проекта external-secrets. Или пять часов работы, четыре PR и тридцать дней бана

Сразу предупрежу, что я здесь выражаюсь немного более резко, чем должен. Это мой блог, и тут я могу позволить себе авторскую риторику. В рассылке CNCF и в публичных действиях на GitHub я держусь гораздо более вежливой и уважительной семантики.

Предыстория. У меня на работе есть задача: ArgoCD управляет флотом кластеров через ServiceAccount Token. Токены эти долгоживущие, а хочется короткоживущие и с автоматической ротацией — через связку External Secrets Operator и AWS Secrets Manager. Схема такая: сгенерили токен для SA, через PushSecret опубликовали его в секретницу, на стороне ArgoCD ExternalSecret засинкал токен обратно.

При применении я нашёл и зарепортил баг 6806. PushSecret на каждой сверке дёргает DeleteResourcePolicy в AWS Secrets Manager — даже когда resourcePolicy в манифесте нет вовсе. Следствия два, и оба неприятные: право на удаление политики де-факто обязательно для всех, хотя документация обещает ровно обратное, и политика, повешенная снаружи терраформом, молча сносится посторонним PushSecret'ом. Молча — потому что удаление несуществующей политики возвращает 200. В тот же день дал в апстрим и фикс — 6807.

После чего обнаружил, что ESO не умеет генерировать ServiceAccountToken, хотя эту фичу просили ещё год назад в 5338. Просили, лайкали, но никто не дошёл до реализации — issue закрыли по неактивности автора. Без неё мне не сделать задуманное красиво, через оператор и без костылей.

Я решил посвятить этому утро субботы. Пять часов: погружение в проект, чтение кодовой базы, просмотр истории issues и PR на предмет того, к чему мантейнеры придираются чаще всего, сверка с документацией, разбирательство с обвязкой для разработки, сборка и запуск исправленной версии на локальном kind-кластере — чтобы убедиться, что генератор действительно работает, а не выглядит работающим.

Попутно нашёл и зарепортил 6810, с фиксом в 6811 — вместе с первыми в проекте тестами на этот пакет. Их собственный скаффолдер esoctl bootstrap generator печатает галочку успеха и оставляет дерево, которое не собирается. Три дефекта, два бесшумных: якоря в патчере протухли, а флаг успеха выставляется вне проверки.

Пока разбирался с фичей, увидел, что перевыпуск токена надо планировать по сроку, который вернул apiserver, а не по числу, которое написал пользователь: apiserver умеет молча урезать запрошенное время жизни. Предложил design в 6812 — и на первом же пуше словил красный CI.

Оказалось, шаблон PR предлагает тип desig(scope), а проверка принимает только design. То есть любой, кто следует шаблону для design-документа, обязан получить красный чек. Опечатку внесли 27 августа 2025 года в PR 5200 — автор Skarlso, тот самый мантейнер, который через одиннадцать месяцев меня забанит. Прожила она в шаблоне одиннадцать с половиной месяцев: за это время через него прошёл как минимум один design-документ, 5801, и всё равно никто не починил. Никто просто не смотрел — рук нет. Починил я, одним символом, в 6813. Это единственный мой PR, который влили, и влил его другой человек.

Наконец доделал работу, дописал тесты и открыл PR на сам функционал — 6814. И стал ждать, что будет.

2/3

Вообще-то я предвидел такой разворот. Когда я с Claude смотрел историю issues и PR за последние месяцы, паттерн неприязни к LLM-контрибьюциям читался невооружённым глазом. Но я тихо надеялся, что мои правки касаются реальных багов, покрыты тестами и воспроизведены на стенде — и что этого хватит. Не хватило.

В воскресенье мантейнер по имени alekc влил правку шаблона. Через сорок минут заапрувил фикс скаффолдера — и заапрувил всерьёз: откатил файл к базе, убедился, что пять новых тестов краснеют, проверил, что мой генератор json-тегов воспроизводит все семнадцать существующих, и нашёл дефект, которого не нашли ни я, ни CodeRabbit. Ничего героического — человек просто сделал свою работу и сделал её хорошо. Запомните эту планку, она обычная.

Ещё через четыре часа Skarlso закрыл этот PR. И остальные. И забанил меня на тридцать дней — «as a repeated LLM user disregarding our llm policy».

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

Сначала о том, где прав он.

В их шаблоне есть пункт: «I confirm that I understand the submitted changes and can explain them without relying on an AI tool». Я его не поставил. Не по недосмотру — я специально его не ставил, потому что это было бы враньём. Я не Go-разработчик. Я платформенный инженер, который читает Go, но не разберёт построчно диф на тридцать один файл. Код писал Claude Code. Поведение проверял я. А в политике сказано прямым текстом: «If you cannot explain the change, do not submit it».

Пустая галочка — это раскрытие, а не разрешение. Правило было написано заранее, написано ясно и применено ровно так, как написано. Я не собираюсь изображать, что меня наказали ни за что.

А теперь о том, что это за правило.

Оно требует, чтобы человек мог объяснить каждую строчку без инструмента. Не «отвечает за результат». Не «проверил, что работает». Не «доказал поведение». Именно — объясни код без ИИ.

Это правило из мира, которого больше нет.

Оно описывает единственный способ принести пользу проекту: две недели вчитываться в чужую кодовую базу, потом руками написать фикс. Такой способ существует, он хороший, я его уважаю. Но он больше не единственный, и притворяться, что единственный, — значит набирать себе контрибьюторов из тех, у кого есть две свободные недели. Их мало. Их с каждым годом меньше. И именно поэтому у проекта не хватает рук.

Год назад мантейнеры этого проекта опубликовали issue «Health of External Secrets project» — публичное признание, что рук нет и людей жжёт. Откликнулось больше трёхсот человек. В ответ построили лестницу контрибьютора: Contributor → Member → Reviewer → Maintainer, треки, интерим-роли, приглашение самономинироваться. И написали там фразу, которая у меня застряла: «not everyone can contribute code, but many still want to help».

А в их чеклисте готовности к инкубации CNCF до сих пор стоит неотмеченным пункт: «Track Record of contributor ladder being actively used».

То есть: рук не хватает, лестница построена, лестницей никто не пользуется. И когда по ней приходит человек — его отсекает пункт, измеряющий не то, что он принёс, а то, каким инструментом он это сделал.

3/3

Вот это я и называю луддизмом.

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

Луддит не глуп и не зол. Луддит уставший. Он выгорел на потоке, который вырос, а сам под этот поток не вырос, и вместо того чтобы масштабироваться — поставил на входе ворота с вопросом «а ты точно писал это сам?». Ворота дают немедленное облегчение и не решают ничего: поток не уменьшится, а те, кто мог бы разгрузить, уйдут.

И ждут при этом чуда. Что в 2026 году кто-то отложит рабочую неделю, чтобы въехать в чужой оператор на Go, и пришлёт фикс, написанный целиком руками, без единой подсказки машины. Не пришлёт. Такой человек либо уже мантейнер, либо ему за это платят зарплату.

Мне легко было бы написать, что человек просто испугался: кто-то за пять часов сделал то, на что по его меркам нужен месяц. Но я не умею читать мысли и не буду этим заниматься — приписать мотив это самый слабый ход из возможных и единственный, который потом процитируют против меня. Поэтому только то, что видно снаружи. Патч с апрувом второго мантейнера закрыли, не упомянув этот апрув ни словом. Патч по AWS закрыли, ни разу на него не взглянув: за всю его жизнь там нет ни одного человеческого ревью, ни одного комментария. Баги, которые эти патчи чинят, остались открытыми. Опечатку, которую я починил, он же сам когда-то и внёс. В этот момент никто не смотрел на код — смотрели на то, чем он написан. Этого достаточно, мотивы можно не додумывать.

Мне и не нужно, чтобы мне поверили на слово. Мне нужно, чтобы посмотрели на диф. Проверить фикс дешевле, чем допрашивать автора о его инструментах: откатил файл, прогнал тесты, посмотрел, краснеют ли. Ровно это сделал alekc за сорок минут — и нашёл в моём патче дефект, который я пропустил. Вот как это работает. Вот что масштабируется.

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

И вот что добивает. У проекта тридцать шесть открытых багов, самому старому — с сентября прошлого года. Готовность к инкубации CNCF висит незакрытой с августа 2025-го, её два раза за год спасали от стейл-бота словами «не устарело, скоро займусь». Мантейнеры сами написали, что выгорают и что рук не хватает. А человек, пришедший с патчами, получает тридцать дней бана и напутствие: «use this time to refine your skills in communication and community engagement».

Про коммуникацию — отдельно. За всё время моего контакта с проектом мантейнеры не написали мне ни одного слова. Ни на issue, ни на PR, ни в ответ на прямой вопрос «вы вообще берёте такие генераторы от внешних контрибьюторов, или мне не тратить время?» — который я задал до того, как написал хоть строчку кода. Единственная человеческая реплика в мой адрес за всю историю — это текст бана. Время закрыть четыре PR и написать про бан нашлось. Ни одного слова про сам код — нет.

Учиться выстраивать коммуникацию мне посоветовали ровно те, кто не сказал мне ни слова. Это уже ни в какие ворота.

Что в сухом остатке.

Оба бага живы. Issue 6806 и 6810 открыты до сих пор — дефекты признаны, исправления закрыты. Фикс скаффолдера, одобренный с независимой перепроверкой, закрыт через четыре часа после апрува. Фикс по AWS закрыт вообще без единого человеческого ревью.

Всё подписано под DCO и принадлежит им. Могут взять, переписать, отдать кому угодно, снять моё имя. Мне важнее, чтобы починили.

Я написал на список рассылки мантейнеров проекта в CNCF — cncf-ExternalSecretsOp-maintainers@lists.cncf.io — с апелляцией и с этим самым вопросом: куда лестница ставит эксплуатанта, который умеет доказать поведение и не умеет написать идиоматичный Go. Напишу, чем кончится.