🎤 Вчера читал доклад об опыте патчинга Django Makemigrations Command для обеспечения консинстентного перехода состояния схемы БД в подходе Blue-Green Deployment на Moscow Python №107
Спойлер: Не пишите костыли, процессы рулят!

Пока готовлю пост с полезными материалами для подготовки к докладу приглашаю вас посмотреть на то - как это было 🔥

✍️ В конце доклада обещал выложить материалы, которые использовал при подготовке
Здесь собраны как ссылки, на которые я ссылался в презентации, так и те, что в целом помогают лучше понять проблематику и возможные способы ее решения. Разбил все по смысловым блокам

🔁 Прямая и обратная совместимость:

Это база, собственно, чтобы проблему решать сначала необходимо проблему понять
- Базовая терминология и правила от Yandex
- Хорошее объяснение проблемы обратной совместимости с Habr
- Классическая статья Роберта Якоты о совместимости на примере JSON схем
- Expand and Contract Pattern
- Практическая модель сохранения совместимости схемы базы данных

🔵 Blue Green Deployment:

Ссылки для понимания самого подхода. Из этих статей брал визуализации и перерисовывал их для доклада в DrawIO
- Ссылочка на Medium
- Ссылочка на Semaphore

🐤 Canary deployment и другие стратегии:

Когда нужно не просто выкатиться без даунтайма, а контролировать риск и blast radius.
- О различных политиках деплоя по-частям
- Здесь же упоминания A/B тестов и Feature Flag's как альтернативные способы ограничивать влияние изменений
- О Канареечном релизе

🧩 Django Issue:

Issue 470, на который я ссылался в докладе. По сути крик сообщества с просьбой расширить фреймворк и вернуть разработчикам контроль над инкапсуляцией.
- Django Issue №470

🪦 Кладбище GitHub:

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

Сюда же положил репозиторий со своим решением
- Репозиторий три

📚 Дополнительные ссылки с Habr:

Дополнительные полезные материалы для погружения в проблему
- Еще раз о различных стратегиях деплоя
- Еще раз про Blue Green Deployment от Otus

🔐 End-2-End:
Большинство из перечисленных ссылок могли бы сэкономить команде кучу часов разработки. По мере изучения материалов становится ясно, что проблема стара как мир, а основные решения давно описаны и разобраны. Но кем бы мы были, если бы не находили некоторые грабли самостоятельно

🍕Когда большой выбор мешает заказывать еду

Обычный вечер
Ты возвращаешься с работы - уставший, выжатый и, конечно же, голодный
Открываешь приложение доставки и тебя затягивает в выбор - десятки категорий и сотни позиций

Начинается скролл:

- «Пицца или роллы?»
- «Может вок?»
- «Или вообще суп?»

Каждый новый вопрос не приближает к решению, а только откладывает его

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

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

Но нас волнует конкретный сценарий
Когда человек заходит заказать еду. Самая короткая воронка тут простая:

Открыл приложение -> Посмотрел меню -> Добавил в корзину -> Оформил заказ

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

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

Пользователи теряются и уходят туда, где выбор проще и однозначнее

Один бренд, Одна категория, Одно решение

➡️ Это хорошо описывается тем, что называют парадоксом выбора
Когда вариантов слишком много, решение становится тяжелым

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

💡В итоге мы пришли к идеи - AI Асситент
Как способ помочь пользователю сделать выбор, пользуясь человеческим языком

Этот пост я написал, пока готовлю материал про первый A/B эксперимент с ассисентом, наши пользователи уже тестируют новый функционал!

Дальше - про гипотезы, эксперименты, RAG и ADR, метрики и результаты
И, пожалуй, самое интересное в этой серии - я сам пока не знаю, куда она нас приведет

Но точно знаю одно:
Дорога появляется под ногами идущего

☕️ Вчера был на мастермейнде в формате «AI Завтрака», организованном в небольшой кафешке на Петроградке
Тема встречи: «ИИ в бизнесе - инструмент роста или дорогое развлечение?»

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

За столом - юристы, серийные стартаперы, фаундеры, дизайнеры, операционные менеджеры. Каждый пришел со своими кейсами и запросами на внедрение AI для решения задач в своей сфере

