Сбой (fault) – ситуация, когда работа одного из компонентов информационной системы отклоняется от ожидаемых характеристик. При этом вся система в целом продолжает функционировать.

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

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

Считается, что в крупной системе сбои так или иначе неизбежны, поэтому системы пишут и конфигурируют таким образом, чтобы они были устойчивы к сбоям (особенно некритичным).

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

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

• Если система развёрнута на одном сервере, то практикуется избыточность аппаратных ресурсов. Сюда относят как дополнительное железо, например, в виде жёстких дисков или процессоров с возможностью горячей замены, так и резервные источники электрического питания для ЦОДов и пр. Предполагается, что если какой-то компонент (например, жёсткий диск) выйдет из строя, то он будет оперативно заменён резервным компонентом. В случае отказа сервера, предполагается возможность быстро восстановить приложение на новой машине. Такой подход не способен обеспечить высокую доступность приложения, а также может быть неоптимальным с точки зрения утилизации вычислительных ресурсов, часть которых неизбежно будет простаивать длительное время.
• Если система спроектирована таким образом, чтобы нормально работать сразу на нескольких машинах (это необязательно микросервисная архитектура, монолиты без состояния – уже большой шаг навстречу), то это, с одной стороны, позволяет осуществлять балансировку нагрузки между машинами, с другой, повышает устойчивость системы в целом к аппаратным сбоям. Кроме того, такой подход позволяет более оптимально утилизировать доступные вычислительные ресурсы, а также позволяет очень гибко управлять процессом обновления системы.

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

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

Ошибки в программном обеспечении могут проявить себя:

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