#AI #мысли

Больше года активно использую AI в работе.
Не скрываю, пробовал почти все, от локальных до платных(писал выше и не раз).
Генерация документации, кодогенерация, написание тестов всех типов, авторевью, просто чат и поиск решений.

Все новости "нас заменят AI" читаю пока со скепсисом.
Умные работодатели об AI знают не хуже нашего и они просто начинают оплачивать подписку на AI-tools(CodeRabbit, Cursor IDE etc). Руководители знают, что AI умеют.

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

#пятница #мысли #AI

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

#aws #aurora #eks #troubleshooting #longread

Лонгрид "история одного бага".
Часть 1 из 3.

Веселье.
Жил был стартап. Сперва на пару человек, но уже в облаке.
Пару сервисов в ECS и база MySQL.
Всем было весело и интересно.
Со временем продукт вырос, у него появилось масса нового: новые микросервисы, postgresql(а потом была удалена), Mongo и так далее. Обычный жизненный цикл любого продукта.
Стартап перешёл из этапа pre-seed в seed.
Уже есть реальные живые пользователи, кто реально платит живые деньги за продукт.
Это привело к тому, что на инфраструктуре появилась нагрузка.
Из одноинстансовой базы был совершён переход на cluster Aurora(mySQL compatible), был добавлен RDS proxy(а я не знаю зачем изначально), а ECS заменён на EKS.
На самом деле много всего было сделано, но выходе в проекте был макросервис(наполовину распиленный монолит) монорепы и десятки микросервсов.
Потом пришла series a и клиентов появилось сильно больше.
Пришла НАГРУЗКА.

Масштабирование
Продукт, не смотря на то, что это макросервис и монорепозиторий, научили в масштабирование.
Сперва было тупое через HPA и ресурсы, затем появилась KEDA и продукт научился в масштабирование по количеству сообщений в SQS или лагу в кафка топике. Стало не хватать нод, добавили автоскейлер (впоследствии заменив на карпентер).
Да и в целом было сделано на 99% масштабирование и кластеризация всего и вся.
Где-то на этом моменте продукт начал получать весьма негативные фидбеки "ЧОТА ТОРМОЗИТ ИНОГДА" и команда впервые задумалась о мониторинге.

Observability, v1.
Была добавлена графана для инфры, прометиус в куб и опенсёрч для логов(вообще не связан с историей).
Помимо всей инфры в кубах, начали мониторить и алертить стандартные метрики всех ресурсов Амзаона.
невероятно обширная работа, от 60 дашбордов, больше 400 панелей в графане по всем ресурсам стандартных графиков.
И.. и это ничего не дало.

Не верю.
Команда ничего не понимала.
Да как так-то? Все метрики есть, дашборды украдены из интернетов, но любой случай "ЧОТА ТОРМОЗИТ ИНОГДА" по метрикам и графикам не видно.
Начали копать дальше, читать про базы данных, движки, прокси и многое другое.
Стартап вырос из своих штанишек, надо было пересилить себя и разобраться.
Сложность была в том, что никто не понимал что не так то. Откуда вообще копать.
Так же всё усложнялось тем, что нет времени на раскачку и траблшутинг, проблема возникает редко, а надо пилить новые фичи, люди ждут продукт, как и инвесторы.
Шли недели и месяцы. Многие думали, что это не проблема софта, а проблема Амазон. Не верю, картинно возражали они и шли дальше пилить код.
А затем пришёл series b и пришла даже не нагрузка, а НАГРУЗИЩЕ.
х800 трафик и количество от клиентов от того, что было месяц назад.
Проблема стала так же в сотни раз чаще и пришло время её фиксировать.

Observability, v2.
Команда научилась отслеживать slow logs и реагировать на них.
https://xn--r1a.website/makebreakreflect/33
Есть запросы больше 10 секунд? Изучаем query и катим фикс.
И так до тех пор, пока слоу логи не прекратились.
И.. это не решило проблему.

