Модель Кано классифицирует требования по влиянию на удовлетворённость:
Базовые (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
4840. Распределённая система должна одновременно обеспечивать строгую согласованность данных (consistency) и доступность при любых сбоях. При сетевом разделении система перестаёт принимать записи. Какую теорему иллюстрирует этот пример?
Anonymous Quiz
4%
Теорема Геделя о неполноте
95%
CAP-теорема: из трёх свойств можно гарантировать только два
0%
Закон Амдала
2%
Теорема Коуза
В 2000 году Эрик Брюер сформулировал, что в распределённой системе невозможно одновременно гарантировать три свойства:
Consistency (C) – все узлы видят одни и те же данные в один момент времени (нет устаревших копий).
Availability (A) – каждый запрос получает ответ (даже если некоторые узлы недоступны).
Partition tolerance (P) – система продолжает работать при разрыве связи между узлами (сетевом разделении).
При возникновении сетевого разделения система вынуждена выбирать между C и A:
CP‑система (например, HBase, MongoDB с настройкой по умолчанию) жертвует доступностью: при разделении блокирует запись, чтобы не нарушить согласованность.
AP‑система (например, Cassandra, CouchDB) жертвует строгой согласованностью: возвращает данные, которые могут быть устаревшими, но система остаётся доступной.
Почему это важно для аналитика?
При выборе базы данных для распределённой системы (например, банковской или социальной сети) вы должны понимать, что невозможно получить и строгую согласованность, и абсолютную доступность при любых сбоях.
Финансовые транзакции – приоритет согласованности (CP). Даже если система временно недоступна, деньги не должны потеряться.
Лента новостей – приоритет доступности (AP). Лучше показать слегка устаревшие новости, чем вообще не открыть приложение.
Реальный кейс:
В Amazon при оформлении заказа применяется строгая согласованность (CP), а при просмотре каталога — eventual consistency (AP). CAP-теорема помогает объяснить такие архитектурные компромиссы заказчику.
Вывод:
Аналитик, знающий CAP-теорему, может аргументированно выбирать хранилище данных под бизнес-требования, понимая неизбежные компромиссы.
Please open Telegram to view this post
VIEW IN TELEGRAM
Если коротко, то ИИ уже не будущее, а наше настоящее.
* Он пишет тексты, анализирует данные, автоматизирует продажи, создает изображения и экономит десятки часов в неделю.
Вопрос уже не в том, заменит ли ИИ людей.
Вопрос – кто быстрее научится им пользоваться.
Специально для тебя ПОДБОРКА сильных экспертов в сфере ИИ
Включайся сейчас - 1 клик, без смс и регистрации. 🏁 Не отставай. Или обгоняй.
Делимся знаниями и аудиторией — растём вместе ⚡️
Забирай ПАПКУ бесплатно. Ссылка действительна 24 часа
* Отписаться можно в любой момент. Остаться — тоже. ✔️
Ссылка ➡️ https://t.me/addlist/n__Pk89IyogzOTVk
* Он пишет тексты, анализирует данные, автоматизирует продажи, создает изображения и экономит десятки часов в неделю.
Вопрос уже не в том, заменит ли ИИ людей.
Вопрос – кто быстрее научится им пользоваться.
Специально для тебя ПОДБОРКА сильных экспертов в сфере ИИ
Включайся сейчас - 1 клик, без смс и регистрации. 🏁 Не отставай. Или обгоняй.
Делимся знаниями и аудиторией — растём вместе ⚡️
Забирай ПАПКУ бесплатно. Ссылка действительна 24 часа
* Отписаться можно в любой момент. Остаться — тоже. ✔️
Ссылка ➡️ https://t.me/addlist/n__Pk89IyogzOTVk
🔥1
4841. В системе бронирования билетов критично не потерять ни одной записи. Репликация базы данных настроена асинхронно. При сбое мастер-сервера последних транзакций пропадают. Как изменить настройку репликации, чтобы гарантировать нулевую потерю данных?
Anonymous Quiz
3%
Увеличить количество реплик
88%
Переключиться на синхронную репликацию (операция подтверждается только после записи на реплику)
1%
Увеличить частоту снэпшотов
8%
Включить кэширование на мастере
НЕБОЛЬШОЙ АПГРЕЙД ТВОЕЙ ЛЕНТЫ, КОТОРЫЙ ДАСТ ХОРОШИЙ БУСТ ТВОЕЙ КАРЬЕРЕ
Друзья, наш канал попал в подборку тг-каналов про ИТ, ИИ, технологии и карьеру — получилась такая ламповая тусовка «для своих» 😎
Тут мы собрали каналы для себя, которые реально помогают:
➕ следить за ИИ — от свежих инструментов до реальных кейсов
➕ разбираться в технологиях — тренды, обзоры и объяснения
➕ расти в IT — советы по карьере, поиску работы и развитию
➕ быть в теме HR Tech — как технологии меняют найм и управление
🆒 Осталось только добавить папку себе ✔️https://t.me/addlist/n__Pk89IyogzOTVk
Друзья, наш канал попал в подборку тг-каналов про ИТ, ИИ, технологии и карьеру — получилась такая ламповая тусовка «для своих» 😎
Тут мы собрали каналы для себя, которые реально помогают:
➕ следить за ИИ — от свежих инструментов до реальных кейсов
➕ разбираться в технологиях — тренды, обзоры и объяснения
➕ расти в IT — советы по карьере, поиску работы и развитию
➕ быть в теме HR Tech — как технологии меняют найм и управление
🆒 Осталось только добавить папку себе ✔️https://t.me/addlist/n__Pk89IyogzOTVk
❤1👍1🔥1
Мастер-сервер принимает транзакцию, подтверждает клиенту «успех» и потом отправляет изменения на реплику. Если мастер падает между подтверждением и отправкой, реплика не получает данные → потеря транзакций. Это допустимо в системах, где допустима микро-потеря (например, аналитика), но не в финансовых или критичных системах.
Синхронная репликация
Мастер отправляет данные на реплику, ждёт её подтверждения, и только после этого отвечает клиенту «успех». При падении мастера реплика уже имеет данные, и потери нет. Недостаток: задержка увеличивается, так как клиент ждёт ответа от реплики.
Пример из реальной жизни
В банковских системах (например, при переводе денег) используется синхронная репликация. В социальных сетях (лайки, просмотры) — асинхронная, так как пара потерянных лайков не критична.
Что должен зафиксировать аналитик
Допустимо ли RPO (Recovery Point Objective) больше нуля? Если нет — синхронная репликация.
Какая задержка допустима? Синхронная репликация медленнее.
Нужно ли распределение по географическим зонам? Тогда синхронная репликация может быть очень медленной.
Вывод: Для критичных к потере данных систем синхронная репликация обязательна. Аналитик должен указать это в требованиях к отказоустойчивости.
Please open Telegram to view this post
VIEW IN TELEGRAM
4842. Внешний API ограничивает 10 запросов в секунду. Ваше приложение шлёт 50 запросов в секунду и получает ошибки 429. Какая техника защиты должна быть реализована на стороне клиента?
Anonymous Quiz
9%
Увеличить таймаут соединения
84%
Внедрить token bucket или leaky bucket на клиенте, ограничивая исходящий поток
6%
Увеличить количество потоков
2%
Перестать использовать API
Это алгоритм, который контролирует скорость отправки запросов:
Корзина с токенами (например, 10 токенов).
Каждый запрос забирает 1 токен.
Корзина пополняется с заданной скоростью (например, 1 токен в 0.1 секунды).
Если токенов нет, запрос задерживается или отклоняется.
Leaky bucket — аналогичен, но ограничивает не пиковую скорость, а среднюю.
Почему это должен делать клиент?
Если клиент превышает лимиты API, он получит HTTP 429 («Too Many Requests») и может быть заблокирован. Клиент сам должен ограничивать свою нагрузку, чтобы не перегружать внешний сервис и не терять запросы.
Реальный пример
Twitter API ограничивает 300 запросов на 15 минут. Клиентские библиотеки (например, Tweepy) содержат встроенный token bucket. Без него приложение поймает 429 и упадёт.
Что должен зафиксировать аналитик
Требование: «На стороне клиента реализовать ограничение частоты запросов в соответствии со спецификацией API (token bucket)».
Параметры: максимальная скорость, размер корзины, стратегия при переполнении (блокировка, очередь).
Обработка ошибок 429: увеличение задержки (exponential backoff).
Вывод: Rate limiting — обязанность не только провайдера API, но и клиента. Аналитик должен включать это требование в спецификации интеграций.
Please open Telegram to view this post
VIEW IN TELEGRAM