Pull to refresh
140.51

Работа параноика: планы аварийного восстановления/непрерывности, метеорит, зомби-апокалипсис, 1000 уборщиц, портал в ад

Reading time 13 min
Views 35K

Схема отработки аварии первого уровня в «Мультикарте»

Есть такой миф, что у нас отказоустойчивых инфраструктур у крупных компаний не было примерно до 2007 года. Мол, именно тогда начали появляться документы DRP (аварийного восстановления), выделяться отделы риск-менеджмента и так далее.

Это неправда. Просто до этого не было методологии и английского названия, а сами системы были. Первым проектом, который стали «называть по правилам», была инфраструктура «Альфы». В Сбербанке и «Транснефти», насколько я знаю, отказоустойчивая инфраструктура тоже была испокон веков, но только называлась «резервный центр обработки данных». И так далее.

А теперь поехали развеивать другие мифы про DRP и непрерывности. Ну и заодно расскажу про наш последний проект — аварийные планы «Мультикарты», то есть той системы, через которую идут все ваши оплаты картами в России.

Ну и, конечно, истории былинных провалов.

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

Хотя исторически в Москве большая часть серьёзных планов начала писаться в 2005-м. Тогда много чего поотказывало. До 2005-го можно было просто отнести оборудование в соседнее здание, и это считалось нормой. Когда же упала подстанция и сеть питания на полгорода попросту рухнула, ко многим сразу пришло новое видение. Где-то соляра по пробкам не пробралась до ЦОДа. Где-то дизель два года не проверяли, там ДТ разлагалось на фракции, и в итоге ДГУ схватили по куску воды. Помню, когда ВТБ выбирал место для нового ЦОДа (мы помогали немного), смотрели на карту энергетических зон Москвы далеко не в последнюю очередь.

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

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

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

— Такой уровень паранойи, чтобы писать планы непрерывности, есть только в банках.
Это не так, конечно же. Последние 7–8 лет непрерывностью занимаются четыре отрасли: банки, страховые компании, телеком и розница. С первыми тремя понятно: по фактической структуре они и являются банками, и разницы на уровне инфраструктуры между тем же сотовым оператором и крупным банком часто намного меньше, чем между двумя интернет-провайдерами. Потому что занимаются они, по сути, одним и тем же. Миф связан с тем, что только у финансовых учреждений есть регуляторная база в виде контроля на уровне стандартов Центробанка и международных штучек в виде аудитов от головных организаций. Все банки и большинство операторов раз в год проверяются. В случае проблем могут отозвать лицензию. Никто не хочет объяснять в телевизоре, почему бабушки не смогли получить пенсию.

Отдельно стоит розница — она, как правило, ориентируется только на себя (на свою прибыль) и прекрасно понимает, что простой недопустим. Если ты стоишь сутки — ты теряешь суточный оборот плюс кучу клиентов на будущее.

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

— Аварийное восстановление — работа ИТ-отдела.
Несмотря на то, что основные риски чаще всего лежат в области отказа узлов ИТ-инфраструктуры, это всё же делает не ИТ-отдел. И не безопасники. И уж, конечно, не финансовый отдел. Однако инициативы по управлению риском обычно исходят из этих трёх точек, поэтому поначалу в компании выделяется основной ИТ-риск, и именно ИТ-специалисты начинают его решать (это истории 2000–2005 годов). Как правило, затем начинается трезвая финансовая оценка каждого этапа бизнеса и появляется понимание, что есть и другие риски, — в процесс включается PR-отдел, служба обеспечения (например, для развёртывания временного офиса), кадровики и прочие, прочие, прочие. В итоге выделяется отдельная команда или даже отдел, который занимается именно минимизацией рисков.

Происходит обычно так: начинают обследования инфраструктуры и процессов управления. Методологии используются самые разные — от ISO до ITIL. Выполняется сбор вариантов угроз и анализ их воздействия. Затем построение политики, появление положения о непрерывности, аварийные планы. Когда с базовой частью покончено, идёт детализация по всем процессам: управление конкретными инцидентами, «аварийные конверты», планы регламентных работ, проработка сценариев параноиков. Идёт выстраивание процесса управления непрерывностью. Затем тестирование, учения, работа с кадрами по типу «что делать», консультации.

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

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

— Разработка планов аварийного восстановления — это очень-очень дорого.
И да и нет. Дело в том, что обычно такая работа (речь про риск-менеджмент в целом, не только в ИТ) поручается аудиторо-консалтинговым компаниям с громким именем и большим портфелем проектов. Не хочу хвалиться. Но, собственно, наши аналогичные услуги банально дешевле, а бизнес при этом знаем лучше, потому что как минимум треть крупных ИТ-инфраструктур в России мы строили своими же руками. Конечно, мы не торгуем своим именем, но именно непрерывность бизнеса делаем хорошо.

