Бизнес-критические приложения и сервисы

Под бизнес-критическими приложениями (или критически важными для бизнеса приложениями, Business Critical Application, BCA) принято понимать приложения и сервисы, жизненно необходимые для обеспечения непрерывности бизнеса. Если работа такого приложения на какое-то время прерывается или в нем происходит сбой, нормальная деятельность организации, функционирование бизнес-процессов, предоставление сервисов клиентам не могут продолжаться в обычном режиме. Следствием этого могут стать краткосрочные или даже долгосрочные финансовые потери, юридические издержки, снижение производительности труда, репутационные риски, снижение уровня доверия клиентов и другие нежелательные эффекты. Предлагаем чуть подробнее погрузиться в эту проблематику…

Классификация приложений

Используемые в современных организациях программные приложения и сервисы необходимо время от времени исследовать и проверять, назначая им уровни (степени) значимости (важности, критичности), которые отражают объем потенциальных убытков в случае возникновения проблем с их функционированием. Подобная классификация должна быть тесно связана с целями и стратегиями деятельности, принятыми в организации. В разных отраслях даже одним и тем же приложениям могут назначаться различные приоритеты в соответствии с потребностями и степенью зависимости от них бизнеса, но в большинстве случаев принято выделять три основных типа уровней значимости: критические для миссии (mission critical), критически важные для бизнеса (business critical) и некритические или низкоприоритетные приложения.

Уровень значимости приложения определяет приоритет обслуживания при массовых инцидентах (порядок восстановления систем), типовые значения SLA (Service Level Agreement, соглашения об уровне обслуживания) и стандартные инфраструктурные решения, используемые для работы приложения. Последние обладают определенным набором характеристик надежности, которые обеспечивают различную скорость восстановления при сбоях.

Критические для миссии приложения

Миссия – основная цель и смысл существования организации. Приложения, поддерживающие выполнение основных бизнес-процессов, которые связаны с осуществлением миссии, принято называть критическими для миссии (mission critical). Если критически важный ресурс простаивает, даже кратковременно, это может спровоцировать массовые сбои и привести к негативным последствиям для всего бизнеса – мгновенным или долгосрочным. Критически важные программные активы и устройства рассматриваются в контексте наивысшего приоритета, который необходимо поддерживать для обеспечения жизнеспособности операций.

Критически важные для бизнеса приложения

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

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

Некритические или низкоприоритетные приложения

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

Типы критических приложений

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

Финансовые приложения

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

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

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

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

NB. Чувствительная информация – информация, несанкционированное раскрытие, модификация или сокрытие которой может привести к ощутимому убытку или (денежному) ущербу.

Системы обмена сообщениями

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

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

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

Унаследованные системы

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

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

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

Дополнительные примеры BCA – корпоративные базы данных, системы планирования ресурсов предприятия (Enterprise Resource Planning, ERP), системы управления взаимоотношениями с клиентами (Customer Relationship Management, CRM).

4 шага для обеспечения безопасности BCA

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

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

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

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

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

План обеспечения непрерывности бизнес-процессов и аварийного восстановления

План обеспечения непрерывности бизнес-процессов и аварийного восстановления (Business Continuity and Disaster Recovery, BCDR) – это совокупность подходов или процессов, которые поддерживают способность организации продолжать функционировать после возникновения неблагоприятных событий. К последним относятся перебои в работе из-за сбоя электропитания, халатности сотрудников, сбоя в работе оборудования, программного обеспечения или кибератак.

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

Компонента обеспечения непрерывности бизнес-процессов плана BCDR касается людей, процессов и ресурсов, которые требуются до, во время и после инцидента, для того, чтобы свести к минимуму время прерывания бизнес-операций и понесенные бизнесом затраты, и включает в себя следующие элементы:

Команда. Первым и одним из наиболее важных компонентов плана обеспечения непрерывности бизнеса (Business Continuity Plan, BCP) является организация группы обеспечения непрерывности; BCP будет эффективным только в том случае, если он качественно проработан и имеется специальная команда для его выполнения в любой момент.
Анализ воздействия на бизнес (Business Impact Analysis, BIA) – глубокий анализ потенциальных угроз и того, каким образом они могут повлиять на бизнес, обычно описывается с точки зрения затрат, определяет наиболее важные бизнес-функции, которые необходимо быстро защитить и восстановить.
Планирование ресурсов – определение ресурсов (аппаратных систем, программного обеспечения, альтернативных офисных помещений и других ресурсов, которые будут использоваться во время сбоя), а также ключевых сотрудников и ролей, которые они должны играть в такие моменты.

Компонента обеспечения аварийного восстановления плана BCDR является подмножеством планирования непрерывности бизнеса и включает в себя починку и запуск систем после сбоев. Планирование аварийного восстановления включает:

Определение параметров для компании, таких как целевое время восстановления (Recovery Time Objective, RTO) – максимальное время, в течение которого системы могут быть отключены без причинения значительного ущерба бизнесу, и целевое время восстановления (Recovery Point Objective, RPO) – максимально допустимый объем данных, которые могут быть потеряны без ущерба для бизнеса.
Внедрение решений резервного копирования и аварийного восстановления (Backup and Disaster Recovery, BDR) и разработка процессов для восстановления приложений и данных на всех системах.

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

Надежный план BCDR:

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

6 шагов для выполнения надежного плана BCDR

Определите команду: команда по обеспечению непрерывности не только выполнит план BCP в случае сбоев, но также проследит за тем, чтобы другие сотрудники были проинформированы и знали, как нужно реагировать в кризисной ситуации. Команда также будет нести ответственность за планирование и реализацию стратегии кризисной коммуникации.
Проведите BIA: BIA определяет влияние внезапной потери бизнес-функций, обычно с точки зрения затрат для бизнеса, а также наиболее важные бизнес-функции, что позволяет разработать план BIA, в котором приоритет отдается восстановлению этих важных функций.
Разработайте план восстановления: определите приемлемое время простоя для критически важных систем и внедрите для них, а также данных SaaS-приложений BDR-решения. Решения могут функционировать на базе выделенных устройств или в облаке. Рассматривайте решения аварийного восстановления как услуги (Disaster Recovery as a Service, DRaaS) в качестве части общей стратегии.
Тестируйте резервные копии: тестирование аварийного восстановления является жизненно важной частью плана BCDR, без тестирования у организации не будет необходимой информации о принципиальной возможности восстановления резервных копий.
Выполните план: в случае сбоя выполните процессы, которые вернут все системы и бизнес в нормальное состояние.
Измеряйте, просматривайте и обновляйте план: оценивайте успешность выполнения и обновляйте план на основе любых обнаруженных недочетов; для получения наилучших результатов рекомендуется предварительно протестировать план BCDR.

Программный комплекс “Центральный Пульт” в контексте обеспечения непрерывности цифрового бизнеса

Программный комплекс “Центральный Пульт” (SAYMON) – современная программная платформа, позволяющая описать и поставить на контроль всю структуру цифровой (или в некоторых случаях уместнее говорить – “оцифрованной”) деятельности организации.

“Центральный Пульт” использует объектную модель для описания иерархии влияния и зависимости – построения ресурсно-сервисной или, как мы предпочитаем говорить, “компонентной” модели. Построение такой модели предусматривает, кроме всего прочего, описание бизнес-сервисов, их свойств, критичности и показателей; цифровых сервисов, обеспечивающих работу бизнес-сервисов, их свойств и целевых показателей; сервисных платформ, информационно-коммуникационных систем и ресурсов, обеспечивающих оказание сервисов и их показателей. При этом на каждом уровне, при наличии технической возможности, обеспечивается непрерывный автоматический контроль показателей и анализ нормальности или аварийности их значений (мониторинг).

Мониторинг осуществляется не на каком-то отдельном уровне, а на всем технологическом стеке поддержки выполнения операций, обеспечивающих работу сервисов, с учетом резервирований и кластеризации, целевых и актуальных уровней предоставления сервиса (SLA, SLO – Service Level Objective). При этом отклонение показателей от нормальных значений на каждом из уровней обеспечивается не только регистрацией для формирования отчетности, но и уведомлениями дежурных, ответственных сотрудников и подразделений на визуальном уровне схем и иерархий, через электронную почту, мессенджеры или системы регистрации заявок.

“Центральный Пульт” таким образом обеспечивает сигнализацию о деградациях в работе подсистем и сервисов в целом и помогает оперативному восстановлению обслуживания клиентов или предотвращению прерываний обслуживания. В терминах обеспечения непрерывности программный комплекс помогает перейти от реактивных операций (основанных на жалобах клиентов) к проактивным (основанным на знаниях о состоянии услуг/сервисов и инфраструктуры) и к предиктивным (основанным на машинном анализе и автоматизированном прогнозировании развивающихся аномалий работы систем). Немалую роль, кроме объектной модели графов, в комплексе играют временные ряды – специальные форматы данных для большого количества измерений показателей, позволяющие задействовать богатые возможности математического аппарата и искусственных нейронных сетей для определения аномалий и построения прогнозов.

“Центральный Пульт” (или коротко – SAYMON) играет все более значимую роль в работе любой современной организации. Благодаря развитым средствам графического описания и программного определения, комплекс позволяет реализовать систему контроля предоставления сервисов и работы ресурсов организации. Реализация может выполняться и корректироваться персоналом компании-заказчика или системным интегратором – в зависимости от сложности и динамики переопределения (изменения) инфраструктуры.

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