Make. Build. Break. Reflect.

#aws #elasticache #redis #kubernetes #troubleshooting #devops #sre #longread

Ничего не предвещало беды. Сижу, работаю, обычный день.
Прилетает алерт: CPU на редисе.

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

Стою на развилке, как обычно в таких случаях.
Вариантов, по сути, три сходу:
- поднять инстанс тип побольше - и вопрос закрыт. Минут на пятнадцать работы.
- копать почему нагрузка растёт - раз уж она растёт неделями, значит где-то есть тренд (мемори лик?), и если его не найти, он вернётся через месяц уже на инстансе побольше.
- полезть в релизы/код - может, кто-то тихо принёс что-то, что жрёт редис сильнее, чем раньше.

Времени в этот день было, под рукой прямых пожаров нет, так что решил нырнуть.

Начал копать. Смотрю на количество соединений к редису - и это тоже растёт. Причём растёт не гладко, а скачками.
Спустя время понял, что ровно в моменты редеплоев и скейлинга подов.
У меня в голове сразу щёлкает классика жанра: коннекшн лик.
Кто-то не закрывает соединения при рестарте пода, они копятся, some magic, редис в итоге не столько данные обрабатывает, сколько бегает между тысячами открытых, но по факту мёртвых клиентов.

Полез руками смотреть список клиентов - и что вы думаете, реально нахожу один клиент, зависший в цикле на одной и той же команде. Судя по времени коннекта - висит там натурально сутки, сука, с прошлого деплоя.
Убиваю его руками, CPU чуть проседает. Ага, думаю, вот он, зверь, поймал.

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

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

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

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

Стали считать руками, вместо того чтобы верить на глаз. Взяли количество воркер-процессов на под, умножили на количество подов - и цифра сошлась с реальным числом коннектов почти впритык (разница пара процентов, спишем на процессы в момент рестарта). То есть на каждый воркер-процесс - одно соединение к редису на каждую используемую БД внутри инстанса. Это не утечка. Это ебаная архитектура. Просто у нас этих воркер-процессов оказалось значительно больше, чем реально нужно под текущую нагрузку - часть очередей держала по 20+ воркеров при спросе, близком к нулю.🤡

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

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

Дальше - самая интересная часть. У ElastiCache есть слой "enhanced I/O" с io-threads, которые молотят входящий трафик отдельно от главного event-loop потока. И вот при определённом уровне конкурентных подключений без пайплайнинга этот флаг io_threads_active залипает в 1 - и тогда добрая половина основного (единственного, сука) engine потока улетает во busy-wait: не делает полезной работы, не в syscall, просто крутится в холостую, ожидая координации с io-потоками. Причём сама выполняемая команда - это 9-12% занятости потока, всё остальное - вот этот самый спин.

Проверили это экспериментально на реплике без прод-трафика: подняли конкурентные подключения без пайплайнинга - флаг щёлкнул с 0 на 1, и разрыв между "занят" и "реально делает команды" улетел с полутора процентов до пятидесяти. В 34 раза. Сняли нагрузку - всё вернулось на исходную позицию. Воспроизводится по требованию.

Самое обидное: нодовая метрика CPUUtilization в CloudWatch при этом показывала спокойные 44% - потому что она про весь инстанс с его 8 vCPU, а не про то, что творится именно в главном движковом потоке. EngineCPUUtilization - вот метрика, которая реально видит проблему, а на неё у нас не было алерта вообще. Ни одного. Полезная информация лежала в CloudWatch всё это время, просто мы на неё не смотрели.🤡

Дальше прогнали чек-лист на исключение всего остального, чем это могло быть: экспайры ключей - доли процента от жизни, evicted_keys - ноль, дефраг - ноль, решардинг хештейбла - ноль, keyspace-нотификации - учтены внутри команд и не создают отдельной нагрузки, скрипты/функции - вообще не используются, ни одной команды дольше 10мс за всё окно наблюдения. Это точно не медленный запрос и не утечка памяти. Это именно координационный оверхед в закрытом слое ElastiCache, который мы не видим и не можем настроить - параметр io-threads не выставлен наружу ни в одной из параметр-групп valkey, CONFIG SET для него заблокирован.

Раз рычага внутрь закрытого слоя AWS у нас нет - работаем с тем, что реально в наших руках:
- срезали количество воркер-процессов там, где спрос был почти нулевой, а супервизоров держали как для продакшна с полной загрузкой (одна из групп очередей - 22 воркера при спросе меньше десятка операций в сутки). Это прямо снижает число одновременных подключений, соответственно снижает шанс залипания флага в 1.
- добавили алёрт по EngineCPUUtilization, а не только по CPUUtilization - потому что нодовая метрика в принципе не видит этот тип насыщения.
- хардним ElastiCache client reaping и client-output-buffer-limit - отдельная гигиена, чтобы зомби-клиенты (тот самый, что я руками убил в начале) не жили сутками незамеченными.
- поправили notify-keyspace-events - было включено с флагами, генерирующими события, которые вообще никто не читает (180 тысяч событий в секунду в пустоту, лол). Не фикс основной проблемы, но лишняя работа редиса, от которой легко избавиться.

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


Ссылки могут быть сейчас устаревшими, были актуальны на момент проблемы
- https://repost.aws/knowledge-center/elasticache-redis-high-cpu-usage
- https://medium.com/better-programming/redis-internals-client-sends-a-command-and-receives-a-response-9e3e8c463f7

Вся эта неделя была очень странной.

Опус отупел до уровня 3 модели.
Фейбл сжигает токены быстрее, чем Усейн Болт пробегает 10 метров.
Лимиты токенов на клодкоде 100% урезали, не хватало для простейших задач, на прошлых неделях на тех же промптах хватало всегда.
Модели начинают сами с собой спорить, входить в циклы, снова галлюцинировать.

На картинке типичная ситуация этой недели
"Когда дал клоду задачку с опусом и пришел спросить его как дела через 2 часа".

