Make. Build. Break. Reflect.

#ai #claude #размышления

Инженеры всего мира десятилетиями бились над величайшей архитектурой в истории.
Лучшие умы планеты сожгли себе жизнь, глаза и нервы, чтобы родить M5: процессор, который, кажется, считает быстрее, чем я успеваю передумать.
Немыслимые объёмы оперативки, в которые раньше влезала бы вся инфраструктура небольшой компании.
Идеальные экраны: 4K, 120 герц, цветопередача такая, что закатное небо на обоях выглядит живее, чем за окном....
....и вот всё это великолепие, весь этот труд человечества, нужно мне ровно для одного.

Чтобы запустить десяток агентов на чёрном экране терминала 😬.

С полным управлением через консоль, цветопередачей на гордые 16 цветов, где вся анимация это псевдографика и крутящийся писюн |/-\ в углу.
Топовое железо планеты гоняет писюны-ASCII-спиннеры, спасибо, инженеры, вы старались не зря😬.

- - -
Ладно, это всё хихоньки да хахоньки.

А если серьёзно, то по будням по вечерам вместо отдыха и игор я в последнее время сидел и разбирался со всеми свежими фичами Claude Code.

Сначала полез в официальные доки.
И каждый раз ловлю одно и то же ощущение: что-то новое там появляется буквально каждый день, сука.
То, что месяц-два назад было опенсорсом с 34к звёзд или хаком из чьего-то твита или постом в телеге, сегодня уже встроенная фича с отдельной страницей в документации.
Клодкод своими фичами нехило так убивает целые сотни и тысячи опенсорс проектов и именитые платные SaaS продукты.
Скиллы, хуки, сабагенты, малтиэйдженси, чекпойнты, саббраузеры e2e, headless-режим для CI - читаешь и понимаешь, что половину ты или пропустил, или не успел, или просто не знал, что оно так умеет.🚬

Потом пошёл по сторонним ресурсам.
- https://github.com/luongnv89/claude-howto
- https://github.com/hesreallyhim/awesome-claude-code

❗️Половина там уже чертовски устарела, так что имеет смысл читать это только если у вас, как у меня, есть какой-никакой опыт, но чего-то пропустили. Депрекейтед вещи будут видны сразу, пропускайте. Как быть тем, у кого опыта не - не знаю 😬 ❗️

Из нового, что понравилось, попробовал cmux - нативный терминал, заточенный прямо под мультиагентные воркфлоу: вертикальные табы, кольца-нотификации, когда агент ждёт ответа, встроенный браузер (вырубил сразу, лол).
Макоёбы онли.
- https://cmux.com/
"зумеры открыли для себя tmux" (с) загиенили где-то вдалеке пользователи tmux

Пока этой мой основной сетап: cmux + claude cli +MCP + linux cli tools + куча плагинов и экстеншнов + omyzsh и его плагины.

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

И вот тут начинается часть менее весёлая.🚬
На работе я откровенно не успеваю за коллегами.
Все так быстро и так глубоко влетают во всё это ИИ-добро, что я на их фоне ощущаю себя каким-то слоупоком из мезозоя🦍.
Люди идут семимильными шагами, а ты вроде и бежишь, и читаешь по вечерам, и пробуешь, а всё равно отстаёшь. Догоняющий по жизни.

Ещё и отставший и уставший от этих агентов.
Интересно, придумали ли в твиттерах или на IT конференциях новые термины типа agent fatigue как это было с алёртами? 🤔

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

Но я рад одному: что мои мозги пока ещё работают, что мне всё ещё любопытно ковыряться в новом по вечерам, и что деменции пока нет)

#бытовое #ai #пятница

В эпоху ИИстерии, агентов и "умных" ассистентов.

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

Пройти весь этот проклятый путь: от "опишите вашу проблему" до "я вас не понимаю, попробуйте переформулировать".
Через бесконечные кнопки - к магическому "мы передали ваш запрос команде" (bruh, нет, конечно же).
И особенно прекрасно будет, если в какой-то момент не сработает фича "позвать человека".
Побудьте с этим, поговорите со своим конченым ИИ, доверьтесь ему - он же у вас умный, правда?
Может, тогда внезапно окажется, что "AI-powered support!!11!" - это не совсем про помощь, а про аккуратное высоко интеллектуальное автоматизированное игнорирование клиентов.

- - -
Саппорт у Claude Code наглухо отбитый: решить что-либо невозможно, на почту не отвечают. Чат-ассистент уже создал 11 заявок - все без ответа три недели.
Три недели, господа. В 2026 году.
Ну а что - нищеброду можно и не отвечать, не корпорат же, всего-то платит 200 баксов в месяц. 🚬

