основываясь на моем опыте, также зависит от характеристик сервера, обычно мне достаются впервую очередь недостаточно производительные серверы, и доп нагрузка на дисковую подсистему ее снижает.
взрослый ИТ должен предоставить оценку расходов на содержание DRP и помочь бизнесу посчитать риски/потери в случае отсутствия DRP нередко DRP с оплатой трафика стоит дешевле чем один массовый инцидент с потерей данных.
ничего. также как и хостить сайт из дома/офиса но это по совокупности архитектурных (доступность, отказоустойчивость, масштабируемость, заложенные риски и пр) обычно незрелое решение.
Если у вас старый сервер, и вам комфортно с сервером - арендуйте новый сразу в ЦОДе, модель затрат сменится, и вы получите быстро работающую замену старому, хорошие каналы - и всё, что хотите.
Это дополнительная точка отказа и снижение отказоустойчивости/доступности. Если бизнес на такой риск готов и это с ним согласовано то отлично.
Так что рекомендация: сделайте аудит, и внимательно посчитайте и согласуйте решение с бизнесом.
если оветственность не на вас - то ОК помочь посчитать потери и риски для трансляции их бизнесу?
Ну это странно, зип всегда нужен и должен быть, оборудование всегда может сломаться/не включиться. Гарантия тут не сильно поможет, не всякий поставщик именно под вас будет держать у себя на складе железки. А уж сейчас сроки от месяца и выше даже специально искать не надо - они все ещё дольше.
далеко не все и не всегда. инструменты обеспечения доступности различаются, ЗИП - только один из них, необязательный. пример: кластер серверов на гарантии, точки отказа: все комплектующие , включая системные платы. ЗИП на все компоненты держать не требуется, это нагрузка на закупку, хранение и их проверку. Вероятность выхода из строя можно оценить по мат модели вероятностно, если сильно требуется
.Но если время восстановления из бэкапа примерно равно поднятию с нуля - лучше с нуля.
обычно как раз наоборот - ВМ в репозитории в более подготовленном состоянии , нет такого уровня неопределенности как в случае с новыми. Элементарная вероятность рисков диктует при прочих равных взять ВМ из резервных копий. Нередко идут двумя сценариями параллельно
Опять-же, если был какой-то инцидент с проникновением - то не факт, что в бэкапе УЖЕ не сидит сюрприз
Зрелое решение принимают исходя из ситуации, бывало быстрей и эффективней восстановить ВМ с бэкдором, извлечь БД и заново развернуть ОС+СУБД
Были-бы варианты. Ужать базу до приемлемых размеров (и времени восстановления/выгрузки РИБ) стоит несколько лямов. Перейти на другое решение - аналогично. Проапгрейдить инфраструктуру (и прокачивать такие объёмы быстро, если потребуется) - аналогично.
в случае каждой реализации DRP индивидуально. Но зрелый согласованный уровень доступности с бизнесом должен быть в одном из двух состояний: согласовано/согласовывается. У вас в каком?
Почему?
У меня есть пример: восстановление offsite копии ключевых сервисов(13 штук) по L2 занимает 16часов. При отсутствии резервного оборудования RTO выше чем ручное восстановление из резервных копий, развертывание новых ОС и пр
установить Винду, Сиквел и 1С получилось быстрее, чем просто скопировать образ для развёртывания, часа 2-3 ушло, а вот потом РИБ выгрузить на все филиалы заняло 3-4 дня
такие RPO RTO согласованы с бизнесом?). В моих проектах 3-4 дня чаще всего это колоссальные потери выручки, уровня сервиса и т.п.
И тогда копирование с облачного провайдера займёт ещё больше времени, чем 3-4 дня, нет, спасибо, как-нибудь сами
да, но не безусловно. Суть статьи - обсуждать такие темы с бизнесом обязательно, сокращая разрыв в ожиданиях, обещаниях доступности, SLA, OLA и пр. У меня есть примеры где и неделю готовы потерпеть лишь бы не платить за размещение отчуждаемой копии поближе.
Все ваши тезисы могут быть как абсолютно верны так и нет, в зависимости от целей, которые управленческая вертикаль ставит перед инженерной/ИТ(и в обратную сторону также работает) Суть статьи - в необходимости им быть интегрированными.
я меняю тормозные шланги самостоятельно, используя мануал и регламенты от производителя и соответствующий тех.процесс :) как и в случае с автосервисом - выбор подрядчика/исполнителя + использование лучших практик при обслуживании 1с позволяет гарантировать высокую доступность информационных систем
Не могу согласиться Давайте исходить из зрелых стандартов техосмотра( пример USS, Aucnet, JAAI или тот же Сякен) Прохождение которых именно гарантирует безхопасность при использовании авто согласно рекомендациям от производителя, правилам движения и здравому смыслу
ИТ аудит и есть один из правильных путей решения. В целом аудирование ИТ-департамента это хорошая практика и показатель зрелости компании/команды. Я не сторонник выкидывать людей на мороз, нередко локальный ИТ недооценивают потому что он управляется неэффективно или сильно оторван от бизнеса
комплексный глубокий вопрос для ответа на него я бы начал с верхнего уровня 1. оценил финансовые потери и эффективность существующего ИТ( измерить и оценить расходы, простои) 2. оценил риски и угрозы с стороны ИТ поблочно: люди , технологии, процессы
Абсолютно верно. Но в статье и не сказано что репликация это резервное копирование. Перечислены наиболее часто исопльзуемые методы защиты от сбоев со стороны инфраструктуры. Не было задачи перечислить все практики SRE поэтому использован ряд допущений, в т.ч. контроль точек восстановления, состояния репликаций, обновление DRP, соответсвующие регламенты и процессы
рынок аутсорсинг услуг растет постоянно, ИТ - особенно. В ИТ специфика усложняется и чаще всего бизнес смотрит на нее как на магию, абслютно ему неподвластную. что важно: ИТ в любой компании это не только человек , но и процессы, и технологии.
вот тут подробней об этом
https://its.1c.ru/db/metod8dev/content/5837/hdoc
Да, если просто обновлять статистику, то надо чистить процедурный кэш. А вот ребилд индексов обновляет и план запросов.
основываясь на моем опыте, также зависит от характеристик сервера, обычно мне достаются впервую очередь недостаточно производительные серверы, и доп нагрузка на дисковую подсистему ее снижает.
тут требуется много уточнений, ситуации бывают разные
взрослый ИТ должен предоставить оценку расходов на содержание DRP и помочь бизнесу посчитать риски/потери в случае отсутствия DRP
нередко DRP с оплатой трафика стоит дешевле чем один массовый инцидент с потерей данных.
ничего.
также как и хостить сайт из дома/офиса
но это по совокупности архитектурных (доступность, отказоустойчивость, масштабируемость, заложенные риски и пр) обычно незрелое решение.
разве?)
а если это публикации web приложений?
а если связка RDS+SSL ?
и в среднем отказоустойчивей
и в среднем технологичней
если ответ по отчуждаемым копиям уже есть, то адаптировать DRP под облако не проблема.
но вопрос важный , да
Это дополнительная точка отказа и снижение отказоустойчивости/доступности. Если бизнес на такой риск готов и это с ним согласовано то отлично.
уточняю: этот вопрос нужно задавать при любой инфраструктуре (земля\облако)
очень интересно послушать развернуто
если оветственность не на вас - то ОК
помочь посчитать потери и риски для трансляции их бизнесу?
далеко не все и не всегда. инструменты обеспечения доступности различаются, ЗИП - только один из них, необязательный.
пример: кластер серверов на гарантии, точки отказа: все комплектующие , включая системные платы. ЗИП на все компоненты держать не требуется, это нагрузка на закупку, хранение и их проверку. Вероятность выхода из строя можно оценить по мат модели вероятностно, если сильно требуется
обычно как раз наоборот - ВМ в репозитории в более подготовленном состоянии , нет такого уровня неопределенности как в случае с новыми. Элементарная вероятность рисков диктует при прочих равных взять ВМ из резервных копий.
Нередко идут двумя сценариями параллельно
Зрелое решение принимают исходя из ситуации, бывало быстрей и эффективней восстановить ВМ с бэкдором, извлечь БД и заново развернуть ОС+СУБД
в случае каждой реализации DRP индивидуально. Но зрелый согласованный уровень доступности с бизнесом должен быть в одном из двух состояний: согласовано/согласовывается. У вас в каком?
У меня есть пример: восстановление offsite копии ключевых сервисов(13 штук) по L2 занимает 16часов. При отсутствии резервного оборудования RTO выше чем ручное восстановление из резервных копий, развертывание новых ОС и пр
такие RPO RTO согласованы с бизнесом?). В моих проектах 3-4 дня чаще всего это колоссальные потери выручки, уровня сервиса и т.п.
да, но не безусловно. Суть статьи - обсуждать такие темы с бизнесом обязательно, сокращая разрыв в ожиданиях, обещаниях доступности, SLA, OLA и пр.
У меня есть примеры где и неделю готовы потерпеть лишь бы не платить за размещение отчуждаемой копии поближе.
Все ваши тезисы могут быть как абсолютно верны так и нет, в зависимости от целей, которые управленческая вертикаль ставит перед инженерной/ИТ(и в обратную сторону также работает)
Суть статьи - в необходимости им быть интегрированными.
я меняю тормозные шланги самостоятельно, используя мануал и регламенты от производителя и соответствующий тех.процесс :)
как и в случае с автосервисом - выбор подрядчика/исполнителя + использование лучших практик при обслуживании 1с позволяет гарантировать высокую доступность информационных систем
Не могу согласиться
Давайте исходить из зрелых стандартов техосмотра( пример USS, Aucnet, JAAI или тот же Сякен)
Прохождение которых именно гарантирует безхопасность при использовании авто согласно рекомендациям от производителя, правилам движения и здравому смыслу
ИТ аудит и есть один из правильных путей решения.
В целом аудирование ИТ-департамента это хорошая практика и показатель зрелости компании/команды.
Я не сторонник выкидывать людей на мороз, нередко локальный ИТ недооценивают потому что он управляется неэффективно или сильно оторван от бизнеса
комплексный глубокий вопрос
для ответа на него я бы начал с верхнего уровня
1. оценил финансовые потери и эффективность существующего ИТ( измерить и оценить расходы, простои)
2. оценил риски и угрозы с стороны ИТ поблочно: люди , технологии, процессы
Абсолютно верно. Но в статье и не сказано что репликация это резервное копирование.
Перечислены наиболее часто исопльзуемые методы защиты от сбоев со стороны инфраструктуры. Не было задачи перечислить все практики SRE поэтому использован ряд допущений, в т.ч. контроль точек восстановления, состояния репликаций, обновление DRP, соответсвующие регламенты и процессы
рынок аутсорсинг услуг растет постоянно, ИТ - особенно. В ИТ специфика усложняется и чаще всего бизнес смотрит на нее как на магию, абслютно ему неподвластную.
что важно: ИТ в любой компании это не только человек , но и процессы, и технологии.