Кубер/хелм/девопс во всём виноват.
Обратили внимание, что частично проблема повторятся, когда идёт деплой или скейлинг.
Проверили всё, пробы, макссёрж, количество реплик, стратеджи, перешли на KEDA с детальнейшим конфигом, пофиксили пару серёезных багов со стороны не совсем корректной настойки проб.
https://xn--r1a.website/makebreakreflect/9
И.. это не решило проблему.

#aws #aurora #eks #troubleshooting #longread

Лонгрид "история одного бага".
Часть 2 из 3.

Observability, v3
Было принято решение мониторить поэтапно, каждый элемент инфры отдельно, а не комплексно, как это было ранее.
Например не просто "базу", а "базу поэтапно.
Что приходит на приложении при обращении к прокси, что происходит на RDS proxy, что приходит от прокси до БД, что внутри БД. На всё метрики и новые дашборды. Где не было метрик - писали сами.
Часть в графине, часть в CloudWatch, смотря откуда source был или быстрее/удобнее.
Эээ трейсинг мониторинга?
Первая зацепка попалась впервые за много месяцев, когда появился дашборд RDS proxy и там был замечен спайк.
Честно говоря не представляю, кто первый придумал назвать это спайком, но дальше по всем post mortem данный фигурант назвался спайк. Спайк количество подключений клиента к БД. Вместо частых 300-500 спайки доходили до 40000(в зависимости от типа инстанса и от настроек, их меняли часто во время эксплуатации и траблшутинга)
И.. спайки совпали с временем жалоб "ЧОТА ТОРМОЗИТ ИНОГДА".

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

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

Кастомизейшн? v2
Были созданы отдельные RDS proxy endpoint для каждого сервиса отдельно.
https://xn--r1a.website/makebreakreflect/55
То есть каждый сервис со своими подами(независимо сколько их в скейлинге сейчас) подключается через отдельный эндпойнт RDS proxy, с отдельной учётной записи.

Радость, v2.
О чудо, снова закричала команда.
Радость улетучилась раньше, чем прошло эхо от коллективного крика.
Стало понятно, что нагрузка идет только на один определённый эндпойнт, только от конкретного юзера-приложения.
Команда глянула в код и.. это ничего не дало.
Приложением из монорепозитория.
У него буквально 1-2 параметра энтрипойнта других и немного другой функционал.
Сами параметры запуска этого сервиса 100% на влияют на проблему.
Грубо говоря у одного сервиса задача "слушай вебхуки, пушь в базу", у второго "слушай sqs, пушь в базу", а у третьего "слушай кафку, пушь в базу". Всё остальное одинаковое.

Observability, v4
Ок, команда знает про спайк, про нагрузку от RDS proxy от одного сервиса, но откуда оно?
Создаётся ещё несколько новых dashboard, устанавливается Performance insight от AWS.
Команда видит, что есть нагрузка на read/write IOPS область, снова читаются книги, статьи, снова оптимизация кода и инфры.
https://xn--r1a.website/makebreakreflect/115

#aws #aurora #eks #troubleshooting #longread

Лонгрид "история одного бага".
Часть 3 из 3.

Финал. Финал без разбивки.
Понимаю, что вы уже устали читать, но конец близок.
И вот мы приходим к состоянию, что команда видит чуть ли не каждый трейс, обращение, логи, слоу логи, мониторинг базовых сущностей и метрик, мониторинг кастом метрик, всё это обвешано алёртингом, а количество дашбордов больше 50(панелей около 450). Господи, да даже влияние запроса на IOPS видно в аналитике.
Все. Ждут. Проблему.
Создана целая вселенная, как во Black and White и теперь под микроскопом смотрим кто же из наших мелких хулиганит.

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

