🛠 #SYSTEMDESIGN: 5 РЕШЕНИЙ, КОТОРЫЕ СПАСУТ ВАШ ПРОЕКТ
Привет, коллеги! 👋 System Design — это компромиссы. Разберём 5 кейсов, где правильные решения спасли бизнес. 🚀
🔁 КЕЙС 1: RETRY + CIRCUIT BREAKER
Платёжный шлюз падал с 503. Сервис терял деньги.
Решение:
Retry спасает от временных сбоев, Circuit Breaker — от лавины.
Вывод: Интеграции = Retry + Circuit Breaker.
📨 КЕЙС 2: АСИНХРОННОСТЬ ДЛЯ УВЕДОМЛЕНИЙ
При регистрации email и SMS тормозили 10 секунд.
Решение:
Вывод: Всё не критичное — в очередь.
🔢 КЕЙС 3: ВЕРСИОНИРОВАНИЕ API
Изменили формат ответа — мобильное приложение упало.
Решение:
Вывод: Версионируйте API с первого дня.
📁 КЕЙС 4: ЗАГРУЗКА ФАЙЛОВ В S3
Аватарки через бэкенд убивали сервер.
Решение: Подписанные URL.
Вывод: Файлы — в облако, через подписанные URL.
⏱️ КЕЙС 5: АСИНХРОННЫЙ КОЛЛБЭК
Внешний сервис отвечал 30 секунд — пользователь ждал.
Решение:
Вывод: Долгие операции — асинхронно.
✅ ЧЕК-ЛИСТ:
Retry + Circuit Breaker для интеграций
Асинхронность для не критичного
Версионирование API
Файлы через подписанные URL
Webhook для долгих операций
🎯 ИТОГ: System Design — это умные компромиссы. Хороший аналитик помогает команде выбрать решения, которые работают сегодня и не убьют завтра.
#SYSTEMDESIGN
#SYSTEMDESIGN
Привет, коллеги! 👋 System Design — это компромиссы. Разберём 5 кейсов, где правильные решения спасли бизнес. 🚀
🔁 КЕЙС 1: RETRY + CIRCUIT BREAKER
Платёжный шлюз падал с 503. Сервис терял деньги.
Решение:
@retry(stop_max_attempt_number=3)
@circuit_breaker(failure_threshold=5)
def process_payment(data):
return gateway.charge(data)
Retry спасает от временных сбоев, Circuit Breaker — от лавины.
Вывод: Интеграции = Retry + Circuit Breaker.
📨 КЕЙС 2: АСИНХРОННОСТЬ ДЛЯ УВЕДОМЛЕНИЙ
При регистрации email и SMS тормозили 10 секунд.
Решение:
user.save()
queue.send('email', user) # асинхронно
queue.send('sms', user)
return "OK" # 200 мс
Пользователь не ждёт, сбои не ломают UX.
Вывод: Всё не критичное — в очередь.
🔢 КЕЙС 3: ВЕРСИОНИРОВАНИЕ API
Изменили формат ответа — мобильное приложение упало.
Решение:
GET /api/v1/orders # старый формат
GET /api/v2/orders # новый формат
Старые клиенты работают, новые используют v2.
Вывод: Версионируйте API с первого дня.
📁 КЕЙС 4: ЗАГРУЗКА ФАЙЛОВ В S3
Аватарки через бэкенд убивали сервер.
Решение: Подписанные URL.
1. Бэкенд выдаёт временную ссылку на S3
2. Клиент загружает файл напрямую
3. S3 уведомляет бэкенд
Бэкенд не тратит ресурсы на файлы.
Вывод: Файлы — в облако, через подписанные URL.
⏱️ КЕЙС 5: АСИНХРОННЫЙ КОЛЛБЭК
Внешний сервис отвечал 30 секунд — пользователь ждал.
Решение:
1. Запрос → получаем request_id
2. "Ждите уведомление"
3. Webhook с результатом
Пользователь не ждёт, сервер не блокируется.
Вывод: Долгие операции — асинхронно.
✅ ЧЕК-ЛИСТ:
Retry + Circuit Breaker для интеграций
Асинхронность для не критичного
Версионирование API
Файлы через подписанные URL
Webhook для долгих операций
🎯 ИТОГ: System Design — это умные компромиссы. Хороший аналитик помогает команде выбрать решения, которые работают сегодня и не убьют завтра.
#SYSTEMDESIGN
#SYSTEMDESIGN
👍1
📚 #OTHER: КАК АНАЛИТИК СПАС LEGACY-ПРОЕКТ БЕЗ ДОКУМЕНТАЦИИ
Привет, коллеги! 👋
В рубрике #OTHER собираем нестандартные ситуации, которые не вписываются в шаблоны, но без которых профессия аналитика немыслима. Сегодня расскажу историю про расследование в legacy-джунглях. Когда код молчит, документация сгорела, а бизнес требует новую фичу «на вчера». Поехали! 🚀
🔥 КЕЙС: НАЙТИ ИГЛУ В СТОГЕ СПАГЕТТИ-КОДА
Контекст:
Крупный логистический оператор. Система управления заказами написана в 2002 году на Delphi, база данных — Oracle 9i. Автор системы уволился в 2008-м, документация — пара мятых листов с каракулями. Бизнес-процессы за 15 лет изменились до неузнаваемости, но система работает и её надо развивать.
Задача:
Добавить новый тип доставки — «курьером до двери с примеркой». Нужно понять, как сейчас рассчитывается стоимость доставки, чтобы интегрировать новый тариф. Срок — 2 недели.
Команда в панике:
Разработчики боятся трогать код.
Тестировщики не знают, что должно быть правильно.
Бизнес давит: «Мы теряем деньги каждый день».
🕵️ МЕТОД РАБОТЫ АНАЛИТИКА-ДЕТЕКТИВА
Шаг 1. Поиск свидетелей
Оказалось, в компании ещё работает технолог, который принимал ту систему 20 лет назад. Он помнил бизнес-логику:
«Доставка по Москве считалась как вес × 15, но если суммарный вес больше 100 кг — дополнительный коэффициент 0,8. А для области — вес × 20 плюс зональный коэффициент».
📌 Вывод: 80% логики можно восстановить через живых людей. Интервью с ветеранами — золотая жила.
Шаг 2. Reverse engineering через данные
Я выгрузил из базы 50 000 завершённых заказов: входные параметры (вес, габариты, регион) и итоговую стоимость. Построил простую линейную регрессию в Python, которая предсказывала стоимость с точностью 97%. Затем проанализировал, какие признаки важны — так я вычислил скрытые коэффициенты и формулы.
Пример кода для анализа:
Шаг 3. Провокация системы
На тестовом контуре я отправлял «странные» заказы: отрицательный вес, нулевая стоимость, несуществующий регион. Смотрел, какие ошибки вылетают. Иногда ошибки содержали куски кода или названия процедур — это давало зацепки. Например, ошибка «Division by zero in CalculateRegionalCoefficient» подсказала название ключевого метода.
Шаг 4. Археология кода
Не читая всё подряд, я искал маркеры: названия полей из базы, константы, числа. Нашёл блок:
Сверил с бизнес-правилами — оказалось, это надбавка за «дальнее Подмосковье». Задокументировал.
✅ РЕЗУЛЬТАТ
Через 10 дней у меня была точная спецификация алгоритма на человеческом языке. Java-разработчик написал новый микросервис за неделю, тестирование на исторических данных показало 100% совпадение. Бизнес получил новую фичу в срок.
Что важнее кода?
Умение задавать правильные вопросы.
Навыки работы с данными (SQL, Python).
Терпение и методичность.
Коммуникация с ветеранами.
🎯 ИТОГ:
Системный аналитик в мире legacy — это археолог, детектив и переводчик с машинного на человеческий. Навыки работы с «прочим» — с отсутствием документации, молчащим кодом и утерянными знаниями — отличают настоящего профессионала.
Помните: каждая непонятная строчка кода — это чьё-то бизнес-правило, за которое кто-то платил деньги. Ваша задача — вернуть этому правилу смысл.
#OTHER
Привет, коллеги! 👋
В рубрике #OTHER собираем нестандартные ситуации, которые не вписываются в шаблоны, но без которых профессия аналитика немыслима. Сегодня расскажу историю про расследование в legacy-джунглях. Когда код молчит, документация сгорела, а бизнес требует новую фичу «на вчера». Поехали! 🚀
🔥 КЕЙС: НАЙТИ ИГЛУ В СТОГЕ СПАГЕТТИ-КОДА
Контекст:
Крупный логистический оператор. Система управления заказами написана в 2002 году на Delphi, база данных — Oracle 9i. Автор системы уволился в 2008-м, документация — пара мятых листов с каракулями. Бизнес-процессы за 15 лет изменились до неузнаваемости, но система работает и её надо развивать.
Задача:
Добавить новый тип доставки — «курьером до двери с примеркой». Нужно понять, как сейчас рассчитывается стоимость доставки, чтобы интегрировать новый тариф. Срок — 2 недели.
Команда в панике:
Разработчики боятся трогать код.
Тестировщики не знают, что должно быть правильно.
Бизнес давит: «Мы теряем деньги каждый день».
🕵️ МЕТОД РАБОТЫ АНАЛИТИКА-ДЕТЕКТИВА
Шаг 1. Поиск свидетелей
Оказалось, в компании ещё работает технолог, который принимал ту систему 20 лет назад. Он помнил бизнес-логику:
«Доставка по Москве считалась как вес × 15, но если суммарный вес больше 100 кг — дополнительный коэффициент 0,8. А для области — вес × 20 плюс зональный коэффициент».
📌 Вывод: 80% логики можно восстановить через живых людей. Интервью с ветеранами — золотая жила.
Шаг 2. Reverse engineering через данные
Я выгрузил из базы 50 000 завершённых заказов: входные параметры (вес, габариты, регион) и итоговую стоимость. Построил простую линейную регрессию в Python, которая предсказывала стоимость с точностью 97%. Затем проанализировал, какие признаки важны — так я вычислил скрытые коэффициенты и формулы.
Пример кода для анализа:
import pandas as pd
from sklearn.linear_model import LinearRegression
data = pd.read_sql("SELECT weight, region, distance, final_cost FROM orders", connection)
X = data[['weight', 'region', 'distance']]
y = data['final_cost']
model = LinearRegression().fit(X, y)
print(model.coef_) # выявили веса
Шаг 3. Провокация системы
На тестовом контуре я отправлял «странные» заказы: отрицательный вес, нулевая стоимость, несуществующий регион. Смотрел, какие ошибки вылетают. Иногда ошибки содержали куски кода или названия процедур — это давало зацепки. Например, ошибка «Division by zero in CalculateRegionalCoefficient» подсказала название ключевого метода.
Шаг 4. Археология кода
Не читая всё подряд, я искал маркеры: названия полей из базы, константы, числа. Нашёл блок:
if Region in [1,3,5,7] then
Coef := 1.2
else
Coef := 1.5
Сверил с бизнес-правилами — оказалось, это надбавка за «дальнее Подмосковье». Задокументировал.
✅ РЕЗУЛЬТАТ
Через 10 дней у меня была точная спецификация алгоритма на человеческом языке. Java-разработчик написал новый микросервис за неделю, тестирование на исторических данных показало 100% совпадение. Бизнес получил новую фичу в срок.
Что важнее кода?
Умение задавать правильные вопросы.
Навыки работы с данными (SQL, Python).
Терпение и методичность.
Коммуникация с ветеранами.
🎯 ИТОГ:
Системный аналитик в мире legacy — это археолог, детектив и переводчик с машинного на человеческий. Навыки работы с «прочим» — с отсутствием документации, молчащим кодом и утерянными знаниями — отличают настоящего профессионала.
Помните: каждая непонятная строчка кода — это чьё-то бизнес-правило, за которое кто-то платил деньги. Ваша задача — вернуть этому правилу смысл.
#OTHER
❤3
📚 #OTHER: КАК ПРОВОДИТЬ ИНТЕРВЬЮ С ЗАКАЗЧИКОМ, ЧТОБЫ НЕ ПОЛУЧИТЬ «КОТА В МЕШКЕ»
Привет, коллеги! 👋
В рубрике #OTHER сегодня поговорим о навыке, который не выучить по учебникам, но без которого аналитик превращается в секретаря-стенографиста. Речь о проведении интервью с заказчиком. Казалось бы, что сложного: пришёл, задал вопросы, записал ответы. Но на практике именно на этом этапе рождаются (или умирают) требования. Разберём реальные кейсы и лайфхаки. Поехали! 🚀
🎭 КЕЙС 1: ИСТОРИЯ ПРО «НАМ НУЖНО КАК В СБЕР»
Ситуация:
Менеджер говорит: «Сделайте личный кабинет как в Сбербанке — удобно и современно». Команда кивает, разработчики рисуют интерфейсы, через месяц показывают — заказчик в ярости: «Это не то, у Сбера по-другому!».
Ошибка аналитика:
Не были заданы уточняющие вопросы. «Как в Сбере» — это не требование, а эмоция.
Что нужно было спросить:
Какие именно функции Сбера вам нравятся? (переводы, история, шаблоны?)
Что вы подразумеваете под «удобно»? (минимум кликов, крупные кнопки, подсказки?)
Покажите, где вы это видели, давайте вместе посмотрим.
Результат:
Совместный просмотр сайта Сбера выявил, что заказчику нравится конкретный виджет — история операций с графиками. Остальное не нужно.
Вывод:
Все абстрактные пожелания («как в...», «современный», «удобный») требуют декомпозиции до конкретных примеров.
🕵️ КЕЙС 2: МОЛЧАЛИВЫЙ ЭКСПЕРТ
Ситуация:
Интервью с главным бухгалтером. На все вопросы отвечает односложно: «да», «нет», «нормально». Время идёт, информации ноль.
Ошибка аналитика:
Не подготовился, не создал доверительную атмосферу, задавал закрытые вопросы.
Что сработало:
Начал с лёгкого: «Расскажите, как проходит ваш типичный день. С чего начинаете работу в системе?»
Переключился на открытые вопросы: «Опишите самую сложную ситуацию, с которой сталкивались при закрытии месяца».
Принёс распечатки текущих отчётов: «Покажите, где обычно возникают ошибки?»
Результат:
Разговорился, выяснили кучу нюансов, которые не были нигде задокументированы.
Вывод:
Если эксперт неразговорчив — меняйте тактику: открытые вопросы, визуальные материалы, сценарии.
📊 КЕЙС 3: ЗАКАЗЧИК-ФАНТАЗЁР
Ситуация:
Владелец продукта сыплет идеями: «А ещё сделаем чат с ИИ, и интеграцию с телеграмом, и блокчейн для лояльности…». Бюджет и сроки нереальны.
Ошибка аналитика:
Записывал всё подряд, не приоритезируя.
Что нужно было сделать:
Техника «Five Whys»: «Для чего вам блокчейн? А какая проблема решается? А что будет, если не сделаем?»
Визуализация скоупа: «Давайте отметим, что войдёт в MVP, а что — в следующие релизы».
Оценка усилий: «Эта функция потребует 3 месяца разработки. Мы можем сдвинуть дату запуска или заменить её на что-то более простое?»
Результат:
От блокчейна отказались, ИИ отложили, MVP запустили вовремя.
Вывод:
Аналитик должен фильтровать и приоритизировать, иначе проект утонет в «хотелках».
✅ ПРАВИЛА УСПЕШНОГО ИНТЕРВЬЮ
Готовься
Изучи предметную область заранее.
Составь список вопросов, но будь готов импровизировать.
Узнай роли участников: кто принимает решения, кто эксперт, кто пользователь.
Создавай комфорт
Начинай с лёгких, нейтральных тем.
Объясни цель интервью и как его результаты помогут.
Не перебивай, дай высказаться.
Задавай правильные вопросы
Открытые: «Как вы делаете это сейчас?» вместо «Вы делаете так?».
Уточняющие: «Что значит "быстро"? 1 секунда или 10?».
Гипотетические: «Что произойдёт, если этот отчёт не сформируется вовремя?».
Используй визуализацию
Рисуй схемы прямо при нём, уточняй: «Я правильно понял, что данные идут так?».
Показывай прототипы или скриншоты похожих систем.
Фиксируй и перепроверяй
Записывай (с разрешения) на диктофон.
После встречи отправляй резюме: «Правильно ли я понял, что...».
Уточняй приоритеты: «Что из этого самое важное?».
Управляй ожиданиями
Сразу обозначай ограничения: «Это технически возможно, но займёт 2 месяца».
Не обещай того, в чём не уверен.
🎯 ИТОГ:
Интервью с заказчиком — это не допрос и не светская беседа. Это исследование, цель которого — докопаться до истинных потребностей, отделить желаемое от необходимого и создать фундамент для успешного проекта.
#OTHER
Привет, коллеги! 👋
В рубрике #OTHER сегодня поговорим о навыке, который не выучить по учебникам, но без которого аналитик превращается в секретаря-стенографиста. Речь о проведении интервью с заказчиком. Казалось бы, что сложного: пришёл, задал вопросы, записал ответы. Но на практике именно на этом этапе рождаются (или умирают) требования. Разберём реальные кейсы и лайфхаки. Поехали! 🚀
🎭 КЕЙС 1: ИСТОРИЯ ПРО «НАМ НУЖНО КАК В СБЕР»
Ситуация:
Менеджер говорит: «Сделайте личный кабинет как в Сбербанке — удобно и современно». Команда кивает, разработчики рисуют интерфейсы, через месяц показывают — заказчик в ярости: «Это не то, у Сбера по-другому!».
Ошибка аналитика:
Не были заданы уточняющие вопросы. «Как в Сбере» — это не требование, а эмоция.
Что нужно было спросить:
Какие именно функции Сбера вам нравятся? (переводы, история, шаблоны?)
Что вы подразумеваете под «удобно»? (минимум кликов, крупные кнопки, подсказки?)
Покажите, где вы это видели, давайте вместе посмотрим.
Результат:
Совместный просмотр сайта Сбера выявил, что заказчику нравится конкретный виджет — история операций с графиками. Остальное не нужно.
Вывод:
Все абстрактные пожелания («как в...», «современный», «удобный») требуют декомпозиции до конкретных примеров.
🕵️ КЕЙС 2: МОЛЧАЛИВЫЙ ЭКСПЕРТ
Ситуация:
Интервью с главным бухгалтером. На все вопросы отвечает односложно: «да», «нет», «нормально». Время идёт, информации ноль.
Ошибка аналитика:
Не подготовился, не создал доверительную атмосферу, задавал закрытые вопросы.
Что сработало:
Начал с лёгкого: «Расскажите, как проходит ваш типичный день. С чего начинаете работу в системе?»
Переключился на открытые вопросы: «Опишите самую сложную ситуацию, с которой сталкивались при закрытии месяца».
Принёс распечатки текущих отчётов: «Покажите, где обычно возникают ошибки?»
Результат:
Разговорился, выяснили кучу нюансов, которые не были нигде задокументированы.
Вывод:
Если эксперт неразговорчив — меняйте тактику: открытые вопросы, визуальные материалы, сценарии.
📊 КЕЙС 3: ЗАКАЗЧИК-ФАНТАЗЁР
Ситуация:
Владелец продукта сыплет идеями: «А ещё сделаем чат с ИИ, и интеграцию с телеграмом, и блокчейн для лояльности…». Бюджет и сроки нереальны.
Ошибка аналитика:
Записывал всё подряд, не приоритезируя.
Что нужно было сделать:
Техника «Five Whys»: «Для чего вам блокчейн? А какая проблема решается? А что будет, если не сделаем?»
Визуализация скоупа: «Давайте отметим, что войдёт в MVP, а что — в следующие релизы».
Оценка усилий: «Эта функция потребует 3 месяца разработки. Мы можем сдвинуть дату запуска или заменить её на что-то более простое?»
Результат:
От блокчейна отказались, ИИ отложили, MVP запустили вовремя.
Вывод:
Аналитик должен фильтровать и приоритизировать, иначе проект утонет в «хотелках».
✅ ПРАВИЛА УСПЕШНОГО ИНТЕРВЬЮ
Готовься
Изучи предметную область заранее.
Составь список вопросов, но будь готов импровизировать.
Узнай роли участников: кто принимает решения, кто эксперт, кто пользователь.
Создавай комфорт
Начинай с лёгких, нейтральных тем.
Объясни цель интервью и как его результаты помогут.
Не перебивай, дай высказаться.
Задавай правильные вопросы
Открытые: «Как вы делаете это сейчас?» вместо «Вы делаете так?».
Уточняющие: «Что значит "быстро"? 1 секунда или 10?».
Гипотетические: «Что произойдёт, если этот отчёт не сформируется вовремя?».
Используй визуализацию
Рисуй схемы прямо при нём, уточняй: «Я правильно понял, что данные идут так?».
Показывай прототипы или скриншоты похожих систем.
Фиксируй и перепроверяй
Записывай (с разрешения) на диктофон.
После встречи отправляй резюме: «Правильно ли я понял, что...».
Уточняй приоритеты: «Что из этого самое важное?».
Управляй ожиданиями
Сразу обозначай ограничения: «Это технически возможно, но займёт 2 месяца».
Не обещай того, в чём не уверен.
🎯 ИТОГ:
Интервью с заказчиком — это не допрос и не светская беседа. Это исследование, цель которого — докопаться до истинных потребностей, отделить желаемое от необходимого и создать фундамент для успешного проекта.
#OTHER
❤1
🏗 АРХИТЕКТУРА ПО ДЛЯ АНАЛИТИКА: КЕЙСЫ С КОДОМ
Привет, коллеги! 👋 Часто слышу: «Архитектура — не моё дело». Это опасное заблуждение. Аналитик закладывает архитектуру через требования. Разберём на реальных кейсах с примерами кода, почему без понимания #ARCHITECTURE проект рискует превратиться в руины. 🏚
📌 Кейс 1: Монолит vs Микросервисы
Задача: Доставка еды. Разработчик пишет монолит:
Проблема: Если упал сервис курьеров — заказ не создаётся. Любое изменение в уведомлениях ломает заказ.
Что должен был заложить аналитик: Асинхронное событие через брокер.
Требование: «Критичные операции синхронны, остальные — асинхронны через брокер». Это развязывает сервисы и повышает отказоустойчивость.
📌 Кейс 2: Нагрузка и кэширование
Задача: Банковский личный кабинет. Аналитик забыл спросить про нагрузку. Разработчик пишет:
Реальность: 10 000 запросов в секунду кладут БД. Баланс открывается 10 секунд.
Правильное требование: «Время отклика < 1 секунды при 10 000 RPS». Решение — кэш:
Вывод: NFR диктуют архитектуру.
📌 Кейс 3: Синхронный вызов, который всё тормозит
Задача: Онлайн-кинотеатр — при старте фильма обновить рекомендации.
Плохо (всё синхронно):
Хорошо (асинхронно):
Требование: «Некритичные интеграции — асинхронны с гарантированной доставкой».
📌 Кейс 4: Забыли про GDPR
Задача: FinTech для Европы. Аналитик не учёл требования. Хранят логи вечно:
Правильные требования:
Логи хранятся 90 дней, затем удаляются.
IP хранить в хэшированном виде.
По запросу пользователя — полное удаление.
Реализация TTL:
Запомните: Аналитик не обязан писать код, но обязан понимать последствия своих требований. Примеры выше — не для копирования, а для понимания, как архитектура влияет на бизнес.💡
#ARCHITECHTURE
Привет, коллеги! 👋 Часто слышу: «Архитектура — не моё дело». Это опасное заблуждение. Аналитик закладывает архитектуру через требования. Разберём на реальных кейсах с примерами кода, почему без понимания #ARCHITECTURE проект рискует превратиться в руины. 🏚
📌 Кейс 1: Монолит vs Микросервисы
Задача: Доставка еды. Разработчик пишет монолит:
def create_order(user_id, items):
user = db.users.find_one(user_id)
if user.balance < total_cost(items): raise "Не хватает средств"
db.users.update_one(user_id, {"$inc": {"balance": -total_cost(items)}})
order_id = db.orders.insert_one({"user": user_id, "items": items})
requests.post("http://courier-system/api/assign", json={"order": order_id})
return order_id
Проблема: Если упал сервис курьеров — заказ не создаётся. Любое изменение в уведомлениях ломает заказ.
Что должен был заложить аналитик: Асинхронное событие через брокер.
def create_order(user_id, items):
with db.transaction():
# проверка и списание
user = db.users.find_one(user_id)
if user.balance < total_cost(items): raise
db.users.update_one(user_id, {"$inc": {"balance": -total_cost(items)}})
order_id = db.orders.insert_one({"user": user_id, "items": items})
kafka.produce("order_created", {"order_id": order_id}) # событие
return order_id
Требование: «Критичные операции синхронны, остальные — асинхронны через брокер». Это развязывает сервисы и повышает отказоустойчивость.
📌 Кейс 2: Нагрузка и кэширование
Задача: Банковский личный кабинет. Аналитик забыл спросить про нагрузку. Разработчик пишет:
public AccountInfo getAccount(String userId) {
return jdbc.query("SELECT * FROM accounts WHERE user_id = ?", userId);
}Реальность: 10 000 запросов в секунду кладут БД. Баланс открывается 10 секунд.
Правильное требование: «Время отклика < 1 секунды при 10 000 RPS». Решение — кэш:
public AccountInfo getAccount(String userId) {
AccountInfo cached = redis.get("account:" + userId);
if (cached != null) return cached;
AccountInfo fromDb = jdbc.query(...);
redis.setex("account:" + userId, 60, fromDb); // TTL 60 сек
return fromDb;
}Вывод: NFR диктуют архитектуру.
📌 Кейс 3: Синхронный вызов, который всё тормозит
Задача: Онлайн-кинотеатр — при старте фильма обновить рекомендации.
Плохо (всё синхронно):
def start_movie(user_id, movie_id):
check_subscription(user_id)
deduct_credit(user_id)
recommendations.update(user_id, movie_id) # тормозит — пользователь ждёт
return "ok"
Хорошо (асинхронно):
def start_movie(user_id, movie_id):
check_subscription(user_id)
deduct_credit(user_id)
kafka.produce("movie_started", {"user": user_id, "movie": movie_id}) # не ждём
return "ok"
Требование: «Некритичные интеграции — асинхронны с гарантированной доставкой».
📌 Кейс 4: Забыли про GDPR
Задача: FinTech для Европы. Аналитик не учёл требования. Хранят логи вечно:
CREATE TABLE access_logs (user_id INT, accessed_at TIMESTAMP, ip VARCHAR(45));
Штраф: €20 млн за нарушение GDPR.
Правильные требования:
Логи хранятся 90 дней, затем удаляются.
IP хранить в хэшированном виде.
По запросу пользователя — полное удаление.
Реализация TTL:
db.logs.insert_one({
"user_id": user_id,
"ip_hash": hashlib.sha256(ip.encode()).hexdigest(),
"expire_at": datetime.utcnow() + timedelta(days=90)
})
db.logs.create_index("expire_at", expireAfterSeconds=0) # автоудалениеЗапомните: Аналитик не обязан писать код, но обязан понимать последствия своих требований. Примеры выше — не для копирования, а для понимания, как архитектура влияет на бизнес.
#ARCHITECHTURE
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Необходимые компетенции менеджера в IT
😁2
🔍 ТЕСТИРОВАНИЕ ДЛЯ СИСТЕМНОГО АНАЛИТИКА: НЕ ПРОСТО СДАЛ И ЗАБЫЛ
Привет, коллеги! 👋 Хороший аналитик активно участвует в тестировании — он лучше всех знает, как система должна работать. Разберём на примерах с кодом, как это помогает.
📌 Зачем аналитику тестирование?
✅ Валидация требований
✅ Поиск неучтённых сценариев
✅ Экономия времени (баг на ранней стадии дешевле)
📌 Виды тестирования, где аналитик незаменим
🔹 Приёмочное тестирование (UAT)
Готовим сценарии и проверяем бизнес-требования.
Пример: Оформление заказа с промокодом. Проверяем не только успех, но и:
Промокод истёк
Не применим к товару
Введён с маленькой буквы
🔹 Интеграционное тестирование
Аналитик описывает все возможные ответы внешнего сервиса.
Код (Python):
Кейс: Внешний сервис возвращал 500 при временной ошибке. Разработчик обработал как фатальную. Аналитик настоял на ретраях — баг нашли на стенде, не на проде. ✅
🔹 Регрессионное тестирование
Автоматизируем ключевые бизнес-сценарии.
Код (проверка баланса):
📌 Кейс: «Баг, который нашёл аналитик»
Ситуация: В ТЗ: «При изменении email уведомление на старый и новый адреса». Разработчик сделал только на новый. Тестировщики не заметили — в тест-кейсах не было уточнения.
Что сделал аналитик? Написал приёмочный тест с проверкой двух адресов и провалил приёмку. Баг исправили до проде.
Мораль: Критерии приёмки должны быть конкретными, а аналитик — участвовать в проверке.
📌 Как аналитик может писать автотесты?
Проверять API в Postman
Писать простые скрипты на Python
Формулировать Gherkin-сценарии для Cucumber
Пример Gherkin:
🎯 ИТОГ: ЧТО ДЕЛАТЬ АНАЛИТИКУ?
Участвовать в планировании тестирования
Писать приёмочные тесты
Проверять демо перед показом заказчику
Автоматизировать рутину простыми скриптами
Анализировать баги на проде — они показывают слабые места в требованиях
Помните: Качественный анализ + участие в тестировании = надёжный продукт. Аналитик, который проверяет результат, стоит дороже любого документа. 💰
#TESTING
Привет, коллеги! 👋 Хороший аналитик активно участвует в тестировании — он лучше всех знает, как система должна работать. Разберём на примерах с кодом, как это помогает.
📌 Зачем аналитику тестирование?
✅ Валидация требований
✅ Поиск неучтённых сценариев
✅ Экономия времени (баг на ранней стадии дешевле)
📌 Виды тестирования, где аналитик незаменим
🔹 Приёмочное тестирование (UAT)
Готовим сценарии и проверяем бизнес-требования.
Пример: Оформление заказа с промокодом. Проверяем не только успех, но и:
Промокод истёк
Не применим к товару
Введён с маленькой буквы
🔹 Интеграционное тестирование
Аналитик описывает все возможные ответы внешнего сервиса.
Код (Python):
import requests, time
def test_payment_retry():
response = requests.post("https://payment-gateway/api/pay", json={"order_id": 123})
if response.status_code == 429: # Too Many Requests
time.sleep(5) # повтор через 5 сек
response = requests.post(...)
assert response.status_code == 200
else:
assert response.status_code == 200
Кейс: Внешний сервис возвращал 500 при временной ошибке. Разработчик обработал как фатальную. Аналитик настоял на ретраях — баг нашли на стенде, не на проде. ✅
🔹 Регрессионное тестирование
Автоматизируем ключевые бизнес-сценарии.
Код (проверка баланса):
def test_balance_after_purchase():
user_id = 123
initial = get_balance(user_id)
purchase(user_id, 300)
new_balance = get_balance(user_id)
assert new_balance == initial - 300
📌 Кейс: «Баг, который нашёл аналитик»
Ситуация: В ТЗ: «При изменении email уведомление на старый и новый адреса». Разработчик сделал только на новый. Тестировщики не заметили — в тест-кейсах не было уточнения.
Что сделал аналитик? Написал приёмочный тест с проверкой двух адресов и провалил приёмку. Баг исправили до проде.
Мораль: Критерии приёмки должны быть конкретными, а аналитик — участвовать в проверке.
📌 Как аналитик может писать автотесты?
Проверять API в Postman
Писать простые скрипты на Python
Формулировать Gherkin-сценарии для Cucumber
Пример Gherkin:
Feature: Оформление заказа
Scenario: Успешное оформление с промокодом
Given пользователь авторизован
And в корзине товар на 1000 рублей
And у пользователя есть промокод на скидку 10%
When пользователь применяет промокод
Then сумма заказа уменьшается на 10%
And заказ успешно оформлен
🎯 ИТОГ: ЧТО ДЕЛАТЬ АНАЛИТИКУ?
Участвовать в планировании тестирования
Писать приёмочные тесты
Проверять демо перед показом заказчику
Автоматизировать рутину простыми скриптами
Анализировать баги на проде — они показывают слабые места в требованиях
Помните: Качественный анализ + участие в тестировании = надёжный продукт. Аналитик, который проверяет результат, стоит дороже любого документа. 💰
#TESTING
🔍 ТЕСТИРОВАНИЕ ДЛЯ АНАЛИТИКА: КОД, КЕЙСЫ, ИНСАЙТЫ
Привет, коллеги! 👋 Хороший аналитик не просто пишет требования, но и участвует в тестировании. Почему? Потому что именно вы знаете, как система должна работать на самом деле. Сегодня покажу на реальных кейсах с примерами кода, как аналитик может помочь QA и разработке находить баги до продакшена. 🚀
📌 Кейс 1: Интеграция и ретраи (код на Python)
Ситуация: Платежный шлюз иногда возвращает 503 (сервис временно недоступен). В требованиях написано: «При ошибке повторить запрос». Разработчик сделал один повтор через 1 секунду.
Что сделал аналитик: Написал простой скрипт, который показал, что 1 секунда — слишком мало, сервис не успевает восстановиться.
Результат: Баг нашли на тестовом стенде. В ТЗ добавили экспоненциальную задержку (1, 2, 4 сек) и 3 попытки. 🎯
📌 Кейс 2: Граничные значения (тестируем форму)
Ситуация: В форме заказа есть поле «Количество товаров» от 1 до 999. Разработчик сделал валидацию, но пропустил ноль и отрицательные числа.
Что сделал аналитик: Написал параметризованный тест на Python с библиотекой pytest:
Результат: Тест показал, что 0 и отрицательные числа пропускаются. Разработчик исправил валидацию до выкладки. ✅
📌 Кейс 3: Регрессия (автотест на проверку баланса)
Ситуация: Добавили новую фичу — скидки постоянным клиентам. Нужно убедиться, что старый функционал (списание баланса) не сломался.
Что сделал аналитик: Простой скрипт для smoke-теста:
Результат: Запускаем перед каждым релизом — спим спокойно. 😴
📌 Инструменты для аналитика
Postman — коллекции с автотестами для API (проверка статусов, схем ответа).
Python + requests — быстрые скрипты для сложных сценариев.
pytest — параметризация, фикстуры, отчёты.
Gherkin (Cucumber) — сценарии на понятном бизнесу языке:
🎯 ИТОГ: ЧТО ДЕЛАТЬ АНАЛИТИКУ?
Писать проверяемые требования — с цифрами, диапазонами, примерами.
Готовить тестовые сценарии — включая негативные и граничные.
Автоматизировать рутину — простые скрипты экономят часы ручных проверок.
Участвовать в код-ревью тестов — подсказывать QA, какие кейсы важны.
Помните: Баг, найденный на этапе анализа или тестирования, стоит в 10 раз дешевле, чем на проде. Аналитик с навыками тестирования — золото для команды.💰
#TESTING
Привет, коллеги! 👋 Хороший аналитик не просто пишет требования, но и участвует в тестировании. Почему? Потому что именно вы знаете, как система должна работать на самом деле. Сегодня покажу на реальных кейсах с примерами кода, как аналитик может помочь QA и разработке находить баги до продакшена. 🚀
📌 Кейс 1: Интеграция и ретраи (код на Python)
Ситуация: Платежный шлюз иногда возвращает 503 (сервис временно недоступен). В требованиях написано: «При ошибке повторить запрос». Разработчик сделал один повтор через 1 секунду.
Что сделал аналитик: Написал простой скрипт, который показал, что 1 секунда — слишком мало, сервис не успевает восстановиться.
```python
import requests
import time
def test_payment_retry():
url = "https://payment-gateway/api/pay"
payload = {"order_id": 123, "amount": 1000}
for attempt in range(3):
response = requests.post(url, json=payload)
if response.status_code == 503:
wait_time = 2 ** attempt # 1, 2, 4 секунды
print(f"Попытка {attempt+1} не удалась, ждём {wait_time}с")
time.sleep(wait_time)
else:
assert response.status_code == 200
print("Успех!")
return
assert False, "Все попытки исчерпаны"
Результат: Баг нашли на тестовом стенде. В ТЗ добавили экспоненциальную задержку (1, 2, 4 сек) и 3 попытки. 🎯
📌 Кейс 2: Граничные значения (тестируем форму)
Ситуация: В форме заказа есть поле «Количество товаров» от 1 до 999. Разработчик сделал валидацию, но пропустил ноль и отрицательные числа.
Что сделал аналитик: Написал параметризованный тест на Python с библиотекой pytest:
import pytest
def validate_quantity(q):
return 1 <= q <= 999
@pytest.mark.parametrize("input,expected", [
(0, False), # граница снизу
(1, True), # минимальное допустимое
(500, True), # среднее значение
(999, True), # максимальное допустимое
(1000, False), # граница сверху
(-5, False), # отрицательное
("abc", False) # не число
])
def test_quantity_validation(input, expected):
assert validate_quantity(input) == expected
Результат: Тест показал, что 0 и отрицательные числа пропускаются. Разработчик исправил валидацию до выкладки. ✅
📌 Кейс 3: Регрессия (автотест на проверку баланса)
Ситуация: Добавили новую фичу — скидки постоянным клиентам. Нужно убедиться, что старый функционал (списание баланса) не сломался.
Что сделал аналитик: Простой скрипт для smoke-теста:
def test_balance_after_purchase():
# Данные тестового пользователя
user_id = 999
initial_balance = get_balance(user_id) # предположим, 1000
# Покупаем товар за 300
purchase(user_id, 300)
# Проверяем новый баланс
new_balance = get_balance(user_id)
expected = initial_balance - 300
assert new_balance == expected, f"Ожидалось {expected}, получено {new_balance}"
print("Баланс обновился корректно")
Результат: Запускаем перед каждым релизом — спим спокойно. 😴
📌 Инструменты для аналитика
Postman — коллекции с автотестами для API (проверка статусов, схем ответа).
Python + requests — быстрые скрипты для сложных сценариев.
pytest — параметризация, фикстуры, отчёты.
Gherkin (Cucumber) — сценарии на понятном бизнесу языке:
Feature: Бонусы за регистрацию
Scenario: Новый пользователь получает 500 бонусов
Given пользователь не зарегистрирован
When он регистрируется с телефоном "+79991234567"
Then его бонусный счёт равен 500
🎯 ИТОГ: ЧТО ДЕЛАТЬ АНАЛИТИКУ?
Писать проверяемые требования — с цифрами, диапазонами, примерами.
Готовить тестовые сценарии — включая негативные и граничные.
Автоматизировать рутину — простые скрипты экономят часы ручных проверок.
Участвовать в код-ревью тестов — подсказывать QA, какие кейсы важны.
Помните: Баг, найденный на этапе анализа или тестирования, стоит в 10 раз дешевле, чем на проде. Аналитик с навыками тестирования — золото для команды.
#TESTING
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
📊 SQL ДЛЯ СИСТЕМНОГО АНАЛИТИКА: НЕ ПРОСТО ЗАПРОСЫ, А СУПЕРСИЛА
Привет, коллеги! 👋 Часто слышу: «SQL — это для разработчиков и DBA». На самом деле, SQL — один из главных инструментов аналитика. С его помощью вы можете:
проверять данные, не дожидаясь отчётов;
находить баги быстрее, чем разработчики;
отвечать на вопросы бизнеса за 5 минут.
Сегодня покажу на реальных кейсах, как SQL спасает проекты. 🚀
📌 Кейс 1: «Где мои бонусы?» (проверка гипотезы)
Менеджер жалуется: «Клиенты не получают бонусы за регистрацию!». Разработчики говорят: «Всё работает, проверяли». Вы решаете проверить сами.
Пишете запрос в базу:
Результат: бонусы получают только 30% пользователей, хотя должны все. Баг найден за 2 минуты — разработчик ошибся в условии начисления. Вы сэкономили день споров. ✅
📌 Кейс 2: «Аномалия в продажах» (обнаружение бага)
Бизнес заметил: вчера продажи упали на 20%. Начинается паника. Вы идёте в базу и смотрите динамику по часам:
Обнаруживаете, что провал пришёлся на 14:00–15:00 — именно в это время выкатывали новую версию. Дальше — запрос по конкретному виду товаров:
Выясняется: пропали заказы из категории «Электроника». Оказывается, разработчики задефили изменения в прайсе для этой категории. Без SQL вы бы искали проблему часами. ⏱️
📌 Кейс 3: «Тестовые данные для приёмки» (помощь тестировщикам)
QA нужно проверить сценарий «пользователь с 10 заказами». Вы пишете запрос, который выгружает подходящих пользователей:
Тестировщики получают готовый список реальных пользователей (или их id) и могут быстро проверить сценарий. Никакого ручного подбора данных. 🧪
📌 Кейс 4: «Массовое обновление» (подготовка данных)
Нужно проставить признак «VIP» всем клиентам, у которых сумма покупок > 1 млн. Вместо ручного обновления пишете запрос:
10 секунд — и задача решена. Безопасно, быстро, без ошибок. 🔥
🎯 ЧТО ДАЁТ SQL АНАЛИТИКУ?
Независимость — вы не ждёте отчёты от разработчиков.
Скорость — ответы на вопросы бизнеса за минуты.
Глубина — можете проверить данные на любом уровне детализации.
Доверие — ваши выводы подкреплены фактами, а не догадками.
📚 С ЧЕГО НАЧАТЬ?
Освойте SELECT, WHERE, GROUP BY, JOIN — этого хватит для 80% задач.
Изучите оконные функции (ROW_NUMBER(), LAG()) — они выводят анализ на новый уровень.
Практикуйтесь на учебных базах или в своём проекте (с доступом только на чтение!).
Помните: SQL — это не просто язык запросов, а ваш главный помощник в расследованиях. Чем лучше вы им владеете, тем больше инсайтов можете дать команде.💪
#SQL
Привет, коллеги! 👋 Часто слышу: «SQL — это для разработчиков и DBA». На самом деле, SQL — один из главных инструментов аналитика. С его помощью вы можете:
проверять данные, не дожидаясь отчётов;
находить баги быстрее, чем разработчики;
отвечать на вопросы бизнеса за 5 минут.
Сегодня покажу на реальных кейсах, как SQL спасает проекты. 🚀
📌 Кейс 1: «Где мои бонусы?» (проверка гипотезы)
Менеджер жалуется: «Клиенты не получают бонусы за регистрацию!». Разработчики говорят: «Всё работает, проверяли». Вы решаете проверить сами.
Пишете запрос в базу:
SELECT
DATE(created_at) as reg_date,
COUNT(user_id) as total_users,
COUNT(bonus_id) as users_with_bonus,
ROUND(COUNT(bonus_id) * 100.0 / COUNT(user_id), 2) as percent
FROM users
LEFT JOIN bonuses ON users.user_id = bonuses.user_id
WHERE created_at >= '2024-10-01'
GROUP BY reg_date
ORDER BY reg_date;
Результат: бонусы получают только 30% пользователей, хотя должны все. Баг найден за 2 минуты — разработчик ошибся в условии начисления. Вы сэкономили день споров. ✅
📌 Кейс 2: «Аномалия в продажах» (обнаружение бага)
Бизнес заметил: вчера продажи упали на 20%. Начинается паника. Вы идёте в базу и смотрите динамику по часам:
SELECT
DATE_TRUNC('hour', order_time) as hour,
COUNT(order_id) as orders,
SUM(amount) as revenue
FROM orders
WHERE order_time >= CURRENT_DATE - INTERVAL '2 days'
GROUP BY hour
ORDER BY hour;
Обнаруживаете, что провал пришёлся на 14:00–15:00 — именно в это время выкатывали новую версию. Дальше — запрос по конкретному виду товаров:
SELECT
product_category,
COUNT(order_id) as orders
FROM orders
WHERE order_time BETWEEN '2024-10-15 14:00' AND '2024-10-15 15:00'
GROUP BY product_category;
Выясняется: пропали заказы из категории «Электроника». Оказывается, разработчики задефили изменения в прайсе для этой категории. Без SQL вы бы искали проблему часами. ⏱️
📌 Кейс 3: «Тестовые данные для приёмки» (помощь тестировщикам)
QA нужно проверить сценарий «пользователь с 10 заказами». Вы пишете запрос, который выгружает подходящих пользователей:
SELECT
user_id,
COUNT(order_id) as order_count,
SUM(amount) as total_spent
FROM orders
GROUP BY user_id
HAVING COUNT(order_id) >= 10
ORDER BY order_count DESC
LIMIT 20;
Тестировщики получают готовый список реальных пользователей (или их id) и могут быстро проверить сценарий. Никакого ручного подбора данных. 🧪
📌 Кейс 4: «Массовое обновление» (подготовка данных)
Нужно проставить признак «VIP» всем клиентам, у которых сумма покупок > 1 млн. Вместо ручного обновления пишете запрос:
UPDATE customers
SET is_vip = TRUE
WHERE customer_id IN (
SELECT customer_id
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 1000000
);
10 секунд — и задача решена. Безопасно, быстро, без ошибок. 🔥
🎯 ЧТО ДАЁТ SQL АНАЛИТИКУ?
Независимость — вы не ждёте отчёты от разработчиков.
Скорость — ответы на вопросы бизнеса за минуты.
Глубина — можете проверить данные на любом уровне детализации.
Доверие — ваши выводы подкреплены фактами, а не догадками.
📚 С ЧЕГО НАЧАТЬ?
Освойте SELECT, WHERE, GROUP BY, JOIN — этого хватит для 80% задач.
Изучите оконные функции (ROW_NUMBER(), LAG()) — они выводят анализ на новый уровень.
Практикуйтесь на учебных базах или в своём проекте (с доступом только на чтение!).
Помните: SQL — это не просто язык запросов, а ваш главный помощник в расследованиях. Чем лучше вы им владеете, тем больше инсайтов можете дать команде.
#SQL
Please open Telegram to view this post
VIEW IN TELEGRAM
📊 SQL ДЛЯ АНАЛИТИКА: ОКОННЫЕ ФУНКЦИИ — СЛЕДУЮЩИЙ УРОВЕНЬ
Привет, коллеги! 👋 Вы уже знаете SELECT, JOIN и GROUP BY. Но есть вещь, которая выводит анализ на новый уровень — оконные функции. Они позволяют считать скользящие средние, приросты, доли и ранги без сложных подзапросов. Сегодня разберём на реальных задачах. Поехали! 🚀
📌 Кейс 1: Сравнение продаж с прошлым месяцем (LAG)
Менеджер просит: «Покажи помесячную динамику и прирост к прошлому месяцу». Без оконных функций пришлось бы делать self-join или подзапрос. А так:
Что получим: месячная выручка, прошлая выручка и процент роста. Всё одним запросом! 🔥
📌 Кейс 2: Топ-3 товара в каждой категории (ROW_NUMBER)
Нужно для каждой категории выделить три самых продаваемых товара. Раньше — муть с подзапросами. Теперь:
Результат: аккуратный топ по каждой категории. А если нужны все товары с повторами (если продажи одинаковые) — используйте RANK() или DENSE_RANK(). 🏆
📌 Кейс 3: Скользящее среднее за 7 дней (AVG OVER)
Для отчёта по трендам нужно сгладить дневные скачки. Скользящее среднее — идеально:
Теперь видно тенденцию без шума. Маркетологи будут благодарны! 📈
📌 Кейс 4: Доля товара в общей выручке (SUM OVER)
ABC-анализ: надо понять, какие товары дают 80% выручки. Считаем долю накопленным итогом:
Видим, где граница 80%. Классика для категорийных менеджеров. 📦
🎯 ПОЧЕМУ ЭТО ВАЖНО ДЛЯ АНАЛИТИКА?
Скорость: один запрос вместо трёх.
Гибкость: можно комбинировать с группировками и фильтрами.
Точность: меньше шансов ошибиться в логике.
Освойте оконные функции — и бизнес будет носить вас на руках за быстрые и точные ответы. 💪
#SQL
Привет, коллеги! 👋 Вы уже знаете SELECT, JOIN и GROUP BY. Но есть вещь, которая выводит анализ на новый уровень — оконные функции. Они позволяют считать скользящие средние, приросты, доли и ранги без сложных подзапросов. Сегодня разберём на реальных задачах. Поехали! 🚀
📌 Кейс 1: Сравнение продаж с прошлым месяцем (LAG)
Менеджер просит: «Покажи помесячную динамику и прирост к прошлому месяцу». Без оконных функций пришлось бы делать self-join или подзапрос. А так:
SELECT
DATE_TRUNC('month', order_date) as month,
SUM(amount) as revenue,
LAG(SUM(amount)) OVER (ORDER BY DATE_TRUNC('month', order_date)) as prev_revenue,
(SUM(amount) - LAG(SUM(amount)) OVER (ORDER BY DATE_TRUNC('month', order_date))) /
LAG(SUM(amount)) OVER (ORDER BY DATE_TRUNC('month', order_date)) * 100 as growth_percent
FROM orders
GROUP BY month
ORDER BY month;
Что получим: месячная выручка, прошлая выручка и процент роста. Всё одним запросом! 🔥
📌 Кейс 2: Топ-3 товара в каждой категории (ROW_NUMBER)
Нужно для каждой категории выделить три самых продаваемых товара. Раньше — муть с подзапросами. Теперь:
WITH ranked_products AS (
SELECT
category_id,
product_id,
SUM(quantity) as total_sold,
ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY SUM(quantity) DESC) as rn
FROM order_items
GROUP BY category_id, product_id
)
SELECT category_id, product_id, total_sold
FROM ranked_products
WHERE rn <= 3;
Результат: аккуратный топ по каждой категории. А если нужны все товары с повторами (если продажи одинаковые) — используйте RANK() или DENSE_RANK(). 🏆
📌 Кейс 3: Скользящее среднее за 7 дней (AVG OVER)
Для отчёта по трендам нужно сгладить дневные скачки. Скользящее среднее — идеально:
SELECT
date,
revenue,
AVG(revenue) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) as avg_7d
FROM daily_revenue
ORDER BY date;
Теперь видно тенденцию без шума. Маркетологи будут благодарны! 📈
📌 Кейс 4: Доля товара в общей выручке (SUM OVER)
ABC-анализ: надо понять, какие товары дают 80% выручки. Считаем долю накопленным итогом:
WITH product_revenue AS (
SELECT
product_id,
SUM(amount) as revenue,
SUM(SUM(amount)) OVER () as total_revenue
FROM sales
GROUP BY product_id
)
SELECT
product_id,
revenue,
revenue / total_revenue * 100 as percent,
SUM(revenue / total_revenue * 100) OVER (ORDER BY revenue DESC) as cumulative_percent
FROM product_revenue
ORDER BY revenue DESC;
Видим, где граница 80%. Классика для категорийных менеджеров. 📦
🎯 ПОЧЕМУ ЭТО ВАЖНО ДЛЯ АНАЛИТИКА?
Скорость: один запрос вместо трёх.
Гибкость: можно комбинировать с группировками и фильтрами.
Точность: меньше шансов ошибиться в логике.
Освойте оконные функции — и бизнес будет носить вас на руках за быстрые и точные ответы. 💪
#SQL
90% каналов про AI и ИТ бесполезны
Одни пересказывают новости.
Другие копируют посты друг у друга.
В итоге человек читает десятки каналов, но новых идей почти не появляется.
Сегодня главная ценность - не количество информации, а сильные источники. Люди, которые действительно работают с технологиями и делятся практикой, а не пересказами.
Поэтому мы собрали подборку сильных каналов про ит и искусственный интеллект. Внутри авторы, которые разбирают: новые AI-инструменты, технологии и продукты, стартапы, реальные кейсы использования нейросетей, вайб-кодинг и др. Это экономит время. Не нужно искать хорошие каналы по одному
Ссылка для добавления➡️ https://t.me/addlist/3WsuUGbOgm8xYTAy
Давайте поддержим каналы, чтобы качественного контента стало больше!
Одни пересказывают новости.
Другие копируют посты друг у друга.
В итоге человек читает десятки каналов, но новых идей почти не появляется.
Сегодня главная ценность - не количество информации, а сильные источники. Люди, которые действительно работают с технологиями и делятся практикой, а не пересказами.
Поэтому мы собрали подборку сильных каналов про ит и искусственный интеллект. Внутри авторы, которые разбирают: новые AI-инструменты, технологии и продукты, стартапы, реальные кейсы использования нейросетей, вайб-кодинг и др. Это экономит время. Не нужно искать хорошие каналы по одному
Ссылка для добавления
Давайте поддержим каналы, чтобы качественного контента стало больше!
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
IT 🧑💻
Вероника invites you to add the folder “IT 🧑💻”, which includes 26 chats.
❤1
📜 ТРЕБОВАНИЯ, КОТОРЫЕ РАБОТАЮТ: КАК КОД ПОМОГАЕТ АНАЛИТИКУ
Привет, коллеги! 👋 Слышали фразу: «Требования должны быть однозначными»? Легко сказать, сложно сделать. Сегодня покажу, как код (да, код!) помогает аналитику проверять и уточнять требования до передачи разработчикам. Реальные кейсы внутри. 🧑💻
📌 Кейс 1: «Скидка при заказе от 1000 рублей»
Бизнес-аналитик записал: «Если сумма заказа превышает 1000 рублей, применяется скидка 10%». Разработчик реализовал, тестировщик проверил — всё ок. Но на проде клиенты жалуются: скидка не применяется, когда сумма ровно 1000.
В чём проблема? Слово «превышает» можно трактовать как «больше» (>1000) или «больше или равно» (>=1000)? Аналитик не уточнил.
Что сделал бы проактивный аналитик? Написал бы простой тест на Python ещё до разработки:
Или даже на бизнес-языке (Gherkin):
Этот тест сразу подсветит неоднозначность. Спор решается на этапе анализа, а не на проде. 🔥
📌 Кейс 2: «Пароль должен содержать спецсимволы»
Требование: «Пароль должен содержать хотя бы один спецсимвол». Разработчик написал проверку: if any(c in "!@#$%" for c in password). Тестировщик проверил пароль "pass!" — работает. Через месяц выясняется, что клиенты из Германии не могут ввести "ß", потому что это не спецсимвол, а буква. Или спецсимволы типа "©" не считаются.
Как аналитик мог предотвратить это? Уточнить: «спецсимволы — это символы из набора ASCII: !"#$%&'()*+,-./:;<=>?@[]^_{|}~`». Или ещё лучше — сразу дать регулярное выражение в требованиях:
Но и это не всё. Аналитик может написать параметризованный тест, который проверяет граничные случаи:
Тест "pass©" провалится, и аналитик поймёт: нужно либо расширить набор, либо уточнить у бизнеса, считать ли «©» спецсимволом. 🎯
📌 Кейс 3: «Акция действует с 1 по 31 октября»
Бизнес сказал: «Акция на товары категории "Электроника" с 1 по 31 октября». Разработчик жёстко закодил даты. 1 ноября акция закончилась, но менеджер просит продлить до 5 ноября. Начинается аврал.
Что должен был сделать аналитик? Сформулировать требование как параметризованное, а не жёсткое. И показать пример кода, как это должно быть реализовано:
И тест, проверяющий, что даты можно менять без изменения кода:
Теперь гибкость заложена в требования. 🚀
🎯 ЧТО ДАЁТ АНАЛИТИКУ ТАКОЙ ПОДХОД?
Экономия времени на переделках.
Повышение доверия команды — требования превращаются в исполняемые спецификации.
Автоматическая регрессия — тесты остаются и проверяют, что требования не нарушены.
Совет: Дружить с разработчиками и просить их показывать код тестов. А лучше — писать простые тесты самим (хотя бы в виде псевдокода). Это поднимает качество требований на новый уровень.📈
#REQUIREMENTS
Привет, коллеги! 👋 Слышали фразу: «Требования должны быть однозначными»? Легко сказать, сложно сделать. Сегодня покажу, как код (да, код!) помогает аналитику проверять и уточнять требования до передачи разработчикам. Реальные кейсы внутри. 🧑💻
📌 Кейс 1: «Скидка при заказе от 1000 рублей»
Бизнес-аналитик записал: «Если сумма заказа превышает 1000 рублей, применяется скидка 10%». Разработчик реализовал, тестировщик проверил — всё ок. Но на проде клиенты жалуются: скидка не применяется, когда сумма ровно 1000.
В чём проблема? Слово «превышает» можно трактовать как «больше» (>1000) или «больше или равно» (>=1000)? Аналитик не уточнил.
Что сделал бы проактивный аналитик? Написал бы простой тест на Python ещё до разработки:
def test_discount():
assert apply_discount(1000) == 1000 # 0% или 10%?
assert apply_discount(1001) == 900.9 # должно быть 10%
assert apply_discount(500) == 500 # без скидки
Или даже на бизнес-языке (Gherkin):
Feature: Скидка на заказ
Scenario: Сумма ровно 1000
Given сумма заказа 1000 рублей
When рассчитывается скидка
Then скидка не применяется (0%) # или применяется? Надо решить!
Этот тест сразу подсветит неоднозначность. Спор решается на этапе анализа, а не на проде. 🔥
📌 Кейс 2: «Пароль должен содержать спецсимволы»
Требование: «Пароль должен содержать хотя бы один спецсимвол». Разработчик написал проверку: if any(c in "!@#$%" for c in password). Тестировщик проверил пароль "pass!" — работает. Через месяц выясняется, что клиенты из Германии не могут ввести "ß", потому что это не спецсимвол, а буква. Или спецсимволы типа "©" не считаются.
Как аналитик мог предотвратить это? Уточнить: «спецсимволы — это символы из набора ASCII: !"#$%&'()*+,-./:;<=>?@[]^_{|}~`». Или ещё лучше — сразу дать регулярное выражение в требованиях:
[!@#$%^&*(),.?":{}|<>]Но и это не всё. Аналитик может написать параметризованный тест, который проверяет граничные случаи:
import pytest
def validate_password(password):
# минимальная проверка для примера
return any(c in "!@#$%^&*" for c in password)
@pytest.mark.parametrize("pwd,expected", [
("pass!", True), # содержит !
("pass", False), # нет спецсимвола
("pass©", False), # © не в наборе
("pass#", True), # содержит #
])
def test_special_char(pwd, expected):
assert validate_password(pwd) == expected
Тест "pass©" провалится, и аналитик поймёт: нужно либо расширить набор, либо уточнить у бизнеса, считать ли «©» спецсимволом. 🎯
📌 Кейс 3: «Акция действует с 1 по 31 октября»
Бизнес сказал: «Акция на товары категории "Электроника" с 1 по 31 октября». Разработчик жёстко закодил даты. 1 ноября акция закончилась, но менеджер просит продлить до 5 ноября. Начинается аврал.
Что должен был сделать аналитик? Сформулировать требование как параметризованное, а не жёсткое. И показать пример кода, как это должно быть реализовано:
# Плохо
if date >= "2025-10-01" and date <= "2025-10-31":
apply_discount()
# Хорошо — параметры в конфиге или БД
promo = get_promo("october_electronics")
if promo.is_active(date):
apply_discount()
И тест, проверяющий, что даты можно менять без изменения кода:
def test_promo_flexible():
set_promo_dates("2025-10-01", "2025-10-31")
assert is_promo_active("2025-10-15") == True
assert is_promo_active("2025-11-01") == False
set_promo_dates("2025-10-01", "2025-11-05")
assert is_promo_active("2025-11-01") == True
Теперь гибкость заложена в требования. 🚀
🎯 ЧТО ДАЁТ АНАЛИТИКУ ТАКОЙ ПОДХОД?
Экономия времени на переделках.
Повышение доверия команды — требования превращаются в исполняемые спецификации.
Автоматическая регрессия — тесты остаются и проверяют, что требования не нарушены.
Совет: Дружить с разработчиками и просить их показывать код тестов. А лучше — писать простые тесты самим (хотя бы в виде псевдокода). Это поднимает качество требований на новый уровень.
#REQUIREMENTS
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Когда решил помочь коллегам, но вовремя осознал, на кого повесят задачу
🙈4
📊 BPMN: НЕ ПРОСТО КАРТИНКИ, А ИНСТРУМЕНТ АНАЛИЗА
Привет, коллеги! 👋 Многие думают, что BPMN нужен только чтобы «нарисовать процесс для заказчика». На самом деле, это мощный инструмент анализа, который помогает находить узкие места, избыточность и скрытые проблемы. Сегодня покажу на реальных кейсах, как BPMN спасает проекты. 🚀
📌 Кейс 1: «Согласование договора за 2 недели»
Компания жаловалась, что согласование договора занимает 14 дней. Аналитик нарисовал процесс в BPMN и сразу увидел проблему:
Дорожка юриста: проверка договора → отправка финансисту.
Дорожка финансиста: проверка бюджета → возврат юристу с правками.
Дорожка руководителя: финальное утверждение.
Что обнаружилось? В BPMN стало видно, что документ ходит по кругу между юристом и финансистом по 3–4 раза, потому что нет чёткого порядка правок. Каждый раз после изменений одного отдела другой снова проверял всё заново.
Решение: Внедрили шлюз (XOR) — теперь после правок документ идёт только тому, кто их запросил, а не всем подряд. Срок сократился до 3 дней. 📉
📌 Кейс 2: «Потерянные заявки»
В службу поддержки поступали жалобы: заявки клиентов «исчезают». Аналитик построил BPMN-модель обработки заявок и нашёл «чёрную дыру»:
Но если клиент не отвечал 3 дня, процесс просто зависал — не было таймера и альтернативного пути. Заявка оставалась в статусе «ожидание» навсегда.
Решение: Добавили пограничное событие-таймер на 3 дня. Если ответа нет — заявка автоматически закрывается с уведомлением клиента. Исчезновения прекратились. ✅
📌 Как BPMN связан с кодом?
Хорошая BPMN-модель — это основа для:
Написания user stories: Каждый шаг процесса — потенциальная задача в Jira.
Тест-кейсов: Можно автоматически генерировать сценарии для каждого пути.
Симуляции: Инструменты вроде Camuda позволяют «прогонять» модель и собирать метрики.
Пример симуляции на Python (упрощённо):
Такая симуляция помогает оценить нагрузку на отделы ещё до внедрения. 📊
📌 Кейс 3: «Автоматизация по BPMN»
Банк решил автоматизировать процесс выдачи кредитов. Аналитик описал процесс в BPMN, выделив:
Автоматические шаги (проверка кредитной истории)
Ручные шаги (звонок клиенту)
Шлюзы (если скоринг < 300 → отказ)
BPMN-модель стала техническим заданием для разработчиков. Они реализовали workflow-движок (Camunda), который выполняет процесс строго по диаграмме. Любое изменение процесса теперь делается аналитиком (меняется BPMN), а не кодом. 🏗
🎯 ЧТО ДАЁТ BPMN АНАЛИТИКУ?
Наглядность — заказчик видит процесс и утверждает его.
Выявление узких мест — петли, лишние согласования, таймауты.
Основу для автоматизации — workflow-движки понимают BPMN.
Документирование — процесс не в тексте, а в исполняемой модели.
Совет: Не ограничивайтесь рисованием. Прогоняйте модель, считайте метрики, ищите аномалии. BPMN — это язык, на котором вы разговариваете с бизнесом и разработкой. 📈
#BPMN
Привет, коллеги! 👋 Многие думают, что BPMN нужен только чтобы «нарисовать процесс для заказчика». На самом деле, это мощный инструмент анализа, который помогает находить узкие места, избыточность и скрытые проблемы. Сегодня покажу на реальных кейсах, как BPMN спасает проекты. 🚀
📌 Кейс 1: «Согласование договора за 2 недели»
Компания жаловалась, что согласование договора занимает 14 дней. Аналитик нарисовал процесс в BPMN и сразу увидел проблему:
Дорожка юриста: проверка договора → отправка финансисту.
Дорожка финансиста: проверка бюджета → возврат юристу с правками.
Дорожка руководителя: финальное утверждение.
Что обнаружилось? В BPMN стало видно, что документ ходит по кругу между юристом и финансистом по 3–4 раза, потому что нет чёткого порядка правок. Каждый раз после изменений одного отдела другой снова проверял всё заново.
Решение: Внедрили шлюз (XOR) — теперь после правок документ идёт только тому, кто их запросил, а не всем подряд. Срок сократился до 3 дней. 📉
📌 Кейс 2: «Потерянные заявки»
В службу поддержки поступали жалобы: заявки клиентов «исчезают». Аналитик построил BPMN-модель обработки заявок и нашёл «чёрную дыру»:
[Клиент отправляет заявку] → [Менеджер берёт в работу] → [Запрос доп. информации] → (ожидание ответа)
Но если клиент не отвечал 3 дня, процесс просто зависал — не было таймера и альтернативного пути. Заявка оставалась в статусе «ожидание» навсегда.
Решение: Добавили пограничное событие-таймер на 3 дня. Если ответа нет — заявка автоматически закрывается с уведомлением клиента. Исчезновения прекратились. ✅
📌 Как BPMN связан с кодом?
Хорошая BPMN-модель — это основа для:
Написания user stories: Каждый шаг процесса — потенциальная задача в Jira.
Тест-кейсов: Можно автоматически генерировать сценарии для каждого пути.
Симуляции: Инструменты вроде Camuda позволяют «прогонять» модель и собирать метрики.
Пример симуляции на Python (упрощённо):
# Имитация процесса согласования
def simulate_approval(legal_ok, finance_ok):
if not legal_ok:
return "rejected"
if not finance_ok:
return "rework"
return "approved"
# Прогоняем 1000 сценариев
results = [simulate_approval(random.choice([True, False]), random.choice([True, False])) for _ in range(1000)]
print(Counter(results)) # Сколько раз утвердили, отправили на доработку, отклонили
Такая симуляция помогает оценить нагрузку на отделы ещё до внедрения. 📊
📌 Кейс 3: «Автоматизация по BPMN»
Банк решил автоматизировать процесс выдачи кредитов. Аналитик описал процесс в BPMN, выделив:
Автоматические шаги (проверка кредитной истории)
Ручные шаги (звонок клиенту)
Шлюзы (если скоринг < 300 → отказ)
BPMN-модель стала техническим заданием для разработчиков. Они реализовали workflow-движок (Camunda), который выполняет процесс строго по диаграмме. Любое изменение процесса теперь делается аналитиком (меняется BPMN), а не кодом. 🏗
🎯 ЧТО ДАЁТ BPMN АНАЛИТИКУ?
Наглядность — заказчик видит процесс и утверждает его.
Выявление узких мест — петли, лишние согласования, таймауты.
Основу для автоматизации — workflow-движки понимают BPMN.
Документирование — процесс не в тексте, а в исполняемой модели.
Совет: Не ограничивайтесь рисованием. Прогоняйте модель, считайте метрики, ищите аномалии. BPMN — это язык, на котором вы разговариваете с бизнесом и разработкой. 📈
#BPMN
ИИ меняет всё. Кто разбирается в трендах, тот управляет будущим.
Я собрал папку с экспертами. Здесь настоящие практики, инсайты и кейсы — всё в одном месте.
Добавляйте себе папку и оставайтесь на шаг впереди 💪🏻
Я собрал папку с экспертами. Здесь настоящие практики, инсайты и кейсы — всё в одном месте.
Добавляйте себе папку и оставайтесь на шаг впереди 💪🏻
Еще вчера искусственный интеллект казался сюжетом из научной фантастики, а сегодня это «двигатель», который переписывает правила игры в IT. Нейросети больше не просто развлекают нас картинками - они пишут код, находят баги, проектируют архитектуры и анализируют данные быстрее, чем целые отделы.
Быть в IT сейчас - значит быть на передовой этой революции. ИИ не заменяет разработчика, он дает ему «экзоскелет», увеличивая продуктивность в разы. Те, кто научится внедрять нейросети в свои рабочие процессы, станут самыми востребованными специалистами десятилетия.
Собрали всё самое важное в этой папке:
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
ITech👾
Юлия invites you to add the folder “ITech👾”, which includes 30 chats.
❤1
🔗 ИНТЕГРАЦИЯ: КАК НЕ ПОТЕРЯТЬ ЗАКАЗЫ И ДЕНЬГИ
Привет, коллеги! 👋 Интеграции — всегда боль. Данные теряются, сервисы падают, форматы не сходятся. Разберём реальные кейсы и покажем, как код помогает проектировать надёжные интеграции. 🚀
📌 Кейс 1: Потерянные заказы
Ситуация: Магазин передаёт заказы в CRM через REST API. При падении CRM заказы терялись.
Решение — ретраи и Dead Letter Queue:
В требования: 3 попытки, экспоненциальная задержка, DLQ для упавших.
📌 Кейс 2: Двойные списания
Ситуация: Платёжный шлюз дублировал уведомления — деньги списывались дважды.
Решение — идемпотентность:
Требование: Все интеграции должны быть идемпотентными.
📌 Кейс 3: Разные форматы дат
Ситуация: CRM шлёт DD.MM.YYYY, бухгалтерия ждёт YYYY-MM-DD. Ошибки в отчётах.
Решение — тест контракта:
В требованиях: точные форматы и тесты в CI/CD.
📌 Кейс 4: Таймауты убивают производительность
Ситуация: Внешний сервис тормозил — вся система висла.
Решение — таймауты и fallback:
Требование: Таймауты на все внешние вызовы + кэш/заглушки.
🎯 ИТОГ
Код помогает аналитику:
Проверить требования до разработки
Дать разработчикам чёткие примеры
Подготовить тесты для приёмки
Аналитик, который мыслит кодом, — золото для команды.💰
#INTEGRATION
Привет, коллеги! 👋 Интеграции — всегда боль. Данные теряются, сервисы падают, форматы не сходятся. Разберём реальные кейсы и покажем, как код помогает проектировать надёжные интеграции. 🚀
📌 Кейс 1: Потерянные заказы
Ситуация: Магазин передаёт заказы в CRM через REST API. При падении CRM заказы терялись.
Решение — ретраи и Dead Letter Queue:
def send_order(order, max_retries=3):
for attempt in range(max_retries):
try:
response = requests.post("https://crm/orders", json=order, timeout=5)
if response.status_code == 200:
return True
time.sleep(2 ** attempt)
except:
time.sleep(2 ** attempt)
save_to_dlq(order) # в отдельную очередь
return False
В требования: 3 попытки, экспоненциальная задержка, DLQ для упавших.
📌 Кейс 2: Двойные списания
Ситуация: Платёжный шлюз дублировал уведомления — деньги списывались дважды.
Решение — идемпотентность:
key = hashlib.sha256(f"{order_id}_{amount}".encode()).hexdigest()
if redis.exists(key):
return {"status": "duplicate"} # уже обработали
redis.setex(key, 86400, "processed")
process_payment(payload)Требование: Все интеграции должны быть идемпотентными.
📌 Кейс 3: Разные форматы дат
Ситуация: CRM шлёт DD.MM.YYYY, бухгалтерия ждёт YYYY-MM-DD. Ошибки в отчётах.
Решение — тест контракта:
@pytest.mark.parametrize("date,format,ok", [
("15.03.2025", "%d.%m.%Y", True),
("2025-03-15", "%Y-%m-%d", True),
])
def test_date_format(date, format, ok):
assert validate_date(date, format) == okВ требованиях: точные форматы и тесты в CI/CD.
📌 Кейс 4: Таймауты убивают производительность
Ситуация: Внешний сервис тормозил — вся система висла.
Решение — таймауты и fallback:
async with timeout(2):
result = await session.get(url)
if timeout:
return get_cached_data() # запасной вариант
Требование: Таймауты на все внешние вызовы + кэш/заглушки.
🎯 ИТОГ
Код помогает аналитику:
Проверить требования до разработки
Дать разработчикам чёткие примеры
Подготовить тесты для приёмки
Аналитик, который мыслит кодом, — золото для команды.
#INTEGRATION
Please open Telegram to view this post
VIEW IN TELEGRAM