4795. Автотесты на заказ проходят, но через неделю на проде обнаружили, что перестала работать интеграция с CRM — из ответа API исчезло поле crm_id. Какой вид тестирования должен был предотвратить это?
Anonymous Quiz
16%
Модульное тестирование
5%
Нагрузочное тестирование
75%
Контрактное тестирование (Contract testing)
5%
Юзабилити-тестирование
Please open Telegram to view this post
VIEW IN TELEGRAM
ИИ уже не “будущее” — он тихо стал частью повседневности.🤖
Нейросети помогают писать тексты, генерировать изображения, анализировать данные, искать ошибки в коде и даже придумывать идеи для бизнеса. Но самое интересное — ИИ не заменяет человека, а усиливает того, кто умеет правильно задавать вопросы.🧠
Главный навык ближайших лет — не просто пользоваться технологиями, а понимать, как с ними сотрудничать.
IT + ИИ + нейро = новая реальность, где побеждает не тот, кто знает всё, а тот, кто быстрее учится. 🚀
Забрать папку 🎁
Добавиться в папку ⚡️
Нейросети помогают писать тексты, генерировать изображения, анализировать данные, искать ошибки в коде и даже придумывать идеи для бизнеса. Но самое интересное — ИИ не заменяет человека, а усиливает того, кто умеет правильно задавать вопросы.🧠
Главный навык ближайших лет — не просто пользоваться технологиями, а понимать, как с ними сотрудничать.
IT + ИИ + нейро = новая реальность, где побеждает не тот, кто знает всё, а тот, кто быстрее учится. 🚀
Забрать папку 🎁
Добавиться в папку ⚡️
Telegram
PRO IT🧠
Арина🔥 Романова invites you to add the folder “PRO IT🧠”, which includes 36 chats.
4796. Стартап запускает сервис доставки с прогнозом 100 заказов в день. Команда хочет использовать микросервисную архитектуру «на вырост». Какой аргумент против этого решения наиболее весомый?
Anonymous Quiz
5%
Микросервисы требуют больше серверов
3%
Микросервисы не поддерживают ACID-транзакции
88%
Микросервисы сложнее в отладке и эксплуатации, что замедлит выход MVP
3%
Микросервисы медленнее из-за сетевых вызовов
Микросервисная архитектура даёт преимущества при большом масштабе (тысячи заказов в секунду, 10+ команд разработки), но на старте проекта главное — как можно быстрее выкатить рабочий продукт (MVP), проверить гипотезы и получить обратную связь. Микросервисы же требуют значительных начальных инвестиций в инфраструктуру, инструменты и процессы.
2. Что значит «сложнее в отладке и эксплуатации»
Отладка: локально поднять 5 сервисов с их базами данных, очередями, кэшами — это время и память. Трассировка запроса, проходящего через сервисы, требует внедрения распределённого трейсинга (Jaeger, Zipkin).
Эксплуатация: нужны оркестрация (Kubernetes), сервис-меш (Istio), мониторинг (Prometheus + Grafana), сбор логов (ELK). Всё это настраивается неделями.
Развёртывание: CI/CD для микросервисов сложнее, чем для монолита.
Для MVP с 100 заказами в день эти затраты неоправданны. Монолит (или модульный монолит) позволит запуститься за месяц вместо трёх.
3. Почему остальные аргументы слабее
A (больше серверов): В облаке дешёвые инстансы для 5 микросервисов стоят несущественно. Не главное.
B (нет ACID-транзакций): Действительно проблема, но для доставки еды конечная согласованность (eventual consistency) часто допустима. Например, если заказ создался, а уведомление чуть задержалось — не катастрофа.
D (сетевые задержки): При 100 заказах в день сетевые вызовы добавляют миллисекунды, пользователь не заметит. Не весомо.
4. Реальный кейс
Стартап потратил 6 месяцев на проектирование микросервисов, а конкуренты на монолите запустились за 2 месяца и захватили рынок. После этого стартап закрылся. Другой пример: известный сервис доставки еды начинал с монолита и перешёл на микросервисы только когда нагрузка превысила 1000 заказов в минуту.
5. Что должен сделать аналитик
Оценить стадию проекта (MVP — монолит).
Согласовать с командой «архитектуру на вырост» в виде модульного монолита с чёткими границами пакетов, которые в будущем легко вырезать.
Зафиксировать нефункциональное требование: «Архитектура должна позволять выделение сервисов без полной переписки при росте нагрузки более 5000 заказов в сутки».
Вывод: Микросервисы — не бесплатный бонус, а плата высокой сложностью за масштабируемость и независимость команд. Для MVP эта плата обычно чрезмерна.
Please open Telegram to view this post
VIEW IN TELEGRAM
4797. При интеграции с платёжным шлюзом поступление callback-ов иногда приводит к дублированию платежей (одна и та же транзакция обрабатывается дважды). Какое требование аналитик должен добавить в спецификацию интеграции?
Anonymous Quiz
1%
Увеличить таймаут ожидания ответа от шлюза
96%
Обработка должна быть идемпотентной с использованием уникального ID транзакции
2%
Отключить повторные callback-и на стороне шлюза
1%
Сохранять все входящие запросы в отдельную таблицу для ручного разбора
Платёжные системы часто работают по семантике at-least-once (как минимум один раз). Это означает, что при сомнении (таймаут, неполучение подтверждения, перезапуск) шлюз может отправить callback повторно. Сетевые сбои, перезагрузки серверов — обычная причина дублей. Если ваша система списывает деньги при каждом вызове, клиент заплатит дважды.
2. Идемпотентность — единственное решение
Идемпотентная операция при повторном выполнении с теми же входными данными не меняет состояние системы. В данном случае: обработав первый callback, вы списываете деньги и запоминаете уникальный ID транзакции (например, payment_id). При повторном callback вы проверяете: если payment_id уже обработан — просто возвращаете успех, не списывая повторно. Технически это делается через хранение ID в Redis (с TTL) или в БД с уникальным индексом.
3. Почему не подходят другие варианты?
A (увеличить таймаут) — не влияет на дубликаты, таймаут отвечает за время ожидания ответа от вашего сервера шлюзом, но шлюз может дублировать и без таймаута.
C (отключить повторные callback на стороне шлюза) — невозможно, это внутренняя логика шлюза. Даже если бы можно было, вы снизите надёжность: при временном сбое уведомление потеряется навсегда.
D (ручной разбор) — не масштабируется, при тысячах платежей в день ручная проверка невозможна, бизнес не успеет.
4. Реальный кейс
Интернет-магазин подключил платёжный шлюз. В первые часы у нескольких клиентов списались деньги дважды. Анализ показал, что шлюз отправлял дубликат при задержке ответа магазина более 2 секунд. Внедрение идемпотентности на основе transaction_id позволило автоматически отсекать дубликаты без потери надёжности.
5. Что должен зафиксировать аналитик в требованиях
«Обработка callback-ов должна быть идемпотентной. Для этого использовать уникальный идентификатор платежа, предоставляемый шлюзом (поле payment_id), и хранить обработанные ID в Redis или БД с временем жизни не менее 24 часов».
«При повторном получении callback-а с уже обработанным ID система должна возвращать HTTP 200 OK без повторного выполнения бизнес-логики».
«Для защиты от гонок использовать блокировки или атомарные операции (например, SET NX в Redis)».
Вывод: Идемпотентность — обязательное требование для любой интеграции, где внешняя система может повторять запросы (а это почти все платёжные, SMS, email-сервисы). Без неё дублирование неизбежно приведёт к финансовым потерям и недовольству клиентов.
Please open Telegram to view this post
VIEW IN TELEGRAM
4798. Аналитик записал требование дословно. В результате разработчик реализовал уведомление при любом изменении статуса, включая промежуточные технические статусы. Клиенты начали жаловаться на спам. Какую практику аналитик должен был применить?
Anonymous Quiz
6%
Согласовать требование с разработчиками до передачи в работу
82%
Добавить критерии приемки с явным перечнем статусов, при которых уведомление должно отправляться
2%
Провести нагрузочное тестирование уведомлений
10%
Указать, что уведомление должно быть только после финального статуса
Фраза «при смене статуса» допускает множество интерпретаций. У заказа может быть 10 статусов: «Создан», «Оплачен», «На сборке», «Передан курьеру», «В пути», «Доставлен», «Отменён», «Возврат», «Переназначен» и т.д. Бизнес, вероятно, хотел уведомлять только о статусах, важных для клиента (например, «Оплачен», «Передан курьеру», «Доставлен»). Разработчик же, следуя букве, отправил уведомление при любом изменении, в том числе техническом («Переназначено курьеру» из-за смены смены). Это привело к спаму.
2. Что такое критерии приемки (Acceptance Criteria)?
Это список проверяемых условий, которые должны выполняться, чтобы пользовательская история считалась завершённой. Они пишутся на понятном бизнесу языке и часто в формате Given-When-Then. В данном случае аналитик должен был включить:
Критерии приемки:
Уведомление отправляется при переходе в статусы: «Оплачен», «Передан в доставку», «Доставлен».
Уведомление не отправляется при статусах: «Отменён», «Возврат», «Переназначено курьеру».
Уведомление содержит текст, соответствующий статусу (тексты приведены в приложении).
3. Почему не подходят другие варианты?
A (согласовать с разработчиками) — полезно, но разработчики не являются заказчиками. Они не могут решить, какие статусы важны для бизнеса.
C (нагрузочное тестирование) — не связано с логикой отправки, это про производительность.
D (только после финального статуса) — это тоже предположение, не обязательно верное. Бизнес мог ждать уведомления и на промежуточных этапах.
4. Реальный кейс
В службе доставки продуктов клиенты начали получать уведомления «Курьер переназначен» (при смене смены) в 3 часа ночи. Жалобы посыпались. Аналитик не указал явный список статусов. После добавления критериев приемки разработчик изменил логику, и уведомления стали приходить только о ключевых событиях.
5. Что должен сделать аналитик
Всегда задавать вопрос: «А при каких именно статусах нужно уведомление? Приведите примеры».
Фиксировать ответы в виде таблицы или списка.
Включать критерии приемки в каждую пользовательскую историю.
Проверять, что тестировщики учли все перечисленные статусы.
Вывод: Избегайте общих фраз. Если есть список значений — перечисляйте их явно в критериях приемки. Это сэкономит часы переделок и нервов команды.
Please open Telegram to view this post
VIEW IN TELEGRAM
4799. При моделировании процесса выдачи кредита две независимые проверки должны выполняться одновременно и не мешать друг другу. Процесс продолжается только после завершения обеих проверок. Какой элемент BPMN следует использовать?
Anonymous Quiz
3%
Исключающий шлюз (XOR)
90%
AND-шлюз (параллельный) с разветвлением (fork) и слиянием (join)
5%
Включающий шлюз (OR)
1%
Событийный шлюз (Event-based Gateway)
Две проверки не зависят друг от друга: одну можно выполнять в кредитном бюро, другую в скоринговой системе. Нет смысла делать их последовательно — это удвоит время ожидания. Нужно запустить их параллельно и продолжить процесс только после того, как обе завершатся.
2. Как работает AND-шлюз
Fork (разветвление): шлюз с одним входом и двумя выходами. Поток разделяется на две параллельные ветки. Обе выполняются одновременно.
Join (слияние): шлюз с двумя входами и одним выходом. Он пропускает поток дальше только после того, как все входящие ветки завершились.
Соединяя fork и join, вы получаете параллельное выполнение с синхронизацией.
3. Почему не подходят другие шлюзы
XOR (исключающий) — активирует только один путь из нескольких. Если поставить XOR, будет выполнена только одна проверка, вторая не запустится. Не подходит.
OR (включающий) — может активировать один или несколько путей. Но при слиянии OR продолжает работу после завершения первой активированной ветки, не дожидаясь остальных. Это не гарантирует выполнения обеих проверок.
Событийный шлюз — выбирает путь на основе наступления события (таймер, сообщение). Для параллельного выполнения не используется.
4. Реальный кейс
В банке процесс выдачи кредита изначально был последовательным: сначала скоринг (1 минута), потом кредитная история (1 минута). Заявка обрабатывалась 2 минуты. Аналитик перерисовал процесс с AND-шлюзом: проверки запускаются параллельно, общее время сократилось до 1 минуты. Клиенты стали получать решение в два раза быстрее.
5. Дополнительные детали для аналитика
Дорожки (swimlanes) помогают показать, кто за какую проверку отвечает (скоринг — отдел рисков, кредитная история — бюро).
Таймеры можно прикрепить к каждой ветке: если одна проверка зависла, через 30 секунд отправить уведомление администратору.
Исключения: если одна из проверок падает с ошибкой, то join не сработает. Нужно добавить шлюз для обработки ошибок (например, если скоринг недоступен, вернуть отказ).
Вывод: AND-шлюз (fork/join) — ключевой элемент BPMN для параллельного выполнения независимых задач и синхронизации. Его правильное применение сокращает время процессов и повышает эффективность.
Please open Telegram to view this post
VIEW IN TELEGRAM
📂 Подборка каналов по ИИ и IT технологиям
Подборка каналов для тех, кто работает в IT, хочет держать руку на пульсе без мониторинга сотни источников и сделать АПГРЕЙД своего информационного поля.
Что внутри:
🔗 [Добавить папку]
Подборка каналов для тех, кто работает в IT, хочет держать руку на пульсе без мониторинга сотни источников и сделать АПГРЕЙД своего информационного поля.
Что внутри:
– AI: реальные инструменты и внедрения, без хайпа;
– IT технологии: тренды, обзоры, инсайты от первых лиц;
– Карьера: как расти и не выгорать;
– HR Tech: кто и как нанимает профессионалов сейчас;
– AI life hacks: применение ИИ для удаленки и работы за рубежом.
🔗 [Добавить папку]
🔥1
4800. Стартап запускает сервис доставки с прогнозом 100 заказов в день. Команда хочет использовать микросервисную архитектуру «на вырост». Какой аргумент против этого решения наиболее весомый?
Anonymous Quiz
1%
Микросервисы требуют больше серверов
3%
Микросервисы не поддерживают ACID-транзакции
95%
Микросервисы сложнее в отладке и эксплуатации, что замедлит выход MVP
1%
Микросервисы медленнее из-за сетевых вызовов
🤔2
ДЛЯ РОСТА НЕ ВСЕГДА ОБЯЗАТЕЛЬНО НУЖНО КУДА-ТО БЕЖАТЬ, ЧТО-ТО ВПАРИВАТЬ И/ИЛИ КОГО-ТО ДОГОНЯТЬ ... * На деле — часто достаточно просто оказаться в том месте, где "дышится" иначе ✔️
Мы собрали для тебя ПОДБОРКУ каналов про продажи с IT & AI, в которую хотим тебя пригласить. Там всё без надрыва:
🚫 Без кричащих заголовков
🚫 Без "купи прямо сейчас, иначе потом будет дороже"
🚫 Без ощущения, что ты что-то упускаешь
▪️ Там про другое:
— про то, как слышать клиента, а не продавливать
— про сделки, после которых не чувствуешь себя выжатым
— про Telegram как про живое пространство, где хочется быть
— и про деньги, которые приходят не через манипуляции, а через доверие
Делимся знаниями и аудиторией — растём вместе ⚡️ Забирай ПАПКУ бесплатно. * Отписаться можно в любой момент. Остаться — тоже. ✔️
Ссылка ➡️ https://t.me/addlist/3sxzEXxFW2Q5YTNk
Мы собрали для тебя ПОДБОРКУ каналов про продажи с IT & AI, в которую хотим тебя пригласить. Там всё без надрыва:
🚫 Без кричащих заголовков
🚫 Без "купи прямо сейчас, иначе потом будет дороже"
🚫 Без ощущения, что ты что-то упускаешь
▪️ Там про другое:
— про то, как слышать клиента, а не продавливать
— про сделки, после которых не чувствуешь себя выжатым
— про Telegram как про живое пространство, где хочется быть
— и про деньги, которые приходят не через манипуляции, а через доверие
Делимся знаниями и аудиторией — растём вместе ⚡️ Забирай ПАПКУ бесплатно. * Отписаться можно в любой момент. Остаться — тоже. ✔️
Ссылка ➡️ https://t.me/addlist/3sxzEXxFW2Q5YTNk
🔥2❤1👍1
Микросервисная архитектура даёт преимущества при большом масштабе (тысячи заказов в секунду, 10+ команд разработки), но на старте проекта главное — как можно быстрее выкатить рабочий продукт (MVP), проверить гипотезы и получить обратную связь. Микросервисы же требуют значительных начальных инвестиций в инфраструктуру, инструменты и процессы.
2. Что значит «сложнее в отладке и эксплуатации»
Отладка: локально поднять 5 сервисов с их базами данных, очередями, кэшами — это время и память. Трассировка запроса, проходящего через сервисы, требует внедрения распределённого трейсинга (Jaeger, Zipkin).
Эксплуатация: нужны оркестрация (Kubernetes), сервис-меш (Istio), мониторинг (Prometheus + Grafana), сбор логов (ELK). Всё это настраивается неделями.
Развёртывание: CI/CD для микросервисов сложнее, чем для монолита.
Для MVP с 100 заказами в день эти затраты неоправданны. Монолит (или модульный монолит) позволит запуститься за месяц вместо трёх.
3. Почему остальные аргументы слабее
A (больше серверов): В облаке дешёвые инстансы для 5 микросервисов стоят несущественно. Не главное.
B (нет ACID-транзакций): Действительно проблема, но для доставки еды конечная согласованность (eventual consistency) часто допустима. Например, если заказ создался, а уведомление чуть задержалось — не катастрофа.
D (сетевые задержки): При 100 заказах в день сетевые вызовы добавляют миллисекунды, пользователь не заметит. Не весомо.
4. Реальный кейс
Стартап потратил 6 месяцев на проектирование микросервисов, а конкуренты на монолите запустились за 2 месяца и захватили рынок. После этого стартап закрылся. Другой пример: известный сервис доставки еды начинал с монолита и перешёл на микросервисы только когда нагрузка превысила 1000 заказов в минуту.
5. Что должен сделать аналитик
Оценить стадию проекта (MVP — монолит).
Согласовать с командой «архитектуру на вырост» в виде модульного монолита с чёткими границами пакетов, которые в будущем легко вырезать.
Зафиксировать нефункциональное требование: «Архитектура должна позволять выделение сервисов без полной переписки при росте нагрузки более 5000 заказов в сутки».
Вывод: Микросервисы — не бесплатный бонус, а плата высокой сложностью за масштабируемость и независимость команд. Для MVP эта плата обычно чрезмерна.
Please open Telegram to view this post
VIEW IN TELEGRAM