4698. Вы проектируете интеграцию с государственным порталом для получения персональных данных клиентов (паспортные данные, СНИЛС). Портал предоставляет REST API. Какое требование по безопасности обязательно должно быть в спецификации?
Anonymous Quiz
94%
Использовать шифрование TLS и взаимную аутентификацию (mTLS)
1%
Передавать данные в открытом виде внутри корпоративной сети
4%
Хранить логи всех запросов с персональными данными в открытом доступе
1%
Передавать данные через общую базу данных, доступную обоим системам
Шифрование при передаче (TLS) — обязательное требование
Любая передача персональных данных по открытым каналам (интернет) должна быть зашифрована. TLS (Transport Layer Security) гарантирует, что данные не будут перехвачены или изменены в пути. Это базовое требование и 152-ФЗ, и PCI DSS, и здравого смысла.
Взаимная аутентификация (mTLS) — best practice для B2B-интеграций
Взаимный TLS (mutual TLS) позволяет обеим сторонам удостовериться в подлинности друг друга: не только клиент проверяет сертификат сервера, но и сервер проверяет сертификат клиента. Это исключает риск подключения к поддельному порталу или приёма данных от неавторизованного отправителя.
Соответствие законодательству
Статья 19 152-ФЗ «Персональные данные» прямо требует обеспечивать конфиденциальность при обработке, в том числе при передаче. Роскомнадзор при проверках запрашивает наличие шифрования.
❌ Почему другие варианты опасны или недопустимы:
В (Открытая передача внутри сети):
Даже внутри корпоративной сети могут быть внутренние угрозы, перехват, скомпрометированные сегменты. PCI DSS и стандарты безопасности требуют шифрования везде, где данные покидают доверенную среду.
C (Открытые логи с ПДн):
Хранение персональных данных в логах в открытом виде — грубейшее нарушение. Логи часто имеют более слабую защиту, чем основные базы данных, и становятся источником утечек. Требуется либо не логировать ПДн вовсе, либо обезличивать/шифровать их.
D (Общая база данных):
Предоставление прямого доступа к своей БД внешней системе — антипаттерн интеграции и безопасности. Это создаёт неприемлемые риски: избыточный доступ, сложность контроля, масштабирование проблем доступа. Нарушается принцип наименьших привилегий.
📌 Что ещё должен учесть аналитик в требованиях:
Протокол и версия TLS — не ниже 1.2, с запретом устаревших шифров.
Управление сертификатами — кто выпускает, как обновлять, кто отвечает за отзыв.
Логирование без ПДн — фиксировать факт обмена, но не содержимое, либо маскировать данные.
Контракт данных — какие поля передаются, в каком формате, с какой периодичностью.
💡 Реальный кейс из практики:
При интеграции с Госуслугами (ЕСИА) обязательным требованием является использование ГОСТ-криптографии и взаимной аутентификации по сертификатам. Если аналитик этого не заложит в ТЗ, разработка интеграции остановится на этапе подключения к песочнице.
🎯 Вывод:
Безопасность при интеграциях начинается с простых, но критических вещей: шифрование канала и проверка сторон. Аналитик обязан включать эти требования в спецификацию на самом раннем этапе, иначе вся система может быть признана несоответствующей регуляторам и уязвимой для атак.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
4699. В системе управления задачами есть запрос для получения списка задач, назначенных на конкретного сотрудника. Таблица tasks содержит 10 миллионов записей. Запрос выполняется медленно (более 30 секунд). Какой способ оптимизации даст наибольший эффект?
Anonymous Quiz
25%
Добавить индекс на поле assignee_id
51%
Добавить составной индекс на поля (assignee_id, status, created_at)
2%
Увеличить объем оперативной памяти на сервере БД
23%
Разделить таблицу на две: активные и архивные задачи
✅ Почему вариант B — оптимальное решение:
Покрывающий индекс (covering index)
Составной индекс (assignee_id, status, created_at) включает все поля, которые, скорее всего, участвуют в типичном запросе:
assignee_id — для фильтрации по сотруднику
status — для фильтрации по статусу ("в работе", "завершена")
created_at — для сортировки по дате (обычно задачи показывают от новых к старым)
Эффективность использования
Такой индекс позволяет СУБД:
Быстро найти все задачи конкретного сотрудника по первой части индекса
Сразу отфильтровать по статусу (вторая часть)
Получить данные уже отсортированными по дате (третья часть) — без дополнительной сортировки
В идеальном случае вообще не обращаться к таблице, если запрашиваются только эти поля
Реальный прирост производительности
Для таблицы в 10 млн записей разница между простым индексом на assignee_id и составным покрывающим индексом может составлять:
Простой индекс: сначала поиск по индексу → затем чтение строк таблицы → затем фильтрация → затем сортировка
Составной индекс: всё делается за один проход по индексу
❌ Почему другие варианты хуже:
A (Индекс на assignee_id):
Поможет найти задачи сотрудника, но после этого СУБД придётся читать сами строки из таблицы (возможно, тысячи), фильтровать по статусу в памяти и сортировать. Это всё ещё дорого.
C (Увеличить память):
Это временное решение. Если запрос неоптимален, память просто откладывает проблему. При первых запросах после перезагрузки или новых данных всё вернётся.
D (Разделение таблиц):
Хорошая стратегия для управления данными, но:
Требует изменений в коде приложения (понимать, в какую таблицу писать/читать)
Не решает проблему сортировки и фильтрации в рамках активной таблицы
Может быть полезно, но как дополнительная оптимизация, а не первичная
📌 Роль аналитика в оптимизации:
Аналитик должен:
Понять типичные запросы к системе (через логи, интервью с пользователями)
Выявить частые паттерны фильтрации и сортировки
Заложить в требования необходимость индексов под эти паттерны
Согласовать с разработчиками возможность и стоимость создания индексов
💡 Пример из практики:
В одном проекре аналитик заметил, что 90% запросов к таблице заказов фильтруются по customer_id и status, а сортируются по created_at. Составной индекс (customer_id, status, created_at) сократил время выполнения типового запроса с 45 секунд до 200 миллисекунд.
🎯 Вывод:
Правильно спроектированные индексы — это не техническая деталь, а архитектурное решение, напрямую влияющее на пользовательский опыт. Аналитик, понимающий это, создаёт системы, которые не тормозят при росте данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3❤1
4700. Вам нужно для каждого клиента интернет-магазина получить полную информацию о его самом последнем заказе (с самой поздней датой). Какой подход к написанию запроса даст правильный результат и будет оптимальным по производительности?
Anonymous Quiz
44%
Сгруппировать записи по клиентам и выбрать максимальную дату заказа
19%
Использовать левое соединение таблицы с самой собой с условием, что более поздний заказ отсутствует
22%
Применить оконную функцию для нумерации заказов каждого клиента
14%
Отсортировать все заказы по клиенту и дате, но не фильтровать – результат будет содержать все строки
❤1
✅ Почему вариант C — лучший:
Полнота данных – в отличие от простой группировки (вариант A), оконная функция позволяет получить все поля исходной таблицы, а не только ключ и дату.
Читаемость и стандарт – конструкция с ROW_NUMBER() понятна большинству разработчиков и поддерживается всеми современными СУБД (PostgreSQL, MySQL 8+, Oracle, SQL Server).
Производительность – при наличии индекса на (customer_id, order_date DESC) запрос выполняется за один проход по данным, без многократных вложенных сканирований, как в варианте B.
❌ Почему другие варианты хуже:
A – не решает задачу, так как возвращает только дату, а не все поля заказа.
B – классический «анти-джойн» технически рабочий, но:
Тяжеловесен: требует полного сканирования и сравнения таблицы с самой собой.
Трудночитаем и сложен в поддержке, особенно для начинающих.
При больших объёмах данных (миллионы строк) выполняется неприемлемо долго.
D – просто сортировка без фильтрации не выделяет последний заказ; результат содержит все записи, что не соответствует требованию.
📌 Роль аналитика:
Понимание оконных функций позволяет грамотно формулировать требования к отчётам и выборкам. Зная, что для задачи «последний заказ клиента» оптимально использовать ROW_NUMBER(), вы помогаете команде избежать неэффективных решений и закладываете правильную логику с самого начала.
Please open Telegram to view this post
VIEW IN TELEGRAM
4701. Стартап с командой из 5 человек разрабатывает MVP платформы онлайн-курсов. В будущем планируется масштабирование и добавление новых функций. Какую архитектуру выбрать на старте?
Anonymous Quiz
58%
Модульный монолит
33%
Микросервисная
2%
Серверлесс
6%
Событийно-ориентированная
❤1
1. Скорость разработки (Time-to-Market)
В монолите всё работает «в одном процессе»: вызовы между модулями — это просто вызовы функций, а не HTTP-запросы. Не нужно тратить время на:
Проектирование и версионирование API между сервисами
Настройку сетевого взаимодействия и балансировщиков
Обработку таймаутов и повторных попыток
Сериализацию/десериализацию данных
Для команды из 5 человек это означает, что первую версию продукта можно выпустить за 1-2 месяца, а не за полгода. В стартапе это часто вопрос выживания.
2. Простота разработки и тестирования
Одно приложение легче:
Собрать и запустить локально у каждого разработчика
Покрыть интеграционными тестами (не нужно поднимать окружение из 5+ сервисов)
Отлаживать (дебаггер работает сквозь все слои)
Деплоить (один артефакт, одна команда деплоя)
3. Модульность внутри монолита — залог будущего
«Модульный монолит» — это не свалка кода, а чётко организованная структура:
Выделение бизнес-модулей (курсы, пользователи, оплата, уведомления)
Строгое разделение слоёв (контроллеры → сервисы → репозитории)
Чёткие интерфейсы между модулями внутри кода
Это позволяет в будущем «вырезать» модуль в отдельный микросервис, если:
Модуль требует независимого масштабирования (например, видео-сервис)
Команда выросла и нужно разделить ответственность
Появились специфические требования к технологиям (например, для видео нужен Go, а для оплаты — Java)
4. Экономия ресурсов
Пока у стартапа нет миллионной нагрузки, платить за инфраструктуру для микросервисов (балансировщики, несколько баз данных, оркестрация) — просто выбрасывать деньги. Монолит можно крутить на одном небольшом сервере за $50/мес.
❌ Почему другие варианты не подходят:
A) Микросервисная архитектура
Микросервисы — это распределённая система, со всеми вытекающими сложностями:
Сетевое взаимодействие — любой вызов может упасть с таймаутом, нужно реализовывать retry, circuit breaker
Распределённые данные — сложно делать JOIN между таблицами разных сервисов, нужны саги или паттерн CQRS
DevOps-нагрузка — нужно настроить CI/CD для каждого сервиса, мониторинг, логирование, трассировку
Когнитивная нагрузка — разработчики должны держать в голове всю картину взаимодействий
Для 5 человек и MVP это неподъёмно. Микросервисы — это про организационную масштабируемость, а не про техническую. Конвей Глиз (C. Hale) говорил: «Микросервисы — это то, что вы делаете, когда ваша команда выросла настолько, что монолит мешает её организации».
C) Серверлесс (FaaS)
Serverless (AWS Lambda, Google Cloud Functions) хорошо подходит для:
Обработки событий (загрузили файл — запустилась функция)
Микросервисов с чёткой единичной ответственностью
Проектов с непредсказуемой, скачкообразной нагрузкой
Но для целого приложения с множеством взаимосвязанных функций serverless создаёт проблемы:
Холодный старт — если функции долго не вызывались, первый пользователь будет ждать 1-3 секунды
Vendor lock-in — логика привязывается к конкретной облачной платформе
Сложность отладки — трудно воспроизвести распределённый сценарий локально
Ограничения по времени выполнения — большинство функций не могут работать дольше 15 минут
MVP платформы онлайн-курсов требует целостного приложения с сессиями пользователей, сложными транзакциями — serverless здесь неудобен.
D) Событийно-ориентированная архитектура
Event-driven архитектура (через Kafka, RabbitMQ) отлично подходит для:
Слабосвязанных систем
Асинхронных процессов (уведомления, аналитика)
Интеграций между командами
Но для MVP это избыточно:
Сложность понимания потоков данных (событие может обрабатываться несколькими подписчиками в неизвестном порядке)
Eventual consistency — данные не согласованы мгновенно, что может сбивать с толку пользователей
Нужна инфраструктура для брокера сообщений
Для простого сценария «купил курс — получил доступ» можно обойтись синхронным вызовом в монолите, не усложняя систему.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
УСПЕВАЕТЕ СЛЕДИТЬ ЗА ИИ-НОВИНКАМИ ?! Технологии ИИ не ждут. А вы?
Каждую неделю выходят десятки обновлений нейросетей и новых инструментов. То, что вчера делали за 3 часа, сегодня нейросеть делает за 5 минут. Вопрос только в том — узнаете ли вы об этом первыми?
Пока большинство спит, единицы тестируют новые связки и вырываются вперед. Хотите быть в их числе?
Мы собрали ПАПКУ со всеми свежими ИИ-инструментами, фишками и апдейтами. Никакой воды — только то, что реально упрощает работу и приносит результат.
Подписывайтесь, чтобы всегда быть на острие 🚀
Держим руку на пульсе вместе: собираю в папке все прорывные ИИ-инструменты и обновления, чтобы вы всегда были первыми.
Не выпадайте из обоймы! Подписывайся на ИИ-обновления по ссылке ➡️ https://t.me/addlist/J1ZVdNPqSV81YTE0
Каждую неделю выходят десятки обновлений нейросетей и новых инструментов. То, что вчера делали за 3 часа, сегодня нейросеть делает за 5 минут. Вопрос только в том — узнаете ли вы об этом первыми?
Пока большинство спит, единицы тестируют новые связки и вырываются вперед. Хотите быть в их числе?
Мы собрали ПАПКУ со всеми свежими ИИ-инструментами, фишками и апдейтами. Никакой воды — только то, что реально упрощает работу и приносит результат.
Подписывайтесь, чтобы всегда быть на острие 🚀
Держим руку на пульсе вместе: собираю в папке все прорывные ИИ-инструменты и обновления, чтобы вы всегда были первыми.
Не выпадайте из обоймы! Подписывайся на ИИ-обновления по ссылке ➡️ https://t.me/addlist/J1ZVdNPqSV81YTE0
4702. Вы проектируете платежный шлюз, который интегрируется с несколькими внешними банковскими API. Какой архитектурный паттерн защитит систему от каскадных сбоев?
Anonymous Quiz
23%
Retry with exponential backoff
60%
Circuit Breaker
6%
Bulkhead
11%
Timeout
✅ Паттерн Circuit Breaker («Автоматический выключатель»)
Работает как электрический автомат в квартире:
Замкнут (Closed) — запросы проходят, статистика ошибок собирается.
Разомкнут (Open) — если ошибки превысили порог (например, 50% за последнюю минуту), все последующие вызовы мгновенно отклоняются без попытки соединения. Вместо реального вызова возвращается fallback-ответ (заглушка).
Полуоткрыт (Half-Open) — через некоторое время пропускается тестовый запрос, чтобы проверить, восстановился ли сервис. Если успешно — выключатель снова замыкается.
Почему это спасает ресурсы:
При разомкнутом состоянии не тратятся потоки, соединения, память на бесполезные вызовы.
Сервис получает передышку для восстановления без лавины повторных запросов.
Пользователи получают быстрый ответ (fallback), а не ждут таймаута.
❌ Почему другие варианты не решают проблему кардинально:
A (Retry with exponential backoff) — повторяет запросы с растущей задержкой, но при длительной недоступности всё равно будет пытаться, расходуя ресурсы. Может даже усугубить ситуацию, создавая отложенную нагрузку.
C (Bulkhead) — изолирует ресурсы (например, отдельный пул потоков для каждого банка). Это полезно, чтобы один банк не «съел» все потоки, но не предотвращает повторные попытки и не даёт сервису восстановиться.
D (Timeout) — ограничивает время ожидания ответа, но при каждом новом запросе снова ждёт, и ресурсы всё равно тратятся.
📌 Роль аналитика:
В требованиях к интеграциям нужно явно указывать необходимость реализации Circuit Breaker, а также определять:
Пороговые значения ошибок для срабатывани
Время восстановления (таймаут перед полуоткрытым состоянием)
Fallback-логику (что возвращать пользователю при отключении)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
4703. При проектировании сложной бизнес-логики, описанной с помощью таблицы решений (decision table), какой метод тест-дизайна наиболее подходит для проверки корректности реализации?
Anonymous Quiz
15%
Эквивалентное разделение
23%
Анализ граничных значений
54%
Таблица решений
9%
Попарное тестирование
❌ Другие методы менее эффективны для этой задачи:
Эквивалентное разделение (A) разбивает диапазоны значений на классы, но не учитывает комбинации разных условий.
Анализ граничных значений (B) фокусируется на границах диапазонов, что полезно для числовых полей, но не для логических комбинаций.
Попарное тестирование (D) сокращает количество тестов за счёт проверки всех пар значений, но может пропустить ошибки, возникающие только при определённых сочетаниях трёх и более условий.
Вывод для аналитика:
Понимание методов тест-дизайна помогает не только писать качественные требования, но и эффективно взаимодействовать с QA. Если бизнес-логика формализована таблицей решений, лучший способ её проверить — построить тесты, покрывающие столбцы этой таблицы.
Please open Telegram to view this post
VIEW IN TELEGRAM
4704. Вам нужно описать бизнес-процесс обработки заказа, в котором участвуют несколько ролей (менеджер, склад, курьер) и есть параллельные ветки. Какую диаграмму UML лучше всего выбрать для этой задачи?
Anonymous Quiz
9%
Диаграмма классов
43%
Диаграмма последовательности
45%
Диаграмма деятельности
4%
Диаграмма компонентов
✅ Почему диаграмма деятельности — лучший выбор:
Поддержка параллельных потоков:
С помощью элементов fork (разветвление) и join (слияние) можно показать, что несколько действий выполняются одновременно. Например, после получения заказа параллельно запускаются проверка на складе и поиск свободного курьера.
Разделение по ролям (swimlanes / дорожки):
Диаграмма деятельности позволяет группировать действия по исполнителям, отображая зоны ответственности каждой роли. Это делает процесс наглядным для всех стейкхолдеров.
Условия и ветвления:
С помощью узлов решения (decision nodes) легко показать альтернативные пути, например, «если товар в наличии → резервировать, иначе → уведомить менеджера».
Понятность бизнес-аналитикам и разработчикам:
Диаграмма деятельности читается практически как блок-схема, что делает её отличным инструментом коммуникации между бизнесом и IT.
❌ Почему другие варианты не подходят:
A (Диаграмма классов) — показывает статическую структуру системы: классы, их атрибуты, методы и связи. Она не предназначена для моделирования динамики процессов.
B (Диаграмма последовательности) — отображает взаимодействие объектов во времени, обычно для конкретного сценария использования (use case). Она хороша для детализации обмена сообщениями, но плохо подходит для параллельных веток и бизнес-процессов с множеством ролей.
D (Диаграмма компонентов) — описывает физическую архитектуру системы: компоненты, их интерфейсы и зависимости. Это уровень развертывания, а не бизнес-логики.
📌 Роль системного аналитика:
Выбор правильной диаграммы — важная часть работы аналитика. Для моделирования бизнес-процессов, особенно с параллельными ветвями и несколькими участниками, диаграмма деятельности является стандартным и наиболее выразительным средством в UML. Она помогает:
Согласовать процесс с заказчиком.
Выявить узкие места и лишние шаги.
Передать разработчикам четкое понимание логики.
Пример из практики:
В проекте по автоматизации доставки мы использовали диаграмму деятельности с дорожками для ролей «Клиент», «Магазин», «Курьер». Параллельные ветки показали, что комплектация заказа и маршрутизация курьера могут происходить одновременно, что сократило время доставки на 20%.
Please open Telegram to view this post
VIEW IN TELEGRAM