Надо отметить, что на стороне «большой четвёрки» — идеально вылизанная на западном рынке методология и хорошие автоматизированные продукты (то есть они своего рода «Макдональдс» рынка). Быстро, предсказуемо. Но картошку жарит студент. Собственно, это рождает ещё одно следствие, которое позволяет нам конкурировать с этими крутыми парнями в России: они работают ровно по процессу, шаг влево или вправо — расстрел. А в реальном бизнесе не всегда это подходит. Ситуация ещё веселее (скажем так, основанная на эмпирическом опыте и реальных событиях), когда такой игрок приходит на наш рынок, выставляет огромный прайс, получает оплату, а потом нанимает кого-нибудь из местных на субподряд. Естественно, приходили с такими предложениями и к нам.

— Надо сделать усилием воли DRP-план и не беспокоиться.
К сожалению, так не выйдет. Это как с безопасностью: нельзя один раз установить правила и всех обучить. При появлении любого нового проекта в компании в него сразу же нужно закладывать требования как к безопасности, так и к аварийному восстановлению. Например, сделали сервис — надо сразу же на уровне внутренних стандартов требовать, чтобы он умел мигрировать на вторую площадку в дата-центре, описать, что и как делать в случае аварии с ним (гасить или нет при деградации каналов), назначить приоритет восстановления, обновить множество документов для техслужб, безопасников, ИТ-отдела. Прописать, какие нужны профилактические работы и когда. И это только самое простое.

Ещё постоянно меняются внешние риски. Например, геополитические риски после 2011 года получили приоритет. Это означает изменение всех планов, иногда даже изменение самих процессов управления (у тех, у кого DRP стоит на таком уровне). Опять же, пример — когда проходили митинги в Москве с участием 100 тысяч человек вблизи основного офиса крупного российского банка, он взял и перекинул всё в резервный дата-центр. Потому что вокруг начал бегать ОМОН, а есть примета, что если рядом бегает ОМОН, то могут вырубить свет.

Или вот одного большого сотового оператора аудировали с Запада. Под них сделали планы непрерывности с кирпич толщиной. Эти планы никто не актуализировал. Прошло несколько лет. Появились новые регионы, сменилась сама структура оператора. А потом в далёкой-далёкой галактике начали падать бесперебойники в ЦОДе. Инженер выключает серверы, а они включаются обратно. И такая карусель с полчаса примерно. Включили план аварийного восстановления, а вся IP-адресация уже новая. Привет.

Кстати, отгадка включений-выключений не имела отношения к DRP, но была очень забавной. Вылетели ИБП — как следствие, серверы начали греться. Инженер их гасил. В это время по thermal shotdown отключались батареи. Нагрузка падала, всё это остывало, а затем автоматически всё включалось. Опять начинался нагрев. В итоге скачки шли ещё полтора часа после переключения, пока искали проблему.

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

Документы нужны такие:


— Делаем active-active и не паримся!
На практике опытные CIO очень не любят балансировку между дата-центрами. Дело в том, что на моей памяти ещё ни одна история с active-active не проходила проверку временем. Сначала всё выглядит идеально. Заходит команда, делает балансировку, процесс начинается. А потом он растягивается, растягивается…

В одной системе 200–300 точек интеграции — невозможно следить. Сценарии должны быть реалистичные. Даже если заказчик говорит про постоянно обновляемые планы и инфраструктуру, стоит сделать пробное тестирование. Мы делаем такое за символические деньги, просто в обучающих целях. На моей памяти никто не прошёл. Заказчики сами видят, где начинается реальный мир.

Помню, были масштабные учения с тестированием — отключали один из активных дата-центров в схеме active-active-backup. Это случилось примерно через год после того, как сделали балансировку. План тестирования был поминутный, очень детальный. Всё шло хорошо, но только вот в момент переключения VMware вдруг выяснилось, что есть такое место, куда накатывается разница виртуалок. Только сам золотой образ во втором ЦОДе немного отставал по версии. Буквально чуть-чуть. И вот при попытке зацепить обновлённые машины Linux-кластер упал, как озимые, в kernel panic. Вместо получаса простоя стало 5 часов. Дальше страшные слова: «Не попали в окно».

Этот тест был мягкий — не рубильник дёргали, а просто корректно изолировали основной ЦОД. С другой стороны, помню совсем другое тестирование офисных сервисов. Там, когда переключали площадки для проверки сценария, заткнули не все дырки в синхронизации. И часть звонков кол-центра и трафика офиса пролезли не в ту сторону. Данные покорраптились. А там карточки клиентов с транзакциями. Связаны с примерно двумя сотнями подсистем.

