Рубрика «аварийное восстановление»

Как вы уже знаете (с предыдущей статьи), компания Loon уделяет особое внимание обеспечению связи по всему миру с помощью атмосферных шаров. Полезная во время стихийных бедствий, компания Alphabet вновь продемонстрировала универсальность своего подхода, быстро обеспечив LTE связь после землетрясения магнитудой 8,0 в Перу, когда все хотели знать о состоянии и благополучии своих близких.

Аэростаты Loon обеспечивают аварийное подключение к сети и интернет в Перу после землетрясения магнитудой — 8,0 - 1

26 мая 2019 года сильное землетрясение обрушилось на отдаленный регион Перу — Амазонку. Благодаря существующему коммерческому тестированию и работе с Telefónica по обеспечению доступа к мобильному интернету в районах с недостаточным уровнем доступности, компания Loon смогла обеспечить связь в течение 48 часов.

В воскресенье утром в регионе произошло землетрясение магнитудой 8,0. По просьбе правительства Перу и Tefónica мы быстро перенаправили группу воздушных шаров в пострадавшую зону. Ранним утром во вторник прибыли первые воздушные шары и начали обслуживать LTE пользователей, находящихся внизу. Скоро прибудет еще больше шаров.

Читать полностью »

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

  • RPO (recovery point objective) – допустимая потеря данных. Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) защиту своих данных от потери выше приемлемого уровня.
  • RTO (recovery time objective) – допустимое время восстановления данных Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) возможность восстановления своей работы в приемлемый срок.

Часто эта пара показателей отображается в виде одномерного графика вдоль оси времени.
Но в таком одномерном графике нет самого главного, на что ориентируется бизнес – денег! О том, как рассчитывать RTO и RPO, исходя из требований бизнеса, я расскажу под катом.

Обеспечение доступности данных и сервисов: показатели RPO, RTO и планирование SLA - 1


Читать полностью »

Объяснительная записка

Публикую журналированный результат работы по обеспечению себя универсальным живучим образом установленной операционной системы (далее ОС) Windows XP SP3.

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

Почему это нужно?

Фривольное клонирование ОС MS Windows XP - Server 2003 своими руками, средствами GNU-Linux - 1

Что отличает данный материал от распространенных статей на тему клонирования ОС? Ограничения, поставленные передо мною жизнью и самим собой. Перечислю их:

1) ОС должна устанавливаться и работать на разделах произвольных размеров;
2) ОС должна исправно загружаться, будучи установленной на любой тип носителя, поддерживающий загрузку (оснащенный MBR*);
3) ОС должна функционировать на различных вариантах аппаратно-зависимого уровня (HAL**);
4) Образ ОС должен занимать минимум места на носителе для ускорения его переноса, дооснащения, переборки;
5) Образ ОС должен включать в себя необходимый набор установленного и настроенного лучшим образом ПО (вариант «система под ключ»);
6) Все манипуляции по приготовлению образа и по его развертке должны производиться штатными средствами GNU/Linux***. Смысл: разобрать по косточкам принцип работы имеющегося ПО для клонирования ОС;
7) Носителем образа ОС может быть сервер в сети, USB-накопитель (твердотельный либо винчестер), оптический или жесткий магнитный диск;
8) Носитель образа ОС должен быть оснащен средствами диагностики и ремонта ПО компьютера;
9) Желательно процесс клонирования ОС сделать максимально доступным ради хорошей повторяемости без урезания надежности результата;
10) Команда dd, безусловно, хороша, вот только неохота возиться с пустым пространством, нулями и отсутствием четкого вывода текущего действия. Кроме того, раздел, в который будет установлен клон, должен быть произвольным (см. п. 1).

Вне рассмотрения:

1) Юридические моменты установки неподдерживаемой ныне ОС;
2) Активация неактивируемой ныне официально ОС;
3) Целесообразность производимых действий. Не задротствакрасноглазия ради, но токмо волею пославших меня юзеров. Пославших за попытку убедить в кошерности использования свежего свободно-распространяемого программного обеспечения на их дуболомных машинах;
4) Подробности типовой установки ОС Windows XP и доп. ПО на компьютер, за исключением разбивки диска;
5) Подробности метода сетевого клонирования: рассмотрю в дальнейшем, сейчас такой нужды не имею.

Кому это нужно?

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

Конструктивная критика приветствуется; особенно ценны предложения по совершенствованию способа, а также теория, обосновывающая замечания.

Дата написания статьи — 2 декабря 2014 года, посему будущим поколениям шлю свой привет, а насколько сохранится актуальность материала для вас — не ведаю.

Добро пожаловать, %username%, под отрезок.
Читать полностью »

Соотносим потребности бизнеса с его возможностями

Планирование аварийного восстановления. Часть третья — заключительная

В предыдущих статьях (1,2), посвященных вопросам планирования аварийного восстановления, были описаны процедуры сбора и обработки информации об ИТ-инфраструктуре организации, позволяющие получить точную информацию о:

  • ИТ-сервисах, критичных для бизнеса компании,
  • Текущем времени восстановления их работы в случае сбоя,
  • Минимально достижимых сроках аварийного восстановления,
  • Необходимых ресурсах для их достижения.

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