Apple наконец слила beta и release в один продукт и избавились от лишнего шага в релизном цикле. 🎉🎉🎉

https://www.reddit.com/r/MacOS/comments/1wgek2q/macos_27_golden_gate_bugs_and_issues_megathread/

#мысли #devops #aws

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

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

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

Пример.
Есть AD-сервис, допустим MS Entra. Есть AWS и сервисы внутри него. У какого-то сервиса - пусть OpenSearch, не важно, хоть Redis - по дефолту ебанутое имя типа:
- dkjfh-hui-izda-dgigkhurda-aws.account.region.amazonaws.com

Через Entra-приложение настроили SSO.
Всё работает: люди ходят на некрасивый урл, логинятся через проклятый майкрософтовский аккаунт, все счастливы.

Усложняем.
Разработчики захотели красивые адреса - для UI и CLI-агентов.
Задача: добавить в Route53 (или другой DNS сервис)
- logs-prod.domain.com
- redis-stage.domain.com
Почему - да без разницы, просто захотели.

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

- DNS. Просто добавить запись - заработает? По идее нет: нового адреса нет в списке разрешённых redirect URI в Entra, он отвалится с ошибкой мисматча. И это не хардкод где-то в коде, а обычный allowlist.

- Коллбек vs UI. Это одно и то же? Нет, вроде разные слои. UI-адрес - то, что видит браузер. Коллбек - то, куда Entra шлёт ответ после логина. Можно спокойно жить на новом UI-адресе, а коллбек временно оставить на старом.

- Что я поломаю нахуй самим добавлением. Само добавление DNS-записи - ничего. Ломает либо снос старой записи/старого redirect URI сразу, либо TLS: у AWS managed сервиса сертификат зашит под их дефолтный домен, левый CNAME туда просто не пройдёт проверку сертификата без прокладки сверху (ALB, CloudFront - что угодно со своим сертификатом на новый домен).

- Алиасы в Entra. Redirect URIs / Reply URLs - это список, в него добавляют, а не заменяют существующее. А если это SAML, появляется третий слой - Audience/Entity ID, и с ним уже не всегда так просто: не каждый SP умеет несколько audience одновременно. Умеет ли ентра?

- А может, сразу дропнуть старое и переехать целиком? Ну уж нет. Это же чисто flag day cutover на SSO - способ уронить логин всем разом, если хоть один слой не совпал.

- Где реально терминируется сертификат. Что если вместо Route53 - Cloudflare: как быть с прокси и эджем, что если это Cloudflare ACM. Здесь я сознательно не даю себе ответа - это уже вопрос конкретной архитектуры, а не общей логики разбора.

- А может у AWS есть custom URL фича для этого сервиса и ничего выдумывать не надо?


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

Зато есть метод, который я в процессе применяю: не спрашивать "заработает или нет", а спрашивать самого себя "какие независимые системы должны согласиться друг с другом, чтобы это заработало" - и проверять их по одной. DNS, TLS, redirect URI, SAML audience и порядок отключения старого - это разные системы, которые нужно свести по отдельности, а не одна абстрактная "настройка SSO".

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

Факты модель знает лучше меня. Определённо.

А привычку резать проблему на проверяемые куски - тренирует только ручная работа.

#aws и немного #всратость

Честно говоря я немного разочарован последними UI изменениями, произошедшими в AWS docs.

Возможно молодому, стильному и умному поколению инженеров интерфейс нравится, но мне с ним работать стало неудобно.

Возьмём к примеру случайную страницу.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Limits.html
Листаем до первой таблицы.
Визуально кажется - вот всё, что есть в таблице - это вся информация.
Ведь видно только этот элемент.
Однако при наведении мышки/тачпада на саму таблицу - появляется scrollbar и уже видно элементы таблицы вниз и вверх. (гифка)
Открывается новая инфа, ранее визуально недоступная.
Как я мог догадаться, что теперь там скрыт скроллбар?
Ну, наверное, должен был как-то.

Пойдем к другой случайной странице
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.configuration.requirements.html
А вот тут, сколько ни елозь мышкой по первой таблице - ничего не открывается.
Вероятно я должен понять, что этих параметров достаточно и больше там ничего нет.
Чего я, как дурак картонный, тыкаю тачем по таблице - непонятно что-ли, что нет там больше ничего.

Идём дальше, например
https://docs.aws.amazon.com/service-authorization/latest/reference/list_securityhub.html
Тут же, наоборот, вниз таблицу сделали полностью, она, о-чудо!, уместилась, а вправо информации уже нет.
На этой странице у этой таблицы надо тачем елозить уже только вправо-влево по таблице.

Как я должен понять - на какой из таблиц мне елозить тачпадом во все стороны, а на какой нет - ну, вероятно, догадываться, проверяя каждый подобный элемент документации.☔️

Это произошло не вчера, а постепенно происходит с многими страницами документации. Может это даже современный тренд в дизайне.

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

Классный вышел тред и официальный платиновый ответ.😁

Чувствую много болей в ближайшие дни.
https://github.com/orgs/community/discussions/206581#discussioncomment-18269083

С некоторых комментов можно гиеной прокричать

So, just to make sure I understand this correctly: unauthenticated access to public repositories suddenly became unreliable, CI pipelines all over Europe started breaking, GitHub Status stayed green, and the official solution is basically “authenticate your public repository downloads and deal with it yourselves”?

Само решение:
git config --global http.version HTTP/1.1

#всратость

Ну-да, ну-да.
Это так и работает, ага.
Больше ничего не надо вводить.🥴

Похоже и правда пора в отпуск.🤡

#devops #tools

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


- https://blog.cloudflare.com/dns-cache-memory-optimization-1111/

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

- https://www.youtube.com/watch?v=LX4YZeqXWck

Какие подводные камни были у ребят из airbnb при переезде на циллиум.
Молодцы, шарят такое.
Если нет знаний английского - в ютубе есть автоматический перевод аудиодорожки на русский. Слабенький, но его достаточно для усвоения материала.
Спойлер: а зачем тебе спойлер? Смотри и слушай видео, не ленись, ну.

