#машины_разное

Рассказал на Tech Internals Conf, он же англоязычная вариация Highload++, про миграции API.

Рекомендуется к просмотру аудитории любой степени подготовки.

#машины_разное

Я думаю, все и так достаточно рассосали падение Гугла, поэтому давайте расскажу в нескольких постах подробнее про feature flag’и, и какие у них есть полезности.

Из очевидного - безопасность сервиса. Представьте себе мечту Андрея Синицы DevOps и SRE любителей, где в секунду выкатываются десятки изменений.

Если в релизный цикл попадет баг, и нужно будет откатиться, то вы откатите не только свое изменение, но и другие (а там могли быть критические фиксы!), и будете делать это долго: плохие экземпляры потуши, старые релизные подними, трафик перенаправь, а если это делается глобально, то и сам релиз откатываться начнет не сразу (смотря как быстро алерт сработает), да и возвращаться будет долго.

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

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

Более того, выкатку флага тоже можно и нужно контролировать с таким же усердием, как и сам релиз. Например, повесить на флаг те же алерты, что и на сервис, включить флаг для 1% запросов в canary, и смотреть как та пищит. Если у нас выстрелил алерт по SLO доступности, то дело скорее всего в фиче, и система выкатки так же умно его откатит назад.

Инженеру остается проанализировать логи, написать фикс и повторить итерацию.

Позже расскажу про как флаги позволяют контролировать выполнение кода, но пока поспекулирую, что флаги пропускают либо когда очень спешат (а в нынешней экономике все очень спешат), либо когда риск изменения низкий. А ваш покорный прилично инцидентов просмотрел, триггерами которых являлись «низкорисковые» изменения. :)

#машины_разное

Само понятие «флаг» может произвести впечатление, что это какой-то тумблер «вкл/выкл», который захотел включил, захотел выключил.

Самый простой флажок будет выглядеть именно так, но ✨настоящая магия ✨ прячется за условиями выполнения, которые могут быть статическими и динамическими! Давайте на примере расскажу про Configuration Driven Development (далее CDD).

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

Самый простой флаг, который определяет какой адрес базы дать на базе энва будет таким псевдокодом на YAML:

default: prod-db
flags:
- test:
if:
- env = testing
then: test-db
- prod:
if:
- env = production
then: prod-db

Опытный инженер увидит подозрительное default, которое может нагнать страх, и этот страх вполне оправдан. Выбирая между «передаем по умолчанию прод, и возможно не тот енв получит доступ» и «передаем null, и приложение упадет», я бы выбрал второ- исходя из ситуации.

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

default: prod-db
flags:
- test:
if-one-of:
- env = testing
- req-tenancy = test
then: test-db
- prod:
if-one-of:
- env = production
- req-tenancy = prod
then: prod-db

А что, если нам нужно обеспечить теневой трафик, который живет в рамках теста, но нуждается в "живых" данных? Тогда можно использовать использовать логическое умножение:

default: prod-db
flags:
- shadow:
if-all-of:
- env = testing
- req-tenancy = shadow
then: prod-db

Тут вы наверняка скажите: «Карен, ты упоролся, connection string к базе инициализируется на старте приложения, а ты предлагаешь это делать на каждый запрос?!», а я вам отвечу: «Не душните, взял самый наглядный пример, чтоб всем было понятно!»

У CDD очевидно есть и бизнес применение, например решать в какой PSP передать платеж на базе параметров платежного поручения. Представьте себе такое:

flags:
- dest1:
if-all-of:
- country-code = BR
- payment-method = payment_card
- card-type = debit
then: psp1

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

Я не зря оговорился о разношерстных параметрах, ведь диверсификация параметров это необходимая составляющая экспериментов!

У вас бывало такое, что вы запускаете любое мобильное приложение, а оно ПОЧЕМУ-ТО ведет себя иначе? А потом точно так же ПОЧЕМУ-ТО ведет себя как раньше?

Это означает, что вы попали под эксперимент. Эксперименты это целые наборы флагов, которые принимают в качестве параметров… да вообще что угодно, от страны и устройства до пола, возраста, и последних 10 пролайканных фоток. Эксперименты проверяют жизнеспособность фич и их полезность, поэтому ставятся на длительный период и измеряют бизнес метрики навроде конверсии. Если цифры идут вверх, расширяем поле экспериментов дальше, пока не уйдем на 100%.

Платформа экспериментации - красивая обертка над системой конфигураций, feature flag’ов, мониторинга и механизмов раскатки, и стоит на вооружении у всех больших дядечек и тетечек.

