Конец эпохи паролей: что придет на смену?
В прошлом посте разобрали, как хранятся пароли. Хеши, соль, перчик, bcrypt – всё красиво. Но есть проблема.
Пароль можно украсть. Фишинг, кейлоггер, утечка с другого сервиса, где ты использовал тот же пароль. И всё – злоумышленник заходит как ты.
Причём существуют целые базы утечек – миллиарды паролей, собранных из взломов разных сервисов. При брутфорсе они перебираются первыми. Если твой пароль когда-то утёк хоть откуда-то – его подберут не за годы, а за секунды.
Мне как-то пришло сообщение в телеге – мол, проголосуйте за девочку. От человека, с которым давно не общался. И так живенько написано. А там вход через телегу, бац-бац – и у тебя нет аккаунта. Ну, у меня стоит облачный пароль, поэтому угнать мой аккаунт не вышло. Но сама схема рабочая – без второго фактора люди теряют аккаунты за секунды.
Поэтому одного пароля уже давно недостаточно.
Что такое 2FA
Двухфакторная аутентификация – два разных доказательства для входа:
🔸 Что-то, что ты знаешь – пароль
🔸 Что-то, что ты имеешь – телефон, ключ, приложение
Даже если пароль утёк, без второго фактора войти не получится.
Варианты второго фактора
SMS-код – самый знакомый. Сервер генерирует код, шлёт через SMS-шлюз, ты вводишь. Просто, но ненадёжно: SIM можно перевыпустить (SIM-свопинг), SMS – перехватить через уязвимость SS7, а код – выманить фишингом в реальном времени. Лучше, чем ничего, но самый слабый вариант. А еще SMS-ки стоят денюжек. Коды на почты, в ТГ аккаунты и другие сервисы – в той же категории.
TOTP – одноразовые коды из приложения (Google Authenticator, Authy, Яндекс.Ключ). При настройке сканируешь QR-код – секретный ключ сохраняется на устройстве. Каждые 30 секунд приложение генерирует новый код из этого ключа и текущего времени. Сервер делает то же самое и сравнивает. Секрет не передаётся по сети после настройки – перехватить нечего.
Push-уведомления – то, что делают банки и, например, Яндекс. Вместо кода получаешь push: "Вы входите с устройства X?" → нажимаешь "Да". Под капотом – асимметричная криптография: устройство подписывает ответ приватным ключом, который никогда не покидает телефон.
Физические ключи и токены – YubiKey, смарт-карты, корпоративные ID-карты. Тот же принцип: приватный ключ зашит в устройство, вытащить его нельзя. Воткнул ключ в USB или приложил карту – подтвердил личность. В корпоративной среде это стандарт уже давно.
Фактор владения побеждает
А теперь интересное. Некоторые сервисы вообще отказались от паролей:
🔸 Telegram – нет пароля по умолчанию. Вход только через код на устройство. Облачный пароль – это опциональный второй фактор. Всё наоборот: владение телефоном – первый фактор, пароль – дополнительная защита
🔸 Microsoft – разрешает удалить пароль из аккаунта целиком, вход через Authenticator или Passkey
🔸 WhatsApp, Signal – только номер + устройство
🔸 Passkeys (Apple, Google, Microsoft) – стандарт FIDO2/WebAuthn. Приватный ключ на устройстве + биометрия. Пароля нет вообще. Фишинг невозможен – ключ привязан к домену
Тренд понятен: фактор владения (телефон, ключ, токен) оказался надёжнее фактора знания (пароль). Пароль можно подобрать, перехватить, выманить. Физическое устройство – нет.
Такое требование, как «поддержка 2FA», может показаться конкретной задачей. Но на самом деле это выбор: какой фактор, какая интеграция, какие риски. И, может, стоит спросить: а нужен ли вообще пароль?
Диаграммы процесса TOTP приложу в комментах для наглядности
А какой второй фактор используете вы? Есть ли сервисы, где вы уже забыли о необходимости вводить пароль? Или вы просто забыли пароль?
@analyst_exe
В прошлом посте разобрали, как хранятся пароли. Хеши, соль, перчик, bcrypt – всё красиво. Но есть проблема.
Пароль можно украсть. Фишинг, кейлоггер, утечка с другого сервиса, где ты использовал тот же пароль. И всё – злоумышленник заходит как ты.
Причём существуют целые базы утечек – миллиарды паролей, собранных из взломов разных сервисов. При брутфорсе они перебираются первыми. Если твой пароль когда-то утёк хоть откуда-то – его подберут не за годы, а за секунды.
Мне как-то пришло сообщение в телеге – мол, проголосуйте за девочку. От человека, с которым давно не общался. И так живенько написано. А там вход через телегу, бац-бац – и у тебя нет аккаунта. Ну, у меня стоит облачный пароль, поэтому угнать мой аккаунт не вышло. Но сама схема рабочая – без второго фактора люди теряют аккаунты за секунды.
Поэтому одного пароля уже давно недостаточно.
Что такое 2FA
Двухфакторная аутентификация – два разных доказательства для входа:
🔸 Что-то, что ты знаешь – пароль
🔸 Что-то, что ты имеешь – телефон, ключ, приложение
Даже если пароль утёк, без второго фактора войти не получится.
Варианты второго фактора
SMS-код – самый знакомый. Сервер генерирует код, шлёт через SMS-шлюз, ты вводишь. Просто, но ненадёжно: SIM можно перевыпустить (SIM-свопинг), SMS – перехватить через уязвимость SS7, а код – выманить фишингом в реальном времени. Лучше, чем ничего, но самый слабый вариант. А еще SMS-ки стоят денюжек. Коды на почты, в ТГ аккаунты и другие сервисы – в той же категории.
TOTP – одноразовые коды из приложения (Google Authenticator, Authy, Яндекс.Ключ). При настройке сканируешь QR-код – секретный ключ сохраняется на устройстве. Каждые 30 секунд приложение генерирует новый код из этого ключа и текущего времени. Сервер делает то же самое и сравнивает. Секрет не передаётся по сети после настройки – перехватить нечего.
Push-уведомления – то, что делают банки и, например, Яндекс. Вместо кода получаешь push: "Вы входите с устройства X?" → нажимаешь "Да". Под капотом – асимметричная криптография: устройство подписывает ответ приватным ключом, который никогда не покидает телефон.
Физические ключи и токены – YubiKey, смарт-карты, корпоративные ID-карты. Тот же принцип: приватный ключ зашит в устройство, вытащить его нельзя. Воткнул ключ в USB или приложил карту – подтвердил личность. В корпоративной среде это стандарт уже давно.
Фактор владения побеждает
А теперь интересное. Некоторые сервисы вообще отказались от паролей:
🔸 Telegram – нет пароля по умолчанию. Вход только через код на устройство. Облачный пароль – это опциональный второй фактор. Всё наоборот: владение телефоном – первый фактор, пароль – дополнительная защита
🔸 Microsoft – разрешает удалить пароль из аккаунта целиком, вход через Authenticator или Passkey
🔸 WhatsApp, Signal – только номер + устройство
🔸 Passkeys (Apple, Google, Microsoft) – стандарт FIDO2/WebAuthn. Приватный ключ на устройстве + биометрия. Пароля нет вообще. Фишинг невозможен – ключ привязан к домену
Тренд понятен: фактор владения (телефон, ключ, токен) оказался надёжнее фактора знания (пароль). Пароль можно подобрать, перехватить, выманить. Физическое устройство – нет.
Такое требование, как «поддержка 2FA», может показаться конкретной задачей. Но на самом деле это выбор: какой фактор, какая интеграция, какие риски. И, может, стоит спросить: а нужен ли вообще пароль?
Диаграммы процесса TOTP приложу в комментах для наглядности
А какой второй фактор используете вы? Есть ли сервисы, где вы уже забыли о необходимости вводить пароль? Или вы просто забыли пароль?
@analyst_exe
🔥11
Как UI заставляет пользователя нажимать «нужные» кнопки
Утро. Электричка. Покупаю билет в терминале. И замечаю три сценария, в которых выбор делается за меня.
1. На экране покупки по умолчанию стоит "Записать на карту? – Да". Не бумажный билет, а именно карта. Я ничего не нажимал – за меня уже решили. Зачем? Меньше бумажных билетов = меньше расходников, меньше мусора, больше людей привыкает к картам.
2. Жму "Купить", затем возвращаюсь по кнопке "Назад" – и переключатель "Записать на карту?" сам перекинулся на "Нет", а кнопка "Купить" поменялась на "Купить бумажный билет". Терминал понял: раз ты вернулся с экрана карты – значит, карты нет. И не заставляет тебя переключать вручную. Мелочь, но экономит секунды в очереди.
3. Экран оплаты. Кнопка "Оплата банковской картой" – большая. "Оплата через СБП" – меньше, не так бросается в глаза. Почему? Представим: утро, толпа, все торопятся. Приложить карту к терминалу – секунда. Достать телефон, открыть приложение банка, найти СБП, отсканировать QR – дольше. Большая кнопка = быстрый сценарий = меньше очередь.
Каждый из этих дефолтов – продуктовое решение, зашитое в интерфейс.
Это не просто визуальное оформление. Это подталкивание к нужному поведению через UI. Ничего не запрещают – просто делают нужный вариант удобнее.
Где ещё это работает:
🔸 Галочка "Согласен на рассылку" – по умолчанию вкл/выкл меняет конверсию в разы
🔸 "Рекомендуемый тариф" – выделен цветом, хотя необязательно лучший для тебя
🔸 Подписки на сервисы – 2 клика чтобы подписаться, 10 – чтобы отписаться
Почему это важно для аналитика
Когда пишешь требования к интерфейсу – ты не просто описываешь кнопки. Ты решаешь:
🔸 Какое значение стоит по умолчанию – и это определяет, что выберет 80% пользователей
🔸 Какая кнопка больше – и это определяет основной сценарий
🔸 Что происходит при нажатии "Назад" – и это определяет, насколько система умная
Дефолты – это не "ну пусть будет так". Это самое сильное продуктовое решение в интерфейсе.
Замечали подобное? Где ещё UI незаметно делает выбор за вас?
@analyst_exe
Утро. Электричка. Покупаю билет в терминале. И замечаю три сценария, в которых выбор делается за меня.
1. На экране покупки по умолчанию стоит "Записать на карту? – Да". Не бумажный билет, а именно карта. Я ничего не нажимал – за меня уже решили. Зачем? Меньше бумажных билетов = меньше расходников, меньше мусора, больше людей привыкает к картам.
2. Жму "Купить", затем возвращаюсь по кнопке "Назад" – и переключатель "Записать на карту?" сам перекинулся на "Нет", а кнопка "Купить" поменялась на "Купить бумажный билет". Терминал понял: раз ты вернулся с экрана карты – значит, карты нет. И не заставляет тебя переключать вручную. Мелочь, но экономит секунды в очереди.
3. Экран оплаты. Кнопка "Оплата банковской картой" – большая. "Оплата через СБП" – меньше, не так бросается в глаза. Почему? Представим: утро, толпа, все торопятся. Приложить карту к терминалу – секунда. Достать телефон, открыть приложение банка, найти СБП, отсканировать QR – дольше. Большая кнопка = быстрый сценарий = меньше очередь.
Каждый из этих дефолтов – продуктовое решение, зашитое в интерфейс.
Это не просто визуальное оформление. Это подталкивание к нужному поведению через UI. Ничего не запрещают – просто делают нужный вариант удобнее.
Где ещё это работает:
🔸 Галочка "Согласен на рассылку" – по умолчанию вкл/выкл меняет конверсию в разы
🔸 "Рекомендуемый тариф" – выделен цветом, хотя необязательно лучший для тебя
🔸 Подписки на сервисы – 2 клика чтобы подписаться, 10 – чтобы отписаться
Почему это важно для аналитика
Когда пишешь требования к интерфейсу – ты не просто описываешь кнопки. Ты решаешь:
🔸 Какое значение стоит по умолчанию – и это определяет, что выберет 80% пользователей
🔸 Какая кнопка больше – и это определяет основной сценарий
🔸 Что происходит при нажатии "Назад" – и это определяет, насколько система умная
Дефолты – это не "ну пусть будет так". Это самое сильное продуктовое решение в интерфейсе.
Замечали подобное? Где ещё UI незаметно делает выбор за вас?
@analyst_exe
❤11🔥6
Как я сделал себе девопса из папки и текстового файла
У меня десктоп на Ubuntu. Свежее ядро, видеокарта NVIDIA, Wayland — в общем, всё то, что периодически ломается. И я не девопс. Я аналитик, который хочет, чтобы система просто работала.
Недавно у меня опять отвалилось переключение языка (а когда что-то ломается, я не терплю, а чиню). Раньше я бы два часа гуглил, копировал команды с StackOverflow, ломал что-нибудь ещё – и в итоге починил бы, но не понял как. А через месяц всё заново, потому что ничего не записал.
В этот раз я сделал по-другому (после 10 раз общения с ИИ без контекста, конечно же).
Что я сделал
Создал папку
Всё. Это вся "архитектура".
Как это работает
Запускаю Claude Code в этой папке. Он читает
Агент:
🔸 Читает логи – видит, что месяц назад уже была проблема с раскладкой
🔸 Диагностирует – выполняет команды, смотрит конфиги
🔸 Фиксит – перед опасными командами спрашивает подтверждение
🔸 Записывает всё в лог:
В следующий раз агент не начинает с нуля. Читает историю, не тратит время на тупиковые решения.
Знакомо?
Если убрать слово "Linux" – это ровно то, чем мы занимаемся как аналитики:
🔸
🔸 Он же – ТЗ для исполнителя (агента)
🔸 logs/ – журнал решений, тот же changelog
🔸 Вся папка – инструкция для повторяемого процесса
Обычно мы описываем чужие системы для чужих исполнителей. А тут – свою систему для своего агента.
Что может пойти не так
Агент выполняет команды с правами твоего пользователя. Если ты не понимаешь, что он делает – ты не делегируешь, а играешь в рулетку.
Что я делаю:
🔸 Читаю команды перед подтверждением – rm -rf точно замечу
🔸 Храню папку в git: если наломает дров – откачусь
🔸 sudo-команды подтверждаю вручную – вижу, что агент хочет сделать с правами суперпользователя
И побочный эффект, которого не ожидал: чем чаще читаешь, что делает агент – тем больше сам разбираешься. Я не учил systemd специально. Но после десятка сессий уже понимаю, что такое
Выводы
🔸 Не обязательно быть экспертом – достаточно уметь описать контекст, поставить задачу и организовать процесс так, чтобы знания не терялись
🔸 Это тот же навык, который мы используем в аналитике – просто направленный на другую задачу
🔸 AI-агент без контекста – гугл с автодополнением. С контекстом и историей – младший коллега, который помнит прошлый спринт
🔸 Делегировать – значит описать, проконтролировать и залогировать
Всего лишь папка, текстовый файл и привычка записывать. Это не рокет-сайенс. Но работает точно лучше, чем "загуглю и как-нибудь починю".
А что вы делегируете AI-агентам кроме кода и текстов? Любопытно узнать самый неожиданный кейс)
@analyst_exe
У меня десктоп на Ubuntu. Свежее ядро, видеокарта NVIDIA, Wayland — в общем, всё то, что периодически ломается. И я не девопс. Я аналитик, который хочет, чтобы система просто работала.
Недавно у меня опять отвалилось переключение языка (а когда что-то ломается, я не терплю, а чиню). Раньше я бы два часа гуглил, копировал команды с StackOverflow, ломал что-нибудь ещё – и в итоге починил бы, но не понял как. А через месяц всё заново, потому что ничего не записал.
В этот раз я сделал по-другому (после 10 раз общения с ИИ без контекста, конечно же).
Что я сделал
Создал папку
devops/ и один файл — CLAUDE.md. Это инструкция для Claude Code (AI-агент, который работает в терминале). Вот суть:# Система
- OS: Ubuntu 25.04, ядро 6.14
- GPU: RTX 5070 Ti, драйвер 570
- Сервисы: Docker, PostgreSQL, Nginx
# Правила
- Перед началом – прочитай логи из logs/
- Каждое действие логируй в logs/
- Не трогай конфиги без бэкапа
- После фикса – проверь, что не сломал другое
Всё. Это вся "архитектура".
Как это работает
Запускаю Claude Code в этой папке. Он читает
CLAUDE.md – и узнает: какая система, что стоит, что чинили раньше. Далее сообщаю о проблеме: "раскладка крашит сессию, почини".Агент:
🔸 Читает логи – видит, что месяц назад уже была проблема с раскладкой
🔸 Диагностирует – выполняет команды, смотрит конфиги
🔸 Фиксит – перед опасными командами спрашивает подтверждение
🔸 Записывает всё в лог:
# 2025-02-15: Переключение раскладки
Проблема: после обновления GNOME 48 сессия падает
Диагностика: input-sources пустой, ошибки extension
Решение: пересоздал input-sources, отключил расширение
Проверка: переключил 50 раз — не крашится
В следующий раз агент не начинает с нуля. Читает историю, не тратит время на тупиковые решения.
Знакомо?
Если убрать слово "Linux" – это ровно то, чем мы занимаемся как аналитики:
🔸
CLAUDE.md – это AS-IS системы🔸 Он же – ТЗ для исполнителя (агента)
🔸 logs/ – журнал решений, тот же changelog
🔸 Вся папка – инструкция для повторяемого процесса
Обычно мы описываем чужие системы для чужих исполнителей. А тут – свою систему для своего агента.
Что может пойти не так
Агент выполняет команды с правами твоего пользователя. Если ты не понимаешь, что он делает – ты не делегируешь, а играешь в рулетку.
Что я делаю:
🔸 Читаю команды перед подтверждением – rm -rf точно замечу
🔸 Храню папку в git: если наломает дров – откачусь
🔸 sudo-команды подтверждаю вручную – вижу, что агент хочет сделать с правами суперпользователя
И побочный эффект, которого не ожидал: чем чаще читаешь, что делает агент – тем больше сам разбираешься. Я не учил systemd специально. Но после десятка сессий уже понимаю, что такое
systemctl restart и зачем journalctl -xe. Делегирование не отупляет – оно учит, если не жмёшь "подтвердить" с закрытыми глазами.Выводы
🔸 Не обязательно быть экспертом – достаточно уметь описать контекст, поставить задачу и организовать процесс так, чтобы знания не терялись
🔸 Это тот же навык, который мы используем в аналитике – просто направленный на другую задачу
🔸 AI-агент без контекста – гугл с автодополнением. С контекстом и историей – младший коллега, который помнит прошлый спринт
🔸 Делегировать – значит описать, проконтролировать и залогировать
Всего лишь папка, текстовый файл и привычка записывать. Это не рокет-сайенс. Но работает точно лучше, чем "загуглю и как-нибудь починю".
А что вы делегируете AI-агентам кроме кода и текстов? Любопытно узнать самый неожиданный кейс)
@analyst_exe
🔥10❤4
Как пройти в метро за 1 рубль
Приложил карту к турникету – списался 1₽. Через минуту пришло второе уведомление – 83₽.
С самокатом похожая история: при привязке карты списался 1₽, а после поездки – 189₽ за 20 минут.
Снаружи выглядит одинаково. Два списания, задержка между ними. Если вы хоть раз видели в выписке транзакцию на 1₽ и не понимали откуда она – сейчас разберёмся.
Внутри – два совершенно разных паттерна.
Самокат: авторизация + списание
Когда вы сканируете QR на самокате, приложение не знает, сколько вы накатаете. 5 минут? Час? Итоговая сумма неизвестна. Поэтому:
🔸 Шаг 1 – авторизация. Приложение просит банк проверить карту и заморозить 1₽. Банк отвечает: «Карта живая, деньги есть». Самокат разблокирован.
🔸 Шаг 2 – списание. Поездка окончена. Сервис посчитал сумму – 189₽ за 20 минут. Отправляет в банк: «Списывай». Холд снимается, реальная сумма уходит со счёта.
Между этими фазами – время. Потому что бизнес-логика требует подождать: сумма определится только когда вы закончите поездку.
Тот же паттерн в каршеринге, такси, аренде – везде, где итоговая сумма неизвестна на старте.
Причина двух фаз – бизнесовая. Мы не можем списать сразу, потому что не знаем сколько.
Ладно, с самокатом разобрались. А теперь – метро. И тут всё наоборот.
Метро: отложенная авторизация
В метро всё иначе. Сумма известна заранее – 83₽ по банковской карте. Казалось бы, списывай сразу. Но нет.
Через турникеты загруженной станции в час пик проходят тысячи людей в минуту. Турникет должен открыться за доли секунды. А полный цикл банковской транзакции – это цепочка: терминал → банк-эквайер → платёжная система → банк-эмитент → ответ обратно. Это секунды. В час пик такая задержка приведет к очереди до входа в вестибюль.
Поэтому турникет делает минимум: проверил карту, если не в стоп-листе – открылся. А полная транзакция уходит в фоновую очередь и обрабатывается позже. Сначала пропусти, потом разберись.
Это отложенная авторизация – система не ждёт подтверждения, а обрабатывает транзакцию в фоне. Данные «догонят» реальность чуть позже. Зато пропускная способность – тысячи человек в минуту.
Причина двух фаз – техническая. Мы знаем сколько, но не можем себе позволить ждать.
Почему аналитику важно это различать?
Потому что решения – разные.
Если причина бизнесовая (сумма неизвестна) – закладывайте два шага: заморозить и списать. Предусматривайте таймаут на холд (до 30 дней, потом деньги размораживаются) и сценарий отката. Нарисовали одно действие «оплатить» – потеряли половину логики. Видел кейс: аналитик описал оплату подписки одним действием «списать». Без авторизации, без проверки карты. В прод ушло как есть. Первый баг прилетел, когда у пользователя сменилась карта – система молча списала сумму с несуществующего счёта и неделю показывала «подписка активна».
Если причина техническая (нагрузка) – закладывайте фоновую обработку: очередь, отложенное списание, повторные попытки при сбоях. Заложили синхронный ответ на каждый запрос – система ляжет под нагрузкой.
Когда видите задержку между операциями, первый вопрос: это бизнес не знает итоговое значение, или система не тянет синхронно?
Ответ на этот вопрос определяет архитектуру.
Теперь вы знаете, откуда берётся этот загадочный рубль в выписке. Перешлите тому, кто каждый раз дёргается, когда видит списание на 1₽.
А в следующем посте – разберём сам турникет. Одна железка, три способа оплаты: Тройка, банковская карта, Face Pay. Три совершенно разных архитектуры внутри одного устройства.
p.s. покатался на метро называется...
@analyst_exe
Приложил карту к турникету – списался 1₽. Через минуту пришло второе уведомление – 83₽.
С самокатом похожая история: при привязке карты списался 1₽, а после поездки – 189₽ за 20 минут.
Снаружи выглядит одинаково. Два списания, задержка между ними. Если вы хоть раз видели в выписке транзакцию на 1₽ и не понимали откуда она – сейчас разберёмся.
Внутри – два совершенно разных паттерна.
Самокат: авторизация + списание
Когда вы сканируете QR на самокате, приложение не знает, сколько вы накатаете. 5 минут? Час? Итоговая сумма неизвестна. Поэтому:
🔸 Шаг 1 – авторизация. Приложение просит банк проверить карту и заморозить 1₽. Банк отвечает: «Карта живая, деньги есть». Самокат разблокирован.
🔸 Шаг 2 – списание. Поездка окончена. Сервис посчитал сумму – 189₽ за 20 минут. Отправляет в банк: «Списывай». Холд снимается, реальная сумма уходит со счёта.
Между этими фазами – время. Потому что бизнес-логика требует подождать: сумма определится только когда вы закончите поездку.
Тот же паттерн в каршеринге, такси, аренде – везде, где итоговая сумма неизвестна на старте.
Причина двух фаз – бизнесовая. Мы не можем списать сразу, потому что не знаем сколько.
Ладно, с самокатом разобрались. А теперь – метро. И тут всё наоборот.
Метро: отложенная авторизация
В метро всё иначе. Сумма известна заранее – 83₽ по банковской карте. Казалось бы, списывай сразу. Но нет.
Через турникеты загруженной станции в час пик проходят тысячи людей в минуту. Турникет должен открыться за доли секунды. А полный цикл банковской транзакции – это цепочка: терминал → банк-эквайер → платёжная система → банк-эмитент → ответ обратно. Это секунды. В час пик такая задержка приведет к очереди до входа в вестибюль.
Поэтому турникет делает минимум: проверил карту, если не в стоп-листе – открылся. А полная транзакция уходит в фоновую очередь и обрабатывается позже. Сначала пропусти, потом разберись.
Это отложенная авторизация – система не ждёт подтверждения, а обрабатывает транзакцию в фоне. Данные «догонят» реальность чуть позже. Зато пропускная способность – тысячи человек в минуту.
Причина двух фаз – техническая. Мы знаем сколько, но не можем себе позволить ждать.
Почему аналитику важно это различать?
Потому что решения – разные.
Если причина бизнесовая (сумма неизвестна) – закладывайте два шага: заморозить и списать. Предусматривайте таймаут на холд (до 30 дней, потом деньги размораживаются) и сценарий отката. Нарисовали одно действие «оплатить» – потеряли половину логики. Видел кейс: аналитик описал оплату подписки одним действием «списать». Без авторизации, без проверки карты. В прод ушло как есть. Первый баг прилетел, когда у пользователя сменилась карта – система молча списала сумму с несуществующего счёта и неделю показывала «подписка активна».
Если причина техническая (нагрузка) – закладывайте фоновую обработку: очередь, отложенное списание, повторные попытки при сбоях. Заложили синхронный ответ на каждый запрос – система ляжет под нагрузкой.
Когда видите задержку между операциями, первый вопрос: это бизнес не знает итоговое значение, или система не тянет синхронно?
Ответ на этот вопрос определяет архитектуру.
Теперь вы знаете, откуда берётся этот загадочный рубль в выписке. Перешлите тому, кто каждый раз дёргается, когда видит списание на 1₽.
А в следующем посте – разберём сам турникет. Одна железка, три способа оплаты: Тройка, банковская карта, Face Pay. Три совершенно разных архитектуры внутри одного устройства.
@analyst_exe
❤10👍6🔥2🥰1😁1
Сделай вот эту штуку, ну которая выезжает. Снизу. Ну ты понял
Типичный диалог аналитика с дизайнером — как на стройке. "Вот эту хрень вот сюда, а вот эту вот так". Все кивают, а потом приходит не то.
У каждого элемента интерфейса есть нормальное название. Знаете его — одно слово вместо абзаца объяснений.
Откуда вообще эти названия?
🔸 Burger – три полоски похожи на бургер в разрезе (булка-котлета-булка). Придумал Норм Кокс в 1981 году для интерфейса Xerox Star — первого коммерческого ПК с GUI.
🔸 Kebab – три точки вертикально, как мясо на шампуре. Название придумали дизайнеры по аналогии с бургером. Google популяризировал в Material Design.
🔸 Meatball – три точки горизонтально. Фрикадельки в ряд. Apple использует в iOS и macOS.
🔸 Breadcrumbs – "хлебные крошки" из сказки про Гензеля и Гретель. Дети оставляли крошки, чтобы найти дорогу домой. В интерфейсе — цепочка навигации, чтобы пользователь не потерялся.
🔸 Toast – уведомление "выскакивает" снизу экрана, как тост из тостера. Появилось в Android.
🔸 Skeleton – "скелет" контента. Серые плейсхолдеры повторяют форму будущих элементов — текста, картинок, аватарок — как скелет повторяет форму тела.
🔸Accordion – открывается и закрывается, как меха аккордеона.
🔸Carousel – карусель. Элементы крутятся по кругу, как лошадки на карусели.
И так далее...
42 термина. Знаете название — говорите на одном языке с фронтом. Не знаете — "сделай вон ту штуку" и три итерации переделок.
Если хотите узнать про историю и "как это появилось" - с вас🔥 , с меня продолжение
Какой компонент вы до сих пор описываете жестами?
Сохраните себе. Перешлите тому, кто до сих пор пишет "кнопка с тремя полосками" вместо "бургер-меню".
@analyst_exe
Типичный диалог аналитика с дизайнером — как на стройке. "Вот эту хрень вот сюда, а вот эту вот так". Все кивают, а потом приходит не то.
У каждого элемента интерфейса есть нормальное название. Знаете его — одно слово вместо абзаца объяснений.
Откуда вообще эти названия?
🔸 Burger – три полоски похожи на бургер в разрезе (булка-котлета-булка). Придумал Норм Кокс в 1981 году для интерфейса Xerox Star — первого коммерческого ПК с GUI.
🔸 Kebab – три точки вертикально, как мясо на шампуре. Название придумали дизайнеры по аналогии с бургером. Google популяризировал в Material Design.
🔸 Meatball – три точки горизонтально. Фрикадельки в ряд. Apple использует в iOS и macOS.
🔸 Breadcrumbs – "хлебные крошки" из сказки про Гензеля и Гретель. Дети оставляли крошки, чтобы найти дорогу домой. В интерфейсе — цепочка навигации, чтобы пользователь не потерялся.
🔸 Toast – уведомление "выскакивает" снизу экрана, как тост из тостера. Появилось в Android.
🔸 Skeleton – "скелет" контента. Серые плейсхолдеры повторяют форму будущих элементов — текста, картинок, аватарок — как скелет повторяет форму тела.
🔸Accordion – открывается и закрывается, как меха аккордеона.
🔸Carousel – карусель. Элементы крутятся по кругу, как лошадки на карусели.
И так далее...
42 термина. Знаете название — говорите на одном языке с фронтом. Не знаете — "сделай вон ту штуку" и три итерации переделок.
Если хотите узнать про историю и "как это появилось" - с вас
Какой компонент вы до сих пор описываете жестами?
Сохраните себе. Перешлите тому, кто до сих пор пишет "кнопка с тремя полосками" вместо "бургер-меню".
@analyst_exe
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥25❤3👍3
Forwarded from Архитектура, Процессы и котики (Denis Kotov)
«UML Sequence Diagram — язык общения аналитика с командой»
Sequence-диаграмма - это способ показать, кто с кем и в каком порядке взаимодействует в системе. Без длинных описаний, без додумываний - одна схема вместо тысячи слов.
🎬 YouTube: ссылка
VK: ссылка
Разбираем:
• Как строить диаграммы последовательностей и читать чужие;
• Почему это один из главных инструментов в арсенале аналитика;
• Как с их помощью договариваться с разработкой и не терять контекст;
• Где граница между полезной детализацией и перегруженной схемой.
🔥 Смотрите, делитесь мнением в комментариях.
Пишите какие темы разобрать в следующих видео?
Sequence-диаграмма - это способ показать, кто с кем и в каком порядке взаимодействует в системе. Без длинных описаний, без додумываний - одна схема вместо тысячи слов.
🎬 YouTube: ссылка
VK: ссылка
Разбираем:
• Как строить диаграммы последовательностей и читать чужие;
• Почему это один из главных инструментов в арсенале аналитика;
• Как с их помощью договариваться с разработкой и не терять контекст;
• Где граница между полезной детализацией и перегруженной схемой.
🔥 Смотрите, делитесь мнением в комментариях.
Пишите какие темы разобрать в следующих видео?
🔥15❤4
Начало недели vs конец недели
Держимся, переходим в контратаку на работе по левому флангу. Офисный планктон за мнооой, удаленщики прикрывают с тыла! Вперёд товарищи, за премию!
@analyst_exe
Держимся, переходим в контратаку на работе по левому флангу. Офисный планктон за мнооой, удаленщики прикрывают с тыла! Вперёд товарищи, за премию!
@analyst_exe
😁13🤔1
Как пройти в метро за 1 рубль. Часть 2
(первая часть)
Вы прикладываете карту к турникету. Турникет открылся. Хотя денег на счёте – ноль.
Как так? Почему пустили?
Ваш попутчик прикладывает Тройку. Турникет открывается. Никакого сервера даже не спрашивали.
Человек впереди посмотрел в камеру. Турникет открылся. Его лицо обработал сервер, который стоит тут же, в вестибюле.
Одна железка – три принципиально разных архитектуры.
🔶 Тройка работает автономно. Чип на карте хранит баланс – он и есть источник истины. Турникет считывает его локально – решение принимается за миллисекунды, без сервера. Даже если все серверы метро упадут – Тройка продолжит работать. А с 2024 года турникет ещё и записывает отложенное пополнение на карту прямо при проходе: вы пополнили Тройку через приложение, а баланс на чипе обновится, когда приложите карту к турникету.
🔶 Банковская карта – сначала пропусти, потом разберись. Турникет проверяет только одно: нет ли карты в стоп-листе (список карт, с которых метро не смогло списать деньги за прошлые поездки). Нет? Открывается. Фактическое списание произойдёт позже – сначала авторизация (блокируется 1 рубль), потом клиринг (финальный расчёт на полную стоимость).
Если денег на счёте ноль – турникет всё равно откроется. Он не знает ваш баланс. Стоп-лист обновляется не в реальном времени. Перевозчик осознанно принимает этот риск – остановить поток людей дороже, чем потерять 83 рубля.
🔶 Face Pay – распознавание на месте. Гонять каждое лицо в облако – слишком медленно. Поэтому в каждом вестибюле стоят edge-серверы с копией математических слепков лиц. Сравнение происходит тут же, за доли секунды. Но если этот сервер упадёт – Face Pay встанет. Единственное из трех решений, которое зависит от вычислительного сервера на месте.
Все три архитектуры – ответ на один вопрос: что должно работать, даже когда связи нет?
Тройка работает всегда – ей вообще не нужна связь. Банковская карта – пока не попадет в стоп-лист. Face Pay – пока жив сервер в вестибюле. Боромир – заплатит наличными.
Каждая архитектура ошибается по-своему. И каждая жертвует чем-то ради главного.
А чем бы вы пожертвовали, если бы делали систему оплаты с нуля?
P.S. Чем-то мне это напоминает CAP-теорему. Если набираем 🔥 – разберу её на пальцах в следующем посте.
@analyst_exe
(первая часть)
Вы прикладываете карту к турникету. Турникет открылся. Хотя денег на счёте – ноль.
Как так? Почему пустили?
Ваш попутчик прикладывает Тройку. Турникет открывается. Никакого сервера даже не спрашивали.
Человек впереди посмотрел в камеру. Турникет открылся. Его лицо обработал сервер, который стоит тут же, в вестибюле.
Одна железка – три принципиально разных архитектуры.
🔶 Тройка работает автономно. Чип на карте хранит баланс – он и есть источник истины. Турникет считывает его локально – решение принимается за миллисекунды, без сервера. Даже если все серверы метро упадут – Тройка продолжит работать. А с 2024 года турникет ещё и записывает отложенное пополнение на карту прямо при проходе: вы пополнили Тройку через приложение, а баланс на чипе обновится, когда приложите карту к турникету.
🔶 Банковская карта – сначала пропусти, потом разберись. Турникет проверяет только одно: нет ли карты в стоп-листе (список карт, с которых метро не смогло списать деньги за прошлые поездки). Нет? Открывается. Фактическое списание произойдёт позже – сначала авторизация (блокируется 1 рубль), потом клиринг (финальный расчёт на полную стоимость).
Если денег на счёте ноль – турникет всё равно откроется. Он не знает ваш баланс. Стоп-лист обновляется не в реальном времени. Перевозчик осознанно принимает этот риск – остановить поток людей дороже, чем потерять 83 рубля.
🔶 Face Pay – распознавание на месте. Гонять каждое лицо в облако – слишком медленно. Поэтому в каждом вестибюле стоят edge-серверы с копией математических слепков лиц. Сравнение происходит тут же, за доли секунды. Но если этот сервер упадёт – Face Pay встанет. Единственное из трех решений, которое зависит от вычислительного сервера на месте.
Все три архитектуры – ответ на один вопрос: что должно работать, даже когда связи нет?
Тройка работает всегда – ей вообще не нужна связь. Банковская карта – пока не попадет в стоп-лист. Face Pay – пока жив сервер в вестибюле. Боромир – заплатит наличными.
Каждая архитектура ошибается по-своему. И каждая жертвует чем-то ради главного.
А чем бы вы пожертвовали, если бы делали систему оплаты с нуля?
P.S. Чем-то мне это напоминает CAP-теорему. Если набираем 🔥 – разберу её на пальцах в следующем посте.
@analyst_exe
🔥18❤2
This media is not supported in your browser
VIEW IN TELEGRAM
⚡️Пока падают просмотры телеги, РКН отключает мобильный интернет.. мы набрали 10к просмотров в шортсах про UML 🫶
Хоба и туть
Шопинг, модный лук, ты звезда ютуб.. У, ага ага, на канал зайди ко мне, у, ага, ага, лайк ведет меня к мечте...
Готовлю посты!
ОСТАЛСЯ ЛИ ЕЩЕ ПОРОХ В ПОРОХОВНИЦАХ? НЕ ОСЛАБЕЛА ЛИ АНАЛИТИЧЕСКАЯ СИЛА? НЕ ГОРЯТ ЛИ АНАЛИТИКИ НА РАБОТАХ КАЗЕНЫХ?
@analyst_exe
Хоба и туть
Шопинг, модный лук, ты звезда ютуб.. У, ага ага, на канал зайди ко мне, у, ага, ага, лайк ведет меня к мечте...
Готовлю посты!
ОСТАЛСЯ ЛИ ЕЩЕ ПОРОХ В ПОРОХОВНИЦАХ? НЕ ОСЛАБЕЛА ЛИ АНАЛИТИЧЕСКАЯ СИЛА? НЕ ГОРЯТ ЛИ АНАЛИТИКИ НА РАБОТАХ КАЗЕНЫХ?
@analyst_exe
❤12🔥6😁4
Ему нравилось ощущение «я делаю стартап». А потом я спросил про деньги
Мне написали: "ищу инженера для стартапа умного AI-рюкзака, доля в проекте." Ситуация реальная. Продукт изменил, чтобы не палить человека.
Дальше – 15 фич: солнечная панель, подогрев спины, замок по отпечатку, LED-экран на спинке, встроенный повербанк, приложение с токенами за шаги, голосовой ассистент, антивор-сирена. И слово "революция" раз двадцать.
Я задал 8 вопросов. После восьмого человек вышел из чата.
И тут важно понять: это не означает, что человек плохой или хочет кого-то обмануть. Проблема в том, что он сам верит в свою идею – но перепутал фантазию с проектом. Ему нравится ощущение "я делаю стартап". Лендинг, логотип, список фич – всё это создаёт иллюзию движения. А вопросы про покупателя и деньги ломают эту иллюзию. Поэтому он и выходит из чата – не потому что обиделся, а потому что впервые столкнулся с реальностью.
Вот эти 8 вопросов – сохраняй:
🔸 Кто покупатель?
Не "все от 18 до 35", а конкретный человек. Имя, доход, что делает в субботу вечером. Этот вопрос проверяет, разговаривал ли фаундер хоть с одним живым человеком из своей аудитории.
🔸 Какую проблему решаешь?
Не "вау-эффект", а что болит прямо сейчас без твоего продукта. Если проблему нужно объяснять покупателю – значит её не существует.
🔸 Сколько стоит произвести одну штуку?
Себестоимость компонентов при партии в 100 и в 1000 единиц. Этот вопрос вскрывает, считал ли кто-то экономику. Обычно нет. А между идеей и серийным продуктом лежит разница в десятки раз.
🔸 За сколько продаёшь?
И откуда уверенность, что купят? Этот вопрос проверяет связь с реальностью: если себестоимость неизвестна, а цена "ну, тысяч 50" – маржи может не быть вообще.
🔸 Какие 3 фичи из 15 будут в первой версии – и почему именно они?
Этот вопрос проверяет приоритизацию. Кто не может выбрать три – не понимает, что именно в продукте создаёт ценность. 15 фич в первой версии = ни одной готовой.
🔸 Для чего используется искусственный интеллект?
Если мы уберем AI и продукт не перестанет работать – значит AI тут для презентации, не для пользователей.
🔸 Кто в команде?
Железо + прошивка + софт + приложение – это минимум 3-4 инженера. Если ищут одного "на всё" – задачу не декомпозировали.
🔸 Есть деньги на первую версию?
150 тысяч на премиальный продукт с 15 фичами – это не бюджет, это самообман.
Если на 5+ вопросов из 8 ответ – "потом проработаем", проект находится на очень ранней, эмоциональной стадии. Часто в таких случаях человеку важнее сам образ "я делаю стартап", чем проверка гипотез. Это нормально – многие так начинают. Но вкладываясь в проект на таком этапе, мы рискуем потерять время и деньги.
Перешли тому, кому недавно предлагали "долю в перспективном проекте".
P.S. я был обязан это опубликовать. Хоть человек и вышел из канала после общения, может, мои вопросы помогут ему яснее увидеть свой проект
@analyst_exe
Мне написали: "ищу инженера для стартапа умного AI-рюкзака, доля в проекте." Ситуация реальная. Продукт изменил, чтобы не палить человека.
Дальше – 15 фич: солнечная панель, подогрев спины, замок по отпечатку, LED-экран на спинке, встроенный повербанк, приложение с токенами за шаги, голосовой ассистент, антивор-сирена. И слово "революция" раз двадцать.
Я задал 8 вопросов. После восьмого человек вышел из чата.
И тут важно понять: это не означает, что человек плохой или хочет кого-то обмануть. Проблема в том, что он сам верит в свою идею – но перепутал фантазию с проектом. Ему нравится ощущение "я делаю стартап". Лендинг, логотип, список фич – всё это создаёт иллюзию движения. А вопросы про покупателя и деньги ломают эту иллюзию. Поэтому он и выходит из чата – не потому что обиделся, а потому что впервые столкнулся с реальностью.
Вот эти 8 вопросов – сохраняй:
🔸 Кто покупатель?
Не "все от 18 до 35", а конкретный человек. Имя, доход, что делает в субботу вечером. Этот вопрос проверяет, разговаривал ли фаундер хоть с одним живым человеком из своей аудитории.
🔸 Какую проблему решаешь?
Не "вау-эффект", а что болит прямо сейчас без твоего продукта. Если проблему нужно объяснять покупателю – значит её не существует.
🔸 Сколько стоит произвести одну штуку?
Себестоимость компонентов при партии в 100 и в 1000 единиц. Этот вопрос вскрывает, считал ли кто-то экономику. Обычно нет. А между идеей и серийным продуктом лежит разница в десятки раз.
🔸 За сколько продаёшь?
И откуда уверенность, что купят? Этот вопрос проверяет связь с реальностью: если себестоимость неизвестна, а цена "ну, тысяч 50" – маржи может не быть вообще.
🔸 Какие 3 фичи из 15 будут в первой версии – и почему именно они?
Этот вопрос проверяет приоритизацию. Кто не может выбрать три – не понимает, что именно в продукте создаёт ценность. 15 фич в первой версии = ни одной готовой.
🔸 Для чего используется искусственный интеллект?
Если мы уберем AI и продукт не перестанет работать – значит AI тут для презентации, не для пользователей.
🔸 Кто в команде?
Железо + прошивка + софт + приложение – это минимум 3-4 инженера. Если ищут одного "на всё" – задачу не декомпозировали.
🔸 Есть деньги на первую версию?
150 тысяч на премиальный продукт с 15 фичами – это не бюджет, это самообман.
Если на 5+ вопросов из 8 ответ – "потом проработаем", проект находится на очень ранней, эмоциональной стадии. Часто в таких случаях человеку важнее сам образ "я делаю стартап", чем проверка гипотез. Это нормально – многие так начинают. Но вкладываясь в проект на таком этапе, мы рискуем потерять время и деньги.
Перешли тому, кому недавно предлагали "долю в перспективном проекте".
P.S. я был обязан это опубликовать. Хоть человек и вышел из канала после общения, может, мои вопросы помогут ему яснее увидеть свой проект
@analyst_exe
❤12👍1