#mcp #ai #devops #troubleshooting

Погулил что за буква t.
Буква t это free-threaded сборка, тот же Python, но без GIL. У неё другой ABI, cp314t. И колёс под cp314t у grpcio нет ни одного. Поэтому uv честно говорит, что готового бинаря под мой экзотический питон не завезли, и идёт собирать из исходников. На всех ядрах. Дважды.

Самое обидное: будь у меня обычный 3.14, взялось бы готовое колесо cp314 и ничего бы не грелось. Меня наказала именно free-threaded сборка, которую я когда-то поставил глобально. Когда и зачем именно её, я вспомнил не сразу, но к этому вернёмся в самом конце.

Лечение. Снёс нагрузку через pkill по билд-процессам, CPU сразу в ноль. Дальше, чтобы не повторялось, пинаю opensearch нормальный, не-free-threaded питон прямо в ~/.cursor/mcp.json:

"opensearch-homelab": {
  "command": "uvx",
  "args": [
    "--python", "3.13",
    "opensearch-mcp-server-py"
  ],
  ...
}

Проверяем, что под 3.13 всё ставится из готовых колёс:

uvx --python 3.13 --from opensearch-mcp-server-py python -c "import grpc; print(grpc.version)"
 Downloaded grpcio
Installed 61 packages in 107ms
grpc 1.81.0 on 3.13.12

107 миллисекунд вместо двадцати минут компиляции. Ни одного clang.
Вот и вся разница между есть колесо под твой ABI и нет колеса под твой ABI.

Маленькая засада на сладкое. После того как я убил билд, курсор его тут же воскресил, но по старому конфигу, потому что новый mcp.json он ещё не перечитал. И я снова увидел компиляцию под 3.14t. Лечится тривиально: выключить-включить MCP-серверы в настройках Cursor или рестартнуть его, чтобы он подхватил python 3.13. После этого opensearch стартует на 3.13 мгновенно, кэш уже тёплый.

Первый подозреваемый, тот, что висит живым и на виду, почти никогда не виновник. mcp-grafana чуть не сел за чужое. Обнуляй факты и иди по цепочке зависимостей до конца.

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

Экзотика в окружении, free-threaded питон глобально, аукается там, где не ждёшь. ABI cp314t это не cp314, и весь мир пакетов, у которых нет колёс под no-GIL, начинает собираться из сорцов прямо у тебя на коленке.

Проблема найдена, объяснена на 100%, пофикшена и закрыта. Кулеры выдохнули.

Но остаётся ворпос: а откуда вообще взялся питон с буквой t.

Раз уж вся боль из-за free-threaded сборки, логичный вопрос: кто и когда вхерачил её мне глобально.
Тут я снова не стал гадать, а пошёл по следам в файловой системе и в истории шелла.

Дата рождения каталога сборки в asdf:

stat -f '%SB' ~/.asdf/installs/python/3.14.3t
Mar 17 20:56:52 2026

То есть поставлено 17 марта 2026, вечером. А кто. Да я же сам, руками, в своём терминале. Вот честный след из ~/.zsh_history того же вечера:

asdf plugin add python
asdf install python latest
asdf global python latest
asdf set -u python 3.14.3t

Последовательность красивая: добавил плагин, поставил latest, а потом отдельной командой явно прибил глобально именно 3.14.3t. Буква t стоит прямо в команде, то есть это был осознанный выбор конкретной no-GIL сборки, а не случайный дефолт. И в asdf с тех пор так и живёт ровно одна версия питона, вот эта.
Почему? Да хер его знает, не удивлюсь, если это агент ставил, а я тупо копипастил.🦍

- - -

Так что же там у нас с бобиной?
А, ну да, там же есть полное продолжение.

Мы сидели и вникали,
Разбирали, собирали,
Замеряли, вычисляли,
Днями, сутками, ночами.
Умножали и делили,
Выбирали "или-или",
Но машина всё ж не едет.
Что за козни? Что за бредни?
Мы по новой за расчёты:
Может, там у нас просчёты,
Может, что-то упустили,
Не нашли, не уследили...
Вдруг не то мы вычисляли
Днями, сутками, ночами.
Но машина вновь не едет,
Инженер наш главный бредит.
Снова мы на путь тернистый
Должен быть расчёт уж чистый.
Умножаем, вычисляем,
алгоритмы составляем.
Только было всё напрасно
Лишь потом нам стало ясно:
Дело было не в бобине
Долбоёб сидел в кабине.

