10 января 2008 года в пол-четвертого ночи наш системный администратор Майкл Горсач (Michael Gorsuch) проснулся у себя дома в Бруклине от резкого звука. Это программа Nagios, контролирующая нашу сеть, прислала текстовое сообщение о возникшей неисправности.

Он встал с постели, наступив на собаку (чем ее разбудил), та в сердцах сделала лужу в коридоре и вернулась на лежанку. Майкл же, сев за компьютер в соседней комнате, обнаружил, что один из трех наших центров обработки данных, в центре Манхэттена, недоступен из Интернета.

Этот центр расположен в охраняемом здании в центре Манхэттена, специальным оборудованием управляет интернет-провайдер PEER 1. Там есть резервные генераторы с запасом дизельного топлива на несколько дней и многочисленные аккумуляторы для питания всего оборудования в течение нескольких минут, пока запускаются генераторы. Там есть мощные воздушные кондиционеры, многократно дублирующиеся высокоскоростные соединения с Интернетом и «правильные» инженеры-практики из тех, кто все делает с чувством, с толком, с расстановкой, без модного экстрима, — словом, все очень надежно.

Такие интернет-провайдеры, как PEER 1, обычно гарантируют безотказную работу на условиях SLA (Service Level Agreement — соглашение об уровне обслуживания). В типичном SLA может быть указано, к примеру, что время безотказной работы составляет 99,99%. Арифметика говорит, что в году 525 949 минут (или 525 600, как считают в мюзикле «Rent»), зна-

чит допустимый простой за год — 52,59 минуты. При большем простое SLA обычно предусматривает какие-то штрафные санкции, по правде говоря, смешные — например, возврат денег за те минуты, когда оборудование было неисправно. Однажды за двухдневное отключение, стоившее нам тысяч долларов, мы получили от провайдера T1 скидку порядка 10 долларов. В этом отношении SLA довольно бессмысленны, и с учетом незначительности штрафных санкций многие провайдеры сетевых услуг стали рекламировать 100% времени безотказной работы.

Через 10 минут все заработало, и Майкл снова лег.

Примерно до 5:00. На этот раз Майкл позвонил в центр управления сетями PEER 1 (Network Operations Center, NOC) в Ванкувере. Они что-то протестировали, провели расследование, не выявив никаких неисправностей, и к 5:30 ситуация вроде бы нормализовалась, но Майкл уже дрожал, как дикобраз среди воздушных шариков.

В 6:15 сайт в Нью-Йорке потерял связь с внешним миром. В PEER 1 не обнаружили никаких своих неисправностей. Майкл оделся, сел в метро и поехал на Манхэттен. Сервер работал. Соединение с сетью PEER 1 было нормальным. Проблема, видимо, заключалась в сетевом коммутаторе. Майкл отключил коммутатор, подключил наш роутер прямо к роутеру PEER 1 — и мы снова были в Интернете.

К утру, когда большинство наших американских клиентов пришли на работу, все было прекрасно. По электронной почте начали поступать жалобы от наших европейских клиентов. Проведя расследование, Майкл выяснил, что проблема возникла из-за особенностей настройки коммутатора. Этот коммутатор может работать на разных скоростях (10, 100 или 1000 мегабит в секунду). Можно задать скорость вручную либо позволить устройству автоматически установить самую высокую скорость, допустимую для нормальной работы двух связанных устройств. В отказавшем коммутаторе была задана автоматическая настройка. Она работает, но не всегда, и 10 января она не сработала.

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

Майкл расстроился. Он прислал мне электронное письмо:

Отличная мысль!

Но с SLA связаны некоторые проблемы. Главное — нет осмысленной статистики, потому что отказов очень мало. Насколько я помню, с тех пор как полгода назад мы стали предоставлять хостинг FogBugz On Demand, было всего два незапланированных отключения, считая данное. Одно из них произошло по нашей вине. У большинства надежных сетевых сервисов бывает два, самое большее три отказа за год. Когда случаев отказа так мало, большое значение приобретает их продолжительность, а она может очень сильно варьировать. Внезапно все упирается в то, как скоро кто-то доберется до оборудования, чтобы устранить неисправность. Действительно высокий уровень бесперебойной работы не должен зависеть от того, кто заменяет неисправную деталь. Нельзя даже ждать, пока он определит, что сломалось: нужно заранее выявить все, что может выйти из строя, а это практически невозможно. Опасны неожиданные неожиданности, а не те, к которым вы подготовились.

