Непрерывность ИТ-услуг как искусство возможного
Море не любит непотопляемые суда (исторический факт).
Игорь Соглаев
Много лет реализуя проекты в сфере обеспечения непрерывности ИТ-услуг и проводя обучение профильных специалистов, невозможно не обратить внимание на ряд стереотипов, которые сложились среди айтишников (и не только) по отношению к данной области менеджмента. Стереотипы эти довольно живучи и, на наш взгляд, несут в себе достаточно серьёзные риски. Мы не стали называть эти стереотипы мифами или заблуждениями, потому что большинство из них имеет вполне рациональные объяснения. Более того, появлению некоторых отчасти способствуют и отдельные международно-признанные «лучшие практики», что особенно огорчает, поскольку наш подход к управлению и обучению основан именно на них. Получается, что и наш скромный вклад во всё это тоже присутствует. Мы решили попробовать собрать эти стереотипы в одной статье, разобраться, как они возникли и чем могут быть опасны.
Напомним, что непрерывность – это способность поставщика услуг продолжать работу на приемлемом заранее заданном уровне после катастрофы или разрушительного инцидента. Управление непрерывностью работает со специфическими рисками, которые объединяет высокая степень влияния на деятельность организации по созданию ценности и источники, как правило, находящиеся вовне и, в целом, трудно поддающиеся воздействию. Кроме того, управление упомянутыми рисками должно производиться экономически обоснованным способом. Поэтому при управлении непрерывностью важно всегда помнить, что именно делает вашу организацию именно такой, какая она есть. В подавляющем большинстве случаев речь идёт о людях и знаниях, именно они важнее всего, и именно их мы защищаем, управляя рисками непрерывности. Итак, перейдём к стереотипам.
Размер имеет значение (до непрерывности надо дорасти)
Самый старый и, наверное, самый распространённый стереотип. Есть такое мнение, что обеспечением непрерывности системно занимается только большой бизнес – лидеры цифровой экономики, банки, крупные промышленные предприятия, нефтегазовые компании и т. п., ну и государству, как говорится, сам бог велел. Такая точка зрения вполне обоснована, именно в этих структурах под влиянием радикальных политико-экономических трансформаций, произошедших на рубеже веков, и возникло само понятие непрерывности бизнеса. Но так ли уж важен размер?
У одного моего знакомого, владельца небольшой торговой компании, как-то упал сайт, обеспечивающий работу интернет-магазина. Случай, в общем-то, заурядный, но тут звёзды сошлись в неудачной точке. Во-первых, сайт упал за пару недель до новогодних праздников, в самый пиковый период активности покупателей. Во-вторых, поднять его из резервной (ежедневной) копии собственными силами не получилось – база данных выглядела как настоящая, но почему-то не опознавалась движком. В-третьих, разработчик сайта и магазина (наш общий знакомый) в нужный момент не вышел на связь. Разумеется, у моего знакомого имелись и другие каналы реализации, он не работал через известные маркетплейсы, но была площадка на «Авито» и несколько прямых договоров с постоянными заказчиками – организациями, однако почти 70% заказов в этот период приносил именно интернет-магазин. Разработчика в конце концов нашли, сайт восстановили, но подсчёт недополученной прибыли подтолкнул к серьёзному пересмотру модели поддержки бизнес-процессов.
Другой пример с относительно небольшим бизнесом какое-то время назад даже удостоился эфира на федеральных телеканалах – сеть шиномонтажных мастерских в разгар сезона утратила известным способом базу данных, в которой, в том числе, хранилась информация о точном местонахождении зимних шин клиентов, оставленных на хранение. Складов для хранения было несколько и для удобства они размещались в разных районах столицы, то есть, довольно далеко друг от друга. Каждый комплект шин, разумеется, был снабжён наклейкой с инвентарным номером, фамилией и контактными данными владельца, а в базе этому инвентарному номеру соответствовали идентификаторы склада, стеллажа и полки. Да, у клиентов имелись квитанции с инвентарными номерами, но сравнивать информацию из них диспетчерам было не с чем[1]. Восстановить базу в разумный срок не удалось, поэтому пришлось проводить параллельную инвентаризацию, в связи с чем срок выдачи шин увеличился до 7-10 дней. Учитывая привычку большинства наших водителей «переобуваться» после первого гололёда, а не заранее, можно себе представить их «пользовательский опыт». Тут проблема даже не в упущенной сиюминутно выгоде, а в том, какой процент клиентов рискнул вновь воспользоваться услугой по сезонному хранению шин, а заодно и всеми остальными услугами. Логичным было бы предположить, что уровень лояльности сильно снизился.
По данным Uptime Institute (2023) 60% всех опрошенных организаций в последние 3 года сталкивались с простоями, 32% из которых можно охарактеризовать как значительные, серьёзные или тяжёлые (Рисунок 1).
Рисунок 1. Доля серьёзных простоев
Под такими простоями понимаются прерывания деятельности, связанные с финансовым ущербом, нарушениями нормативных требований, проблемами с безопасностью, потерей клиентов и репутационными издержками. То есть, по сути, эти простои являются ничем иным, как реализовавшимися рисками непрерывности. Причины простоев представлены ниже, большинство из них связаны с сетями, электроснабжением и ошибками программного обеспечения – ничего неожиданного, опять знакомые всем риски (Рисунок 2).
Рисунок 2. Причины простоев
А вот продолжительность простоев за последние 5 лет в среднем увеличилась, о чём свидетельствует следующая диаграмма (Рисунок 3). Причём, самый значительный рост показали простои, длившиеся более 48 часов.
Рисунок 3.Динамика продолжительности простоев
В исследовании IDC Worldwide State of Data Protection and Disaster Recovery Survey, опубликованном в 2021 году, также сообщается о следующих выводах:
- Почти половина сбоев в работе с данными приводит к снижению производительности.
- 43% компаний сталкиваются с потерей данных из-за сбоев.
- Более 30% сбоев приводят к прямой потере дохода.
- Около 40% отключений наносят ущерб репутации и имиджу бренда.
- Половина сбоев серверов приводит к тому, что персонал работает сверхурочно, что ещё больше снижает прибыль.
Какова же цена вопроса? Согласно исследованию Gartner, на которое ссылаются многие консалтинговые компании в своих общедоступных отчётах, средняя стоимость минуты простоя для предприятий малого бизнеса в США составляет $427, а для крупного – $5600 (по данным опросов, проведённых в 2019 году). Впрочем, есть данные опросов, которые показывают гораздо более высокие значения – до $85000 за минуту. По данным уже упомянутого отчёта Uptime Institute в 2022 г. 25% простоев обошлись компаниям более чем в $1 млн. по сравнению с 11% в 2019 г. (см. Рисунок 4).
Рисунок 4. Динамика убытков от простоев
Для большинства отечественных предприятий цифры, скорее всего, будут меньше, но они всё равно довольно значительны. Умножаем стоимость простоя в минуту на длительность, не забыв перевести время из минут в часы. И это только убытки, которые можно оценить в деньгах. Сколько потенциальных клиентов потеряла шиномонтажная сеть из нашего примера, учитывая охват аудитории телеканалов, сложно подсчитать – вероятно, полный ребрендинг был бы в таком случае единственным разумным выходом. Потому что утрата 70% заказов или большей части клиентов одинаково болезненны, вне зависимости от абсолютных цифр потерь.
Непрерывность – это не наше дело (пусть бизнес/айтишники этим занимаются)
Это двойственное предубеждение, которое, надо признать, имеет глубокие корни. Действительно, в книге ITIL Service Design (2011) отсутствие процесса управления непрерывностью бизнеса – (Business continuity management, BCM) справедливо названо главной проблемой обеспечения непрерывности ИТ-услуг. «Если BCM отсутствует, то IT, скорее всего, сделает неверные предположения о критичности бизнес-процессов и, следовательно, примут неправильные стратегии и варианты обеспечения непрерывности…, а бизнес может… потратить деньги впустую на неэффективные и дорогие ИТ-решения»[2]. Утверждение справедливо, однако выводы из него иногда делаются странные, например, внутренние ИТ не уделяют достаточного внимания рискам непрерывности (ну, кроме самых очевидных), ссылаясь на отсутствие у бизнеса понимания того, какие бизнес-процессы по-настоящему критичны. А раз такого понимания нет, и ИТ-решения в этой области действительно весьма затратны, айтишники даже не выходят с предложениями по их реализации, поскольку денег всё равно не дадут. Лечится это, как правило, путём «осознания через инцидент», но зачем же доводить?
С другой стороны, часто можно наблюдать чрезмерную уверенность бизнеса в том, что обеспечение непрерывности – это исключительно ответственность ИТ, а это как раз может приводить к неоправданным затратам на «неэффективные и дорогие ИТ-решения», в то время как возможны (и нужны!) точечные и практически бесплатные корректировки бизнес-процессов.
Напомним, что для внутренних ИТ-подразделений обеспечение непрерывности – это поддержка непрерывности бизнеса путём управления рисками, которые могут повлиять на ИТ-услуги, с целью обеспечения их (услуг) согласованного уровня. А вот для внешних поставщиков ИТ-услуг обеспечение непрерывности ИТ-услуг равно обеспечению непрерывности бизнеса. В рамках соответствующей практики ITIL 4, например, рассматриваются только операционные риски (у управления непрерывности бизнеса всегда более широкий охват).
Движение на пути обеспечения непрерывности должно быть двусторонним, о чём неустанно говорят нам «лучшие практики», однако необходимо учитывать многократно возросшую зависимость практически любого бизнеса от ИТ. Особенно ярко это проявилось с началом пандемии COVID-19, когда многие ИТ-услуги испытали практически экспоненциальный рост спроса и в условиях новых ограничений стали единственно возможным способом ведения бизнеса. Перевод огромного количества сотрудников на удалённую работу тоже способствовал тому, что на двустороннем пути навстречу друг другу от бизнеса требуется всё меньше, а от ИТ – всё больше.
Непрерывность – это очень сложно (и дорого)
Следует признать, что обеспечение непрерывности ИТ-услуг в современном мире – действительно сложный процесс, зачастую (хотя и не всегда) требующий значительных затрат. Более того, наши тренеры и консультанты неизменно и тщательно это подчёркивают для того, чтобы не создавать завышенных ожиданий – задачи по управлению рисками непрерывности имеют много решений, из которых часто приходится выбирать не лучшие, а доступные. Стоимость реализации этих решений нам уже есть с чем сравнивать, ведь как раз с цены простоев мы и начали.
Теперь попробуем разобраться, откуда возникает ощущение избыточной сложности. Менеджер или ИТ-специалист, на которого (внезапно) сваливаются задачи по обеспечению непрерывности, практически всегда сталкивается с проблемой выбора единственно верной и относительно простой методички и обнаруживает (если повезёт, то довольно быстро), что таковой не существует. Причин тому много, и их анализ тянет на отдельное исследование, как и перечисление всех существующих источников информации, поэтому просто примем это как данность.
Заинтересовавшись практическими аспектами обеспечения непрерывности ИТ-услуг, сначала обычно обращаются к международным стандартам, недостатка в которых на первый взгляд нет: американские, британские (вполне добротно переведённые на русский язык под видом ГОСТов) и даже новозеландские: ГОСТ Р ИСО 22301-2021, ГОСТ Р ИСО 55235.3-2012, PAS77 и др. Однако большинство стандартов ожидаемо содержат многочисленные требования к деятельности, но не методические указания по их выполнению. Встречающиеся в названии стандартов фразы «Практические аспекты» или «Руководство» не должны вводить в заблуждение – указания, которые в них содержатся, как правило, очень высокоуровневые.
Кроме того, айтишники интуитивно ищут специализированные отраслевые документы, например ГОСТ Р ИСО/МЭК 27031-2012 (это где про ГИКТОНБ[3]), а они подразумевают, что в целевой организации есть и менеджмент непрерывности бизнеса (МНБ), и риск-менеджмент на соответствующих уровнях зрелости. Но в приведённом примере, когда бизнес считает непрерывность зоной ответственности ИТ, обращение к этим практикам общего менеджмента ещё больше всё усложняет.
Несколько более эффективным может стать обращение к «лучшим практикам» типа COBIT или ITIL: они стандартам не противоречат, но вводят собственный понятийный аппарат и ограничения соответствующих фреймворков. И начинается путаница в определениях и артефактах, стратегия мешается с программой, программа с планом, а план распадается на BCP, SCP и DRP[4], которые похожи, но почему-то разные. В результате, потратив кучу времени на изучение большого количества руководств, часто практически невозможно ответить на простой вопрос: «А как мне написать, проверить и поддерживать DRP конкретно для нашей критичной системы?»
Попытку популяризации управления непрерывностью предпринял в свое время Банк России, выпустив Приложение 5 к Положению Банка России от 16 декабря 2003 года N 242-П, в котором относительно сжато сформулировал «рекомендации» (по факту – требования) по структуре и содержанию плана обеспечения непрерывности и восстановления деятельности (ОНИВД). Шаблон такого плана из неизвестного источника мгновенно разошёлся по сети, и через какое-то время в каждой кредитной организации был свой вариант (тот же шаблон, но с изменённым титульным листом) на случай проверки регулятором. Однако к этому нужному документу очень не хватало подробных методических рекомендаций, которых, к сожалению, не последовало.
Единственная книга на русском языке, которую можно рассматривать в качестве учебника – это «Управление непрерывностью бизнеса. Ваш бизнес будет продолжаться» за авторством уважаемых С. Петренко и А. Беляева – была издана в 2011 году. Она представляет собой хороший обзор большинства актуальных на тот момент подходов и практик, но достаточно объёмна и рассчитана на подготовленного читателя[5].
Не распыляйте усилия и не пытайтесь выполнить все требования и рекомендации. Лучше выбрать какой-то один подход, в рамках которого и действовать, сначала выстроив высокоуровневую схему. Если какой-либо из уровней необходимо детализировать глубже, чем выбранный подход позволяет, обращайтесь к смежным практикам и дисциплинам.
Чтобы повысить эффективность и уменьшить стоимость решений в сфере обеспечения непрерывности, необходимо улучшать точность анализа влияния на бизнес (business impact analysis, BIA) и оценки рисков (risk assessment, RA), а это возможно только при адекватном уровне зрелости данных процессов, поначалу все оценки будут приблизительными, и с этим придётся смириться. В условиях нехватки времени и денег небезынтересным может показаться «модульный» подход, предлагаемый специалистами американской некоммерческой организации SANS Institute, который игнорирует множество этапов классического МНБ и рекомендует начать с планов аварийного восстановления критичных систем (которые отбираются безо всякого BIA, что характерно). Авторы подхода считают (и где-то с ними трудно не согласиться), что даже такой эрзац – это лучше, чем ничего. В любом случае решать вам.
План может быть только всеобъемлющим
Речь в данном случае о том, что планы обеспечения непрерывности (неважно, BCP это, SCP или DRP) должны учитывать все риски и предусматривать все сценарии развития событий, а иначе они просто бесполезны. Такая точка зрения своим существованием тоже, скорее всего, обязана своеобразной интерпретации некоторых фрагментов «лучших практик» и напоминает расхожее мнение о том, что если некие важные для процесса метрики невозможно посчитать с точностью, близкой к абсолютной, то считать их и вовсе не нужно. Откуда это взялось, неясно, мы стараемся учить прямо противоположному – посчитать приблизительно гораздо лучше, чем совсем проигнорировать, тем более, с опытом точность расчётов неуклонно повышается.
Скажем сразу, все варианты развития событий предусмотреть невозможно. В конце концов, мы работаем со специфическими рисками, и реальная катастрофа всё равно пойдёт по какому-то своему сценарию, который ни на каких тренировках не отрабатывался (скорее всего, ввиду нехватки воображения). А непрошеных «режиссёров-сценаристов», к сожалению, хватает, особенно в последнее время, когда эпидемии, военные действия, беспорядки, хакерские атаки, законодательные инициативы, природные и техногенные катастрофы сменяют друг друга в режиме non stop.
В качестве примера можно привести историю с одной давно закрытой (и забытой) финансовой компанией, в которой придумали разместить основной и резервный офисы в Северной и, соответственно, Южной башнях Всемирного торгового центра в Нью-Йорке. Риск одновременной потери обоих офисов был оценен как крайне маловероятное событие, и никаких контрмер на этот случай предусмотрено не было. Ну а в остальном хороший был план, надёжный, как швейцарские часы[6].
Как говорится, если вы не можете повлиять на реальность, просто измените своё отношение к ней. Это шутка, конечно, но реагировать на изменения нужно максимально гибко. Попробуйте декомпозировать процессы восстановления ИТ-услуг, разбить их на стандартные блоки и отрабатывать сценарии вне зависимости от генезиса угроз, при этом не забывая моделировать и оценивать различные обстоятельства, способные осложнить выполнение сценариев и поломать любые «хитрые» планы.
Высокая доступность – наше всё
Адептов систем высокой доступности до сих пор хватает, несмотря на регулярную (и весьма удручающую) статистику сбоев сервисов ведущих цифровых компаний по всему миру. И «лучшие практики» скорее опровергают этот стереотип, например, в актуальной редакции ITIL 4 сказано буквально следующее: «Информационные системы всё больше зависят от такого количества компонентов, что их поведение часто невозможно предсказать или гарантировать. Безотказные системы – это иллюзия. Организация должна быть готова к неизбежным и неожиданным сбоям. Теперь акцент делается не на длительном интервале между сбоями, а на быстром восстановлении сервиса при возникновении неизбежных проблем. Это снижает вероятность нарушения бизнес-операций»[7].
Задолго до осознания этого факта авторами ITIL инженеры компании Google реализовали такой подход на практике. «Вместо огромных серверов с большими объёмами данных на каждом из них, Google содержит тысячи и тысячи небольших и недорогих серверов, рассеянных по всему миру, объединённых в очень сложную сеть. Никто не ожидает от этих серверов стопроцентной надёжности; разного рода сбои ожидаются и когда возникают, выявляются немедленно. Не беда, если сервер неисправен, поскольку все данные разделены на мелкие порции и содержатся во множестве мест. Поэтому когда серверы выходят из строя и автоматически отключаются от сети, содержавшиеся на них данные берутся в некотором хранилище, и их копия быстро помещается на работающий сервер. При этом пользователи даже не замечают, что что-то случилось; они по-прежнему получают почти мгновенные ответы»[8].
Несмотря на давно уже очевидное смещение акцентов с проблемной и очень дорогой отказоустойчивости на быстрое восстановление, особенно уверены в себе обладатели двух (и более) активных ЦОД[9]. Вполне возможно, потому что ни разу не проводили тренировки в условиях, «максимально приближённых к боевым». Сложность систем и большое число зависимостей способны нивелировать многие преимущества высокой доступности.
Айтишники одной очень известной западной компании (российское представительство) провели как-то тренировку с полным отключением основного ЦОД – по сценарию все критичные сервисы должны были быть восстановлены в резервном. На весь процесс отвели полтора часа, считая, что в целом справятся и быстрее, но именно столько было согласовано с бизнесом (тренировка проводилась в рабочее время по стандартам холдинга). Бессердечная реальность скорректировала сценарий уже на самой первой секунде – ключевая группа поддержки (внешний подрядчик) пропала из эфира. Да, они использовали для удалённого доступа оборудование и канал, находящиеся в отключённом основном ЦОДе. Как же так получилось? Этот вопрос следовало бы задать тем, кто отвечал за анализ влияния на бизнес и разработку общего плана непрерывности, ведь очевидно, что критичными могут быть не только бизнес-сервисы.
Разумеется, новый канал был наспех организован, но (не говоря уже про возникшие риски информационной безопасности) на это ушло время, которого потом не хватило, потому что дальше возникли сложности с одним из ключевых компонентов известной платформы виртуализации, который не поднялся автоматически. Официальная инструкция не помогла, как и специалист из техподдержки вендора, привлечённый к решению проблемы (о проведении тренировки вендор был оповещён заранее). И тут все посмотрели на часы. По оценке участников тренировки, данной в ходе проведённого позже post mortem review, им не хватило буквально минут 15-20 (именно столько времени было потеряно на организацию канала) на то, чтобы всё-таки разобраться в проблеме и самим всё поднять. Но время поджимало, а бизнес начал давить. Под этим давлением было принято роковое решение откатить всё назад (вновь активировать основной ЦОД). Однако с этим возникли некоторые сложности (ведь часть служб уже поднялась в резервном), на решение которых ушло ещё почти 5 часов.
По факту произошедшего был проведён полный аудит планов непрерывности, сценариев восстановления критичных систем, инструкций вендоров и прочей документации, около 60% которой было актуализировано. Отдельная работа была проведена с вендором: в одобренной им инструкции нашли ошибку в одной строчке (видимо, для какой-то из более ранних версий она была верной), а выделенный сотрудник техподдержки работал в этой должности всего неделю.
Зависимости – это очень уязвимое место всех планов и сценариев, иногда они настолько неочевидны, что пропускаются в даже в ходе тщательного анализа. Во внедряемой нами у крупного заказчика ITSM-системе было предусмотрено 18 интеграций, и это при наличии в компании общей шины данных. А сколько таких интеграций может быть у систем класса «Mission Critical»? Вполне может получиться, что такая система успешно поднимется в резервном ЦОДе, а вот часть данных для её работы взять будет негде, пока смежные системы классом ниже не восстановлены.
В своё время довелось наблюдать тестирование подобной «неубиваемой» системы интернет-банкинга: 5 web-серверов, 4 сервера приложения, база данных с зеркалированием, и всё это распределялось по двум активным ЦОД с балансировкой трафика. Однако при контрольной проверке выяснилось, что при имитации отключения основного ЦОД система не падает, вот только войти в неё новым пользователям практически невозможно, а большинству уже вошедших доступны только переводы между своими счетами, что, вероятно, увлекательно, но не особо продуктивно. Как вы уже догадались, дело было в кодах подтверждения операций, отправляемых единственным и неповторимым SMS-шлюзом. Счастливые обладатели карт одноразовых кодов разницы не ощутили, но их было не более 5% от общего количества пользователей. Когда систему проектировали, это был вообще единственный способ подтверждения, который потом вытеснили SMS, так что большинство пользователей о такой возможности даже не знали.
Как показывает практика, упасть может всё что угодно и совсем не обязательно у вас. Пример тому – случившаяся 30.01.2024 история с поломкой DNS, вызвавшей массовые отказы сервисов во всем Рунете. Пользователи, имеющие в настройках какой-нибудь публичный DNS-сервер в качестве резервного, сбой практически не заметили, а вот разработчикам ослепших банковских и операторских приложений большой привет. Кстати, новые модные кассы самообслуживания, установленные уже во многих магазинах, во время сбоя тоже не работали, что спровоцировало очереди. Получается, что такой тривиальный риск разработчиками даже не просчитывался. Да, всё поправили довольно быстро (успели откатить изменения?), но не всегда же будет так везти. Даже думать не хочется о последствиях более продолжительных сбоев такого рода.
Повторимся, упасть может ВСЁ, примеры можно приводить ещё долго. Не бывает абсолютной отказоустойчивости и надёжности – даже самые навороченные и дорогие решения в области высокой доступности не могут дать 100-процентной гарантии. Поэтому двигаться нужно в направлении быстрого восстановления и других способов обеспечения непрерывности критичных систем и услуг.
А у нас хорошие планы и отличные показатели на тренировках
Ну и, как говорится, last but not least[10]. Регулярные тренировки – это основа основ непрерывности бизнеса, без них ни один план нельзя считать работоспособным, и в любом стандарте или руководстве это неоднократно и настойчиво подчёркивается. Тем не менее, существует странность, фиксируемая нами в крупных организациях с разветвлённой структурой чаще, чем хотелось бы. Странность эта заключается в том, что в ходе тренировок по отработке планов непрерывности на них непременно хотят продемонстрировать хорошие результаты. И демонстрируют, что характерно. Особенно, когда есть соответствующие показатели, на выполнение которых мотивируются линейные руководители ИТ-подразделений. И иногда получается так, что норматив на выполнение DRP для критичной системы равен 1 часу, на тренировках один за одним бьются рекорды (45, 40, 35 минут!), а реальный значительный инцидент, для устранения которого приходится использовать тот же DRP, устраняется 4,5 часа (документально зафиксированный случай).
Несмотря на то, что мы всегда рекомендуем нашим заказчикам с осторожностью подходить к любым персональным показателям эффективности, особенно на начальных этапах внедрения процессов, ИТ-руководство крупных холдингов обычно встречает это прохладно. Есть предубеждение, что без установки каких-то KPI[11], сотрудники отнесутся к вопросу недостаточно серьёзно, а то и вообще не будут ничего делать. Это не только непрерывности касается, кстати, и имеет под собой рациональную основу (люди действительно в ходе эволюции выработали склонность к оптимизации энергозатрат), но не следует забывать и про другую, не менее интересную особенность человеческой психологии.
Согласно известному в менеджменте принципу Гудхарта[12], когда мера становится целью, она перестаёт быть хорошей мерой, потому что становится объектом манипулирования как прямого (фальсификация чисел), так и косвенного (работа исключительно для улучшения этой меры). То есть, как только у сотрудников появляются конкретные показатели, за невыполнение которых их могут не поощрить и, тем более, наказать, они практически неизбежно начинают работать на эти показатели, забывая про всё остальное. И эта работа со временем подменяет собой всю прочую мотивацию – разница лишь в скорости адаптации, то есть, когда цель «выполнение KPI» сменится на «выполнение KPI любыми средствами», не исключая и искажение результатов. Это вовсе не обязательно прямой обман, но вот выполнение контрольных тренировок лучшими из лучших выглядит весьма привлекательно (и невинно). Однако в реальной чрезвычайной ситуации выполнять DRP будут те, кто окажется под рукой, и далеко не факт, что под рукой окажутся те самые рекордсмены.
Изначальный смысл проведения любых типов тренировок в BCM от пошагового прохождения на бумаге до полной имитации реальной аварии – проверить реалистичность планов непрерывности, найти в них неверные допущения, ошибки в оценке рисков, уязвимые места и т. п. Именно в этом их реальная ценность, а не в том, чтобы уложиться в норматив. Если команда восстановления не может уверенно обеспечить RTO и RPO[13] критичной системы, это повод задуматься о качестве планирования и реалистичности взятых на себя обязательств. И получается, что детальный разбор неудачной отработки DRP с последующими корректирующими мероприятиями имеет для процесса куда большую ценность, чем рапорт об успехе. Даже если это реальный успех, вам ведь могло просто повезти.
Что в итоге?
Учитывая постоянно растущую сложность и непредсказуемость систем, обеспечивающих предоставление ИТ-услуг, увеличение зависимости любого бизнеса от ИТ и постоянно возникающие новые риски прерывания деловых операций, очень важно уметь видеть главное, чтобы в условиях ограниченных ресурсов тратить усилия только на то, что несёт реальную ценность. Сейчас от того, насколько качественно выполнен анализ влияния на бизнес, критично зависит успешность любых планов обеспечения непрерывности. А для этого требуется глубокое понимание бизнес-процессов, потоков создания ценности и самой сути бизнеса вашей организации. Ну и смиритесь уже, наконец, с тем, что по дороге навстречу друг другу вам придётся пройти больше и дольше, чем вашим партнёрам из бизнеса.
Не переоценивайте системы высокой доступности, использующие зеркалирование данных, опыт их эксплуатации в условиях чрезвычайных ситуаций показывает, что при переключениях в режиме реального времени весьма вероятны ошибки, а их исправление нередко представляет собой нетривиальную задачу. Упомянутый выше подход, реализованный в своё время инженерами Google, представляется значительно менее затратным и в конечном счёте более надёжным.
Старайтесь делать ваши планы и сценарии реалистичными и по возможности состоящими из типовых операций, выполнение которых командам восстановления легче доводить до совершенства, так как в условиях реальной катастрофы часто не остаётся времени для творчества.
Регулярно проводите тренировки, разбирая каждую ошибку. Не занимайтесь, как было принято говорить во времена СССР, «лакировкой действительности» и старайтесь поддерживать (по крайней мере внутри ИТ-подразделения) «культуру без обвинений» (no blame culture), в отсутствие которой сотрудники не только не заинтересованы говорить об ошибках, но иногда и реально боятся этого.
Управляйте рисками, следите за новыми угрозами и регулярно оценивайте влияние и вероятность уже существующих. Внимательно изучайте чужой опыт – поверьте, это гораздо менее болезненно, чем приобретать собственный. Примеряйте каждый зафиксированный и упомянутый в средствах массовой информации сбой ИТ-услуг на себя.
Сможете ли вы предусмотреть все возможные риски и варианты развития чрезвычайных ситуаций? Сможете ли быть готовыми ко всему? Конечно, нет. Но только тщательная подготовка и многократные тренировки позволят вам защитить ваш бизнес, компанию, деловую репутацию и ваших сотрудников. И достичь этого без управления непрерывностью точно не получится. Поэтому данная практика должна быть в фокусе внимания руководителей всех уровней. А накопленного в мире опыта точно достаточно, чтобы избежать «хождения по граблям» при внедрении этой практики в повседневную деятельность. И помните: «В критической ситуации вы не подниметесь до уровня своих ожиданий, а упадёте до уровня своей подготовки».
[1] На одном из наших учебных курсов слушателями было предложено простое и бесплатное управленческое решение – впредь печатать на квитанциях и координаты места хранения, но в данном конкретном случае это бы не помогло – внутренние перемещения шин осуществлялись и после их приёмки для оптимизации загрузки складов, а комфортный норматив доставки в выбранный клиентом сервис-центр (на следующий день после заявки) легко выполнялся пока… пока не перестал выполняться.
[2] ITIL Service Design (2011). 4.6.9.1 Challenges
One of the major challenges facing ITSCM is to provide appropriate plans when there is no BCM process. If there is no BCM process, then IT is likely to make incorrect assumptions about business criticality of business processes and therefore adopt the wrong continuity strategies and options. Without BCM, expensive ITSCM solutions and plans will be rendered useless by the absence of corresponding plans and arrangements within the business. Also, if BCM is absent, then the business may fail to identify inexpensive non-IT solutions and waste money on ineffective, expensive IT solutions.
[3] ГИКТОНБ – готовность информационно-коммуникационных технологий к обеспечению непрерывности бизнеса, термин из стандарта ГОСТ Р ИСО/МЭК 27031-2012).
[4] BCP (Business continuity plan), SCP (Service continuity plan), DRP (Disaster recovery plan) – различные документы из Service Continuity Management ITIL 4 Practice Guide.
[5] Сами авторы определяют целевую аудиторию так: «Книга будет полезна руководителям служб автоматизации (CIO) и служб информационной безопасности (CISO), внутренним и внешним аудиторам (CISA), менеджерам высшего эшелона компаний, ответственных за обеспечение непрерывности бизнеса, а также преподавателям и слушателям программ MBA, CIO и CSO, студентам и аспирантам соответствующих специальностей».
[6] 11.09.2001 в результате известных событий обе башни обрушились с интервалом в 29 минут.
[7] ITIL 4: High-velocity IT (2020). 4.3 Techniques for resilient operations
The potential value of digital investments can only be realized when the digital products and services invested in are available for use. Fulfilment of the non-functional requirements provides warranty, and reduces the risk that issues will adversely affect the utility of the products and services. Information systems increasingly rely on so many components that behaviour often cannot be predicted or guaranteed. Failsafe systems are an illusion. The organization must be prepared for inevitable and unexpected failure. The emphasis is no longer on a long interval between failures – it is on restoring service quickly when the inevitable issues occur. This reduces the disruption to business operations.
[8] Поппендик, Мэри, Поппендик, Toм. Бережливое производство программного обеспечения: от идеи до прибыли.: Пер. с англ. М.: ООО «И.Д. Вильямс», 2010.
[9] Центр обработки данных.
[10] Последний, но не по значению (англ.).
[11] KPI (Key performance indicators) – ключевые показатели эффективности.
[12] Чарльз Гудхарт (англ. Charles Goodhart; род. 23 октября 1936 года, Лондон, Великобритания) – главный советник по денежно-кредитной политике Банка Англии и профессор Лондонской школы экономики и политических наук, постулировал в 1975 году, что любая наблюдаемая статистическая закономерность склонна к разрушению, как только на неё оказывается давление с целью управления (any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes).
[13] RTO (recovery time objective) – целевое время восстановления услуги; RPO (recovery point objective) – целевая точка восстановления услуги; основные показатели непрерывности.