#mcp #ai #devops #troubleshooting


Есть такое устойчивое выражение

"дело было не в бобине"

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

- - -
Сидел вечером, ковырял документацию, чтобы догнать коллег по знаниям AI.
А то стал сильно отставать от них.
Курсор предлагает обновится, я соглашаюсь - ну а чо, вечер, казалось бы, что я могу поломать?
Он обновляется и тут ноут включает режим вертолёта: кулеры на взлёт, корпус тёплый, курсор дёргается.
M5, прости господи, топовое железо планеты, а ведёт себя так, будто я ему майнинг ферму на коленке запустил.

Ну, лезу в htop руками: кто это мне нагружает цпу сейчас.

clang processes: 73, summed %CPU: 778.3

(кто такие кланг? я вообще не в курсе)

Семьдесят три процесса clang и почти 800% CPU. То есть кто-то прямо сейчас яростно компилирует C++ всеми ядрами сразу. На моей машине. Которую я не просил ничего компилировать.

Дальше по дереву процессов:

launchd
└─ Cursor.app                         (старт 10:02)
   └─ Cursor Helper (Plugin): extension-host
      └─ uv tool uvx ...

Стартануло всё ровно в момент, когда я обновил Курсор.
Не понимаю какого хера вообще апдейт пошёл. Гуглю, читаю, теперь понятно.
Логично: апдейт, рестарт приложения, extension-host поднимает заново все включённые MCP-серверы.
А у меня их там зоопарк. Старые и новые, часть включённые, часть выключены.

Гипотеза номер один, неправильная.
Живым uvx в этот момент висел mcp-grafana, и палец сам потянулся к нему: вот же, Grafana MCP компилирует свои зависимости. Звучит правдоподобно.

Но привычка копать сработала. Проверяем зависимости пакета:

jq -r '.info.requires_dist' mcp-grafana.json
null

null. То есть у mcp-grafana вообще нет Python-зависимостей. Это сраный го-бинарь, завёрнутый в пип-пакет.
Ему компилировать нечего в принципе. Ну или я чего-то не знаю.
То есть я чуть не повесил вину на невиновного только потому, что он первым попался на глаза.
Обнуляю факты, копаю заново.

И вот тут честно: пока копал, гипотез было заметно больше, чем одна про grafana.
Большую часть я тут не расписываю, потому что они оказались пустышками и только сжирали время.
Просто список того, куда я успел сходить и что отмёл:
- какой-нибудь мой же зависший скрипт или забытый дев-сервер
- фоновая индексация и демоны самого курсор
- сраный докер-полупокер
- прилетевший с апдейтом фоновый апдейтер и его пост-инстал хук
- что это что-то из самого репозитория, terraform, pre-commit и компания
- майнер или малварь, ну а вдруг, паранойя должна быть здоровой

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

Что компилировалось на самом деле. Смотрим, какой исходник жуёт clang, чем бы это не было:

src/core/filter/fused_filters.cc
src/core/xds/grpc/xds_http_rbac_filter.cc
...
-DGRPC_PYTHON_BUILD=1
.../sdists-v9/pypi/grpcio/1.81.0/...
-I/Users/alexk/.asdf/installs/python/3.14.3t/include/python3.14t

Это grpcio. Из исходников, uv скачал sdist, а не колесо.
Под python3.14t. Сотни C/C++ файлов gRPC, вот откуда 70-110 процессов компилятора.

А кто его притащил. mcp-grafana мы исключили. Остаётся второй uvx-сервер в конфиге, opensearch-mcp-server-py. И вот тут вторая засада: прямой зависимости на grpcio у него тоже нет. Цепочка оказалась транзитивной, в три прыжка:

opensearch-mcp-server-py
  └─ opensearch-py==3.1.0
       └─ opensearch-protobufs==0.19.0
            └─ grpcio>=1.68.1      → 1.81.0

То есть свежий opensearch-py подтянул новый gRPC-транспорт (opensearch-protobufs), а тот тянет grpcio. И всё это в двух экземплярах сразу, потому что в конфиге у меня два opensearch-сервера: homelab и login.linode.com. Два параллельных билда grpcio. Привет, кулеры.

Почему из исходников, а не готовое колесо(wheel). Вот ключевой нюанс, ради которого вся стори. Смотрим, какие колёса есть у grpcio 1.81.0 под Python 3.14:

grpcio-1.81.0-cp314-cp314-macosx_11_0_universal2.whl
grpcio-1.81.0-cp314-cp314-manylinux2014_aarch64.whl
...

