Время простоя

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

В то время как плановым простоем можно управлять с целью снижения его влияния на операции, незапланированный простой часто приводит к более серьёзным перебоям, финансовым потерям и требует оперативных действий по реагированию и восстановлению. Для обоих типов простоев необходимы различные стратегии смягчения и управления, чтобы обеспечить минимальное влияние на непрерывность бизнеса^[1].

Отраслевые стандарты для терминов «Продолжительность простоя» или «Продолжительность технического обслуживания» могут иметь разные точки начала и окончания, поэтому во избежание разногласий при выполнении контрактов следует использовать следующие уточнения:

1. «Под ключ» — это самый всеобъемлющий из всех типов простоя. Простой или техническое обслуживание начинается с нажатия оператором установки или оборудования кнопки остановки или выключения для инициирования прекращения работы. Если не указано иное, простой или техническое обслуживание считается завершённым, когда установка или оборудование возвращаются в нормальный режим работы, готовы начать производство, синхронизироваться с системой или сетью.
2. «От выключателя до выключателя» — этот простой или техническое обслуживание начинается с того, что оператор установки или оборудования отключает силовую цепь (главный силовой выключатель переводится в положение «выключено», «отключено» или «охлаждение»), а не цепь управления. Это позволяет оборудованию остыть или достичь температуры окружающей среды, чтобы была возможность подготовить или начать работы по ликвидации простоя/техническому обслуживанию. В зависимости от типа оборудования, простой «от выключателя до выключателя» может быть выгоден при передаче работ по обслуживанию систем управления подрядчикам, поскольку такие работы можно выполнять, пока основное оборудование находится в режиме охлаждения или в режиме ожидания. Если не указано иное, этот тип простоя считается завершённым, когда силовая цепь вновь подаётся под напряжение путём включения силового выключателя.
3. «Завершение процедурой блокировки и опечатывания» — этот простой или техническое обслуживание (иногда ошибочно принимаемый за «выход из режима охлаждения», но не являющийся им) начинается с того, что оператор установки или оборудования отключает силовую цепь, отключает цепь управления и выполняет другие меры нейтрализации потенциальных источников электроэнергии и других потенциальных опасностей — так называемая процедура блокировки и опечатывания (англ. Lock-Out, Tag-Out — LOTO). LOTO — это комплекс мероприятий по блокировке источников опасной энергии, информированию работников и приведению оборудования в состояние, в котором невозможна подача энергии в рабочую зону в момент выполнения работ на оборудовании^[2]. Этот этап технического обслуживания обычно является последней фазой стадии инициации простоя перед началом фактических работ на объекте, установке или оборудовании. После выполнения процедуры LOTO обязательно проводится инструктаж по технике безопасности перед началом любых работ. Если не указано иное, данный тип простоя считается завершённым, когда оборудование достигло механической готовности и готово к переводу на медленный запуск для тяжелого вращающегося оборудования, проведению проверки пуска (Bump-test) или проверки вращения для электродвигателей и т.п., но при этом необходимо соблюдать процедуры возврата или разрешения на работу в соответствии с требованиями LOTO.

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

• Проблемы с аппаратным обеспечением — физические компоненты, такие как серверы, жёсткие диски или сетевые устройства могут выйти из строя, что приводит к простою системы. Возможные причины: износ, производственные дефекты, скачки напряжения или перегрев. Также причинами могут быть факторы окружающей среды — такие условия, как чрезмерная жара, влажность или пыль, могут повлиять на физическую целостность аппаратных компонентов, вызывая отказы и простои. Необходимы надлежащие меры контроля окружающей среды для поддержания оптимальных условий эксплуатации.
• Проблемы с программным обеспечением — ошибки, сбои или несовместимости в программном обеспечении могут привести к сбоям в работе систем. Это включает ошибки операционной системы, сбои приложений или некорректные обновления и патчи.
• Сетевые проблемы — сбои в сетевой инфраструктуре, например в маршрутизаторах, коммутаторах или кабелях могут привести к проблемам с доступам к системам и передаче данных (беспроводные сети, микроволновая связь, спутниковая связь) и/или ограничениями по пропускной способности (системные лимиты). Частыми причинами являются перегрузка сети, ошибки конфигурации или сбои у интернет-провайдера. Системы могут быть перегружены неожиданными всплесками спроса (например, в праздничные дни), что приводит к снижению производительности или сбоям. Масштабирование инфраструктуры и балансировка нагрузки помогают справляться с переменными рабочими нагрузками.
• Человеческий фактор — неправильные конфигурации и настройки, случайное удаление данных или неправильное обслуживание системы могут привести к простою. Обучение и соблюдение лучших практик имеют решающее значение для снижения этого риска.
• Кибератаки — злонамеренные действия, такие как DDoS-атаки, программы-вымогатели или попытки взлома, могут намеренно нарушить работу сервисов и вызвать значительные простои. Надёжные меры безопасности и планы реагирования на инциденты являются необходимой защитой.
• Проблемы с электропитанием — потеря электропитания может привести к полной остановке дата-центров или критически важных систем. Источники бесперебойного питания (ИБП) и резервные генераторы помогают снизить этот риск, но могут не справиться с длительными отключениями.
• Стихийные бедствия — землетрясения, наводнения, ураганы или природные пожары могут физически повредить инфраструктуру и вызвать масштабные простои. Планы восстановления после катастроф и географически распределённые системы важны для обеспечения устойчивости.
• Техническое обслуживание — регулярные работы по обслуживанию, такие как обновления программного обеспечения, модернизация оборудования или перезагрузки систем, требуют плановых простоев для обеспечения безопасности и актуальности систем. Правильное планирование и коммуникация помогают минимизировать нарушения работы^[1].

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

