Drp файл что это
Готовим DRP — не забудьте учесть метеорит
Даже во время катастрофы всегда есть время на чашку чая
DRP (disaster recovery plan) — это штука, которая в идеале никогда не понадобится. Но если вдруг мигрирующие в брачный период бобры перегрызут магистральное оптоволокно или джуниор-админ дропнет продуктивную базу, вы точно хотите быть уверены, что у вас будет заранее составленный план, что с этим всем безобразием делать.
Пока клиенты в панике начинают обрывать телефоны техподдержки, джуниор ищет цианиды, вы с мудрым видом вскрываете красный конверт и начинаете приводить все в порядок.
В этом посте я хочу поделиться рекомендациями, как надо писать DRP и что он должен содержать. А еще мы рассмотрим следующие штуки:
Для каких компаний это может быть полезно
Очень сложно провести границу, когда IT-подразделение начинает нуждаться в подобных вещах. Я бы сказал что DRP вам гарантированно нужно, если:
Документация важна
Начните с документации. Допустим, что ваш сервис работает на базе скрипта на Perl, который был написан три поколения админов назад, а как он работает, никто не знает. Накопленный технический долг и отсутствие документации неизбежно вам прострелит не только колено, но и другие конечности, это скорее вопрос времени.
После того, как у вас на руках есть хорошее описание компонентов сервиса, поднимите статистику по авариям. Почти наверняка они будут совершенно типовые. Например, у вас время от времени переполняется диск, что приводит к отказу ноды до ее ручной очистки. Или становится недоступен клиентский сервис из-за того, что кто-то опять забыл продлить сертификат, а Let’s Encrypt настроить не смог или не захотел.
Мысли как диверсант
Самая сложная часть находится в прогнозировании тех аварий, которых еще ни разу не было, но которые потенциально могут уложить ваш сервис полностью. Тут мы обычно с коллегами играем в злодеев. Берете много кофе и чего-нибудь вкусного и запираетесь в переговорке. Только убедитесь, что в этой же переговорке вы заперли тех инженеров, которые сами поднимали целевой сервис или регулярно с ним работают. Дальше либо на доске, либо на бумаге начинаете рисовать все возможные ужасы, которые могут произойти с вашим сервисом. Не обязательно детализировать вплоть до конкретной уборщицы и выдергивания кабелей, достаточно рассмотреть сценарий «Нарушения целостности локальной сети».
Обычно, большинство типовых аварийных ситуаций укладывается в следующие виды:
После того, как типовые проблемы записаны, наливаем еще кофе и начинаем рассматривать самые странные сценарии, когда какие-то параметры начинают сильно выходить за пределы нормы. Например:
Что такое этот ваш DRP?!
Итак вы определили модель угроз. Учли и местных жителей, которые режут оптоволоконные кабели в поисках меди, и военный радар, который роняет радиорелейную линию строго по пятницам в 16:46. Теперь надо понять, что с этим всем делать.
Ваша задача написать те самые красные конверты, которые будут вскрываться в аварийной ситуации. Сразу рассчитывайте, что когда (не если!) все навернется, рядом окажется только самый неопытный стажер, у которого будут сильно трястись руки от ужаса происходящего. Посмотрите, как реализованы аварийные таблички в медицинских кабинетах. Например, что делать при анафилактическом шоке. Медицинский персонал наизусть знает все протоколы, но когда рядом человек начинает умирать, очень часто все беспомощно хватаются за все подряд. Для этого на стене висит четкая инструкция с пунктами вида «открыть упаковку того-то» и «ввести внутривенно столько-то единиц препарата».
В аварийной ситуации думать сложно! Должны быть простые инструкции для парсинга спинным мозгом.
Хороший DRP состоит из нескольких простых блоков:
Как правильно тестировать
Убедитесь, что любой ответственный сотрудник в состоянии выполнить все пункты. В самый ответственный момент может оказаться, что у инженера нет прав на доступ в нужную систему, отсутствуют пароли от нужной учетки или он понятия не имеет, что значит «Подключитесь к консоли управления сервисом через прокси в головном офисе». Каждый пункт должен быть предельно прост.
Неправильно — «Зайдите на виртуализацию и ребутните мертвую ноду»
Правильно — «Подключитесь через веб-интерфейс к virt.example.com, в разделе ноды выполните перезагрузку ноды, которая вызывает ошибку».
Не допускайте двусмысленностей. Помните про испуганного стажера.
Обязательно тестируйте DRP. Это не просто план для галочки — это то, что позволит вам и вашим клиентам быстро выйти из критической ситуации. Оптимально сделать это несколько раз:
Ключевые пункты
BCP и DRP. Разница иногда не очевидна
Привет, хабр! Это скорее не статья-разъяснение, а статья-рассуждение о непрерывности и самая мякотка, надеюсь, будет в комментариях.
В силу того, что business continuity превратился в модный тренд, что-то вроде нанотехнологий, инноваций и импортозамещения, самое время определиться, что такое BCP и что такое DRP, в чем их разница и почему BCP и DRP как в том анекдоте «не муж и жена, а четыре совершенно разных человека».
BCP (business continuity plan) – план обеспечения непрерывности бизнеса. Содержит детальный план, что необходимо сделать для восстановления бизнес процессов.
DRP (disaster recovery plan) – план восстановления после катастрофы. Содержит детальный план по восстановлению инфраструктуры. Обычно имеется ввиду ИТ инфраструктура, но это могут быть самые разные механизмы, автотранспорт и здания.
Оба плана будут использоваться сразу после возникновения кризисной ситуации или катастрофы. Оба плана содержат набор инструкций и описание людей, которые эти инструкции должны выполнить. Оба плана должны периодически тестироваться, чтобы быть уверенным, что план жизнеспособен. Оба плана должны быть разработаны исходя из требований бизнеса*. Пожалуй, на этом сходство заканчивается и начинаются различия.
DRP – это план про восстановление. Если сгорел склад, то есть запасной склад на такой случай. Если в ЦОД пришли маски-шоу, есть резервный ЦОД. Если сломался автомобиль – есть запасные части для ремонта. Или резервный автомобиль. В зависимости от требований бизнеса, о которых мы поговорим в другой статье.
BCP – это план про непрерывность бизнеса, а точнее, конкретного бизнес процесса. BCP позволяет продолжить бизнес процесс после катастрофы или кризисной ситуации так быстро, как это необходимо для бизнеса.
При выходе из строя офисного здания DRP будет описывать как оперативно запустить новое офисное здание. BCP будет описывать, как организовать удаленную работу сотрудников. В случае, если удаленная работа невозможна, BCP будет включать в себя DRP, но не наоборот. И где-то в этот момент возникнет ощущение, что это одно и то же, но это не так.
В случае выхода из строя ЦОД, например, телекоммуникационной компании, BCP план будет описывать процесс переезда в резервный ЦОД и соответствующие коммуникации. DRP будет описывать переезд каждой системы. Фактически, в этом случае BCP план включает в себя много DRP планов.
BCP создается и тестируется совместно с представителями бизнеса. DRP создается и тестируется внутри ИТ подразделения.
Очень интересует мнение практиков, которые забороли путаницу в терминологии в непрерывности.
— * — требования бизнеса – это именно требования от бизнеса, а не размышления внутри ИТ департамента, как могли бы выглядеть бизнес требования.
Что такое Disaster Recovery
Disaster Recovery (аварийное восстановление) — это сервис восстановления ИТ-систем и данных после сбоя любого уровня. Как правило, предлагается облачными провайдерами как отдельная услуга или включается в состав крупного решения. Условно можно разбить на три составляющие: резервная площадка, программные решения и план восстановления.
Причины востребованности Disaster Recovery
Чем активнее компания использует ИТ-инфраструктуру, тем выше становится зависимость от её работоспособности. Сбои напрямую влияют на доходы организации, её репутацию. Они также негативно сказываются на эффективности сотрудников и комфорте клиентов. Поэтому компании тратят много ресурсов, чтобы снизить риск неполадок в работе инфраструктуры.
Помимо стабильности также необходимо обеспечить быстрое восстановление систем после сбоя. Чем скорее всё заработает, тем меньше негативных последствий для компании. Для этого существуют решения Disaster Recovery — системы аварийного восстановления ИТ-инфраструктуры после сбоя.
Disaster Recovery является частью плана обеспечения непрерывности бизнеса. Его идея в том, что компания должна работать, несмотря на внутренние сбои, кибератаки, другие инциденты. А в случае аварии — не потерять ценные данные и быстро восстановить работоспособность.
Для аварийного восстановления необходима параллельная IT-инфраструктура, которая будет использоваться для хранения данных и шаблонов виртуальных машин либо выступит в роли вспомогательной системы, которая возьмёт на себя рабочие задачи на время инцидента.
Чаще всего Disaster Recovery предлагают облачные провайдеры. Компании-клиенту предоставляются облачные мощности, на которых можно расположить резервную информационную систему (ИС). Основная же располагается в другом ЦОД. Между системами настраиваются каналы связи, чтобы данные одновременно поступали в основную и резервную ИС.
Важно понимать, что аварийное восстановление как сервис (DRaaS) отличается от бэкап-решений. Основная задача системы резервного копирования — сохранность данных в случае аварии. Disaster Recovery же отвечает за сокращение времени простоя ИТ-систем. Бэкап не даёт компании возможность продолжить работу на резервной платформе, пока будет восстанавливаться работоспособность основной. Услуга DRaaS гарантирует, что у компании будет площадка, идентичная основной, которая сможет сохранить непрерывность бизнес-процессов.
Ключевые параметры аварийного восстановления
У решений Disaster Recovery есть два основных параметра, которые влияют на стоимость катастрофоустойчивой системы и размер ущерба в случае инцидента: RTO и RPO.
RTO (recovery time objective) — период времени, за который ИТ-система должна восстановиться. Если RTO составляет четыре часа, то инфраструктура заработает не позже, чем за этот срок. Если RTO несколько секунд, то пользователи могут даже не заметить, что система «падала». Часть решений аварийного восстановления поддерживают автоматическое переключение трафика на резервную инфраструктуру. Это позволяет нивелировать последствия аварии, сделав их незаметными для пользователей. Длительность RTO определяется потребностями бизнеса. Например, сайту с маленьким трафиком большой RTO не повредит, а для крупного онлайн-магазина 2-3 часа RTO — это серьёзные убытки.
RPO (recovery point objective) — период времени, за который могут быть утеряны данные в результате аварии. Заявленные три часа RPO означают, что после восстановления системы могут быть утеряны данные не более чем за три часа до инцидента. А при RPO в несколько секунд сохранятся почти все данные, что особенно критично для банков, крупных девелоперов и других организаций, которым нельзя терять данные даже за минуту. Величина RPO влияет на частоту создания копий IT-инфраструктуры.
Очевидно, что стоимость решения Disaster Recovery будет тем дороже, чем меньше RTO/RPO. Подбирайте модель аварийного восстановления, стоимость которой не превышает размер убытков в случае простоя. Необходим баланс между затратами на катастрофоустойчивость и убытками из-за инцидента с учётом времени восстановления бизнес-процессов и объёма утерянных данных.
Что такое Disaster Recovery Plan
Disaster Recovery Plan (DRP) — это план аварийного восстановления всех ИТ-систем после катастрофы (который в идеале никогда не должен понадобиться). Представляет собой документ с детальным описанием всех действий по устранению последствий аварии и восстановлению данных. В плане указаны роли и обязанности ответственных сотрудников, последовательность предпринимаемых ими действий.
На каком этапе развития компании требуется DRP, сказать непросто. Можно сформулировать этот критерий следующим образом. Disaster Recovery Plan требуется компании, когда:
Если потеря БД за день ничего не меняет, а ИТ-отдел месяцами может ждать комплектующих к старому серверу, DRP вряд ли потребуется. Хотя этот документ способен выручить в трудной ситуации.
Основная цель Disaster Recovery Plan: создание пошаговой инструкции с указанием времени на выполнение отдельных процедур. С помощью плана компания:
План аварийного восстановления состоит из нескольких разделов. В первую очередь это цели разработки плана, факторы риска, список критически важных сервисов.
Целью DRP может являться:
Факторы риска показывают, какие процессы требуют особого внимания в процессе аварийного восстановления. В документе прописываются действия по устранению этих рисков. Например, проверка корректности создания бэкапов, работы каналов резервной связи, тестирование резервной инфраструктуры, проверка наличия нужного оборудования.
Список критически важных сервисов определяет очерёдность процессов восстановления. Чем критичнее процесс, тем быстрее нужно восстановить его работоспособность. Режим аварийного восстановления предполагает, что критические сервисы переносятся на резервную платформу. Поэтому даже при серьёзном инциденте их работоспособность должна сохраняться. Но если и с резервной площадкой что-то не так, работы по восстановлению начинаются с наиболее критичных систем.
DRaaS от Cloud4Y
Корпоративный облачный провайдер Cloud4Y предлагает три модели аварийного восстановления:
Использование облачных решений Disaster Recovery проще с точки зрения организации и управления, а также дешевле, чем построение собственной инфраструктуры. Используя услугу DRaaS от Cloud4Y, вы гарантируете себе возможность вернуться к привычному функционированию в срок, установленный договором. Проработка схем взаимодействия, подключения и маршрутизации занимает немного времени, поэтому интегрировать решения аварийного восстановления может компания любого уровня.
Осторожно! DriverPack Solution не так прост, как кажется.
Видимо навсегда уходят времена, когда мы не ждали подвоха от полюбившихся утилит, к которым уже успели привыкнуть. Была у меня одна такая палочка-выручалочка для автоматического поиска и установки драйверов под Windows и называлась она DriverPack Solution. Вот только сейчас, этот мегаудобный инструмент, позволявший существенно сократить время на поиск подходящих драйверов, окончательно скатился, перейдя на тёмную сторону.
Начиная с 15-ой версии, разработчик начал постепенно набивать сборку всякими рекламными модулями, телеметрией, и прочей дрянью. Вместе с драйверами, тебе до кучи прилетало несколько браузеров, антивирус, парочка архиваторов и ещё чего-то по мелочи.
Не скажу что это, прямо, совсем барахло, но зачем навязывать установку программ, которых я не заказывал? Отключить это безобразие, выбрав только нужные драйвера (далеко не всегда требуется всё, что предлагается утилитой) можно было перейдя в режим эксперта. Однако, не опытные пользователи даже не подозревают что так можно делать, и получают весь набор от автора DriverPack.
Все эти программы появились в сборке не просто так и, полагаю, автору перечисляется какое-то вознаграждение за из установку. И ладно, если только за установку и в самих программах не зашито ещё что-то более неприятное, ведь мы не знаем откуда, на самом деле, берутся их дистрибутивы. А сомнения такие появляются после попытки удаления ещё одного интересного приложения DriverPack Cloud.
Что такое DriverPack Cloud и как его удалить с компьютера
Вот что говорится на сайте разработчика о DriverPack Cloud:
DriverPack Cloud является новым продуктом от команды DriverPack, предназначенным для повышения производительности компьютера без каких-то дополнительных трат или апргейда «железа» вашего ПК. Не удовлетворены скоростью работы CS: GO или Dota 2 на своём компьютере? Попробуйте DriverPack Cloud!
С производительностью всё понятно, халявы не ждите, имеется гораздо более подозрительный функционал. Например, как пишут на сайте, DriverPack Cloud постоянно следит за состоянием драйверов и подгружает важные обновления, а также позволяет находить и удалять потенциально вредоносные программы, помогая вашему антивирусу. То есть, эта вся дребедень постоянно имеет полный доступ к вашим данным и работает на системном уровне.
Вы удивитесь, узнав насколько глубоко DriverPack Cloud запустил свои щупальца в вашу систему. И тут мы подходим к главному, что больше всего меня смутило в новом DriverPack Solution. Даже в режиме эксперта, если вы отказываетесь от установки и снимаете галочку с DriverPack Cloud, он всё равно ставится в вашу систему.
Но это ещё полбеды, данное приложение (DriverPack Cloud) не удаляется штатными средствами, пытаясь закрепиться где только возможно в системе, то есть ведёт себя как типичный троян.
Как удалить DriverPack Cloud
Итак, DriverPack Cloud плевать хотел на любые действия через штатную установку/удаление программ в Windows, однако вывести его всё-таки можно.
В сети можно найти советы использовать CCleaner, который сам не лучше, собирая информацию о пользователях, о чём я уже рассказывал ранее в статье CCleaner следит за тобой. На самом деле всё можно сделать штатными средствами Windows.
Первым делом останавливаем выполнение приложения cloud.exe в диспетчере задач (вызывается классической комбинацией Ctrl+Alt+Del, если кто не в теме). Таких процессов может быть несколько, прибить нужно все.
Далее запускаем редактор реестра командой regedit и через поиск в реестре находим и удаляем все упоминания «DriverPack Cloud».
Остаётся удалить созданные утилитой DriverPack Cloud файлы и каталоги с жёсткого диска. Кроме основного местоположения в каталоге C:/Program Files/ и чистки временных файлов, загляните в собственный пользовательский каталог (предварительно включив отображение скрытых файлов):
Выделенные на скриншотах каталоги подлежат безжалостному истреблению со всем содержимым.
Какой можно сделать вывод из всего сказанного? К сожалению, DriverPack Solution из удобного и простого инструмента превратился практически во вредоносную программу и рекомендовать его к использованию я бы не стал, особенно новичкам.
Лучше потратить чуть больше времени, скачивая драйвера с официального сайта производителя оборудования, но сэкономить кучу сил и нервов, потраченных на избавление от последствий применения данного универсального установщика. А ведь когда-то было хорошо.
Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.
DRP-план в ИТ-компании и проверка его работоспособности
Проводим проверку работоспособности плана восстановления после аварии.
Все мы хотим надеяться, что ничего подобного никогда не произойдет.
У большинства предприятий есть (ну, или хотя бы должен быть) план восстановления после аварии. Аналогичный план должен быть у оператора дата-центра. Любой из подобных объектов подвержен влиянию внешних факторов — полностью исключить вариант аварии нельзя. Даже, казалось бы, самые защищенные объекты могут все же попасть в очень неприятную ситуацию, о чем мы как-то уже писали.
Соответственно, DRP-план (disaster-recovery plan) должен помочь компании быстро выйти на предшествующий аварии рабочий уровень. Обычно в таком плане описываются действия сотрудников в случае аварии. При составлении такого плана цель обычно — сведение к минимуму последствий аварии с обеспечением возможности вернуть контроль над решением критически важных задач, используя заранее определенные ресурсы. Но план — планом, а будет ли он работать? Для проверки этого стоит провести «учебную тревогу».
Дата-центры содержат массу чувствительного к внешним факторам оборудования, которое, в свою очередь, работает с огромными объемами данных, которые могут быть очень ценными. Недавним примером того, к чему может привести даже небольшая авария, служит отмена большинства рейсов авиакомпании Delta Airlines.
Скорее всего, у такой огромной компании был собственный DRP-план. Возможно, в нем были неучтенные моменты, из-за чего пострадали и сама компания, и ее клиенты. И в самом деле, просто план и возможность его быстрой реализации — это разные вещи.
Любая компания, а тем более, ИТ-компания должна учитывать инфраструктуру, людей и процессы при составлении своего собственного плана восстановления после аварии (будь то землетрясение, пожар или человеческий фактор).
Как часто нужно проводить «учебные тревоги»?
Собственно, ответить здесь сложно — у каждой компании уникальная ситуация, которая не дает возможности унифицировать как DRP-план, так и его выполнения. Тем не менее, в любой момент времени руководитель компании должен быть уверен в том, что план отвечает текущей ситуации и может быть реализован. Пересматривать DRP-план стоит после каждого крупного изменения инфраструктуры. А «тревоги» можно проводить раз в месяц или раз в год — все зависит от того, как часто компания меняется.
Эксперты рекомендуют проводить проверку не реже раза в год.
Готовимся
Прежде, чем компания начнет проверять реалистичность и работоспособность своего плана, нужно быть уверенным в его результатах. Убедитесь в том, что обязанности всех сотрудников распределены рационально и корректно. Нельзя допускать того, чтобы у каких-то сотрудников обязанностей не было вообще, а у кого-то их была бы масса, и этот человек (или люди) были, фактически, незаменимыми.
Катастрофа на то и катастрофа, что кто-то из сотрудников может оказаться недоступным и если это будет ключевой человек, то весь план может пойти под откос. Все инструкции и правила должны быть четкими и понятным. Во время проверки плана нужно внимательно следить за ходом реализации DRP-плана.
Каждая деталь проверяемого плана должна быть зафиксирована, с учетом всех возникших проблем и сложностей. Проверку необходимо проводить с привязкой по времени, отслеживая, сколько времени уйдет на решение той либо иной проблемы и реализацию любого этапа. Руководство компании и отдельные сотрудники должны знать, что произойдет, если оборудование и сервисы ИТ-компании простоят определенное время. Как это повлияет на операции, клиентов и доход?
Как тестировать
1. Проверка плана
Это чисто теоретический этап, который почти никогда не включает в себя полноценные «учения». Пересматривать план на соответствие его текущей ситуации в компании и обстановке вокруг нужно несколько раз в год.
Кстати, у DRP должен быть управляющий комитет. В него обычно входят компетентные сотрудники, часто — топ-менеджеры. Кроме того, для работы необходимо привлекать и экспертов, которые могут очень помочь на пути к планированию спасения от катастрофы.
2. Проверка без тревоги
На этом этапе необходимо проверить знания всех сотрудников, кто, по плану, должен участвовать в процессе ликвидации последствий катастрофы. Каждого из сотрудников необходимо опросить на предмет его обязанностей и их выполнения в случае возникновения той либо иной непредвиденной ситуации.
Если ничего подобного не проводить, то сотрудники не будут слишком серьезно относиться к вашему плану. Кто-то что-то обязательно забудет, не так поймет или и вовсе решит не принимать участия. Чтобы не допустить значительное влияние «человеческого фактор» на последствия катастрофы, и нужно проводить такую проверку плана. Все сложности, недопонимание сотрудников, отсутствие ясности в синхронности действий — все это необходимо фиксировать и исправлять.
3. Полномасштабный тест
Это действительно полевые учения, их нужно максимально приблизить к возможному развитию ситуации в случае катастрофы. Результат должен быть ощутим. Оператор дата-центра должен учитывать то, насколько негативно на работе компании может отразиться значительный вынужденный простой оборудования.
Некоторые компании предпочитают скрывать информацию о том, что «учения» ненастоящие, от рядовых сотрудников. Дело в том, что это позволяет добиться от них скорости реакции и действий, максимально приближенным к реальности.
На этом этапе придется использовать ресурсы компании, включая время, оборудование и средства. Результатом должно быть возвращение во внятные сроки «поврежденного» оборудования с быстрой адаптацией работников компании к ситуации.
Что, если что-то пойдет не так?
Это, скорее всего, произойдет в той либо иной степени. Главное — стоит помнить, что гладко проверка такого уровня на все 100% пройти не может. Какие-то ошибки сотрудников и вмешательство неожиданных факторов обязательно повлияют на реализацию плана.
После завершения тестирования вся информация должна быть распределена между сотрудниками компании. Причем некоторые вещи стоит сообщать только тем, кто с ними связан. В идеале, тестировать DRP стоит тогда, когда в компании что-то сильно меняется.
И уже после теста все полученные результаты нужно использовать во благо собственной компании. В целом, поддержание сотрудников и всей компании в готовности к чрезвычайно ситуации — это критично. Работать с планом (модифицировать и дорабатывать его) нужно каждые несколько месяцев. Специалисты рекомендуют делать это раз или два в квартал. Но, конечно. Все зависит от самой компании и ее сотрудников.
Проверять работу плана нужно с разными сценариями и ситуациями. Только в том случае, если сотрудники готовы к катастрофе, компания сможет быстро восстановить работу после сбоя. В противном случае, бизнес такой компании может очень сильно пострадать.
Кстати, интересно было бы узнать, подготовлена ли ваша компания к подобным проблемам, и если да, то как вы проверяете работоспособность составленного плана, и какие у него есть особенности?