Принципы СТО Amazon

👉Думайте о решении реальных проблем, а не о хайпе. Не нужно внедрять технологии только из-за FOMO.
👉Сбои и падения – часть плана, не нужно строить идеальные системы. На больших масштабах каждая дополнительная девятка в SLA стоит миллионы. Стремиться сделать отказоустойчивыми все элементы системы – дорого и бессмысленно. Вместо этого можно думать про три категории сервисов – Tier 1 (ни в коем случае не должно падать), Tier 2 (может немного деградировать), Tier 3 (может упасть, и никому не будет дела).
👉Разделяйте решения на обратимые и необратимые, они же – one-way/two-way doors. Обратимые решения принимайте как можно быстрее на неполных данных. Необратимые – замедлитесь и подумайте глубоко.
👉Security > Operations > Cost. Security – нельзя допускать никаких компромиссов в вопросах безопасности. Operations – софт дольше живет в продакшне, чем в разработке, так что удобство его поддержки должно быть заложено на самом старте. Cost – системы должны дизайниться с расчетом не только на масштабирование, но и наоборот, на возможность сжиматься в меньшие масштабы.
👉Кто сервис написал, тот за него дальше и отвечает – поддерживает, дежурит, чинит аварии по ночам. Благодаря этому у инженеров сохраняется плотный цикл обратной связи, и они видят последствия своих решений.