Про надёжность 🚀

В одном замечательном банке очень любили надежность. 

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

В итоге, взяли самый надёжный в мире брокер сообщений и, желая сделать взаимодействие ещё надёжнее, сделали его менее надёжным. А что надо было сделать? С умом подойти к настройке retention policy и retry policy, внимательно подумать над разными failover сценариями.

Или другой пример: с целью повышения надёжности всей IT-инфраструктуры банка каждый критически важный сервис (то есть, просто каждый), который взаимодействует с базами данных, обязан все данные сохранять ещё и в запасную базу данных. Чтобы, когда первая база данных умрёт, можно было переключиться на запасную. 

Тоже хотели надёжнее, а сделали наоборот. Что надо было сделать? Использовать зарекомендовавшие себя опенсурсные БД на геораспределенных кластерах.

А что плохого то?

Почему я считаю, что озвученные решения менее надёжные? Очень просто: главный фактор, влияющий на надёжность - это сложность системы. Чем больше разных двигающихся частей, тем больше деталек может сломаться. В физических терминах: чем больше степеней свободы, тем выше энтропия, хаос.

Это как с автоматом Калашникова. Почему это самый надёжный автомат в мире? Да потому что он настолько простой, что там ломаться особо нечему. Ну почти.

Это правило работает всегда?

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

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

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

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