Выявление узких мест в существующих решениях
~ 45 минут
В любой сложной системе всегда есть точки, где что-то идёт не так: задерживается выпуск обновлений, возникают постоянные ошибки на продакшне или медленно реализуются новые функции. Это тормозит развитие продукта и напрямую влияет на его успех: пользователи начинают терять терпение, а бизнес — деньги.
Представьте, что вы ведёте машину, а двигатель начинает перегреваться. Проблема не в машине целиком, а в конкретной детали — радиаторе, который плохо справляется с охлаждением.
Похожая ситуация и в разработке: отдельные проблемы мешают всей системе двигаться с нужной скоростью, даже если в целом всё выглядит нормально. Участки процесса, которые работают медленно или неэффективно, создавая «бутылочные горлышки» в развитии продукта, мы называем узкими местами. Они могут быть как в коде, так и в самих процессах работы команды.
Найти их, чтобы потом устранить, — значит дать системе возможность работать быстрее, проще и надёжнее. Здесь на помощь приходят метрики — объективные данные, которые показывают, что и как работает. Анализируя их, можно увидеть скрытые проблемы и спланировать, как их исправить. Именно об этом мы сейчас и поговорим: как смотреть на метрики так, чтобы находить самые слабые места в вашей системе. Особенно это актуально перед началом миграции для больших унаследованных сред.
Узкие места в системе
В любой системе неизбежно возникают проблемы, которые ограничивают её производительность или стабильность: задержки, неэффективные процессы, ошибки архитектуры, сбои интеграций.
Для структурного анализа узких мест удобно использовать диаграмму Исикавы, или «рыбью кость». Этот инструмент помогает выявить первопричины проблемы, разделяя их на категории: люди, процессы, технологии, окружение и так далее.
Возьмем, например, ситуацию, когда производительность микросервисной архитектуры резко падает под высокой нагрузкой. Диаграмма может помочь выявить ключевые причины в разных категориях
- Технологии: неэффективные алгоритмы обработки данных или узкие места в сетевых соединениях.
- Процессы: недостаточное покрытие нагрузочным тестированием или некорректная балансировка нагрузки.
- Люди: нехватка квалификации команды в работе с выбранным стеком технологий.
- Окружение: ограничение ресурсов контейнеризации или ошибок в конфигурации оркестратора.
Почему важно выявлять узкие места?
Прежде чем менять архитектуру или внедрять новые технологии, важно знать, в чём недостатки существующих решений.
- Снижение рисков во время миграции
Процесс миграции систем сопряжён со множеством рисков. Без анализа текущего состояния можно упустить критические проблемы, которые только усугубятся после изменений. Например, если в текущей архитектуре существуют узкие места в обмене данными между модулями, миграция на микросервисную модель без устранения этих проблем приведёт к увеличению количества ошибок и ухудшению производительности.
Понимание, где именно кроются слабые места, позволяет заранее спланировать шаги по их устранению. Это может быть изменение архитектуры, оптимизация процессов или внедрение дополнительных инструментов мониторинга, чтобы избежать неожиданных сбоев.
- Сокращение времени вывода продукта на рынок (Time-to-Market, T2M)
Выявление медленных циклов выпуска, слишком сложных кодовых зависимостей или проблем с координацией действий команды сокращает время разработки и развёртывания.
💡 Time-to-market (T2M) — один из ключевых показателей, который напрямую влияет на конкурентоспособность продукта. Медленные циклы выпуска обновлений, сложные зависимости между компонентами и низкая скорость реакции на изменения в бизнес-требованиях сильно замедляют разработку.
Например, если для внедрения даже небольшого изменения требуется координация работы нескольких команд, это значительно увеличивает T2M. Выявление таких узких мест позволяет пересмотреть процессы: возможно, имеет смысл перейти на микросервисную архитектуру, чтобы команды могли работать независимо, или внедрить фича тоглы, чтобы уменьшить зависимость от больших релизов.
В результате обновления будут выходить быстрее, бизнес быстрее реагировать на запросы клиентов, а пользователи получат улучшения без задержек.
- Приоритизация усилий
Когда проблем много, легко потеряться в том, за что взяться в первую очередь. Узкие места помогают сфокусировать внимание на самых критических зонах. Например, если анализ показывает, что 80% времени на разработку теряется из-за сложных зависимостей между командами, то устранение этих зависимостей станет самым эффективным использованием ресурсов.
Приоритизация усилий позволяет сэкономить время и деньги, сосредоточив ресурсы на устранении проблем, которые несут наибольшие риски. Ещё это помогает избежать распыления ресурсов на незначительные улучшения, которые не влияют на общую производительность системы.
- Согласованность с требованиями к соответствию и управлению
Современные системы должны соблюдать требования к безопасности и управлению данными. Например, несогласованность данных между модулями может привести к ошибкам в обработке транзакций или нарушению требований законодательства вроде GDPR или HIPAA.
Выявление проблем с целостностью данных или отсутствием контроля доступа помогает заранее устранить их и избежать штрафов, потерь данных или повреждения репутации компании.
Учёт рисков при миграции
Вспомним про компанию HealthConnect, отвечающую за данные о пациентах, планирование и выставление счетов. Представим, что сейчас это большое монолитное приложение, в котором несколько отделов (биллинг, записи пациентов, рецепты, результаты анализов) используют одну массивную кодовую базу. Все функции, такие как новые формы записей пациентов или интеграция с API страховой компании, выпускаются вместе каждый квартал.
Здесь можно обнаружить несколько узких мест:
- Зависимость от команды
Команда биллинга ждёт, пока команда записи пациентов закончит свои изменения, поскольку оба обновления должны войти в один и тот же квартальный релиз. Эта зависимость увеличивает время выхода на рынок (T2M) для каждой новой функции.
Последствие этого — отложенные улучшения. Например, простое исправление дозировки лекарств может ждать следующего релиза три месяца.
Возможное решение — разбить монолит на более мелкие сервисы, которые можно выпускать независимо друг от друга.
- Единый цикл выпуска
Все изменения, большие и малые, связаны в единый артефакт для развёртывания. Даже мелкие исправления ошибок ожидают следующего большого релиза, что замедляет инновации и реакцию на срочные проблемы.
Эта ситуация приводит к неспособности быстро реагировать на изменения в законодательстве. Например, новые требования HIPAA приводят к рискам, связанным с соблюдением нормативных требований.
Здесь поможет внедрение фича тоглов или стратегий параллельного запуска для развязывания циклов выпуска друг от друга.
Изменение моделей обмена данными
Закон Конвея
Хотя с законом Конвея вы уже знакомы, напомним его определение.
✏️ Закон Конвея — это принцип, который подчёркивает связь между коммуникационной структурой компании и проектируемыми ею системами. Это означает, что то, как команды общаются и сотрудничают, напрямую влияет на то, как устроена система или продукт.
Закон Конвея гласит, что структура организации влияет на дизайн системы, и это влияние может быть взаимным: организационная структура формирует подход к разработке, а технический дизайн может требовать изменений в организации. Например, если несколько команд работают над компилятором, конечный продукт, скорее всего, будет состоять из нескольких этапов обработки, отражающих распределение задач между командами.
Пример
В HealthConnect отдельная команда аналитиков работает в отрыве от основной команды разработчиков. В результате код и инфраструктура аналитики развиваются как отдельная подсистема без удобных точек интеграции. Когда требуются новые показатели пациентов, основная платформа вынуждена ждать корректировки аналитики, что задерживает понимание.
Получается, что архитектура программного обеспечения имитирует границы отделов, создавая интерфейсы, которые сложно поддерживать и расширять. Форматы данных не соответствуют друг другу, а API между модулем учёта пациентов и аналитической подсистемой оказываются несовместимы.
Проблему можно решить, изменив структуру команд так, чтобы она лучше соответствовала устройству системы, что упростит взаимодействие и устранит узкие места. Другой вариант — создать кросс-функциональные группы, которые будут отвечать за весь процесс, что поможет сделать систему более цельной и согласованной.
Event Sourcing и единый источник правды
Часто узкое место возникает, когда несколько доменных областей напрямую изменяют одни и те же данные. Это приводит к конфликтам данных, неактуальным чтениям и сложным усилиям по координации.
Пример
Страховка пациента часто меняется. Команда биллинга в HealthConnect обновляет данные о страховом покрытии после проверки соответствия требованиям. Одновременно команда по учёту пациентов изменяет личную информацию для обновления персональных данных. Оба обновления применяются к одной и той же таблице базы данных
Patient_Info. Это приводит к конфликтам версий и задержкам в обновлении последующих систем.Взаимосвязанные обновления данных приводят к несовместимым состояниям и блокировкам в базе данных. Логика для определения приоритетов изменений и предотвращения потери данных слишком запутанная.
Решением может быть переход на Event Sourcing, где изменения записываются как события (например,
InsuranceCoverageUpdated), а нижестоящие системы подписываются на них для создания согласованного представления данных в своих доменных зонах. Это уменьшает риск несанкционированного доступа и упрощает управление конфликтами.Метрики для выявления узких мест
Одним из самых эффективных способов выявления узких мест является анализ метрик, которые дают объективное представление о состоянии системы. Метрики помогают понять, где возникают проблемы, что мешает команде работать эффективно и где стоит улучшить процессы. Рассмотрим несколько ключевых показателей, которые стоит отслеживать.
1. Частота развёртывания (Deployment Frequency)
Этот показатель измеряет, как часто команда выпускает обновления и новые функции в продукт. Высокая частота развёртываний свидетельствует о гибкости и способности команды быстро адаптироваться к изменениям. Если частота развёртываний низкая, это может указывать на проблемы в процессе разработки или тестирования, которые тормозят выход новых релизов. Узкое место здесь может быть связано с техническими или организационными ограничениями, такими как сложность инфраструктуры, недостаток автоматизации или плохая координация между командами.
Что нужно искать? Если частота развёртываний ниже ожидаемой, это может быть сигналом о проблемах с непрерывной интеграцией или развёртыванием, которые требуют внимания.
2. Время ожидания изменений (Lead Time for Changes)
Этот показатель измеряет, сколько времени проходит с момента запроса на изменение до его фактического развёртывания в продакшн. Чем меньше это время, тем быстрее команда может реагировать на потребности пользователей или на изменения в бизнес-требованиях. Долгое время ожидания изменений может свидетельствовать о блокировках в процессе разработки, например, из-за сложных зависимостей, долгих циклов тестирования или перегруженности команд.
Что нужно искать? Если время ожидания изменений растёт, важно понять, что именно замедляет процесс: возможно, это избыточное тестирование, ручные операции или проблемы с управлением задачами.
3. Количество ошибок и MTTR (среднее время на исправление)
Количество ошибок показывает, сколько инцидентов или багов возникло за определённый период, а MTTR (Mean Time to Recovery) — это среднее время, необходимое для устранения этих проблем. Высокий уровень ошибок и долгий MTTR говорят о том, что система не только ошибочна, но и медленно восстанавливается, что ухудшает пользовательский опыт.
Что нужно искать? Если ошибки возникают часто или если исправление багов занимает слишком много времени, это может указывать на проблемы с качеством кода, тестированием или процессами развёртывания. Это также может быть связано с недостаточной автоматизацией или плохим мониторингом ошибок.
4. Метрики производительности
Метрики производительности измеряют скорость выполнения критически важных операций для пользователя, таких как обработка запросов, время отклика системы, задержки при загрузке страниц или при генерации отчётов. Например, в медицинских приложениях важным показателем может быть время получения результатов анализов пациента или время, необходимое для формирования счёта. Задержки в таких операциях могут привести к плохому пользовательскому опыту и снизить доверие к продукту.
Что нужно искать? Если метрики производительности показывают значительные задержки в критичных операциях, это явный признак узкого места. Возможно, система не справляется с нагрузкой или имеется неоптимизированный код или архитектурные проблемы.
5. Показатели RTO и RPO
RTO (Recovery Time Objective) — это время, за которое необходимо восстановить работу системы после сбоя. RTO оценивает, сколько времени бизнес может быть недоступен, и включает анализ систем и приложений.
RPO (Recovery Point Objective) — допустимое количество данных, которое компания может потерять с момента последнего резервного копирования. RPO определяет, насколько свежими будут данные после восстановления, и измеряется временем от последнего бэкапа.
Оба показателя помогают планировать аварийное восстановление, балансируя риски простоя, потери данных и стоимость восстановления. Надёжные RTO и RPO минимизируют убытки и защищают прибыль компании.
После того как вы соберёте и проанализируете данные по этим метрикам, следующим шагом будет выявление причин, стоящих за ухудшением показателей. Например, если вы видите, что частота развёртываний низкая, а время ожидания изменений большое, это может указывать на проблему с координацией между командами или с автоматизацией тестирования. Если же метрики производительности показывают задержки, стоит искать решение в оптимизации кода или изменении архитектуры.
Шаг 1. Соберите данные.
Первый шаг — понять, с чем мы работаем. Чтобы найти проблему, нужно видеть полную картину. Используйте инструменты мониторинга и логирования, такие как Grafana, Prometheus или специализированные системы для анализа DevOps-метрик (например, DORA-метрики).
Цель этого шага — собрать как можно больше информации о том, как работает ваш продукт: что происходит с системой при изменениях, как часто возникают ошибки и сколько времени уходит на их устранение.
Шаг 2. Проанализируйте тренды.
Теперь, когда данные собраны, нужно понять, как они меняются с течением времени. Например:
- Частота развёртываний. Выпускаете ли вы обновления реже, чем раньше? Если да, это может указывать на проблемы с процессами или зависимостями внутри команды.
- Время выполнения изменений. Если реализация новых идей занимает всё больше времени, стоит выяснить, что именно тормозит процесс.
- Ошибка на релизе. Если каждый второй релиз сопровождается багами, очевидно, что где-то проседает качество тестирования или код-ревью.
Используйте исторические данные, чтобы найти точки, где показатели начали ухудшаться. Например, если до определённого момента релизы выходили раз в неделю, а теперь это занимает месяц, то в этом временном промежутке стоит искать причину.
Сравнивайте метрики между командами, продуктами или даже разными периодами разработки, чтобы увидеть отклонения. Сравните текущие показатели с ожидаемыми или историческими значениями. Например, если частота развёртываний снизилась, стоит выяснить, какие процессы тормозят релизы.
Шаг 3. Идентифицируйте корневую проблему.
Найдя странности в данных, нужно понять, что за этим стоит. Узкие места часто связаны с одной из следующих причин:
- Сложность архитектуры. Например, монолитное приложение, где изменения одной части системы затрагивают все остальные, что вызывает задержки.
- Зависимости между командами. Если ваша команда не может завершить задачу, пока другая не сделает свою часть, это значительно увеличивает время выполнения изменений.
- Неоптимальные процессы. Возможно, время тратится на согласования, долгие циклы тестирования или ручное управление конфигурациями.
Пример
Если метрики показывают, что развёртывания занимают больше времени, начните с проверки процесса деплоя. Может быть, сборка слишком сложная или каждый релиз требует участия нескольких команд. Если растёт количество ошибок, изучите, как проводятся тесты и код-ревью — возможно, они недостаточно качественные или слишком поверхностные. Если время выполнения изменений растёт, это может быть связано с большими зависимостями между командами или сложностью архитектуры.
Анализ метрик продукта
Опираясь на существующие метрики, можно обнаружить скрытые узкие места.
Например, медицинское приложение отвечает за запись пациентов на приём к врачу, обработку страховых заявлений и формирование ежемесячных отчётов. Предположим, существующие метрики показывают, что за последний квартал среднее время ожидания при формировании счетов удвоилось. Это тревожное увеличение свидетельствует о наличии узких мест в процессе получения данных или обработки данных, связанных с выставлением счетов.
Если количество неудачных операций по выборке данных коррелирует с определённым временем суток или конкретными путями кода, вы будете знать, что в первую очередь нужно исследовать именно эти области.
Разработка новых метрик
Если стандартные метрики измеряют только верхнеуровневые показатели, вроде общего количества запросов в секунду, вам понадобятся более детальные данные.
Например, если возникают задержки при обновлении записей пациентов, можно ввести метрики, измеряющие «Задержку обновления записей пациентов» или «Длительность расчёта счетов».
Ориентируясь на эти показатели, получится определить, что является причиной замедления работы — конкретный вызов микросервиса или операция базы данных. Например, если показатели «Шаги обработки страховых заявлений» постоянно растут, возможно, вы излишне усложнили рабочий процесс по обработке заявлений или какой-то конкретный шаг и он нуждается в переработке.
Мониторинг и логирование
В то время как метрики показывают тенденции, инструменты мониторинга и логирования обеспечивают более полный контекст. Логи показывают, какие операции длились дольше всего, при каких условиях и какие ошибки возникали. Мониторинг позволяет определить использование ресурсов, задержку в сети и другие технические показатели, влияющие на производительность.
Практическое использование инструментов
С помощью этих инструментов можно выявить закономерности. Если каждое замедление коррелирует с конкретным заданием, выполняемым командой аналитиков, то, скорее всего, это задание является ключевым узким местом.
В целом если определённые функции постоянно вызывают предупреждения, это говорит о том, что в архитектуре этих систем есть проблемы.
💡 Лучшие практики
- Начинать с критического пути
Сначала сосредоточьтесь на наиболее важных для бизнеса рабочих процессах. Например, если регистрация пациентов очень важна, начните с изучения всех этапов — от ввода форм до записи в базу данных.
- Сопоставлять технические и бизнес-показатели
Согласуйте показатели производительности с бизнес-результатами. Измеряйте не только задержку API, но и удовлетворённость пациентов или скорость обработки заявок.
- Подтверждать гипотезы с помощью экспериментов
Проводите целевые нагрузочные тесты или используйте фича тоглы для подтверждения предполагаемых узких мест. Вы можете внедрить временный слой кеширования, чтобы проверить, сократит ли он время запроса результатов анализов пациента.
- Привлекать межфункциональные команды
DevOps, службы безопасности и владельцы продуктов помогут получить полное представление о проблемах. Если специалисты по соблюдению нормативных требований отмечают задержку запросов на удаление данных, это может указывать на медленные пакетные задания, которые нуждаются в оптимизации.
Чтобы систематически выявлять места, где архитектура или процессы не соответствуют бизнес- и техническим задачам, вы можете использовать описанные выше практики и чек-лист, который мы подготовили.
Итоги
- Узкие места в системе могут значительно снижать эффективность работы и качество продукта. Для их выявления используется диаграмма Исикавы (или «рыбья кость»), которая помогает структурированно анализировать причины проблем, разделяя их на категории и позволяя найти корневые факторы, влияющие на систему.
- Определение узких мест необходимо для снижения рисков, особенно во время миграции систем, и для сокращения времени вывода продуктов на рынок (T2M). Это также помогает правильно расставить приоритеты в работе, обеспечить согласованность с требованиями регуляторов и повысить управляемость процессов.
- По Закону Конвея архитектура системы неизбежно отражает коммуникационные структуры организации, которая её создаёт. Это означает, что, если внутри компании команды работают изолированно друг от друга, продукт, скорее всего, будет состоять из плохо интегрированных частей. Решением проблем, связанных с этим законом, может быть внедрение Event Sourcing — подхода, при котором изменения состояния системы записываются как события. Это улучшает согласованность данных и облегчает взаимодействие между различными компонентами и командами.
- Для поиска узких мест полезны метрики, такие как частота развёртываний (Deployment Frequency), время ожидания изменений (Lead Time for Changes), количество ошибок и среднее время восстановления (MTTR). Метрики производительности, а также показатели восстановления и устойчивости (RTO и RPO) помогают точно определить слабые места и эффективно их устранить.
- Чтобы оценить состояние системы до проектирования миграции, стоит наладить мониторинг для определения параметров, выявления медленных операций и понимания шаблонов доступа к данным. Важно следовать структурированным методам, чтобы сосредоточиться на критических путях, проверить гипотезы и убедиться, что аспекты дизайна соответствуют целям миграции.