Отказоустойчивость железа достигается через добавление избыточных компонентов, например, в системе может быть несколько жестких дисков, подключенных в режиме RAID-массива. В случае распределённых систем, запросы могут был равномерно распределены между несколькими независимыми машинами внутри дата-центра. Случается и так, что требуется отказоустойчивость на уровне дата-центра, тогда машины распределяют по нескольким физически независимым точкам (например, разные регионы AWS). Важно придерживаться здравого смысла и понимать какого уровня отказоустойчивости вам будет достаточно. Отказоустойчивость кода чуть сложнее. В первую очередь потому что один и тот же код может исполняться на большом пуле физически независимых друг от друга машин. Одна и та же ошибка в коде может автоматически попадать на все узлы сразу. Универсальных рецептов как избавиться от таких проблем нет, необходимо повышать прозрачность того, что происходит на железе, мониторить основные метрики (а они могут быть относительными), настраивать observability и регулярно просматривать данные. Для предотвращения повторных инцидентов полезно практиковать написание т.н. postmortems. Это анализ прошедших сбоев с целью изучения, понимания и дальнейшего предотвращения повторных случаев. Масштабируемость Масштабируемая система это система, способная работать предсказуемо надёжно в условиях увеличивающейся нагрузки. Важно понимать что не всегда система обязана быть масштабируемой. Если вы разрабатываете внутреннюю систему с ограниченным количество пользователей, то нет смысла задумываться о масштабировании, т.к. ни о каком кратном увеличении нагрузки и речи быть не может. Улучшить масштабируемость можно несколькими способами: - Добавлением новых ресурсов (улучшение памяти, дисков, CPU), вертикальное масштабирование (vertical scaling) - Добавлением новых машин, горизонтальное масштабирование (horizontal scaling) Автор подход с горизонтальным масштабированием разбивает на два: 1. Shared-Disk Architecture 2. Shared-Nothing Architecture Первый тип подразумевает отдельные машины, но все они делят между собой единый диск (например, NAS), куда пишут или откуда читают данные. Второй тип пропагандирует отсутствие общих ресурсов, а значит независимость при работе. В случае с первым типом у кластера есть бутылочное горлышко в виде общего сетевого диска. Второй подход подразумеваем более сложную организацию работы с данными (партицирование, шардирование). Следует помнить, что нет универсальных принципов, подходящих для всех. Когда речь заходит о масштабировании и улучшении производительности, то всё становится сугубо относительным и зависит от самого приложения, нюансов организации данных и технологий, используемых для его функционирования. Поддержка Львиная доля затрат приходится не на первоначальную разработку системы, а на её дальнейшую поддержку. Живая функционирующая система требует постоянной поддержки и развития. До сих пор в мире функционируют системы, разработанные на заре появления первых вычислительных машин. Возможно и ваше приложение выдержит проверку временем и в будущем будет активно поддерживаться другими людьми. Чтобы снизить тяжесть бремени поддержки стоит придерживаться нескольких принципов: - Работоспособность (Operability) - Простота или управляемая сложность (Simplicity) - Расширяемость или жизнестойкость (Evolvability) Работоспособность - Автоматизация рутинных задач (например, CI/CD, внедрение DevOps практик) - Автоматический сбор и анализ состояния работы систем и подсистем (Observability & Monitoring) - Актуальная документация и база знаний - Внедрение практики дежурства и postmortems, SRE-практик Простота или управляемая сложность Авторы книги сложность системы делят на два типа: 1. Необходимая (Essential), она появляется из сложности самой доменной области приложения при проектировании 2. Случайная (Accidental), такой тип сложности уже возникает из-за ошибок в проектировании, организации кода, компромиссов при выборе технологий