Локальную сеть госпиталя Beth Israel Deaconess лихорадило в течение четырех дней. Сотрудники госпиталя были вынуждены временно вернуться к "бумажной" системе ведения медицинской документации.

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

— Джон Халамка, руководитель информационной службы медицинского центра CareGroup

Джон Халамка — один из когорты блестящих специалистов, которые стоят во главе ИТ-подразделений известных на весь мир медицинских центров Бостона. С 1998 года он руководит информационной службой престижного медицинского центра CareGroup и его базового госпиталя — Beth Israel Deaconess Medical Center. Наряду с этим Халамка активно участвует в формировании стратегии Massachusetts Health Data Consortium, консорциума, который определяет правила обработки информации для медицинских учреждений штатов Новой Англии.

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

Неудивительно, что в профессиональных кругах Халамка широко известен. Два года подряд еженедельник InformationWeek в своих рейтингах ИТ-подразделений присуждал коллективу Халамки первое место по категории больниц. В сентябре 2002 года в списке InformationWeek, включающем 500 организаций, CareGroup досталась 16-я позиция.

А в ноябре в госпитале Beth Israel Deaconess произошел катастрофический сбой — один из самых серьезных по меркам ИТ-служб медицинских учреждений. В течение четырех дней находящаяся в ведении Халамки сеть неоднократно выходила из строя, а сотрудники госпиталя были вынуждены вернуться к «бумажной» системе ведения медицинской документации, от которой они отказались много лет назад. Если раньше результаты анализов попадали в руки врачей в течение 45 минут, то теперь на их обработку уходило до 5 часов. Впоследствии сеть госпиталя пришлось полностью реконструировать.

Кризис разразился как раз в то время, когда сфера деятельности ИТ-подразделения начала распространяться на лечение стационарных больных. До недавнего времени на директоров информационных служб возлагались лишь заботы по обслуживанию вспомогательных систем, обеспечивающих начисление заработной платы и страховых выплат. Но в последнее время стараниями Халамки и его коллег в современных больницах утвердились такие методы работы, как компьютеризованное оформление рецептов, ведение истории болезни и представление результатов лабораторных анализов в электронном виде и даже Internet-конференции о предстоящих хирургических операциях. Новые возможности составляли предмет гордости ИТ-директоров медицинских учреждений. Сеть, которая обеспечивала все упомянутые возможности, воспринималась при этом как нечто само собой разумеющееся.

«Сеть — это альфа и омега, — уверен сегодня Халамка. — Тот, кто не имеет в своем распоряжении современных сетевых решений, в один прекрасный день потерпит крах».

До 13 ноября 2002 года сам Халамка не знал, что это такое — остаться без сети. Теперь, когда испытания уже позади, он считает своим моральным долгом поделиться полученным опытом с другими.

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

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

СРЕДА

Сеть «повисла»

Среда 13 ноября 2002 года выдалась туманной и дождливой. Халамка работал в своем кабинете в госпитале Beth Israel. Он обратил внимание на то, что сеть заметно «подтормаживает»: на выполнение таких операций, как отправка и получение электронной почты, уходило от пяти до десяти секунд. Примерно в 13 часов 45 минут он отправился к сетевым администраторам, чтобы выяснить, в чем дело.

Некоторые из 250 сотрудников ИТ-службы уже обратили внимание на эту странность в поведении сети. Но они полагали, что причин для беспокойства нет: просто наблюдается внезапный всплеск в интенсивности трафика. На один из базовых сетевых коммутаторов обрушилась лавина пакетов. Откуда — никто не знал. Возможно, все дело в том, что с коммутатором работал сотрудник консалтинговой фирмы; он готовил проект корректировки параметров сети.

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

По словам Раша, в предшествующих случаях броски продолжались от 15 минут до двух часов, а потом они проходили сами по себе.

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

Но это была ошибка.

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

Трафик застопорился. Сеть вышла из строя.

По прошествии менее чем 15 минут, в 14 часов, администраторы решили отказаться от своей затеи и вновь включили коммутаторы. Они полагали, что «тормозящая» сеть все-таки лучше, чем сеть зависшая.

На протяжении всего остатка дня и последующей ночи сеть работала в режиме «вывешенного полотнища» (так Халамка описывает состояние «летаргии», перемежаемое моментами нормального функционирования и — что бывало чаще — полными провалами). Специалисты продолжали поиски неисправности. Примерно в 18 часов, когда многие врачи, медсестры, сотрудники и студенты уже разошлись по домам, сеть вернулась в нормальное состояние. Наконец, в 21 час удалось обнаружить «виновника» сбоя; им оказался цикл Spanning Tree Protocol.