⚖️ Юристы обсуждали, что в российских реалиях автоматизация возможна глубже, чем в Европе или Штатах
Идея показалась интересной, стоит копнуть глубже. Гипотеза в том, что там система держится на прецедентной практике. В России же до 90% процессов типовые и могут решаться умными шаблонизаторами на базе ИИ

🎨Креативщики активно обсуждают направление «нейрофотографии» - то ли как ответвление существующей профессии, то ли как рождение новой. Главное - не спорят, заменит ли их ИИ, а обсуждают, как использовать его здесь и сейчас в креативе

🙎‍♂️Менеджеры и управленцы смотрят шире.
Они почти не говорят про ускорение, скорее про то, что меняется сама структура управления с помощью ИИ. Пока все радуются технологиям на базе MCP и агентских систем, которые позволяют формировать запросы к БД человеческим, а не SQL языком. Если часть решений можно делегировать системе, меняется роль руководителя. Самый осязаемый кейс - автоматизация страхования контейнеров в портах Санкт-Петербурга. Я живу в этом городе и даже не слышал о таком применении ИИ в жизни города

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

• Вам надо менять людей или вам надо менять людей
• Самое важное здесь и сейчас - заниматься просвещением людей. Нести людям технологии, компаниям - решения

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

• Самое важное заниматься просвещением людей

В самом широком смысле этих слов

🔄 A/B тест - это способ измерить влияние изменений на поведение пользователей. Вместо формулировки «перекрасить кнопку» появляется другая - «проверим, как цвет кнопки влияет на метрику через эксперимент»

Раньше мелкие изменения UI мы делали на ощупь. После внедрения A/B тестов начали системно улучшать продукт. Даже простые решения, например перенос строки поиска на главном экране, дали ощутимый финансовый результат

A/B - это не просто «выкатить на часть аудитории». Это механизм измерения влияния изменений. Базовые элементы эксперимента:

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

⚠️ Важно не смотреть в результаты до окончания теста. Иначе возникает риск преждевременных выводов. Не менее важно корректно сформулировать нулевую гипотезу и проверить ее

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

Без A/B тестов отдельные решения в краткосрочной перспективе были бы дешевле. В долгосрочной - выросла бы цена ошибок и значительно просела зрелость продукта и команды

A/B тесты - это способ убрать из продукта мнения и оставить данные. Не «нам кажется», а «мы проверили». В этом и заключается - продуктовая зрелость команды

📝На прошлых неделях готовил заявки для Saint TeamLead и Saint HighLoad

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

🖥 Тема: "Observability за 60 минут". Я думал сделать воркшоп с амбициозной целью - сформировать у слушателей Observability Mindset за 60 минут
Хотел обсудить с инженерами что такое обсервабилити, на чем оно строится и как провести команды через этот путь. И именно здесь я и споткнулся

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

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

😶‍🌫️ Но сама дорога пока что в тумане: Мы видим отдельные шаги, мазками представляем конечное состояние. А вот что между ними - еще только разбираемся

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

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

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

Вы видели окно для обновления секретов в GitLab? Это маленькое окошко, куда даже названия переменных не помещаются. Чтобы не сломать значение, копируешь все в локальный файл, правишь там и вставляешь обратно. И повторяешь этот цикл с десяток раз

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

После основного обновления всегда остаются хвосты. В течение еще нескольких недель, а то и месяцев начинают приходить разработчики/QA и говорит, что на каком-то окружении не работает какая-то интеграция. И каждый раз это ручная работа, без гарантии, что не всплывет еще где-то. Лезешь, сравниваешь переменные с соседними, ищешь, правишь. И такие хвосты тянутся месяцами. Боль

🔄 Продолжаться так это не могло. Эту операционку нужно убирать

Начали смотреть решения и довольно быстро вышли на Hashicorp Vault. Изначально хотели просто объединить в одном месте helm и gitlab secrets, но по факту инструмент оказался гораздо полезнее

💡 Несколько инсайтов:

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

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

Конечно же, не обошлось без сложностей:

• Нельзя обновить одну переменную. Нужно создавать новую версию всего секрета, версий быстро становится много
• Нельзя поддерживать порядок. Vault собирает все в один словарь, переменные лежат в куче, ориентироваться сложнее, чем в аккуратных helm файлах

☝️ На самом деле не так важно, где лежат переменные - если они в безопасности. Важно, чтобы их обновление не превращалось в отдельный сорт страданий для целой команды и не съедало рабочий день