Колёса под cp314 есть. Но все они cp314-cp314.
А у меня глобальный питон через asdf вот такой:

cat ~/.tool-versions
...
python 3.14.3t

Да сука, откуда.

#пятница #aws #azure

Неплохо бизнес день в штатах начинается.😬

AWS:
- We are investigating increased 503 service unavailable errors for some Claude models in the us-east-1 Region.

Azure:
- App Service, Azure Functions, Azure Virtual Machines, Azure Virtual Machine Scale Sets, Azure Backup, Azure Container Registry, Azure Cosmos DB, Azure Database for MySQL flexible servers, Azure Database PostgreSQL Flexible Server, Azure IoT Hub, Azure Kubernetes Service (AKS), Azure Monitor, Application Insights, Log Analytics, Azure NetApp Files, Azure Site Recovery, Azure Synapse Analytics, Microsoft Defender for Cloud, Azure Databricks and Azure Storage, Redis, Azure SQL, Azure Managed Grafana

- https://health.aws.amazon.com/health/status
- https://azure.status.microsoft/en-us/status

#всратость

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

Теряюсь в догадках, что это вообще такое:
- это какая-то шутка?
- пост-ирония, а я, словно дед, не выкупаю?
- ЛЛМ‑галлюцинации и ИИстерический щитпостинг не глядя?
- авторы реально в это верят и так мыслят?!
- заболевание Баззвордзянка после долгого вайб-кодинга?

Не знаю. Пока всё подобное выглядит как:

Запомни эти две линупс команды, выучи 41 баззворд, повторяй словно какаду как мантру каждый день - и ты уже девопёс‑синёр!!1!
😲😮👩‍💻👩‍💻👩‍💻😮😮

🤨

Шедевральные творения во вложении.

#всратость

Маленькая инди-компания опять не смогла.

Google Chrome + Google AntiGravity website+ Google Translate browser plugin.

Насчёт AI не подскажу, но, вероятно, без него не обошлось.

- https://antigravity.google/
- https://antigravity.google/download

Господи, какой же это пздц 🚶‍♀.

#пятница

Хочу иметь такие же стальные яйца уверенности, как у Леди Гаги, пришедшей на репетицию легендарной Metallica в максимально удобном ей наряде.
- https://youtu.be/jLZ2P_QiLZo?si=njfREiqlO6fIvcd-&t=139

Хочу обладать той же непоколебимой самоуверенностью, что и Slack - с десятками инцидентов в год и при этом с гордым 100% uptime на статус-пейдже. 😎
- https://slack-status.com/
- https://slack-status.com/calendar

И, наконец, хочу прокачать до максимума талант наглости и оптимизма - чтобы в CV спокойно писать в разделе сертификатов: дату Planned.
- https://t.me/sysadminka/339409

#troubleshooting #terragrunt #devops #всратость

Очередная всратая история про Tailscale.

Была задача: заменить один легаси Tailscale узел нормальной HA парой.
Два EC2 в Auto Scaling Group, два AZ, автоматическая ротация auth-key через Lambda + Vault.
Красиво, надёжно, как в книжках и доке написано.

Задеплоили, новые ноды поднялись, анонсируют маршруты, всё выглядит отлично.
Убрали легаси (просто потушили).

Через некоторое время в слаке:
- "а почему внутренний адрес ArgoCD отдаёт 403? э!"

Начинаем смотреть чо там: ДНС не резолвит внутренние имена, весь туннель работает, TCP через /16 ходит нормально, но стоит обратиться по FQDN к любому внутреннему сервису - тишина.

dig +short internal-service.company.example.com
;; connection timed out; no servers could be reached

Ну окей, DNS сломался, а почему.

В AWS VPC есть такая штука - AmazonProvidedDNS. Это встроенный резолвер, который живёт по адресу <CIDR_VPC_BASE>+2.
Если мой VPC это 10.72.0.0/20, то резолвер сидит на 10.72.0.2.
Через него работает сплит-днс: внутренние имена идут в приватные Route53 зоны, всё остальное - наружу.

Чтобы это работало через Tailscale-туннель, клиенты должны уметь достучаться до 10.72.0.2.

Легаси-нода анонсировала два маршрута: 10.72.0.0/16 (широкая подсеть) и 10.72.0.2/32 (конкретно этот адрес резолвера).
Новые ноды анонсировали только один маршрут 10.72.0.0/16.

Как оказалось (спасибо нейронкам, документации и коллегам) tailscale работает по принципу Longest Prefix Match (LPM): при выборе маршрута побеждает самый специфичный:
- запрос к 10.72.0.2 шёл через легаси, потому что у неё был /32 - он длиннее /16.
А потом легаси потушили. И tailscale не переключился на /16 новых нод.

