Ньюсмейкер этой недели, Стюарт Рэнс, продолжает делиться своим богатым ИТ-опытом. В этот раз по части такой важной характеристики, как доступность. Недавно Сюарт поучаствовал в дискуссии об ИТ-услугах и о том, как обеспечивать приемлемый уровень их доступности. Хотя поводом и послужил сбой системы авиационно-диспетчерской службы Лондона 12 декабря 2014 г., идеи, вынесенные из обсуждения, применимы для любых систем, а не только для таких критичных, как контроль и управление воздушными перевозками.
Несмотря на то, что сбой продолжался недолго, последствия были огромными. Множество рейсов было отклонено, их невозможно было принять, и самолёты вынужденно садились в других аэропортах. Пассажиры, соответственно, оказывались совсем не там, где планировали быть. Авиалиниям потребовался целый день, чтобы вернуться в нормальный режим работы.
Есть два пути увеличения доступности ИТ-услуги. Первый – уменьшить частоту возникновения сбоев, второй – уменьшить время, требующееся для восстановления из состояния сбоя. Система авиационно-диспетчерской службы – система критически важная. Сбой в её работе недопустим, поскольку это может обернуться трагическими жертвами – самолёты должны контролируемо и управляемо приземляться.
Некоторые коллеги Стюарта говорили о том, что поскольку сбоев быть не должно, систему нужно проектировать так, чтобы вообще исключить потенциальный отказ. Быстрое восстановление здесь не поможет, поскольку сбой-то так или иначе произошёл, и самолёты не могут садиться. На что автор отвечал, что в реальном мире никто не может предусмотреть все потенциальные отказы системы, а значит, уменьшение времени восстановления становится необходимостью. Точка зрения Стюарта была подкреплена и статьёй, опубликованной в издании "The Register". В ней говорится о том, что авиационно-диспетчерская служба может продолжать свою работу в течение 8 минут после того, как доступ диспетчеров к планам полётов воздушных судов прекратился (как раз это и произошло 12 декабря). А по прошествии 8 минут в посадке пилотам самолётов нужно будет отказывать. Таким образом сбой, который был устранён менее, чем за 8 минут, является несущественным, а длящийся всего на несколько минут дольше граничных 8 – весьма заметным по последствиям.
Стюарт отмечает, что он часто видит в SLA аптайм, выраженный в виде процентов доступности ИТ-услуги в рабочее время – например, 99,95%. Проблема в том, что почти невозможно создать решение, которое сможет обеспечить заявленные цифры. Мы можем предсказать частоту сбоев аппаратного обеспечения, но в большинстве своём отказы в ИТ происходят не по вине оборудования, а вызваны комплексным взаимодействием людей, процессов, программного обеспечения, сетей. По этой причине лучшее, что мы можем сделать на тот случай, когда что-то пошло не так – иметь под рукой план восстановления ИТ-услуги для её пользователей. А значит, нужно сфокусироваться на времени восстановления.
Сколько ваших ИТ-услуг были спроектированы с учётом времени восстановления как ключевого ограничения? А насколько вы уверены в том, что можете восстановить предоставление ИТ-услуги в течение времени, приемлемого для заказчика? Достаточно ли хорошо и полно протестированы ваши планы по восстановлению? Если вы не можете ответить положительно на все эти вопросы, то, возможно, настала пора пересмотреть ваш подход к обеспечению требований заказчика к доступности ИТ-услуг.
Я бы не стал противопоставлять два пути повышения доступности: Первый — уменьшить частоту возникновения сбоев, второй — уменьшить время, требующееся для восстановления из состояния сбоя.
Оба должны присутствовать. Но привелденный пример относится, на мой взгляд, больше к другой теме – мажорный инцидент(major incident). Что у ребят случилось – произошел инцидент, который они не смогли в нормативные сроки устранить. В силу серьёзных последствий им необходимо было привлечь бизнес для перехода на ручное правление, без ИТ. А вот плана на Major Incident у них как раз и не было. Все уже забыли как работали диспетчеры до эры ИТ.