Надежность: качество релизов

Недавно писал сюда нашу стратегию надежности. Думаю, стоит раскрыть чуть подробней некоторые пункты - почему они важны и полезны. В этот раз - про качество релизов.

Пусть у вас в эксплуатации находится сложная и развестстая система сервисов, обеспечивающих функционирование вашего продукта. Даже если ее не трогать (вообще убрать руки с клавиатуры) она долго не протянет. Но мы же постоянно норовим нанести пользы и причинить добро. А потому катаем разного рода релизы по 50+ раз в неделю (это не преувеличение, это количество релизов только бекендов Еды за прошлую неделю).

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

Например, сделать в ci-пайплайне автоматическое нагрузочное тестирование микросервиса в изолированном load-окружении перед каждой выкладкой. Если ваш сервис поработает хотя бы 10-15 минут под полной нагрузкой, у вас будут шансы увидеть намного больше, чем при функциональном тестировании - обычные тесты не смогут спровоцировать корки (сегфолты), утечки или проезды по памяти. Вы сможете убедиться, что утилизация ресурсов и тайминги ответов не ухудшаются vs прошлый релиз. Что вы нигде не наворотили с алгоритмической сложностью, сделав вложенный цикл или выбрав неудачную структуру данных. Да, внедрение требует усилий. Да, нужно поддерживать патроны (запросы) в актуальном и релевантном состоянии. Да, отсутствие проблем в релизе это не гарантирует. Но это хорошая солома, которую лучше подстелить.

Также можно проверять капасити системы end-to-end нагрузочным тестированием в продакшне. Это поможет своевременно заметить нахватку запаса прочности по системе в целом, а иногда - заметить проблемный релиз, произошедший между регулярными стрельбами. Тестировать можно скриптом, можно танком - важно, что если у вас транзакционный сервис, должен проверяться цикл заказа (главное - не забудьте отметить в системе тестовые заказы тестовыми).

Разумеется, у вас есть тестирование. Но если оно по большей части ручное, вам не избежать ошибок из-за человеческого фактора. А если у вас в добавок очень много тесткейсов, вряд ли вы сможете при каждом релизе проверять их все. Скорее всего, вы придумаете какой-то подход с чередованием паков тестов от релиза к релизу. Но автоматизировав 75-80-90% тестов, вы получите и снижение пропусков, и возможность всегда гонять весь пак регресс-тестов. Без этого - никак.

Ну и понятная, но не очень простая в реализации вещь - кататься лучше маленькими кусочками. Чтобы не было принципа "одно лечим - другое калечим". Разбиение приложения на модули, уход от монолитов (не только на беке - с фронтами та же история), сокращение импакта изменений, изоляция блоков - залог более крепкого сна после выкладки. Различные bdui-подходы этому тоже помогают. Впрочем, тема bdui намного шире, про нее стоит как-нибудь поразгонять отдельно.