Что такое отказоустойчивость системы

Отказоустойчивость

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

Отказоустойчивость связана со следующими техническими характеристиками систем:

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

Литература

См. также

Полезное

Смотреть что такое «Отказоустойчивость» в других словарях:

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

отказоустойчивость — 3.33 отказоустойчивость: Свойство системы продолжать правильное выполнение функций при наличии ограниченного числа аппаратных или программных дефектов. Источник: ГОСТ Р 51904 2002: Программное обеспечение встроенных систем. Общие требования к… … Словарь-справочник терминов нормативно-технической документации

отказоустойчивость — atsparumas gedimui statusas T sritis radioelektronika atitikmenys: angl. fault tolerance vok. Beständigkeit gegen Versagen, f; Fehlertoleranz, f rus. отказоустойчивость, f pranc. tolérance des pannes, f … Radioelektronikos terminų žodynas

отказоустойчивость — отказоуст ойчивость, и … Русский орфографический словарь

ОТКАЗОУСТОЙЧИВОСТЬ — свойство компьютерной системы после возникновения какой либо неисправности в ее аппаратном или программном компонентах продолжать работу без вмешательства человека, обеспечивать непрерывность работы, целостность данных и восстановление работы в… … Словарь понятий и терминов, сформулированных в нормативных документах российского законодательства

отказоустойчивость — отказ/о/у/стой/чив/ость/ … Морфемно-орфографический словарь

отказоустойчивость системы управления техническими средствами корабля — отказоустойчивость СУ ТС Составляющая качества структурной организации системы управления техническими средствами корабля, проявляющаяся при отказах отдельных устройств, сбоях в их работе и (или) проявлении ошибок в программном обеспечении и… … Справочник технического переводчика