Протокол STP выполняет практически те же функции, что и регулировщик дорожного движения. Данные поступают на коммутатор и обращаются с вопросом: «А теперь куда?». STP рассчитывает кратчайший маршрут. Затем он блокирует все другие возможные маршруты, чтобы данные отправлялись прямо к месту назначения и на последующих перекрестках не нужно было принимать решения, по какой дороге двигаться дальше.

Но все дело в том, что STP выполняет расчеты на глубину лишь семи пересечений. Если на пути данных возникает еще один — восьмой «перекресток», они могут сбиться с дороги. Иногда в таких случаях данные начинают носиться по кругу. Трафик в сети затрудняется. Во-первых, каналы связи засоряются теми данными, которые передаются по кругу. Во-вторых, вычислительная мощность других коммутаторов расходуется теперь не на регулирование собственного трафика, а на пересчет маршрутов; ведь им приходится принимать на себя ношу того коммутатора, который «гоняет» данные по кругу.

И вот что случилось. В среду кто-то из научных работников госпиталя Beth Israel Deaconess загрузил в одну из программ для совместной работы с медицинскими файлами некоторые данные, и они «пошли по кругу». Их объем составлял несколько гигабайт, поэтому каналы связи были заблокированы. Затем, когда сотрудники Халамки отключили коммутатор, возникла ситуация, аналогичная ЧП на дороге: один полицейский заблокировал движение на перекрестке, а все остальные регулировщики закрыли движение по всем направлениям, чтобы рассчитать обходные маршруты движения.

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

«Мы отключили избыточные соединения, — вспоминает Халамка. — И все вроде бы получилось. Разошлись по домам в отличном настроении. Задача, казалось, была решена».

ЧЕТВЕРГ

Закупорка артерий

Больницы пробуждаются рано. К 7 утра врачи и медсестры начали отправлять первые сообщения электронной почты (за день в Beth Israel Deaconess их набирается до 100 тыс.). Фармацевты приступили к заполнению рецептов — по сети побежали первые биты данных (к вечеру общий объем трафика составляет порядка 40 Тбайт). Начали поступать результаты лабораторных анализов (ежедневно их выполняется до 3 тыс.).

Примерно в 18 часов, когда многие врачи, медсестры, сотрудники и студенты уже разошлись по домам, сеть вернулась в нормальное состояние. Наконец, в 21 час удалось обнаружить «виновника» сбоя; им оказался цикл Spanning Tree Protocol

К 8 утра сеть опять начала вести себя так, будто трафику приходилось преодолевать сильный встречный ветер. Халамка понял, что накануне вечером сеть функционировала нормально лишь потому, что в это время в ней практически никто не работал. С началом дня был отмечен всплеск активности. Сеть перешла в режим «полотнища на слабом ветру». Значит, проблема так и не была снята.

Сотрудники Халамки лихорадочно искали подлинный источник проблем. Согласно одной из рассматриваемых гипотез, это могли быть сети отдельных больниц CareGroup в различных населенных пунктах штата Массачусетс. Они функционировали как обособленные сети, подключаемые к сети Beth Israel Deaconess. По словам Джин Клоу, возглавляющей расположенную в городе Кембридж больницу Mount Auburn Hospital, которая служит центральным звеном вычислительной сети отдельно расположенных больниц, сеть местных больниц не отличалась высоким быстродействием, а учетная система в ней и вовсе не работала.

Проще всего было бы продолжить отключение линий связи, устраняя тем самым потенциальную возможность формирования циклов STP. Ho это привело бы к изоляции отдельно расположенных больниц. Поэтому сотрудникам ИТ-службы, работавшим в контакте с инженерами компании Callisma, пришлось избрать более сложное решение. Они попытались заменить коммутаторы, соединяющие базовую сеть с сетью отдельно расположенных больниц, на маршрутизаторы. Это должно было позволить устранить проблемы, связанные с STP, не разрывая контакта с этими больницами.

Работы продолжались семь часов. По непонятным причинам, каким-то образом касающимся протокола VLAN Trunking Protocol, маршрутизаторы так и не заработали. Сеть оставалась в подвешенном состоянии на протяжении всего дня.

