[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-single-point-of-failure::ru":3,"gloss-cluster-single-point-of-failure::ru":23,"gloss-next-single-point-of-failure::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"single-point-of-failure","cloud","Единая точка отказа","Единая точка отказа — это любой компонент, потеря которого останавливает всю систему, сколько бы других частей ни было продублировано. Выражение старое и по-прежнему полезное, потому что названная им вещь почти никогда не находится там, куда указывает схема архитектуры. Команды дублируют очевидное рано — два сервера, две зоны, реплика базы — а потом накапливают зависимости второго рода, которые резервировать никто не собирался: единственная машина, где крутится ночное задание; сертификат, который продлевает один человек; учётная запись, чьи данные почему-то общие для всех сервисов; очередь, через которую идут все пути; маленький внутренний сервис, написанный годы назад, без которого ничего не стартует. Резервирование тоже ломается способом, который стоит назвать: две копии независимы, только если не могут отказать по одной причине. Два экземпляра одной программы с одним дефектом встретят один и тот же вход в один и тот же день. Две зоны, питаемые одной конфигурацией, получат одно и то же плохое изменение с разницей в минуту. Два поставщика, которые разрешают имена через один и тот же вышестоящий сервис, для этого сервиса являются одним поставщиком. Полезное упражнение — не рисовать схему, а допрашивать её: выберите каждый прямоугольник и спросите, что станет с пользовательским запросом, если это исчезнет прямо сейчас; затем спросите то же о том, что прямоугольниками не является, — о человеке, учётных данных, договоре, сборочном конвейере, регистрации домена. Ответы дают короткий список. Большинство пунктов в нём чинится дёшево, как только записано, и ценность упражнения почти целиком в том, что они записаны до ночи, когда один из них обнаружит сбой. Стоит принять и то, что часть из них останется. Убрать все — не инженерная цель, а бесконечный регресс, и компания, делающая вид, что это не так, получает дорогую архитектуру и никакого плана. Полезная позиция — знать, какие вы решили оставить, иметь записанным, что вы делаете, когда каждая из них отваливается, и пересматривать список, когда система меняет форму.","Единая точка отказа останавливает всё независимо от дублирования. Почему настоящие точки — это люди, ключи и задания, а не серверы.",null,[11,14,17,20],{"slug":12,"name":13},"availability-zone","Зона доступности (Availability Zone)",{"slug":15,"name":16},"blast-radius","Радиус поражения",{"slug":18,"name":19},"disaster-recovery","Аварийное восстановление",{"slug":21,"name":22},"multi-region","Мультирегиональная архитектура (Multi-Region)",[24,28,32,33,36,39,43,46,49,52,55,58],{"slug":25,"category":5,"name":26,"updated_at":27},"air-gapped-deployment","Развёртывание без выхода в сеть","2026-09-09T03:30:02+00:00",{"slug":29,"category":5,"name":30,"updated_at":31},"autoscaling","Автомасштабирование (Autoscaling)","2026-09-08T21:32:36+00:00",{"slug":12,"category":5,"name":13,"updated_at":31},{"slug":34,"category":5,"name":35,"updated_at":31},"block-storage","Блочное хранилище (Block Storage)",{"slug":37,"category":5,"name":38,"updated_at":27},"bring-your-own-cloud","Развёртывание в своём облаке (BYOC)",{"slug":40,"category":5,"name":41,"updated_at":42},"budget-alert","Оповещение о бюджете","2026-09-08T21:32:37+00:00",{"slug":44,"category":5,"name":45,"updated_at":27},"change-freeze","Заморозка изменений",{"slug":47,"category":5,"name":48,"updated_at":27},"control-plane","Управляющий слой и слой данных",{"slug":50,"category":5,"name":51,"updated_at":42},"cost-allocation-tag","Метка распределения затрат",{"slug":53,"category":5,"name":54,"updated_at":42},"cost-chargeback","Внутреннее перевыставление затрат",{"slug":56,"category":5,"name":57,"updated_at":42},"cost-observability","Наблюдаемость затрат",{"slug":18,"category":5,"name":19,"updated_at":31}]