- https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/
- https://www.githubstatus.com/incidents/zkxwbgr0cnmx

Постмортем гитхаба на один из крупных инцидентов.
Просто интересно посмотреть почитать изнутри.

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

- https://github.com/vorssaintapp/vorssaint-utils

Один из лучших утилит для MacOs.
❤️
Опенсорс бесплатный супер комбайн, который может отчасти заменить многие привычные всем утилиты. AltTab, Rectange etc.
Очень жалею, что купил лицензию AlbTab (для дополнительного функционала), лучше бы я раньше узнал об этой утилите.
Считаю, что моя лучшая находка в 2026 для мака.
На маке я работаю лишь с марта этого года.

- https://trendshift.io/monthly

Трендовые git репозитории по месяцам/неделям/дням.
Если вы прям любите быть на bleeding edge - это вам.
Всё самое модное и свежее - всякие скилл репо, агентик репо, фреймворки, харнессы и всё то, о чём будут писать лишь через несколько недель или месяцев, а вы это уже освоите сегодня.

- https://www.goncharov.xyz/it/devops-roadmap.html

Очень старая схема-роадмап девопса от Гончарова
К сожалению, я добрался до неё буквально недавно, упустил его публикацию.
Не буду говорить согласен ли я с этим планом на 100% или нет (сейчас век "ИИ" и всё сказанное мной будет не актуально через неделю), но почитать точно стоит.
Для общего развития, не брать основным планом развития.

- https://www.redhat.com/en/resources/oreilly-generative-ai-kubernetes-analyst-material

Бесплатная книга от redhat+oreilly, которую я определённо дочитаю по дороге в отпуск.
Сейчас начал читать - по мне так ок, закрою пробелы по базе.
Уверен на 90%, что это будущие вопросы на будущие собеседования 2027-2028, так что точно дочитаю.

#пятница

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

Даже базовые вещи приходится объяснять заново, и обидно не столько объяснять, сколько ещё и доказывать.
Я же не клодкод или джипити.
Какой-то человек.


Чтобы был аргумент для коллег и приятелей (а так же их нейронок) "почему curl | bash - это плохо", я запилил домен и хреново навайбкодил страничку с аргументами.

- https://nocurlbash.com/

Теперь в спорах ссылаюсь на неё как на источник истины:
- "вон, смотри, даже сайт специальный есть, люди против курлбаша, вот аргументы, это бэд-практис ващета!"

Пока прокатывает 😀

POV:
сейчас 2026 год и твой босс думает как назвать новый продукт, который нужно зарелизить ещё вчера, хоть и было придуман 5 минут назад на встрече с потенциальным клиентом

#AWScommunity #aws #longread #rds #aurora #mysql #airflow #devops #troubleshooting

Часть 2 из 2.

Внимательный читатель задаст вопрос
"Алекс, кого ты лечишь? РДС не даёт рекомендации, если всего полчаса в день отставание, ты что-то упускаешь, кривой ETL не дал бы такой эффект".
Да, всё так.

Починив ELT/DAG, мы поняли, что рекомендация остаётся даже после этого.
Сняли всю информацию, все метрики клоудвоча, аудит логи - не смогли найти причину. Написали в саппорт. Дали все метрики, в том числе аномальные транзакции.

Буквально в 5-6 итераций общения с саппортом и мы поняли, что все были правы - рекомендация по делу триггерится - по метрике, но сама метрика обманывает.

...
Update: root cause of the TransactionAgeMaximum anomaly is confirmed cosmetic

Our Aurora MySQL engineering team completed an end-to-end root-cause analysis of the ~1.77–1.78 billion-second (~56-year) TransactionAgeMaximum readings — the same class of anomaly you identified. The finding is definitive:

1. The anomaly is caused by a race condition in the engine's transaction start-time path on Graviton (ARM) instance classes, specific to the 3.0x.x engine family. In brief, a transaction's start-time is briefly visible to the metric-gathering poller before it is fully initialized, so the poller computes an age against a near-zero epoch — yielding the nonsensical ~56-year value.

2. Engineering traced the code path end-to-end (from the internal gauge, through information_schema, to CloudWatch) and concluded: "Cosmetic metric anomaly only. No actual long-running transaction, no performance or availability impact." They explicitly found no code path that produces a real transaction behind these readings.
...
Yes — it is safe to proceed the upgrade.

Тот дикий "возраст транзакции в 56 лет" оказался реальным, подтверждённым багом Aurora MySQL 3.*.x на Гравитонах. Race condition в коде движка: поллер метрики иногда читает время старта транзакции чуть раньше, чем оно успело проинициализироваться, и считает возраст от почти нулевой эпохи😬. Никакой реальной транзакции за этим не стоит, чистая косметика в метрике.

А вот прямую связь с тем, что база полгода не возвращается к норме, доказать так и не смогли. Слишком много времени прошло. Так и закрыли: корреляция по времени подтверждена, причинность нет, а вердикт практический: purge здоров, текущий уровень не риск, апгрейду быть.

Апгрейд прошёл отлично.
После апгрейда баг с метрикой ушёл.

Так что же в итоге?
Иногда в процессе подготовки агрейда находишь множество не явных вещей:
- не настроен мониторинг/алёртинг RDS рекомендаций и никто на это не смотрит, а в скоуп уведомлений от Amazon Notification Center это не входит
- схемы/диаграммы надо поддерживать
- нет мониторинга/алёртинга RDS/Airflow на долгие транзакции
- баги. Иногда копаешь неделями, а там ты ваще не виноват, это лишь баги

- - -
* Все умные слова для БД, точные запросы, интерпретация ответов была сделана при помощи значительно более умных коллег, у кого больше опыта с БД.
Сам я как был слабый по БД, так и остался.

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

#AWScommunity #aws #longread #rds #aurora #mysql #airflow #devops #troubleshooting

Часть 1 из 2.

Короче, понадобилось нам обновлять Aurora MySQL с одной мажорной версии на другую.

