4833. Публичный API страдает от перебора паролей (1000 запросов/сек). Как ограничить частоту до 10 запросов/сек с одного ключа?
Anonymous Quiz
5%
Очередь сообщений
93%
Rate limiting (token bucket) на API Gateway
3%
Кэширование
0%
Увеличение серверов
Как работает token bucket
У каждого клиента (IP, API-ключ) есть корзина с токенами (например, 10 токенов).
Каждый запрос забирает 1 токен.
Корзина пополняется с заданной скоростью (например, 1 токен в 0.1 секунды).
Если токенов нет, возвращается HTTP 429 Too Many Requests.
Где реализовывать – на API Gateway (единая точка входа), чтобы не дублировать в каждом микросервисе.
Почему не очередь – очередь сглаживает всплески, но не останавливает злоумышленника, который может забить очередь и создать проблемы.
Вывод – аналитик должен прописывать лимиты (10 запросов/сек) и поведение при превышении в требованиях к публичным API.
Please open Telegram to view this post
VIEW IN TELEGRAM
4834. Заказчик просит: «Система должна выбирать самого быстрого курьера». Разработчик реализовал выбор по расстоянию на карте. Заказчик имел в виду освобождение от других заказов. Что упустил аналитик?
Anonymous Quiz
0%
Не проверил возможность реализации
100%
Не уточнил бизнес-правило: что значит «быстрый» (время освобождения) и как его вычислять
0%
Не назначил ответственного
0%
Не сделал ручной выбор курьера
В проектах интеграции с курьерскими службами нередко возникает неоднозначность термина «быстрый». Для логиста «быстрота» может означать минимальное время до прибытия к клиенту с учётом текущих заказов курьера. Для разработчика, не спросившего уточнений, «быстро» — это минимальная дистанция на карте (евклидово расстояние или время в пути без трафика). Результат: система предлагает курьера, который находится за углом, но у него ещё три невыполненных заказа, а реально свободный курьер из соседнего района — через 15 минут. Заказчик недоволен, бизнес теряет деньги.
Что должен был сделать аналитик?
Задать уточняющие вопросы:
«Как именно измерить "быстроту"? По времени, по расстоянию, по рейтингу?»
«Учитываем ли мы текущую загрузку курьера (активные заказы)?»
«Где брать данные о времени освобождения? Из какого API?»
«Нужно ли учитывать пробки, время суток?»
Перевести ответы в измеримое бизнес-правило:
«Система выбирает курьера с минимальным ожидаемым временем прибытия к месту заказа, рассчитанным как: (время завершения текущих заказов курьера) + (расчётное время в пути от его текущей позиции до точки заказа). Данные о текущих заказах получаем из API курьерской системы. При равенстве времени выбираем курьера с более высоким рейтингом».
Зафиксировать требование с критериями приёмки:
Пример 1: Курьер А свободен и находится за углом (1 мин), курьер Б занят на 20 мин, но его время пути 5 мин. Итог: А — 1 мин, Б — 25 мин → выбираем А.
Пример 2: Оба курьера свободны, но А — 5 мин пути, Б — 10 мин → выбираем А.
Последствия для проекта, если не уточнить
Разработчик тратит время на реализацию не того алгоритма.
На приёмке выявляется несоответствие → переделка (стоит в 5–10 раз дороже, чем уточнение на этапе анализа).
Заказчик теряет доверие.
Курьеры распределяются неэффективно → задержки доставки, недовольные клиенты.
Вывод для системного аналитика
Любое субъективное прилагательное («быстрый», «удобный», «лучший», «оптимальный») — красный флаг. Всегда конкретизируйте: по какой метрике, на основе каких данных, с какими допущениями. Превратите "быстрый" в формулу или таблицу принятия решений. Это основа качественных требований.
Please open Telegram to view this post
VIEW IN TELEGRAM
4835. Команда обновила API с v1/customers (поля: id, name) до v2/customers (поля: id, firstName, lastName). Через месяц старую версию отключили. Мобильное приложение перестало показывать имена клиентов. Что нужно было сделать аналитику заранее?
Anonymous Quiz
0%
Увеличить срок предупреждения о депрекации
96%
Спроектировать политику версионирования с перекрытием (grace period) и обратно совместимые изменения
4%
Переписать мобильное приложение до отключения старой версии
0%
Откатить API до старой версии
В микросервисной архитектуре у разных клиентов (мобильное приложение, веб-версия, интеграции партнёров) могут быть разные графики обновления. Если разработчики API меняют контракт (удаляют поле
namefirstNamelastNameЧто должен был сделать аналитик
Зафиксировать требование обратной совместимости: новая версия API не должна удалять поля, которые использовались в старой. Вместо этого добавлять новые поля (
firstNamelastNamenameВнедрить grace period: объявить дату устаревания (deprecation) старой версии, например, через 6 месяцев. Всё это время обе версии работают параллельно. В ответах старой версии добавить заголовок
Deprecation: trueПлан миграции: клиенты (мобильное приложение) должны перейти на новую версию в течение grace period. Только после того, как все клиенты переключились, старую версию можно отключать.
Мониторинг: отслеживать, какие клиенты всё ещё используют старую версию, и напоминать им о необходимости обновления.
Почему не подходят другие варианты
A (увеличить срок предупреждения) — без политики параллельной работы и обратной совместимости всё равно ломает клиентов в момент отключения.
C (переписать мобильное приложение до отключения) — на практике часто невозможно, так как обновление зависит от пользователей.
D (откатить API) — временное решение, не решающее проблему в будущем.
Реальный пример
GitHub API версионирует через даты (например,
2022-11-28SunsetВывод для аналитика
При проектировании API всегда закладывайте:
Параллельную работу нескольких версий.
Минимальный срок поддержки старой версии (например, 6–12 месяцев).
Обратную совместимость: добавляйте поля, не удаляйте и не меняйте типы существующих.
Механизм уведомления клиентов о deprecation (заголовки, email, документация).
Please open Telegram to view this post
VIEW IN TELEGRAM
4836. Пользователи говорили: тёмная тема важна, проверка орфографии — нет. После релиза орфографией пользуются все, а тёмную тему — единицы. Какую ошибку допустил аналитик?
Anonymous Quiz
2%
Не проверил реализуемость темной темы
88%
Не использовал модель Кано (не разделил требования на базовые, линейные и «восхитители»)
1%
Не согласовал приоритеты с разработчиками
10%
Опросил слишком мало пользователей
Модель Кано классифицирует требования по влиянию на удовлетворённость:
Базовые (must-have) — если их нет, пользователь сильно недоволен, но их наличие не повышает лояльность (например, проверка орфографии: пользователи её ожидают, но не говорят о ней).
Линейные (чем больше, тем лучше) — например, скорость работы приложения.
Восхитители (attractive) — неожиданные фичи, которые вызывают восторг (тёмная тема для некоторых аудиторий).
Ошибка аналитика: он спросил «насколько важно?» и получил ответы, не отражающие реальной категории. Базовые фичи кажутся неважными («это и так должно быть»), а восхитители — переоценёнными в опросах. Правильный подход: задавать вопросы в паре: «Как вы отреагируете, если функция есть?» и «Как отреагируете, если её нет?». Тогда можно определить тип.
Реальный кейс: В одном приложении доставки пользователи говорили, что «отслеживание курьера в реальном времени» важно, а «точное время доставки» — нет. После внедрения оказалось, что точное время гораздо критичнее. Модель Кано помогла бы выявить, что точное время — базовая функция, а трекинг — восхититель.
Вывод: Аналитик должен использовать модель Кано для выявления скрытых ожиданий и не доверять прямым оценкам важности.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
4837. Заказчик требует, чтобы «система работала без перебоев». Что аналитик должен указать в SLA вместо этого?
Anonymous Quiz
13%
Система должна быть доступна 24/7
85%
Доступность 99.9%, время восстановления после сбоя — не более 1 часа»
0%
Перебоев быть не должно
1%
Администраторы будут следить за системой
Доступность (uptime) — например, 99.9% (это допустимо ~43 минуты простоя в месяц).
RTO (Recovery Time Objective) — максимальное время восстановления.
RPO (Recovery Point Objective) — допустимые потери данных в минутах/часах.
Время отклика поддержки — например, ответ в течение 15 минут.
Без этих цифр заказчик и исполнитель будут спорить: «перебой» — это 1 минута или 1 час? SLA позволяет объективно измерить качество обслуживания.
Реальный пример: В контракте на облачный сервис прописывают 99.95% доступности. Если простой превышает оговорённый лимит, исполнитель выплачивает штраф.
Вывод: Аналитик должен переводить расплывчатые пожелания в измеримые SLA.
Please open Telegram to view this post
VIEW IN TELEGRAM
4838. Партнёр загружает выгрузку в SFTP. Ваша система забирает файл и удаляет его. Если обработка файла упала, файл теряется. Как доработать интеграцию, чтобы избежать потери данных?
Anonymous Quiz
20%
Не удалять файл, а переносить в папку failed
76%
Использовать двухстадийную обработку: сначала переименовать файл, после успеха — удалить
3%
Копировать файл на локальный диск
1%
Обрабатывать файл в исходной директории
Алгоритм:
Заметить файл
data.csvПереименовать в
data.csv.processingОбработать содержимое.
Если успех — удалить
data.csv.processingЕсли ошибка — переименовать обратно в
data.csvdata.csv.errorПочему это лучше, чем просто перемещать в
failedРеальный пример: В банковской интеграции с партнёрами используется паттерн
*.inprogressВывод: Аналитик должен закладывать в требования двухстадийную обработку для любых интеграций через файловые обменники.
Please open Telegram to view this post
VIEW IN TELEGRAM
4839. В DWH нужно хранить историю изменения адреса клиента. При обновлении адреса старый адрес должен сохраниться для прошлых заказов. Какой тип SCD (медленно меняющегося измерения) применить?
Anonymous Quiz
1%
SCD Type 0 (без изменений)
83%
SCD Type 2 (новая строка с датами начала и окончания действия)
5%
SCD Type 1 (перезапись)
11%
SCD Type 3 (отдельная колонка «предыдущий адрес»)
end_date = nowstart_date = nowstart_dateend_dateПочему не Type 1 (перезапись) – потеря истории.
Type 3 (отдельная колонка «предыдущий адрес») – хранит только текущий и предыдущий адрес, но не полную историю.
Type 0 – вообще без изменений.
Реальный пример: В розничной сети SCD Type 2 используется для измерения «Клиент», чтобы видеть, по какому адресу был сделан каждый заказ несколько лет назад.
Вывод: Аналитик должен выбирать тип SCD в зависимости от того, нужна ли история, и как далеко нужно видеть прошлые состояния.
Please open Telegram to view this post
VIEW IN TELEGRAM