#аварийное_восстановление — Public Fediverse posts

Дата-центр вышел из строя. Знаете ли вы, какое оборудование потребуется для восстановления?

В октябре пострадали три площадки одного из крупнейших российских провайдеров: на первой после пожара остановились все системы, на второй несколько модулей вышли из строя полностью, а третью остановили целиком, и облако перешло в аварийный режим ( разбор на Хабре , «Коммерсантъ» ). Весь рунет спрашивал когда всё заработает. А вот ИТ-службы куда реже спрашивали себя, что придётся восстанавливать, если такое случится у них.

https://habr.com/ru/companies/simpleone/articles/1097942/

#цод #itsm #disaster_recovery #резервирование #itam #инвентаризация #непрерывность_бизнеса #аварийное_восстановление #управление_активами #cmdb

Цена простоя: как обосновать бюджет на отказоустойчивость

Сервисы упали. Пользователи не могут оформить заказ, оплатить покупку или перевести деньги. А компания продолжает платить зарплаты, оплачивать аренду и инфраструктуру. Постоянные расходы сохраняются, а возможность зарабатывать оказывается под угрозой. Для крупного бизнеса простой может затронуть сразу несколько направлений. Не проходят платежи — срываются покупки. Не работает оформление доставки — заказы уходят конкурентам. После восстановления часть клиентов возвращается, а часть — нет. К финансовым потерям добавляется риск утратить доверие пользователей. Поэтому надежность становится вопросом не только устройства серверов, но и экономики бизнеса. В этой статье разберем, как крупные компании, владеющие несколькими сервисами, рассчитывают потери от простоя, какие технические решения и организационные меры используют для бесперебойной работы и во сколько обходится такая защита.

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

#датацентры #отказоустойчивость #резервирование #аварийное_восстановление #rto #rpo #доступность_сервисов #itбюджет #стоимость_простоя #аварийное

[Перевод] Аварийное восстановление мультикластерного Kubernetes с Linkerd и HAZL

Высокая доступность приложений помогает выполнять договорные обязательства и соответствовать ожиданиям пользователей. Для этого многие платформенные команды развёртывают кластеры Kubernetes в локальных и облачных окружениях, распределяя их между зонами доступности, регионами и даже провайдерами. Сбой возможен на любом уровне этой инфраструктуры, поэтому нужно заранее проверить, как сервисная сетка поведёт себя при масштабной аварии. Команда VK Tech перевела статью о том, как протестировать аварийное восстановление мультикластерной конфигурации Linkerd и подготовить сервисную сетку к таким сбоям. Статья адресована организациям, которые уже используют или планируют использовать сервисную сетку в мультикластерной конфигурации. Если вы только знакомитесь с этим подходом, начните с руководства по поддержке мультикластерности в Linkerd , изучите преимущества и недостатки мультикластерного Kubernetes и разберитесь в трёх типах мультикластерных архитектур , которые поддерживает Linkerd. Другие полезные материалы перечислены в конце статьи. Авторы моделируют реалистичную мультикластерную конфигурацию с открытой версией Linkerd и Buoyant Enterprise for Linkerd (BEL) и разбирают сценарии аварийного восстановления сервисной сетки. Они показывают, от чего зависит восстановление, как воспроизвести сбои в своих кластерах и какие действия помогут устранить выявленные проблемы. Даже если вы не будете запускать демонстрационную конфигурацию самостоятельно, метрики и результаты экспериментов помогут повысить устойчивость сетки и разобраться в роли Buoyant High Availability Zonal Load Balancing (HAZL) — механизма балансировки нагрузки с учётом зон доступности.

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

#отказоустойчивость #балансировка_нагрузки #аварийное_восстановление #kubernetes #linkerd #service_mesh #chaos_mesh #зоны_доступности #hazl #мультикластерная_архитектура

Облако тоже может сломаться. Часть 2: как переехать во время аварии и не потерять

