Данил Тюменцев

Задача

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

Решение

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

Результат

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

Задача

Без учёта потребления невозможно ни назначить тариф, ни понять, когда мощности кончатся. При этом источник данных — сетевые сервисы, которые отдают статистику непоследовательно, а часть счётчиков молчит из-за конфигурации.

Решение

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

Результат

Появилась фактическая база для тарифной сетки и планирования мощностей вместо оценок «на глаз». Отдельно зафиксирован класс дефектов, при которых система показывает правдоподобные, но неверные цифры — это опаснее явного отказа.

Задача

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

Решение

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

Результат

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

Задача

Платёж подтверждается вебхуком от внешнего провайдера. Если приложение в этот момент недоступно, уведомление теряется, и сделка навсегда остаётся неоплаченной в системе при фактически прошедших деньгах. Для процесса продаж это дороже, чем недоступность интерфейса.

Решение

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

Результат

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

Задача

Каждая лишняя секунда и каждый лишний экран при записи траты снижают вероятность, что запись вообще будет сделана. Классическая форма «сумма — категория — дата» проигрывает одной фразе.

Решение

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

Результат

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

Задача

Подписка с безлимитом здесь невозможна: каждый ролик стоит машинного времени и внешних вызовов. Классическая модель «плати в месяц — пользуйся сколько хочешь» при таком продукте гарантированно уводит в убыток на тяжёлых пользователях.

Решение

Тарифная модель разделена: публикация и планирование — без ограничений, а платится именно генерация. Посчитана себестоимость ролика и от неё выведен размер рендер-фермы, необходимой для заявленного объёма. Запуск сознательно удерживается до закрытия перечня блокирующих условий, а не назначается по календарю.

Результат

Есть тарифная сетка, опирающаяся на расчёт, а не на цены конкурентов, и явный перечень условий запуска. Осознанный перенос даты — тоже управленческое решение: выпуск продукта с отрицательной маржой дороже, чем задержка.

Задача

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

Решение

Накопленный массив вакансий сохранён и проанализирован, чтобы отделить продуктовый вывод от технического сбоя. Развитие приостановлено осознанно: поддержка сбора данных требует постоянных вложений, а спрос на уведомления оказался ниже порога окупаемости.

Результат

Собрано и разобрано 8 659 вакансий — база для оценки рынка. Ресурс перенаправлен на продукты с подтверждённой оплатой. Умение закрыть направление вовремя — часть портфельного управления, а не признак неудачи.

Задача

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

Решение

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

Результат

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

Задача

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

Решение

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

Результат

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

Задача

Отдельный сервер под каждый сайт — это постоянные расходы, не создающие ценности. Но и совместное размещение имеет цену: общий вход по портам должен корректно разводить трафик, иначе один новый домен ломает все остальные сразу.

Решение

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

Результат

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