Дело шло к обеду. В то время когда Халамка разъяснял собравшимся на специальном совещании руководителям CareGroup идею использования маршрутизаторов, в реанимационное отделение Beth Israel Deaconess поступила пациентка 50 с лишним лет, страдающая от алкоголизма. Ее осмотрел доктор Дэниел Сэндс, врач приемного покоя, возглавляющий к тому же группу внедрения компьютерных технологий для лечения стационарных больных. У пациентки наблюдался, выражаясь словами Сэндса, «дефицит электролита» — типичная проблема больных, которым алкоголь заменяет пищу.

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

В 16 часов Халамка встретился с членами кризисного штаба, куда входила главная медсестра госпиталя, руководители лаборатории и аптеки, а также директор административной службы госпиталя доктор Майкл Эпстайн.

«Даже на этом этапе, — рассказывает Халамка, — я твердил: ?Нам остается только чуть изменить конфигурацию? и был уверен, что очень скоро все будет в порядке». Но мои сотрудники выглядели хмуро и вообще были на грани срыва. Телефоны справочной службы CareGroup разрывались от звонков. Вопросы были самые разные. Один из абонентов не мог проверить электронную почту, другой хотел узнать, прошел ли его запрос на получение результатов анализа крови.

В 15:50 в госпитале Beth Israel была закрыта палата интенсивной терапии. Согласно документам Департамента здравоохранения штата Массачусетс, ее не открывали в течение четырех часов, до 19:50.

По словам Эпстайна, на совещании, состоявшемся в 16 часов, он осознал, что «речь идет не о заурядной сети, которую можно отключать без особых последствий». Сэндс и другие сотрудники клиники во весь голос говорили о своей озабоченности. Эпстайн и Халамка решили прибегнуть к крайним мерам. Они обратились за помощью к компании Cisco Systems, которая поставляет госпиталю сетевое оборудование и обеспечивает его техническую поддержку. В ответ на обращение представители Cisco задействовали свою программу страхования клиентов САР (Customer Assurance Program), маловыразительное название которой не дает представления о том, сколь редко применяются и сколь серьезные мероприятия включают в себя эти программы. Реализация программы означает, что Cisco выделяет любую необходимую сумму финансовых средств и привлекает все имеющиеся ресурсы на протяжении того времени, пока не будет разрешен кризис.

О начале реализации САР было объявлено после 16 часов. К 18 часам местная бригада САР из расположенного неподалеку города Келмсфорд (штат Массачусетс) развернула в госпитале командный центр и организовала поддержку по принципу «вслед за солнцем». Это означает, что к выполнению антикризисных мероприятий подключаются дополнительные сотрудники из центров технической поддержки Cisco, a когда рабочий день в этих центрах заканчивается, соответствующие функции передаются аналогичной группе сотрудников центров, которые расположены в других часовых поясах.

Первым делом антикризисная команда Cisco решила немедленно приступить к проверке сети с целью обнаружения цикла STP. Для этого специалистам нужно было проверить 25 тыс. портов в сети. Обычно эта процедура выполняется с помощью адресуемых портам запросов. Но в данном случае сеть настолько вяло реагировала на внешние воздействия, что запросы попросту не проходили.

Инженеры Cisco решили устанавливать связь с главными коммутаторами при помощи модемов, чтобы хоть как-то выйти из положения. Все бросились на поиски этих устройств, и в конце концов в одном из шкафов в куче всякого хлама было обнаружено несколько старых моделей 28-килобитных модемов US Robotics. Их спешно подключили к телефонной сети. Программа САР вступила в этап поисков причин кризиса.

К 21 часу тот самый цикл STP — причина всех проблем — был идентифицирован. Как оказалось, предназначенная для организации совместной работы над требующими высокоскоростных каналов связи графическими файлами и другой клинической информацией сеть PACS (Picture Archive Communication System) находилась на расстоянии 10 «пролетов» от ближайшего базового коммутатора, что превосходит возможности STP.

Именно в этот момент сотрудники антикризисной команды осознали всю масштабность проблемы: сеть, с которой они работали, сильно устарела. Еще в сентябре 2002 года Халамка поручил Рашу проверить инфраструктуру сетевого хозяйства CareGroup. Закончив работу, Раш сказал Халамке: «Ваша сеть создана по последнему слову техники — но по состоянию на 1996 год».

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

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

— Дэниел Сэндс, врач приемного покоя

В 1996 году зона действия сети CareGroup ограничивалась больницей Beth Israel, и сеть эта была создана на базе коммутатора Libby030. B октябре того же года больница объединилась с госпиталем Deaconess. Вычислительная сеть Deaconess была подключена к коммутатору Libby030.

Подобным же образом «нанизывались» на существующую структуру и другие системы. В 1998 году CareGroup подключила сеть PACS k сети бывшего госпиталя Deaconess. Годом позже к Libby030 были подключены новый вычислительный центр и два его основных коммутатора. Позднее появился четвертый базовый коммутатор и целый клубок резервных линий связи, но в конечном итоге все пути вели к Libby030. Теперь Халамка понимает, что вся инфраструктура была «сетью удлинителей, соединяющих другие удлинители». Система была чрезвычайно хрупкой.

Эксперты группы САР решили установить маршрутизатор Cisco 6509 между базовой сетью и сетью PACS. Teм самым снималась необходимость в использовании STP (6509 обладает и функциями коммутации, поэтому было решено отключить три коммутатора внутри сети PACS и передать их функции тому же маршрутизатору 6509).

В 21 час с минутами Boeing 747 c маршрутизатором Cisco 6509 на борту поднялся в воздух в международном аэропорту Минета близ города Сан-Хосе и взял курс на международный аэропорт Логан под Бостоном.

За ночь местная группа инженеров Cisco переоборудовала сеть PACS. Халамка рассказывает об этом с некоторым благоговением: в свое время на создание этой сети ушло целых полгода.

ПЯТНИЦА

Обратно к бумагам

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

К 8 утра сеть опять «повисла».

В 10 часов Халамка с Эпстайном решили выключить сеть и ввести в госпитале «бумажный» документооборот. Как оказалось, это решение вызвало всеобщее облегчение.

«Нам нужно было как-то снять стресс», — рассказывает Эпстайн.

Любопытно, что после отключения сети у Сэндса и других сотрудников клиники тоже полегчало на душе. Некоторые из них и так уже перестали работать с компьютерами, но испытывали при этом чувство вины. «А когда объявили, что сеть отключена, для нас это было как отпущение грехов», — вспоминает Сэндс.

Но для того чтобы погрузиться в бумажную стихию, нужно прежде всего найти бумагу — бланки для рецептов и запросов в лаборатории. Их давно уже сложили в каком-то дальнем углу и благополучно забыли о них, а многим молодым сотрудникам никогда не доводилось работать с бумажными формулярами. В пятницу их учили выписывать рецепты. В этот день Сэндс выписал рецепт ручкой впервые за 10 лет работы в CareGroup. Вот как он вспоминает об этом: «Когда я выполняю подобную операцию на компьютере, он справляется в базе данных, не грозит ли прописанное средство аллергическими осложнениями, и следит за тем, чтобы я не ошибся при указании дозы и частоты приема лекарства. Кроме того, компьютер распечатывает справочные материалы для пациента. Теперь я был с пациентом один на один. Помню, по спине у меня пробежал холодок. Я заставил себя писать медленно и разборчиво».

В полдень к своим сотрудникам присоединился Эпстайн — и будто бы оказался в далеком 1978 году. Он занялся копированием бланков. Затем Эпстайн рассортировал солидную — высотой почти в 10 см — стопку бланков для микробиологических анализов и раздал их курьерам, а курьеры разнесли эти бумаги по палатам, где оставили их для докторов. (В госпитале в это время было около 450 пациентов.)

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

«Мы зависим от сети и в то же время как бы не замечаем ее, — рассказывает Сэндс. — Именно благодаря Халамке мы и знать не знали о том, что компьютеры могут выходить из строя, и предъявляли к системам все более серьезные требования. А потом произошла катастрофа. И тогда мы схватились за голову и застонали: ?Господи, что же делать??»

Халамка превратился в своего рода агента для всех, кому требовались какие-то данные. Он стал как бы осью колеса, спицы которого соединяли его со всеми — с командой САР, с администраторами госпиталя, с клиницистами и с отдельно расположенными больницами. В эти дни Халамке очень пригодилась подготовка, полученная им в реанимационном отделении медицинского центра при Калифорнийском университете в Лос-Анджелесе. В этом центре он работал в 90-е годы, когда уличные банды регулярно устраивали в городе свои кровавые разборки. С той поры Халамка усвоил первое правило работы в кризисных ситуациях: всегда оставайся спокойным и проявляй дружелюбие к людям.