Например, согласование договоров. Самый простой процесс от согласования платёжного поручения до оплаты — 14 логических шагов. В одной из стадий, например, база восстановилась с разлётом в 10 секунд. И всё, привет документам. Oracle поднялся? Да. База хорошая? Да. Документы можно использовать? Нет. С бухгалтерией порядок? Ну, почти — на 40 копеек баланс не сходится. И главбух чего-то, видя это, катается в истерике.

По логике, надо либо ковырять руками пару месяцев после получасового падения, либо проверять логику проводки автоматически. Именно поэтому есть два следствия:

  1. Либо делаются хитрые системы реалтайм-мониторинга, когда проход завершён (ставится галочка). И делается запрос по всем подсистемам, прошло ли. Банк из топ-5, например, явно заинтересован в таком мониторинге целостности всех процессов. У них там может быть перевод с 9 нулями в сумме. Если покорраптить такую транзакцию — ну, будет немного печально.
  2. Либо резервный дата-центр — это именно резерв. Никаких частичных использований, утилизации простаивающих мощностей. Если что — расконсервируем и живём до полугода в нём, причём чтобы мощность железа была достаточная.


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

— Ок, давайте в следующем году сделаем аварийный план для всей компании и...
Не получится. Скорее всего. В малом и среднем бизнесе это работает, а в большом — нет. Нельзя единовременно перевести ЦОД на DRP, когда там 270 подсистем. Надо разбивать на блоки и есть слона по кускам, потихоньку реализовывать блочное переключение.

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

Иногда это спасает людей, надо сказать. Знаю случай, когда монтировали новое оборудование, «тяжёлые» стойки. Первая особенность помещения — огромная гермодверь на входе в машзал. Вторая — очень толстые плитки фальшпола были, и надо было в них делать кабельные вводы. Стали сверлить. Наверху стоит двухконтурный датчик — температура и дым. Сработка по дыму. Делали бы по-западному, гермодверь бы закрылась и пошёл газ. У нас, к счастью, в эксплуатацию не приняли, и потому дверь была припёрта блоком.

Или вот ещё вопрос. Как будет работать DRP, если всё в голове администратора? Любимая фраза с тестов: «Хмммм… Как резолвится? Ну, вроде, по DNS-записи… Где IP-адреса? Ну, где-то были записаны...».

— Хватит пугать! Дата-центры делают взрослые люди, и...
… и они всё равно падают, даже у очень взрослых и собранных людей. Примеры:
  • В крупнейшей в России независимой системе процессинга платежей United Card Service произошёл сбой на 5 часов 20 минут. Клиенты 140 банков — партнёров UCS — не могли воспользоваться своими картами, снять наличные в банкоматах. Тогда зависли тысячи трансакций россиян. Полное восстановление неполадок осложнилось тем, что его не удалось осуществить удалённо, без непосредственного доступа к серверам в дата-центрах. Помимо этого, для восстановления потребовалось провести исчерпывающую диагностику всей инфраструктуры. Использование же резервных систем было крайне рискованно и могло привести к большой потере данных, так как причины сбоя на момент аварии были неясны.
  • Сбой в UCS 21 августа превзошёл масштабы сбоя в НСПК, который произошёл 29 апреля 2015 года. Тогда из-за сбоя в системе ЦБ не обслуживались операции по картам MasterCard и Visa на протяжении более четырёх часов, ориентировочно с 2:30 до 7:15 мск. Сбой не носил системный или программный характер.
  • В сентябре 2008 года в течение нескольких часов без связи находилось 5% абонентов «Билайна». HLR в течение часа поднимали руками.
  • 27 июля из-за аварии в одном из дата-центров «ВКонтакте» несколько часов были недоступны некоторые сервисы сайта: фотографии, сообщения, записи на стенах. Через час после возникновения проблем специалистами компании было принято решение полностью прекратить работу сайта. По непроверенным данным — проблемы с охлаждением.
  • Официальный сайт Института научной информации по общественным наукам (ИНИОН) РАН перестал работать, когда в здании библиотеки начался пожар. Серверы находились на первом этаже постройки и при тушении огня промокли.
  • Сотни сайтов, хостящихся на серверах дата-центра «Бункер» компании «МедиаСофт эксперт», оказались недоступны. При строительстве эстакады на Ярославском шоссе строители вбили сваю в телефонную канализацию. В результате произошёл обрыв двух кабелей, которые связывают ЦОД и ММТС-9 (длина кабелей около 70 км, они идут в основном разными маршрутами, в одной канализации не более 6 км). По стечению обстоятельств именно на этом небольшом участке и произошла авария.
  • В работе системы бронирования Sabre произошёл глобальный сбой, который сказался на работе нескольких авиакомпаний по всему миру. В России он затронул «Аэрофлот». Из-за сбоя регистрация пассажиров проходила вручную, были задержаны 15 рейсов.
  • На Московской бирже произошёл краткосрочный сбой, из-за которого торги на срочном рынке остановились на четыре минуты. Причиной сбоя стала некорректная работа балансировщика. 4 минуты по меркам биржи — это несколько веков.
  • Масштабный сбой в багажной системе терминала D, из-за которого были задержаны шесть тысяч чемоданов, произошёл 2 августа 2013 года. Причиной ЧП также стал сбой в специальной программе обслуживания.


