SRE. Рецепты выживания в продакшене для инженера по надежности

Здесь менеджеры продукта в прямом смысле соревнуются с инженерами: кто же выиграет – скорость запуска или архитектура?

При появлении очередного проекта, который надо сделать быстро-быстро, первое приходящее в голову звучит так: "Хмм, у нас уже есть в продакшене монга-постгря-мускуль-чтоугодно, подселим новую базу для проекта туда!"

Не стоит так делать. А если делаете, то осознавайте последствия и риски. Получается связанность критических компонентов двух совершенно разных проектов. Пойдёте базу обновлять – накосячите и сломаете оба проекта.

Придёт большой трафик обновления в один проект, база начнёт тормозить и сломает второй проект.

Вот ещё несколько очевидных проблем проблемы, связанных с такой практикой:

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

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

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

Возьмите себе за правило: один проект – одна база данных.

Деньги: С первого взгляда может казаться, что это лишняя работа и лишний расход средств.

Помните, пытаясь сэкономить на таких решениях, вы берете эти деньги в кредит у себя будущего под высокий процент.

13. Расселяйте критичные сервисы и непредсказуемые сервисы

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

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