В программе Вебинара:

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

Вебинар пройдет в абсолютно комфортное время – 22:00 по Москве, когда никакие рабочие дела не помешают вам насладиться общением с Дороном

Ссылка для регистрации тут.

До конца 1 квартала Continuity Software (а в России и СНГ – Алмитек) предлагает специальные условия лицензирования для той части ИТ-инфраструктуры, которая обеспечивает высокую доступность, т.е. на локальные кластеры. На эти лицензии до конца Q1 предлагается скидка 50%. Кроме того, по прежнему действует акция по пилотному сканированию с обучением на родине продукта – в Израиле.

• Сбор информации о происходящем из всех доступных источников
• Консолидация, верификация и анализ информации
• Управление командами восстановления
• Информирование всех вовлеченных сторон – прессы, официальных органов, родственников потерпевших и т.п.

Теперь немного о технологиях. В течение долгого времени неизменными атрибутами такого центра были:

• Телефоны (много)
• Доски (whiteboards), на которых записывалась вся информация
• Карты, в которые втыкались разнообразные флажки.

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

1. Передача информации. Для того, чтобы получить любую информацию, находящуюся в ЦУИ, туда надо дозвониться, и получить информацию по телефону. При большом числе участников информационного обмена дозвониться до ЦУИ будет тяжело, информация может искажаться, а сотрудники ЦУИ будут отвлекаться от выполнения своей основной задачи.
2. Анализ действий после завершения инцидента. Очевидно, что все силы в момент инцидента будут брошены на его устранения, и протоколирование действий будет вестись настолько, насколько это будут позволять ресурсы. Тем не менее, последующий «разбор полетов» является важнейшим действием как для минимизации потерь при подобных ситуациях в будущем, так и при работе силовых структур, страховых компаний и т.п. по изучению деталей произошедшего инцидента.
3. Выполнение плана управления инцидентом. Даже если такой план существует (что можно только приветствовать), классический ЦУИ не предоставляет возможностей по отслеживанию выполнения плана/формализации выполняемых действий. В данном случае мы имеем только возможность работы с бумажной версией плана и проставления галочек по выполненным шагам. В принципе, не так уж мало, но в жизни проявляются все проблемы, связанные с подобного рода планами – отсутствие под рукой (или вообще в природе) актуализированной версии, наличие сотрудников, неосведомленных о такого рода плане,  и т.п.

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

Существует целый класс систем, предназначенных для автоматизации деятельности ЦУИ. Функционально – они позволяют делать примерно то же, что делают люди на маркером на досках и флажками на карте – собирают информацию. Даже терминология используется та же – для экранов, предназначенных для сбора и отображения информации, используется термин «доски» (boards). Но процесс проходит уже на качественно новом уровне, в результате чего:

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

И, наконец, при чем тут Гаити. Аналогичная система, построенная на базе решения WebEOC компании ESi, была сразу после землетрясения развернута в посольстве Гаити в Вашингтоне. За 5 дней, с 12 по 17 января, в посольстве был развернут ЦУИ – установлено 20 телефонных линий, развернута система WebEOC, проведено обучение персонала, доработаны дополнительные «доски» для отслеживания пропавших без вести, управления добровольцами, и учета пожертвований. Учитывая масштаб произошедшего, очевидно, что подобное решение смогло реально помочь в ликвидации последствий землетрясения.

Работают подобные решения и в гораздо меньшем масштабе. По опыту внедрения подобных систем (как мировому, так и собственному), эффективны и востребованы подобные решения могут быть для:

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

Из промышленных западных решений на российском рынке представлено решение Incident Manager от компании Sungard, представляющее из себя упомянутую выше систему WebEOC, дополненную интеграцией с системой поддержки планирования управления инцидентами LDRPS. Федеральные структуры типа МЧС используют, насколько я знаю, специализированные отечественные разработки.

Приказ, среди прочего, устанавливает целевые показатели восстановления для сайтов федеральных органов:

RTO – 4 часа

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

RPO – 24 часа

В целях защиты информации, размещенной на официальном сайте, должно быть обеспечено:

[...]

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

Кроме того, определены некоторые требования к хранению резервных копий:

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

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

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

Случится то происшествие, которого вы не ждете.

Казалось бы, ничего нового, про это говорится от раза к разу, но, несмотря ни на что, зачастую готовимся мы именно к тому, с чем уже сталкивались в обозримом прошлом. Типичный пример тому – меры, принимаемые TSA по обеспечению безопасности полетов после очередных [попыток] терактов, когда защитные меры почему то выстраиваются исходя из предположения, что следующая попытка теракта произойдет в точности по сценарию предыдущей. Мораль – планы обеспечения непрерывности деятельности должны быть:
а) достаточно гибкими
б) рассчитывать на самые худшие сценарии развития ситуации

Не рассчитывайте на работоспособность коммунальных служб

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

• У вас не будет электричества. Его может не быть вообще, его могут ограничить предприятиям, его могут «веерно» отключать. В любом случае, если ваш бизнес – это не детский сад или больница, то с большой вероятностью при дефиците энергоснабжения вам может «не хватить».
• Дизель-генераторы могут не помочь. Например, если не будет достаточного запаса солярки, а дороги засыплет снегом. Или заправки не будут работать, потому что там не будет электричества, и насосы не будут работать.
• У вас не будет связи. Бесконечно трагичный, но очень яркий пример – недавнее землетрясение на Гаити. Точнее, не будет привычных видов связи – фиксированной и мобильной. Спутниковая, до определенного масштаба ЧС, будет продолжать работать.
• Воды тоже может какое-то время не быть. Кроме того запаса к кулерам, который есть у вас в офисе, если он есть.
• Транспорт работать не будет. Потому что (см.выше) – не будет топлива, электричества, дорог.

Мораль – определяя свою стратегию, учитывайте возможные изменения окружающего вас мира. Одно из направлений для размышлений – если все ядро вашего бизнеса расположено в одной точке пространства (включая ИТ) – серьезно подумайте о том, чтобы разместить резервную площадку на значительном отдалении.

После ЧС – проведите переоценку RTO

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

Мы тоже решили не отставать, и в первом квартале запустили акцию, направленную на то, чтобы те из вас, кто отвечает за непрерывность ИТ-сервисов, начали год с внешнего [инструментального] аудита своих HA/DR решений, чтобы получить дополнительную информацию о том, что необходимо сделать в текущем году, где есть проблемы, о которых вы, возможно, не подозреваете, а где есть возможности для повышения эффектвности, или даже снижения затрат. В качестве инструмента для проведения аудита было выбрано решение RecoverGuard нашего партнера Continuity Software.

А в качестве бонуса тем, кто начнет свой год с повышения отказоустойчивости своей инфраструктуры достанется поездка в Израиль - короткий курс по принципам работы системы в учебном центре Continuity Software в Тель-Авиве, reference visit в одну из компаний-пользователей RecoverGuard, ну и возможность немного отдохнуть и поплавать под ласковым израильским солнцем – март-апрель самое подходящее время для визита в эту страну.

Более подробную информацию о нашей акции можно посмотреть здесь.