Халамка вспоминает: «Скажу честно, это были 48 часов сплошной нервотрепки. Мы ни секунды не спали, а сеть по-прежнему не выходила из летаргического сна. Я, конечно, бодрился, но мне было ясно: что-то нужно предпринимать. В конце концов, все мы люди, и я чувствовал, что мы приближаемся к пределу человеческих возможностей. Человеку нужен сон, перезарядка. Необходимо было переходить на сменный график работы, иначе наши специалисты могли впасть в отчаяние».

Вдруг он поймал себя на том, что углубился в проблемы логистики, чего раньше с ним никогда не случалось. Где раздобыть койки для авральной команды из 100 человек? Как организовать их питание? Готовых решений не было, и ему приходилось действовать по наитию.

«Узнать, какие детали упущены в плане мероприятий по восстановлению после катастрофического сбоя можно лишь после того, как беда уже случилась», — утверждает Халамка. Формальный, «бумажный» план восстановления у него был, однако в сущности он оказался чем-то вроде плана по устранению злосчастной «ошибки 2000 года». Да, в нем указывались мероприятия по восстановлению сети CareGroup, но во всем остальном план не имел отношения к тому типу отказов, с которым столкнулись сотрудники госпиталя.

Обычно главным звеном плана по восстановлению после сбоя являются меры по восстановлению утраченных данных; возможно — по восстановлению резервных копий утраченных данных или, наконец, по восстановлению целостности данных. В Beth Israel Deaconess c данными ничего не произошло, просто к ним не было доступа.

И тут Халамка сформулировал главный урок, который он извлек из этой истории: к сети нельзя относиться как к вспомогательной службе. «Все мое внимание было поглощено вычислительным центром — и дополнительными накопителями для хранения данных. После событий 11 сентября 2001 года я сосредоточился на решении проблем резервного копирования и обеспечении бесперебойной работы системы. Каналы связи оставались вне нашего поля зрения».

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

С оценкой Раша согласны и другие специалисты. «На мой взгляд, главная опасность в том, что люди начинают думать: наверное, все ИТ-обеспечение здравоохранения несовершенно, и вот-вот грядет новая катастрофа, — делится своими мыслями директор информационной службы другой больницы. — Это неверное представление. Мы все внимательно следили за героическими усилиями по восстановлению сети CareGroup, но это не значит, будто мы только и делаем, что сокрушаемся в связи с тем, что нечто подобное может произойти и в наших сетях. Проблема нам известна. Несколько лет назад, осознав опасность, мы содрогнулись и позаботились о том, чтобы перейти на новую архитектуру».

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

СУББОТА

Надежда умирает последней

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

Разумеется, никто не мог гарантировать, что бедному коммутатору Libby030 и другим устройствам удастся справиться с дополнительной нагрузкой после такой операции. Для страховки руководители авральной бригады решили создать дополнительное ядро сети со средствами маршрутизации, которое поможет компьютерному хозяйству CareGroup шагнуть из 1996-го в 2002 год.

В 8 часов из Сан-Хосе прибыли еще два маршрутизатора Cisco 6509. B 5 часов в бостонском аэропорту приземлился самолет, на котором прибыли три инженера Cisco. Весь день они посвятили созданию дополнительного ядра сети.

В то утро во время обхода больных Сэндс чувствовал себя не в своей тарелке. «Пациенты считают, что доктор должен знать истории их болезней, — рассказывает он. — Но когда у меня перед глазами нет предоставляемой компьютером сводки, мне приходится подходить к пациенту, которого я уже вел, и задавать такие нелепые для лечащего врача вопросы, как, скажем: ?А у вас есть к чему-нибудь аллергия?? Иногда я знал ответы на эти вопросы, но не решался довериться своей памяти. Создавалось неловкое положение, и мне было просто не по себе».

Работы по восстановлению сети продвигались медленно. Никто не хотел брать на себя ответственность и заявлять, что недавно принятое решение — создавать дополнительное ядро сети и отключать избыточные линии связи — наверняка позволит устранить проблему. В 9 утра состоялась встреча Халамки с администрацией CareGroup, в том числе с руководителем центра Полом Леви. ИТ-директор информационной службы был вынужден сообщить собравшимся: «Сказать, в какие сроки мы поднимем сеть, я не могу».

