Каждый спринт разработчики сталкиваются с дилеммой: баг фиксить или фичу делать. Баг теряет 5% заказов — это реальные деньги здесь и сейчас. Фича даст +10% продаж, но не сразу и с риском. Без аналитика команда может выбрать неоптимально.
Что делает хороший аналитик
Собирает цифры:
Потери от бага = 5% от текущей выручки (например, 1 млн руб./день).
Ожидаемый доход от фичи = 10% прироста, но после внедрения (через 3 недели).
Показывает бизнесу. Уточняет, можно ли отложить баг на час (неделю) – обычно нельзя, так как потери растут. Затем организует встречу со стейкхолдерами (владельцем продукта, маркетингом, поддержкой) и вместе определяют приоритет по бизнес-ценности. Возможные варианты:
Сначала фикс бага (1 неделя), затем MVP фичи (2 недели).
Перенести фичу на следующий спринт, но получить план компенсации (скидка на доставку).
Важно зафиксировать решение в протоколе, чтобы потом не было споров. Аналитик не должен выбирать сам — он фасилитатор.
Что будет, если выбрать A (фичу) без согласования
Бизнес потеряет 5% заказов за 3 недели; через месяц фича может не окупить потерь.
Что будет, если B (сделать всё, сократив тестирование)
Выпустите баг ещё больше, либо фича окажется с дефектами.
Реальный пример
В Delivery Club аналогичный конфликт решили взвешиванием: баг с потерей заказов — must have, новая фича — could have. Бизнес согласился отложить фичу.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
4811. Сервис отправки email иногда отвечает 500 ошибкой. При повторе письмо уходит дважды. Как требование должно защитить от дублей?
Anonymous Quiz
0%
Не повторить, а ловить ошибку и оповещать администратора
98%
Добавить уникальный идентификатор письма и проверять на стороне email-сервиса, было ли такое письмо
0%
Увеличить таймаут соединения
2%
Перестать пользоваться этим сервисом
Письма клиентам (со сбросом пароля, подтверждением заказа) не должны дублироваться. Но все внешние сервисы могут выдавать временные ошибки 5xx, и клиент, повторив запрос, рискует получить два письма.
Решение – идемпотентность на стороне получателя
В запросе на отправку письма нужно передавать уникальный идентификатор (например,
message_idДетали в требованиях
«Перед отправкой письма система должна генерировать уникальный
message_idorder_id + timestamp«Email-сервис должен реализовать проверку идемпотентности: если запрос с таким
message_id200 OK«Хранить ID не менее 24 часов для защиты от коллизий при сетевых задержках».
Почему не подходят другие варианты
A (не повторять) – письма могут теряться из-за сетевого сбоя. Надёжность упадёт.
C (увеличить таймаут) – не решает дублирование при повторе (пользователь нажал «отправить» дважды).
D (перестать пользоваться) – нереалистично.
Реальный кейс
Банк отправлял SMS с одноразовым кодом. Из-за ошибки в биллинге при повторе отправлялось две SMS. Клиенты путали код. После внедрения
message_idPlease open Telegram to view this post
VIEW IN TELEGRAM
4812. Запрос на выборку клиентов с суммой покупок > 1000 рублей:
SELECT client_id, SUM(amount) FROM orders GROUP BY client_id HAVING SUM(amount) > 1000.
Запрос выполняется 8 секунд. Как ускорить без сложных архитектурных изменений?
SELECT client_id, SUM(amount) FROM orders GROUP BY client_id HAVING SUM(amount) > 1000.
Запрос выполняется 8 секунд. Как ускорить без сложных архитектурных изменений?
Anonymous Quiz
27%
Добавить индекс на client_id
67%
Создать материализованное представление предрасчитанными суммами по клиентам, обновляемое раз в час
5%
Партиционировать таблицу по дате
1%
Увеличить память сервера
❤1
Партиционирование по дате уменьшит объём сканирования, если в
WHEREМатериализованное представление (MV)
MV хранит предрассчитанный результат запроса:
SELECT client_id, SUM(amount) as total FROM orders GROUP BY client_idЗанимает места ~ (кол-во клиентов) × (несколько байт).
Обновляется инкрементально после каждого изменения в
ordersЗапрос к MV вместо основной таблицы выполняется за миллисекунды (читает всего N строк).
В требованиях нужно указать:
«Для отчёта "топ клиентов" использовать материализованное представление
client_totals«Обновлять представление раз в час (допустима задержка)».
«При изменении данных (INSERT/UPDATE) в
ordersРеальный пример
В CRM-системе отчёт «крупнейшие покупатели» грузился 30 секунд. После создания MV с ежечасным обновлением время упало до 0.2 секунды.
Please open Telegram to view this post
VIEW IN TELEGRAM
4813. Стартап с 5 разработчиками и нагрузкой 100 запросов/сек хочет микросервисы «как у Google». Какой главный риск?
Anonymous Quiz
4%
Микросервисы потребляют больше памяти, чем монолит
94%
Избыточная инженерная сложность замедлит разработку и не даст преимуществ при такой нагрузке
1%
Микросервисы не умеют работать с транзакциями
1%
Несовместимость с облачными провайдерами
Микросервисы решают проблемы масштаба (тысячи разработчиков, миллионы запросов). Для маленькой команды они вводят накладные расходы:
Настройка Kubernetes, сервис-меша, дата-центра или кластера.
Отладка распределённых транзакций – запрос идёт через 5 сервисов, ошибку трудно воспроизвести.
Развёртывание: нужно вызывать CI/CD для каждого сервиса (минимум 3–4).
Мониторинг и логи – собирать их с нескольких сервисов сложнее.
При 100 запросах/сек и 5 разработчиках монолит с чёткими модулями будет работать не хуже, а разработка пойдёт быстрее.
Что делать вместо?
Модульный монолит с чёткими границами пакетов. Если в будущем нагрузка вырастет до 1000+ запросов/сек, легко выделить узкие места в отдельные сервисы.
Реальные примеры
Instagram долгое время был монолитом на Django.
Twitter начинал с монолита Ruby on Rails, а микросервисы внедрял, когда столкнулся с миллионами запросов.
Что аналитик должен рекомендовать
Оценить масштаб (100 запросов/сек – смешная нагрузка для современного сервера).
Оценить команду (5 человек – не нужно разделять).
Указать в NFR не «микросервисы», а «архитектура должна позволять горизонтальное масштабирование и выделение сервисов при росте нагрузки».
Вывод
Не усложняйте. Самая быстрая архитектура для малой команды – монолит с чистыми интерфейсами.
Please open Telegram to view this post
VIEW IN TELEGRAM
4814. Через месяц после утверждения требований заказчик просит добавить новое поле «скидка постоянного клиента» в форму заказа. Команда уже на середине спринта. Какой процесс нужно запустить?
Anonymous Quiz
2%
Сразу добавить поле, не спрашивая
97%
Оценить влияние, согласовать с командой, предложить варианты и зафиксировать решение в протоколе
1%
Отказать, потому что требования утверждены
0%
Передать решение архитектору
Изменения требований в середине спринта — норма. Бизнес не обязан ждать. Но нельзя их принимать без анализа.
Правильный процесс
Оценка влияния: сколько часов займёт (разработка, тестирование, документация), затронет ли другие модули, какой риск регресса.
Переговоры: можно ли перенести другую задачу, отложить текущую реализацию?
Решение: формальное согласование с заказчиком (если есть бюджет, время). Фиксация в протоколе изменений.
Почему не другие варианты
A – хаос, потеря контроля, срыв сроков.
C – негибкость, потеря доверия.
D – архитектор не владеет приоритетами бизнеса.
Реальный пример
В крупном ретейле заказчик попросил добавить отчёт по магазинам за прошлый месяц. Оценка показала 3 дня. Вместо срыва спринта договорились перенести менее важную фичу. Изменение задокументировали.
Please open Telegram to view this post
VIEW IN TELEGRAM
4815. Партнёр передаёт данные о заказах в виде CSV-файлов по FTP. Система иногда обрабатывает один и тот же файл дважды из-за дублирования имён. Как избежать повторной обработки?
Anonymous Quiz
44%
Переименовывать файл после обработки
42%
Использовать контрольный файл
14%
Удалять файл сразу после чтения
1%
Обрабатывать файлы только вручную
Партнёр может скопировать файл повторно с тем же именем (по ошибке). Система видит новый файл и обрабатывает повторно, что ведёт к дублированию заказов.
Решение – идемпотентность на уровне файлов
Нужно хранить уже обработанные имена файлов и их даты модификации (или контрольные суммы). Например: таблица
processed_filesfilenamesizemodified_timeprocessed_atДополнительно
Можно использовать
.done.doneИли переименовывать обработки файл в
.processedПочему не подходят другие
A (переименовывать) – но партнёр может положить файл заново уже с новым именем? Не решает глобально.
C (удалять) – плохо для аудита и отказоустойчивости.
D (ручная обработка) – не масштабируется.
Реальный кейс
В логистике дублирование файлов приводило к тому, что машина направлялась дважды. После внедрения таблицы
processed_filesPlease open Telegram to view this post
VIEW IN TELEGRAM
💯1
4816. В системе бронирования время события хранится как timestamp без зоны (UTC). Пользователь из Лондона и Москвы видят разное время. Как исправить без потери данных?
Anonymous Quiz
21%
Перевести все записи в новый тип timestamptz, выполнив миграцию с учётом правил преобразования
74%
Хранить все времена в UTC, а на клиенте преобразовывать в локальную зону пользователя
4%
Хранить два поля: локальное время и зону
0%
Оставить как есть, так как пользователи привыкнут
Если в БД хранить время без зоны (
timestampПочему B оптимально
Универсальность: данные внутри системы всегда согласованы.
Миграция: если текущие записи трактовались как местное время (например, московское), нужно точно знать, в какой зоне они были сохранены, и преобразовать их в UTC (обратимая операция).
Альтернативы
A – преобразовать в
timestamptzC – избыточно, сложно.
D – неприемлемо для международных систем.
Реальный пример
Требования
Все временные метки в БД –
TIMESTAMP WITH TIME ZONEtimestampКонвертация происходит на уровне представления.
Please open Telegram to view this post
VIEW IN TELEGRAM
4817. На собеседовании спрашивают: «Оцените, сколько дней потребуется, чтобы внедрить авторизацию через OAuth2». Ваш ответ?
Anonymous Quiz
7%
Назову 5 дней, так как OAuth2 типовой
81%
Скажу, диапазон от 2 до 10 дней, плюс риски
6%
Попрошу помощи у других
6%
Откажусь отвечать