시스템 장애를 필연으로 받아들이는 설계와 복구 연습의 중요성

시스템은 본질적으로 중단될 수 있는(breakable) 존재이므로 장애 발생 자체를 잘못이나 비정상으로 간주해서는 안 된다.

🔗 원문 보기

Как построить и проверить катастрофоустойчивость в облаке: от плана до Game Day

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

https://habr.com/ru/companies/vktech/articles/1034702/

#катастрофоустойчивость #облачные_технологии #disaster_recovery #high_availability #rto #rpo #cloud_native #отказоустойчивость #kubernetes #vk_tech

План аварийного восстановления (Disaster Recovery Plan, DRP) DWH — зачем он нужен и как работает

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

https://habr.com/ru/articles/1001966/

#dwh #drp #disaster_recovery_planning #disaster_recovery #план_аварийного_восстановления #аварийное_восстановление #data_warehouse

Акура-тное приземление. 5 ошибок бэкапа, которые могут стоить вам инфраструктуры

Представьте: вы прыгаете с парашютом, дергаете кольцо, а из ранца вместо купола вылетает записка: «404: Not Found». В ИТ-инфраструктуре бэкап — именно такой парашют. И проблема в том, что 90% инженеров уверены: раз ранец за спиной висит, значит, гравитация им не страшна. Мало кто проверяет его «укладку» (валидацию) и тренирует само приземление (DR). Чаще всего процесс строится либо на слепой вере в собственную память, либо на тотальном доверии древним скриптам, которые DevOps-археолог написал еще пять лет назад. В момент свободного падения времени на исправление конфигов этих скриптов уже не будет. Поэтому под катом — краткая инструкция по «укладке парашюта»: быстро и без воды про классические ошибки и как их обойти. Дернуть кольцо

https://habr.com/ru/companies/hstx/articles/995750/

#бэкап #резервное_копирование #Disaster_Recovery #системное_администрирование #информационная_безопасность #RPO #автоматизация #RTO #отказоустойчивость #репликация_данных

Не ждать у моря API. Предсказуемая миграция без интеграций под каждую платформу

Привет Хабр! Я Виктор, в Хайстекс руковожу отделом разработки. Сегодня расскажу про фичу, которая снимает ложную дилемму «API или универсальность», потому что теперь оба сценария можно применять параллельно. При переносе виртуальных машин между облаками и частными контурами API-интеграция обычно даёт максимум автоматизации. Но как только целевых площадок становится больше одной-двух или появляется «собранная на коленке» платформа, выясняется, что у этой автоматизации есть цена. Миграция через API превращается в отдельный проект на недели разработки и тестирования. Этот пост — для инженеров и архитекторов, которые занимаются миграциями ВМ и упираются в стоимость и сроки поддержки API-интеграций под каждую новую целевую площадку. Под катом — как сделать целевую сторону миграции воспроизводимой без зависимости от API конкретного облака и без ожидания поддержки со стороны платформы. API vs D2T

https://habr.com/ru/companies/hstx/articles/978250/

#проектирование_api #миграция_в_облако #виртуализация #iaas #vm #api #devops #облачная_инфраструктура #migration #disaster_recovery

Как выглядит идеальный шторм в облаках, или насколько надежны современные облачные сервисы

Привет, Хабр! Меня зовут Роман Путилов. Последние восемь лет я занимаюсь облачной инфраструктурой. SRE-процессы, SLA «пять девяток», регулярные инциденты и постмортемы – часть моей работы, а не только новостная повестка. За последние годы несколько крупных инцидентов в облаках показали, что одна ошибка может вырубить сразу несколько глобальных сервисов. На кейсах VK, ЕГРН, Яндекса, AWS, Google Cloud и CrowdStrike я разбираю, ведет ли консолидация инфраструктуры к цифровой катастрофе – идеальному шторму, где простая ошибка и несколько неудачных совпадений окажут такой разрушительный эффект, от которого уже нельзя будет оправиться. Будет полезно SRE, архитекторам, IT- и ИБ-руководителям.

https://habr.com/ru/companies/cloud_ru/articles/976912/

#cloud_computing #disaster_recovery #incident #цод #авария #облако #windows

Мы так привыкли к Disaster Recovery у VMware, что разработали свою

Пожар в ЦОДе, авария на подстанции, разорванный во время ремонта кабель между площадками — таких инцидентов за последние годы хватает. Например, в конце этого сентября пожар в государственном дата-центре Южной Кореи парализовал сотни госсервисов и уничтожил свыше 800 терабайтов данных без резервных копий. Единственная реальная защита от таких сценариев — геораспределенные инсталляции с Disaster Recovery (DR). Система автоматически перекидывает нагрузку на резервную, если основная упала. Большинство российских ИТ-инфраструктур виртуализированы, сервисы работают в виртуальных машинах, и заказчикам нужны DR-сценарии именно для виртуализации. Поэтому мы в Orion soft разработали модуль DR для собственной платформы виртуализации zVirt. Он обеспечивает программную репликацию на уровне гипервизора (без агентов внутри гостевых ОС) и аппаратную на уровне СХД. Я Александр Гавриленко, директор технического пресейла zVirt. В этой статье расскажу, как мы воспроизвели привычную функциональность VMware и что адаптировали в решении под специфику российского рынка.

https://habr.com/ru/companies/orion_soft/articles/968802/

#disaster_recovery #zvirt #vmware

Подход к оценке “живой” инфраструктуры и построению disaster recovery

Большинство проектов не имеют нормального плана восстановления после падений. Если план и присутствует, скорее всего, в нем покрыты не все кейсы, и часть из них, возможно, устарела. При этом задач на подготовку восстановительных процедур никто не ставит. Зато сразу после падений начинаются вопросы к технарям: почему вы не заботитесь о сервисах как следует? На самом деле создать disaster recovery план — т.е. набор документов и инструкций, в которых указано, как именно восстанавливать сервис — не так сложно. Как это сделать, читайте в статье.

https://habr.com/ru/articles/911240/

#аудит_файловых_серверов #метрики #восстановление_файлов #карта_связей #микросервисы #slo #мониторинг_сервера #disaster_recovery #disaster_recovery_planning

«Это катастрофа, шеф!» — как облако помогает организовать Disaster Recovery

Привет, Хабр! Рассказываем, на что обратить внимание при планировании аварийного восстановления: что может сделать сама компания, а где поможет облачный провайдер. А также обсуждаем, какие установки мешают компаниям грамотно организовать

https://habr.com/ru/companies/mws/articles/860910/

#disaster_recovery #катастрофоустойчивость #mws