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

В начале 90-х годов прошлого века LAS (London Ambulance Service) обслуживала регион, где проживало 6,8 млн человек. Система регистрировала 2—2,5 тыс. звонков ежедневно с прогнозируемым ростом количества обращений на 15% ежегодно.

Около 60% из них требовали вызова кареты скорой помощи — таковых насчитывалось 212 машин (не считая тех, что были на обслуживании и ремонте). Также были задействованы 445 единиц транспорта, один вертолет и мотоциклетное подразделение, 70 станций, 2746 сотрудников (более 3 тыс. по другим данным) — очевидно, что со всей этой армией нужно было как-то справляться.

Только 16% проектов в сфере информационных систем завершались вовремя и в рамках бюджета.

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

На радикальные меры пошли где-то в 90—91 годах после того, как правительство потребовало сократить время реакции до трех минут (звонок — ответ — отправка машины или перевод на консультацию). Тогда руководство LAS приняло решение воскресить один из прошлых проектов. Участие человека хотели минимизировать.

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

«Кто сделает дешевле, тот и выиграет тендер»

Со стороны звучит достаточно просто, однако система подразумевала тесную взаимосвязь различных сложных компонентов в режиме реального времени. Тем не менее внедрить LASCAD (или CAD, «компьютеризированная система вызова») хотели сразу и целиком, а не поэтапно и узлами.

Небольшое отступление. По данным того времени, лишь 16% проектов в сфере информационных систем (IS) завершались вовремя и в рамках выделенного изначально бюджета, тогда как 53% «съедали» больше денег и времени, а 31% отменяли.

Система LASCAD не была исключением из правил. Оригинальная версия платформы начала обретать формы еще в 1987 году, затем в 1989-м вносились изменения, но после превышения бюджета на 300% так и не запущенный проект закрыли. Новые требования «делать все быстрее» заставили вернуться к продукту, но…

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

Позже представители власти вовсю критиковали выбор подрядчика на доработку ПО. Кому-то это покажется знакомым, но основным критерием была цена — «кто сделает дешевле, тот и выиграет тендер». Поэтому всех тех, кто просил больше 1,5 млн фунтов стерлингов, вычеркнули из списка сразу (на предыдущие попытки потратили 7,5 млн фунтов). Осталось 17 подрядчиков, пять из которых согласились на озвученные условия — до 11 месяцев на все про все, сроки сдвигать категорически запрещено контрактом.

За дело взялось объединение из нескольких небольших фирм, во главе которых оказалась System Options (SO) — разработчик программного обеспечения, не имевший дела с крупными проектами, а также с продуктами, обладавшими повышенными требованиями к безопасности, отказоустойчивости и так далее. Некоторые источники пишут, что SO оказывала консультационные услуги и до этого к разработке ПО отношения не имела.

К моменту запуска в системе насчитывался 81 известный баг.

Однако этот подрядчик просил за работу менее миллиона фунтов — на 44% меньше, чем следующая ставка от другой компании. От консультаций с конечными пользователями системы отказались, чтобы сэкономить время и деньги — все решения о функционале и дизайне принимались «пиэмами» и представителями SO.

Вероятно, по причине экономии и сжатых сроков в ПО не было многоуровневой системы защиты от сбоев, хотя она подразумевалась. «Такая система должна работать стабильнее, чем защитные системы ядерного реактора», — говорил Робин Блумфилд, который консультировал правительство по вопросу разработки данной CAD. По его словам, на деле единственной резервной системой были сами операторы, ничего другого не предусмотрели.

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

Система LASCAD проработала не больше 36 часов.

К моменту запуска в системе насчитывался 81 известный баг (уровень их критичности не указывается, но для подобного продукта и этого более чем достаточно), под нагрузкой ее не проверяли вовсе. Условную кнопку «пуск» нажали ночью 26 октября 1992 года. На диспетчеров моментально обрушился шквал звонков.

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

Бригады выезжали по несколько машин на один вызов и не ехали на другие (заявки пропадали, их «съедала» система). Рассказывают о случае, когда медики прибыли на место, а пациент уже скончался и даже был вывезен в морг. Были и более трагические ситуации, когда предположительно из-за сбоев в LASCAD жители города и пригорода умирали, не получив помощи.

Данные о количестве умерших во время «полевого тестирования» системы разнятся — источники называют цифры от 20 до 45 человек. Дело в том, что определить взаимосвязь не всегда представлялось возможным. В номере от 30 октября 1992 года The Independent писала по горячим следам о 10—20 смертях.

Система LASCAD проработала не больше 36 часов (по другим данным — несколько часов), после чего ее полностью отключили от греха подальше.

«CAD не „упала“ окончательно, однако проблемы аккумулировались, и все привело к появлению симптомов системного сбоя», — осторожно писали в 1993 году. Действительно, ПО работало, в противном случае все было бы намного хуже, но на ум приходит выражение «толочь воду в ступе».

Оперативно были озвучены некоторые из очевидных причин сбоев. Самой заметной проблемой внедренного ПО стала его некорректная работа при заполнении оператором граф анкеты. Интерфейс был, мягко говоря, неудобен (оператор мог не видеть необходимую информацию), а в случае нажатия «не той кнопки» что-либо изменить было нельзя. И наконец, критическая ошибка, связанная с утечкой памяти. Ее вызывал небольшой фрагмент кода, но его было достаточно, чтобы спустя короткое время система была выведена из строя. Тестирование? Нет, не слышали.

Существовали и более серьезные упущения. К ним отнесли непрофессиональную работу менеджеров проекта: «Да, не будь ключевых ошибок (в коде), система могла бы и устоять. Но проблема кроется в том, как проектом управляли». А следуй разработчики и заказчики стандартам, которые выдвигают в отношении подобных продуктов, проблем можно было бы избежать. Выбор подрядчика без опыта, но «дешевого» — тоже так себе решение.

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

LAS тем временем вернулась к ручному управлению вызовами, а CAD отправили на доработку. Снова ее включили только в 1996 году. На этот раз с развертыванием не торопились: неделя на ограниченную «обкатку», затем постепенное подключение компонентов, снижающих вовлеченность в процесс операторов. Скептиков поначалу было много, однако их количество уменьшалось — по мере заметного снижения жалоб на работу повысившей эффективность службы.

В будущем LASCAD ждала пара потрясений, связанных с некорректными апдейтами, однако в целом подход «медленно, дорого и профессионально» сработал (новые версии разрабатывали in-house, со сроками не торопили). К тому же второй такой ошибки общество бы не простило.

Список источников: Wired, The Register, The Independent, Springer, Paperap, Erich Musick, Robert Pinchbeck.

Читайте также:

• Надо ли заклеивать веб-камеру и как остановить слежку Google?
• Собрали игровой компьютер за 100 рублей. Рассказываем как

Библиотека Onliner: лучшие материалы и циклы статей

Наш канал в Telegram. Присоединяйтесь!

Быстрая связь с редакцией: читайте паблик-чат Onliner и пишите нам в Viber!

Перепечатка текста и фотографий Onliner без разрешения редакции запрещена. nak@onliner.by