Close

Путь к успешному управлению инцидентами начинается здесь

Просмотр тем

Планы аварийного восстановления для ИТ-специалистов и специалистов DevOps

По мере увеличения важности ИТ-услуг для бизнеса эффективные методы аварийного восстановления работы ИТ приобретают такую же, если не большую важность.

О чем бы ни шла речь — о простое в работе приложений, потере данных или даже пожаре в локальном ЦОД, — реагировать на проблему, пока она в самом разгаре, практически всегда сложно.

Восстановление после крупного инцидента может быть губительным для небольших компаний. По данным FEMA, около 40–60 процентов маленьких компаний закрылись, пытаясь восстановиться после крупного инцидента.

Что такое план аварийного восстановления?

План аварийного восстановления — это документированный набор действий и процедур, разработанных для защиты организации и ее ИТ-ресурсов в аварийной ситуации. Как правило, план включает сценарии, перечни процедур, резервное копирование и инструкции по возвращению компании и ИТ-служб в режим нормальной работы. Этот план особенно актуален при таких событиях, как сбой системы, отключение сервиса, нарушение безопасности и потеря данных.

По данным IBM:

«До 1970-х годов большинству организаций приходилось лишь делать копии своих бумажных записей. В 1970-х годах планирование аварийного восстановления приобрело значение, поскольку предприятия начали в большей степени полагаться на компьютеры. В то время большинство систем были мэйнфреймами, ориентированными на пакетную обработку данных. Пока ожидалось восстановление основного вычислительного центра, можно было загрузить резервные ленты на другой, удаленный мэйнфрейм».

Планирование аварийного восстановления и планирование непрерывной работы бизнеса

Планирование аварийного восстановления — это разновидность планирования непрерывной работы бизнеса. В то время как планирование аварийного восстановления направлено на максимально быстрое восстановление работы затронутых сбоем сервисов, планирование непрерывной работы бизнеса фокусируется на обеспечении бесперебойной работы предприятия в случае аварии.

ИТ играют центральную роль в обоих случаях, будь то аварийное восстановление или непрерывная работа бизнеса.

Легко спутать аварийное восстановление и непрерывную работу бизнеса или рассматривать их как что-то взаимозаменяемое. Планирование аварийного восстановления направлено на восстановление сервиса после инцидента. Аварийное восстановление — это меньшая часть общего плана обеспечения непрерывной работы бизнеса. План обеспечения непрерывной работы бизнеса предназначен для обеспечения функционирования компании до, во время и после инцидента. Если аварийное восстановление — это «как мы разрешим этот инцидент», то непрерывная работа бизнеса — это «как мы продолжим нормально работать даже во время инцидента».

Планирование аварийного восстановления и управление инцидентами

Для команд DevOps и ИТ-специалистов управление инцидентами — это процесс, используемый для реагирования на незапланированные события или сбои в работе сервиса и для возвращения сервиса в рабочее состояние.

Понятия «управление инцидентами» и «аварийное восстановление» часто используются взаимозаменяемо, в зависимости от команды и компании. Управление инцидентами также сосредоточено на оперативном устранении инцидентов и перезапуске сервисов во время инцидента.

В Atlassian мы определяем инцидент как событие, которое приводит к нарушению или снижению качества работы сервиса и требует незамедлительных действий.

Или, согласно книге Google по обеспечению надежности сайта (SRE):

«Эффективное управление инцидентами играет ключевую роль в сокращении числа сбоев, вызываемых инцидентами, и обеспечивает скорейшее восстановление нормальной работы компании. Если вы заранее не определились, как вы будете реагировать на потенциальные инциденты, о нормальном управлении инцидентами не может быть и речи».

Google также рекомендует включить управление инцидентами в процесс тестирования аварийного восстановления, используемый в организации.

Что такое целевое время восстановления?

Целевое время восстановления — это приемлемое время восстановления для бизнес-функции, которое позволяет возобновить нормальное обслуживание после сбоя. Оно тесно связано со средним временем восстановления, которое было рассмотрено в контексте показателей DevOps.

Планирование аварийного восстановления в стиле DevOps

Как планы аварийного восстановления остаются актуальными в мире непрерывной поставки, автоматизированного тестирования и нескольких развертываний за день?

Другими словами, какую роль играют планы аварийного восстановления в организациях, работающих по методу DevOps?

К счастью, эти два метода отлично работают вместе и могут принести пользу друг другу. Те же инструменты и процессы, которые вы используете для передачи кода из среды разработки в среду тестирования, а из среды тестирования в рабочую среду, также могут играть определенную роль в аварийном восстановлении. Например, резервные копии рабочих сред, используемые для тестирования развертываний, также можно использовать для моделирования аварий. Отслеживаемые коммиты кода из конвейера CI/CD могут быть полезным инструментом для выявления последних изменений, который можно использовать в сценарии аварийного восстановления.

Ни для кого не секрет, что именно концепция DevOps все чаще задает темп для принятия всех ИТ-решений в компании. Однако серьезный труд, вкладываемый в план восстановления и соответствующие ресурсы, не должен тратиться впустую, а сам план аварийного восстановления не должен бесполезно стоять на полке, собирая пыль.

продолжение темы
Bug tracking best practices