отказоустойчивость (в информационных технологиях) — Способность ИТ услуги или конфигурационной единицы продолжать обеспечивать эксплуатирование корректно после сбоя части компонента. [http://www.dtln.ru/slovar terminov] отказоустойчивость (ITIL Service Strategy) Способность ИТ услуги или другой… … Справочник технического переводчика

отказоустойчивость гидротехнического сооружения — Способность гидротехнического сооружения препятствовать возникновению неисправностей и отказов, которые могут привести к аварии, и обеспечивать его защищенность от неблагоприятных воздействий окружающей среды, ошибок эксплуатационного персонала и … Справочник технического переводчика

отказоустойчивость программного средства — Совокупность свойств программного средства, характеризующая его способность поддерживать необходимый уровень пригодности при проявлении дефектов программного средства или нарушении установленных интерфейсов. Примечание Необходимый уровень… … Справочник технического переводчика

Источник

Отказоустойчивые системы: зачем нужны и как построить

Методы построения отказоустойчивых систем

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

Примеры систем с различными значениями вероятностей безотказной работы

Источник: G. Candea, «Principles of Dependable Computer Systems». Stanford University, 2003

Способы построения отказоустойчивых систем

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

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

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

Временная избыточность (Time Redundancy) заключается в использовании некоторой части производительности компьютера для контроля за исполнением программ и восстановления (рестарта) вычислительного процесса (запас времени для повторного выполнения операции (например, двойного или тройного просчёта на вычислительной машине).

Наглядным примером введения многоуровневой избыточности в систему, для достижения отказоустойчивости, может послужить система контроля и управления авиалайнера Airbus 320 (fly-by-wire flight control system). В процессе функционирования системы управления, и обеспечения взаимосвязей между различными компонентами и контроля за последними, в Airbus 320 задействовано 5 различных независимых компьютеров. Система управления авиалайнером строилась из расчета, что обнаружение ошибок должно осуществляться как в аппаратной, так и в программной части системы. По этой причине, в процессе управления полетом, дополнительно задействовано два типа программного обеспечения, от двух независимых разработчиков.

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

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

Источник

Отказоустойчивые ИТ-системы: принципы построения

Чтобы разобраться в том, как реализуется отказоустойчивость ИТ-систем, как она определяется, из чего складывается и на что влияет, лучше подойти к рассмотрению этого понятия с точки зрения обеспечения непрерывности бизнеса. В настоящее время прослеживается явная тенденция ужесточения требований к информационным системам, обеспечивающим непрерывность бизнеса, и тому есть простое объяснение — цена минуты простоя такой информационной системы с каждым годом увеличивается экспоненциально. При этом быстро растет и число ИТ-систем, которые обслуживают непрерывные бизнес-процессы, и, следовательно, тоже должны функционировать в непрерывном режиме.

Перечислим факторы, влияющие на непрерывность функционирования любой ИТ-системы:

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

Инженерные системы ЦОДа

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

Административно-организационное обеспечение

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

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

Средства безопасности

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

Средства контроля и управления ИТ-инфраструктурой и ПО

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

Реализация механизма создания резервных копий

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

Определение отказоустойчивости

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

Механизмы реализации отказоустойчивости

В настоящее время единственным механизмом обеспечения отказоустойчивости ИТ-системы является избыточность входящих в нее компонентов. Рассмотрим как реализуется отказоустойчивость на компонентных уровнях.

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

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

Примером кластерного ПО для обеспечения отказоустойчивости программного обеспечения может служить Veritas Cluster Service. Данный продукт имеет богатый функционал для построения зависимостей между разными уровнями ресурсов кластера, расширенные средства диагностики и определяемый набор политик для переноса нагрузки с отказавшего узла кластера на корректно функционирующие узлы.

Другой пример реализации механизма отказоустойчивости ПО — серверная виртуализация.

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

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

Отказоустойчивость аппаратного обеспечения ИТ-системы на уровне отдельного устройства. Аппаратная отказоустойчивость отдельного устройства обеспечивается избыточностью наименее надежных его компонентов. Например, сервер может иметь несколько дополнительных блоков питания и вентиляторов охлаждения, при этом условия, когда он оказывается неработоспособным, определяются реализованной схемой избыточности тех или иных компонентов. Наиболее распространены схемы N+1 (избыточным является только один компонент в подсистеме, и, соответственно, допускается отказ только одного такого же компонента) и 2N (двукратная избыточность, допускающая выход из строя половины установленных в функциональном блоке идентичных компонентов).

Аппаратная отказоустойчивость устройства обеспечивается его производителем. Возможности настройки в этом случае, как правило, минимальны, а внесение изменений в схему реализации отказоустойчивости возможно только производителем через обновление микрокода аппаратного устройства.

Отказоустойчивость отдельных модулей внутри устройства. Обеспечение отказоустойчивости на уровне отдельных модулей распространено, в частности, при организации хранения данных, причем как оперативного, так и долговременного, и так же основано на избыточности отдельных аппаратных компонентов: жестких дисков и (значительно реже) модулей оперативной памяти. Обычно в таких случаях пользователь аппаратного устройства сам ищет разумный компромисс между отказоустойчивостью и производительностью модуля, а также риском потери данных и стоимостью их хранения. При этом схема реализации отказоустойчивости выбирается из жестко заданных производителем оборудования вариантов. Вместе с тем варианты здесь могут быть самые разные. Применяются схемы N+1, N+2, 2N, а также множество производных схем, заданных производителем в виде шаблонов. Стоит также отметить, что такого рода решения могут предусматривать автоматическое устранение отказа через некоторый период времени.

Во избежание потери данных отказоустойчивость отдельных модулей хранения реализуется во всех системах корпоративного класса. Для ИТ-персонала компаний это не представляет особой сложности, но для правильного выбора схемы обеспечения отказоустойчивости RedSys рекомендует использовать проектный подход.

Катастрофоустойчивое решение

В редких случаях причиной утраты работоспособности ИТ-системы может стать отказ ЦОДа в целом в результате локальной или глобальной катастрофы. Стоимость катастрофоустойчивого решения весьма значительна, поскольку требует дублирования функционала ЦОДа на географически удаленной площадке. При этом используют два разных подхода. Первый предполагает практически полное воспроизведение функционала защищаемого ЦОДа на удаленной площадке с той же или, как вариант, с несколько меньшей производительностью. В случае отказа основного ЦОДа его функции берет на себя резервный. Факторами риска в данном случае являются административный ИТ-персонал, который должен своевременно принять решение о переносе сервисов на другую площадку, и наличие отработанного регламента для успешного выполнения этой операции. Во время переноса нагрузки в резервный ЦОД предоставляемые сервисы могут быть временно недоступны. Существует также риск потерять некоторый объем данных, определяемый тем, как организована репликация данных между ЦОДами. Данный подход к обеспечению катастрофоустойчивости ИТ-систем базируется на нескольких кластерах, объединенных в так называемый метрокластер.

Второй подход предполагает обеспечение сохранности данных, то есть в случае отказа основного ЦОДа на удаленной площадке остаются невредимыми резервные копии и/или реплики данных с СХД основного ЦОДа. Это менее дорогое решение, поскольку на удаленной площадке создается только избыточная часть системы резервного копирования или часть системы хранения данных. Оно не защищает полностью от отказа ЦОДа, но позволяет свести к минимуму риск потери данных.

Автор статьи — Алексей Амосов, директор департамента программно-аппаратных комплексов RedSys.

СПЕЦПРОЕКТ КОМПАНИИ REDSYS

Источник

Построение отказоустойчивой (fault tolerant) системы

В разработке банковского ПО данному аспекту системы уделяется наибольшее внимание. Часто, описывая отказоустойчивую систему, используют слова: Fault Tolerance, Resilience, Reliability, Stability, DR (disaster recovery). Данная характеристика — суть способность системы продолжать корректно работать при падении одной или нескольких подсистем, от которых она зависит. Я кратко опишу какие подходы могут применяться в данной области и приведу пару примеров.

Сразу прошу меня просить, что некоторые вещи будут специфичны только для java, но все же, по большому счету все нижеописанное применимо к любой платформе, поэтому топик и помещен в эту тему.

С чего начать?

Прежде всего нужно хорошо знать архитектуру вашего приложения, охватывать взглядом весь стек вашей системы — от софта до железа.

Так же можно посмотреть в сторону такой вещи как fault tree analysis. Это когда вы строите диаграмму ваших компонент в виде дерева зависимостей, и снизу вверх начинаете проставлять кумулятивную вероятность падения ваших компонентов. На этой диаграмме будет хорошо видны самые уязвимые места, которые потенциально могут принести самый большой ущерб.

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

Способы реализации

Есть два принципиально разных подхода, хотя они вполне могут независимо или полузависимо сочетаться для вашей системы. Один подход — это DR (disaster recovery), когда полная копия всей вашей системы может быть поднята в другом датацентре. Данный метод выручает практически в любой ситуации, однако, он может имеет очень длительный промежуток простоя. Я знаю одну систему, в которой это занимает в районе часа. Но тут тоже надо быть очень аккуратным, не только конфигурация системы, но и железо в DR должны совпадать с продакшеном. Например, когда мы тестировали DR, в одной из систем с которыми я работал, то у нас при сильной нагрузке оказалось, что один из компонентов заточен на работу в однопоточной среде и его пропускная способность пропорциональна частоте процессора, а на DR у нас была мега железка с огромным количеством ядер, но с небольшой тактовой частотой, так что этот компонент стал затыкаться. Вобщем, тест был весьма неудачен и «более клевое» железо на текущей конфигурации нашей системы нам явно не подходило.

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

low level fault tolerant services

Принцип тут следующий — ваша система должна состоять из более менее независимых систем каждая из которых должна быть отказоустойчивой. В идеале не изобретать велосипед, а использовать уже готовые решения. Это на самом деле наилучший вариант, когда вся ваша система будет опираться на так называемые low level fault tolerant services.

Single point of failure

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

Избыточность (Redundancy)

Это когда в вашей системе присутствует избыточное количество необходимых вам компонент. И при падении одного из таких избыточных компонент, все должно продолжать работать. При таком подходе проектирования можно выделить две стратегии: active-active и active-passive.

Active-Active

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

Active-Passive

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

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

Балансировка нагрузки (Load Balancing)

Обычно этот термин всплывает при построении высоконагруженных систем. Однако для отказоустойчивых систем данный принцип тоже можно применить. Идея в том, что у вас есть несколько идентичных компонентов, между которыми более менее равномерно распределяется вся нагрузка. В отличие от вышеописанной active-active стратегии, здесь каждую задачу выполняет только один компонент. Данный механизм идеально подходит для stateless компонент, иначе для отказоустойчивости вам постоянно придется синхронизировать состояние. Например в случае веб-серверов — делать репликацию сессии. В данном решении очень важно иметь как минимум N+1 redundancy, т.е. если для пиковых нагрузок вам необходимо N работающих на всю катушку компонент, то в вашей системе должно присутствовать N+1 таких компонент, так как иначе, если у вас упадет один из элементов, то на все остальные нагрузка увеличиться и вся ваша система рухнет как домино.

Самый распространенный пример load balancing — это, наверное, балансирование нагрузки веб-серверов. Тут бывают как программные решения (Nginx), так и специальные железки. В backend системах load-balancing часто используют для реализации балансирования реализуют при помощи JMS очереди, вешая на не неё несколько идентичных слушателей. В данном случае очередь гарантирует, что сообщение попадет только в один из компонентов, и пока он его не обработает, следующее сообщение он взять не сможет. Кстати в такой же системе, если в качестве очереди взять topic, то можно реализовать active-active систему.

Защитное программирование (Defencive coding)

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

Infinite Loop. Следите за тем, чтобы при возникновения ошибки во время обработки сообщения, вы не выходили в бесконечный цикл, который постоянно пытается выполнить данную операцию, особенно если сообщение приходит вам извне, и вы не можете гарантировать, что оно корректно. Я уже ни один раз видел, как из-за этой ошибки подвисает вся система. Что же в этом случае делать? Например, можно отправлять сообщение об ошибке в систему мониторинга (см. ниже) и переходить к обработке следующего таска.

Reconnection. Обязательно пишите логику реконнекта, особенно в системах с наличием firewall.

Degradate gracefully. Throttling. Если ваше приложение получает извне сообщения, то обязательно подумайте, что вы будете делать, если вам будет приходить сообщений много больше, чем вы можете обработать. Например, вы можете начинать реджектить запросы или эмулировать медленный коннекшен, замедляя отсылку ответа.

State Management. Попытайтесь сделать так, чтобы ваша система время от времени сохраняла свое состояние (checkpoint), чтобы в случае больших проблем вы всегда могли откатиться в последние консистентное состояние. Например, в FIX протоколе, распространенном в финансовых приложениях, есть понятие sequence. Каждое сообщение имеет свой порядковый номер, сервер запоминает номер последнего отосланного сообщения, а клиент запоминает номер последнего принятого сообщения. На рестарте они обмениваются данными номерами, и если между ними есть промежуток, то сервер высылает все пропущенные сообщения.

InfrastructureError. Если в вашем приложении произошла ошибка, из которой вы не можете восстановиться, например OutOfMemoryError в java, то можно попробовать остановить приложение и запустить его заново. Это можно автоматизировать с помощью такой тулзы как Tanuki Java Service Wrapper, о данной функции которого я подробно писал тут.

NullPointerException. Однако, не надо сходить с ума, проверяя каждый входной параметр метода или конструктора на null. Лучше примите за правило: никогда не передавать в системе null между компонентами.

Изоляция инфраструктуры

Совместное использование железа вашей системы с какими бы то еще ни было приложениями очень опасно. Еще его называют принципом студенческой кухни (student kitchen), если кто-то что-то там делает, то это не может не повлиять на других людей, пользующихся теми же вещами. Самое неприятное, что данные случае очень сложно определить, если анализ проводить не сразу, а спустя определенное время. Примеров данной проблемы можно привести множество. Например, третье приложение начало активно использовать оперативную память — таким образов ваши процессы начали свопиться и производительно вашей системы жутко деградирует. Или третья система начала активно использовать жесткий диск, а вы пишите логи синхронно, в этом случае ваше приложение опять сильно замедлиться. Переполнение жесткого диска третьими системами и забивка канала связи — тоже возможные проблемы, правда они могут возникнуть и в случае когда железо используется только вашей системой, просто она состоит из большого количества процессов. Например, очень распространенный случай того как приложения написанные на java влияют друг на друга — это параллельный сборщик мусора. Когда в одном из компонентов он срабатывает, то по-умолчанию он использует все доступные CPU ресурсы на полную катушку, так что если у вас на этой же машине крутится приложение требующее быстрого отклика, то данная проблема не надумана. Хотя количество доступных потоков для сборки мусора всегда можно ограничить специальным флагов при запуске JVM.

Мониторинг

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

Для мониторинга существует множество готовых решений (Triton, Nagious), как платных так и open-source. Стандартные функции — это мониторинг диска, оперативной памяти, процессоров и трафика. Так же бывают различные плагины, которые позволяют мониторить лог файлы и при появлении там ошибок отсылать сообщение в систему мониторинга.

Не смотря на наличие готовых решений, банки почему-то разрабатывают свои собственные решения. Однако они уже больше заточены на получение сообщений посланных программно из внутренних приложений. Например, если по какой-то причине некая back-end система не смогла обработать ордер, то в описанную систему мониторинга можно отослать сообщения со всеми деталями ордера, чтобы support смог ввести детали ордера вручную.

Еще одна разновидность мониторинга — это health monitor, когда ваше приложение шлет специальные heartbeat, и если в течении определенного интервала времени от приложения ничего не было слышно, то в системе трекинга всплывает сообщение о неисправности.

Problem Management

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

Источник