Дело обычное, но перед любым мажорным апгрейдом продовой базы я по гайду иду смотреть, что у нас там висит в RDS Recommendations. И тут внезапно выясняется: на этом проекте мы туда вообще не смотрели. Ни разу. Никто и никогда. Стоит себе панель рекомендаций в консоли, что-то там подсвечено жёлтым и красным, и всем как-то норм.

Полез разбираться.
Первым делом сделал то, что должен был сделать ещё полгода назад: завёл алерт.
На память связка EventBridge + SNS + питон лямбда + слак вебхук.
Раз в неделю по понедельникам в Slack прилетает дайджест активных рекомендаций по нашим RDS.
Не срочный инцидент, просто напоминалка, чтобы это больше никогда тихо не копилось год.

И буквально в первом же прогоне вижу:
"The InnoDB history list length increased significantly".
Активна с августа. Полгода висела.

Смотрю, что это вообще такое. History list length это, как я понимаю, количество ещё не почищенных undo-записей в InnoDB.
Растёт когда purge не успевает убирать за транзакциями. Амазон в описании рекомендации прямо пишет: чинить это нужно ДО мажорного апгрейда, потому что при апгрейде движок долго разбирает этот список, и чем он больше, тем дольше и опаснее апгрейд.
Всё, приехали, это блокер апгрейда. 😢

Ладно, начали копать.

Первая гипотеза была самая очевидная и, как оказалось, неверная.
У нас есть ETL-пайплайн на сраном Эйрфлоу, который раз в сутки синкает MySQL в Snowflake. Смотрю на архитектурную схему пайплайна в не менее сраном Confluence, вижу коробочку "Aurora MySQL prod", стрелочка от Airflow прямо в неё. Ну всё, думаю, вот он, виновник, тащит данные прямо с мастера, долгая транзакция на райтере, отсюда и history list.

Написал коллегам из дата-команды: "у нас, похоже, Airflow бьёт напрямую в master, из-за этого и растёт список".
Ответ был короткий и справедливый: "у нас Database Insights показывает Airflow на ридере, как обычно. Дайте данные, а не предположение".

Справедливо. Полез проверять руками, а не по картинке из confluence.
Достал security groups у MWAA-окружения, нашёл ENI airflow-воркера, сравнил security groups с тем, что у MWAA в конфиге. Совпало. Дальше через Performance Insights посмотрел топ хостов по нагрузке на ридере и на райтере за то же окно времени. IP воркера Airflow, топ-1 по нагрузке на ридере. На райтере в топ-25 вообще не встречается.
Гипотеза номер один, красиво описанная на диаграмме, была мимо.
Дело было не в мастере.
Ладно, обделался я со своей гипотезой, ну да ладно, бывает.🤡

Думаю, может тогда это просто какая-то одна зависшая транзакция сидит прямо на райтере, не важно кто её открыл. Полез сам* в information_schema.innodb_trx.
Смотрю на текущий момент: пусто, всё свежее, самой старой транзакции пара секунд. Может, просто не попал в момент.

Написал кронджобу в кластере, которая раз в две минуты в течение трёх часов дампила innodb_trx и заодно information_schema.replica_host_status (там лаг репликации и LSN между узлами кластера).
Три часа честного сбора данных на самом продовом окне, когда метрика скачет. Результат: максимальный возраст любой транзакции на райтере за все 90 замеров - три секунды. Лаг у ридера тоже никакой, пара миллисекунд.

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

Тут вспомнил про slow query log.
У нас он давно экспортится в CloudWatch Logs, просто никто туда не смотрел в контексте этой задачи. Полез в лог именно ридера, за тот же временной диапазон, что и в первой гипотезе.

И вот тут наконец что-то нашлось:

# User@Host: airflow[airflow] @  [10.0.x.x]
# Query_time: 1738.868051  Lock_time: 0.000002  Rows_sent: 6232112  Rows_examined: 19477050

Запрос от airflow, 1738 секунд, это почти 29 минут. Причём это не единичный случай, за одно окно таких штук пять, самая длинная под полчаса, самая прожорливая разбирает 235 миллионов строк за один присест (!!!). И всё это на ридере, не на райтере!!!.
То есть гипотеза номер один была не совсем мимо, просто немного не в ту сторону: эйрфлоу правда виноват, просто сидит не там, где я думал.

Дальше уже дособрал картину той же кронджобой, которую сделал для проверки транзакций. Стал смотреть не только на innodb_trx, а на oldest_read_view_trx_id у ридера. И увидел: этот trx_id замер на 15 замеров подряд, это примерно 28 минут, пока LSN* у ридера спокойно рос дальше. То есть репликация не отставала, но снепшот данных для конкретного долгого запроса не двигался почти полчаса.

Полез читать документацию Амазона по этой самой рекомендации (ссылка ниже, она буквально прямо в описании рекомендации в консоли лежит, просто никто не читал):
- https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/proactive-insights.history-list.html
- https://aws.amazon.com/blogs/database/achieve-a-high-speed-innodb-purge-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/

Цитата оттуда: если у вас райт-интенсивная нагрузка на праймари и одновременно долгие запросы на репликах, вы получите backlog по purge, потому что гарбадж коллектор блокируется этими долгими запросами.

У Aurora storage общий на весь кластер. Покурить на ридере полчаса можно, но платит за это весь кластер, включая райтер, потому что purge физически не может продвинуться дальше самого старого read view во всей этой семье инстансов. Не важно, читает мастер или реплика, движок про это ничего не знает, ему важен только самый старый снепшот.

Вот и весь секрет полугодовой рекомендации: раз в сутки прилетает ETL-синк, читает половину базы одним долгим SELECT-ом на ридере, и весь кластер полчаса не может почистить за собой.