Это не баг, кстати, а документированное поведение, написанное прямо в KB-1019:

"Tailscale does not fall back to a less-specific route when the subnet router for a more-specific route goes offline.
Tailscale drops traffic to 10.0.0.1 rather than falling back to subnet router A's 10.0.0.0/16 route."

Я, конечно, как и коллеги, прочитали это уже после. Ну всё как обычно.

Для работы HA failover у tailscale вообще требуется, чтобы обе ноды анонсировали идентичные префиксы - широкий /16 не является фолбэком для /32 - это просто другой маршрут.

Итого: DNS-резолвер 10.72.0.2 видел только легаси через /32, новые ноды с 10.72.0.0/16 для tailscale были вообще не кандидатами на трафик к этому конкретному адресу. Убрали легаси - адрес пропал из таблицы маршрутов. DNS умер и всё, издец.

TCP до других адресов в 10.72/16 работало нормально - там /32-специфики не было, оба маршрута от новых нод были равнозначными, failover сработал.

Фикс простой: каждая нода должна явно анонсировать <VPC_CIDR_BASE>+2/32.

В terra модуле добавили вычисление адреса резолвера через cidrhost(var.vpc_cidr, 2) и автоматически подклеиваем его как /32 к списку advertised_routes.
Плюс в tailscale ACL нужна отдельная запись в autoApprovers.routes под этот /32 - общий /16 его не покрывает, там тоже exact match 😬.

locals {
  vpc_dns_resolver  = cidrhost(var.vpc_cidr, 2)
  advertised_routes = distinct(
    concat(var.advertised_routes, ["${local.vpc_dns_resolver}/32"])
  )
}

Теперь при любой замене ноды все HA-пиры анонсируют и /16, и /32 резолвера - файловер работает корректно, ДНС не падает.

Мораль тут банальная, но всё равно немного обидная: читай документацию до деплоя, а не после инцидента.

Мы предполагали, что Tailscale при отсутствии /32 анонсера переключится на покрывающий /16.
Вроде логично же - подсеть включает адрес, значит маршрут есть, но у tailscale другая логика: /32 и /16 - это разные маршруты, не уточнение одного другим, фоллбек намеренно не делается, потому что иначе можно случайно отправить трафик не туда.

Один 32-битный префикс, пропущенный при проектировании нового модуля - и несколько часов дебага всей командой*.

* я только коммиты смотрел, читал доки тейлскейла, AWS по VPC и слушал на митосе как ребята траблшутят.

- - -
В следующий раз, когда мне захочется поныть про "тупые" вопросы о сетях и подсетях на собесе, просто вспомню, как один /32 положил нам DNS 😬

Года два-три думал об этом, мечтал, планировал, читал и смотрел обзоры, хотел - и наконец-то "созрел".
Накопил денег и, пока не видит супруга, заказал себе новую для меня ортолинейную клавиатуру Voyager и не менее свежий для мира тачпад Navigator под правую кисть.

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

С нетерпением жду, когда наконец окунусь в мир раздельной клавиатуры и по‑настоящему комфортной печати (надеюсь). Ну и мучений конечно же.

Не ожидаю разочарования, потому что кисти рук очень болят, я устал, правда, и я хочу попробовать что-то новое.
Вдруг это поможет.

#kubernetes #kubelet #devops #observability

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

Свежая статья от LearnKube про то, откуда на самом деле берутся метрики в Kubernetes
- https://learnkube.com/kubernetes-metrics-cadvisor-kubelet-cri 🔥🔥🔥

По мне так прям годная разборка пайплайна метрик кубера: kubelet > cAdvisor > CRI.
Не маркетинговая жыжа инфоцыган, а прям пошагово на minikube с containerd, с командами, выводами, /sys/fs/cgroup/ наизнанку.