В саппорте сперва сперва катают как в доте новичка тупыми вопросами категории "вы пробовали выключить и включить", на что сразу получают максимально подробный и отчасти грубый ответ "дайте нам другого менеджера" и сразу переключают на очень умного инженера, явно выше первого уровня технической поддержки.
Он анализирует все десятки скриншотов, логов, аргументов, истории траблшутинга и даёт одну единственную ссылку на документацию и ссылку на логи.
первая ссылка https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-pinning.html
где нас интересует только это
Any statement with a text size greater than 16 KB causes the proxy to pin the session.
А вторая ссылка на логи, которые упустила команда, и где есть чёткое
The proxy can't reuse this connection until the session ends. Reason: The connection ran a SQL query which exceeded the 16384 byte limit.
(это было пропущено при траблшутинге, есть косяк).
Срочный созвон, брейншторм разработчиков за 0.00000001мс, фикс на 2 строчки(ограничение payload).
И.. и проблема ушла.

Итог.
Вот так, в поисках одного бага, который возникал на 1-3 секунды, аффектил всех клиентов, который появился только при нагрузке при росте продукта, позволили потратить больше 11.000 долларов(дебаг, включение фичей, доп услуги, хранение и обогащение метрик, борды, разделение по rdx proxy endpoints и многоие другое), десятки часов траблшутинга, научив всю команду обсервабилити и пониманию КАЖДОГО этапа всех элементов продукта.
Всего-лишь большой payload в базу через прокси.. Всего-лишь большой payload..

*В этой истории упущены ещё два десятка незначительных модификаций, которые либо вели команду не тудла, либо ну совсем ни на что не влияли, а текста отняли бы ещё на пару постов.

#devops

Дотфайлы в репозитории: что, сколько?

В 2025 репо без дотфайлов - как микросервис без контейнера: не взлетает.
Они решают всё: от фильтра мусора до CI/CD и AI IDE.
Сколько их сейчас нужно для стандартного проекта?
5-10 - стандарт для микросервисов.
Меньше - тухло, больше 15 - безусловно перегиб.
Пробежимся по категориям.

1. Игнорирование: убираем мусор
.gitignore - Очевидно, без вопросов. Чистит node_modules, логи, .env. Все знают, что тут.
.dockerignore - Почти все проекты - контейнеры. Фильтрует контекст Docker, чтобы не тащить лишнего. Писал тут https://xn--r1a.website/makebreakreflect/84
.helmignore - Как .dockerignore, но для Helm-чартов. Нужен для репо с чартами или гетерогенных пайплайнов.
.npmignore - Чистит лишнее при публикации npm-пакетов. Только для пакетов.
2. Окружение: переменные
.env - Хранит DATABASE_URL, порты. В .gitignore, без вариантов.
.env.example/development/production - Шаблон(ы) .env для разных окружений.
3. Инструменты: линтеры, форматтеры, хуки
.eslintrc - Линтинг JS/TS. Без него в JS/TS никуда.
.yamllint - Линтинг YAML - K8s, CI/CD. Если YAML много, надо.
.tflint - Линтинг Terraform. Для Terraform-проектов.
.prettierrc - Форматирует код. Почти везде.
.nvmrc - Фиксирует версию Node.js. Для Node.
.huskyrc - Преккоммит-хуки. Автопроверки перед коммитом.
.lintstagedrc - Линтинг только изменённых файлов. Работает с Husky.
.pre-commit-config.yaml - Конфиг для pre-commit. Например запускает линтеры (tflint, ESLint, chehov) перед коммитом. Для автопроверок. Must have как по мне для всех.
5. CI/CD: автоматизация
.github/workflows/*.yml - Пайплайны GitHub Actions. Для GitHub CI/CD.
.gitlab-ci.yml - Пайплайны GitLab. Для GitLab.
6. Тесты и сборка
.jest.config.js - Конфиг Jest для тестов JS/TS.
.tsconfig.json - Конфиг TypeScript. Для TS.
.vite.config.js - Сборка фронта/бэка. Для сложных сборок.
7. IDE/AI IDE: редакторы
.editorconfig - Единые настройки редакторов. Для команд.
.cursorignore - Исключает файлы для AI в Cursor. Для Cursor. Например с локальным .env и паролями.
.cursorrules - правила Cursor IDE
.cursor/rules/*.mdc - Правила для AI Cursor - стиль кода, ограничения. Для Cursor.
.windsurfrules - Правила Windsurf, стиль, ограничения.
.idea/ - Конфиги IntelliJ. Для JetBrains

Так сколько же? Для бизнес аппликейшн среднее значение 6-8:
.gitignore, .dockerignore, .CICD.yaml, .editorconfig, .pre-commit-config.yaml, .IDE.yaml + для стека
Для helm chart 3+:
.gitignore, .helmignore, .pre-commit-config.yaml, .yamllint.yaml
Для terra*/инфры 5+:
.gitignore, .editorconfig, .pre-commit-config.yaml, .IDE.yaml, .tflint, yamllint.yaml