Представим ситуацию: облачная площадка недоступна, GitLab и внутренние сервисы не работают, а бизнес ждёт конкретных сроков восстановления. Нужно срочно переехать к другому провайдеру, но при этом не потерять данные и не создать ещё больше проблем. Разберём практический порядок аварийной миграции: от выбора нового провайдера и проверки квот до восстановления GitLab, Kubernetes, баз данных и переключения DNS. Поговорим о Terraform, Ansible, GitOps, резервных копиях и репликации. Покажем, почему статус Running ещё не означает успешное восстановление и какие проверки действительно необходимы перед возвращением сервисов в эксплуатацию.

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

#disaster_recovery #gitlab #devops #backup_and_restore #аварийное_восстановление #ansible #kubernetes #terraform #gitops #миграция_инфраструктуры

Облако тоже может сломаться. Часть 1: как спроектировать инфраструктуру, переживающую отказ зоны или провайдера

Облако часто воспринимается как гарантия доступности инфраструктуры. Но что произойдёт, если целиком откажет зона доступности, перестанет отвечать API провайдера или резервные копии окажутся недоступны вместе с основными сервисами? Разберём, почему несколько VM ещё не означают отказоустойчивость, чем multi-AZ отличается от multi-cloud, как правильно определять RPO и RTO и когда действительно нужна вторая площадка. Сравним active-active, active-passive, pilot light и восстановление из резервных копий. А главное — разберём, какие решения стоит принять до аварии, чтобы потом не пришлось импровизировать под давлением бизнеса.

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

#отказоустойчивость #multicloud #высокая_доступность #аварийное_восстановление #облачная_инфраструктура #аварии_в_датацентрах #terraform #devsecops_и_devops #rpo_rto

Железо чинят инженеры ЦОДа, остальное поднимает DevOps

Недавно у Яндекса случилась неприятная история с дата-центрами: несколько площадок пришлось остановить, и Yandex Cloud какое-то время работал в ограниченном режиме. Что произошло и что крутилось на этих площадках, я подробно разбирал в отдельной статье: https://habr.com/p/1093198/ Здесь хочу про другое. Клиентов у Yandex Cloud около 64 000, и тем, чьи ресурсы стояли на затронутых площадках, пришлось поднимать свою инфраструктуру заново, внутри облака или у другого провайдера. Во многих компаниях эту работу делает DevOps-команда.

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

#цод #отказоустойчивость #disaster_recovery #devops #аварийное_восстановление #kubernetes #terraform #yandex_cloud #миграция_между_облаками #карьера_devops

Миграция с VMware: девять осей обвязки vSphere и что с ними будет на открытом стеке

Tesco переносит с VMware около 40 тысяч серверных нагрузок, от которых зависят магазинные серверы и системы данных, включая кассы в торговых залах. По данным The Register , ритейлер начал выбирать замену после отказа Broadcom продлевать поддержку его инсталляций. Миграция идёт в предельно возможном темпе — в опубликованных материалах его описали как at exceptional pace. Уже в ходе проекта выяснилось, что Veeam и Zerto, на которых построены резервное копирование и защита данных, не работают с выбранной платформой. Часть функций пришлось дорабатывать или закупать заново. Computer Weekly При переходе с vSphere виртуальные машины обычно переносятся средствами конвертации без серьёзных сюрпризов. Сложнее сохранить всё, что за полтора десятка лет выросло вокруг платформы: резервное копирование, микросегментацию, аварийное восстановление, интеграции и регламенты ИБ. Совместимость бэкап-системы с целевой платформой можно проверить по документации за рабочий день, но в миграционном проекте таких проверок набирается около десятка, и каждая требует примерно столько же времени. Состав этой обвязки нужно определить до переноса, иначе несовместимости обнаружатся уже во время миграции. Обвязку можно разложить по девяти функциональным осям: часть возможностей заработает сразу после переноса, часть команде придётся собирать самостоятельно, а часть устроена иначе и потребует новых регламентов. В статье разберём эти группы, порядок проверок и различия между версиями платформ от сообщества; доработки вендоров поверх открытой базы рассмотрим отдельно. Это вторая статья цикла: в первой обсуждались класс решения, модель поддержки и совокупная стоимость владения. Материал рассчитан на инженеров эксплуатации и архитекторов виртуализации, которые выбирают целевую платформу или уже ведут миграцию; специалистам по ИБ будут полезны разделы о доступе к коду и регуляторных требованиях. Таблица девяти осей и чек-лист пригодятся также при переходе с Hyper-V и Nutanix: они относятся к слою оркестрации и не зависят от исходной платформы.

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