О чём в двух словах:
- как кублет на старте решает, cgroup v1 или v2 у ноды, и какой cgroup driver брать (systemd vs cgroupfs)
- как QoS класс пода (Guaranteed/Burstable/BestEffort) определяет, в какой слайс он улетит. С трейсом от UID пода в API до .scope юнита на диске
- что такое пауз-контейнер и почему у тебя у каждого пода два скоуп юнита, даже если контейнер один
- четыре эндпоинта кублета и чем они отличаются, типа:
- - /metrics/cadvisor - контейнерные метрики в прометей формате от cAdvisor
- - /stats/summary - JSON по нодам/подам/контейнерам/волюмам
- - /metrics/resource - лёгкие cpu/memory, на это сейчас смотрит metrics-server 0.6+
- - /metrics - внутренняя кухня самого кублета (kubelet_runtime_operations_duration_seconds и тд)
- зачем ваще сделали фичу PodAndContainerStatsFromCRI - чтобы кублет тащил статы пода/контейнера прямо из рантайма через gRPC, а не гонял cAdvisor по cgroup-фс второй раз
- что произойдёт с твоим /metrics/cadvisor если её включить (спойлер: пздц контейнерные метрики оттуда исчезнут, останется только machine-level)
- про KubeletCgroupDriverFromCRI (я честно скипнул, пипец нудятина про рантайм драйвера)

Кому полезно:
- SRE/DevOps/SysAdmin, кто прометиусом/викторииметрикс скрейпит /metrics/cadvisor и думает, что всё ок навсегда. Включат гейт, обнаружат пропавшие метрики и сюрприз-сюрприз 😬
- тем, кто сидит на кластерах с cgroup v1 - пора планировать миграцию, иначе 1.35 встретите со сломанным кублетом
- тем, кто хоть раз получал баг репорт "у нас метрик нет на /metrics/cadvisor" и не понимал откуда они вообще должны прилетать
- начинающим, кто хочет понять физику процессов, а не "ну вот стоит прометеус и метрики откуда-то есть"
- шизикам-любителям полазить по /sys/fs/cgroup/kubepods.slice/, потому что половина статьи это именно ssh + ls -la 😀

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

Никакого AI, сорян, чисто инженерный документ для инженеров про кубы.

внезапная #пятница

В 16.37 упала интеграция со Slack.

Сначала никто не придал значения: не грузятся картинки, не отправляются сообщения - бывает.
Но через несколько минут стало понятно, что вместе со Slack исчезло всё: алерты, уведомления, инциденты, интеграции с джира и другими системами.
Это была.. это была katastrofa!

Alertmanager и Grafana IRM продолжали честно, но грустно, стрелять событиями, но они уходили в пустоту.

Автономные AI-агенты, на которых недавно переложили реагирование на инциденты, перестали работать - им просто неоткуда было читать сигналы и некуда писать решения.

Прод уже начинал сыпаться: росла нагрузка, сервисы деградировали, поды уходили в рестарты.
Но в команде царила странная пауза.

Инженеры сидели в Slack и ждали, когда появится алерт.
Без него никто не понимал, куда смотреть и что именно сломалось.
Слишком многое теперь начиналось с уведомления.
Инженерам пришлось руками, РУКАМИ, писать в чаты Слака и телеги:
- "А у нас вообще есть инцидент?"
- "Кто on-call?"
- "Где это посмотреть, если нет алерта?"
- "А какой агент за это отвечает?"
- "а где хаддл?"
Ответа не было.

И только Валера, простой старый сисадмин, которого держали "на всякий случай", просто открыл Grafana и Прометиус в браузере. Без интеграций, без ботов, без AI.
Через пару минут он уже видел картину целиком.

Он зашёл в Alertmanager UI, сам прочитал алерты, потом пошёл в kubectl и начал разбираться, что происходит в кластере.
Без подсказок, без рекомендаций, без "предложенных действий" и MCP.
Просто как раньше.

Проблема нашлась быстро - кривой rollout положил часть прод-кластера.
Валера пофиксил деплой, проверил состояние, убедился, что метрики возвращаются в норму, и только после этого открыл Slack и сам, своими руками, без агентов, написал:
"Прод падал. Починил. Чекните."

Через несколько минут Slack ожил.
За ним - агенты.
Они прочитали тред, проанализировали данные и сгенерировали отчёт об инциденте.
А потом поставили Валере 👍
Потому что без интеграций они не умеют нихуя ничего.
А Валера - умеет.

#devops #linux #security

Только-только отгремели два LPE
- https://copy.fail/
- https://github.com/V4bel/dirtyfrag

Не успели донести ещё до продакшна изменения-фиксы, так уже третья проблема прилетела.
- https://github.com/v12-security/pocs/tree/main/fragnesia

Какой ад, если честно 🤦‍♂️🤦‍♂️🤦‍♂️

Чот всё как-то проклято с этими LPE.
Ведь точно не последняя будет с такой-то волной интереса и доступностью AI агентов и ассистентов.

Применять это в пятницу вечером на продакшне, я конечно же, не буду 😬

#aws #eks #kubernetes #bottlerocket #troubleshooting #security #linux #CVE

Сорри за частые посты сегодня☔️

Пока я был в отпуске и спал, снова сломали все интернеты.

