Почему надежность сложной системы нельзя держать в голове одного человека

Цифровые сервисы должны выдерживать не только привычную нагрузку, но и резкие скачки активности, когда за считаные секунды к ним обращаются миллионы пользователей. Однако надежность системы проверяется не только количеством запросов. Иногда достаточно десятикратного роста объема данных, чтобы обнаружить слабые места архитектуры, которые прежде оставались незаметными.

Фото: из личного архива Данила Редько

Инженер-разработчик Данил Редько

Инженер-разработчик Данил Редько специализируется на серверных системах и инфраструктуре, рассчитанной на высокие нагрузки. В одном из проектов он фактически совмещал работу архитектора, разработчика и инженера по инфраструктуре. Система, которую создавала его команда, выросла с 200 тысяч до двух миллионов обрабатываемых документов в месяц. Вместе с масштабом проявились и слабые места: база данных перестала справляться, а отдельные компоненты начали выходить из строя.

В интервью Pravda.ru Данил Редько рассказал, как небольшая команда может создавать сложные системы, почему масштабируемость нельзя отделять от качества данных и какую инженерную ошибку он сегодня не стал бы повторять.

— Данил, вы совмещали разработку, проектирование архитектуры и работу с инфраструктурой. Как вы пришли к такой роли?

— Сначала я пришел в компанию как разработчик, работавший и с серверной, и с клиентской частью приложений. Постепенно обязанности расширились: сначала из команды ушел инженер по инфраструктуре, и его задачи перешли ко мне. Затем я стал самостоятельно проектировать архитектуру и принимать инфраструктурные решения. В итоге фактически совмещал несколько ролей, хотя официально никто не назначал меня ни архитектором, ни инженером по инфраструктуре. Плана стать специалистом, который отвечает за все, не было. Я разбирался по ходу работы, потому что системе требовались решения, а команда была небольшой.

Мы разрабатывали систему автоматического сбора данных, которая обходила сайты муниципалитетов и собирала информацию о бюджетах, планах капитальных вложений и тендерах. На основе этих данных Citylitics предоставлял корпоративным клиентам информацию для поиска коммерческих возможностей. Например, поставщик труб или компания, строящая мосты, могли понять, какому городу и когда понадобятся их услуги. В работе использовались Kubernetes, RabbitMQ, Elasticsearch и PostgreSQL. Это была не просто задача сбора информации: требовалось обрабатывать большие объемы документов и сохранять точность данных, от которой зависела ценность продукта.

— Когда один человек отвечает и за разработку, и за инфраструктуру, что обычно страдает первым?

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

Когда совмещаешь несколько ролей, неизбежно приходится расставлять приоритеты. Я недостаточно внимания уделял этому направлению, и во время инцидентов стало сложно понять, почему произошел сбой. Приходилось вручную изучать журналы событий и собирать картину по отдельным фрагментам.

Если бы я начинал проект заново, наблюдаемость была бы в приоритете с первого дня, а не после появления проблем. Это не дополнительное удобство, а часть архитектуры надежной системы.

— При этом вы не стали экономить на масштабируемости. Почему именно она была принципиальна?

— Нам было критически важно обрабатывать большой объем документов с высокой точностью. Если точность снижалась, страдал продукт, а вместе с ним и бизнес. Это была не техническая прихоть, а прямая связь между инженерным решением и ценностью, которую мы давали клиентам.

Масштабируемость в таком проекте — не просто способность принять больше запросов. Важно, чтобы при росте объема не ухудшалось качество обработки. Иначе можно увеличить производительность на бумаге, но фактически начать выдавать клиентам менее полезные данные.

— В какой момент стало понятно, что прежняя архитектура больше не справляется?

— Мы улучшили систему сбора данных, добавили поддержку новых типов документов и расширили охват. В результате объем вырос с 200 тысяч до двух миллионов документов в месяц. Инфраструктура к такому росту готова не была.

Проблемы возникли сразу в двух местах. База данных перестала справляться с нагрузкой, а отдельные экземпляры приложений в Kubernetes начали аварийно завершать работу из-за ее чрезмерного роста. Конвейер обработки данных стал работать хуже, и вместе с ним снижалась точность. Стало ясно, что недостаточно просто увеличить ресурсы. Нужно пересмотреть архитектуру и понять, какие компоненты масштабируются независимо друг от друга.

— Что пришлось изменить?

— Мы переработали систему под Kubernetes с автоматическим масштабированием, чтобы отдельные экземпляры приложений могли увеличиваться в количестве в зависимости от нагрузки. Базу данных масштабировали отдельно, поскольку у нее были собственные ограничения и характер нагрузки.

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

— Как вы проверяли, что после изменений система действительно готова к работе?

— Мы много тестировали в изолированной среде. Запускали реальный процесс сбора данных, наблюдали за поведением системы, проверяли ее под нагрузкой до развертывания в рабочей среде.

Для меня важен не только формальный результат испытаний. Нужно видеть, как система ведет себя в реальных условиях: выдерживают ли компоненты нагрузку, не появляются ли новые узкие места, сохраняется ли стабильность обработки. Мы смотрели на систему в работе, а не только на отдельные показатели. Это позволило обнаружить проблемы до того, как изменения затронули рабочую среду.

— По каким признакам вы поняли, что система перестала быть хрупкой?

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

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

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

— В обоих случаях важно заранее понимать, как система поведет себя при резком росте нагрузки. Но характер нагрузки и требования к результату могут различаться.

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

Общий инженерный принцип — не считать систему готовой только потому, что она работает при обычной нагрузке. Нужно понимать ее поведение в условиях, для которых она и создается.

— Сейчас вы разрабатываете программные интерфейсы для интеграции искусственного интеллекта в рабочие процессы крупных международных компаний. Меняется ли с появлением ИИ само понимание надежности?

— Когда искусственный интеллект встраивается в рабочие процессы, он становится частью более сложной системы. Поэтому важно не только обеспечить взаимодействие с моделью, но и продумать, как оно вписывается в существующую инфраструктуру и процессы компании. Для инженера по-прежнему важны предсказуемость, устойчивость и понимание того, что происходит на каждом этапе. Чем больше компонентов участвует в процессе, тем важнее видеть их взаимосвязи и уметь разбирать сбои.

— Какой главный профессиональный вывод вы сделали из опыта, когда одновременно отвечали за архитектуру, разработку и инфраструктуру?

— Когда один человек закрывает все эти направления, система работает ровно до тех пор, пока он держит в голове все принятые компромиссы. Но это ненадежная модель: человек может забыть детали, уйти из проекта, переключиться на другие задачи.

Именно поэтому наблюдаемость для меня теперь не приятный бонус, а обязательная часть инженерной работы. Она позволяет не только разобраться в инциденте сегодня, но и понять систему самому через полгода или передать ее другому специалисту.

Сложную систему можно построить небольшой командой. Но ее устойчивость определяется не тем, сколько задач способен взять на себя один инженер, а тем, насколько понятны архитектура, ограничения и поведение системы всем, кто с ней работает. Иначе каждый сбой превращается в детективное расследование, а надежность остается зависимой от памяти одного человека.