Как начинаешь процесс анализа?

Как я начинаю процесс анализа

Процесс анализа — это структурированный подход к пониманию проблемы, требований и возможных решений. За 10+ лет я выработал методику, которая помогает избежать ошибок на ранних стадиях.

Фаза 1: Погружение и сбор информации

Первый день — слушание, не решение. Встречаюсь с заинтересованными лицами: бизнес, продукт, инженеры, поддержка.

Ключевые вопросы, которые задаю:

• Какая текущая боль? Что не работает?
• Каковы бизнес-цели? Какой результат нужен?
• Кто пользователи системы? Как они её используют?
• Какие есть ограничения? (бюджет, сроки, технологии)
• Что было попыток раньше? Почему не сработало?

Документирование: пишу все в заметках, но не анализирую пока.

Фаза 2: Исследование текущего состояния

Изучение архитектуры:

• Запрашиваю диаграммы систем (если есть)
• Изучаю код, конфигурацию, database schema
• Смотрю логи, мониторинг, алерты
• Если no documentation — рисую архитектуру сам на основе кода

Профилирование и метрики:

• Какие операции медленные? Где bottleneck?
• Какие ошибки происходят? Как часто?
• Какие ресурсы используются? (CPU, память, network)

Интервью с командой разработки:

• Что они думают о проблеме?
• Какие попытки оптимизации уже делались?
• Какие есть технические ограничения?

Фаза 3: Анализ и синтез информации

Систематизирую информацию:

• Root cause analysis — что является первопричиной проблемы
• Симптомы vs реальная проблема (часто люди описывают симптомы)
• Приоритизация по impact × effort

Пример из практики:

Когда пришел на e-commerce проект, сказали «система медленная». Но это был симптом. После анализа выявил несколько проблем:

1. Неоптимизированные SQL запросы (80% нагрузки)
2. Отсутствие кэширования (повторные запросы)
3. Неправильное использование индексов в БД
4. Memory leak в приложении

Основная причина — отсутствие профилирования на ранних стадиях.

Фаза 4: Формулирование гипотез

Не сразу прыгаю к решению. Сначала выдвигаю несколько гипотез.

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

Гипотеза 1: Проблема в SQL запросах (N+1 issue)

• Проверка: EXPLAIN ANALYZE на медленных запросах
• Вероятность: 70%

Гипотеза 2: Недостаточно памяти на сервере

• Проверка: посмотреть метрики памяти
• Вероятность: 20%

Гипотеза 3: Архитектурная проблема (неправильное масштабирование)

• Проверка: анализ потока данных между компонентами
• Вероятность: 10%

Фаза 5: Проверка гипотез

Тестирую каждую гипотезу данными:

Использую метрики, логи, профилеры. Никогда не опираюсь на интуицию.

Ошибка, которую видел много раз:
"Давайте переделаем на микросервисы, это ускорит систему"

Верно: Давайте сначала профилируем и найдем реальное узкое место
Тогда решение будет обоснованным

Фаза 6: Создание плана действий

Только когда гипотезы проверены, пишу plan:

1. Quick wins — быстрые улучшения с минимальным риском

   • Оптимизация SQL запроса
   • Добавление индекса
   • Включение кэширования

2. Medium term — улучшения, требующие 1-2 спринта

   • Рефакторинг компонента
   • Внедрение нового инструмента

3. Long term — стратегические изменения

   • Архитектурное переделывание
   • Миграция на новую технологию

Фаза 7: Документирование и презентация

Создаю документ анализа с:

• Описанием проблемы (конкретные метрики, не размытые формулировки)
• Root cause analysis
• Предлагаемые решения (с плюсами и минусами каждого)
• Временная и ресурсная оценка
• Риски и как их смягчить

Презентирую заинтересованным сторонам. Важно не только сказать «что делать», но и объяснить «почему».

Мой инструментарий

Для анализа архитектуры:

• Draw.io или ArchiMate для диаграмм
• git log для истории проекта
• Grep/Ctrl+F для поиска паттернов в коде

Для профилирования:

• EXPLAIN ANALYZE для SQL
• CPU/Memory профилеры
• APM (Application Performance Monitoring)
• Логи и метрики (ELK, Prometheus)

Для общения:

• OneNote/Confluence для документирования
• Slack/Email для асинхронного общения
• Регулярные sync встречи с командой

Ключевые принципы анализа

1. Data-driven — решения на основе данных, не угаданий

2. Пока не понял — не действую — лучше потратить день на анализ, чем месяц на неправильное решение

3. Вовлекаю команду — они знают систему лучше, чем я. Мое дело — структурировать знание

4. Простота критична — объясняю выводы так, чтобы даже не-технические люди поняли

5. Документирую для будущего — когда я уйду, выводы должны остаться

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