Вообще-то признавать свою беспомощность — не в характере Халамки. «Никто из нас не слышал, чтобы Джон когда-нибудь говорил: ?Что я наделал!? или ?Как же теперь быть??, — рассказывает один из его коллег по Health Data Consortium. — Eмy было действительно тяжело расписываться в своем бессилии».

«Когда Джон сообщил нам, что не может назвать срок возобновления работы сети, мы перестали требовать, чтобы он дважды в день представлял нам отчеты о своих действиях», — вспоминает Эпстайн. Необходимо было дать Халамке возможность сосредоточиться на решении проблемы. Но Эпстайн начинал терять терпение. Он вспоминает, что подумал тогда, что мы не можем продолжать рассылать сотрудникам докладные записки, в которых говорится: «Вот ведь какая штука, коллеги, — сеть-то еще не восстановлена».

«Если бы я почувствовал в те горячие дни, что кто-то мог бы справиться с делом лучше, чем я, если бы у меня возникло ощущение, что я препятствую быстрейшему разрешению кризиса, я сложил бы с себя свои обязанности, — рассказывает Халамка. — Но такие мысли не посещали меня ни на секунду, так же, как и опасения на тот счет, что я могу потерять свою должность. Несу ли я личную ответственность за весь этот эпизод? Да, безусловно. Вызывает ли это эмоциональный надлом? Разумеется, вызывает. Но раз я виноват, мне и исправлять положение».

Ночью в субботу, когда работы по созданию дополнительного ядра были завершены, Халамка запустил сеть. Она заработала... Всеобщая радость. Халамка наконец-то отправился домой.

В час ночи его разбудил зуммер пейджера.

Еще один сбой.

ВОСКРЕСЕНЬЕ

Причина сбоя была очевидной: сетевая плата одного из базовых коммутаторов вышла из строя. Плату заменили. Халамка вновь улегся в кровать.

Время — 6 утра. Еще один сбой; на этот раз произошло «замусоривание» памяти одного из базовых коммутаторов. Авральная бригада инженеров Cisco быстро нашла причину: ошибка во встроенном программном обеспечении, отклонение от правильных настроек виртуальных локальных сетей, обнаружить которое по силам только экспертам. Сбой ликвидирован.

Весь день ИТ-специалисты занимались документированием изменений, внесенных в структуру сети. Халамка упрямо не хотел объявлять о восстановлении работы сети, хотя она функционировала вполне нормально.

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

ПОНЕДЕЛЬНИК

Все приходит в норму

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

Около 7:30 утра, когда госпиталь входит в нормальный рабочий ритм, Халамка сидел у компьютера, уставясь в диаграмму. Он боялся увидеть на экране размашистую остроконечную «гармошку». Опасения оказались напрасными. В полдень Халамка распорядился о возвращении к обычному режиму работы. Кризис миновал. Он закончился обыденно, без фанфар. Халамка был один в своем кабинете, так же, как и в тот день, когда все началось.


Scott Berinato. All systems down. CIO, 15 February 2003


О чем следует побеспокоиться

Из четырехдневного испытания директор информационной службы госпиталя Beth Israel Deaconess Джон Халамка извлек два важнейших урока.

УРОК ПЕРВЫЙ

Тот, кто относится к сети как ко второстепенной службе, подвергает свою организацию серьезному риску.

Что необходимо делать:

  1. Быстрее выводить из эксплуатации устаревшее сетевое оборудование и разработать меры по управлению общим жизненным циклом сетевых устройств.
  2. Перед выполнением мероприятий по внесению изменений в структуру сети требовать обязательного проведения предварительного анализа и тестирования предпринимаемых шагов.
  3. Документировать все изменения; в числе прочего постоянно обновлять диаграммы физической и логической структуры сети.
  4. Проводить мероприятия по внесению изменений в структуру сети только по выходным дням с 2 до 5 часов утра.

УРОК ВТОРОЙ

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

Что необходимо делать:

  1. Планировать меры по материально-техническому снабжению бригады ИТ-специалистов, в том числе позаботиться об их питании, ночлеге, а также об организации работы по сменам.
  2. общении с сотрудниками предприятия оперировать только фактами; необоснованный оптимизм, выражаемый даже из самых лучших побуждений, в периоды кризисов может привести к психологическим срывам.
  3. Подготовить основную линию действий на случай, если "все пойдет вразнос", в частности подготовить модемы для опроса устройств сети, а также вариант плана на бумаге.
  4. разработке планов восстановления не ограничиваться обеспечением целостности данных; необходимо учесть проблемы самой сети.