Бежать и пилить все недостающие файлы? Не, конечно не стоит.
Каждый сам должен для себя решить когда и что ему нужно в проектах и постепенно добавлять то, чего не хватает команде и бизнесу. Взросление не происходит мгновенно.
Если не знаете с чего начать, то спросите любую нейронку какие дотфайлы нужны вам для вашего проекта и какой пример содержимого.
В конце концов есть даже генераторы и готовые сборки, например:
https://github.com/PatrickJS/awesome-cursorrules
https://github.com/sanjeed5/awesome-cursor-rules-mdc/
https://github.com/github/gitignore
https://github.com/toptal/gitignore
(искать через "awesome .DOTFILENAME")

У нас уже почти стандарт 7 файлов по минималке везде, кроме хелм чарта.
В монолит монорепе аж 14 дотфайлов. Все в работе.

* Безусловно я мог пропустить часть дотфайлов, либо забыл, либо не работал с ними.
** .CICD.yaml = ямл для того CICD, который на проекте, от трависа до гитхаба/гитлаба.

Update: конечно я забыл про один из главных файлов .tool-versions - просто мастхэв.
Подробно писал про asdf тут https://xn--r1a.website/makebreakreflect/69

#aws #vanta #ai #azure

На этом моём скриншоте прекрасно всё.
Добро пожаловать в 2025 год.

Vanta, компания, которая за огромные деньги позволяет проходить аудит от SOC2 до PCIDSS, при помощи AI генерирует рекомендации с несуществующими ресурсами терраформ.

У меня всё.

#kubernetes

Настройка пула соединений для базы данных в Kubernetes.

А как же правильно настроить пул соединений при работе с приложениями в Kubernetes?
У нас же много nodes, PODs, всё динамически, везде скейлинг количества подов.
Не будет ли проблем с тем, что закончились коннекшны к базе и новые поды не смогут подключится?
Проблемы будут, надо считать.

Для начала нам надо понять какая база данных у нас.
Допустим реляционная база данных MySQL.
В зависимости от железа(CPU/Memory) у нас есть разное значение параметра max_connections
Сам параметр этот динамический, значение можно рассчитать и установить самому, либо взять дефолтное(например в облачной базе данных).
Для простоты расчётов будем считать, что у нас max_connections = 1000. Вы берёте свою цифру своего сервера.
- Первым делом нам надо зарезервировать 5 коннекшнов под административные нужды.
Например в случае проблем у нас будет шанс, что мы(инженеры/SRE) сможем к базе подключение сделать.

max_connections_db = max_connections - 5
max_connections_db = 1000 - 5 = 995

- У нас так же включен скейлинг приложений-клиентов через KEDA/HPA со значениями

min PODs = 2, max PODs = 30.

- Для расчета размера пула соединений на под (pool_size_per_pod) используется формула

pool_size_per_pod = floor(max_connections_db / N)

где N текущее количество подов (2 ≤ N ≤ 30).

pool_size_per_pod = floor(995 / 30) ≈ 33 соединения на под

Можно было бы на этом остановится, но это будет ошибка.

У нас время от времени проходит деплой и поднимаются новые реплики, которые тоже занимают пул соединений.
Предположим, что у нас Rolling Update + maxSurge = 25%.
Это означает, что во время деплоя может быть создано до 25% дополнительных подов сверх текущего количества.
Максимальное количество подов с учетом maxSurge