Перебои в работе, вызванные системными сбоями, могут оказать серьезное влияние на пользователей компьютерных/сетевых систем, в особенности в тех отраслях, где требуется практически круглосуточное обслуживание:

• медицинская информатика;
• атомная энергетика и другая инфраструктура;
• банки и другие финансовые учреждения;
• аэронавтика, авиалинии;
• информационные агентства;
• электронная коммерция и обработка транзакций в реальном времени;
• онлайн-игры.

Также пострадать могут пользователи интернет-провайдеров и другие клиенты телекоммуникационных сетей.

Корпорации могут терять доход от бизнеса из-за сбоев в сети или не выполнять условия контрактов, что приводит к финансовым потерям. Согласно отчету Veeam за 2019 год по управлению данными в облаке, организации в среднем сталкиваются с незапланированными простоями от 5 до 10 раз в год, при этом средняя стоимость одного часа простоя составляет 102 450 долларов США.

Влияние времени простоя на пользователей и корпорации зависит от чувствительности к определённым аспектам:

• на некоторых больше влияет длительность сбоя — для них важно, сколько времени потребуется для восстановления после проблемы;
• другие более чувствительны к времени суток, когда происходит отключение — простои в часы пик оказывают на них наибо́льшее влияние.

Самые требовательные пользователи — это те, кто нуждается в высокой доступности.

Примеры крупных сбоев:

• 29 ноября 2024 года российские авиакомпании сообщили о проблемах с оформлением билетов из-за глобального сбоя в системе бронирования Leonardo^[3].
• 14 января 2025 года были зафиксированы сбои на сетях практически всех крупнейших мобильных операторов и провайдеров, маркетплейсы столкнулись с проблемами на пунктах выдачи, а в супермаркетах барахлили кассы. Рунет практически не работал в течение двух часов. Проблемы были связаны с набором расширений протокола DNS — DNSSEC, который гарантирует достоверность данных при обращении к ресурсам — благодаря ему в доменной зоне .ru гарантируется исключение вероятности подмены IP-адреса в результате атак^[4]. В Роскомнадзоре пояснили, что причиной падения интернета стало «кратковременное нарушение связности»^[5].
• 15 января 2025 года из-за повреждения кабеля ПАО «Ростелеком» у 3,8 млн. абонентов в 21 регионе России замедлился интернет. Причина обрыва кабеля — строительные работы в Татарстане. Внутризоновый оптический кабель залегал на глубине около 3 м, с ПАО «Ростелеком» работы были согласованы в близлежащей зоне, но работник пересёк границу разрешённого участка и случилось ЧП^[4].
• 14 июля 2025 года компания Novabev Group, владеющая сетью алкомаркетов «ВинЛаб», сообщила, что сбой в работе её магазинов и сервисов произошел из-за «беспрецедентной кибератаки». Как говорится в заявлении, компания подверглась «масштабной и скоординированной» атаке хакеров, из-за которой была нарушена работа части её IT-инфраструктуры^[6].

