Аварии в интеграциях: как пережить отказ одной или нескольких связанных систем для бизнеса?

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

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

Причина в том, что интеграция – не просто соединение двух систем проводом, который либо есть, либо его нет. Это постоянный обмен данными, где каждая сторона чего-то ждёт от другой и строит на этом ожидании свою работу. Когда ожидание не оправдывается, последствия не остаются в точке сбоя: они распространяются дальше, как круги по воде.

Запросы, не получившие ответа, накапливаются, очередь обработки растёт, ресурсы, рассчитанные на нормальный ритм, заканчиваются быстрее. И вот уже система, которая формально работает, начинает отвечать медленно, а затем и вовсе перестаёт справляться – не потому, что в ней самой что-то сломалось, а потому, что её сосед перестал отвечать вовремя.

Именно поэтому устойчивость интеграции – это отдельная характеристика, которую нужно проверять и о которой нужно договариваться заранее. Устойчивость не означает отсутствие сбоев: сбои случаются у всех, и никакая система от них не застрахована.

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

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

Почему сбой одной системы ломает другую?

На первый взгляд связь между двумя системами устроена просто: одна отправляет данные, другая их принимает. Пока всё идёт по плану, эта простота не вызывает вопросов. Сложности начинаются в тот момент, когда принимающая сторона перестаёт отвечать так, как от неё ждут.

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

Главная причина, по которой сбой одной системы задевает другую, – это ожидание. Любая связка построена на том, что сосед ответит в разумные сроки. Когда ответа нет, отправитель не может просто забыть о запросе: он должен решить, что делать дальше, и любое решение имеет последствия.

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

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

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

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

Хранилище, в которое пишутся незавершённые данные, заполняется и замедляет чтение. Канал, по которому идут повторные попытки, оказывается перегружен, и страдают все, кто им пользуется. В результате система, которая сама не сбоила, начинает испытывать трудности из-за того, что делит ресурсы с проблемным соседом.

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

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

Типичные сценарии аварий

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

Сценарий 1. Соседняя система молчит

Это самый очевидный случай: система отправила запрос и не получила никакого ответа. Не ошибку, не отказ, а именно тишину. С точки зрения отправителя это самое неприятное состояние, потому что непонятно, что произошло на другой стороне.

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

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

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

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

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

Сценарий 2. Соседняя система отвечает ошибкой

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

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

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

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

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

Если сообщение говорит «попробуйте позже», но не уточняет, когда именно и сохранились ли его данные, доверие к продукту падает. Поэтому обработка ошибок – это не только техническая задача, но и вопрос того, что видит и чувствует пользователь в момент сбоя.

Сценарий 3. Соседняя система отвечает, но медленно

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

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

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

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

Как выглядит устойчивая интеграция?

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

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

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

Сохранение работоспособности: не зависнуть, не потерять, не напугать

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

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

Ограничение последствий: сбой в одном месте не останавливает всё

Вторая составляющая отвечает на вопрос, насколько далеко распространяется влияние сбоя. В связанной системе всегда есть соблазн устроить всё так, что одна операция ждёт другую, та ждёт третью, и в итоге любая задержка на одном конце цепочки останавливает работу на другом. Устойчивая интеграция так не устроена: сбой в одной связке не должен приводить к остановке всей системы.

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

Восстановление: вернуться к норме без ручного вмешательства

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

Восстановление включает несколько аспектов. Накопленные запросы должны быть обработаны, а не потеряны. Данные, которые не удалось передать в момент сбоя, должны быть доставлены, когда связь восстановится. Очереди должны разгрузиться, а не остаться переполненными на неопределённое время.

И, что немаловажно, система должна вернуться к тому же уровню производительности, который был до сбоя, а не остаться в полусобранном состоянии, где часть возможностей недоступна навсегда. Если после каждого сбоя требуется ручная «починка», это признак того, что устойчивость не заложена в систему, а поддерживается усилиями людей, которые рано или поздно закончатся.

Что проверить на случай аварии?

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

Юридические вопросы, которые стоит закрепить в договоре с подрядчиком

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

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

