#terraform #AWS #IaC #devops

Все мы живём в привычках.
Как однажды научили - так и делаем, словно котики, повторяющие одно и то же всю жизнь.

Учили поднимать руку, чтобы постучать в дверь.
А можно стучать кистью, не поднимая руку.
Мелочь, но никто не задумывается, потому что "так делается".

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

Вот так и в нашем айти.

Когда меня учили Terraform и в проекте были накликанные руками ресурсы, объясняли процесс примерно так: пишешь код ресурса, потом идёшь на registry.terraform.io, находишь нужный ресурс, листаешь вниз до секции Import - там написано в каком формате передавать ID (у каждого ресурса свой синтаксис, угадай с первого раза).
Потом идёшь в AWS консоль за нужным ARN или именем ресурса. Возвращаешься, запускаешь команду:

terraform import aws_iam_role.eks_node_role eks-node-role-production

Делаешь план, убираешь дрифт. Следующий ресурс - снова на сайт, снова читаешь синтаксис, снова в консоль за ARN:

terraform import aws_iam_role_policy_attachment.eks_worker_node_policy \
  eks-node-role-production/arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy

И так для каждого накликанного ресурса, по одному.

Ну я как обезьянка и повторял.
IAM роль? terraform import.
Политика? terraform import.
Node group? terraform import.
Пять ресурсов - пять итераций, пять заходов на сайт.

Оказывается, с Terraform 1.5 (лето 2023, и да, я снова не знал 🚬) есть блок import прямо в коде.
Без отдельных команд.
Без итераций.
Без "а я точно не забыл что-то запустить".

import {
  to = aws_iam_role.eks_node_role
  id = "eks-node-role-production"
}
resource "aws_iam_role" "eks_node_role" {
  name = "eks-node-role-production"
  ...
}

import {
  to = aws_iam_role_policy_attachment.eks_worker_node_policy
  id = "eks-node-role-production/arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
}
resource "aws_iam_role_policy_attachment" "eks_worker_node_policy" {
  role       = aws_iam_role.eks_node_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
}

Запускаешь обычный terraform apply - он сам всё импортирует.
Это в коде, видно в PR, и при потере стейта не нужно вспоминать, что и как импортировать.
Документация прямо внутри конфига.

Import block не избавляет от необходимости знать ID формат, он просто убирает CLI-танцы.
Важно: import block выполняется только если ресурса нет в state.
После успешного импорта его можно удалить - он больше не нужен.

А если совсем не хочется писать конфиг руками - можно ещё и сгенерировать его через

terraform plan -generate-config-out=generated.tf

Так и живём.
Срываем саморастворяющуюся плёнку с капсул, хотя давно этого делать не нужно.

#devops #linux #security

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

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

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

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

#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, сорян, чисто инженерный документ для инженеров про кубы.

#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 😬

#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 с тех пор так и живёт ровно одна версия питона, вот эта.
Почему? Да хер его знает, не удивлюсь, если это агент ставил, а я тупо копипастил.🦍

- - -

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

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

#devops #ai

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

Почитал что сейчас есть, посмотрел на модели, харнессы, потыкал всё мышкой. Остановился на Open Interpreter + Ollama + qwen3.5:9b.
Звучало просто, логично и работало в голове идеально.

Запустил установку.
Прошло 25 минут.
Висит, гнида. Начинаю разбираться.

Оказывается TUI завис на онбординге с пустым экраном и жрёт 98% CPU в бесконечном рендер-луп. 🤡
Убил, запускаю снова, указываю модель.
Модель не найдена.
Потому что новый standalone использует опенаи респонс апи, который ollama не поддерживает.
Хорошо, ставлю питон-пакет.
Не собирается какой-то tiktoken - python 3.14 слишком новый для pyo3 0.20.3.
Переключаю на 3.12.
Устанавливается. Запускаю - запускается старый standalone из ~/.local/bin, который раньше в PATH. Да бл.
Убираю, запускаю снова.
Падает с pkg_resources not found.
Откатываю setuptools ниже 71 версии.
И так ещё полчаса-час сношений вприсядку в противогазе в гамаке.
В итоге заработало, фуф.

Отличный онбординг для тех, кто хочет в агенты, в первый раз питон и "просто попробовать". 😀
Депенденси хелл на каждом шагу, три конфликта версий, два разных бинаря в PATH и одна пустая туи которая молча жрёт процессор.
Сделано збсь, ставлю класс. 😬

Ладно, поныл и хватит.

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