В следующем посте постараюсь собрать для вас подходящие инструменты, с которыми вы можете использовать feature flag’и с минимальным ущербом для здоровья.

#машины_разное

Итак, я хочу управление конфигурацией отдельно от кода, желательно с поддержкой код ревью, работающее на любой платформе. Я сразу отбрасываю GO Feature Flag (хотя задумка прикольная), и останавливаю свое внимание на Unleash, Flagsmith, Flagr и Flipt. И тут начинаются дурацкие компромисы.

Код ревью есть только у Flipt. При этом все они предлагают инкрементальную выкатку с ограничениями (“Включи эту фичу для владельцев айфонов с новым прикольным стекляным иосом.”), но Unleash предлагает еще и концепцию strategy. Глядя в доку, это все еще выглядит как набор ограничений, где мы передаем параметры навроде клиента, пользовательского идентификатора и так далее. Зачем тут было выпендриваться - непонятно.

Все варианты интегрируются с мониторингом по-своему, а точнее никак. Например прикрутить график из Графаны к интерфейсу feature-flag’а чтобы наблюдать за метриками во время релиза нельзя. Но зачем-то можно экспортировать метрики самих управлялок, например активацию/деактивацию флагов - но я бы это делал через само приложение.

Отдельно стоял вопрос доставки конфигурацией на клиент, это важный аспект с точки зрения производительности. Следите за руками:
1. Нам прилетает запрос, приложение должно решить, включать флаг или нет.
2. Если для этого нам нужно обратиться к серверу - прибавляем еще один запрос на сервер.
3. Пусть каждый запрос на сервер стоит 10 мс - потому что сетевые запросы не бесплатные
4. Если на пути нашего запроса в бизнес логике есть 5 проверок флагов, то мы просто так накидывем себе 5 * 10 мс задержки.
И это не говоря о надежности, потому что SLO нашего эндпоинта будет зависеть от SLO API feature flag’а.

Очевидным решением является кеширование флага на клиенте с проактивным eviction policy - то есть клиент раз в минуту, например, опрашивает сервер и смотрит не обновились ли значения или условия флага, а при выкатке клиент получает нотификацию и обновляет все флаги. Вот тут уже… прям плохо. Все поддерживают polling, Unleash из коробки поддерживает нотификации, которые обновят значение флагов; Flagsmith это делает через webhook’и, но не во всех клиентах это поддерживается; Flagr и Flipt это не умеют вовсе.

А что по платным облачным решениям? Ну тут не то, чтобы прям лучше. Каноничный откат есть только у Kameleoon, он выключает фичу если какие-то метрики выходят за допустимые рамки. LaunchDarkly за каким-то хреном сделали kill switch, который требует ручной активации от оператора. Чем это лучше отката фичи на 0% - непонятно - но разработчики божатся, что это быстрее. Охотно верю.

У публичных клавдиев все еще хуже. Более-менее рабочее решение дает AWS AppConfig - тут тебе и кеширование, и поддержка автоматических роллбеков на базе алертов из CloudWatch. У GCP нет такого сервиса вообще, Azure App Configuration не умеет откатывать флаги.

С локальным кешированием у большой тройки двойки все еще тупее. AWS AppConfig предлагает ставить агента, который будет кешировать флаги, при этом этот клиент может ставиться в качестве sidecar’а для контейнеров и даже Lambda функций. Учитывая, что Lambda должна быстро отработать и умереть, польза от этого sidecar’а только в том, чтобы переиспользовать теплый контейнер с закешированной конфигурацией флагов. Стоит ли в свежем контейнере функции оставлять возможно протухший набор флагов вопрос дискуссионный.

А вот cache eviction на базе обновлений не поддерживает никто, извольте подождать пока таймер истечет. То есть AWS смог в автоматический роллбек, но в server-side events не смог даже при условии, что у них для флагов аж целый агент есть. Пиздец.

Что по итогам?

Если вы только открываете для себя увлекательный мир разработки через конфигурации, используйте Unleash или Flipt, если у вас сильно развита культура код ревью.

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

#пятничное

Инженер-программист Шивам Баларани рассеянно смотрел в монитор. Через блеклый интерфейс JIRA ему в ответ смотрела скупо описанная задача в спринте. Шивам Баларани немного сщурился, наклонил голову набок, скопировал текст задачи и открыл корпоративный ChatGPT в новой вкладке. Включив режим «Deep Research», он начал промпт со словами: «Тебе нужно решить следующую задачу». Вставив текст из JIRA, Шивам добавил уточнящих деталей касательно языка, версии, платформы, зависимостей, и, немного подумав, разрешил ChatGPT придумать собственное решение или предложить уже существующее с открытым исходным кодом на GitHub.