N_max_with_surge = ceil(N × (1 + 0.25)) = ceil(N × 1.25)

и для худшего случая в режиме максимальной нагрузки N=30

N_max_with_surge = ceil(30 × 1.25) = ceil(37.5) = 38

Тогда размер пула соединений на под с учетом maxSurge:

pool_size_per_pod = floor(max_connections_db / N_max_with_surge) = floor(995 / 38) ≈ 26

Итак, мы получили цифру 26.
Теперь мы можем добавить её в переменные окружения нашего golang аппликейшна.

poolSizeStr := os.Getenv("DB_POOL_SIZE")

и в ваш yaml/values файл типа

env:
- name: DB_POOL_SIZE
  value: "26"

Итого: расчет пула соединений это простая арифметика, которая не зависит напрямую от Kubernetes, но требует учета его особенностей (KEDA, maxSurge, несколько дата центров например - не рассматривал в примере выше). Настройка пула соединений обеспечивает стабильную работу системы без превышения лимита соединений даже при максимальном масштабировании и деплое.
Наш расчёт пула соединений на POD (26) учитывает maxSurge = 25%, KEDA (2–30 подов) и резерв в 5 соединений, гарантируя стабильность системы.

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

#docker #devsecops #paranoia #devops

Что у нас есть в пайплайнах?
Линтер питон скриптов, валидация YAML, tflint для терраформа, checkov для безопасности, git-leaks, sonarqube, скоринг кода, sast, dast и многое другое. Миллионы всего.
Всем и всё это знакомо.

А что по Dockerfile?
Есть великолепный проект для простых проверок:
https://github.com/hadolint/hadolint

Его можно добавить в pre-commit hook
https://github.com/hadolint/hadolint/blob/master/.pre-commit-hooks.yaml
Можно добавить в pipeline.
Что он умеет?
- проверка и анализ Docker на соответствие лучшим практикам
- интеграция с ShellCheck (моя любовь ❤️), но нужно не для всех
- гибкий конфиг через .hadolint.yaml
- поддержка игнора
- интеграция с CICD

Всё-всё, хватит пустых слов, что он умеет можно почитать и в документации, давайте к практике и примеру.

Добавляем его в наш основной канико(да когда ж ты умрёшь?!) имадж, используемый для сборок:

FROM gcr.io/kaniko-project/executor:v1.23.1-debug

ENV TRIVY_VERSION=0.61.0 \
  CRANE_VERSION=0.19.0 \
  HADOLINT=v2.12.0

RUN wget --no-verbose https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}/trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz && \
  tar -zxvf trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz -C /kaniko && \
  rm -f trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz

RUN wget --no-verbose https://github.com/google/go-containerregistry/releases/download/v${CRANE_VERSION}/go-containerregistry_Linux_x86_64.tar.gz && \
  tar -zxvf go-containerregistry_Linux_x86_64.tar.gz -C /kaniko && \
  rm -f go-containerregistry_Linux_x86_64.tar.gz && \
  rm -f /kaniko/LICENSE /kaniko/README.md

RUN wget --no-verbose https://github.com/hadolint/hadolint/releases/download/${HADOLINT}/hadolint-Linux-x86_64 && \
  mv hadolint-Linux-x86_64 /kaniko/hadolint && \
  chmod +x /kaniko/hadolint

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

# Lint the Dockerfile
echo "Executing hadolint check on $dockerfilePath"
/kaniko/hadolint $dockerfilePath --error DL3006 --error DL3007 --failure-threshold error

Что тут проверяем?
- чтобы всегда стоял тег бейз имаджа
https://github.com/hadolint/hadolint/wiki/DL3006
- чтобы тег бейз имаджа был НЕ latest
https://github.com/hadolint/hadolint/wiki/DL3007

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

Ещё один инструмент в нашем бесконечном списке бесконечных инструментов.