Для конкретно меня, конкретно моих задач, моих хотелок, моих требований и ожиданий.
- всё, что ниже 9В, выбрасывать в помойку
- 9B-30B вполне годный локальный автономный неторопливый агент для рутинных микро задач
- 30В+ потребляет слишком много ресурсов, где-то на грани "братаааан, а нужно ли тебе оно? может лучше сабскрипшн клауд за пять баксов в месяц?"
Выше не тестировал.

Пока оставил qwen3.5:9b.
Он, конечно, ну ннннннннникак не может сравниваться с любой облачной моделью, это просто бессмысленно даже думать о сравнении.
Для хоум фан-задач очень даже ок.

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

Погонял полуавтономно несколько дней - ну ожидания совпали с реальностью.
Пока очень доволен.

Оба агента назвал Бабушка и Вахтёр.
Неторопливые, словно старички, но исправно делающие свою простую работу.


Кому делать нехер, вот ссылки:
- https://www.openinterpreter.com/docs/terminal/quickstart
- https://ollama.com/library/qwen3.5
- https://pi.dev/
- https://github.com/nousresearch/hermes-agent

#всратость #devops #ai

Очередные размышления.

Мы автоматизировали общение и написание кода, но не процессы

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

Однако никто не рассказывает "а чо по процессам?".
Я чот не вижу, чтобы кто-то транформировал процессы.
Во всяком случае у нас на это забили болт, как мне кажется.

Пример:
прилетает девелопер, пишет "не работает релиз в прод".
Стоп. Не так.
А, мы ж теперь ЗА ИИ ТРАНСФОРМАЦИЮ!

12:28 прилетает мне в слак сообщение, клодом написанное, с красивым форматированием и полной подробной информацией, что перестал работать релиз в прод. С путями, текстом ошибки, предполагаемой проблемой.
12:35 мой агент агента агента агентный агент пишет в ответ "Спасибо за обращение! сейчас вернусь с обеда! Сделаю!" обратно в слак.

пу-пу-пу

13:22 возвращаюсь к лэптопу, ныряю в проблему при помощи Claude code ненаглядного, запускаю несколько mcp и cli tools, дергаю там skills, получаю reports - все по ии-трансформационному!
13:28 понимаю суть проблемы с пруфами: argocd не может синкнуть git репозиторий - протух токен, при помощи которого он обращается для гит пулл синка
13:36 при помощи клода пишу и отправляю не менее красивое отформатированное сообщение в слак канал для девопс команды "парни, проверьте, плиз, в этом проекте/группе есть ли деплой токены? не протухло ли чего?" - планируя, что следующим вопросом попрошу просто рефрешнуть

а никто не отвечает

13:41 агентный агент пингует devops duty дежурного в треде "хелп спасити памагити"
13:52 девопс отвечает мне, что "PAT у нас почти год уже нет, токенов у тебя тут нет"
13:53 агент быстро делает ресёрч, говорит пойдем посмотрим что за токен, иду в волт сам, копирую токен - а там, мать его, glpat- и правда персональный токен. Ну, вероятно, кто-то это сделал год назад, пока было разрешено и это попало в прод и так работало год".
14:04 сам пишу девопсу "можешь ли ты создать токен новый?"
14:08 получаю ответ "мы не создаем/менеджим токены, расскажи свою боль и мы поможем тебе"
14:13 пилю кулстори с подробным пояснением, что тупо токен протух и все подробности проекта/путей и тп

тадам

15:24 отвечают мне, что могут запилить ssh key, есть ли у нас сервис аккаунт?
15:25 разбираюсь чо там настроено (я не основной инженер на этом проекте)
15:35 честно отвечаю, что меня устроит любой ПРОСТОЙ и БЫСТРЫЙ вариант без переделок, вообще любой вариант устроит, хоть деплой токен на 7 дней - за неделю успею переделать все нормально по любым вашим требованиям, мне лишь бы прод поднять
15:41 мне делают деплой токен - с временем протухания, а так же сервис аккаунт без времени протухания и кладут логин/токен в Vault. Два варианта - что первое подойдёт.
15:42 я руками, не доверяя агенту, делаю патч externalsecret, добавляя туда новый логин и новый путь до токена, дергаю форс-рефреш экстерналсекрет, патчу арго аппликейшн на ре-синк - всё руками в терминале
15:45 - сервис задеплоен, проблемы нет, синк работает
15:46 - агентном создаю в беклог таску, чтобы терра модуль аргошки поменять на новый формат логина/пароля с новыми путями в волте

