Представьте, что вы спрашиваете банковского ассистента про банкоматы в Москве, а он присылает карту Саратова. Или ещё интереснее: официальный бот внезапно начинает отвечать русскоязычным клиентам на латинице.

Это весёлые будни ИТ в банке, где каждый релиз похож на русскую рулетку. Потому что есть один нюанс — у нас нет предпродовой среды. Вообще.

И пока эта проблема не решена, мы живём в очень интересном, мягко говоря, режиме.

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

Мы выносили эту историю на общебанковские управляющие комитеты, стучались к руководству. Но руководство долгое время считало, что предпрод — это какая-то наша прихоть. Их логика проста: «А что? Всё же вроде нормально, ничего не падает... Ну вы же как-то справляетесь! На фига вам ещё какая-то среда?»

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

Как это работает у нас сейчас

Что я вкладываю в понятие предпродовая среда, и почему её отсутствие для нас катастрофично?

Предпрод — это точная копия прода. На ней стоят такие же конфигурации, такие же конфиги, те же версии библиотек. Процесс выглядит так:

1. Мы тестируем фичу на тестовой среде.

2. Прогоняем её на предпроде, делаем регресс, убеждаемся, что на боевой конфигурации всё работает.

3. И только когда убедимся, что на точной копии прода всё чисто, мы катим в настоящий прод.

4. Там проводим финальное smoke-тестирование, чтобы убедиться, что новый функционал работает и, что важнее, старый не отвалился.

А по факту у нас есть только тестовая среда, где мы гоняем функциональные и нагрузочные тесты. Но конфигурации на тесте и на проде не совпадают. Это классика жанра: на тесте всё зелёное, всё прогналось, проблем нет. Раскатываем в прод — и тут же льются ошибки и поломки.

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

В банке вообще есть общая проблема с тестовыми средами: их мало, они есть не у всех. Некоторые департаменты и команды вообще пользуются одной общей средой, делят её между собой, из-за чего возникает куча проблем. Логичного объяснения, почему нам до сих пор не выделили предпрод, я добиться не могу. Руководство то говорит, что это дорого, то — что «не приоритет».

Хотя у нас система класса критикал, она должна быть максимально отказоустойчивой — 98%, а сейчас у нас, дай бог, 70%, что для такой системы очень мало.

Бизнес хочет вчера

Вторая сторона медали — это наши заказчики. У нас есть бизнес-заказчики: цифровой бизнес, розница, юрлица. Там всем рулят продакт-оунеры.

И вот, как оказалось, этим ребятам вообще всё равно, есть у нас предпрод или нет. Их мир устроен иначе. Они ходят на управляющие комитеты раз в квартал, показывая там очень ладные презентации с мастер-планами. У них там чётко написано, на какие фичи они «коммитятся» в этом квартале.

Их главная цель — заявить о фиче и не облажаться на следующем комитете. Как технически это будет сделано — их в душе не волнует.

Раньше руководство использовало такой аргумент против предпрода: «Если будет ещё одна среда — это сильно увеличит нам Time-to-Market (TTM)». Пока вы там будете тестировать ещё на одной ступени, конкуренты уйдут вперёд.

Но это, мягко говоря, спорное заявление. Давайте посчитаем честно, сколько времени мы тратим на:

• Откат релиза назад, когда он падает на проде. 

• Срочные фиксы багов. 

• Пересборку поставки и повторную выкатку. 

Если сложить всё это время, то аргумент про быстрый TTM рассыпается. Но бизнес считает TTM от идеи до первой выкатки. То, что после выкатки потом неделю мы чиним баги хотфиксами, не попадает в их метрики успеха.

Есть ещё одна боль — мы только раскатили релиз, ещё даже не успев провести smoke-тестирование, а заказчики уже побежали и сообщили своему руководству, что всё готово. Им главное — быстрее, выше, сильнее. Они галочку поставили.

А через полчаса случается поломка. Мы всё откатываем. Они прибегают в ужасе: «Как это — всё сломалось?! Почему? Мы же уже всем рассказали!» Но они не могут послать своих начальников: им прилетает за неработающий функционал. В итоге они приходят жаловаться к нам: «Какой ужас, всё пропало!»

Запуск шести AI-ассистентов за 2,5 месяца

Когда я только пришла на проект, сверху спустилась задача: «Хотим за два с половиной месяца запустить шесть чат-ботов-болталок на разные тематики». Аргументация: «Вон Т-Банк проводит у себя эксперименты, давайте и нам тоже». Никто даже особо не разбирался, нужно ли это нам: просто конкурентная гонка.

Мне нужно было скоординировать пять разных команд, собрать человеческие ресурсы, которых не было (нам сказали: «Займите у других департаментов»), распределить разработку, тестирование и выкатить это в прод. Мы запустили несколько AI-ассистентов-болталок по разным тематикам. Это боты без выхода в Интернет с зашитыми промптами, работающие через нашу внутреннюю шину и внешнюю LLM (Гигачат). На тесте всё было ОК, а вот на проде начались приключения.

