🍀BitBitGo🍀 Системный Анализ
3.22K subscribers
216 photos
153 videos
112 links
Курс «Системный анализ»
https://bitbitgo.by/
Пишем про системный анализ.
Поможем стартануть в карьере IT. Присоединяйся!
Download Telegram
This media is not supported in your browser
VIEW IN TELEGRAM
Когда ко встрече подключился ОЧЕНЬ важный тех специалист
😁4
📐 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
Media is too big
VIEW IN TELEGRAM
Рабочие переписки с ChatGPT
😁6
🔗 #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-спецификация с жёсткой схемой.

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

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 записей. 😱

Было (плохо):

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👍1
🛠 #SYSTEMDESIGN: 5 РЕШЕНИЙ, КОТОРЫЕ СПАСУТ ВАШ ПРОЕКТ

Привет, коллеги! 👋 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%. Затем проанализировал, какие признаки важны — так я вычислил скрытые коэффициенты и формулы.

Пример кода для анализа:

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
1
🏗 АРХИТЕКТУРА ПО ДЛЯ АНАЛИТИКА: КЕЙСЫ С КОДОМ

Привет, коллеги! 👋 Часто слышу: «Архитектура — не моё дело». Это опасное заблуждение. Аналитик закладывает архитектуру через требования. Разберём на реальных кейсах с примерами кода, почему без понимания #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):

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 секунда — слишком мало, сервис не успевает восстановиться.

```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: «Где мои бонусы?» (проверка гипотезы)

Менеджер жалуется: «Клиенты не получают бонусы за регистрацию!». Разработчики говорят: «Всё работает, проверяли». Вы решаете проверить сами.

Пишете запрос в базу:

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