Планирование обеспечения непрерывности бизнеса чаще всего терпит неудачу не во время кризиса, а на этапе оценки, предшествующем ему. Организации проводят анализ влияния на бизнес, документируют целевые показатели времени восстановления, разрабатывают комплексные сценарии восстановления, а затем в самый неподходящий момент обнаруживают, что, казалось бы, некритичная устаревшая служба аутентификации является единой точкой отказа для всей их платформы электронной коммерции, что пакетная программа COBOL, которую все считали низкоприоритетной, передает данные в службу проверки платежей в реальном времени, или что два приложения, которым назначен один и тот же уровень восстановления, имеют недокументированную зависимость, которая делает последовательное восстановление невозможным. Оценка была проведена. Зависимости — нет.
Оценка критичности приложений — это процесс присвоения количественной или многоуровневой меры важности каждому приложению в портфеле организации. Эта мера определяет приоритет восстановления, уровень инвестиций в резервирование, требования к управлению изменениями и его место в последовательности аварийного восстановления. Когда эта оценка основана исключительно на опросах о влиянии на бизнес и интервью с владельцами приложений, она отражает то, что люди думают о функциях приложений. Когда же она основана на структурном анализе того, что приложения делают на самом деле, кто с кем связывается, какие потоки данных проходят через какие программы, какие общие компоненты находятся на критическом пути нескольких систем с более высоким приоритетом, она отражает операционную реальность.
Именно разрыв между убеждениями и реальностью является причиной сбоев в планах обеспечения непрерывности бизнеса.
Последовательности восстановления, отражающие фактические зависимости
SMART TS XL определяет каждую программу на критическом пути ваших приложений первого уровня — на всех языках программирования из вашего портфолио.
УЗНАТЬ БОЛЬШЕ…Что на самом деле измеряет оценка критичности приложения?
Критичность — это не одномерное понятие. Для определения критичности корпоративного приложения можно учитывать пользовательские данные, позволяющие оценить критичность или важность приложения, включая его наибольшее влияние на стратегические потребности бизнеса, влияние на деловых партнеров, взаимодействие с клиентами и влияние на другие корпоративные приложения. Каждое из этих измерений отражает различные аспекты того, что означает «критичность»:
Влияние на бизнес — это потери организации за каждый час простоя. Наиболее наглядным аспектом является потеря доходов: система обработки платежей, обрабатывающая 10 миллионов долларов в час, имеет измеримые затраты за каждую минуту простоя. Но влияние на бизнес выходит за рамки потери доходов и включает в себя регуляторные риски (какие обязательства по соблюдению нормативных требований влечет за собой простой?), ущерб репутации (затрагивает ли это непосредственно клиентов?) и договорные штрафы (влечет ли за собой соглашение об уровне обслуживания штрафные санкции?).
Операционная зависимость — это количество других систем или процессов, зависящих от данного приложения. Приложение с низким прямым влиянием на бизнес может иметь высокую критичность, поскольку оно находится в пути зависимостей приложений с высоким прямым влиянием. Служба аутентификации, обеспечивающая работу всех остальных приложений, взаимодействующих с клиентами, более критична, чем это следует из её собственной функции.
Сложность восстановления — это то, насколько сложно и долго восстанавливать приложение. Приложение со средним влиянием на бизнес и временем восстановления в 48 часов может потребовать больших инвестиций в резервирование, чем приложение со значительным влиянием на бизнес и временем восстановления в 2 часа, поскольку общий риск простоя выше.
Регуляторные обязательства , определяющие, какие приложения подлежат требованиям непрерывности работы в соответствии с нормативными актами. Финансовые учреждения, подпадающие под действие DORA, должны продемонстрировать, что критически важные функции могут выдерживать определенные сценарии сбоев. Медицинские организации, подпадающие под действие HIPAA, должны обеспечивать доступность систем, содержащих защищенную медицинскую информацию. Регуляторный аспект может иметь приоритет над оценкой влияния на бизнес для конкретных приложений.
Показатель критичности представляет собой совокупность всех четырех параметров, взвешенных с учетом допустимого уровня риска конкретной организации, нормативно-правовой среды и бизнес-модели.
Стандартные уровни критичности
В большинстве корпоративных портфелей приложений используется четырехуровневая модель критичности. Категории критичности в матрице критичности приложений включают: критически важные для миссии, критически важные для бизнеса, операционные и административные. Приведенные ниже определения отражают текущую отраслевую практику, соответствующую стандарту ISO 22301 (Системы управления непрерывностью бизнеса) и рекомендациям Института непрерывности бизнеса по передовой практике:
Приложения первого уровня, критически важные для выполнения основных бизнес-процессов, отказ которых немедленно останавливает основные бизнес-операции или создает неприемлемый риск с точки зрения регулирования или безопасности. Целевое время восстановления (RTO): обычно 0-4 часа. Целевая точка восстановления (RPO): обычно 0-1 час. Примеры: основные системы обработки банковских транзакций, системы торговли в реальном времени, системы аварийного диспетчерского управления, интерфейсы промышленного управления, системы авторизации платежей. Эти приложения оправдывают самые высокие инвестиции в инфраструктуру: активно-активное резервирование, репликация с нулевым RPO, автоматическое переключение при сбое и наиболее строгий контроль изменений.
Второй уровень — критически важные для бизнеса приложения, сбой которых существенно нарушает бизнес-процессы, но не приводит к их немедленной остановке. Целевое время восстановления: обычно 4–24 часа. Целевая точка восстановления: обычно 1–4 часа. Примеры: CRM-системы, модули ERP, системы управления заказами, системы управления персоналом в периоды начисления заработной платы, системы отчетности в периоды подачи отчетности в регулирующие органы. Для этих приложений оправдано наличие высокодоступной инфраструктуры, регулярного тестирования отказоустойчивости и приоритетной последовательности восстановления.
Третий уровень: бизнес- приложения, поддерживающие операционную деятельность компании, временная недоступность которых может быть устранена с помощью ручных обходных решений. Целевое время восстановления: обычно 24-72 часа. Целевое время точки восстановления: обычно 4-24 часа. Примеры: внутренние инструменты для совместной работы, отчетность, не предназначенная для взаимодействия с клиентами, административные порталы, платформы для обучения. Подходят стандартные процедуры резервного копирования и восстановления.
Уровень 4, административные приложения, поддерживающие административные функции и не оказывающие прямого влияния на операционную деятельность. Целевое время восстановления: обычно 72+ часа. Целевая точка восстановления: 24+ часа или время последнего резервного копирования. Примеры: внутренние вики-системы документации, некритичные инструменты разработки, историческая отчетность. Восстановление из резервной копии осуществляется по мере необходимости.
Присвоение уровня не является постоянным. Приложение, которое большую часть года находится в 3-м уровне, может перейти во 2-й уровень во время закрытия финансового месяца, периодов подготовки нормативной отчетности или пиковых сезонов торговли. Динамическая критичность, при которой присвоение уровня меняется в зависимости от операционного календаря, — это усовершенствование, которое организации со зрелыми программами обеспечения непрерывности бизнеса внедряют после установления базовой структуры уровней.
Методология оценки: перевод параметров в числовые значения.
Структурированная методология оценки преобразует четыре параметра критичности в числовой балл, который определяет уровень приоритетности объективно, а не на основе организационной политики. Предложенный ниже подход позволяет получить сводную оценку от 0 до 100 с использованием взвешенных критериев:
Измерение 1: Влияние на бизнес (вес: 35%)
| Влияние простоя на выручку в зависимости от часа простоя | Счет |
|---|---|
| > 1 млн долларов в час | 35 |
| 100 000–1 000 000 долларов в час | 28 |
| 1000–100 000 долларов в час | 21 |
| 1000–10 000 долларов в час | 14 |
| < 1 долларов в час | 7 |
| Прямого влияния на выручку нет. | 0 |
Влияние нормативных требований (DORA, HIPAA, PCI-DSS, обязательства по соблюдению требований SOX, возникающие в результате сбоя) добавляет к этому показателю до 10 дополнительных баллов.
Измерение 2: Операционная зависимость (вес: 30%)
| Встроенные приложения: Приложения, зависящие от данного приложения | Счет |
|---|---|
| > 20 зависимых приложений | 30 |
| 10-20 зависимых приложения | 24 |
| 5-9 зависимых приложения | 18 |
| 2-4 зависимых приложения | 12 |
| 1 зависимое приложение | 6 |
| Без иждивенцев (самостоятельно) | 0 |
В данном случае показатель «входящих зависимостей» — это количество структурных зависимостей, число приложений, которые обращаются к этому приложению, считывают его выходные данные или зависят от его данных, а не количество пользователей или предполагаемая важность. Этот параметр чаще всего неправильно рассчитывается в опросах, поскольку владельцы приложений не знают всех своих конечных потребителей.
Измерение 3: Сложность восстановления (вес: 20%)
| Расчетное время восстановления без предварительно созданной системы аварийного восстановления | Счет |
|---|---|
| > 72 часов | 20 |
| 24-72 часов | 16 |
| 8-24 часов | 12 |
| 2-8 часов | 8 |
| <2 часов | 4 |
| Автоматическое переключение на резервный сервер менее чем за 15 минут | 0 |
Аспект 4: Конфиденциальность данных и нормативные обязательства (вес: 15%)
| Классификация данных и нормативные требования | Счет |
|---|---|
| Регулируемая персональная идентификационная информация (PII) / медицинская информация (PHI) / информация о заболеваниях сердца (CHD) с четко определенным сроком восстановления. | 15 |
| Регулируемые данные без обязательства соблюдения определенного срока восстановления. | 12 |
| Конфиденциальные внутренние данные (коммерческая тайна, финансовые отчеты) | 9 |
| Внутренние оперативные данные | 6 |
| Неконфиденциальные внутренние данные | 3 |
| Данные не сохранены | 0 |
Сопоставление сводного балла с уровнями:
| Композитный счет | Назначение по уровням |
|---|---|
| 75-100 | Уровень 1, критически важный для выполнения миссии |
| 50-74 | Уровень 2, критически важный для бизнеса |
| 25-49 | Уровень 3, Операционная деятельность бизнеса |
| 0-24 | Уровень 4, Административный |
Проблема зависимости: почему оценка на основе опросов дает сбои.
Наиболее вероятная ошибка в расчетах – это операционная зависимость, и именно она влечет за собой самые серьезные последствия в случае неверного расчета. Казалось бы, некритичная устаревшая служба аутентификации может стать единой точкой отказа для всей платформы электронной коммерции, и ее сбой может остановить все транзакции, приносящие доход. Этот процесс выходит за рамки абстрактных угроз и переходит к конкретным, измеримым последствиям для соглашений об уровне обслуживания.
Владельцы приложений знают свои прямые зависимости от вышестоящих систем, к которым они обращаются. Однако они редко знают свои полные зависимости от нижестоящих систем, к которым они обращаются. Внутренняя служба аутентификации пользователей может считаться владельцем низкокритичной (она не приносит дохода, она проста, она редко дает сбои), в то время как от нее зависят двенадцать приложений, ориентированных на клиентов, которые все относятся к первому уровню. Фактическая критичность службы аутентификации относится к первому уровню не из-за ее собственной функции, а из-за ее положения в графе зависимостей систем более высокого уровня.
Систематическая ошибка при оценке критичности на основе опроса приводит к следующему. В опросе для владельцев приложений задается вопрос: «Насколько критично это приложение?» Владелец службы аутентификации отвечает «от низкой до средней», исходя из функциональности самой службы. Двенадцать зависимых владельцев приложений отвечают на этот опрос не о службе аутентификации, а о своих собственных приложениях. Взаимосвязь зависимостей никогда не фиксируется.
Последствия проявляются в последовательности восстановления: план обеспечения непрерывности бизнеса определяет порядок восстановления на основе оценок критичности, полученных в ходе опроса, и служба аутентификации планируется к восстановлению на уровне 3. Во время реального инцидента приложения уровня 1, которые должны восстановиться первыми, не могут этого сделать, поскольку служба аутентификации, от которой они зависят, не была восстановлена. Последовательность восстановления прерывается в точке наибольшей критичности зависимости.
Три типа зависимостей, которые постоянно упускаются из виду в ходе опросов:
Скрытые общие компоненты. Внутренняя программа на COBOL, обрабатывающая конвертацию валюты для трех отдельных бизнес-процессов, ни один из которых, согласно результатам опроса, не имеет общего компонента, представляет собой скрытую зависимость, влияющую на восстановление всех трех процессов. Если программа конвертации валюты относится к уровню 3, а любой из трех бизнес-процессов — к уровню 1, то эффективная критичность программы конвертации валюты соответствует уровню 1.
Зависимости в конвейере данных. Приложения, обрабатывающие пакетные данные из других приложений, имеют зависимость, которая носит временной, а не реальный характер. Риск заключается не в одновременных, а в последовательных сбоях: нижестоящее приложение восстанавливается, но его источник данных не восстанавливается до той же точки восстановления, создавая видимость корректной работы с устаревшими данными. Этот класс зависимостей не отображается на картах топологии сети или в анализе графов вызовов, если не отслеживается сам поток данных.
Зависимости от общей конфигурации и схемы. Приложения, использующие общие схемы баз данных, службы конфигурации или поставщиков идентификации, имеют неявную зависимость, даже если они никогда не обращаются друг к другу напрямую. Изменение схемы в общей базе данных может повлиять на несколько приложений. Восстановление одного приложения после повреждения схемы без восстановления всех приложений, использующих эту схему, приводит к несогласованному состоянию во всем портфеле приложений.
Интеграция плана обеспечения непрерывности бизнеса: как показатели критичности влияют на решения о восстановлении.
Показатель критичности является входными данными для шести конкретных проектных решений в рамках плана обеспечения непрерывности бизнеса:
1. Определение последовательности восстановления. Приложения восстанавливаются в порядке критичности: сначала 1-й уровень, затем 2-й, затем 3-й, но внутри уровня последовательность определяется графом зависимостей. Приложения, не имеющие входящих зависимостей (от которых не зависят другие приложения), могут восстанавливаться в любом порядке внутри своего уровня. Приложения с высоким уровнем входящих зависимостей должны восстанавливаться раньше своих зависимых приложений, независимо от их относительного рейтинга внутри уровня. Таким образом, последовательность восстановления определяется следующим образом: порядок уровней применяется к подпоследовательности, ограниченной зависимостями, внутри каждого уровня.
2. Установка целевых значений RTO и RPO. Показатель критичности калибрует целевые значения RTO и RPO. Максимально допустимое время простоя (MTD) и целевая точка восстановления (RPO) для каждого производственного приложения составляют техническую основу всей стратегии обеспечения непрерывности бизнеса. MTD — это максимальное время, в течение которого бизнес может допустить недоступность приложения. RTO должно быть меньше MTD. Разница между RTO и MTD — это буфер безопасности. Приложения первого уровня с высоким влиянием на бизнес в час простоя имеют узкие пределы MTD/RTO и требуют инфраструктуры, разработанной для быстрого автоматизированного восстановления.
3. Калибровка инвестиций в инфраструктуру. Показатели критичности напрямую влияют на решения об инвестициях в инфраструктуру аварийного восстановления. Для приложений первого уровня оправдана многорегиональная избыточность типа актив-актив. Для приложений второго уровня оправдана пассивно-активная избыточность с проверенным переключением при сбое. Для приложений третьего уровня оправдано регулярное резервное копирование с документированными процедурами восстановления. Для приложений четвертого уровня можно полагаться на стандартные политики резервного копирования. Без показателей критичности решения об инвестициях в инфраструктуру по умолчанию приводят либо к равномерному переинвестированию (дорого) или равномерному недоинвестированию (рискованно).
4. Требования к управлению изменениями. Приложения с более высокими показателями критичности требуют более строгого управления изменениями: более длительные периоды фиксации изменений, большее количество обязательных утверждающих лиц, более обширное предварительное тестирование, более консервативные процедуры отката. Применение управления изменениями уровня 1 к приложениям уровня 4 приводит к пустой трате времени инженеров. Применение управления изменениями уровня 4 к приложениям уровня 1 создает неприемлемый риск.
5. Частота тестирования и проверки. План обеспечения непрерывности бизнеса (BCP) требует периодического тестирования процедур восстановления, проведения настольных учений, тестирования переключения компонентов на резервный уровень и полномасштабных симуляций аварийного восстановления. Частота тестирования определяется показателями критичности: приложения уровня 1 требуют ежеквартальных тестов аварийного восстановления; приложения уровня 4 — ежегодных тестов. Тестирование каждого приложения с одинаковой частотой нецелесообразно и не является необходимым.
6. Требования SLA поставщика. Для приложений, зависящих от услуг сторонних поставщиков, оценка критичности определяет требования SLA, которые должны быть включены в договоры с поставщиками. Приложение уровня 1 с RTO (возвратом к работоспособности) в 4 часа требует SLA от стороннего поставщика, гарантирующего доступность, соответствующую этому RTO. Приложение уровня 4 этого не требует.
Сложность, связанная с устаревшей системой
Устаревшие системы усложняют оценку критичности таким образом, что современные системы управления портфелем приложений не могут адекватно её учесть. Стандартная оценка критичности предполагает, что владельцы приложений знают, что они делают и кто от них зависит. Для устаревших систем, программ на COBOL, которые поддерживались несколькими поколениями разработчиков, потоков заданий JCL, зависимости которых были задокументированы в последний раз в 2008 году, программ на RPG, создающих выходные файлы, используемые процессами, которые никто из нынешних сотрудников организации не написал, это предположение не выполняется.
Фактическая структура зависимостей устаревшей системы видна только в самом коде. Программа на COBOL, которая записывает данные в набор данных, считываемый двенадцатью нижестоящими программами, имеет двенадцать зависимостей, но этот факт может быть неизвестен владельцу программы на COBOL, который видит только функцию программы (обработка ежедневных транзакций), а не её структурную роль (создание набора данных, который обеспечивает работу двенадцати других процессов).
Для устаревших систем оценка критичности с учетом зависимостей требует анализа кода, а не опросов владельцев. Количество входящих соединений для программы на COBOL можно определить только путем изучения каждой второй программы в среде и определения того, какие из них ссылаются на выходные наборы данных первой программы, соглашения о вызове функций или общие книги копирования. Именно такой анализ предоставляют платформы структурного анализа кода, и без него оценка критичности, присвоенная устаревшей программе, с учетом зависимостей является в лучшем случае лишь приблизительным предположением.
Последствия неправильной оценки критичности устаревших приложений особенно серьезны, поскольку устаревшие системы, как правило, являются одновременно крайне критичными (они часто содержат основную бизнес-логику, накопленную за десятилетия) и имеют низкие оценки (их владельцы не могут сформулировать, что от них зависит, поэтому они присваивают им заниженные оценки). В результате устаревшие программы, которым присвоен уровень 3, фактически находятся на критическом пути бизнес-процессов уровня 1, что соответствует типу сбоя, наблюдаемому при ошибках в последовательности восстановления во время реальных инцидентов.
Как SMART TS XL Предоставляет доказательства зависимости для оценки критичности.
SMART TS XL Этот подход напрямую рассматривает аспект зависимости при оценке критичности приложений для класса приложений, где подходы, основанные на опросах, наименее надежны.
Возможность построения карты зависимостей приложений позволяет создать полный граф зависимостей для каждого языка программирования в среде: каждая программа COBOL, которая вызывает каждую другую, каждый шаг задания JCL, который производит данные, потребляемые нижестоящими программами, каждый общий копибук, создающий неявную зависимость между программами, которые никогда не вызывают друг друга напрямую, каждый набор данных, который передается между программами-производителями и программами-потребителями. Этот граф является структурной базой данных для оценки критичности зависимостей, подсчета количества взаимодействующих компонентов, идентификации общих компонентов и скрытых зависимостей в конвейере данных, которые невозможно надежно выявить с помощью обычных методов анализа.
Возможность анализа влияния позволяет запрашивать граф зависимостей для планирования плана обеспечения непрерывности бизнеса: для любого приложения в портфеле перечисляются все остальные приложения, которые зависят от него напрямую или транзитивно и, следовательно, наследуют его требования к доступности. Программа COBOL с тремя прямыми зависимостями и двадцатью транзитивными зависимостями (программами, которые зависят от прямых зависимостей) имеет эффективную критичность, отражающую двадцать три программы, в критическом пути которых она находится, а не только свою собственную функцию.
Функция статического анализа кода отображает метрики структурной сложности, которые влияют на сложность восстановления: цикломатическую сложность, метрики связности, процент мертвого кода и индикаторы технического долга, которые прогнозируют продолжительность и рискованность восстановления каждого приложения. Восстановление приложения с высокой сложностью и плотной связностью обходится дороже, а его показатель сложности восстановления по третьему измерению выше, чем у приложения с аналогичной функциональностью и чистой архитектурой.
Функция корпоративного поиска позволяет запрашивать полный перечень зависимостей на протяжении всего жизненного цикла BCP: находить каждую программу, которая обращается к определенному набору данных (идентифицируя все программы, зависящие от его доступности), каждую программу, которая использует определенный копибук (идентифицируя все программы, затронутые его доступностью), каждое задание JCL, которое выполняется в определенном пакетном окне (идентифицируя все программы, которые должны восстановиться до начала этого окна). Эта функция поиска поддерживает ежегодный обзор оценок критичности, процесс обновления, который поддерживает актуальность оценок по мере развития портфеля приложений.
Для организаций, осуществляющих модернизация наследия программы наряду с разработкой плана обеспечения непрерывности бизнеса, SMART TS XLАнализ служит одновременно обеим целям: карта зависимостей, которая используется для оценки критичности, также определяет последовательность миграции, а метрики сложности, которые используются для оценки сложности восстановления, также определяют оценку трудозатрат на модернизацию.
Поддержание актуальности оценок: цикл ежегодного обзора
Оценка зрелости обеспечения непрерывности бизнеса должна помочь вам в трех вещах: понять ваше текущее состояние, выявить наиболее значимые пробелы и построить реалистичный план улучшения. Именно это превращает оценку зрелости в более эффективную программу.
По мере изменений в организациях оценки критичности приложений отклоняются от реальности. Добавляются новые приложения. Старые приложения выводятся из эксплуатации, но не полностью отключаются. Создаются интеграции между приложениями, которые ранее не зависели друг от друга. Меняются бизнес-процессы, а вместе с ними и приложения, от которых они зависят. Нормативные требования развиваются и налагают новые обязательства по восстановлению.
Ежегодный цикл пересмотра оценок критичности должен включать в себя:
Повторный структурный анализ. Повторно выполните сопоставление зависимостей, чтобы выявить новые зависимости, появившиеся с момента последнего обзора. Приложения, которые ранее работали автономно, теперь могут иметь зависимости, повышающие их критичность. Приложения, от которых сильно зависели, могли перейти на более новые системы, что снизило их критичность.
Переоценка влияния на бизнес. Показатели выручки и операционной эффективности меняются по мере роста бизнеса и развития его портфеля приложений. Приложение, которое три года назад обеспечивало бизнес-ценность в размере 1 долларов в час, теперь может обеспечивать в десять раз большую ценность после роста бизнеса.
Учет результатов тестов на восстановление. Тесты на восстановление выявляют расхождения между предполагаемой и фактической сложностью восстановления. Приложение, получившее низкую оценку по сложности восстановления при первоначальной оценке, могло показать плохие результаты в настольном упражнении, что указывает на необходимость пересмотра оценки в сторону повышения.
Обзор изменений в нормативно-правовом законодательстве. Новые нормативные акты или изменения в существующих могут налагать новые обязательства по времени восстановления для конкретных приложений. Например, требования регламента DORA к операционной устойчивости финансовых учреждений ЕС наложили конкретные обязательства по времени восстановления для «критически важных или важных функций», которые могли не быть отражены в оценках критичности до принятия DORA.
В организациях с развитыми программами обеспечения непрерывности бизнеса оценка критичности рассматривается не как разовое мероприятие, а как непрерывный процесс: оценки обновляются при существенных изменениях зависимостей приложений, влияния на бизнес или нормативных обязательств и ежегодно подтверждаются посредством структурированного анализа.
Качество оценки напрямую зависит от наличия зависимостей.
Оценка критичности приложений наиболее эффективна, когда ее зависимость основана на структурных данных, а не на опросах. Влияние на бизнес и нормативные обязательства можно надежно оценить с помощью интервью и анализа бизнес-процессов. Операционная зависимость не может быть оценена таким образом, поскольку требует знания того, что зависит от каждого приложения, а владельцы приложений систематически недооценивают своих конечных потребителей.
Режим отказа предсказуем: последовательность восстановления, построенная на основе оценок критичности, полученных в ходе опроса, дает сбой в скрытых зависимостях. Устаревшая служба аутентификации восстанавливается с задержкой. Программа конвертации валют на COBOL оказывается в автономном режиме, когда зависящие от нее приложения пытаются восстановиться. Общая схема базы данных находится в другой точке восстановления, чем приложения, которые считывают из нее данные. Каждого из этих сбоев можно избежать, используя данные о зависимостях, полученные в результате структурного анализа, и каждый из них обходится дорого, если происходит во время реального инцидента, а не во время настольной игры.
Методология оценки разработана. Существуют соответствующие структуры. Проблема большинства организаций заключается не в системе оценки, а в доказательной базе по её наиболее важному аспекту. Необходимо устранить этот пробел с помощью структурного анализа до того, как следующий инцидент потребует применения плана обеспечения непрерывности бизнеса (BCP).