Выкатываем, значит, ассистентов. Клиент пишет: «Составь маршрут в Москву на два дня». Ассистент молчит. Вообще ничего не происходит. Это худшее, что может быть. Ладно бы он ответил: «Я думаю», но тут просто игнор. Причина — сбой на этапе интеграции. Запрос проходил через несколько платформ, шёл в Гигачат, и где-то между нашей шиной и соседней командой сигнал терялся. Заказчики прибежали через полчаса с криками — пришлось ставить заглушку «Временно недоступен» и срочно фиксить.

Ещё был кейс, как тревел-ассистент отправлял карту Саратова  на запрос «Подскажи ближайшие банкоматы в Москве». Или давал битую ссылку. Ассистент отвечает, но несёт полную ересь. Скорее всего, проблема была в том, как он себя определял в контексте, или как обрабатывались данные до отправки в LLM.

Знатный косячок — когда ассистент вдруг начал отвечать на латинице. Хотя у него стоят жёсткие ограничения, и он не должен так себя вести.

Один раз приходят продакт-оунеры: «Ой, а у вас русская буква «б» изменилась на латинскую «B» в ответе». Мы начали разбираться. Оказалось, что это происходило не только с этой буквой, — менялись и другие. Мы проверили весь пайплайн — на нашей стороне чисто. Оказалось, что проблема — на стороне Гигачата. Но так как кейсов было мало, этот баг мы даже отложили, потому что были проблемы посерьёзнее.

Самая жесть была с ассистентом для детей. Там куча ограничений: никаких политики, мата, ругательств, 18+. Мы тестировали на детях сотрудников (с разрешения родителей, конечно). Дети спрашивали: «Помоги сделать уроки». Но нам нужно было убедиться, что бот не ляпнет ничего лишнего. Мне кажется, мы сделали невозможное, чтобы это запустить.

Наш кризис-менеджмент

Как мы это ловим?

У нас есть метод раскатки, который называется «канарейка». Это когда мы выкатываем релиз постепенно: сначала — на 1-2% пользователей. Смотрим, сломалось или нет. Если нет — катим дальше. Заказчики даже поддерживают эту историю, так как им кажется, что это безопасно. Но это не панацея. Во-первых, это медленно. Во-вторых, требует дополнительных затрат на проверки. А в-третьих, если так катить всех заказчиков, то можно убиться: объёмы слишком большие.

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

Есть автоматические алерты от функционального сопровождения. Например, если Гигачат умер совсем, то должен прийти алерт. Но алерты — тоже не идеальное решение. Было такое, что сервис упал, а алерт не пришёл. Гигачат лежал, но мы узнали об этом только через четыре-пять часов, когда пришёл злой заказчик.

Если случается форс-мажор, то у нас нет времени на бюрократию. Я пишу в общий чат: «Ребята, чат-бот не отвечает. Смотрим все». Подключаются моя команда, смежники, тестировщики. Мы пытаемся воспроизвести баг. Если он воспроизводится — каждый смотрит свои логи. Я не ищу виноватых, а говорю: «Все команды проекта активно ищут и сообщают». И в итоге они сами ищут, сами находят.

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

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

На постмортем-анализы у нас времени нет. Мы почти не заводим инцидентов в системе. Всё решается в Телеграме: быстро созвонились, быстро пофиксили, выкатили — побежали дальше.

Никогда не ищем козла отпущения

По идее, бизнес должен сказать нам, какие баги критичны, а какие — нет. Но у нас никакой матрицы критичности по факту нет. Для заказчика критично всё. Запятая не там — истерика и: «Срочно чините!» Мне пришлось самой пытаться внедрить это понимание. Я спрашиваю: «У вас есть матрица? Как мы поймём, за что хвататься? Мы не можем починить всё сразу». 

По факту сейчас это работает так: заказчик вопит, а TPO сам решает, это реально критично или подождёт.

Когда что-то падает, команды любят показывать друг на друга пальцем: «Это не у нас, это у вас». Я всегда пресекаю это на корню: мы не ищем виноватых, нам нужно разобраться.

Особенно это касается молодых разработчиков: они боятся признаться, если накосячили. Молчат, как партизаны, думают, что их убьют. Приходится с ними работать: «Ребята, говорите. Если вы случайно влили не ту ветку — скажите сразу. Чем быстрее скажете, тем быстрее починим. Мы вас не убьём».

Возвращаемся к истокам

Сейчас мы находимся в очень странной точке. Мы погнались за Agile, за скоростью, за дебюрократизацией. Мы хотели уйти от Waterfall, когда требования согласовывали год. И мы ушли. Мы разгоняем Time-to-Market, запихиваем задачи в спринты на лету (несмотря на сопротивление).

Но этот срач в процессах привёл к тому, что мы упёрлись в потолок. Мы поняли, что без предпрода дальше нельзя. Эта проблема затрагивает все команды и тормозит нас больше, чем любая бюрократия. 

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

Сейчас мы объединились всем департаментом, всеми IT-командами, и эскалируем это на самый верх — руководству банка. Мы несём им фактуру, цифры и пытаемся доказать очевидное: скупой платит дважды. Похоже, что мы прошли полный круг отрицания и возвращаемся к тому, от чего убегали — к необходимости выстроенных скучных процессов и сред. Потому что на одних лишь скорости и героизме далеко не уедешь. Особенно когда твой чат-бот начинает говорить на другом языке или отправлять клиентов в Саратов. К тётке в глушь.

Будем добиваться предпрода. Пожелайте удачи!