company_banner

Готовим DRP — не забудьте учесть метеорит


    Даже во время катастрофы всегда есть время на чашку чая

    DRP (disaster recovery plan) — это штука, которая в идеале никогда не понадобится. Но если вдруг мигрирующие в брачный период бобры перегрызут магистральное оптоволокно или джуниор-админ дропнет продуктивную базу, вы точно хотите быть уверены, что у вас будет заранее составленный план, что с этим всем безобразием делать.

    Пока клиенты в панике начинают обрывать телефоны техподдержки, джуниор ищет цианиды, вы с мудрым видом вскрываете красный конверт и начинаете приводить все в порядок.

    В этом посте я хочу поделиться рекомендациями, как надо писать DRP и что он должен содержать. А еще мы рассмотрим следующие штуки:

    1. Научимся думать как злодей.
    2. Разберем пользу чашки чая во время апокалипсиса.
    3. Продумаем удобную структуру DRP
    4. Посмотрим, как нужно его тестировать

    Для каких компаний это может быть полезно


    Очень сложно провести границу, когда IT-подразделение начинает нуждаться в подобных вещах. Я бы сказал что DRP вам гарантированно нужно, если:

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

    Когда IT-отдел месяцами выпрашивает хотя бы пару HDD в старенький сервер для бэкапов, у вас вряд ли получится организовать полноценный переезд упавшего сервиса на резервные мощности. Хотя и тут документация лишней не будет.

    Документация важна


    Начните с документации. Допустим, что ваш сервис работает на базе скрипта на Perl, который был написан три поколения админов назад, а как он работает, никто не знает. Накопленный технический долг и отсутствие документации неизбежно вам прострелит не только колено, но и другие конечности, это скорее вопрос времени.

    После того, как у вас на руках есть хорошее описание компонентов сервиса, поднимите статистику по авариям. Почти наверняка они будут совершенно типовые. Например, у вас время от времени переполняется диск, что приводит к отказу ноды до ее ручной очистки. Или становится недоступен клиентский сервис из-за того, что кто-то опять забыл продлить сертификат, а Let's Encrypt настроить не смог или не захотел.

    Мысли как диверсант


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

    Обычно, большинство типовых аварийных ситуаций укладывается в следующие виды:

    • Отказ сети
    • Отказ сервисов ОС
    • Отказ приложения
    • Отказ железа
    • Отказ виртуализации

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

    После того, как типовые проблемы записаны, наливаем еще кофе и начинаем рассматривать самые странные сценарии, когда какие-то параметры начинают сильно выходить за пределы нормы. Например:

    • Что случится, если время на активной ноде сдвинется на минуту назад относительно других в кластере?
    • А если время вперед сдвинется, а если на 10 лет?
    • Что произойдет, если во время синхронизации нода кластера внезапно потеряет сеть?
    • А что будет, если две ноды не поделят лидерство из-за временной изоляции друг друга по сети?

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

    Что такое этот ваш DRP?!


    Итак вы определили модель угроз. Учли и местных жителей, которые режут оптоволоконные кабели в поисках меди, и военный радар, который роняет радиорелейную линию строго по пятницам в 16:46. Теперь надо понять, что с этим всем делать.

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

    В аварийной ситуации думать сложно! Должны быть простые инструкции для парсинга спинным мозгом.

    Хороший DRP состоит из нескольких простых блоков:

    1. Кого оповестить о начале аварии. Это важно для того, чтобы максимально распараллелить процесс устранения.
    2. Как правильно диагностировать — выполняем трассировку, смотрим в systemctl status servicename и так далее.
    3. Сколько можно потратить время на каждый этап. Если не успеваете починить руками за время SLA — виртуальная машина убивается и накатывается из вчерашнего бэкапа.
    4. Как убедиться, что авария завершена.

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

    Не надо путать DRP и паспорт системы! Не перегружайте его излишними данными. Просто дайте возможность быстро и удобно по гиперссылкам перейти в нужный раздел документации и почитать в расширенном формате о нужных участках архитектуры сервиса. А в самом DRP только прямые указания куда и как подключаться с конкретными командами для копипасты.

    Как правильно тестировать


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

    Неправильно — «Зайдите на виртуализацию и ребутните мертвую ноду»
    Правильно — «Подключитесь через веб-интерфейс к virt.example.com, в разделе ноды выполните перезагрузку ноды, которая вызывает ошибку».

    Не допускайте двусмысленностей. Помните про испуганного стажера.

    Обязательно тестируйте DRP. Это не просто план для галочки — это то, что позволит вам и вашим клиентам быстро выйти из критической ситуации. Оптимально сделать это несколько раз:

    • Один эксперт и несколько стажеров работают на тестовом стенде, который максимально имитирует реальный сервис. Эксперт ломает сервис различными способами и дает возможность стажерам восстановить его согласно DRP. Все проблемы, неясности в документации и ошибки записываются. После обучения стажеров, DRP дополняется и упрощается в непонятных местах.
    • Тестирование на реальном сервисе. На самом деле никогда нельзя создать идеальную копию настоящего сервиса. Поэтому, пару раз в год необходимо планово выключать часть серверов, рвать коннекты и устраивать другие аварии из списка угроз, чтобы оценить порядок восстановления. Лучше плановая авария на 10 минут посреди ночи, чем внезапный отказ на несколько часов в пик нагрузки с потерей данных.
    • Реальное устранение аварии. Да, это тоже часть тестирования. Если случается авария, которой не было в списке угроз, необходимо дополнить и доработать DRP по результатам ее расследования.

    Ключевые пункты


    1. Если фигня может случиться, она не просто случится, но и сделает это по максимально катастрофичному сценарию.
    2. Убедитесь, что у вас есть ресурсы для аварийного переброса нагрузки.
    3. Убедитесь, что у вас есть бэкапы, они автоматически создаются и регулярно проверяются на консистентность.
    4. Продумайте типовые сценарии угроз.
    5. Дайте возможность инженерам придумать нетиповые варианты положить сервис.
    6. DRP должен быть простой и тупой инструкцией. Вся сложная диагностика только после того, как у клиентов восстановился сервис. Пусть даже на резервных мощностях.
    7. Укажите ключевые телефоны и контакты в DRP.
    8. Регулярно тестируйте сотрудников на понимание DRP.
    9. Устраивайте плановые аварии на продуктиве. Стенды не могут заменить все.



    RUVDS.com
    VDS/VPS-хостинг. Скидка 10% по коду HABR

    Комментарии 16

      0
      Самое веселое происходит, когда забывают документацию обновить, а что-то ключевое меняется. Тогда бывает больно в экстренной ситуации.
        0
        Не, самое веселое — это когда DPR погдотовлен но не проверен. И когда наступает черный день и активируется DPR, то оказывается что например резервные IP, например, в черном списке РКН.
        +1
        «Плановая авария на продакшене на 10 минут посреди ночи» это просто замечательный совет. Такое можно проворачивать только в случае, если вы готовы к «щас у нас весь прод упадёт», по-другому лучше даже не пытаться.
          0

          Плановая "авария", когда ты перевел пользователей в резервный пул, гораздо лучше, чем вставший колом продакшен, а вы к этому не готовы.


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

            0
            А кто говорит про «переживать перезагрузку», это любой сервер должен уметь.
              0

              Это скорее крайний случай технического долга и хрупкой архитектуры.

                0
                Тут мог бы быть длинный комментарий, но постараюсь покороче: возьмусь утверждать, что в подавляющем большинстве давно живущих российских компаний малого, среднего и даже большого бизнеса IT-инфраструктура представляет из себя мешанину оборудования разной степени древности и запутанности взаимодействий; непосредственно в сервисах каша не меньшая; причём всё это с минимальным резервированием, счастье были бы рабочие бэкапы.
                И основные силы IT-служб уходят на поддержку этого разнообразия в сколь-нибудь рабочем состоянии. Бизнес на все крики, служебки и переговоры кивает головой, но как только дело доходит до денег — моментально сливается. «Работало же всё до этого? Да? Ну вот пусть и дальше работает». И чесаться начинают только когда уже рак вовсю свистит. И крайними ну вот с очень большой долей вероятности так или иначе будут те же айтишники. Которые об этом прекрасно в курсе и ночные аварии «на 10 минут» на боевом окружении в своём уме устраивать точно не будут.
                  0

                  Само собой, что это надо объяснить бизнесу в целом. "Вот смотрите, есть такой риск. Если все сдохнет, будем терять N долларов в секунду. Давайте его снимем"

                    0
                    Начал писать ответ, но притомился, так как получается слишком длинно (но я черновик сохранил, если что).
                    Краткая мысль, если мы говорим о российском не ИТ бизнесе, то там всё плохо с управлением (хотя и в нём тоже, знаю примеры весьма солидных и известных по именам контор, где просто дикий управленческий бардак).
                    Я лучше вот такую ссылочку дам, опять же возьмусь утверждать, что она покрывает подавляющую часть российского бизнеса, во всяком случае она разошлась широкой копипастой и везде все в один голос воют, что «это ж про нас»: www.facebook.com/photo.php?fbid=902645646532554&set=a.753933981403722.1073741827.100003613815841&type=3&theater
                    Это я к чему — управление рисками в ИТ? Не, не слышали.
                      0
                      Тогда, видимо, будет уместна цитата из поста:
                      Когда IT-отдел месяцами выпрашивает хотя бы пару HDD в старенький сервер для бэкапов, у вас вряд ли получится организовать полноценный переезд упавшего сервиса на резервные мощности.
                        0
                        Ну тогда у вас сферический DRP в вакууме, так бОльшая часть нашего бизнеса так и работает. Я возможно не поленюсь — и допишу свой комментарий, чтобы было больше и понятней про ИТ в таких ситуациях.
          0

          а можно ночью не надо, я часто ночью работаю

            0
            Устраивайте плановые аварии на продуктиве. Стенды не могут заменить все.

            Интерестно, кто-нибудь это реально делает и как это все проводится(в плане ответственности). Ну т.е. если продуктив после этого не запустится, типа проводившему тест придется искать новую работу?
            Я что-то с другом понимаю как представитель бизнеса(далекий от IT) будет реагировать на фразу — «эти айтишники что-то там тестировали и положили прод».
              0
              Время от времени сервер надо перезагружать. Например, если надо быть уверенным, что всё что на нём крутится, а также настройки сети корректны и запускаются после перезагрузки. Типовая проблема — настроили сеть (например, для связи с другими серверами), а после ребута не встало, а не вставшая сеть чинится посложнее, чем «зайти по ssh». Перезапуск машины время от времени позволяет ночью в час X починить его обычной перезагрузкой и спать спокойно.
                0
                Если представители бизнеса сами заинтересованы в этом, то ещё как проводятся. Слышал, что в одном банке от каждой команды (которых не мало) пару раз в год нужно дежурить в ночные часы, когда админы полносвтю выключают и переключают дата центры, именно для этого самого тестирования.
                  0
                  Согласен. У нас тоже проводится подобное. В идеале, это вообще бесшовно для пользователей и сервисов. Просто нагрузка перераспределяется, имитируя отказ одного и или двух ЦОДов.

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

              Самое читаемое