Ошибки в программировании – дело обычное, хоть и неприятное. В данной статье будет рассказано о том, какими бывают ошибки (баги), а также что собой представляют исключения.
Определение
Ошибка в программировании (или так называемый баг) – это ситуация у разработчиков, при которой определенный код вследствие обработки выдает неверный результат. Причин данному явлению множество: неисправность компилятора, сбои интерфейса, неточности и нарушения в программном коде.
Баги обнаруживаются чаще всего в момент отладки или бета-тестирования. Реже – после итогового релиза готовой программы. Вот несколько вариантов багов:
Ошибки в программах могут привести соответствующее приложение в негодность, а также к непредсказуемым алгоритмам функционирования. Желательно обнаруживать баги на этапе ранней разработки или тестирования. Лишь в этом случае программист сможет оперативно и относительно недорого внести необходимые изменения в код для отладки ПО.
История происхождения термина
Баг – слово, которое используется разработчиками в качестве сленга. Оно произошло от слова «bug» – «жук». Точно неизвестно, откуда в программировании и IT возник соответствующий термин. Существуют две теории:
Второй вариант кажется более реалистичным. Это факт, который подтвержден документально. Со временем научились различать различные типы багов в IT. Далее они будут рассмотрены более подробно.
Как классифицируют
Ошибки работы программ разделяются по разным факторам. Классификация у рядовых пользователей и разработчиков различается. То, что для первых – «просто программа вылетела» или «глючит», для вторых – огромная головная боль. Но существует и общепринятая классификация ошибок. Пример – по критичности:
Последний вариант требует особого внимания со стороны программистов. Их стараются обнаружить и устранить в первую очередь. Критические ошибки могут отложить релиз исходной программы на неопределенный срок.
Также существуют различные виды сбоев в плане частоты проявления: постоянные и «разовые». Вторые встречаются редко, чаще – при определенных настройках и действиях со стороны пользователя. Первые появляются независимо от используемой платформы и выполненных клиентом манипуляций.
Иногда может получиться так, что ошибка возникает только на устройстве конкретного пользователя. В данном случае устранение неполадки требует индивидуального подхода. Иногда – полной замены компьютера. Связано это с тем, что никто не будет редактировать исходный код, когда он «глючит» только у одного пользователя.
Виды
Существуют различные типы ошибок в программах в зависимости от типовых условий использования приложений. Пример – сбои, которые возникают при возрастании нагрузки на оперативную память или центральный процессор устройства. Есть баги граничных условий, сбоя идентификаторов, несовместимости с архитектурой процессора (наиболее распространенная проблема на мобильных устройствах).
Разработчики выделяют следующие типы ошибок по уровню сложности:
Также есть классификация «по критичности». Тут всего два варианта – warning («варнинги») и критические весомые сбои. Первые сопровождаются характерными сообщениями и отчетами для разработчиков. Они не представляют серьезной опасности для работоспособности приложения. При компилировании такие сбои легко исправляются. В отдельных случаях компилятор справляется с этой задачей самостоятельно. А вот критические весомые сбои говорят сами за себя. Они приводят к серьезным нарушениям ПО. Исправляются обычно путем проработки логики и значительных изменений программного кода.
Типы багов
Ошибки в программах бывают:
Это – основная классификация сбоев в приложениях и операционных системах. Логические, синтаксические и «среды выполнения» встречаются в разработке чаще остальных. На них будет сделан основной акцент.
Ошибки синтаксиса
Синтаксические баги распространены среди новичков. Они относятся к категории «самых безобидных». С данной категорией ошибок способны справиться компиляторы тех или иных языков. Соответствующие инструменты показывают, где допущена неточность. Остается лишь понять, как исправить ее.
Синтаксические ошибки – ошибки синтаксиса, правил языка. Вот пример в Паскале:
Код написан неверно. Согласно действующим синтаксическим нормам, в Pascal в первой строчке нужно в конце поставить точку с запятой.
Логические
Тут стоит выделить обычные и арифметические типы. Вторые возникают, когда программе при работе необходимо вычислить много переменных, но на каком-то этапе расчетов возникают неполадки или нечто непредвиденное. Пример – получение в результатах «бесконечности».
Логические сбои обычного типа – самые сложные и неприятные. Их тяжелее всего обнаружить и исправить. С точки зрения языка программа может быть написана идеально, но работать неправильно. Подобное явление – следствие логической ошибки. Компиляторы их не обнаруживают.
Выше – пример логической ошибки в программе. Тут:
Может показаться, что ошибка безобидная. В приведенном примере так и есть, но в более крупных программах такое явление приводит к серьезным последствиям.
Время выполнения
Run-time сбои – это ошибка времени выполнения программы. Встречается даже когда исходный код лишен логических и синтаксических ошибок. Связаны такие неполадки с ходом выполнения программного продукта. Пример – в процессе функционирования ПО был удален файл, считываемый программой. Если игнорировать подобные неполадки, можно столкнуться с аварийным завершением работы контента.
Самый распространенный пример в данной категории – это неожиданное деление на ноль. Предложенный фрагмент кода с точки зрения синтаксиса и логики написан грамотно. Но, если клиент наберет 0, произойдет сбой системы.
Компиляционный тип
Встречается при разработке на языках высокого уровня. Во время преобразований в машинный тип «что-то идет не так». Причиной служат синтаксические ошибки или сбои непосредственно в компиляторе.
Наличие подобных неполадок делает бета-тестирование невозможным. Компиляционные ошибки устраняются при разработке-отладке.
Ресурсные
Ресурсный тип ошибок – это сбои вроде «переполнение буфера» или «нехватка памяти». Тесно связаны с «железом» устройства. Могут быть вызваны действиями пользователя. Пример – запуск «свежих» игр на стареньких компьютерах.
Исправить ситуацию помогают основательные работы над исходным кодом. А именно – полное переписывание программы или «проблемного» фрагмента.
Взаимодействие
Подразумевается взаимодействие с аппаратным или программным окружением. Пример – ошибка при использовании веб-протоколов. Это приведет к тому, что облачный сервис не будет нормально функционировать. При постоянном возникновении соответствующей неполадки остается один путь – полностью переписывать «проблемный» участок кода, ответственный за соответствующий баг.
Исключения и как избежать багов
Исключение – событие, при возникновении которых начинается «неправильное» поведение программы. Механизм, необходимый для стабилизации обработки неполадок независимо от типа ПО, платформ и иных условий. Помогают разрабатывать единые концепции ответа на баги со стороны операционной системы или контента.
Исключения нужны для охвата критических багов. Избежать неполадок помогут отладчики на этапе разработки. А еще – своевременное поэтапное тестирование программы.
P. S. Большой выбор курсов по тестированию есть и в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.
Отладка программы призвана выискивать «вредителей» кода и устранять их. За это отвечают отладчик и журналирование для вывода сведений о программе.
В предыдущей части мы рассмотрели исходный код и его составляющие.
После того, как вы начнете проверять фрагменты кода или попытаетесь решить связанные с ним проблемы, вы очень скоро поймете, что существуют моменты, когда программа крашится, прерывается и прекращает работу.
Это часто вызвано ошибками, известными как дефекты или исключительные ситуации во время выполнения. Акт обнаружения и удаления ошибок из нашего кода – это отладка программы. Вы лучше разберетесь в отладке на практике, используя ее как можно чаще. Мы не только отлаживаем собственный код, но и порой дебажим написанное другими программистами.
Для начала необходимо рассортировать общие ошибки, которые могут возникнуть в исходном коде.
Синтаксические ошибки
Эти эрроры не позволяют скомпилировать исходный код на компилируемых языках программирования. Они обнаруживаются во время компиляции или интерпретации исходного кода. Они также могут быть легко обнаружены статическими анализаторами (линтами). Подробнее о линтах мы узнаем немного позже.
Синтаксические ошибки в основном вызваны нарушением ожидаемой формы или структуры языка, на котором пишется программа. Как пример, это может быть отсутствующая закрывающая скобка в уравнении.
Семантические ошибки
Отладка программы может потребоваться и по причине семантических ошибок, также известных как логические. Они являются наиболее сложными из всех, потому что не могут быть легко обнаружены. Признак того, что существует семантическая ошибка, – это когда программа запускается, отрабатывает, но не дает желаемого результата.
Рассмотрим данный пример:
3 + 5 * 6
По порядку приоритета, называемому старшинством операции, с учетом математических правил мы ожидаем, что сначала будет оценена часть умножения, и окончательный результат будет равен 33. Если программист хотел, чтобы сначала происходило добавление двух чисел, следовало поступить иначе. Для этого используются круглые скобки, которые отвечают за смещение приоритетов в математической формуле. Исправленный пример должен выглядеть так:
(3 + 5) * 6
3 + 5, заключенные в скобки, дадут желаемый результат, а именно 48.
Ошибки в процессе выполнения
Как и семантические, ошибки во время выполнения никогда не обнаруживаются при компиляции. В отличие от семантических ошибок, эти прерывают программу и препятствуют ее дальнейшему выполнению. Они обычно вызваны неожиданным результатом некоторых вычислений в исходном коде.
Вот хороший пример:
input = 25
x = 0.8/(Math.sqrt(input) – 5)
Фрагмент кода выше будет скомпилирован успешно, но input 25 приведет к ZeroDivisionError. Это ошибка во время выполнения. Другим популярным примером является StackOverflowError или IndexOutofBoundError. Важно то, что вы идентифицируете эти ошибки и узнаете, как с ними бороться.
Существуют ошибки, связанные с тем, как ваш исходный код использует память и пространство на платформе или в среде, в которой он запущен. Они также являются ошибками во время выполнения. Такие ошибки, как OutOfMemoryErrorand и HeapError обычно вызваны тем, что ваш исходный код использует слишком много ресурсов. Хорошее знание алгоритмов поможет написать код, который лучше использует ресурсы. В этом и заключается отладка программы.
Процесс перезаписи кода для повышения производительности называется оптимизацией. Менее популярное наименование процесса – рефакторинг. Поскольку вы тратите больше времени на кодинг, то должны иметь это в виду.
Отладка программы
Вот несколько советов о том, как правильно выполнять отладку:
Двигаемся дальше
Поздравляем! Слово «ошибка» уже привычно для вас, равно как и «отладка программы». В качестве новичка вы можете изучать кодинг по книгам, онлайн-урокам или видео. И даже чужой код вам теперь не страшен 🙂
В процессе кодинга измените что-нибудь, чтобы понять, как он работает. Но будьте уверены в том, что сами написали.
Викторина
input = Hippo’
if input == ‘Hippo’:
print ‘Hello, Hippo’
Ответы на вопросы
2. Синтаксическая ошибка: Отсутствует стартовая кавычка в первой строке.
Что называют исключением. Исключения в мире программирования
В программировании исключением называют возникновение ошибки (ошибок) и различных непредвиденных ситуаций в процессе выполнения программы. Исключения могут появляться как в итоге неправильных действий юзера, так и из-за потери сетевого соединения с сервером, отсутствии нужного ресурса на диске и т. п. Также среди причин исключений — ошибки программирования либо неверное использование API.
При этом в отличие от «человеческого мира», программное приложение должно чётко понимать, как поступать в подобной ситуации. И вот как раз для этого в Java и существует механизм исключений (exception).
Используемые ключевые слова
При обработке исключений в Java применяются следующие ключевые слова:
— try – служит для определения блока кода, в котором может произойти исключение;
— catch – необходим для определения блока кода, где происходит обработка исключения;
— finally – применяется для определения блока кода, являющегося необязательным, однако при его наличии он выполняется в любом случае вне зависимости от результата выполнения блока try.
Кроме того:
1. Для возбуждения исключения используем throw.
2. Для предупреждения в сигнатуре методов о том, что метод может выбросить исключение, применяем throws.
Давайте на примере посмотрим, как используются ключевые слова в Java-программе:
//метод считывает строку с клавиатуры
//предупреждаем с помощью throws,
// что метод может выбросить исключение MyException
//в блок try заключаем код, в котором может произойти исключение, в данном
// случае компилятор нам подсказывает, что метод readLine() класса
// BufferedReader может выбросить исключение ввода/вывода
// в блок catch заключаем код по обработке исключения IOException
// в блоке finally закрываем поток чтения
// при закрытии потока тоже возможно исключение, например, если он не был открыт, поэтому “оборачиваем” код в блок try
// пишем обработку исключения при закрытии потока чтения
// мы решили, что пустая строка может нарушить в дальнейшем работу нашей программы, например, на результате этого метода нам надо вызывать метод substring(1,2), поэтому мы вынуждены прервать выполнение программы с генерацией своего типа исключения MyException с помощью throw
“String can not be empty!”
Зачем нам механизм исключений?
Для понимания опять приведём пример из обычного мира. Представьте, что на какой-нибудь автодороге имеется участок с аварийным мостом, на котором ограничена грузоподъёмность. И если по такому мосту проедет грузовик со слишком большой массой, мост разрушится, а в момент этого ЧП ситуация для шофёра станет, мягко говоря, исключительной. И вот, дабы такого не произошло, дорожные службы заранее устанавливают на дороге соответствующие предупреждающие знаки. И тогда водитель, посмотрев на знак, сравнит массу своего авто со значением разрешённой грузоподъёмности и примет соответствующее решение, например, поедет по другой дороге.
То есть мы видим, что из-за правильных действий дорожной службы шоферы крупногабаритных транспортных средств:
1) получили возможность заранее изменить свой путь;
2) были предупреждены об опасности;
3) были предупреждены о невозможности проезжать по мосту при определённых условиях.
Вот как наш жизненный пример соотносится с применением исключения на Java:
Исходя из вышесказанного, мы можем назвать одну из причин применения исключений в Java. Заключается она в возможности предупреждения исключительной ситуации для её последующего разрешения и продолжения работы программы. То есть механизм исключений позволит защитить написанный код от неверного применения пользователем путём валидации входящих данных.
Что же, давайте ещё раз побудем дорожной службой. Чтобы установить знак, мы ведь должны знать места, где водителей ТС могут ждать различные неприятности. Это первое. Далее, нам ведь надо заготовить и установить знаки. Это второе. И, наконец, надо предусмотреть маршруты объезда, позволяющие избежать опасности.
Иногда бывает, что мы не можем предусмотреть «запасной аэродром» либо специально желаем предоставить право его выбора юзеру. Но всё равно мы должны как минимум предупредить пользователя об опасности. Иначе он превратится в разъярённого шофёра, который ехал долго, не встретил ни одного предупреждающего знака и в итоге добрался до аварийного моста, проехать по которому не представляется возможным.
Что касается программирования на Java, то мы, когда пишем свои классы и методы, далеко не всегда можем предвидеть контекст их применения другими программистами в своих программах, а значит, не можем со стопроцентной вероятностью предвидеть правильный путь для разрешения исключительных ситуаций. Но предупредить коллег о возможной исключительной ситуации мы всё-таки должны, и это не что иное, как правило хорошего тона.
Выполнить это правило в Java нам как раз и помогает механизм исключений с помощью throws. Выбрасывая исключение, мы, по сути, объявляем общее поведение нашего метода и предоставляем пользователю метода право написания кода по обработке исключения.
Предупреждаем о неприятностях
Если мы не планируем обрабатывать исключение в собственном методе, но желаем предупредить пользователей метода о возможной исключительной ситуации, мы используем, как это уже было упомянуто, ключевое слово throws. В сигнатуре метода оно означает, что при некоторых обстоятельствах метод может выбросить исключение. Это предупреждение становится частью интерфейса метода и даёт право пользователю на создание своего варианта реализации обработчика исключения.
После упоминания ключевого слова throws мы указываем тип исключения. Как правило, речь идёт о наследниках класса Exception Java. Но так как Java — это объектно-ориентированный язык программирования, все исключения представляют собой объекты.
Иерархия исключений в Java
Когда возникают ошибки при выполнении программы, исполняющая среда Java Virtual Machine обеспечивает создание объекта нужного типа, используя иерархию исключений Java — речь идёт о множестве возможных исключительных ситуаций, которые унаследованы от класса Throwable — общего предка. При этом исключительные ситуации, которые возникают в программе, делят на 2 группы:
1. Ситуации, при которых восстановление нормальной дальнейшей работы невозможно.
2. Ситуации с возможностью восстановления.
К первой группе можно отнести случаи, при которых возникают исключения, которые унаследованы из класса Error. Это ошибки, возникающие во время выполнения программы при сбое работы Java Virtual Machine, переполнении памяти либо сбое системы. Как правило, такие ошибки говорят о серьёзных проблемах, устранение которых программными средствами невозможно. Данный вид исключений в Java относят к неконтролируемым исключениям на стадии компиляции (unchecked). К этой же группе относятся и исключения-наследники класса Exception, генерируемые Java Virtual Machine в процессе выполнения программы — RuntimeException. Данные исключения тоже считаются unchecked на стадии компиляции, а значит, написание кода по их обработке необязательно.
Что касается второй группы, то к ней относят ситуации, которые можно предвидеть ещё на стадии написания приложения, поэтому для них код обработки должен быть написан. Это контролируемые исключения (checked). И в большинстве случаев Java-разработчики работают именно с этими исключениями, выполняя их обработку.
Создание исключения
В процессе исполнения программы исключение генерируется Java Virtual Machine либо вручную посредством оператора throw. В таком случае в памяти происходит создание объекта исключения, выполнение основного кода прерывается, а встроенный в JVM обработчик исключений пробует найти способ обработать это самое исключение.
Обработка исключения
В процессе возбуждения исключения в try обработчик исключения ищется в блоке catch, который следует за try. При этом если в catch присутствует обработчик данного вида исключения, происходит передача управления ему. Если же нет, JVM осуществляет поиск обработчика данного типа исключения, используя для этого цепочку вызова методов. И так происходит до тех пор, пока не находится подходящий catch. После того, как блок catch выполнится, управление переходит в необязательный блок finally. Если подходящий блок catch найден не будет, Java Virtual Machine остановит выполнение программы, выведя стек вызовов методов под названием stack trace. Причём перед этим выполнится код блока finally при наличии такового.
Рассмотрим практический пример обработки исключений:
“Exception: s is null!”
“Inside method print: ”
“Exception was processed. Program continues”
“Inside bloсk finally”
А теперь глянем на результаты работы метода main:
Блок finally чаще всего используют, чтобы закрыть открытые в try потоки либо освободить ресурсы. Но при написании программы уследить за закрытием всех ресурсов возможно не всегда. Чтобы облегчить жизнь разработчикам Java, была предложена конструкция try-with-resources, автоматически закрывающая ресурсы, открытые в try. Используя try-with-resources, мы можем переписать наш первый пример следующим образом:
А благодаря появившимся возможностям Java начиная с седьмой версии, мы можем ещё и объединять в одном блоке перехват разнотипных исключений, делая код компактнее и читабельнее:
Итоги
Итак, применение исключений в Java повышает отказоустойчивость программы благодаря использованию запасных путей. Кроме того, появляется возможность отделить код обработки исключительных ситуаций от логики основного кода за счёт блоков catch и переложить обработку исключений на пользователя кода посредством throws.
Основные вопросы об исключениях в Java
1. Что такое проверяемые и непроверяемые исключения?
Если говорить коротко, то первые должны быть явно пойманы в теле метода либо объявлены в секции throws метода. Вторые вызываются проблемами, которые не могут быть решены. Например, это нулевой указатель или деление на ноль. Проверяемые исключения очень важны, ведь от других программистов, использующих ваш API, вы ожидаете, что они знают, как обращаться с исключениями. К примеру, наиболее часто встречаемое проверяемое исключение — IOException, непроверяемое — RuntimeException.
2. Почему переменные, определённые в try, нельзя использовать в catch либо finally?
Давайте посмотрим на нижеследующий код. Обратите внимание, что строку s, которая объявлена в блоке try, нельзя применять в блоке catch. То есть данный код не скомпилируется.
А всё потому, что неизвестно, где конкретно в try могло быть вызвано исключение. Вполне вероятно, что оно было вызвано до объявления объекта.
3. Почему Integer.parseInt(null) и Double.parseDouble(null) вызывают разные исключения?
Это проблема JDK. Так как они были разработаны разными людьми, то заморачиваться вам над этим не стоит:
// вызывает java.lang. NumberFormatException: null
// вызывает java.lang. NullPointerException
4. Каковы основные runtime exceptions в Java?
Вот лишь некоторые из них:
Их можно задействовать в операторе if, если условие не выполняется:
“obj не может быть равно null”
5. Возможно ли поймать в одном блоке catch несколько исключений?
Вполне. Пока классы данных исключений можно отследить вверх по иерархии наследования классов до одного и того же суперкласса, возможно применение только этого суперкласса.
6. Способен ли конструктор вызывать исключения?
Способен, ведь конструктор — это лишь особый вид метода.
//get current directory
7. Возможен ли вызов исключений в final?
В принципе, можете сделать таким образом:
Но если желаете сохранить читабельность, объявите вложенный блок try-catch в качестве нового метода и вставьте вызов данного метода в блок finally.
Это, пожалуй, самый болезненный отчет об ошибке, который я когда-либо читал. Он красочно описывает шаги, которые привели к потере 465 миллионов долларов компанией Knight Capital в связи с ошибкой программного обеспечения, проявившейся в прошлом году и обанкротившей компанию
Для обеспечения участия своих клиентов в Программе ликвидности (ПЛ) на Нью-Йоркской фондовой бирже, запуск которой планировался 1 августа 2012 года, Knight внес ряд изменений в свои системы и программный код, связанный с процессом обработки заказов. Эти изменения включали в себя разработку и развертывание нового программного кода в SMARS. S MARS представляет собой автоматизированный, высокоскоростной, алгоритмический маршрутизатор, который отправляет заказы на рынок. Одна из основных функций SMARS — это получение заказов от других компонентов торговой платформы Knight («родительских» заказов), и, по мере необходимости на основе имеющейся ликвидности, отправка одного или нескольких представительских (или «дочерних») заказов внешним службам на исполнение.
13. При развертывании новый ПЛ код в SMARS должен был заменить неиспользуемый код в соответствующей части маршрутизатора. Этот неиспользуемый код ранее был нужен для функцинальности Power Peg, которую компания не применяла уже долгие годы. Несмотря на это, она оставалась рабочей и могла вызываться во время развертывания ПЛ. Новый ПЛ код использовал флаг, который ранее был использовался для активации Power Peg. Knight хотела удалить код Power Peg, чтобы при установке этого флага в “да” использовалась новая функциональность ПЛ, а не Power Peg.
14. Ранее при использовании Power Peg суммирующая функция вычисляла количество акций в выполняемых дочерних заказах и сигнализировала о необходимости прекращения размещения дочерних заказов после того, как родительский заказ был выполнен. В 2003 году Knight прекратили использовать Power Peg. В 2005 Knight изменили код Power Peg, переместив функцию отслеживания выполнения родительского заказа на более раннюю стадию последовательности кода SMARS. Повторного тестирования кода Power Peg после изменения Knight не выполнили и в том, что процедура по-прежнему работает корректно, не убедились.
15. Начиная с 27 июля 2012, компания Knight развернула новый ПЛ код в SMARS, разместив его на ограниченном числе серверов. Во время развертывания нового кода один из техников не скопировал новый код на один из восьми серверов SMARS. В Knight не было второго техника, который бы проводил проверку развертывания, и никто не понял, что код Power Peg не был удален с восьмого сервера и новый ПЛ код не был добавлен. В Knight не было никаких письменных процедур, которые требовали бы такой проверки.
16. 1 августа Knight получала заказы от брокеров-дилеров, чьи клиенты могли участвовать в ПЛ. Семь серверов обрабатывали заказы правильно. Но заказы, отправленные на 8 сервер с установленным флагом запуска, запустили дефектный код Power Peg, который всё ещё присутствовал на этом сервере. В результате сервер воспринял заказы как родительские и начал отправлять дочерние заказы в трейдинговые центры. Вследствие того, что функция проверки выполнения родительского заказа была перемещена на другую стадию процесса, сервер продолжал размещать дочерние заказы безостановочно — не обращая внимания на то, что родительский заказ уже выполнен. Хотя некоторая часть системы обработки заказов определяла, что родительский заказ выполнен, в SMARS эта информация не попадала.
19. 1 августа Knight также получала заказы, которые относились к ПЛ, но предназначались для торговли до открытия рынка. 6 серверов SMARS обрабатывали эти заказы и, начиная примерно с 8:01 утра, внутренние системы генерировали автоматические сообщения (под названием «отказ BNET»), которые ссылались на SMARS и описывали ошибку как «Power Peg отключен». Система Knight отправила 97 таких сообщений до 9:30 утра, когда открылся рынок. Сообщения подобного типа не расценивались системой, как опасные, а персонал вообще не читал их.
27. 1 августа в Knight не было никаких процедур, касающихся реагирования на инциденты. Иными словами, в компании не было контрольных процедур для руководства персоналом, когда происходили серьезные проблемы. 1 августа Knight пользовался услугами своей команды техников, чтобы выявить и устранить проблемы в SMARS в живой торговой среде. Система Knight продолжала посылать миллионы «дочерних» заказов, пока персонал пытался выявить источник проблемы. Компания даже удалила новый ПЛ код с семи серверов, на которых он был установлен правильно. Это усугубило ситуацию, ведь новые «родительские» заказы активировали код Power Peg, который присутствовал на этих серверах, подобно тому, что уже произошло на восьмом сервере.
Как 45 минут терять по $172 222 в секунду
Каким бы совершенным и надежным не было программное обеспечение, практика показывает, что сбои в работе ПО будут всегда.
Чаще всего подобные ошибки имеют локальный характер, поэтому в короткие сроки исправляются специалистами.
Впрочем, бывали случаи, когда баги в программах являлись причиной аварий, повлекших за собой гибель людей и многомиллионные убытки.
Авария Ariane 5: ошибка стоимостью $500 млн
4 июня 1996 с космодрома «Куру» Европейским космическим агентством была впервые запущена новая ракета-носитель Ariane 5.
Поначалу все шло по плану: ракета стартовала, оставив после себя гигантские клубы газа, но неожиданно на 37 секунде полета на высоте 4 км она резко отклонилась от курса и самоуничтожилась.
В результате аварии потеряли 4 спутника, что были на борту ракеты.
Они предназначались для изучения магнитного поля Земли.
До сих пор эта катастрофа считается самой крупной аварией в истории по величине убытков.
Причина всего — программная ошибка.
Сразу же после инцидента ведущие мировые эксперты провели независимое расследование.
В результате чего выяснили, что причиной аварии стали многочисленные ошибки в программном обеспечении бортовых компьютеров Ariane 5.
Toyota и 7134 ошибок в коде
Несколько лет назад была опубликована страшная статистика: в период с 2000 по 2010 год ошибки в программном коде автомобилей Toyota стали причиной гибели 89 человек.
Расследование получило широкий резонанс, ведь ранее никто не догадывался об истинных причинах аварий (все сводилось к таким классическим вариантам как невнимательность водителей и плохие погодные условия).
Расследование проводилось более 10 месяцев совместными усилиями нескольких правительственных агентств.
В ходе проверки выявили ужасающий факт: ПО автомобилей содержало 7134 ошибок в программном коде.
Toyota до сих пор отрицает вину программного обеспечения своей бортовой системы и утверждает, что результаты исследования были сфабрикованы и не соответствуют действительности.
Therac-25: лечение с летальным исходом
С 1985 по 1987 год в ходе сеансов лучевой терапии с использованием медицинского аппарата Therac-25 погибли как минимум 6 человек.
Все они получили смертельную дозу радиации.
Аппарат разработала канадская государственная медицинская организация.
Его применяли для лечения опухолей высокоэнергетическими лучами.
В Therac-25 имелась программная защита от рентгеновских лучей.
Примечательно, что ПО создал всего один человек, а это более 20 миллионов строк кода, написанных на устаревшем языке программирования.
В 1985 году это ПО установили на большинство действующих в то время аппаратов Therac-25.
Спустя несколько дней после этого устройство, которое до этого работало безупречно стало причиной первого смертельного случая, зарегистрированного при сеансе лучевой терапии.
Вначале медицинские работники винили во всем плохое состояние пациентов и аппаратное обеспечение устройства.
Однако после очередного смертельного случая было проведено масштабное расследование.
Эксперты доказали, что причиной смертельного облучения пациентов стали многочисленные ошибки в программном коде, в результате чего одна и та же команда выполнялась многократно.
Блэкаут в США: всё, электричество кончилось!
Программная ошибка в системе мониторинга электрооборудования корпорации General Electric стала причиной одного из самых масштабных блэкаутов.
В результате аварии на несколько часов более 50 млн жителей США остались без электричества.
14 августа 2003 года программная ошибка привела к незапланированной перезагрузке системы мониторинга оборудования на одной из электростанций, в результате чего отключилась система сигнализации.
По злополучному стечению обстоятельств вскоре после этого в штате Огайо из-за упавшего дерева произошло отключение линии электропередач.
Поскольку система сигнализации была отключена, операторы электростанции не обнаружили сбоя.
В итоге локальная поломка обрела по-настоящему катастрофический масштаб: в крупнейших городах восточного побережья один за другим начали отключаться перегруженные линии электропередач.
Однажды в Джорджии: остановка работы АЭС
Масштабный инцидент на крупной атомной электростанции в штате Джорджия — работа АЭС была остановлена более чем на двое суток.
Позже выяснилось, что причиной этому послужила банальная переустановка программного обеспечения на одном из основных управляющих компьютеров, который отвечает за диагностику главных систем станции.
После обновления ПО компьютер автоматически перезагрузился, при этом уничтожив часть данных о контроле показателей уровня радиации.
В итоге система безопасности АЭС восприняла потерю информации за внешнюю утечку радиоактивных веществ и полностью остановила эксплуатацию всех систем станции на 48 часов.
Технологии повсюду. Даже если Вы – убеждённый луддит и не приемлите ничего сложнее прищепки, в наше суетное, насквозь опутанное проводами время технологии всё равно имеют непосредственное влияние на Вашу жизнь. Программное обеспечение контролирует подачу воды в Ваш дом, управляет энергетикой и даже отслеживает перемещение поездов метро.
Принимая во внимание, что все программы, написанные человеком, человек же может и скомпрометировать, технологии становятся источником опасности для индивидуума. Общество уже не раз и не два получало пощёчины от технологий, слишком легкомысленно воспринимая, скажем, ядерный распад или влияние социальных сетей на ситуацию в конкретном регионе.
Так что, нравится нам это или нет, а «умное» программное обеспечение уже давно контролирует множество аспектов нашей жизни. Сбой в его работе может иметь для человечества весьма неприятные – если не сказать катастрофические – последствия. Остаётся надеяться, что в будущем компьютерные ошибки не станут причиной жертв, сравнимых с теми, что уже пережила планета Земля в прошлом. Предлагаем Вашему вниманию 6 наиболее примечательных случаев компьютерной «халатности».
Космический глюк
Гибель ракеты Ariane 5
4 июня 1996 года Европейское космическое агентство запустило ракету-носитель семейства Ариан, предназначенную для выведения полезной нагрузки на низкую опорную орбиту. Ракета, стартовавшая с космодрома Куру во Французской Гвиане, через 37 секунд после взлёта взорвалась в воздухе, засеяв окрестности обломками. К счастью, никто не пострадал. Специалисты подозревали утечку топлива или проблемы с электроникой. Но всё оказалось гораздо прозаичнее: ошибка в программном обеспечении модуля управления привела к самоуничтожению ракеты. Миллионы евро сгорели в воздухе из-за ошибки в коде.
Сбой стоимостью миллиард долларов
Разорение Knight Capital
В 2013 году капитализация крупной инвестиционной компании Knight Capital составляла несколько миллиардов долларов. Она заслуженно считалась одной из самых успешных инвестиционных групп в США. Тем не менее, всего за полчаса её финансовый успех превратился в воспоминание: сбой компьютерной программы полностью разорил компанию. Компьютеры начали неконтролируемо покупать и продавать миллионы акций, пока трейдеры беспомощно стучали по клавишам. За феерически короткое время Knight Capital потеряла полмиллиарда долларов. Итогом сбоя стало падение акций компании на 75% – всего за 2 дня перспективная фирма практически полностью разорилась.
Программная медицинская ошибка
Сбой в установке Therac-25
В 80-ых годах прошлого века минимум 6 пациентов один за другим скончались от получения большой дозы рентгеновского излучения из аппарата для лучевой терапии Therac-25, применяемого в процессе лечения рака. Некоторые пациенты получили дозы в десятки тысяч рад – и всё из-за программной ошибки блока управления установки. Примечательно, что проблему не замечали в течение нескольких лет. Эксперты, изучившие систему, установили, что сбой был вызван ошибкой в коде, в результате которой программа пыталась выполнять одну и ту же команду многократно. Вместо облучения в медицинских дозах пациенты умирали от передозировки радиацией. Данная программная ошибка считается приведшей к одним из наихудших последствий по вине программного обеспечения за всю историю использования компьютеров.
Гроза в торговой сети
Отключение серверов Amazon
В августе 2014 года в течение 45 минут серверы Amazon – общеизвестного крупнейшего в мире сайта среди продающих товары и услуги через Интернет – были недоступны из-за отключения электричества. Изначально авария, вызванная сильной грозой, усугубилась многочисленными осложнениями в виде внезапно всплывших программных ошибок, в результате чего произошёл каскадный сбой. За время простоя сайт потерял около $5 млн. К счастью, сайт более чем серьёзно подходит к безопасности данных, так что рядовые пользователи не лишились ни денег, ни уже оплаченных, но ещё не доставленных заказов.
Электронная тьма
Массовое отключение электроэнергии на северо-востоке США
К чему может привести маленькая, незаметная и незамеченная ошибка в программном обеспечении для мониторинга работы оборудования General Electric Energy? В 2003 году примерно треть штатов США остались без электроэнергии вообще. Света не было не только в домах граждан, но и в больницах, школах, на вокзалах. Не работали компьютеры в полицейских участках, не функционировали радары сил противовоздушной обороны, самолёты не могли подняться со взлётных полос. Хуже того: умолкли диспетчерские вышки, и несколько страшных часов самолёты, находящиеся в воздухе, не могли сесть. Глобальный каскадный сбой, вызванный неприметной ошибкой, послужил причиной одного из самых масштабных отключений электроэнергии в истории.
Массовое приземление
Приземление всех самолётов American Airlines
Из-за обнаруженной в 2013 году ошибки в программном обеспечении систем контроля полётов руководству авиаперевозчика American Airlines пришлось вернуть на землю абсолютно все свои самолёты. Сбой возник в системе бронирования билетов, когда в результате слияния нескольких авиакомпаний две существующие системы объединились в одну. Проблема с управлением полётами возникла после того, как попытка объединить платформы, написанные на разных языках программирования, провалилась.