=^._.^=

We built a courtroom where every claim needed a receipt, then realized we’d been testifying from memory

—

Когда-либо в этом промежутке времени я его закончу

change is fine; unjustified change is not

Ну и на правах рекламы собственного дурдома.

У меня есть side-проект: slop-комикс про SOL & LIS.

Кошкодевочки, бытовуха, IT, мемы, немного лора и периодические последствия слишком долгой работы с LLM.

Короче, всё то, чему в основном канале места уже как будто маловато :D

→ SOL & LIS

Наверное, многим очевидное, но приходит со временем:

тесты тоже очень легко написать так, чтобы они подтверждали твою собственную ошибку.

Ты уже знаешь, как система «должна» работать.

Пишешь код из этой модели.
Потом из этой же модели пишешь тест.

Создаёшь нужное состояние. Делаешь нужные шаги. Проверяешь ожидаемый результат.

Зелёное.

Ну охуенно :D

Только иногда это не два независимых доказательства.

Это две реализации одной и той же мысли, которые согласились друг с другом.

И чем дольше ковыряю распределённые системы, тем больше мне это не нравится.

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

Причём тест не врёт.

Он честно проверяет ровно тот мир, который ты ему построил.

Проблема в том, что этот мир придумал тоже ты.

Поэтому мне сейчас гораздо интереснее не «какие ещё тесты написать», а как заставить тесты спорить с моей моделью системы.

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

Убрать кусок механизма.
Потерять ответ.
Повторить одно действие несколько раз.
Поменять порядок событий.
Оставить систему надолго вообще без изменений.

И посмотреть, где мои красивые «значит» перестают быть правдой.

Наверное, отсюда у меня постепенно появился довольно простой критерий:

зелёный тест говорит, что система прошла придуманный тобой сценарий.

А хороший тест ещё должен ответить на более неприятный вопрос:

что именно должно сломаться, чтобы он перестал быть зелёным?

Если ответ — «ну, примерно то, что я уже предусмотрел», то, возможно, мы всё ещё тестируем собственную уверенность.

Немного оффтопа и щитпоста.
Я наконец сменил свой стиль ❕

До и после

Не каждый байт должен спрашивать разрешения.

Я тут поймал себя на забавной мысли. Раньше на архитектурное «а вдруг?» мне хотелось ответить ещё одним механизмом контроля.

Заранее выделить. Зарезервировать. Согласовать. Проверить, что все согласились. На случай, если не согласились, тоже что-нибудь построить.

И в какой-то момент пользователь просто хочет сохранить файл, а у меня для этого должно состояться заседание распределённого правительства.

Ну охуеть. Зато архитектура строгая :D

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

И вот от этого желания держать за горло каждый переход состояния я постепенно отхожу.

Мне всё ближе lazy-подход: делать работу тогда, когда она действительно нужна. Не поднимать полмира ради возможности когда-нибудь им воспользоваться. Не заставлять обычное действие проходить через всю систему только потому, что нам так удобнее поддерживать красивую модель.

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

И нет, я не пришёл к «да похуй, потом починим». Потерянные данные, двойные списания и дырявая изоляция от слова lazy приемлемыми не становятся.

Просто теперь мне мало объяснения, зачем нужен очередной предохранитель. Я ещё хочу понимать, сколько новых способов сломаться он принёс с собой. Что будет без него. И действительно ли мы защищаем важный инвариант, а не моё архитектурное чувство прекрасного.

Я не стал меньше требовать от системы. Я стал больше требовать от каждого усложнения.

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

UNKNOWN — это не дефект state machine. Дефект начинается, когда система обязана выбрать состояние, для которого у неё нет evidence.

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

Мой личный top tier когнитивных навыков LLM на данный момент:

1. ox-alpha
2. ChatGPT 5.6 Sol, Claude Fable 5
3. GLM 5.3, Grok 4.6, Claude Opus 5
4. Kimi K3
5. DeepSeek V4 Pro, Qwen3.8

Все учитывается только с самыми высокими настройками ризонинга на чистом system prompt без harnesses.

Честно скажу, что ox-alpha сейчас идет даже выше Fable и Sol на когнитивных тестах

ox-alpha не перестаёт приятно удивлять.

Она почти прошла мой когнитивный тест, который пока нормально не прошла ни одна из моделей.

Конкретно основной фактор: ложная premise пользователя не становится фактом только потому, что она написана в задании.

А ещё на adversarial review системного дизайна она оказалась одной из сильнейших: не пыталась любой ценой «найти баг», сама ломала собственные findings и понижала их до OPEN DESIGN / NOT ENOUGH EVIDENCE, когда доказательств не хватало.

Вот это уже гораздо интереснее очередного +5% на бенчмарке.

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

Сильный coding agent не спасает от слабой инженерии. Он делает её масштабируемой.

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

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

Поэтому агентная разработка начинается не с промпта и не с тестов. Она начинается с системного дизайна: кто владеет фактом, где находится durable truth, что происходит при timeout, какой эффект нельзя повторить и какой судья обязан покраснеть при нарушении этого закона.

Надеюсь, вводную я более-менее дал.

Курс/репозиторий готовлю.

Основная мысль там будет простая:

Не учить Terraform, Kubernetes, Flux или Ansible. Учиться понимать, какую именно проблему ты решаешь, на каком слое она находится и какую абстракцию на неё стоит надеть.

Сначала увидеть машину, процесс, сеть, диск и состояние.

Потом уже сделать так, чтобы тебе больше не приходилось ходить и трогать их руками.

Вот это, собственно, и есть переход от «администрирования серверов» к современной инфраструктуре.

Я, кстати, уже давно почти не хожу по SSH. И Ansible в своей текущей инфраструктуре тоже практически не использую.

Просто в какой-то момент я окончательно уехал в облака.

Промежуточным этапом были gold images для Kubernetes-нод.

Да, буквально образ VM можно собрать кодом. Описать, какие пакеты там должны быть, какой runtime, kubelet, sysctl, сертификаты, агенты — собрать образ пайплайном и хранить всю его историю в Git.

Не «вот та VM, которую Вася настроил два года назад и лучше её не трогать».

А артефакт.

Сломалась нода — выкинул. Из того же описания приехала новая.

Но сейчас у меня цепочка стала ещё короче.

Мне не надо сначала заказать VM, потом зайти туда, что-то настроить, потом раскатить Kubernetes, потом идти разворачивать приложение.

Я пишу в репозиторий инфраструктуры примерно следующее:

> хочу PostgreSQL-кластер, три реплики, вот столько CPU, вот столько памяти, вот такие диски.

git commit && git push.

Дальше я уже почти зритель.

GitOps-контроллер увидел изменение и начал сходиться к нему.

Не хватает capacity — Karpenter поднимает дополнительные ноды.

Нужен диск — CSI запросил volume.

Облако его создало, Cinder приаттачил к нужной ноде.

Оператор PostgreSQL поднял кластер, собрал кворум, настроил репликацию.

Через какое-то время у меня просто есть работающий PostgreSQL внутри Kubernetes.

Я даже не думал, на какой конкретно машине он должен жить.

И вот это, наверное, главное изменение.

Раньше значительная часть работы была про:

«куда поставить?»
«на какую VM зайти?»
«что там уже установлено?»
«а можно её перезагрузить?»
«а кто вообще знает пароль?»

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

Не потому что железо исчезло.

Просто мне больше не надо каждый раз заниматься им лично.

Время сейчас такое.

От идеи до деплоя заказчик даёт ровно день.

И тот был вчера.

И маленькое уточнение, а то может показаться, что я выше описал какой-то «правильный стек».

Terraform, Ansible, Flux и GitLab CI — не единственные варианты. Это вообще инструменты разных классов, и я бы сначала делил задачи, а уже потом выбирал, чем их решать.

Условно:

Provisioning инфраструктуры — Terraform, OpenTofu, Pulumi и т.д.
Их задача — получить VM, сеть, диски, балансировщики и прочие ресурсы.

Configuration management — Ansible, Salt, Puppet, Chef.
Тут уже ОС, пакеты, пользователи, файлы, systemd и всё, что находится внутри машины.

CI — GitLab CI, GitHub Actions, Jenkins и куча других вариантов.
Собрать, проверить, протестировать, упаковать изменение.

GitOps / CD для Kubernetes — Flux, Argo CD.
И вот это уже тот слой, который смотрит на состояние в Git и приводит кластер к нему.

То есть названия можно заменить почти в каждой строке. Я просто взял то, с чем хорошо знаком и работаю.

Причём Flux я сам использую в основном в пэтах и небольших контурах. В проде у меня Argo CD.

Не потому что Flux «хуже». Просто мне нет смысла тащить Argo туда, где Flux решает задачу несколькими CRD и почти не требует внимания. И наоборот — когда кластеров, приложений, команд, политик и зависимостей становится много, мне удобнее уже Argo.

Собственно, в этом и ещё одна мысль всего репозитория.

Не надо учить Terraform + Ansible + Flux + GitLab как связку.

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

А конкретный продукт выбирается уже после.

Иначе очень быстро получается Kubernetes ради Kubernetes, Argo ради Argo и двадцать операторов ради красивой схемы в README.

IaC начинается с VM, которую страшно удалить

Крч, самый честный тест на IaC: можно ли удалить VM и получить её заново.

Не данные, понятно. Саму машину и всё, что делает её рабочей.

Если нельзя, значит к ней уже всё прибито: IP, пакеты, /etc, cron, сертификаты, ручные исключения и знания человека, который «помнит, почему тут так». Формально это виртуалка. Фактически — единственный экземпляр самой себя.

Каждый ручной фикс, который не вернулся в код, — ещё один гвоздь.

Terraform, Ansible, Kubernetes и Flux нужны не потому, что YAML чем-то благороднее SSH. Они вытаскивают разные гвозди.

Terraform делает VM, сеть и диски результатом описания, а не похода по панели.

Ansible делает пакеты, пользователей, сервисы и конфиги результатом playbook, а не истории команд в shell.

Kubernetes переносит управление с конкретной машины на workload и постоянно сводит факт к желаемому состоянию.

Flux берёт это состояние из Git и продолжает сверять с ним кластер.

GitLab CI проверяет и собирает изменение. Если pipeline один раз сделал kubectl apply и ушёл — это доставка. В GitOps-контуре кластер забирает изменение сам и не перестаёт его сверять.

Собираю небольшой учебный репозиторий, где этот переход будет виден целиком: Proxmox → Terraform → Ansible → Kubernetes → Flux, плюс GitLab CI.

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

Не ещё один склад манифестов. Хочу сделать переводчик из мира «зайди на сервер и поправь» в мир, где машину можно выбросить, а знание о системе останется.

Репозиторий ещё собираю.

Прошу подписать крайне важную петицию