#vk_cloud #VMware #vSphere #KVM #OpenStack #Proxmox_VE #миграция_виртуальных_машин #виртуализация #резервное_копирование #аварийное_восстановление

Где заканчивается автопилот в DR: разбор оркестрации ВМ, WORM в S3, конфликтов с СРК и задач DBA

Привет, Хабр! Разбирать вопросы после эфиров — полезная практика. В чате трансляции часто поднимают темы, с которыми инженерам приходится сталкиваться на пилотах и в продакшене. На вебинаре Хайстекс про восстановление в гибридной и мультиоблачной среде мы разбирали сценарии катастрофоустойчивости. Из обсуждения в чате получился список практических тем: оркестрация, гибридное хранение, защита от шифровальщиков и совместная работа с действующей СРК. Под катом разбор этих тем и линк на демо. Кат

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

#вопросы_и_ответы #команда_разработки #разбор #аварийное_восстановление #disaster_recovery #репликация #failover #failback #oracle #s3

[Перевод] Аварийное восстановление в Kubernetes: три воспроизводимых сценария сбоя

Команда

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

#vk_cloud #Kubernetes #аварийное_восстановление #резервное_копирование #Velero #GitOps #RPO_RTO #statefulприложения #CSI_snapshots #отказоустойчивость

Бэкап конфигурации WAF за 50 секунд, или Как не терять дни работы между снапшотами

Привет, Хабр! Меня зовут Артем Токарь, я младший инженер технической поддержки в К2 Кибербезопасность . Наша команда работает в составе Центра экспертизы по комплексному сервису К2Тех и занимается администрированием средств защиты информации. В том числе мы защищаем сайты заказчиков от веб‑атак — стоим на границе между приложениями и теми, кто к ним обращается. Я расскажу, как мы искали способ бэкапить свой WAF так, чтобы не разориться на облаке и при потенциальном откате не потерять несколько дней ручной работы. Спойлер: все дело в том, что именно бэкапить. Если сохранять только те данные, которые часто меняются, резервные копии перестают стоить как чугунный мост. Например, терабайтные снапшоты можно легко заменить архивом на 50 мегабайт, который снимается за 50 секунд.

https://habr.com/ru/companies/k2tech/articles/1064340/

#waf #solidwall #бэкап_конфигурации #аварийное_восстановление #отказоустойчивость #снапшоты #postgresql #mongodb #zabbix

Почему ваш DR-план не сработает при реальной аварии (и что с этим делать)

Недавно на вебинаре Хайстекс разбирались реальные сценарии DR на практике. В чате трансляции зрители задали ряд технических вопросов, наиболее интересные из них легли в основу этого разбора.

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

#аварийное_восстановление #disaster_recovery #RTO #RPO #репликация #failover #failback #резервное_копирование #виртуализация #хайстекс_акура

Поймай меня, если сможешь [часть 1]: облако на Huawei Cloud Stack — что это, как используют и лицензирование

Привет, постоянные и не очень читатели! Всего одна сделка (зато какая — на 61 000 000 000 $) неплохо так встряхнула мир виртуализации и IT в целом: Broadcom купила VMware, упразднила кучу SKU и ввела подписную модель лицензирования крупными пакетами (многие оплачивают то, что им и не нужно вовсе, так как пакетов меньше просто нет). Самое плохое, что ни партнёры, ни конечные клиенты не были готовы к такому повороту событий и сопутствующему ущербу, а потому до сих пор оправляются. Вариантов, как все выкручиваются, много, а довольных новой моделью VMware by Broadcom — мало. Если у вас тоже наболело или вы просто зашли поглядеть на ещё один способ сложить (или нет?) все виртуалки в одну проприетарную корзину Huawei Cloud Stack , то эта серия статей для вас. Дропдаун

https://habr.com/ru/companies/servermall/articles/1042642/

#huawei #cloud #облако #частное_облако #гибридное_облако #hcs #конвергентное_облако #высокая_доступность #аварийное_восстановление #openstack

Александрийская библиотека: краткая история античной системы хранения

