This media is not supported in your browser
VIEW IN TELEGRAM
Когда ко встрече подключился ОЧЕНЬ важный тех специалист
😁4
📐 UML ДЛЯ СИСТЕМНОГО АНАЛИТИКА: КОГДА КАРТИНКА ГОВОРИТ ГРОМЧЕ СЛОВ
Привет, коллеги! 👋 UML — не просто "рисовалки", а мощный инструмент коммуникации. Покажу на кейсах, как диаграммы спасают проекты. 🚀
📌 КЕЙС 1: ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ
Спорили 3 часа, как обрабатывать ошибки SMS-шлюза. Нарисовали схему — споры ушли.
Вывод: Sequence Diagram лучший для описания взаимодействия компонентов во времени.
📊 КЕЙС 2: ДИАГРАММА СОСТОЯНИЙ
Путались в статусах заказа. State Machine Diagram навёл порядок.
Вывод: Идеально для документирования архитектуры кодом.
🛠 ЧТО ИСПОЛЬЗОВАТЬ?
PlantUML — текст → диаграмма
Draw.io — быстро
Miro — для совместной работы
🎯 ИТОГ: UML экономит часы переговоров и делает систему прозрачной для всех.
#UML
Привет, коллеги! 👋 UML — не просто "рисовалки", а мощный инструмент коммуникации. Покажу на кейсах, как диаграммы спасают проекты. 🚀
📌 КЕЙС 1: ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ
Спорили 3 часа, как обрабатывать ошибки SMS-шлюза. Нарисовали схему — споры ушли.
User -> CRM: Заказ
CRM -> SMS: POST /send-sms
alt Успешно
SMS --> CRM: 200 OK
else Таймаут
SMS --> CRM: 504
CRM -> User: "Будет отправлено позже"
end
Вывод: Sequence Diagram лучший для описания взаимодействия компонентов во времени.
📊 КЕЙС 2: ДИАГРАММА СОСТОЯНИЙ
Путались в статусах заказа. State Machine Diagram навёл порядок.
[*] → Создан → Оплачен → В сборке → Доставлен
Создан → Отменён
Доставлен → Возврат → Завершён
Вывод: Незаменима для объектов со сложной статусной моделью.
🧩 КЕЙС 3: ДИАГРАММА КЛАССОВ
Новички не могли спроектировать БД. Class Diagram дал чёткую структуру.
text
User 1 ----many Enrollment
Course 1 ----many Enrollment
Course 1 ----many Lesson
Вывод: Это чертёж будущей системы до написания кода.
🏗 КЕЙС 4: C4-МОДЕЛЬ
В 15 микросервисах никто не видел общей картины. C4 + PlantUML спасли.
```text
Клиент → [Платформа] → [Платёжный шлюз]
Курьер → [Платформа] → [SMS-сервис]
Вывод: Идеально для документирования архитектуры кодом.
🛠 ЧТО ИСПОЛЬЗОВАТЬ?
PlantUML — текст → диаграмма
Draw.io — быстро
Miro — для совместной работы
🎯 ИТОГ: UML экономит часы переговоров и делает систему прозрачной для всех.
#UML
❤1
🔗 #INTEGRATION: КАК НЕ ПОТОНУТЬ В КОНТРАКТАХ И НЕ ПОТЕРЯТЬ ДАННЫЕ
Привет, коллеги! 👋
Сегодня покажу на реальных кейсах, как чёткие контракты и идемпотентность спасают проекты. Поехали! 🚀
📌 КЕЙС 1: КОГДА ФОРМАТЫ НЕ СОШЛИСЬ
CRM с датами DD.MM.YYYY интегрировали с сервисом, ждущим YYYY-MM-DD. Месяц отчёты строились по несуществующим датам. 😱
Решение: JSON Schema
Код проверки:
Вывод: JSON Schema — обязательный контракт для каждой интеграции. 📝
🔄 КЕЙС 2: ДУБЛИКАТЫ В ОЧЕРЕДИ
Из-за сбоя сети служба доставки получила дубликаты заказов из очереди. 💔
Решение: Идемпотентность
Вывод: Уникальный message_id и проверка на дубликаты — обязательное требование. 🛡
🧪 КЕЙС 3: ТЕСТИРОВАНИЕ КОНТРАКТОВ
Интеграция упала на проде из-за неожиданного статуса ответа.
Решение: Pact (контрактное тестирование)
Вывод: Тесты на контракты ловят нестыковки до выкатки. 🧪
✅ ЧЕК-ЛИСТ АНАЛИТИКА
Контракт: JSON Schema, примеры, правила трансформации
Надёжность: Уникальный ID, retry policy, DLQ
Тестирование: Контрактные тесты, негативные сценарии
Мониторинг: Метрики, алерты, логи с ID запроса
🎯 ИТОГ:
Интеграция — это контракт, идемпотентность, тесты и мониторинг. Аналитик, закладывающий это в требования, спасает команду от ночных дежурств.
#INTEGRATION
Привет, коллеги! 👋
Сегодня покажу на реальных кейсах, как чёткие контракты и идемпотентность спасают проекты. Поехали! 🚀
📌 КЕЙС 1: КОГДА ФОРМАТЫ НЕ СОШЛИСЬ
CRM с датами DD.MM.YYYY интегрировали с сервисом, ждущим YYYY-MM-DD. Месяц отчёты строились по несуществующим датам. 😱
Решение: JSON Schema
{
"properties": {
"birth_date": {
"pattern": "^\\d{4}-\\d{2}-\\d{2}$"
}
}
}Код проверки:
validate(instance=request, schema=schema) # Ошибка при неверном формате
Вывод: JSON Schema — обязательный контракт для каждой интеграции. 📝
🔄 КЕЙС 2: ДУБЛИКАТЫ В ОЧЕРЕДИ
Из-за сбоя сети служба доставки получила дубликаты заказов из очереди. 💔
Решение: Идемпотентность
if redis.exists(f"processed:{msg_id}"):
return # уже обработано
create_delivery(order_id)
redis.setex(f"processed:{msg_id}", 86400, "1")Вывод: Уникальный message_id и проверка на дубликаты — обязательное требование. 🛡
🧪 КЕЙС 3: ТЕСТИРОВАНИЕ КОНТРАКТОВ
Интеграция упала на проде из-за неожиданного статуса ответа.
Решение: Pact (контрактное тестирование)
provider.uponReceiving('запрос')
.withRequest({ body: { order_id: 123 } })
.willRespondWith({ status: 201, body: { delivery_id: 456 } });Вывод: Тесты на контракты ловят нестыковки до выкатки. 🧪
✅ ЧЕК-ЛИСТ АНАЛИТИКА
Контракт: JSON Schema, примеры, правила трансформации
Надёжность: Уникальный ID, retry policy, DLQ
Тестирование: Контрактные тесты, негативные сценарии
Мониторинг: Метрики, алерты, логи с ID запроса
🎯 ИТОГ:
Интеграция — это контракт, идемпотентность, тесты и мониторинг. Аналитик, закладывающий это в требования, спасает команду от ночных дежурств.
#INTEGRATION
🔗 #INTEGRATION: КАК НЕ УТОНУТЬ В API И НЕ ПРОСПАТЬ ИЗМЕНЕНИЯ
Привет, коллеги! 👋 Интеграции — это не просто «дёрнуть API». Это управление контрактами, версиями и нагрузкой. Покажу на кейсах, как инструменты спасают проекты. 🚀
📌 КЕЙС 1: REST API — OpenAPI как контракт
CRM и биллинг ссорились из-за формата телефона. 😫
Решение: OpenAPI-спецификация с жёсткой схемой.
Код валидации (Pydantic):
Вывод: OpenAPI — стандарт для REST. 📝
🔄 КЕЙС 2: АСИНХРОН — Avro + Schema Registry
Добавили поле в событие Kafka — аналитика упала. 💥
Решение: Avro-схемы с default-значениями.
Вывод: Avro + Registry для асинхронных шин. 📦
⏱️ КЕЙС 3: RATE LIMITING
SMS-шлюз отвечал 429 в час пик, уведомления терялись. 📉
Решение: Асинхронная очередь с лимитером.
Вывод: Rate limiting и retry policy обязательны. ⏳
✅ ЧЕК-ЛИСТ АНАЛИТИКА:
Контракт: OpenAPI / AsyncAPI / Avro
Валидация: схемы на всех уровнях
Версионирование: политика совместимости
Ошибки: retry policy, DLQ, rate limiting
Мониторинг: метрики, алерты, логи
🎯 ИТОГ: Интеграция — это контракты, версии и защита. Закладывайте это в требования.
Привет, коллеги! 👋 Интеграции — это не просто «дёрнуть API». Это управление контрактами, версиями и нагрузкой. Покажу на кейсах, как инструменты спасают проекты. 🚀
📌 КЕЙС 1: REST API — OpenAPI как контракт
CRM и биллинг ссорились из-за формата телефона. 😫
Решение: OpenAPI-спецификация с жёсткой схемой.
phone: { type: string, pattern: '^\+7\d{10}$' }Код валидации (Pydantic):
Customer(phone="+79991234567") # ok
Customer(phone="89991234567") # error
Вывод: OpenAPI — стандарт для REST. 📝
🔄 КЕЙС 2: АСИНХРОН — Avro + Schema Registry
Добавили поле в событие Kafka — аналитика упала. 💥
Решение: Avro-схемы с default-значениями.
{"name": "promo_code", "type": ["null", "string"], "default": null}
Schema Registry хранит версии — потребители не ломаются.Вывод: Avro + Registry для асинхронных шин. 📦
⏱️ КЕЙС 3: RATE LIMITING
SMS-шлюз отвечал 429 в час пик, уведомления терялись. 📉
Решение: Асинхронная очередь с лимитером.
async with AsyncLimiter(100, 1):
await send_sms(phone, text) # не превысит лимит
Вывод: Rate limiting и retry policy обязательны. ⏳
✅ ЧЕК-ЛИСТ АНАЛИТИКА:
Контракт: OpenAPI / AsyncAPI / Avro
Валидация: схемы на всех уровнях
Версионирование: политика совместимости
Ошибки: retry policy, DLQ, rate limiting
Мониторинг: метрики, алерты, логи
🎯 ИТОГ: Интеграция — это контракты, версии и защита. Закладывайте это в требования.
🧪 #TESTING: КАК АНАЛИТИКУ ЗАКЛАДЫВАТЬ КАЧЕСТВО ДО КОДА
Привет, коллеги! 👋 Аналитик не просто пишет требования — он создаёт тестируемую систему. Покажу на кейсах, как формализация помогает QA. Поехали! 🚀
📌 КЕЙС 1: ПЛОХИЕ ACCEPTANCE CRITERIA
Было: «При сумме >5000 скидка». Разработчик сделал 5%, а нужно было 10% для новых клиентов. 😱
Решение: Given-When-Then
Вывод: Сценарии исключают разночтения. ✅
📦 КЕЙС 2: JSON SCHEMA ДЛЯ КОНТРАКТОВ
Интеграция упала: телефон передали числом, а API ждал строку с +7. 💥
Решение: JSON Schema
Код проверки:
python
validate(instance=request, schema=schema) # ошибка при неверном формате
Вывод: Контракты ловят нестыковки до прода. 🛡
🛠 КЕЙС 3: ГЕНЕРАЦИЯ ТЕСТОВЫХ ДАННЫХ
Тестировщики вручную создавали заказы. Аналитик написал скрипт.
Вывод: Готовые данные по бизнес-правилам экономят часы. ⏱️
✅ ЧЕК-ЛИСТ АНАЛИТИКА:
Acceptance Criteria в Given-When-Then
JSON Schema для всех интеграций
Скрипты генерации тестовых данных
Примеры запросов-ответов
Негативные сценарии
🎯 ИТОГ: Чем чётче требования — тем меньше багов в проде. Инструменты выше — must-have для аналитика.
#TESTING
Привет, коллеги! 👋 Аналитик не просто пишет требования — он создаёт тестируемую систему. Покажу на кейсах, как формализация помогает QA. Поехали! 🚀
📌 КЕЙС 1: ПЛОХИЕ ACCEPTANCE CRITERIA
Было: «При сумме >5000 скидка». Разработчик сделал 5%, а нужно было 10% для новых клиентов. 😱
Решение: Given-When-Then
Scenario: Постоянный клиент с суммой >5000
Given клиент постоянный (более 5 заказов)
And сумма 6000
When считаем итог
Then скидка = 600 (10%), итог = 5400
Вывод: Сценарии исключают разночтения. ✅
📦 КЕЙС 2: JSON SCHEMA ДЛЯ КОНТРАКТОВ
Интеграция упала: телефон передали числом, а API ждал строку с +7. 💥
Решение: JSON Schema
{
"properties": {
"phone": {"type": "string", "pattern": "^\\+7\\d{10}$"}
}
}Код проверки:
python
validate(instance=request, schema=schema) # ошибка при неверном формате
Вывод: Контракты ловят нестыковки до прода. 🛡
🛠 КЕЙС 3: ГЕНЕРАЦИЯ ТЕСТОВЫХ ДАННЫХ
Тестировщики вручную создавали заказы. Аналитик написал скрипт.
def generate_order():
total = random.choice([3000, 6000, 10000])
discount = total * 0.1 if total > 5000 else 0
return {"total": total, "discount": discount}
Вывод: Готовые данные по бизнес-правилам экономят часы. ⏱️
✅ ЧЕК-ЛИСТ АНАЛИТИКА:
Acceptance Criteria в Given-When-Then
JSON Schema для всех интеграций
Скрипты генерации тестовых данных
Примеры запросов-ответов
Негативные сценарии
🎯 ИТОГ: Чем чётче требования — тем меньше багов в проде. Инструменты выше — must-have для аналитика.
#TESTING
🗄 #DBMS ДЛЯ СИСТЕМНОГО АНАЛИТИКА: КАК НЕ УТОНУТЬ В ДАННЫХ
Привет, коллеги! 👋 Решения аналитика на этапе проектирования определяют, будет ли система тормозить или рухнет под нагрузкой. Покажу на кейсах, как понимание БД спасает проекты. 🚀
📌 КЕЙС 1: НОРМАЛИЗАЦИЯ
Всё хранили в одной таблице заказов. Клиент сменил телефон — обновляли 1000 записей. 😱
Было (плохо):
Вывод: Нормализация устраняет аномалии. Проектируйте структуру, а не «табличку».
📊 КЕЙС 2: ИНДЕКСЫ
Поиск клиента по email в таблице users (10 млн строк) — 30 секунд.
До:
Вывод: Индексы на полях в WHERE обязательны. Это дёшево и эффективно.
🔒 КЕЙС 3: ТРАНЗАКЦИИ
Два менеджера одновременно забронировали последний номер в отеле. Двойная продажа! 💔
Решение: Блокировка строки.
Вывод: Аналитик должен предусматривать конкурентный доступ и блокировки.
📈 КЕЙС 4: ВЫБОР БД
10 000 датчиков шлют показания каждую секунду. PostgreSQL раздулся и тормозит.
Решение: Time Series DB (InfluxDB).
Вывод: Выбирайте СУБД под задачу: реляционные, документные, временные ряды, графовые.
✅ ЧЕК-ЛИСТ АНАЛИТИКА:
Нормализация (до 3НФ)
Индексы на частые WHERE
Транзакции и блокировки
Выбор типа СУБД под задачу
🎯 ИТОГ: База данных — сердце системы. Ошибки в проектировании на этапе анализа приводят к миллионным потерям позже. Хороший аналитик — архитектор данных.
#DBMS
Привет, коллеги! 👋 Решения аналитика на этапе проектирования определяют, будет ли система тормозить или рухнет под нагрузкой. Покажу на кейсах, как понимание БД спасает проекты. 🚀
📌 КЕЙС 1: НОРМАЛИЗАЦИЯ
Всё хранили в одной таблице заказов. Клиент сменил телефон — обновляли 1000 записей. 😱
Было (плохо):
CREATE TABLE orders (customer_name, customer_phone, product_name, ...);
Стало (хорошо):
CREATE TABLE customers (id, name, phone);
CREATE TABLE products (id, name, price);
CREATE TABLE orders (id, customer_id, date);
CREATE TABLE order_items (order_id, product_id, qty);
Вывод: Нормализация устраняет аномалии. Проектируйте структуру, а не «табличку».
📊 КЕЙС 2: ИНДЕКСЫ
Поиск клиента по email в таблице users (10 млн строк) — 30 секунд.
До:
SELECT * FROM users WHERE email = 'ivan@example.com'; -- 30 сек
После:
CREATE INDEX idx_users_email ON users(email); -- 10 мс
Вывод: Индексы на полях в WHERE обязательны. Это дёшево и эффективно.
🔒 КЕЙС 3: ТРАНЗАКЦИИ
Два менеджера одновременно забронировали последний номер в отеле. Двойная продажа! 💔
Решение: Блокировка строки.
BEGIN;
SELECT * FROM rooms WHERE id = 123 AND status = 'free' FOR UPDATE;
-- теперь никто не изменит строку
INSERT INTO bookings (room_id, customer_id) VALUES (123, 456);
COMMIT;
Вывод: Аналитик должен предусматривать конкурентный доступ и блокировки.
📈 КЕЙС 4: ВЫБОР БД
10 000 датчиков шлют показания каждую секунду. PostgreSQL раздулся и тормозит.
Решение: Time Series DB (InfluxDB).
INSERT sensors,device_id=101 temperature=22.5
SELECT MEAN(temperature) FROM sensors WHERE time > now() - 1h
Вывод: Выбирайте СУБД под задачу: реляционные, документные, временные ряды, графовые.
✅ ЧЕК-ЛИСТ АНАЛИТИКА:
Нормализация (до 3НФ)
Индексы на частые WHERE
Транзакции и блокировки
Выбор типа СУБД под задачу
🎯 ИТОГ: База данных — сердце системы. Ошибки в проектировании на этапе анализа приводят к миллионным потерям позже. Хороший аналитик — архитектор данных.
#DBMS
🛠 #SYSTEMDESIGN: КАК ПРОЕКТИРОВАТЬ СИСТЕМЫ, КОТОРЫЕ НЕ РАЗВАЛЯТСЯ
Привет, коллеги! 👋 Проектирование — это компромиссы и предвидение. Разберём на реальных кейсах, какие решения спасают проекты, а какие — убивают. 🚀
📌 КЕЙС 1: МОНОЛИТ VS МИКРОСЕРВИСЫ
Стартап доставки, команда 5 человек, MVP за 2 месяца. Техлид хотел микросервисы — это убило бы сроки.
Решение: Модульный монолит с чёткими слоями. Запустились вовремя, через год выделили сервис доставки без переписывания.
Вывод: Для маленькой команды — модульный монолит. Микросервисы нужны для независимых команд, а не для «модности».
🔒 КЕЙС 2: ПОСЛЕДНИЙ БИЛЕТ
Два пользователя одновременно покупают последний билет — двойная продажа. Ошибка: в требованиях не учли конкурентность.
Решение: Пессимистическая блокировка SELECT FOR UPDATE. Второй пользователь ждёт и видит, что место уже занято.
Вывод: Для уникальных ресурсов (места, товары) закладывайте блокировки.
📊 КЕЙС 3: IoT-ПОТОК
10 000 датчиков в секунду. Пытались писать в PostgreSQL — БД раздулась, запросы тормозили.
Решение: Потоковая обработка (Kafka + Flink) + ClickHouse для агрегатов. Сырые данные не храним — только 5-минутные средние.
Вывод: Для временных рядов — специализированные БД (Time Series).
🚀 КЕЙС 4: КЭШИРОВАНИЕ
Интернет-магазин: страницы товаров грузились 5 секунд. DevOps хотел сервер за 2 млн руб.
Решение: Внедрили Redis. Кэш на 5 минут, нагрузка на БД упала на 95%, время загрузки — 200 мс. Сервер не купили.
Вывод: Кэширование — первое средство от высокой нагрузки на чтение.
🧩 КЕЙС 5: CQRS
Система задач: отчёты строились 5 минут, потому что читали те же таблицы, куда активно писали.
Решение: Разделили модели записи (PostgreSQL) и чтения (MongoDB). Синхронизация через события.
Вывод: При дисбалансе чтения и записи помогает CQRS.
✅ ЧЕК-ЛИСТ АНАЛИТИКА:
Какая нагрузка (чтение/запись, пики)?
Конкурентность (что, если одновременно)?
Объём данных (рост через год)?
Допустимое время отклика?
Бюджет и команда сейчас и потом.
🎯 ИТОГ: Проектирование — это выбор компромиссов. Хороший аналитик помогает команде найти баланс между скоростью, стоимостью и масштабируемостью.
#OTHER
Привет, коллеги! 👋 Проектирование — это компромиссы и предвидение. Разберём на реальных кейсах, какие решения спасают проекты, а какие — убивают. 🚀
📌 КЕЙС 1: МОНОЛИТ VS МИКРОСЕРВИСЫ
Стартап доставки, команда 5 человек, MVP за 2 месяца. Техлид хотел микросервисы — это убило бы сроки.
Решение: Модульный монолит с чёткими слоями. Запустились вовремя, через год выделили сервис доставки без переписывания.
Вывод: Для маленькой команды — модульный монолит. Микросервисы нужны для независимых команд, а не для «модности».
🔒 КЕЙС 2: ПОСЛЕДНИЙ БИЛЕТ
Два пользователя одновременно покупают последний билет — двойная продажа. Ошибка: в требованиях не учли конкурентность.
Решение: Пессимистическая блокировка SELECT FOR UPDATE. Второй пользователь ждёт и видит, что место уже занято.
Вывод: Для уникальных ресурсов (места, товары) закладывайте блокировки.
📊 КЕЙС 3: IoT-ПОТОК
10 000 датчиков в секунду. Пытались писать в PostgreSQL — БД раздулась, запросы тормозили.
Решение: Потоковая обработка (Kafka + Flink) + ClickHouse для агрегатов. Сырые данные не храним — только 5-минутные средние.
Вывод: Для временных рядов — специализированные БД (Time Series).
🚀 КЕЙС 4: КЭШИРОВАНИЕ
Интернет-магазин: страницы товаров грузились 5 секунд. DevOps хотел сервер за 2 млн руб.
Решение: Внедрили Redis. Кэш на 5 минут, нагрузка на БД упала на 95%, время загрузки — 200 мс. Сервер не купили.
Вывод: Кэширование — первое средство от высокой нагрузки на чтение.
🧩 КЕЙС 5: CQRS
Система задач: отчёты строились 5 минут, потому что читали те же таблицы, куда активно писали.
Решение: Разделили модели записи (PostgreSQL) и чтения (MongoDB). Синхронизация через события.
Вывод: При дисбалансе чтения и записи помогает CQRS.
✅ ЧЕК-ЛИСТ АНАЛИТИКА:
Какая нагрузка (чтение/запись, пики)?
Конкурентность (что, если одновременно)?
Объём данных (рост через год)?
Допустимое время отклика?
Бюджет и команда сейчас и потом.
🎯 ИТОГ: Проектирование — это выбор компромиссов. Хороший аналитик помогает команде найти баланс между скоростью, стоимостью и масштабируемостью.
#OTHER
❤1👍1
🛠 #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