• 8 мая 1988 года, в воскресенье, в День матери, в помещении, где стоял главный телефонный коммутатор центрального офиса Хинсдейл компании Bell в Иллинойсе, произошёл пожар. Это была одна из крупнейших коммутационных систем в штате, обслуживавшая более 3,5 миллионов вызовов в день и 38 000 клиентов, включая многочисленные предприятия, больницы, а также аэропорты Чикаго O'Hare и Midway^[7].
• 15 января 1990 года практически вся сеть AT&T из коммутаторов 4ESS для междугородной связи неоднократно выходила из строя и восстанавливалась, нарушая междугороднюю телефонную связь по всей территории США. Проблема исчезла сама собой, когда трафик снизился. Была обнаружена ошибка в программном обеспечении^[8].
• 13 апреля 1998 года компания AT&T зафиксировала сбой на своей сети Frame Relay в течение 26 часов^[9]. Это затронуло тысячи клиентов, в том числе и банковские транзакции. AT&T не выполнила соглашения об уровне обслуживания по своим контрактам с клиентами и была вынуждена вернуть средства^[10] по 6600 счетам клиентов, что обошлось в миллионы долларов.
• В течение новогодних каникул 2007– 2008 годов в работе игрового сервиса Xbox Live наблюдались периодические перебои, которые длились тринадцать дней^[11]. В качестве причины простоев была названа повышенная нагрузка из-за большого количества новых покупателей Xbox 360 — самого большого числа новых регистраций в истории Xbox Live. В качестве компенсации за проблемы с сервисом Microsoft предложила своим пользователям возможность получить бесплатную игру^[12].
• 20 апреля 2011 года был зафиксирован сбой в сети PlayStation Network компании Sony, сбой был постепенно восстановлен только к 15 мая 2011 года. Этот простой стал самым продолжительным с момента запуска PSN в 2006 году. Sony заявила, что причиной проблемы стал взлом, в результате которого были похищены личные данные пользователей. 26 апреля 2011 года Sony сообщила, что большое количество пользовательских данных было похищено в результате той же атаки, которая вызвала простой^[13].
• В конце 2011 года вышел из строя коммутатор компании Telstra в пригороде Сиднея Райде после того, как в электрический щит проникла вода из-за продолжительных дождей. Коммутатор в Райде является одним из крупнейших коммутаторов по площади в Австралии, сбой повлиял на более чем 720 000 услуг.
• 29 февраля 2016 года дата-центр ServerAxis в Майами неожиданно перестал работать, и так и не был восстановлен. Это затронуло нескольких провайдеров и сотни веб-сайтов. Простой повлиял на освещение турнира NCAA Division I по женскому баскетболу 2016 года, так как WBBState, один из пострадавших сайтов, был самым полным источником статистики по женскому баскетболу^[14].
• В октябре 2021 года во время мероприятия Chipotle Mexican Grill на игровой платформе Roblox произошёл сбой. Многие пользователи думали, что причиной сбоя стало именно это событие, поскольку оно вызвало огромный отклик — пользователи могли получить бесплатный буррито от Chipotle. Этот простой стал самым продолжительным в истории Roblox и длился 3 дня^[15][16][17].
• 8 июля 2022 года канадский оператор связи Rogers столкнулся с серьёзным сбоем в работе, затронувшим одновременно более 12 миллионов пользователей кабельного интернета и сотовых сетей. Авария вызвала сбои в работе службы 911, межбанковских транзакций, а также нарушила работу государственных служб^[18].
• 19 июля 2024 года компания CrowdStrike выпустила ошибочное обновление драйвера устройства для своего программного обеспечения Falcon, в результате чего компьютеры под управлением Windows, серверы и виртуальные машины начали аварийно завершать работу и попадать в циклы перезагрузки. Этот инцидент непреднамеренно затронул примерно 8,5 миллионов устройств на Windows по всему миру, включая критическую инфраструктуру, такую как службы 911 в различных штатах. Этот сбой считается крупнейшим в истории информационных технологий (по состоянию на 2025 год)^[19][20].

В соглашениях об уровне обслуживания (SLA) часто указывается процентное значение (за месяц или за год), которое рассчитывается путём деления суммы всех периодов простоя на общее время эталонного периода (например, месяца). 0% простоя означает, что сервер был доступен всё время.

Для интернет-серверов простой выше 1% в год или больше считается неприемлемым, так как это означает простой более 3 дней в году. Для электронной коммерции и других промышленных применений любое значение выше 0,1% обычно считается недопустимым^[21].