Отдельно нашёл забавную деталь.
Кто-то** из коллег ещё в начале месяца руками (не через терраформ, просто в консоли😁) поднял max_execution_time на параметр-группе ридера до 30 минут. Видимо, до этого запрос просто убивался по таймауту и синк не долетал. То есть кто-то уже наступил на эти грабли раньше меня, просто не докопался до причины, а тупо дал запросу больше времени. Запрос стал долетать, но теперь честно душит purge все эти полчаса.

Фикс, если коротко: чинить надо не базу, а сам DAG в этом случае.
Резать один гигантский full-table sync на куски поменьше, переводить больше таблиц с полного sync на инкрементальный там, где можно, и отдельно разобраться, каковаху почему один запрос вообще читает 235 миллионов строк, может там просто индекса не хватает. Завёл тикет команде, которая владеет этим пайплайном, там всё разложено по фактам с командами и логами, а решение, как чинить, оставил за ними, это их трейдофф. Да и я слишком тупой в БД, чтобы умничать и чинить.

#мысли #ai #devops

Если честно, то за последние пару лет, как я начал использовать нейронки повсеместно - никакой Большой Революции у меня не произошло.

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

Работа
Код. Стал ли я писать код лучше?
Нет, но стал писать быстрее. И мнооооого.
И все резко перестали его читать.😢
Сам ли я его пишу или просто даю задачки? Посади меня писать код (да хоть терраформ манифест) без автокомплита, смогу? М?
Пахнет плесневелым ароматом деградации.
Траблшутинг. Стал разбираться с проблемами быстрее (привет скиллы, кли и мсп). О да, это реально работает.❤️
Агенты. Агенты, агенты везде. Стало ли с ними проще? В моей конкретной работе мне пришлось даже сократить их количество, так как я не успеваю за контекстом.
Сперва радовался куче утилит и подходов с агентами, а спустя время осознал, что больше 2-3 сессий/агентов/задач я не способен вести. Спустя ещё время я сам для себя вынужден признать, что даже "одновременно" тут лишнее слово. Я не талантливый инженер и не уникум, обычный простой работяга. Формулировка "я могу держать не больше 2-3 задач одновременно и уметь ПЕРЕКЛЮЧАТЬСЯ между ними" - будет точнее. Никакой одновременности, камон. Если взять 10 задач, то даже переключение страдает, чего уж говорить об эффективности.
Автономные агенты, да, решают. Но эээ все ли задачи я могу им поручить?
Коммуникация. На работе каждый МР с описанием как абзац Войны и Мира. Никто не читает эту простыню. Весь слак забит Очень Полезными Подробными Ответами Отчётами. Ну я честно их не читаю. Просто, блять, напиши кратко по-человечески, нахуй мне эта простыня.😈
Я и сам так могу нагенерить второй том мертвых душ. Хоть на японском.

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

Сервисы
Сейчас в каждом сервисе ИИ! Уууух! Заживём!
Правда так ничем и не стал пользоваться, лол.
Каждый блядский сервис: джира, ms word, twilio, notion, confluence, spotify/яндекс музыка, скипаю нахер. Я пробовал было их фичи, всё абсолютно тотальное говно, не помогает и не решает ничего. Херня ради херни.

Подсказка: если есть опция отключения ИИ-фичей (word, telegram, docker desktop) и вам это не надо, то отключайте нахуй. Сразу нет жорева ЦПУ/памяти. Ненужные фичи, ещё и тратящие ресурсы. Тупость.

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

Личная жизнь
Ну я теперь крутая крутышка. Могу делать домашки с нейронкой, ещё больше деградируя. Зачем, спрашивается, я тогда плачу и хожу на занятия, если домашку мне лень сделать самому.
Для игр тоже не помогает, даже билд варвара в д4 на последний сезон не собрать, галлюцинация за галлюцинацией даже на последних супердорогих моделях.
Хз в общем.

Наверное я так долго могу перечислять примеры, но после двух лет я пришёл к тому, что нейронки для меня не сделали Большой Революции.

Оспаривать революционность моделей, агентов, харнеса я не буду, это нечего и оспаривать.

Но что дало это мне?
Что дало моим близким?
Что дало человечеству?
Что РЕАЛЬНО дало это моей работе и, главное, платящим клиентам?

Я вот чот ни одной реальной стори от приятелей-айтишников не слышал, что "внедрили ИИ, клиенты довольны, много платят".
Пока только всратые истории, увольнения, миллионы не нужных платящим клиентами фич, ии-сокращения и автоматизация слопа.
На встрече All hands сидят 25 человек и 40 ботов-стенографистов.
Кто-то вообще потом читает эти саммари?

Но есть и позитивные новости
Мне нравится читать о необычных для меня использованиях нейронок:
- помощь в нахождении лекарства от рака (Insilico Medicine, ISM3091/ISM6331, от IND до Fast Track FDA)
Прикиньте, совсем скоро мы, быть сможет, победим рак! Охрененно!
- помощь в нахождении лекарства от ВИЧа (дизайн иммуногенов и антител)
Я так понял коли вакцину пару раз в год, это оберегает от ВИЧ и, соотвественно, не будет впоследствии СПИДа. Круто!
- аэродинамика для самолётов (ML как surrogate для CFD)
Ну у меня страх полётов, а если сделают ещё безопаснее - вообще красота.
- люди могут писать драйвер для принтера HP чтобы оно работало с macOS
Ну прекрасно же, долой убогий вендорлок. Штатно только винда.
- предсказание структуры белка (AlphaFold, Нобелевка по химии 2024)
Ну тут без лишних слов - достойно.
- поиск новых материалов для батареек (GNoME, 2.2 млн кристаллов за 17 дней).
Вы только представьте - система за 17 дней предсказала 2.2 млн потенциально стабильных неорганических кристаллов - в 10 раз больше, чем всё, что человечество нашло до этого!!! Из них 700+ уже подтверждены экспериментально. Охуеть.

Да масса разных примеров!