В мае 2026 вышла пара свежих уязвимостей ядра linux в ос
- первая: CVE-2026-31431, она же Copy Fail
https://copy.fail
- вторая: Dirty Frag, смежная к первой
https://github.com/V4bel/dirtyfrag

Обе уязвимости это локальное повышение привилегий (LPE).
То есть если кто-то запустил код на вашей ноде, он может стать рутом.
В контексте Kubernetes это означает выход из контейнера на хост.

Первым делом пошёл смотреть, а вообще мы уязвимы или нет.
Способ 1:

kubectl debug node/<имя_ноды> -it --image=busybox -- sh

Внутри:

chroot /host modprobe algif_aead

Если в ответ получаете:

modprobe: ERROR: could not insert 'algif_aead': Operation not permitted

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

Способ 2: через SSM напрямую на ноду (только для Bottlerocket)
Это нативный способ для Bottlerocket.
Я писал об этом не раз, искать по тегу #bottlerocket

Подключаемся к ноде и проверяем модули:

cat /proc/modules | grep -E 'algif_aead|esp4|esp6|rxrpc'

Если пусто, модули не загружены.
Пробуем загрузить принудительно:

modprobe algif_aead

Если Operation not permitted, не уязвимы.

Почему у нас не сработало, хотя версия ядра старая
У нас EKS с Bottlerocket AMI.
Bottlerocket по умолчанию запускается с

kernel.lockdown = integrity.

В этом режиме загрузка не подписанных модулей через modprobe из пространства пользователя запрещена.
То есть Copy Fail + Dirty Frag требуют загрузить модуль algif_aead (или esp4/esp6/rxrpc как обход), но lockdown просто не даёт это сделать.

Это не значит, что можно расслабиться.
Это значит, что есть один слой защиты.
Defence-in-depth требует добавить второй явный слой и всё равно обновить ядро.

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

Bottlerocket (Terraform, launch template + user data):
Добавляем в bottlerocket.tpl:

[settings.kernel]
lockdown = "integrity"

[settings.kernel.modules.algif_aead]
allowed = false

[settings.kernel.modules.esp4]
allowed = false

[settings.kernel.modules.esp6]
allowed = false

[settings.kernel.modules.rxrpc]
allowed = false

Это работает на уровне Bottlerocket API.
Он сам создаст нужные записи в /etc/modprobe.d/ при старте ноды.

Если у вас Karpenter, то добавляете в NodeClass или EC2NodeClass в секцию userData аналогичный блок для вашего distro.
Если у вас самописные Terraform-модули для нод-групп, то смотрите где у вас формируется user_data для launch template.
Добавляете туда блок выше.
Паттерн один и тот же, разница только в синтаксисе шаблона.

Как проверить что всё применилось
Для Bottlerocket есть нативный способ: через apiclient прямо с ноды, без debug подов и без sheltie.
Работает через SSM send-command из любого места где есть aws cli.

Узнаём instance ID:

kubectl get node <имя_ноды> -o jsonpath='{.spec.providerID}' | sed 's|.*\/||'

Запускаем команду через SSM:

aws ssm send-command \
  --instance-ids <instance-id> \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["apiclient get settings.kernel"]' \
  --region us-east-1

Смотрим результат:

aws ssm get-command-invocation \
  --command-id <command-id> \
  --instance-id <instance-id> \
  --region us-east-1 \
  --query 'StandardOutputContent' \
  --output text

Если всё применилось, увидите:

{
  "settings": {
    "kernel": {
      "lockdown": "integrity",
      "modules": {
        "algif_aead": { "allowed": false },
        "esp4":       { "allowed": false },
        "esp6":       { "allowed": false },
        "rxrpc":      { "allowed": false }
      }
    }
  }
}

Если патч не применён, только lockdown, без modules:

{
  "settings": {
    "kernel": {
      "lockdown": "integrity"
    }
  }
}

Это показывает конфиг именно так, как его видит сама OS.
Лучше чем смотреть файлы руками.
Можно спать дальше 🛌

#пятница

Читаю я все эти новости про увольнения конца 2025 - начала 2026:
- оракл 30к
- амазон 30к
- интел 28к+
- ups 30к
- микрософт 18к
- куча менее известных компаний с 5-10к каждая

Что из этого стоит вынести?
Работать по выходным "в надежде на премию/опцион" - проклятая инвестиция.
Из последнего - https://finance.yahoo.com/markets/stocks/articles/oracles-cfo-got-26m-stock-184500098.html
Просто до хруста нагнули ребят и по-борцовски перекинули через себя на пол. Всё, что не успело вестнуться, просто сгорело - у людей улетели десятки и сотни тысяч долларов на бумаге.