Бл, ну камон.
Два девопса* два часа решают проблему протухшего токена, ну камон.🤡🤡

Итого: 6 минут на диагностику, 2 часа на согласование токена, 4 часа невозможности задеплоить релиз от момента обнаружения проблемы до фикса.

Много вопросов, мало ответов**:
- почему сразу не дать право создавать деплой/сервис-аккаунт с токеном? В чём проблема? Чем помогает такой вахтеризм?
- в чём проблема быстро выдать PAT на 7 дней с техдолгом переделки вместо двух часов пинг-понга? Мы прод, бл, чиним, алё, ребята.
- мы всё автоматизируем, но час можем не отвечать в слаке. Кто тогда отвечает за аптайм?
- где алерт на экспайред токенов? Где борда?

ИИ инструменты реально помогают
- диагноз за 6 минут это предел мечтаний пару лет назад
- красивенькие понятные сообщения в слаке, чтобы любой быстро понял суть треда

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

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

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

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

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

#apple #devops #tools и снова #всратость

Деградация и вайбкодинг.

Не так давно я пересел на новые для себя вещи:
- раздельная клавиатура (там ничего нового, минимальные различия с обычной клавиатурой)
- для редких случаев отдельный magic touchpad
- макбук
- дополнительный большой монитор

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

К сожалению в макбуке нет многих очевидных вещей, которые хотелось бы видеть.
Каждый раз надо что-то менять в настройках через терминал, то ставить какие-то утилиты.
Работа с окошками - rectangle.
Биндинг клавиш - Karabiner-Elements. Особенно спасает с проклятыми раскладками в ЕС (Германия).
Менеджер пакетов - Homebrew.
Ланчеры типа Raycast.
Ну и так далее, ну в общем штатно мак ну не совсем готов для работы инженера.

И так я привык к этому, что изначально воспринимал, что "в маке многого нет".😬

Идём к моей микрозадачке.

Все стандартные шоткаты всем известны:
- command+tab - между самими программами
- ctrl+tab - между табами внутри программы
А вот если, например, открыто несколько VSCode или несколько окон браузера Кром - такой комбинации нет.
Мишн контрол тут мне просто не очень подходит с дополнительным монитором.

Мне сперва показалось "да кому это надо", но нет, у меня несколько окон браузера открыто - от MCP Developer Tools для разработки до браузера для себя. Редактор кода - под каждую репу (да, иногда мне так удобнее, чем флипать воркспейсы). Такая же фигня с terminal раньше была (сейчас с cmux неактуально).

Что сделал я? Конечно же спросил какую-то нейронку (не помню уже кто) - какая есть для моей задачи утилита?🤡
Нейронка честно выполнила свою работу и сказала, что есть крутой проект - reef.

Они взяли и навайбкодили (я уверен) новый продукт.
- https://getreef.app/ (тут попросят денежку, но можно поставить 0)
- https://github.com/gouwsxander/reef (сразу бесплатный архив)
Не пересекаются по логике и хоткеяи с ректанглом.
В общем одни плюсы.

Как это работает:
- просто качаешь и ставишь программу
- затем в самой программе биндишь цифру 0, например, на VSCode
- открываешь свои 15 VSCode
- жмёшь ctrl+0
- появляется прозрачное окно посредине экрана и выбираешь нужный экземпляр
- всё

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

Сижу, значит, уже почти привык к новой утилите и работе, решил затащить статью для моих читателей.
Пишу всё это и думаю, а что у них ещё есть.
Поиск выдал замечательный ролик на ютубе, с чего всё начиналось.
Где, собственно, у автора такие же мысли/проблемы возникли с окошками
https://www.youtube.com/watch?v=niRCi5zJvHU

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

И тут мои глаза цепляют комменты к видео..
Господи, стыд-то какой.🤡🤡🤡🤡🤡