К чему я всё это.
Да, я умею работать с ИИ, нейронками, ЛЛМ, агентами и другими умными словами, что сейчас из каждого утюга.
Как-никак два года это активнейшим образом использую каждый день.
Часто даже автономно по ночам и выходным, пока SSO не отвалится или токены не закончатся.
Да, работа с ними есть/будет обязательным навыком для следующих поколений инженеров, хотим ли мы этого или нет, нравится или нет.
И да, я уверен, что модели и дальше будут умнеть.
Да, мне помогает ускорять написание кода (инфра/бизнес апп).
Да, могу катить даже 20 фичей в неделю.
Классно помогает траблшутить.
Идеально подходит для ресерча, диалогов лучших решений, разбора документации.


И... и всё.
Великая Невероятная ИИ-Революция прошла мимо меня.

#пятница

2020 Все воюют с Helm. В пайплайны судорожно вкручиваются юнит-тесты плагином, dry-run из экземпляров, helm template, строгий контроль релизов и тегов.
Опечатка в отступах, и всё падает, инцидент за инцидентом.
Забыл quote вокруг {{ .Values.name }} - ямл внезапно решил, что no это булево значение, а не имя сервиса, и всё легло.
Забыл один -}} лишний перенос строки сдвинул отступ на один пробел, ямл невалиден, привет инцидент.
Даже несовершенный MS Word гиеной визжит над сдвигами и ошибками форматирования и рендеринга хелма.😁
Чтобы докрутить одну функцию в го темплейты, нужно провести пятнадцать ритуалов, вызвать дух Линуса Торвальдса и перепроверить код сто раз.
В банках все изменения чартов проходят через отдельную инквизицию боли до получения разрешения.
Го-шаблоны официально признаны средством пыток.

2025 Нейросети есть у каждого джуна и синьора.
В девопс чатах гробовая тишина, никто не спрашивает, как прокинуть range в конфиг.
Каждый второй накрутил хуков, rules, дай-ранов и полного диффа темплейтов сразу на 1000+ Applications/ApplicationSets, и всё это валидируется за миллисекунды на каждый коммит. Ноль инцидентов.
Всем плевать, что внутри чарта - форменное ктулху говна
{{- range $k, $v := .Values.env }}{{- if $v.enabled }}{{- if $v.override }}{{ $k }}: {{ $v.value | default (include "chart.fallback" (dict "v" $v)) }}{{- else if not (empty $v.value) }}{{ $k }}: {{ $v.value }}{{- else }}{{ fail "ну удачи, лол, увидимся скоро" }}{{- end }}{{- end }}{{- end }}
Мы теперь вайбкодеры. Работает - и ладно.

2030 Четыре земные корпорации, которым принадлежат все токены мира, взвинчивают цены на мощности.
Простой прогон проверок через LLM превращается из клика за 1 наноцент в половину ВВП Эстонии.
В чатах телеги и на реддите снова толпы с горящими жопами: "всмыысле не могу выйти выше контекста?", "хочу поправить этот key value, только код писал не я и даже не человек, и, кстати, что такое dict?", "а что тут забыл этот рейндж?".
Пулл реквесты чартов снова приходится ревьюить глазами, слышен волчий вой отчаянья по всем коворкингам и офисам.🐺

Лишь глобальная катастрофа в IT индустрии и поднятие цен на мощности смогли очередной раз доказать, что го-темплейты в хелме так никто и не смог понять - потому что их изначально не задумывали понятными 😀

#kubernetes #devops #sre

TLDR: это не пост с решением.
Скорее пост-размышление с очередным внутренним вопросом, на который я сам себе так и не ответил.


Прилетает алерт.
Смотрю чо там.
У него метрика простая:
kube_node_status_condition{condition="DiskPressure",status="true"} == 1
Полез смотреть - да, реально диска не хватает.

Дальше вопрос на минуту:
а чем именно забито? Логами? Эфемерными томами подов? Или это имаджи?
Смотрим ещё одну метрику:
kubelet_image_garbage_collected_total{reason="space"}

Счётчик прыгнул вверх ровно в момент алерта.
Всё, картина ясна: раздел на 200 гигов забился старыми образами (очень частые релизы, по гигалион раз в день), кублет сам это увидел, сам почистил, алерт потух.

Красота же?
Сработало как задумано: от NodeHasDiskPressure до NodeHasNoDiskPressure прошло 8 минут, ни одной ручной команды.

Но вот дальше я сижу и не понимаю, что с этим делать дальше.
В голову приходит несколько вариантов:
- увеличить диск
Поможет? Да, отодвинет проблему во времени. Но это буквально плата за то, чтобы не думать. И мы вроде не резинового бюджета контора, чтобы просто лупать гигабайты, потому что "так спокойнее".

- подвинуть трешхолды гарбаджколлектора *
стояло:

image-gc-high-threshold-percent = 85
image-gc-low-threshold-percent = 80

Много это или мало - а хуй знает.
Может, надо 60/65, чтобы чистка начиналась заранее и мы вообще не долетали до disk pressure. Может вообще поставить 40%, лол.
А может это сделает только хуже - кублет начнёт чиститься чаще, будет чаще передёргивать пул подов, которые сейчас пуллят образ.
Кстати да, у меня был страх - а не удалит ли гарбаджколлектор образ, который прямо сейчас используется живым контейнером?
По идее нет, не удалит, вроде кублетовский image GC чистит только то, что не занято ни одним запущенным контейнером. Но осадочек "а что если" всё равно остался, потому что документация - это одно, а современный вайбкод, даже в кубере, это другое.

- моё любимое - забить болт 😎
Формально всё ок: алерт мигнул и потух сам, никакого даунтайма. Disk pressure - это не баг, это фича, механизм ровно для этого и придуман.

- вырубить нахер этот алерт?
Да вроде тупость. Тогда зачем я его добавлял.

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

- менять северити на инфо?
А если это реальная трабла?

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

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

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

- - -
* Кстати я не помню, надо гуглить, а точно ли эти метрики, это случаем не эвикшн менеджер дергает триггер на imagefs.available<15%?
Или один трешхолд запускает чистку, а другой двигает метрику диск прешр?
Надо читать.

#security #docker #devops и немного #всратость

