Как одна строчка кода нанесла ущерб на $60 млн

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

Несмотря на отчаянные попытки устранить последствия, сеть AT&T оставалась частично неисправной в течение целых 9 часов, что привело к 50% показателю «неудачных соединений». 

В итоге AT&T потеряла 60 миллионов долларов, а более 60 тысяч жителей немаленького города Нью-Джерси на 9 часов оказались в XIX веке — фактически лишились полноценного доступа к связи по стационарным и домашним телефонам (а телефон тогда был по большому счету единственным средством связи). Кроме того, были отменены 500 авиарейсов, что нарушило планы 85 тыс человек.

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

Однако в этот день неисправность, возникшая в одном из коммутаторов, каскадом распространилась по сети. 

Это произошло из-за простейшей ошибки в обновлении ПО, которое содержало критический дефект, затрагивающий 114 коммутаторов. Когда свеже-обновленный нью-йоркский центральный коммутатор перезагрузился и стал рассылать управляющие сигналы остальным, возник тот самый обвальный «эффект домино», что привело к крупномасштабному отказу большой системы, классическому эпик-фэйлу.

Факт в том, что этот небольшой патч не был протестирован. Причём, тестирование не проводилось по просьбе руководства, поскольку изменения в коде сочли «незначительными».

При этом бОльшая часть кода в ПО AT&T подвергалась очень тщательному, образцовому тестированию.

Как уже было сказано, причиной столь масштабного сбоя стала ошибка в коде обновления ПО на коммутаторах сети. Ошибка в программе (на C) заключалась в неправильном расположении оператора прерывания break во вложенных (nested) условных операторах, что приводило к многократной перезаписи данных и перезагрузках системы.

Пример кода (С-псевдокод):

1  while (ring receive buffer not empty 
          and side buffer not empty):

2    Initialize pointer to first message in side buffer
     or ring receive buffer

3    get copy of buffer

4    switch (message):

5       case (incoming_message):

6             if (sending switch is out of service):

7                 if (ring write buffer is empty):

8                     send "in service" to status map

9                 else:

10                    break // ! ОШИБКА !

                  END IF

11           process incoming message, set up pointers to
             optional parameters

12           break
       END SWITCH


13   do optional parameter work

Проблема заключалась в следующем:

  • Если ring write buffer is NOT empty (буфер записи вызова НЕ пуст), то оператор `if` в строке 7 пропускается, и вместо него выполняется оператор break в строке 10.
  • Однако, чтобы программа работала правильно, вместо этого должна была выполняться строка 11.
  • Если вместо правильной обработки входящего вызова и установки указателей на опциональные параметры — выполняется оператор break, то данные (указатели, которые должны были сохраняться) — перезаписываются.
  • Подпрограмма для автоопределения и исправления ошибок все-таки определяла факт некорректной перезаписи данных, и запускала отключение коммутатора для его сброса (перезагрузки). 
  • Однако, проблема усугублялась тем, что по факту дефектное программное обеспечение после обновления было установлено уже на всех коммутаторах в этой крупнейшей подсети, что привело к массовым перезагрузкам, которые в конечном итоге и привели систему к 50%-ной доступности для абонентов.

Таким образом, несмотря на то что система была изначально спроектирована с полным соблюдением требований к отказоустойчивости, всего лишь одна строчка кода «поломала» один из главных узлов связи в восточной части США.

Инженерам AT&T потребовалось целых 9 часов, чтобы полностью восстановить работу системы. Как? Очень просто: откатом ПО коммутаторов к предыдущей, рабочей версии.

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

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

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

Источник


Божественный канал по бизнес-анализу

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

🔥 Популярное

💬 Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас