Production Ready: как проверить работоспособность продукта

Что значит «продукт готов»? У каждого разработчика может быть свой ответ на этот вопрос. И хотя в общем и целом представления могут совпадать, разных трактовок не избежать и рано или поздно любой команде понадобится выработать общий язык, который позволит смотреть на продукт с одних и тех же позиций и выдавать стабильный результат. Эти единые представления и составляют понятие Production Readу.

Общие критерии Production Ready помогают всей команде

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

Наш набор критериев Production Ready объединил и наши собственные знания, и лучшие практики из «внешнего мира» разработки. Этот момент стоит отдельно подчеркнуть – необязательно брать под копирку чужой опыт, у вашей команды может быть свой стиль работы. Главное, чтобы он был эффективным и соответствовал принятому вами единому стандарту.

Итак, как мы понимаем, что наш продукт действительно Production Ready?

Он соответствует требованиям проекта. Этот пункт прежде всего предполагает, что такие требования существуют, они формализованы и задокументированы. Сюда входят и запросы клиента, и пожелания пользователей, и технические требования окружений. Все участники команды про эти требования знают и ориентируются на них при разработке.
Продукт имеет хорошо продуманную архитектуру. То есть она формируется не стихийным образом. Если решение заранее спроектировано, его архитектура учитывает возможные риски и перспективы развития. Такой подход позволит команде продумать отказоустойчивость продукта, заранее определиться с техническими средствами, которые обеспечат нужную функциональность, и проверить их совместимость. Иначе в будущем может выясниться, что внедрить нужную фичу нельзя без того, чтобы переделывать фундаментальные модули продукта. От архитектуры зависят другие критерии – мы ещё не раз к ней вернёмся.
Систему можно протестировать. В данном случае мы не имеем в виду 100-процентное покрытие тестами (хотя это тоже полезная вещь). Важно закладывать саму возможность оценить работоспособность системы до того, как она запущена в бой. Не так важно, будут ли это ручные проверки или автоматизированные тесты – главное, чтобы продукт сам по себе мог получать тестовые данные и выдавать результат. На низком уровне это означает, например, что в решении нет сильно связанных классов и каждый модуль можно проверить с помощью абстракций и mock-ов. На верхнем – что у вас есть тестовое окружение и проверки работоспособности не вызовут проблемы у реальных пользователей.
Продукт работает стабильно. Не бывает систем, которые работают бесперебойно 100% времени, поэтому под стабильностью следует понимать соответствие требованиям SLA. Эти требования меняются от продукта к продукту, а иногда - даже от одного модуля системы к другому. У сайта-визитки и учётной системы принципиально разные требования к стабильности. Самое главное, чтобы они были прописаны в SLA, а команда гарантировала их выполнение.
Решение готово к поддержке. У команды есть логи и средства мониторинга, а разработчики могут быстро установить, что сломалось и как это починить. Плюс ко всему, продукт должен быть пригоден к ремонту, т.е. провести диагностику и исправить ошибку можно без переписывания всего приложения. Иногда решить проблему с продуктом не невозможно из-за ошибок на архитектурном уровне – например, разработчики выбрали шину, которая не справляется с потоком запросов, и менять нужно всю систему.
Систему можно масштабировать. Ещё один пункт, который закладывается в архитектуре. Важно помнить, что можно экономить на ресурсах, но не на технологиях. Например, при запуске продукт должен справляться с тысячей запросов в час, а через год число пользователей вырастет, и нагрузка дойдёт до десяти тысяч. Команда должна заранее представлять жизненный цикл своего продукта, понимать, какие технологии потребуются на каждом этапе и как обеспечить их работоспособность.
Продукт задокументирован. Опять же, в первую очередь речь о самой возможности готовить документацию. В широком смысле продукт должен документироваться автоматически – описание взаимодействий, инфраструктуры и т.д. должно содержаться прямо в коде.
Продукт работает. Это может показаться очевидным, но нужно понимать, что пока решение не запущено на боевом сервере и с ним не работают реальные пользователи, систему нельзя считать готовой. Если код, который выполняет все требования, лежит в Gitlab, а не запущен на сервере, продукт не готов.
Продукт приносит ценность. Это самая обширная тема, о которой можно написать отдельную статью, а то и книгу. Не погружаясь в подробности, скажем так: система решает возложенную на неё бизнес-задачу, продает билеты или страховки, обеспечивает взаиморасчеты с клиентами, помогает сотрудникам оформлять отпуска и т.д.

Подводя итог

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