Обеспечение действительно высокого коэффициента надежности обходится очень дорого. Пресловутые «шесть девяток» (99,9999% готовности к работе) соответствуют тридцати секундам простоя в год. Это просто смешно. Даже тот, кто заявляет, что построил какую-то ультрадорогую сверхизбыточную суперпуперсистему с шестью девятками, проснется в один прекрасный день — не знаю, когда, но он наступит непременно, -и обнаружит, что произошло нечто совершенно непредвиденное — ну, там, три электромагнитные бомбы, по одной в каждый центр обработки данных, — и хоть всю голову сломай, но две недели ничего работать не будет.

Думать надо вот о чем: если ваша система с шестью девятками по каким-то таинственным причинам хоть раз выйдет из строя, то даже выяснив и устранив причину за час, вы исчерпаете свой бюджет допустимых отказов на целое столетие вперед. Даже у таких известных своей надежностью систем, как служба междугородней связи AT&T, случается длительный перебой в работе (6 часов в 1991 году), понижающий их уровень до малопочтенных трех девяток, а ведь междугородняя связь AT&T считается службой связи высшего класса, золотым стандартом надежности.

Для непрерывного обслуживания через Интернет характерна проблема черного лебедя. Нассим Тадлеб (Nassim Taleb), придумавший этот термин, определяет его так (www.edge.org/3rd_culture/taleb04/taleb_indexx.html): «Черный лебедь — это выброс, событие вне области обычных ожиданий». Почти все перебои в работе Интернета являются неожиданными неожиданностями — крайне маловероятными событиями за гранью ожидаемого. Такие вещи случаются настолько редко, что пользоваться обычными статистическими представлениями вроде «среднего времени между отказами» бессмысленно. Какое может быть «среднее время между катастрофическими наводнениями в Новом Орлеане»?

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

Где-то посреди между «крайне ненадежным» уровнем обслуживания, когда постоянно возникают дурацкие перебои, и «крайне надежным», когда миллионы вкладываются в то, чтобы рабочее время увеличилось всего на минуту за целый год, есть наилучшая область, в которой приняты меры против всех ожидаемых неожиданностей. Отказ одного жесткого диска допускается и не выводит вас из строя. Отказ одного сервера DNS допускается и не выводит вас из строя. Но неожиданные неожиданности могут привести к сбою. Это лучшее, на что можно рассчитывать.

Чтобы попасть в это милое место, мы воспользовались идеей Сакичи Тойода (Sakichi Toyoda), основателя компании Toyota. Он называет ее «пять почему». Когда что-то выходит из строя, снова и снова спрашивайте — почему, пока не выясните главную причину. Тогда вы сможете устранить эту причину, а не ее симптомы.

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

Мы потеряли соединение с PEER 1 NY.

Почему? — Видимо, наш коммутатор перевел порт в нерабочее состояние.

Почему? — После обсуждения с NOC PEER 1 мы пришли к предположению, что это могло быть вызвано несоответствием скорости/дуп-лекса Ethernet.

Почему? — В интерфейсе коммутатора был задан автоматический выбор скорости вместо ручной настройки.

Почему? — Мы знали о возможности подобной проблемы и прежде. Но у нас нет письменных стандартов и процедур проверки конфигурации промышленных коммутаторов.

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

«Если бы мы сначала написали стандарт, а потом установили коммутатор и проверяли свою работу на соответствие стандарту, этого перебоя не было бы, — писал Майкл. — Или, случись он однажды, в стандарт были бы внесены соответствующие изменения».

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

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

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

P S. Кстати, мы хотим взять еще одного системного администратора, чтобы будить посреди ночи не только Майкла.