Человек и машина

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

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

#машины_aws Пожалуй, лучший инцидент, что я когда либо видел. Если вкратце: 1. Управление DNS записями для DynamoDB отвалилось, в итоге: 2. Эндпоинты DynamoDB (в том числе для внутреннего пользования) отвалились, в итоге: 3. Storage backend, которым выступала DynamoDB, одного из компонентов control plane EC2 отвалился, в итоге: 4. Отвалился NLB, который не мог следить за событиями EC2. Очень радует, что AWS решил минимальными усилиями решить конкретную проблему, а не сделать отдельный внутренний Kinesis как тогда с инцидентом CloudWatch и Cognito. Да и не пользуйтесь us-east-1, сколько еще повторять. Новые фичи раньше всех того не стоят.

#машины_разное Моя любимая рубрика «Разработчики СУБД знают лучше». Вы наверняка помните, сколько шума вызвало в свое время использование O_DIRECT. Теперь разработчики пошли еще дальше - решили что io_uring для плебеев и сделали свой асинхронный ввод-вывод внутри Postgres. Обожаю 🤤

#пятничное Инженер-программист Шивам Баларани рассеянно смотрел в монитор. Через блеклый интерфейс 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 попрощался с ним со словами: “А ты-то нахуя нужен?”

Вот это я конечно не попал в лимиты телеграма. 🤦‍♂️

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

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

#машины_разное Само понятие «флаг» может произвести впечатление, что это какой-то тумблер «вкл/выкл», который захотел включил, захотел выключил. Самый простой флажок будет выглядеть именно так, но ✨настоящая магия ✨ прячется за условиями выполнения, которые могут быть статическими и динамическими! Давайте на примере расскажу про 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’и с минимальным ущербом для здоровья.

#машины_разное Я думаю, все и так достаточно рассосали падение Гугла, поэтому давайте расскажу в нескольких постах подробнее про feature flag’и, и какие у них есть полезности. Из очевидного - безопасность сервиса. Представьте себе мечту Андрея Синицы DevOps и SRE любителей, где в секунду выкатываются десятки изменений. Если в релизный цикл попадет баг, и нужно будет откатиться, то вы откатите не только свое изменение, но и другие (а там могли быть критические фиксы!), и будете делать это долго: плохие экземпляры потуши, старые релизные подними, трафик перенаправь, а если это делается глобально, то и сам релиз откатываться начнет не сразу (смотря как быстро алерт сработает), да и возвращаться будет долго. В целом запуск бинаря в контейнере даже в самых современных оркестрациях занимает десятки секунд, что непростительно много, а даже самый чуткий алерт выстрелит в лучшем случае через минуту. С флагами вы можете спокойно донести баговое решение до прода и спать крепко - до тех пор, пока флаг неактивен, плохой код исполняться не будет. Более того, выкатку флага тоже можно и нужно контролировать с таким же усердием, как и сам релиз. Например, повесить на флаг те же алерты, что и на сервис, включить флаг для 1% запросов в canary, и смотреть как та пищит. Если у нас выстрелил алерт по SLO доступности, то дело скорее всего в фиче, и система выкатки так же умно его откатит назад. Инженеру остается проанализировать логи, написать фикс и повторить итерацию. Позже расскажу про как флаги позволяют контролировать выполнение кода, но пока поспекулирую, что флаги пропускают либо когда очень спешат (а в нынешней экономике все очень спешат), либо когда риск изменения низкий. А ваш покорный прилично инцидентов просмотрел, триггерами которых являлись «низкорисковые» изменения. :)