основываясь на моем опыте, также зависит от характеристик сервера, обычно мне достаются впервую очередь недостаточно производительные серверы, и доп нагрузка на дисковую подсистему ее снижает.
взрослый ИТ должен предоставить оценку расходов на содержание DRP и помочь бизнесу посчитать риски/потери в случае отсутствия DRP нередко DRP с оплатой трафика стоит дешевле чем один массовый инцидент с потерей данных.
ничего. также как и хостить сайт из дома/офиса но это по совокупности архитектурных (доступность, отказоустойчивость, масштабируемость, заложенные риски и пр) обычно незрелое решение.
Если у вас старый сервер, и вам комфортно с сервером - арендуйте новый сразу в ЦОДе, модель затрат сменится, и вы получите быстро работающую замену старому, хорошие каналы - и всё, что хотите.
Это дополнительная точка отказа и снижение отказоустойчивости/доступности. Если бизнес на такой риск готов и это с ним согласовано то отлично.
Так что рекомендация: сделайте аудит, и внимательно посчитайте и согласуйте решение с бизнесом.
если оветственность не на вас - то ОК помочь посчитать потери и риски для трансляции их бизнесу?
Ну это странно, зип всегда нужен и должен быть, оборудование всегда может сломаться/не включиться. Гарантия тут не сильно поможет, не всякий поставщик именно под вас будет держать у себя на складе железки. А уж сейчас сроки от месяца и выше даже специально искать не надо - они все ещё дольше.
далеко не все и не всегда. инструменты обеспечения доступности различаются, ЗИП - только один из них, необязательный. пример: кластер серверов на гарантии, точки отказа: все комплектующие , включая системные платы. ЗИП на все компоненты держать не требуется, это нагрузка на закупку, хранение и их проверку. Вероятность выхода из строя можно оценить по мат модели вероятностно, если сильно требуется
.Но если время восстановления из бэкапа примерно равно поднятию с нуля - лучше с нуля.
обычно как раз наоборот - ВМ в репозитории в более подготовленном состоянии , нет такого уровня неопределенности как в случае с новыми. Элементарная вероятность рисков диктует при прочих равных взять ВМ из резервных копий. Нередко идут двумя сценариями параллельно
Опять-же, если был какой-то инцидент с проникновением - то не факт, что в бэкапе УЖЕ не сидит сюрприз
Зрелое решение принимают исходя из ситуации, бывало быстрей и эффективней восстановить ВМ с бэкдором, извлечь БД и заново развернуть ОС+СУБД
Были-бы варианты. Ужать базу до приемлемых размеров (и времени восстановления/выгрузки РИБ) стоит несколько лямов. Перейти на другое решение - аналогично. Проапгрейдить инфраструктуру (и прокачивать такие объёмы быстро, если потребуется) - аналогично.
в случае каждой реализации DRP индивидуально. Но зрелый согласованный уровень доступности с бизнесом должен быть в одном из двух состояний: согласовано/согласовывается. У вас в каком?
Почему?
У меня есть пример: восстановление offsite копии ключевых сервисов(13 штук) по L2 занимает 16часов. При отсутствии резервного оборудования RTO выше чем ручное восстановление из резервных копий, развертывание новых ОС и пр
установить Винду, Сиквел и 1С получилось быстрее, чем просто скопировать образ для развёртывания, часа 2-3 ушло, а вот потом РИБ выгрузить на все филиалы заняло 3-4 дня
такие RPO RTO согласованы с бизнесом?). В моих проектах 3-4 дня чаще всего это колоссальные потери выручки, уровня сервиса и т.п.
И тогда копирование с облачного провайдера займёт ещё больше времени, чем 3-4 дня, нет, спасибо, как-нибудь сами
да, но не безусловно. Суть статьи - обсуждать такие темы с бизнесом обязательно, сокращая разрыв в ожиданиях, обещаниях доступности, SLA, OLA и пр. У меня есть примеры где и неделю готовы потерпеть лишь бы не платить за размещение отчуждаемой копии поближе.
Все ваши тезисы могут быть как абсолютно верны так и нет, в зависимости от целей, которые управленческая вертикаль ставит перед инженерной/ИТ(и в обратную сторону также работает) Суть статьи - в необходимости им быть интегрированными.
ИТ аудит и есть один из правильных путей решения. В целом аудирование ИТ-департамента это хорошая практика и показатель зрелости компании/команды. Я не сторонник выкидывать людей на мороз, нередко локальный ИТ недооценивают потому что он управляется неэффективно или сильно оторван от бизнеса
комплексный глубокий вопрос для ответа на него я бы начал с верхнего уровня 1. оценил финансовые потери и эффективность существующего ИТ( измерить и оценить расходы, простои) 2. оценил риски и угрозы с стороны ИТ поблочно: люди , технологии, процессы
Абсолютно верно. Но в статье и не сказано что репликация это резервное копирование. Перечислены наиболее часто исопльзуемые методы защиты от сбоев со стороны инфраструктуры. Не было задачи перечислить все практики SRE поэтому использован ряд допущений, в т.ч. контроль точек восстановления, состояния репликаций, обновление DRP, соответсвующие регламенты и процессы
рынок аутсорсинг услуг растет постоянно, ИТ - особенно. В ИТ специфика усложняется и чаще всего бизнес смотрит на нее как на магию, абслютно ему неподвластную. что важно: ИТ в любой компании это не только человек , но и процессы, и технологии.
Выбор аутсорсера (ит, бухгалтерия, юристы и прочая классика) как и inhouse специалиста это навык. На рынке есть достаточное количество зрелых компаний не экономящих на кадрах, на процессах, на оценке эффективности, на методологиях и best pratices. Именно поэтому в OPBOK описаны не только передачи услуги inhouse-outsource но и outsource-outsource
для бизнеса аутсорс это всегда осознанный выбор, включая планирование рисков
вот тут подробней об этом
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. оценил финансовые потери и эффективность существующего ИТ( измерить и оценить расходы, простои)
2. оценил риски и угрозы с стороны ИТ поблочно: люди , технологии, процессы
Абсолютно верно. Но в статье и не сказано что репликация это резервное копирование.
Перечислены наиболее часто исопльзуемые методы защиты от сбоев со стороны инфраструктуры. Не было задачи перечислить все практики SRE поэтому использован ряд допущений, в т.ч. контроль точек восстановления, состояния репликаций, обновление DRP, соответсвующие регламенты и процессы
рынок аутсорсинг услуг растет постоянно, ИТ - особенно. В ИТ специфика усложняется и чаще всего бизнес смотрит на нее как на магию, абслютно ему неподвластную.
что важно: ИТ в любой компании это не только человек , но и процессы, и технологии.
Выбор аутсорсера (ит, бухгалтерия, юристы и прочая классика) как и inhouse специалиста это навык. На рынке есть достаточное количество зрелых компаний не экономящих на кадрах, на процессах, на оценке эффективности, на методологиях и best pratices.
Именно поэтому в OPBOK описаны не только передачи услуги inhouse-outsource но и outsource-outsource
для бизнеса аутсорс это всегда осознанный выбор, включая планирование рисков