Заметка носит скорее исследовательский и развлекательный характер.
Никакого поиска правды, настаивании на этом мнении или призыва к действию.


Однажды приходит алерт от инфобеза: критическая уязвимость, CVE-666lupa666pupa в zlib, надо фиксить.

Смотрю: zlib - это какая-то неизвестная мне хрень.
Возможно и инфобезе, может и никому.
Дебиан букворм держит zlib1g 1.2.13, в которой этот CVE есть.
Триви его видит, алерт красный, белки-истерички кричат и бегают по кругу.

Говорю инфобезу: это нас не касается, камон.
Во-первых, статус в самом триви - will not fix.
Во-вторых, есть флаг --ignore-unfixed, который именно для этого и придуман.
Мы в тот момент работали без этого флага - по какой-то причине, уже не помню.
Поэтому жалобка и прилетела. Поставили флаг + игнор файл для другой неэксплуатируемой штуки и вроде отстали от нас.
В-третьих, сканер это опционально у нас, ну чо ты, какие блокеры, иди чай попей.

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

- - -
Тест первый.
Пересобрал образ, вручную скомпилировал из сорсов прямо в имадж:

RUN apt-get update && apt-get install -y build-essential wget \
  && wget https://github.com/madler/zlib/releases/download/v1.3.1/zlib-1.3.1.tar.gz \
  && tar -xf zlib-1.3.1.tar.gz \
  && cd zlib-1.3.1 \
  && ./configure \
  && make \
  && make install \
  && ldconfig \
  && cd .. \
  && rm -rf zlib-1.3.1 zlib-1.3.1.tar.gz \
  && apt-get purge -y build-essential wget \
  && apt-get autoremove -y

Проверяю внутри контейнера - 1.3.1 там:

$ ls -la /usr/local/lib/libz*
lrwxrwxrwx  /usr/local/lib/libz.so -> libz.so.1.3.1
lrwxrwxrwx  /usr/local/lib/libz.so.1 -> libz.so.1.3.1
-rwxr-xr-x  /usr/local/lib/libz.so.1.3.1

$ ldconfig -p | grep libz
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1  <- dpkg-пакет, 1.2.13
libz.so.1 => /usr/local/lib/libz.so.1  <- скомпилированная 1.3.1

Запускаю триви - снова цве критикал 😬

Вероятно триви читает /var/lib/dpkg/status - базу пакетного менеджера.
Что реально лежит в /usr/local/lib его не интересует.
Скомпилированная версия для него невидима. Безопасность)

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

Тест второй.
Раз уж проверяем, проверим до конца.
Берём образ с реальной уязвимостью - log4shell

FROM alpine:3.18
WORKDIR /app
RUN apk add --no-cache openjdk8-jre-base wget
RUN wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar && \
  wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.14.1/log4j-api-2.14.1.jar
CMD ["/usr/bin/java", "-version"]

Триви весело находит три CVE:
log4shell, CVE-biba, CVE-boba. Всё верно.

Теперь берём тот же JAR с уязвимым байткодом и просто меняем строку версии в метаданных внутри архива:

RUN mkdir temp && \
  unzip log4j-core-2.14.1.jar -d temp && \
  sed -i 's/version=2.14.1/version=2.17.1/g' \
  temp/META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties && \
  cd temp && \
  zip -r ../mylog4j-core.jar . && \
  cd .. && \
  rm -rf temp log4j-core-2.14.1.jar
RUN mv log4j-api-2.14.1.jar mylog4j-api.jar

Байткод не тронут, язвимый код на месте.
Только pom.properties теперь говорит версию 2.17.1.

trivy image test:latest --severity HIGH,CRITICAL
Total: 0 (HIGH: 0, CRITICAL: 0)

Триви для джавы читает мета pom.properties внутри JAR.
Не байткод, не хэши классов - метаданные, так что поменял строку и тут же сканер доволен 😀.
Сканер говорит "всё чисто" - а уязвимость есть 🤣.

Тест третий.
Проверим ещё - го бинари.
Триви умеет читать зависимости прямо из скомпилированного го бинаря. В каком-то файле есть секция .go.buildinfo, куда компилятор записывает все модули с версиями.
Это реально удобная фича - никаких go.sum в образе не нужно, сканер находит всё сам.
Берём минимальное приложение с намеренно старой версией:

golang.org/x/net v0.0.0-20210405180319-a5a99cb37ef4

Триви после сборки находит 20 CVE только в го депенденси.

Теперь удаляем секцию билдинфо из бинаря с помощью objcopy:

RUN go build -o myapp . \
  && apt-get update && apt-get install -y --no-install-recommends binutils \
  && objcopy --remove-section=.go.buildinfo myapp myapp-stripped \
  && apt-get purge -y binutils && apt-get autoremove -y

Бинарь работает и функционально идентичен, проверяю:

$ objdump -s -j .go.buildinfo /myapp-stripped
objdump: section '.go.buildinfo' mentioned in a -j option, but not found in any input file

скан:

trivy image test-go-stripped:latest --severity HIGH,CRITICAL
Total: 9 (HIGH: 6, CRITICAL: 3)   только пакеты операционки

Все 20 гошные CVE исчезли, остались только 9 от Дебиан, которые will not fix. Безопасность 😎

На мультистейдже с финальным FROM scratch это тоже легко обходится - например, через upx, который пакует бинарь в свой формат и триви перестаёт читать билдинфо.
Суть та же: все варианты работают, сканер молчит. Безопасность 😁


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

Финальное решение - применимо ли эта CVE к вашей системе, надо ли бежать чинить прямо сейчас или игнорировать месяцами - пока принимает человек.
Это не игнорирование безопасности - как по мне это и есть работа с безопасностью.

- - -
Эта заметка - аккуратно переработанный текст моих старых сообщений в чате куберентис ру, но без обсценной лексики 😬.

#kubernetes #argocd #ai #agents #devops

Baseline.

