Comments 7
Это значит, что в случае аварии админу придется вручную устанавливать Windows, драйверы, программы, настраивать сеть и безопасность. Это 2-3 дня простоя вместо пары часов.
Вот это мне непонятно, откуда 2-3 дня? Вы там кластер сразу поднимать собрались со всей сетевой инфраструктурой?
Из реального опыта: установить Винду, Сиквел и 1С получилось быстрее, чем просто скопировать образ для развёртывания, часа 2-3 ушло, а вот потом РИБ выгрузить на все филиалы заняло 3-4 дня. Т.е. местные пользователи не работали сутки, примерно, а удалённые - почти рабочую неделю в максимуме.
В следующих статьях разберем, как правильно выбрать облачного провайдера для резервной площадки
И тогда копирование с облачного провайдера займёт ещё больше времени, чем 3-4 дня, нет, спасибо, как-нибудь сами.
В соседнем кабинете бэкапы хранить не стоит, а вот в другом здании, но не сильно близком, до которого можно кинуть опту и организовать 10G-сеть хотя-бы на оборудовании с Али - вполне вариант. На случай землетрясения, ядерного взрыва или массового бомбометания будет не до 1С и прочего ИТ, думаю... Но для параноиков можно и в облако на этот случай складировать бэкапы - как-раз как отстроят новые кабинеты и закупят технику оно и скачается.
установить Винду, Сиквел и 1С получилось быстрее, чем просто скопировать образ для развёртывания, часа 2-3 ушло, а вот потом РИБ выгрузить на все филиалы заняло 3-4 дня
такие RPO RTO согласованы с бизнесом?). В моих проектах 3-4 дня чаще всего это колоссальные потери выручки, уровня сервиса и т.п.
И тогда копирование с облачного провайдера займёт ещё больше времени, чем 3-4 дня, нет, спасибо, как-нибудь сами
да, но не безусловно. Суть статьи - обсуждать такие темы с бизнесом обязательно, сокращая разрыв в ожиданиях, обещаниях доступности, SLA, OLA и пр.
У меня есть примеры где и неделю готовы потерпеть лишь бы не платить за размещение отчуждаемой копии поближе.
Все ваши тезисы могут быть как абсолютно верны так и нет, в зависимости от целей, которые управленческая вертикаль ставит перед инженерной/ИТ(и в обратную сторону также работает)
Суть статьи - в необходимости им быть интегрированными.
такие RPO RTO согласованы с бизнесом?)
Были-бы варианты. Ужать базу до приемлемых размеров (и времени восстановления/выгрузки РИБ) стоит несколько лямов. Перейти на другое решение - аналогично. Проапгрейдить инфраструктуру (и прокачивать такие объёмы быстро, если потребуется) - аналогично.
Бизнес в курсе, но куда тратить лямы - пока думает (пока гром не грянет).
В моих проектах 3-4 дня чаще всего это колоссальные потери выручки, уровня сервиса и т.п.
А у нас это 3-4 дня работы на бумажку с последующим внесением в базу, когда она будет. Это будут какие-то потери, но не колоссальные, т.е. бизнес не встанет, но кому то надо будет оплатить переработку по двойному тарифу.
да, но не безусловно.
Почему?
Организовать самому, если это не палатка с шаурмой, выйдет дешевле и с более приличными скоростями, чем в каком-то удалённом облаке (кроме случая когда ЦОД с нужным облаком в прямой видимости находится).
Да даже снять гараж или квартиру и кинуть туда опту выйдет дешевле чем облако, но это больше к параноикам с чёрной бухгалтерией.
Все ваши тезисы могут быть как абсолютно верны так и нет
Так изначальный вопрос был: Откуда 2-3 дня на поднятие сервера 1С? Что там за сервер такой, что не хватит дня с перекурами и обедом?
Были-бы варианты. Ужать базу до приемлемых размеров (и времени восстановления/выгрузки РИБ) стоит несколько лямов. Перейти на другое решение - аналогично. Проапгрейдить инфраструктуру (и прокачивать такие объёмы быстро, если потребуется) - аналогично.
в случае каждой реализации DRP индивидуально. Но зрелый согласованный уровень доступности с бизнесом должен быть в одном из двух состояний: согласовано/согласовывается. У вас в каком?
Почему?
У меня есть пример: восстановление offsite копии ключевых сервисов(13 штук) по L2 занимает 16часов. При отсутствии резервного оборудования RTO выше чем ручное восстановление из резервных копий, развертывание новых ОС и пр
У вас в каком?
Пока всё работает - денег нет!
При отсутствии резервного оборудования
Ну это странно, зип всегда нужен и должен быть, оборудование всегда может сломаться/не включиться. Гарантия тут не сильно поможет, не всякий поставщик именно под вас будет держать у себя на складе железки. А уж сейчас сроки от месяца и выше даже специально искать не надо - они все ещё дольше.
RTO выше чем ручное восстановление из резервных копий, развертывание новых ОС
Тут ещё важно насколько всё глобально, а то какие-то не соответствия могут получиться и всё равно придётся переставлять с нуля. Если одну машину восстановить или несколько не связанных (с другими и между собой) - да. Но если время восстановления из бэкапа примерно равно поднятию с нуля - лучше с нуля. А уж если много связанных машин - то только с нуля. Из бэкапа поднимаются базы, но не сама система.
Опять-же, если был какой-то инцидент с проникновением - то не факт, что в бэкапе УЖЕ не сидит сюрприз.
Пока всё работает - денег нет!
если оветственность не на вас - то ОК
помочь посчитать потери и риски для трансляции их бизнесу?
Ну это странно, зип всегда нужен и должен быть, оборудование всегда может сломаться/не включиться. Гарантия тут не сильно поможет, не всякий поставщик именно под вас будет держать у себя на складе железки. А уж сейчас сроки от месяца и выше даже специально искать не надо - они все ещё дольше.
далеко не все и не всегда. инструменты обеспечения доступности различаются, ЗИП - только один из них, необязательный.
пример: кластер серверов на гарантии, точки отказа: все комплектующие , включая системные платы. ЗИП на все компоненты держать не требуется, это нагрузка на закупку, хранение и их проверку. Вероятность выхода из строя можно оценить по мат модели вероятностно, если сильно требуется
.Но если время восстановления из бэкапа примерно равно поднятию с нуля - лучше с нуля.
обычно как раз наоборот - ВМ в репозитории в более подготовленном состоянии , нет такого уровня неопределенности как в случае с новыми. Элементарная вероятность рисков диктует при прочих равных взять ВМ из резервных копий.
Нередко идут двумя сценариями параллельно
Опять-же, если был какой-то инцидент с проникновением - то не факт, что в бэкапе УЖЕ не сидит сюрприз
Зрелое решение принимают исходя из ситуации, бывало быстрей и эффективней восстановить ВМ с бэкдором, извлечь БД и заново развернуть ОС+СУБД
помочь посчитать потери и риски для трансляции их бизнесу?
Нет, спасибо.
Да и бизнесу это не интересно пока не клюнуло. Все трансляции мимо ушей идут.
пример: кластер серверов на гарантии
Кластер - это не ЗИП в работе, сильно упрощая? Т.е., три машины не смогут перераспределить нагрузку и обойтись двумя, при пропадании третьей, например? Если нет - то в чём смысл кластера тогда? Или мы просто про масштабирование и распределение нагрузки?
Опять-же кластер серверов - это одинаковое железо? Почему бы не сделать +1 железка и тогда такой кластер спокойно переживёт -1 и не надо зип на склад класть?
обычно как раз наоборот
ВМ в репозитории в более подготовленном состоянии, но план восстановления пишется с точки зрения "ничего нет" и там есть инструкции как поднять все сервисы с нуля, в том числе.
быстрей и эффективней восстановить ВМ с бэкдором, извлечь БД и заново развернуть ОС+СУБД
У меня в любом случает делается и образ всей системы и конкретные базы или каталоги с сервисами, поэтому таких сложных путей быть не должно.
Да и те же SQL-базы в образе так хорошо не сожмутся, как это умеет делать MS SQL или Постгри.
План аварийного восстановления (DRP): практический гайд для собственника. О чем спросить ИТ-отдел, пока все работает