Оказывается всё в маке есть для этой задачи.
- command + ` (ноут из Германии, на США раскладке вроде command + >)
- ctrl + стрелка вниз

Прикиньте какая у нас меня сейчас деградация.
- двое ребят пилят целое приложение, потому, что не захотели ПОГУГЛИТЬ блд
- я, пользуюсь ответами нейронки по изначально неверно составленному запросу (утилита, а не нативный шоткат), ставлю этот софт и занимаюсь никому не нужной настройкой.
Ну не жопа ли.

Да, конкретно их софт поможет, если открыто 50+ программ с 10+ реплик каждый, но у меня такой задачи и не стоит, лол, мне между 2-3 флапаться.
Ну или нужен строгий альттаб шоткат на конкретное приложение.
Потому пока себе его оставил, вдруг для некоторых случаев нужно будет 😬

Что наш ждёт через лет пять.. 🫣

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

#devops #troubleshooting #opensource

Понадобилось мне тут на работе проверить есть ли троттлинг ЦПУ.
Причём без создания, тупо взять квери, проверить в explore на графане с датасорса виктории метрикс и всё.
Это новый проект, там ещё обсервабилити не готов, мне чисто проверить.

Зашёл я на свой любимый сайт, откуда пиз ворую алерты
https://samber.github.io/awesome-prometheus-alerts/rules/

А там красота - всё зарефактили, всё по-другому.
Зашёл в раздел кубера - а там этого алерта нет.
Command+f тоже не находит по ключевым словам.
Поискал на главной - тоже нет.
Самая большая тупость рефакторинга - нет поля для поиска по сайту.🚬

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

И тут мне стало интересно, а чо поиск не показывал? Чего поиска нет на сайте.
С плейврайт я уже работал, а теперь захотелось поработать с аддоном для браузера Крома.
https://github.com/ChromeDevTools/chrome-devtools-mcp

В конфиге MCP серверов это всё выглядит просто

    },
    "chrome-devtools-my": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--autoConnect"
      ]
    }

Со стороны браузера Кром надо просто галочку включить

chrome://inspect/#remote-debugging

Как это работает в двух словах:
- запускаю клодкод в терминале
- прошу чот проверить/поменять
- включаю галочку дебаггинга в браузере
- клод спрашивает разрешения, открывает либо отдельную сессию/профиль браузера, либо в моей же сессии (смотря как настроить!!!). У меня это отдельная сессия-профиль, Он открывает вкладку, спрашивает разрешение на управление браузером и работает
- сам через нативный developers tools видит ошибки в консоли, в нетворкинге, латенси запросов, все url бэкенда и всё!
- делает виртуальные скриншоты, ищет поля, и исправляет поля
- он буквально за меня кликает все элементы страницы и видит весь дебаг
- галочку потом можно снять для успокоения паранойи

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

Прошу запилить МР на гитхаб с минимальнейшими исправлениями и скриншотами "до/после".
https://github.com/samber/awesome-prometheus-alerts/pull/590

На выходных автор смержил, правда потом поправил поиск - не в центре экрана, а аккуратнее в углу справа.

Итоги:
- поправить простые(!) фронт штуки с помощью нейронки, Кром браузера и мсп девелоперс тулс - достаточно легко в 2026. QA, фронтенд - тут не нужны😢, можно самому делать мелкие исправления БАГОВ. Фичи пилить я бы не решился.
- по токенам подобные мелкие штуки недорогие - специально посчитал, около 7000 токенов вышло
- девелопертулс мне понравился больше, для дебаггинга он прям топ
- для СЕБЯ(!) я определил так:
- - - https://playwright.dev - автоматизированные тесты, кросс браузеры
- - - https://github.com/ChromeDevTools/chrome-devtools-mcp - сила в дебаггинге нативного девелоперс тулс
Это похожие, на первый взгляд, инструменты, но с разными задачами как по мне.
- а, ну да, теперь на сайте снова можно юзать поиск и воровать алерты🤡

#devops #troubleshooting #база #одинденьизжизни

Иногда появляются проблемы, которые нельзя быстро решить.
Они неожиданные и вступаешь в ступор "а как какать?".


У нас много подключенных SaaS и интеграций.
Время от времени приходят разные коллеги и просят добавить/обновить DNS записи.
Например интеграция с каким-нибудь chargebee  или hubspot чем бы это не было. Да тысячи их, я даже не знаю чо они делают.

В основном задача состоит из двух типов записи:
- добавить новый CNAME
_E2E2BURMALDADZHIGURDA SOMEDOMAIN.COM
- обновить существующий TXT добавив туда новый хост
"v=spf1 include:outlook.com include:hubspotemail.net include:chargebee.com ~all\""

В общем-то ничего сложного,
Стек на тераформе и легко пилю MR, где добавляю, получаю аппрув, качу в мейн и ..а всё отлично, какие ещё и.

Спустя время прибегают сейлзы/саппорт с большими глазами, говорят не доходят часть почты, а это критикал.
🔥🔥🔥
Бежишь смотришь пайплайн - всё ок, тераформ всё раскатал, валидация прошла, все чеки тоже прошли - всё чисто.
nslookup, dig - базовые привычные команды проверки показывают, что всё ок.

Ну магии не существует, пошли на https://mxtoolbox.com/
Пацаны не даром свою зарплату получают (в отличии от меня, лол), и сайт показывает ошибки нарушения контракта.😞

Ошибка, что адресов уже много и пррривет, RFC, и его лимиты.
Дальнейший поиск меня приводит к неизвестному мне ранее
https://datatracker.ietf.org/doc/html/rfc7208

Оказывается есть лимиты и тут. Сука.

RFC 7208 (спека на SPF) прямо говорит: суммарно можно использовать не больше 10 механизмов, которые дёргают DNS - include, a, mx, ptr, exists, redirect.
И считается это не построчно, а рекурсивно - если внутри одного include спрятан ещё include, он тоже идёт в зачёт. Круто, да? Я сам в охере.

То есть в самой записи можно хоть 100 include понаписать - терраформ смолчит, все валидации пройдут, все провайдеры (клаудфлер в данном случае) скажут ок, MR смержится, ревьюер поставит approve, всё ок. Даже на клаудфлер появится. А хлебнёшь ложку говна уже на проверке письма: получатель досчитывает до 10го lookup и такой "аригато, дальше не считаю" - permerror. Причём не сразу и не у всех - где-то письма улетают в спам, где-то тихо дропаются. Полный рандом, сука. Предполагаю из-за разных политик корректных МТА.

Ок, причину мы нашли, быстро ревертаем коммит, проверяем через https://mxtoolbox.com/ и нам показывают, что всё хорошо.

Ок, мы вернули как было, успокаиваем продажников и саппорт и думаем - "а как быть дальше?" Задачу надо решить.

Вот так сходу есть две мысли
- узнать каким-то образом - все те SPF записи в TXT нужны ли нам - не можем ли мы что-то удалить, чтобы добавить нужное? 😏
- как-то эээ по сабдоменам уровнем ниже разнести записи, ну типа того

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

К счастью в этом случае нашли 1 запись, которая 100% не нужна и больше не используется, дропнули её и добавили новую по задаче.

Как быть при следующем добавлении следующей SPF записи и все они нужны?
А хз, я там уже не работаю 😬

Я и правда честно - не знаю, варианты те же в голове:
- развести интеграции по поддоменам со своим SPF (типа mail.PARTNER.SOMEDOMAIN.СOM), а не тащить всё в основной домен
Тогда, предполагаю, каждый поддомен считает свои 10, а не делит один лимит на всех, но это надо проверять.
- завести привычку прогонять запись через mxtoolbox перед каждым новым includ
- тупорылые танцы со статикой IP, но это статика, шанс инцидента при смене адреса возрастает в 10 раз

Итоги:
- иногда подстава откуда не ждёшь, никакие штатные валидаторы тебе не покажут потенциальную ошибку. В этом случае нам даже впаяли инцидент 😔
- RFC это боль, сколько раз я уже в своей практике упирался в какие-либо лимиты
- если бы не гит-блейм по таскам - чистили бы SPF вслепую.
Инвестируй в IAC - трейсинг "кто и зачем добавил" окупается на все 100% ровно в такие моменты. Git+IaC=❤️

и да, иногда никакого куберентиса 😀

#ai #devops

Раз в 2-3 недели гоняю команду
/insights
в claude code.

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

Отдельно подскажет, чем обогатить CLAUDE.md, как лучше структурировать контекст, где утекают токены и время, и какие паттерны повторяются из сессии в сессию, какие скиллы новые запилить на повторяющиеся задачи.
Научит новым промптам.
Подсветит боли и фрустрации как на скрине 😀.

Смотрю, где стал лучше, где наоборот деградировал, и по итогу подкручиваю промпты, сетап и подход к работе.
Реально держит систему в тонусе, а не работу по инерции.
Если с английским не очень - гугл-переводчик отчёт нормально осилит.

Рекомендация - 10 из 10.

Для кодекса и курсора есть НЕ нативные аналоги, но я сам их не тестировал, лишь видел в чатах обсуждение:
- https://github.com/tim-hilde/opencode-insights
- https://github.com/rapidrabbit76/OpenCodeInsights


- - -
Всегда стрёмно такое постить - сейчас вокруг все дохера умные, что ни напиши - "я и так знаю".😬
А простейшая нативная фича - никто не в курсе среди моих знакомых (на работе, я уверен, все в курсе).
Тонкая грань между "база-базная" и "о, а я не знал" 🦍

#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 переехать на другие подсети, с полным пересозданием всех ресурсов ))))😂🤣

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