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