[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-maintenance-window::ru":3,"gloss-cluster-maintenance-window::ru":23,"gloss-next-maintenance-window::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"maintenance-window","cloud","Окно обслуживания","Окно обслуживания — это заранее согласованный промежуток, в течение которого сервис может быть недоступен ради плановой работы: обновления, переезда, замены оборудования, изменения схемы, которое нельзя сделать на ходу. Смысл того, чтобы дать этому имя, в том, что перерыв перестаёт быть инцидентом. Клиентов предупредили, у работы есть владелец и план отката, а часы были выбраны, а не получились сами собой. Два свойства окна важнее его длины. Первое — кому оно принадлежит. Окно провайдера — это право, которое он оставил за собой в договоре, и оно вполне может приходиться на ваши самые загруженные часы, потому что его загруженные часы находятся в другом месте; если это существенно, договариваться надо до подписания, а не терпеть сюрприз потом. Второе — исключены ли эти часы из обязательств по доступности. Плановое обслуживание очень часто вынесено за скобки обещания, а значит сервис может быть для вас недоступен совершенно законно, и цифра на странице при этом не сдвинется. Это не уловка, но повод читать список исключений, а не заголовок. Практика деградирует предсказуемо. Окна, которыми не пользуются, перестают появляться в расписании; окна, в которые складывают всё подряд, становятся единственным временем, когда вообще что-то выкатывается, и оттого каждое делается крупным и рискованным; а глобальный продукт рано или поздно обнаруживает, что часа, тихого повсюду, не существует, и окно превращается в выбор, какие клиенты примут перерыв на себя. Честный ответ — уменьшать объём работ, вообще требующих окна, то есть делать больше, не роняя сервис, и держать оставшиеся окна короткими, частыми и объявленными настолько заранее, чтобы клиент мог их запланировать, а не отреагировать на них. Стоит вести список не только окон, которые объявляете вы, но и тех, что оставили за собой ваши поставщики: зависимость, берущая своё окно в тот же час, что и вы, превращает две рутинные работы в один незапланированный простой.","Окно обслуживания превращает плановый перерыв в объявленное событие. Кому оно принадлежит и почему обещания доступности его исключают.",null,[11,14,17,20],{"slug":12,"name":13},"blue-green-deployment","Blue-Green Deployment (сине-зелёное развёртывание)",{"slug":15,"name":16},"runbook","Ранбук",{"slug":18,"name":19},"sla","Соглашение об уровне обслуживания (SLA)",{"slug":21,"name":22},"status-page","Страница статуса",[24,28,32,35,38,41,45,48,51,54,57,60],{"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":33,"category":5,"name":34,"updated_at":31},"availability-zone","Зона доступности (Availability Zone)",{"slug":36,"category":5,"name":37,"updated_at":31},"block-storage","Блочное хранилище (Block Storage)",{"slug":39,"category":5,"name":40,"updated_at":27},"bring-your-own-cloud","Развёртывание в своём облаке (BYOC)",{"slug":42,"category":5,"name":43,"updated_at":44},"budget-alert","Оповещение о бюджете","2026-09-08T21:32:37+00:00",{"slug":46,"category":5,"name":47,"updated_at":27},"change-freeze","Заморозка изменений",{"slug":49,"category":5,"name":50,"updated_at":27},"control-plane","Управляющий слой и слой данных",{"slug":52,"category":5,"name":53,"updated_at":44},"cost-allocation-tag","Метка распределения затрат",{"slug":55,"category":5,"name":56,"updated_at":44},"cost-chargeback","Внутреннее перевыставление затрат",{"slug":58,"category":5,"name":59,"updated_at":44},"cost-observability","Наблюдаемость затрат",{"slug":61,"category":5,"name":62,"updated_at":31},"disaster-recovery","Аварийное восстановление"]