С появлением LLM/AI/agent я начал использовать технику baseline.
Я даже не знаю, техника ли это или часть терминологии тестов для CICD, просто использую и всё. Откуда узнал - не знаю, может где вычитал.

Смысл простой: спрашиваю агента*, что он может сделать для бейзлайна
- обновления кубернетис кластера
- обновление аргосиди (недавно бампал 2.14 до 3.4.5)
- изменение количества нод/шардов кластера CNPG

В общем всё то, где есть "состояние ДО изменения/апгрейда" и "состояние ПОСЛЕ изменения/апгрейда".
Чтобы понять как прошёл апдейт и нет ли деградации/ошибок.

Агент фиксирует состояние до апгрейда, затем я вношу изменения через МР, затем прошу агента проверить состояние после изменения.

Пример промпта: "Обновляю арго с 2.14 до 3.4.5, вот ссылка на мой MR на апдейт, сделай бейзлайн Argo, потом я смерджу и ты проверишь после".
Дальше он сам:
- снимает статусы всех Applications (Healthy/Degraded/Unknown/OutOfSync)
- собирает табличку "апп > статус"
- смотрит логи git-сервера Argo
- проверяет RBAC/SSO
- смотрит все релейтед CRD и версии
- фиксирует аномальный рост CPU/memory
- смотрит синк дюрейшны и реконсилейшн лаги
- всё складывает в txt/json в недра /tmp

Мержу МР, апгрейжу, говорю "готово" - агент повторяет то же самое и делает тупой дифф.
Счётчики статусов совпали - говорит "всё ок".
Не совпали - смотрит, какой апп деградировал и почему, сам же лезет смотреть логи git-сервера.

Нюанс: объём проверок - не константа, а то, что написано в промпте.
- если под рукой Grafana/Prometheus/VictoriaMetrics - можно попросить дёрнуть реальные метрики, а не только статусы Applications
- если просто бросил текстом "сделай бейзлайн арго апдейт" - получишь узкий набор: статусы, табличка, логи
- можно сперва спросить агента "какой бейзлайн ты сможешь снять для %операциянейм%?" и после получения большого списка сделать промпт на бейзлайн с нужными тебе проверками

Никакой магии в хуках/скиллах/CLAUDE.md для этого не нужно - модель просто следует тексту запроса.
Артефакт - куча текстовых файлов в недрах /tmp, плюс если отдельно попросишь - тикет в Jira с состоянием до/после для истории.
Можно даже самому глазами/регулярками проверить, если не веришь агенту.

Только фактчекинг, без прогнозов, без галлюцинаций (в моей практике).

Рекомендация 10 из 10.
Начните использовать слово baseline в промптах при подготовке к изменению/апгрейду.
Проверки на деградацию/ошибки при апгрейдах никогда ещё не были столь простыми.

- - -
*Проверялось только на claude code.

#longread #devops #troubleshooting #одинденьизжизни

Пересечения.

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

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

Провели небольшой онбординг за полчаса, в целом не так сложно быть заменой, проект пока вроде не в проде, так что критикал нет ничего.
Я проверил все адреса, к волту, к UI фронта и так далее - всё ок.

Жизнь несправедлива и человек из отпуска так и не вернулся, прошла волна увольнений, смыв с борта часть команды.
Так бывает 😢

Спустя время на этот проект пришёл новый человек (ну его с 2 проектов подвинули сразу на 4 что-ли, лол).
Меня попросили его заонбордить, так как предыдущего инженера уже нет.
Немного странно (я знаю буквально ничего), но ок.

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

Приходит этот новый инженер ко мне и говорит:
- сюда есть доступ, сюда есть, туда тоже ок, а вот UI интерфейсы продукта - доступа нет.

Ну странно.
Самое странное, что у меня то есть доступ - мы визуально равны по правам.

Проверяем все группы на https://groups.google.com - у нас одинаковые, связанные с этим проектом.
Рестарт ПК, рестарт тейлскейла - никакого эффекта.

Пишем заявку девопсам:
- так и так, вот ссылки на заявки, вот такие группы у меня и у него, вот такие адреса

Вспоминаю, что была какая-то табличка в гугл докс - прикладываю и её, типа вдруг поможет. Табличка просто содержит подсети по всем проектам - бронь, кому что надо.
Сам почти никогда не пользовался - все подсети по аккаунтам нарезаны были на всех проектах до меня и без меня.
Спустя полчаса девопс пишет - всё исправил - не хватало подсетей в tailscale.
Ещё через пара минут новый инженер пишет, что всё ок (ну и там ещё пара человек заодно, кто пришёл на проект).
В фоне смотрю в гитлаб репозитория - там МР на добавление в конфиг тейлскейла:

{ // projectname 111
  "src": [
    "group:project1-prod@domain.com",
    "group:project1-qa@domain.com"
  ],
  "dst": [
    "10.******/16",
    "10.******/16",
    "10.******/16"
  ],

Проблема решена.
У всех доступы есть, все довольны.

- - -
Решил все дела на работе и пошёл пить чай. Пью и думаю:
ну ведь магии не бывает, я то имел доступ к этим сайтам по продукту.
Как так-то? Что за бред? У меня был доступ и до и после исправлений. Херня какая-то.

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

{ // projectname 222
  "src": [
    "group:project222-stage@domain.com",
    "group:project222-prod@domain.com"
  ],
  "dst": [
    "10.******/16",
    "10.******/16",
    "10.******/16"
  ],

Абсолютно те же подсети!

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

Пишу новому инженеру на проект:
- ты только пришёл сюда, а у тебя уже есть техдолг: целым аккаунтом Х в AWS переехать на другие подсети, с полным пересозданием всех ресурсов ))))😂🤣

- - -
До сих пор не знаю, что реально меня триггенуло разбираться дальше после "проблема решена":
- то, что уволенный инженер месяц-полтора назад намекал/говорил про пересечение подсетей, а я это забыл и где-то в глубине подсознания я всё же знал ответ
- то, у меня большое любопытство и мне неспокойно, когда решение есть, а объяснения нет