Компании оптимизируют расходы быстро и без эмоций. И это норм.
Вчера ты перерабатывал, сегодня - строка в отчёте (сгенерированном ИИ, лол).
Премии могут не случиться, опционы - обесцениться (читайте про Oracle), а вот выгореть - вполне реально.

Мы, трудяги-работяги цифрового мира, у себя одни.
Не будьте оленями.
Завтра выходной - отдыхаем.

#AWScommunity #troubleshooting #EKS #kubernetes #nodejs #aws #longread #SRE

Пока был в отпуске дописал свой лонгрид по дебаггингу 502 ошибок в приложении, запущенных в кубернетис.
Информация может быть полезна начинающим специалистам и мидлам по направлениям DevOps/SRE/VibeOps.
Более старшим и опытным товарищам заметка может показаться слабой.

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

https://teletype.in/@kruchkov_alexandr/K-2Mql5Hsok

Никаких технических статей и заметок на этой неделе нет по причине моего отпуска.

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

Читал я для себя, так как планировал попробовать сплит клавиатуру и хотел понять, надо ли оно мне, какие плюсы и минусы несет. Заметка у автора получилась просто огромная, очень интересно.

https://optozorax.github.io/p/my-keyboard-layout/

#пятница #байки #всратость

Давно не было баек.

Когда-то давно я работал в банке синего цвета.
Или красного. Или жёлтого. А уже и не важно, может и не работал вовсе.

В банках всё строго регламентировано: отдельный контур для дева, отдельный для стейджа, препрод и прод. Свои отдельные аккаунты, свои отдельные CI/CD системы, свои раннеры, только под проект. Те, кто работал в банках, наверняка знают, как всё урезано и изолировано.

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

И вот тут выяснилось кое-что неприятное.
Не все инженеры из продуктовых команд после работы на шаренном раннере чистили за собой кеш и конфиг.
А oc login, как это принято, пишет конфиг сессии прямо на диск.
И этот конфиг никуда не девается, если явно не выйти.

То есть следующий инженер, который запускал свою джобу на том же раннере, мог просто подобрать чужой опеншифт конфиг и зайти в чужой неймспейс.
А оттуда все секреты кубера, пароли к БД и так далее. Дев, конечно, но тем не менее.

Я писал команде поддержки конвейера - разводили руками. Писал команде поддержки опеншифтов - тоже ничего. Хотя решений было полно: запретить запись этого файла на раннере, чистить конфиг после каждого старта, да хоть просто добавить logout в шаблон джобы. Сотни вариантов. Ни один не взлетел.

Тогда я решил действовать сам. Решение получилось, скажем так, воспитательное.
Я создал пайплайн, который раз в пять минут по крону проверял незавершённые сессии. Если находил, то скейлил все деплойменты и деплойментконфиги в ноль, поднимал десять реплик фейкового пода с говорящим именем и чистил конфиг за нерадивым инженером.
Добавил, так сказать, немного пассивной агрессии в инфраструктуре. 😀

Вот примерно так это выглядело:

object CheckOrphanSessions : BuildType({
    name = "check-shared-runner-sessions"

    steps {
        script {
            scriptContent = """
                #!/usr/bin/env bash

                oc=/path/to/oc

                whoami=${'$'}(${'$'}oc whoami)

                if [[ ${'$'}whoami == *"deploy-sa"* ]]; then

                    ${'$'}oc scale deployment --all --replicas=0
                    ${'$'}oc scale deploymentconfig --all --replicas=0

                    ${'$'}oc new-app \
                        --name add-oc-logout-command-after-deploy-on-omni-agents \
                        --docker-image=registry.example.internal/fakeimage:latest \
                        --allow-missing-images

                    ${'$'}oc scale deployment/add-oc-logout-command-after-deploy-on-omni-agents --replicas=10

                    ${'$'}oc logout
                    echo "##ci[buildStatus text='caught you. ${'$'}whoami did not logout']"
                else
                    echo "##ci[buildStatus text='agent is clean']"
                fi
            """.trimIndent()
        }
    }

    triggers {
        schedule {
            schedulingPolicy = cron {
                minutes = "*/5"
            }
            branchFilter = ""
            triggerBuild = always()
            withPendingChangesOnly = false
        }
    }
})

Помогло ли это? Конечно же нет.😬

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

Не знаю, как насчёт импортозамещения, возможно сфера влияния поменялась, сейчас уже ничего этого не существует.

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