Вчера, если вы не в курсе, в стране отмечался Общероссийский день библиотек. Чем не повод отметить сие событие тематичной статьёй. Она не стала великой сразу и не исчезла в один день. История Александрийской библиотеки — это длинный процесс, длившийся более шести веков: от амбициозного старта к постепенному усложнению и, в конечном счёте, распаду системы, которая удивительно напоминает раннюю версию того, что сегодня называют инфраструктурой хранения данных. Всё началось с власти. Птолемеи, закрепившиеся в конце IV века до н.э. в Египте после распада державы Александра Македонского, строят Александрию как столицу нового типа — не только административную, но и культурную. Библиотека здесь возникает не просто ради собрания книг, а как политический проект: собрать тексты — значит собрать знание, а что знание — сила, понимали уже тогда. Библиотека изначально была встроена в Мусейон — учреждение, которое Страбон в книге «География» описывает как часть царского дворца, где учёные живут, питаются и работают за счёт царя. Это был не архив, а научное производство: свитки не лежали мёртвым грузом, их читали, переписывали, сравнивали, исправляли. Фактически библиотечных собраний было два: главное — в царском дворце в квартале Брухейон, и вспомогательное — в храме Сераписа (Серапеуме), где хранились общедоступные фонды и учебная литература.

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

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

Между нами SLA: как бизнесу и поддержке договориться до первого инцидента

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

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

#системное_администрирование #devops #sla #техническая_поддержка #мониторинг_сервера #инциденты #ревью_кода #рефакторинг #аварийное_восстановление #аварийные_ситуации

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

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

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

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

План аварийного восстановления (DRP): практический гайд для собственника. О чем спросить ИТ-отдел, пока все работает

Эта статья написана для владельцев бизнеса, генеральных и операционных директоров. Мы намеренно упрощаем технические термины, чтобы сфокусироваться на главном — управленческих рисках и деньгах. Ранее мы уже выпустили фундаментальный разбор Disaster Recovery (DR) : что это такое, чем RTO отличается от RPO и какие стратегии защиты существуют. Если вы еще не посчитали, во сколько миллионов обойдется вашей компании день простоя — рекомендуем начать с первой части.

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

#drp #аварийное_восстановление #drpплан #План_аварийного_восстановления

Как планы действий помогают нам работать с аварийными ситуациями в критических системах

У билайна есть разношерстный парк Unix-серверов: это AIX, Solaris, где-то есть даже HPUX на итаниуме. Они достаточно надежны, но так как они начали эксплуатироваться давно, вероятность их выхода из строя по мере расходования запаса надежности увеличивается. Часто на таких серверах работают критичные программные продукты, а данные с них хранятся на системах хранения данных (СХД), которые тоже не молодеют. Сервера питаются электричеством, которое, хотя и резервируется, иногда может дать нестандартный вольтаж, определив который системы защиты обесточат оборудование. Еще возможен внезапный глюк системного софта, например, дисковой подсистемы. В общем, мы знаем, что если что-то может пойти не так, оно обязательно когда-нибудь так сделает. Для таких случаев у нас есть планы действий в аварийных ситуациях, которые значительно отличаются от типичного плана из интернета. В этой статье расскажу, как мы их разработали и какие корректирующие действия предусмотрены в аварийно-восстановительных работах (АВР).

https://habr.com/ru/companies/beeline_tech/articles/891362/

#аварии #схд #аварийное_восстановление

Аварийное восстановление СРК: стратегии, план и кейс

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

https://habr.com/ru/companies/trinity/articles/856152/

#срк #система_резервного_копирования #бэкап #аварийное_восстановление #тринити #российское_по #отечественное_по #импортозамещение #российские_серверы #российский_софт

Непрерывность бизнеса и аварийное восстановление: в чём разница

В этой статье мы разберёмся, в чём разница между непрерывностью бизнеса и аварийным восстановлением (восстановлением после сбоя) — двумя обязательными стратегиями для любой компании, желающей избежать длительного простоя. Как объединение обеих практик повышает устойчивость к потенциально опасным для бизнеса угрозам?

https://habr.com/ru/companies/sberbank/articles/839630/

#непрерывность_бизнеса #аварийное_восстановление