Это точка отсчёта: если после запуска поведение окажется другим, будет с чем сравнивать. К этому же блоку примыкает вопрос о времени ожидания – стоит зафиксировать, через какой срок система перестаёт ждать ответа и переходит к запасному сценарию. Без этого числа любые споры о том, «долго ли ждала система», остаются вопросом вкуса.

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

• сохраняются ли данные при прерывании операции;
• могут ли они задвоиться при повторной отправке;
• кто отвечает за сверку после восстановления.

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

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

Ещё один пункт, который часто обходят стороной, – ответственность за последствия. Кто разбирается, если данные потерялись, если операция выполнилась дважды, если сбой одной связки остановил работу остальных. Это не вопрос поиска виноватого, а вопрос о том, кто и за чей счёт устраняет последствия.

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

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

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

Как проверить устойчивость интеграции перед приемкой?

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

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

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

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

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

Отдельного внимания заслуживает медленный ответ. Этот сценарий коварен тем, что формально всё работает, и именно поэтому его часто пропускают. Достаточно искусственно замедлить ответы соседа в несколько раз и посмотреть, как поведёт себя система: начнут ли накапливаться запросы в очереди, вырастет ли время ожидания для операций, которые сами по себе не были проблемными, и где находится тот порог, за которым замедление переходит в отказ. Хорошая проверка показывает не только то, что система «выдержала», но и то, при каком уровне замедления она начинает сдавать, – это даёт представление о запасе прочности.

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

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

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

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

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

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

Отчет о проверке устойчивости интеграции

• Смотрите, какие сценарии сбоя проверялись. В отчёте должны быть перечислены все три сценария: молчание соседа, ответ ошибкой и медленный ответ. Если какого-то из них нет, устойчивость проверена не полностью.
• Проверяйте, что происходило с данными в каждом случае. По каждому сценарию должно быть указано, сохранились ли данные, не задвоились ли они, не потерялись ли операции, которые были в процессе выполнения. Общая фраза «данные в порядке» без привязки к сценарию – повод уточнить.
• Ищите, что видел пользователь в момент сбоя. В отчёте должно быть описано сообщение или поведение экрана: понятно ли, что произошло, сохранились ли данные, что делать дальше. Если этого нет, значит, проверяли только технику, а не опыт человека.
• Смотрите, как система восстанавливалась. Должно быть указано, сколько времени заняло возвращение к нормальной работе и потребовалось ли ручное вмешательство. Если в отчёте сказано «восстановление прошло успешно», но не уточнено, чьими руками, — это неполная картина.
• Проверяйте, ограничивались ли последствия. В отчёте должно быть видно, что при отключении одной связки остальные операции продолжали работать. Если этого не проверяли, сбой одной связки может остановить всё.
• Смотрите, какие сбои остались непроверенными. Хороший отчёт честно перечисляет, что не проверялось и почему: не было времени, не было доступа, сценарий сочли маловероятным. Отсутствие такого списка – признак того, что отчёт приукрашен.
• Обращайте внимание на условия проверки. Должно быть указано, на какой среде проводились замеры и насколько она близка к рабочей. Если условия не описаны или заметно отличаются от реальной эксплуатации, к результатам стоит относиться с осторожностью.
• Проверяйте, есть ли цифры, а не только оценки. В отчёте должны быть конкретные значения: через сколько секунд система перестала ждать, при каком замедлении начались сбои, сколько времени заняло восстановление. Формулировки вроде «система показала устойчивость» без цифр ничего не доказывают.
• Смотрите, различается ли источник ошибки. В отчёте должно быть видно, на какой стороне возникла проблема в каждом сценарии: у отправителя, у получателя или в самой связке. Если все сбои описаны одинаково, разобраться в реальной аварии будет сложно.
• Проверяйте, повторялись ли сбои. Если система проверялась только на одном коротком сбое, неизвестно, как она поведёт себя при серии сбоев подряд. В отчёте должно быть указано, проводилась ли такая проверка.

Разработка ПО от 66 Бит

Сегодня мы разобрали как позитивные, так и негативные сценарии аварий в интеграциях систем для бизнеса, ну а если вы хотите быть уверенными в качестве устойчивости своих интеграций, советуем обратиться в 66 Бит!

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