🔐 БЕЗОПАСНОСТЬ В РАБОТЕ СИСТЕМНОГО АНАЛИТИКА: НЕ ТОЛЬКО ДЛЯ DEVSEOPS

Приветствую, коллеги! 👋 Сегодня разберем, почему тема кибербезопасности (#SECURITY) — это не только головная боль DevOps и разработчиков, но и прямая зона ответственности системного аналитика. От наших требований и решений на ранних этапах зависит, будет ли система надежным крепостью или дырявым решетом. 🏰➡️ 🧀

🤔 Почему аналитик? Ведь есть же security-специалисты!
Именно аналитик закладывает логику работы системы и правила обработки данных в требованиях. Если мы на этапе проектирования не учтем угрозы, то исправлять их в готовом коде будет в 10-100 раз дороже. Мы — первый рубеж обороны! 🛡

🎯 Ключевые зоны ответственности аналитика в безопасности:

Сбор нефункциональных требований по безопасности: Это не просто «система должна быть защищена». Конкретизируем:
Аутентификация и авторизация: Как именно пользователь доказывает, кто он? (OAuth 2.0, биометрия, 2FA). Какие роли и права доступа будут? (RBAC, ABAC). 🔑

Аудит и логирование: Какие действия пользователей и системы должны логироваться (логи изменений, доступ к конфиденциальным данным)? Как долго хранить логи? 📊
Защита данных: Какие данные являются персональными (ПДн) или коммерческой тайной? Нужно ли их шифровать при хранении (encryption at rest) и передаче (TLS)? Как реализовать маскирование в интерфейсах? 🗝

Соответствие стандартам: Работаем в РФ? Значит, нужно учитывать 152-ФЗ, 187-ФЗ (КИИ), 266-ФЗ (ГИС). Работаем с платежами? Это PCI DSS. Имеем дело с медданными? HIPAA. Мы должны выявить эти требования на старте! 📜
Проектирование безопасных процессов:

Восстановление после сбоя (Disaster Recovery): Как быстро система должна вернуться к работе после атаки? Какая точка восстановления (RPO) и время (RTO) допустимы? ♻️

Управление инцидентами: Кто и как будет оповещен при подозрительной активности? Какой процесс расследования? 🚨
Моделирование угроз (Threat Modeling) на уровне дизайна: Задаем вопросы:
*«Что, если злоумышленник отправит в поле ввода 10 000 символов? (XSS, SQL-инъекция)»*
«Что, если сотрудник попытается скачать всю клиентскую базу? (утечка данных)»
«Как система отличит легитимного пользователя от бота? (DDoS, фрод)» 🤖

💡 Практические примеры из жизни аналитика:

Кейс 1: Финансовый портал. В ТЗ было: «Пользователь вводит номер счета для перевода». Наша задача: Добавить требование на валидацию и маскировку номера счета в интерфейсе, запрет на сохранение полного номера в логах приложений, обязательное подтверждение операции через второй канал (SMS/пуш). 📱

Кейс 2: Внутренний HR-портал. В процессе описания ролей выяснилось, что менеджер по кадрам может видеть зарплаты всех сотрудников. Наша задача: Предложить архитектуру разделения данных так, чтобы менеджер видел только сотрудников своего отдела, или внедрить систему согласования запросов на доступ к чувствительной информации. 👥

Кейс 3: Интеграция с внешним API. В ТЗ указана просто «интеграция». Наша задача: Дописать требования по взаимной аутентификации (API-ключи, mTLS), шифрованию тела запросов, ограничению частоты вызовов (rate limiting) и анализу логов доступа от партнера. 🔗

🚀 Итог: Что делать уже завтра?

Задавайте «злые» вопросы стейкхолдерам о данных и уязвимостях.
Включите в свой чек-лист анализа требований раздел «Безопасность».
Знакомьтесь с базовыми стандартами (ISO 27001, 152-ФЗ) и OWASP Top 10 (главные уязвимости веб-приложений).
Работайте в тандеме с security-архитектором или пентестером на ранних этапах проектирования.
Запомните: безопасность — это не фича, а свойство системы, закладываемое с самого начала. Аналитик, который мыслит категориями безопасности, — это огромная ценность для компании и гарантия спокойного сна. 😴

#SECURITY

Когда пришло письмо «Прошу подключиться к вопросу ниже»

📊 SQL ДЛЯ СИСТЕМНОГО АНАЛИТИКА: НЕ ПРОСТО ЗАПРОСЫ, А ИНСТРУМЕНТ ПРИНЯТИЯ РЕШЕНИЙ
Привет, коллеги! 👋 Давайте начистоту: многие думают, что SQL для аналитика — это просто проверить данные. На самом деле, это ваш супер-инструмент для выявления проблем, валидации гипотез и даже сбора требований. Сегодня покажу на реальных кейсах, как SQL спасал проекты. 🦸‍♂️

🔍 Кейс 1: «Пропавшие транзакции» — как SQL помог обнаружить баг в ТЗ

Ситуация: В платёжной системе после релиза новой фичи часть транзакций «терялась». Разработчики клялись, что всё работает. Поддержка завалена жалобами.

Что сделал аналитик? Вместо долгих совещаний, написал исследовательский запрос:

SELECT 
    user_id,
    COUNT(CASE WHEN status = 'SUCCESS' THEN 1 END) as success_count,
    COUNT(CASE WHEN status = 'FAILED' THEN 1 END) as failed_count,
    COUNT(CASE WHEN status IS NULL THEN 1 END) as null_count  -- Вот это ключ!
FROM transactions 
WHERE created_at >= '2024-10-01'
GROUP BY user_id
HAVING null_count > 0;

Что обнаружилось: У 15% пользователей были транзакции со статусом NULL, которые не отображались в интерфейсе.

Причина: В техническом задании не учли сценарий таймаута соединения с банком. Система не знала, как обработать этот случай, и оставляла статус пустым.

Итог: За 20 минут SQL-запроса:
✅ Выявлен конкретный баг
✅ Спасена репутация продукта
✅ Дополнено ТЗ обработкой таймаутов

📈 Кейс 2: «Странные бонусы» — валидация бизнес-логики

Задача: После запуска программы лояльности маркетологи заметили, что бонусов начисляется больше, чем ожидалось.
Вместо того чтобы спрашивать «почему?», аналитик провёл анализ данных:

WITH user_orders AS (
    SELECT 
        user_id,
        COUNT(DISTINCT order_id) as order_count,
        SUM(bonus_amount) as total_bonuses
    FROM orders
    WHERE created_at BETWEEN '2024-10-01' AND '2024-10-15'
    GROUP BY user_id
)
SELECT 
    CASE 
        WHEN order_count = 1 THEN 'Один заказ'
        WHEN order_count BETWEEN 2 AND 5 THEN '2-5 заказов'
        ELSE 'Более 5 заказов'
    END as segment,
    COUNT(user_id) as users_count,
    AVG(total_bonuses) as avg_bonus_per_user,
    SUM(total_bonuses) as segment_bonus_total
FROM user_orders
GROUP BY 1
ORDER BY segment_bonus_total DESC;

Открытие: 70% всех бонусов получали пользователи с одним заказом, хотя по логике система должна была начислять больше постоянным клиентам.
Проблема: Ошибка в формуле расчёта — бонусы умножались на коэффициент новизны пользователя, а не на коэффициент лояльности.
Результат: SQL помог не просто найти ошибку, а количественно оценить её влияние на бизнес. 💰

🛠 Кейс 3: «Метрики для руководителя» — когда нужно быстро, но содержательно

Срочный запрос от CEO: «Как идут продажи в новом регионе?»
Вместо дня подготовки отчёта, аналитик за 30 минут сделал:

SELECT 
    DATE_TRUNC('week', order_date) as week,
    region,
    COUNT(order_id) as orders_count,
    SUM(order_amount) as revenue,
    COUNT(DISTINCT customer_id) as unique_customers,
    SUM(order_amount) / COUNT(DISTINCT customer_id) as avg_revenue_per_customer
FROM sales
WHERE region = 'Сибирь'
    AND order_date >= '2024-09-01'
GROUP BY 1, 2
ORDER BY week DESC;

Почему это эффективно?

Готовый анализ трендов по неделям
Ключевые метрики в одном месте
Инсайты для маркетинга — средний чек на клиента
Основа для принятия решений — стоит ли увеличивать инвестиции в регион

🎯 ВАШИ ДЕЙСТВИЯ НА ЗАВТРА:

Начните с малого: Освойте WHERE, GROUP BY, JOIN — этого хватит для 80% задач

Спрашивайте доступ к БД на проекте (только для чтения!)
Автоматизируйте рутину: Сохраняйте полезные запросы в saved queries
Изучайте оконные функции (OVER, PARTITION BY) — это следующий уровень

Запомните: SQL для аналитика — это не про «базы данных», это про понимание данных. Каждый запрос — это вопрос к системе, и правильный вопрос даёт правильный ответ. 🧠

#SQL

Когда начальник очень несмешно пошутил, но скоро выплата премий

Супер мега про макс менеджер после закона от 1 марта об англицизмах

Когда встреча с коллегами вдруг стала интересной

🔗 INTEGRATION В СИСТЕМНОМ АНАЛИЗЕ: КОГДА СВЯЗИ СТАНОВЯТСЯ ПРОБЛЕМАМИ

Привет, коллеги! 👋 Сегодня разберем тему, которую многие недооценивают — интеграции (#INTEGRATION). Это не просто «соединить две системы», а целая философия проектирования. Готовы узнать, как непродуманные интеграции сжигали бюджеты и нервы? Поехали! 🚀

💥 Кейс 1: «Падение из-за чужого таймаута»

Ситуация: Крупный интернет-магазин внедрил систему скоринга для одобрения кредитов. При оформлении заказа наш сайт синхронно вызывал API банка и ждал ответа до 30 секунд.

Что пошло не так? В «Черную пятницу» банковская система не выдержала нагрузки и начала отвечать за 20-25 секунд. Наш сайт лег на 3 часа, потому что все воркеры были заняты ожиданием ответа от банка.

Ошибка аналитика: В ТЗ было просто: «При оформлении заказа вызвать метод /check-credit банковской системы». Не было предусмотрено:

Таймаутов на нашей стороне ⏱️
Асинхронной обработки
Фолбэка на ручную проверку
Решение: Перешли на асинхронную схему:

Заказ создается со статусом «Проверка кредита»
Событие уходит в очередь
Отдельный воркер обрабатывает его с повторными попытками
При таймауте > 5 сек — автоматический переход на ручную проверку
Вывод: Синхронные интеграции с внешними системами — это мина замедленного действия. Всегда проектируйте асинхронно с учетом отказов! 🛡

🔧 Кейс 2: «Тихий убийца данных»

Задача: Интеграция CRM с сервисом email-рассылок. Каждый вечер CRM выгружала CSV-файл с новыми клиентами, сервис рассылок забирал его.

Проблема: Через месяц маркетологи заметили, что 30% писем не доходят. Оказалось:

CRM использовала кодировку Windows-1251
Сервис рассылок ожидал UTF-8
Имена с буквой «ё» и кириллицей превращались в «????» 🤯
Ошибка аналитика: В спецификации не были указаны:

Формат кодировки
Правила валидации данных
Формат обработки ошибок
Решение: Внедрили контракт данных (Data Contract):

{
  "encoding": "UTF-8",
  "required_fields": ["email", "name"],
  "validation_rules": {
    "email": "regex pattern",
    "name": "max_length: 100"
  }
}

Плюс добавили тестовый контур для проверки перед выгрузкой.

📊 Статистика, которая пугает: По данным исследований, 40% падений распределенных систем происходят из-за проблем с интеграциями, а не с внутренними багами.

🎯 ЧЕК-ЛИСТ АНАЛИТИКА ПРИ ПРОЕКТИРОВАНИИ ИНТЕГРАЦИЙ:

Сценарии отказа:

Что если внешняя система не отвечает 10 секунд? 1 минуту? ⏰
Как поведет себя наша система при получении некорректных данных?
Есть ли механизм повтора (retry policy)?
Данные:

Четко прописаны форматы (JSON/XML/CSV)?
Указаны кодировки и стандарты дат?
Есть ли маппинг полей между системами? 📝
Безопасность:

Как происходит аутентификация (API-ключи, OAuth)?
Данные шифруются при передаче?
Есть ли ограничения по частоте запросов (rate limiting)? 🔐
Мониторинг:

Какие метрики будем отслеживать (латентность, ошибки)?
Куда придут алерты при проблемах?
Есть ли дашборд для отслеживания здоровья интеграции? 📈
💡 Паттерны, которые стоит знать:

Retry with backoff: Повторные попытки с растущей задержкой
Circuit Breaker: Автоматическое отключение «сломанной» интеграции
Dead Letter Queue: Очередь для сообщений, которые не удалось обработать
API Versioning: Версионирование интерфейсов для обратной совместимости

🚀 ПРАКТИЧЕСКИЙ СОВЕТ: Начинайте проектирование интеграции с диаграммы последовательности (sequence diagram). Нарисуйте: кто, куда, что отправляет, какие возможны ошибки. Это сэкономит часы совещаний!

🎯 ИТОГ: Хорошая интеграция — как хороший договор: все возможные ситуации предусмотрены, формальности соблюдены, а стороны защищены от неожиданностей. Ваша задача как аналитика — быть юристом в мире данных, который продумает все спорные моменты заранее.

#INTEGRATION

Как воспринимается конец рабочей недели

🗄 DBMS ДЛЯ СИСТЕМНОГО АНАЛИТИКА: КОГДА НЕЗНАНИЕ БАЗ ДАННЫХ СТОИТ ДОРОГО

Привет, коллеги! 👋 Сегодня поговорим о том, почему системный аналитик обязан разбираться в базах данных. Это не «задача разработчиков», а ваша прямая ответственность. Неверные решения на этапе анализа приводят к падениям систем и финансовым потерям. Докажу на реальных кейсах. 💼🔥

📉 Кейс 1: «Простая нормализация, которая съела бизнес»

Ситуация: Стартап по доставке еды решил сэкономить на БД. Аналитик предложил хранить все данные заказа в одной JSON-колонке order_data в таблице orders.

Что пошло не так через 6 месяцев:

Невозможно проанализировать популярные блюда — все данные в JSON 📊
Медленные отчеты — каждый запрос парсит JSON целиком ⏱️
Ошибки в расчётах — разные форматы хранения цен в одном поле 💸
Ошибка: Игнорирование нормализации. Правильная структура требовала:

Таблица orders (основная информация)
Таблица order_items (позиции заказа)
Таблица products (справочник товаров)
Вывод: Аналитик должен знать хотя бы 1-3 нормальные формы. Данные — это актив компании, а не техническая деталь.

🚀 Кейс 2: «Индекс, который спас компанию»

Задача: В мобильном приложении соцсети лента новостей грузилась 8-12 секунд. Пользователи уходили.

Анализ аналитика (не разработчика!): Изучив частые запросы, я заметил паттерн:

SELECT * FROM posts 
WHERE user_id IN (SELECT friend_id FROM friendships WHERE user_id = ?) 
ORDER BY created_at DESC 
LIMIT 20

Проблема: Каждый раз искались друзья + сортировка по дате без индекса.

Решение в ТЗ: Добавить составной индекс (user_id, created_at DESC) в таблицу posts и предусмотреть покрывающий индекс для частых запросов.

Результат: Время загрузки сократилось до 200 мс. 📈

Запомните: Аналитик должен понимать какие запросы будут частыми и проектировать структуру под них.

💥 Кейс 3: «Выбор БД — вопрос архитектуры, а не моды»

История: FinTech-стартап выбрал MongoDB для хранения финансовых транзакций, потому что «это модно и scalable».

Чем обернулось:

Потеря данных при параллельных обновлениях ⚠️
Сложные ACID-транзакции при переводе средств 💰
Дорогой переезд на PostgreSQL через год
Почему аналитик должен был вмешаться: Требования к системе включали:

Гарантированную целостность транзакций
Сложные JOIN между клиентами, счетами и операциями
Строгую схему данных
Правильное решение: Реляционная БД (PostgreSQL) с поддержкой ACID.

🎯 ЧЕК-ЛИСТ АНАЛИТИКА ПРИ РАБОТЕ С БАЗАМИ ДАННЫХ:

Проектирование структуры:

Нужна ли нормализация или подойдет денормализация для производительности?
Какие связи между сущностями (1-1, 1-много, много-много)? 🔗
Есть ли справочники, которые будут часто использоваться?
Производительность:

Какие 3 самых частых запроса будут к системе?
Нужны ли индексы (простые, составные, покрывающие)? 📊
Будет ли партиционирование по датам или другим признакам?
Выбор типа БД:

Нужны ACID-гарантии (финансы) или eventual consistency (соцсети)? ⚖️
Преимущественно запись или чтение?
Жесткая схема или гибкая структура данных?
Безопасность и compliance:

Как хранятся персональные данные (шифрование, маскирование)? 🔐
Есть ли требования к аудиту изменений (кто, когда, что поменял)?
Нужно ли логирование операций?
🔧 Практические инструменты для аналитика:

ER-диаграммы — ваш лучший друг для проектирования структуры
Прототипы запросов — напишите примеры основных SELECT/INSERT заранее
Data dictionary — документ с описанием всех полей, типов, ограничений
Миграции — предусмотрите механизм изменения схемы без простоев

💡 Золотое правило: Данные переживают приложения. Системы переписываются, а данные мигрируют. Ваша задача — спроектировать так, чтобы через 5 лет не было стыдно.

📌 Вопросы, которые должен задавать себе аналитик:

«Как мы будем искать эти данные?»
«Что будет, если два пользователя изменят одну запись одновременно?»
«Как восстановить данные при сбое?»
«Можем ли мы масштабировать это решение?»

🎯 ИТОГ: Системный аналитик — это архитектор данных, а не просто сборщик требований. Глубокое понимание БД отличает senior-аналитика от junior. Незнание основ БД сегодня — дорогостоящие ошибки завтра.

#DBMS

🔗 #INTEGRATION: КОГДА «ПРОСТО ПОДРУЖИТЬ СИСТЕМЫ» ОБХОДИТСЯ В МИЛЛИОНЫ

Приветствую, коллеги! 👋 Сегодня разберём тему, которая выглядит технической, но на деле — это зона стратегических решений аналитика. Интеграции — это не протоколы и форматы, а про риски, деньги и репутацию. Готовы к реальным историям? Погнали! 🚀

💥 Кейс 1: «Чёрная пятница, которая стала чёрным днём»

Контекст: Крупный ритейлер внедрял систему онлайн-кредитования. При оформлении заказа сайт синхронно запрашивал решение у банковского скоринг-сервиса.

Что случилось 24 ноября:
В 11:00 банковский API начал отвечать 8-12 секунд (вместо обычных 200 мс). К 12:30 наш сайт полностью лёг — все воркеры были заблокированы в ожидании ответа от банка.
Потери: 3 часа простоя в пиковый день = ~45 млн руб. упущенной выручки. 💸

Ошибка в ТЗ аналитика:
Было: «При оформлении заказа вызвать метод /check-credit банковской системы»
Не было:

Таймаутов на нашей стороне ⏱️
Асинхронной обработки
Circuit Breaker (автоматического отключения нерабочего контура)
Фолбэка на отложенную проверку
Решение: Внедрили многоуровневую стратегию:

Таймаут 2 секунды на вызов банка
Автоматический переход на локальную проверку при недоступности банка
Асинхронное обновление статуса кредита после создания заказа
Дашборд мониторинга с алертами на degradation
Вывод: Синхронные интеграции с внешними системами — это системный риск. Аналитик должен проектировать их как потенциальные точки отказа.

🔄 Кейс 2: «Миграция, которая породила монстра»

Задача: Перенести данные клиентов из старой CRM в новую. В ТЗ: «Выгрузить все данные за последние 5 лет».

Реализация: Написали скрипт, который 3 дня выгружал CSV по 2 млн строк, потом импортировал.

Что пошло не так:

Телефоны в старой системе: +7 (999) 123-45-67
Новая система ожидала: 79991234567 📱
Даты рождения: 01.01.1990 vs 1990-01-01 📅
История заказов: в старой — одна JSON-колонка, в новой — нормализованная структура
Результат: 40% данных импортировались с ошибками. Месяц ручных правок, гнев клиентов, срыв сроков запуска.

Решение аналитика: Создать детальный контракт данных:

Маппинг каждого поля с правилами трансформации
Промежуточный слой валидации
Инструмент для предварительного тестирования миграции
📌 Правило: Интеграция — это не «скопировать данные», а гарантировать их семантическую корректность.

🧩 Кейс 3: «Общая база данных как точка краха»

Архитектурный антипаттерн: 5 микросервисов одной компании писали в одну базу common_db. Казалось логичным — «данные же общие».

Проблемы, которые проявились через год:

Схемные войны: Сервис A меняет таблицу — падает сервис B 🏗
Масштабирование невозможно: Все сервисы упираются в один ресурс
Аудит катастрофы: Кто сломал данные? Все и никто.
Что должен был предложить аналитика: Принцип владения данными:

У каждого сервиса своя БД
Обмен только через API или асинхронные события
Данные дублируются, если нужно (например, кэш заказов в сервисе доставки)
🎯 ЧЕК-ЛИСТ АНАЛИТИКА ПРИ ПРОЕКТИРОВАНИИ ИНТЕГРАЦИЙ:

1. Стратегия связи:

Синхронная (REST/gRPC) — для мгновенных ответов
Асинхронная (очереди/шины) — для фоновых процессов
Пакетная (ETL) — для больших объёмов
2. Контракт данных:

Форматы (JSON/XML/Protobuf) и их версии
Кодировки и стандарты дат/чисел
Обязательные vs опциональные поля 📝
3. Обработка сбоев:

Таймауты и retry policy (сколько раз, с каким интервалом)
Circuit breaker — отключать ли проблемный сервис?
Dead Letter Queue — куда складывать неудачные сообщения? 💀
4. Мониторинг:

Метрики latency, error rate, throughput
Алёртинг при деградации (не только при падении)
Дашборды здоровья интеграций 📊
5. Безопасность:

Аутентификация (API-ключи, OAuth, mTLS)
Шифрование передаваемых данных
Rate limiting и квоты 🔐
💡 ПРОФЕССИОНАЛЬНЫЙ ИНСАЙТ:

Лучшая интеграция — та, которой нет. Прежде чем проектировать связь между системами, спросите:

🎯 ИТОГ: Проектируя интеграцию, вы создаёте долгосрочные обязательства. Плохая интеграция — это технический долг с высокими процентами. Хорошая интеграция — это надёжный мост, по которому бизнес будет ездить годами.

#INTEGRATION

📚 ПРОЧЕЕ #OTHER: ТАЙНЫ LEGACY-КОДА И ПОЧЕМУ АНАЛИТИК ДОЛЖЕН БЫТЬ ДЕТЕКТИВОМ

Привет, коллеги! 👋

Сегодня рубрика #OTHER — всё то, что не влезло в стандартные категории, но без чего системный аналитик не состоялся бы как профессионал. Речь пойдёт о работе с наследием (legacy). О тех моментах, когда документации нет, команда уволилась, а код молчит как рыба. 🕵️‍♂️

Готовы? Устраивайтесь поудобнее — будет история с реального проекта.

🕰 КЕЙС: «ПОТЕРЯННЫЙ МИР»

Контекст:
Крупный логистический оператор. Система управления заказами (1998 год постройки). Язык — Delphi, база — Oracle 9i. Автор системы уволился в 2005-м, документация — пара листов формата А4 с каракулями. Бизнес-процессы за 20 лет изменились до неузнаваемости, но система работает и её надо развивать. Задача: за месяц разобраться в логике расчёта стоимости доставки, чтобы переписать этот модуль на Java.

Первая мысль: «Открыть код и прочитать».
Реальность: 50 000 строк спагетти-кода, комментариев нет, имена переменных типа a1, xxx, superCalc. 🤯

🔎 РАССЛЕДОВАНИЕ: МЕТОД АНАЛИТИКА-ДЕТЕКТИВА

Я не программист, я аналитик. Значит, мой инструмент — не отладчик, а голова и коммуникации.

Шаг 1. Ищем живых свидетелей
Оказалось, в компании ещё работал технолог, который принимал ту систему 20 лет назад. Он помнил бизнес-логику:
*«Доставка по Москве считалась как вес * 15, но если суммарный вес больше 100 кг — дополнительный коэффициент 0,8»*.

📌 Вывод: 80% логики можно восстановить через экспертов, не глядя в код.

Шаг 2. Reverse engineering через данные
Мы выгрузили из базы 10 000 завершённых заказов: входные параметры (вес, габариты, регион) и итоговая стоимость. Построили модель машинного обучения (просто регрессию), которая предсказывала стоимость с точностью 97%. Затем проанализировали, какие признаки важны — так мы вычислили скрытые коэффициенты и формулы. 🧮

Шаг 3. Провокация системы
На тестовом контуре я отправлял «странные» заказы: отрицательный вес, нулевая стоимость, несуществующий регион. Смотрел, какие ошибки вылетают. Иногда ошибки содержали куски кода или названия процедур — это давало зацепки. Например, ошибка «Division by zero in CalculateRegionalCoefficient» подсказала название ключевого метода.

Шаг 4. Археология кода
Не читая всё подряд, я искал маркеры: названия полей из базы, константы, числа. Нашёл блок:

if Region in [1,3,5,7] then
  Coef := 1.2
else
  Coef := 1.5
Сверил с бизнес-правилами — оказалось, это надбавка за «дальнее Подмосковье».

Результат: Через 3 недели у меня была точная спецификация алгоритма на человеческом языке. Java-разработчик написал новый микросервис за 10 дней, тестирование на исторических данных показало 100% совпадение.

📦 ЧТО ЭТОТ КЕЙС ДАЁТ НАМ, АНАЛИТИКАМ?

1. Аналитик — не писарь, а исследователь
Ваша главная ценность — не в том, чтобы записать то, что говорят. А в том, чтобы докопаться до сути, когда никто не говорит или все забыли.

2. Инструменты бывают разными
SQL, Python, даже Excel — всё это оружие аналитика. В этом кейсе я использовал:

SQL для выгрузки данных 📊
линейную регрессию (sklearn) для обратного инжиниринга формул 🤖
Postman для «провокации» API 🧨
мозг и блокнот 🧠
3. Документация — живой организм
Если документации нет — создайте её сами. После проекта я написал Conceptual Specification на восстановленный модуль. Теперь система готова к эволюции.

4. Люди помнят не код, а смыслы
Общайтесь с ветеранами бизнеса, пока они не ушли. Записывайте интервью, рисуйте блок-схемы, перепроверяйте гипотезы через данные.

✅ ЧЕК-ЛИСТ «LEGACY-ДЕТЕКТИВ» ДЛЯ АНАЛИТИКА

Найти экспертов, работавших с системой на старте
Собрать исторические данные (заказы, логи) — минимум 1000 записей
Проанализировать статистику: какие значения полей, диапазоны, частоты
Построить простую модель предсказания выходного параметра
Провести исследовательское тестирование (негативные сценарии, граничные значения)
Искать в коде ключевые слова из бизнес-лексикона
Фиксировать каждую находку в виде понятной бизнес-логики
Валидировать восстановленную логику с заказчиком

#OTHER

Когда пришло письмо «Прошу подключиться к вопросу ниже»