Ответив на уточняющие вопросы, Шивам Баларани оставил нейросеть заниматься своей работой и пошел налить себе кофе. Вернувшись, закончив просматривать мотивирущее видео про образ жизни на Youtube и допив кофе, он вернулся к вкладке с ChatGPT. Компьютер подготовил для него большой и красивый отчет. Шивам бегло пробежался по рекомендациям, с облегчением увидел подходящее, на взгляд нейросети, решение, и скачал все в Markdown файл. Затем он открыл терминал, прошел в директорию с кодовой базой, запустил в ней Claude Code и впечатал следующую инструкцию: “Ты работаешь над фичей и твоя задача написать функцию в директории transformers. Подход к решению описан в документе /home/shiwam/gpt_research.md.”

Нажав Enter, Шивам отправился за второй чашкой кофе. Вернувшись и отвлекшись на социальную сеть X (ранее Twitter) на полчаса, инженер с неудовольствием увидел, что Claude Code набросал черновой вариант кода и ждал отмашки на продолжение. Дав компьютеру добро на проведение дальнейших операций без отмашки в будущем, Шивам вернулся в социальную сеть Х (ранее Twitter). Уже через 15 минут у Шивама был готово рабочее решение. Только он приготовился подключиться к ответственной миссии финальным “git checkout -b jira-123 ; git add . ; git commit -m ‘JIRA-123 Add transformer feature’ ; git push”, как ему в голову пришла идея. Он добавил еще одну инструкцию: “Ты старший инженер-программист и должен провести код ревью изменениям. Обрати особое внимание на согласованность стиля в кодовой базе, организацию кода, читаемость и лучшие практики языка”. Через пару минут, Claude Code переквалифицировавшийся из автора кода в ревьюера, сделал самому себе несколько замечаний. Шивам, заметно уставший к концу дня от дешевого дофамина, ответил ему коротким “apply these recommendations”. Подождав немного времени, он еще раз прошелся по коду и отправил pull request на проверку коллегам.

На следующий день, pull request представлял собой смесь LGTM и различных комментариев тут и там. Шивам Баларани решил делегировать задачу своему нейроассистенту и скопировал каждый комментарий, добавляя к какой строке и файлу этот комментарий относился. Дав машине целевые указания, инженер-программист решил скоротать время в Instagram. Подняв голову через 10 минут, он закатил глаза от того, что Claude Code закончил черновой вариант и снова ждал отмашки пользователя. “Надо настроить авто-да,” - подумал Шивам, ожидая окончания генерации кода. Повторив Git-ритуал, он отписался в Slack канале “addressed” и снова залип в телефон. Через полчаса, когда pull request перешел в состояние Approved, он нажал кнопку Merge, перенес задачу в состояние QA, нанес курсор на кнопку закрытия терминала и нажал на нее. Его насторожило то, что на долю секунды что-то промерцало в диалоговом окне Claude Code. Инженер-программист Шивам Баларани был готов поклясться, что Claude Code попрощался с ним со словами: “А ты-то нахуя нужен?”

#машины_разное

Моя любимая рубрика «Разработчики СУБД знают лучше».

Вы наверняка помните, сколько шума вызвало в свое время использование O_DIRECT. Теперь разработчики пошли еще дальше - решили что io_uring для плебеев и сделали свой асинхронный ввод-вывод внутри Postgres.

Обожаю 🤤

#машины_aws

Пожалуй, лучший инцидент, что я когда либо видел.

Если вкратце:
1. Управление DNS записями для DynamoDB отвалилось, в итоге:
2. Эндпоинты DynamoDB (в том числе для внутреннего пользования) отвалились, в итоге:
3. Storage backend, которым выступала DynamoDB, одного из компонентов control plane EC2 отвалился, в итоге:
4. Отвалился NLB, который не мог следить за событиями EC2.

Очень радует, что AWS решил минимальными усилиями решить конкретную проблему, а не сделать отдельный внутренний Kinesis как тогда с инцидентом CloudWatch и Cognito.


Да и не пользуйтесь us-east-1, сколько еще повторять. Новые фичи раньше всех того не стоят.

#новогоднее

Если бы мне пришлось охарактеризовать 2025-ый год одним единственным словом, я бы назвал слово «принятие».

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

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

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

#прощальное

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