Данный этап полностью состоит из согласования с руководством компании следующих аспектов взаимодействия:Читать полностью »

Готовимся к любым падениям

Планирование аварийного восстановления. Вторая часть

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

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

Определяем места, где стоит подстелить соломку

Планирование аварийного восстановления. Часть первая

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

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

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

Привет. Ответьте себе на один простой вопрос: давно ли вы в последний раз делали резервную копию данных своего компьютера? На Хабре, конечно, отношение “забэкапленных” пользователей и “незабэкапленных” чуть отличается от среднего по миру (в лучшую, разумеется, сторону), но всё равно показатель далёк даже от 50%. Так что вопрос “давно ли вы делали бэкап”, скорее, риторический: хорошо если встроенные в ОС средства восстановления после сбоев были настроены и занимались каким-то своим резервным копированием, полный бэкап всех критических, чувствительных или просто важных данных делают всё ещё очень и очень редко. И это при копеечной стоимости (и внушительных объёмах) современных жёстких дисков.

Image #2073660, 70.1 KB

Почему пользователи беспечно относятся к своим данным? Ответ, на самом деле, простой:
Читать полностью »

Резервная площадка в облаке

Для подавляющего большинства компаний наличие двух или более собственных площадок все еще остается непозволительной роскошью. И что же делать с обеспечением непрерывности оказания ИТ-сервисов в такой ситуации? Вывод очевиден: если по каким-то причинам нет возможности использовать публичное облако в качестве основной площадки – его можно успешно использовать в качестве резервной!

Читать полностью »

Моя работа — ждать IT катастрофы

Лучшее, что может случиться, — это если результаты того, что я делаю, никогда и никому не пригодятся.

Можно сказать, что я профессиональный параноик: моя задача — разрабатывать планы действий на случай чрезвычайных ситуаций и обучать людей грамотно реагировать в таких случаях. Зачем это нужно? Довольно просто — чтобы в случае непредвиденных ситуаций всегда была страховка.

Вот, например, знаете что будет, если землетрясение уничтожит основной московский ЦОД?

  1. Сработает автоматика и перебросит часть сервисов на другие ЦОДы. Всё то, что было active-active, продолжит работу (это базовые функции сети, вроде звонков и SMS).
  2. Затем включается базовый сценарий реакции. Сразу после происшествия формируются команды восстановления из специально обученных людей на объекте, имеющих подготовку по всем аспектам работы этого объекта. Например, из инженера на смене, охранника, системного администратора и так далее. Они бросают все свои текущие дела и занимаются только восстановлением.
  3. В течение первых 10 минут «бронзовая» команда восстановления анализирует ситуацию. На 11-й минуте руководитель команды докладывает команде более высокого уровня («серебряной», как правило, не присутствующей на объекте), например, главному инженеру и руководителю подразделения.
  4. «Серебряная» команда принимает решение на своём уровне. В нашем случае проблема явно особенно важная, поэтому команда связывается с «золотой» командой — руководителями самого высокого уровня. На принятие решения о том, что ситуация является чрезвычайной, уходит ещё 10 минут (это очень быстро). В течение ещё 5 минут активируются составленные нами планы аварийного восстановления.
  5. Руководители «бронзовых» команд собирают людей и идут восстанавливать, что могут, на месте. Параллельно собирается кризисный комитет, включающий известных специалистов, описанных в плане на этот случай.
  6. Далее кризисный комитет взаимодействует с HR, PR, безопасниками и другими службами. В частности, совершенно точно PR к этому моменту будет остро нуждаться в информации — абоненты уже полчаса без мобильного из интернета, нужно выступить с данными о сроках восстановления.
  7. Разворачивается резервная точка. В течение 20-30 минут восстанавливается инфраструктурный слой. Затем идет восстановление СУБД и там, где надо, восстановление из архива с ленты. Далее — восстановление приложений (от получаса до дня).
  8. Параллельно в течение первого часа проверяется, как всё переехало.
  9. Затем появляются детальные отчёты. План аварийного восстановления заканчивается, и мы снова «засыпаем» до следующей ситуации.

Читать полностью »

Представьте, что ваш дата-центр (или боевой сервер) сегодня упал. Просто взял и упал. Как показывает практика, готовы к этому далеко не все:

  • 93% компаний, которые теряли свой ЦОД на 10 и более дней из-за катастрофы, стали банкротами в течение года (National Archives & Records Administration in Washington)
  • Каждую неделю в США выходит из строя 140 000 жестких дисков (Mozy Online Backup)
  • У 75% компаний нет решений для аварийного восстановления (Forrester Research, Inc.)
  • 34% компаний не тестируют резервные копии.
  • 77% тех, кто тестируют, обнаруживали нечитаемые накопители в своих библиотеках.

В предыдущих постах (раз и два) я писал про организационные меры, которые ускорят и облегчат восстановление ИТ-систем и связанных с ними процессов компании при чрезвычайной ситуации.

Катастрофоустойчивые IT системы: как внедрить в своей компании

Сейчас поговорим про технические решения, которые в этом помогут. Их стоимость разнится от нескольких тысяч до сотен тысяч долларов. Читать полностью »