• Планирование на этапе проектирования сети. Обязанность сетевого инженера — обеспечить, чтобы сбой в сети не произошёл. Если же сбой всё-таки случается, хорошо спроектированная система дополнительно снижает последствия простоя за счёт локализованных сбоев, которые можно быстро обнаружить и устранить.
• Использование методики обеспечения высокой доступности. Отказоустойчивый кластер, спроектированный в соответствии с методиками обеспечения высокой доступности и гарантирующий минимальное время простоя за счёт аппаратной избыточности. Без кластеризации сбой сервера приводит к тому, что поддерживаемые им приложения или сетевые сервисы оказываются недоступны до восстановления его работоспособности. Отказоустойчивая кластеризация исправляет эту ситуацию, перезапуская приложения на других узлах кластера без вмешательства администратора в случае обнаружения аппаратных или программных сбоев.
• Реализация систем резервирования. Установить резервные серверы, источники питания и дублирующие сетевые пути, чтобы они могли взять на себя работу в случае отказа основных систем. Одной из основных причин простоев является неправильная настройка, когда запланированное изменение проходит с ошибками. Обычно организации полагаются на ручной труд для управления процессом резервного копирования конфигураций, но для этого необходимы высококвалифицированные инженеры, которые смогут контролировать процесс в сети с оборудованием разных производителей. Существуют инструменты автоматизации для управления резервным копированием, однако решений для восстановления конфигурации, необходимого для минимизации общего ущерба от сбоя, крайне мало^[22].
• Мониторинг сети и служба технической поддержки. Должен быть налажен процесс обнаружения неисправностей — мониторинг сети — и восстановления её работоспособности. Обычно это включает команду службы технической поддержки, которая может проводить диагностику и решение проблем, и состоит из компетентных инженеров. Отдельная команда службы поддержки обычно необходима для обработки обращений пользователей, что особенно важно во время простоев.
• Организация автоматизированного мониторинга. Система управления сетью FCAPS может использоваться для обнаружения неисправных или выходящих из строя компонентов до поступления жалоб от клиентов, с возможностью проактивного устранения неисправностей. Для большинства веб-сайтов доступен мониторинг. Мониторинг веб-сайтов (синтетический или пассивный) — это сервис, который отслеживает время простоя и количество пользователей на сайте.
• Использование метода управления рисками. Методы управления рисками могут использоваться для определения влияния сбоев в сети на организацию и определения необходимых действий по минимизации риска. Риск можно снизить за счёт использования надёжных компонентов, проведения технического обслуживания, такого как обновления, применения резервных систем, а также наличия плана действий в чрезвычайных ситуациях или плана обеспечения непрерывности бизнеса. Технические средства позволяют уменьшить количество ошибок, используя коды коррекции ошибок, повторную передачу данных, контроль ошибок или схемы разнесения.
• Регулярное создание резервных копий данных. Использовать автоматические решения для обеспечения согласованности и снижения риска ошибок сотрудников.
• Профилактическое обслуживание оборудования. Устанавливать график замены оборудования на основе рекомендаций производителя и исторических данных о его работе.
• Планирование технического обслуживания. Планировать работы в непиковые часы, заранее сообщать о графике и использовать инструменты автоматизации для оптимизации задач.

Плановый простой — это результат запланированного действия со стороны владельца системы и/или поставщика услуг. Такие простои, часто запланированные на окно технического обслуживания (период времени, заранее назначенный техническим персоналом, в течение которого может выполняться профилактическое обслуживание, которое может привести к нарушению обслуживания), могут использоваться для выполнения следующих задач:

• отложенное техническое обслуживание, например, отложенный ремонт оборудования или отложенная перезагрузка для очистки повреждённой памяти;
• диагностика для локализации обнаруженной неисправности;
• ремонт неисправностей аппаратного обеспечения;
• исправление ошибки в базе конфигураций или в недавнем изменении базы конфигураций;
• исправление ошибки в базе данных приложения или в недавнем изменении базы данных приложения;
• установка патчей/обновлений программного обеспечения для устранения программной ошибки.

Простои также могут быть запланированы в результате предсказуемого природного явления, такого как солнечное затмение.

В отраслях, где используются компьютерные системы, необходимо тщательно планировать время планового простоя для технического обслуживания. Во многих случаях можно избежать простоя всей системы с помощью так называемого «последовательного обновления» — процесса постепенного отключения частей системы для обновления без ущерба для общей функциональности.

Существует множество внешних сервисов, которые можно использовать для мониторинга времени работы и простоев, а также доступности сервиса или хоста.

В России учёт крупных сбоев ведётся на сайте DownDetector.su, однако, как указано на информационной странице: сайт не делает самостоятельных выводов о наличии сбоев, а лишь собирает и анализирует публичную информацию — жалобы пользователей и сетевую телеметрию. Информация, размещённая на DownDetector.su, не является официальным подтверждением неисправности (дефекта, повреждения, отказа, сбоя)^[23]. Также можно увидеть статистику сбоев на сайте Сбой.рф^[24], без какой-либо аналитики причин и комментариев.

В мировом масштабе наиболее популярным является Downdetector.com — онлайн-сайт, принадлежащий компании Ookla, который отслеживает регулярные простои и крупные сбои на основе отчётов пользователей, размещаемых на сайте. Кроме того, Downdetector содержит отдельную страницу для каждого веб-сайта, а также интегрирован с Twitter^[25]. Сервис доступен в 45 странах (с отдельным сайтом для каждой страны) и отслеживает 12 000 сервисов по всему миру^[26][27].

Термином противоположным даунтайму/времени простоя является аптайм (англ. uptime) — время непрерывной работы вычислительной системы или её части.

Помимо прямого смысла (время непрерывной работы), термин «аптайм» иногда описывает среднее время работы системы и измеряется в процентах от общего времени измерения. 99 % аптайма соответствует примерно 15-минутному времени простоя/даунтайму в день (8 часов в месяц), 99,9 % — 50 минутам в месяц, 99,99 % — 50 минутам в год (4 минутам в месяц).