«Это катастрофа, шеф!» — как облако помогает восстановить ИТ-инфраструктуру

Рассказываем, на что обратить внимание при планировании аварийного восстановления: что может сделать сама компания, а где поможет облачный провайдер. А также обсуждаем, какие установки мешают компаниям грамотно организовать катастрофоустойчивую инфраструктуру (Disaster Recovery) и прислушаться к мнению ИТ-специалистов на местах.

Прежде чем переходить к советам — вот пара моментов, которые порой ускользают от тех, кто не занимается аварийным восстановлением непосредственно:

1. Disaster Recovery не то, чем кажется

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

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

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

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

2. DR — это коллективная ответственность

Еще одно заблуждение, которое встречается среди управленцев, состоит в том, что DR — целиком и полностью прерогатива системных администраторов. Учитывая, что обрушить инфраструктуру могут происшествия разной природы (многие из которых относятся к компетенции безопасников), разграничивать «ИТ-проблемы» и «ИБ-проблемы» в ряде случаев как минимум неэффективно. Если между подразделениями нет диалога, не выстроена схема совместной работы и не продуманы стратегии коллективного реагирования, при наступлении соответствующего риска может начаться перекидывание ответственности — «это не наше дело».

3. Перспектива восстановления «вручную» — сильнейший демотиватор

Хуже отсутствия диалога по поводу DR между подразделениями может быть полное отсутствие DR. Конечно, чаще всего это касается малого и (много реже) среднего бизнеса. Тем не менее, уверенность менеджмента в том, что, в случае чего, базы, кластеры и поды можно «починить руками», резко уменьшает желание ИТ-специалистов продолжать работать в компании.

В качестве иллюстрации можно привести историю одного из пользователей Reddit. Компания, в которой он работал (кстати, не такая уж и маленькая — в несколько сотен сотрудников), отказывалась хранить резервные копии на удалённой площадке. В итоге сисадмин самостоятельно реализовал «единственно возможный» в этом случае план аварийного восстановления: отложил немного денег из зарплаты и уволился, когда офис, в котором располагалась серверная, накрыл ураган Иэн. Вероятно, этот вариант Disaster Recovery не приходил в голову его руководству и обошелся бизнесу много дороже, чем бэкапы в облаке, которые предлагал им специалист.

4. Если у вас все хорошо, это не значит, что так будет всегда

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

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

В противовес излишнему оптимизму ученые выдвигают стратегию «защитного пессимизма»: она помогает более точно оценить степень риска, предпринять меры по его минимизации, а в случае наступления негативного события действовать более собранно и добиваться лучших результатов. Пожалуй, одним из ярких примеров такого поведения является кейс Intel. В 70-х компания производила плашки оперативной памяти и занимала 80% мирового рынка. Но уже в 1980-х она начала стремительно уступать японским конкурентам. CEO предвидел худший сценарий — полную потерю рынка, поэтому принял грамотное решение переориентироваться на производство микропроцессоров.

Те, кто не принимает ситуацию как должное, критически оценивает собственные возможности и уделяет внимание негативным сценариям («вдруг что-то пойдет не так — что мы будем делать?»), оказывается в выигрыше. Иначе говоря, «защитный пессимизм» — пожалуй, лучшая предпосылка к планированию DR.

1. Начать с простых шагов

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

2. Подготовить план DR

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

3. Протестировать его

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

Важно понимать, каким бы комплексным ни был план disaster recovery, в нем невозможно предусмотреть абсолютно все сценарии — не стоит разрабатывать универсальную стратегию «от всего на свете». Размытые формулировки и отсутствие четких шагов только ухудшат и без того неприятную ситуацию, если инцидент все-таки произойдет. Наоборот, специалисты рекомендуют составлять план DR так, чтобы он покрывал узкие кейсы, не оставляющие места для вольных интерпретаций. Так, в случае потери главной базы данных, должна воспроизводиться одна последовательность шагов, а при падении биллинга — другая.

4. Подумать об увеличении стоимости взлома

В контексте кибербезопасности можно выделить еще один способ повышения катастрофоусточивости — увеличение стоимости взлома.

Идея состоит в том, чтобы сделать взлом настолько дорогим и времязатратным для злоумышленников, насколько это возможно. Добиться этого можно самыми разными способами, начиная с обязательной многофакторной аутентификации для сотрудников, использующих корпоративные аккаунты, до построения полноценной архитектуры нулевого доверия (Zero Trust Architecture). В таком контексте хакерам потребуется регулярно подтверждать свои права доступа, что значительно увеличивает стоимость атаки.

Более экзотичным вариантом может быть построение специальных поддельных окружений — ханипотов, которые мимикрируют под реальные ИТ-ресурсы. Злоумышленники вынуждены взаимодействовать с такими системами и тратить свое время, а безопасники получают возможность следить за их активностью. Правда, здесь, как и в целом в отношении DR, важно грамотно рассчитать точку безубыточности — затраты на поддержание доступности данных и сохранение их в целостности не должны превышать расходы от их потери.

5. Крупным компаниям — обратить внимание на мультиоблако

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

Концепция мультиоблака действительно набирает обороты в бизнес-среде. Согласно опросу, проведенному компанией Oracle среди полутора тысяч сотрудников крупных компаний (со штатом > 1000 человек), 98% работают как минимум с двумя облачными провайдерами, а 31% — размещает инфраструктуру у четырех игроков. В то же время появляются и open source инструменты для управления несколькими облаками — например, Mist и Cloudforet. Последний входит в состав The Linux Foundation.

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