Но вот за пределами России...
  • Ок, пожалуйста, вот вам примеры:
  • Из-за пожара в здании дата-центра Samsung SDS возникли проблемы при получении доступа к Сети у пользователей устройств Samsung (смартфонов, планшетов и телевизоров с интернетом) по всему миру.
  • У Facebook случились проблемы с сервером, в результате чего у пользователей возникали проблемы с мобильными приложениями, плагины на веб-сайтах сообщали об ошибках соединения. Все эти неприятности коснулись более 1,3 миллиарда пользователей Facebook по всему миру. По подсчётам Forbes Magazine, 20-минутное падение стоило Facebook полмиллиона долларов, которые компания потеряла из-за отсутствия рекламы в течение этого времени.
  • На 40% снизились объёмы мирового интернет-трафика в течение того времени, пока серверы Google были недоступны. Отключение сервисов Google, среди которых Gmail, YouTube и Google Drive, длилось около пяти минут. А 5-минутный сбой в 2012 году стоил Google $545,000 выручки.
  • Более 10 млн пользователей смартфонов Blackberry в регионе EMEA (Европа, Ближний Восток и Азия) оказались отрезаны от внутренних протоколов связи. Причина — перебой питания в серверной Research In Motion в Беркшире.
  • Amazon что-то сделал с Сетью и уронил Instagram, Netflix, Vine, Airbnb и другие сервисы (новость от 26 августа 2013 года).
  • Пожар на 5-мегаваттной биткоин-ферме в Таиланде унёс оборудования на миллионы долларов.
  • Проблемы с ИБП вывели из строя сразу два ЦОДа в Нью-Йорке летом 2014-го.
  • В 2010-м Virgin Blue упала на 11 суток. Потери составили от 15 до 20 миллионов долларов. 50 тысяч пассажиров не смогли совершить запланированные полёты.
  • Сингапурская телекоммуникационная компания M1 была оштрафована на рекордную сумму — 1,2 миллиона долларов — за сбой Сети в январе 2013 года. Простой длился 3 дня.



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

Риски


С мифами, вроде, всё. Теперь давайте посмотрим на типовые риски. Про учения не говорю, но проиграйте в голове каждый для себя хотя бы.
— Повреждение здания или техплощадки в результате техногенной или природной катастрофы.
— Пожар.
— Потеря зданий и помещений в результате террористических атак / военных действий / массовых беспорядков.
— Вандализм, злонамеренные действия конкурентов.
— Блокирование доступа в здания организации.
— Сбой электроснабжения на любой из площадок.
— Повреждение коммуникаций за пределами площадок.
— Потеря магистрального канала между площадками.
— Выход из строя незарезервированного сетевого оборудования.
— Сбои инженерной инфраструктуры.
— Отказ ИТ-систем (по сервисам и узлам).
— Отказ систем мониторинга инфраструктуры.
— Одновременная недоступность двух площадок.
— Невозможность удалённого доступа к Сети компании.
— Невосстановимая потеря данных на электронных носителях.
— Потеря возможности производить резервное копирование.
— Потеря произведённых резервных копий.
— Недостаточное гранулирование резервных копий.
— Невосстановимая потеря данных на рабочих станциях пользователей.
— Риски низкого уровня зрелости внутренних процессов. Плюс риски неоднородности или разорванности информации на уровне подразделений или приложений (т. е. один и тот же процесс может существенно различаться от подразделения к подразделению, к отделу).
— Отсутствие документированных описаний предоставляемых критичных бизнес-сервисов. Отсутствие согласованных и отработанных планов действий в случае ЧС.
— Слабая степень отчуждаемости информации в пользу компании.
— Слабое документирование конфигураций.
— Вирусы / вредоносное ПО.
— Злонамеренное повреждение ИТ-систем.
— Кража оборудования, изъятие оборудования силовыми структурами.
— Невыполнение обязательств поставщиками, в т. ч. в случае одновременного воздействия ЧС на компанию и её поставщиков. Неисполнение поставщиком обязательств вследствие действия санкций. Злонамеренные действия сотрудников поставщика. Раскрытие поставщиком информации конфиденциального характера.
— И, наконец, невосстановимая потеря данных (на бумажных носителях).

Ссылки


Tags:
Hubs:
+33
Comments 6
Comments Comments 6

Articles

Information

Website
croc.ru
Registered
Founded
Employees
1,001–5,000 employees
Location
Россия