LINUX.ORG.RU

История изменений

Исправление KivApple, (текущая версия) :

Абсолютно надёжных систем не существует. При проектировании любой реально надёжной системы в спецификациях всегда присутствует список возможных сбоев и для каждого уровня severity их максимально допустимое количество на единицу времени эксплуатации системы. Например, если мне не изменяет память, самолётам допускается падать с вероятностью 1^10-6 на час полёта по какое-то индустриальному стандарту.

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

То есть можно потратить в сотню раз больше денег, чтобы уменьшить в 10 раз вероятность того, что в коде есть ошибка. А можно потратить в 3 раза больше денег и сделать три независимые системы. Вероятность того, что во всех них есть ОДНА И ТА ЖЕ ошибка, будет точно также примерно в 10 раз меньше. А между тем сэкономленное можно пустить на повышение надёжности других частей системы, денег мало никогда не бывает.

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

Да, всякое случается. Но самолёты летают, GPS работает, а по Марсу ездят марсоходы. А если бы добивались 100% надёжности, то до сих пор сидели бы в пещерах.

Исходная версия KivApple, :

Абсолютно надёжных систем не существует. При проектировании любой реально надёжной системы в спецификациях всегда присутствует список возможных сбоев и для каждого уровня severity их максимально допустимое количество на единицу времени эксплуатации системы. Например, если мне не изменяет память, самолётам допускается падать с вероятностью 1^10-6 на час полёта по какое-то индустриальному стандарту.

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

То есть можно потратить в сотню раз больше денег, чтобы уменьшить в 10 раз вероятность того, что в коде есть ошибка. А можно потратить в 3 раза больше денег и сделать три независимые системы. Вероятность того, что во всех них есть ОДНА И ТА ЖЕ ошибка, будет точно также примерно в 10 раз меньше. А между тем сэкономленное можно пустить на повышение надёжности других частей системы, денег мало никогда не бывает.

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