Планирование аварийного восстановления. Часть первая

    Определяем места, где стоит подстелить соломку




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

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

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

    1. Составляем список критичных пользовательских ИТ-сервисов

    Цель планирования аварийного восстановления — обеспечить оперативное восстановление работы конечного сервиса, который получает пользователь, а не какой-то конкретной железки или программы. Пользователю не важно, работает или сломан его принтер – ему важно может он отпечатать документы или нет. Жаловаться пользователь будет не на то, что в сервере отказал жесткий диск, а на то, что у него не работает «1С-ка» или «почта».

    По этой причине первое, что мы делаем – определяем список критичных пользовательских ИТ-сервисов, для которых будем планировать аварийное восстановление. Обычно это:

    • Электронная почта,
    • Телефонная связь,
    • Система управления предприятием,
    • Совместная работа с документами,
    • Печать документов,
    • Доступ в Интернет,
    • И так далее.

    По сути, пользовательские сервисы – это те рабочие инструменты, которые покупает бизнес, вкладывая деньги в железо, ПО и зарплаты специалистов и которые критичны для его функционирования. К примеру сервер «Counter Strike», конечно же, является важным элементом в вопросах улучшения рабочего настроения сотрудников, но не критичным для работы бизнеса.

    2. Определяем точки отказа пользовательских сервисов

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

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

    Так, у сервиса «Электронная почта» могут быть следующие точки отказа (включая, но не ограничиваясь):

    • Серверная ОС,
    • Серверное почтовое приложение,
    • Коммутатор ядра,
    • Электроснабжение,
    • Внешняя зона DNS,
    • Попадание в «черные списки»,
    • Кондиционирование серверной.

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

    3. Определяем зависимости точек отказа

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

    Для пользовательского сервиса «Электронная почта» зависимости точек отказа могут выглядеть так:


    Схема 1. Зависимости точек отказа.

    В данную схему необходимо добавить и остальные критичные пользовательские сервисы и соответствующие точки отказа.

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

    Часть 2: habrahabr.ru/post/226681
    Часть 3: habrahabr.ru/post/228115

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

    Подробнее
    Реклама
    Комментарии 32
    • 0
      Схему руками рисовали или софт? По теме — спасибо, удобная методология.
      • 0
        Схема сделана руками в Visio.
        • 0
          Спасибо. Очень наглядно получилось. Я под такие задачи обычно Mindmap использую типа Xmind
        • 0
          ikormachev Спасибо! Сегодня при переводе описания доклада столкнулась с терминами: автономные компьютерные системы, самовосстановливающиеся / самоадаптивные системы. Собираетесь ли раскрыть и это направление?
          • 0
            Т.н. «самовосстановливающиеся системы» в рамках данных статей рассматриваются исключительно в качестве «точек отказа». Речь не о том, какие надежные системы существуют, речь о том, как подготовиться к ситуациям, когда даже надежные системы дают сбой.
          • 0
            Обожаю такие штуки. Всё ясно, просто и понятно.

            Пока не приходит пушистый лесной зверь. Допустим, баг в софте, который возникает при условии наличия в почтовой базе письма с определённого размера вложения определённого типа с возрастом больше пяти дней. При наличии такого письма почтовый сервер перестаёт принимать нове письма и держит коннекты с входящими серверами на DATA, не отвечая ничего.

            И как ваша схема позволит отладить эту проблему? То есть понятно, что «дело в софте», но где именно — «шут его знает». Для усиления драмы — после отката на бэкап недельной давности всё работает, но недельный откат никого не устраивает, а бэкапы за последующие 6 дней не поднимают сервер.

            Я к тому, что в жизни оно обычно ломается не там, где подстелили соломки и укрепили, а совсем в неожиданных местах.
            • +1
              Есть вполне определенный и конечный набор того, что может сломаться. Задача планирования аварийного восстановления — знать, как восстановить, в какой момент принять решение о полном восстановлении и сколько в целом есть времени на исследование инцидента. То что спрашиваете вы, не входит в рамки аварийного восстановления — это уже вопрос управления Проблемами (поиска и устранения причин повторяющихся инцидентов).

              Тем не менее, в рамках устранения Инцидентов если в ограниченные временные рамки не удается выявить точную причину сбоя, то сбойный элемент остается для дальнейшего исследование, а восстановление сервиса проводится с использованием других резервов. В дальнейшем сбойный элемент можно подвергнуть детальному исследованию.
              • –1
                Я привёл простой и печальный пример, в котором надо выкинуть нафиг бюрократию с Инцедентами, Планами, Управлением, Перекладыванием-ответственности-на-кого-нибудь-другого и прочими попытками бюрократов управлять IT.

                Этот печальный пример имеет два решения: либо контора теряет почту за неделю (при ежечасных бэкапах), либо кто-то саммонит сисадмина и тот применяет 'head' на 'installation', на выходе которого образуется решение проблемы, не описанное в схемах.

                И по жизни именно так. Потому что попытка описать поведение тьюринг-полной системы требует больше, чем тьюринг-полная система (задача занятых бобров) и в общем случае не может быть решена.
                • +1
                  И да и нет. Если у вас для восстановления есть несколько дней, то можно вообще ничего не планировать и не заниматься «бюрократией с инцидентами», а положиться на то, что сисадмин «сделает все как надо». Но когда речь идет на часы, а то и на минуты и цель в том, чтобы это всегда были «часы» или «минуты», а не дни, без планирования не обойтись.
                  • –3
                    Ну, раз вы держитесь за бюрократию, даю установку:

                    бэкап раз в час, допустимые потери почты — не более полутора часов, предельный даунтайм — 4 часа.

                    Сервер упал. Все бэкапы младше недели (и текущая база) приводят к падению всех доступных версий сервиса. Восстановление из бэкапа занимает 30-40 минут.

                    Слово передаётся «планированию».
                    • +1
                      Не все так быстро — ждите вторую часть.
                      • 0
                        Ну, достойный ответ бюрократии.

                        А я ещё раз повторю мысль, что никакая бюрократия:

                        а) не спасёт от field work
                        б) не позволит предсказать сколько это займёт
                        в) не поможет сократить умственную часть работы.

                        Всё, что может сделать бюрократия — это сократить время на бюрократию и неразбериху, пока человека не проинформируют о том, что work time.
                        • +1
                          Вы отличаете бюрократию и планирование? Или по вашему мнению героизм и отвага позволят в любой ситуации добиться восстановления сервиса во вполне определенные временные рамки?
                          • –1
                            1) Я не различаю бюрократию и планирование. Это разные названия одного и того же процесса — придумывания «кому что делать когда что-то случится».
                            2) Мысль, которую я говорю (ещё раз повторить список?) сводится к тому, что никакими методами нельзя добиться гарантий временных рамок для восстановления сервиса.

                            Можно как-то формализовать прелюдию, можно как-то формализовать оповещения и то, что любят онкологи, 'expectation management', но вот сам процесс починки может в любой момент из рутинного превратиться в «творческий». В котором нет ни дедлайнов, ни каких-либо обещаний, ни гарантий. Только best efforts и то, если сильно надоедать не будут.

                            Разумеется, не все аварии такие. И бюрократия хорошо умеет справляться с авариями, о которых она подумала. Проблема реального мира и занятых бобров в том, что никакой бюрократии в принципе не хватит на то, чтобы предусмотреть всё. «В принципе» — это именно «в принципе». То есть не хватит и точка.

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

                            А потом горько плачется, мол, «не соблюли KPI» и грозятся всякими карами.
                            • +2
                              Мысль о том, что все предусмотреть нельзя — здрава. Но это не отменяет пользу бюрократии в обычных ситуациях, как вы правильно сказали, только не нужно давать ей возможность контролировать вообще все.
                              • +1
                                Если я правильно понял Ваш пример, он заключается в следующем: есть некоторая заложенная ошибка в ПО, которая при наступлении определенного события в будущем (прошествии периода времени, определенной даты («проблема тысячелетия») или выполнения ряда действий) приводит к необратимой потере данных, что даже восстановление из резервных копий не дает никаких результатов. Приводя данный пример, вы говорите, что все планы и «бюрократия» в этом случае идут лесом и надо просто дать время админу разобраться в случившемся, провести реверс-инженеринг программного обеспечения, найти ошибку в ПО и героически устранить ее.

                                Дак вот, плохая новость в том, что админ в таких ситуациях совершенно бесполезен. Точно также, как бесполезен офисный админ в вопросах «починки Интернета», когда проблемы в сети на M9, даже если в офиса 3 канала «Интернет» от разных провайдеров. Хорошая в том, что от него не требуется в таких ситуациях применять героизм и отвагу, а требуется обратиться к разработчикам/операторам связи и т.д. и привлечь их к решению данного вопроса. Планирование аварийного восстановления как раз и помогает заранее обозначить зоны ответственности и возможности по восстановлению, и согласовать их с руководством, чтобы в момент работы над аварией никто тебе не грозил «KPI». Этой темы я коснусь в третьей статье.

                                Также что касается заложенной ошибки в ПО я за свою практику знаю только об одном случае, когда это привело к потере данных — это отказ сверхнадежной и супердорогой СХД, когда через 3 дня разбора причин сбоя разработчики вендора признали, что допустили ошибку в коде, приводящую в определенных условиях к потере конфигурации СХД. Но этот сценарий проще, т.к. тут были регулярные ленточные бекапы и даже было хранилище попроще, куда все это можно было восстановить. Что касается ошибки в базе данных, которая приводит к невозможности восстановиться даже из корректно созданной резервной копии, то, на мой взгляд, в этом случае разработчики ПО будут кровно заинтересованы в том, чтобы устранить данный баг вне зависимости от наличия или отсутствия сервисного контракта, т.к. само по себе наличие возможности такой потери данных ставит крест на будущем данного продукта на рынке. Лично мне не известно ни одного случая приведенного вами сценария.
                              • 0
                                знаете, у разработчиков, когда объем методологий и планирования начинает зашкаливать, есть фраза «ПИШИ КОД, БЛ.ТЬ». Тут то же самое. Зачем это все, если в конце концов все разгребает пара человек? Без планов, графиков и отчетов. Просто придут и сделают. Потом отчитаются об ущербе и что можно сделать, чтобы это не повторилось. Вот расскажите, чем ваша схема может ускорить подъем почтового сервера?
                                • 0
                                  Приведенная схема зависимости точек отказа помогает:
                                  1) В формировании плана локализации, который сокращает временя на определение отказавшего элемента.
                                  2) В определении влияния отказа того или иного элемента на бизнес, для последующего обоснования перед руководством необходимости его резервирования.
                                  3) В определении необходимых и достаточных компетенции для устранения последствий аварий. К примеру, если у нас упал гипервизор, то мы будем посреди ночи не только специалистов по виртуализации, но еще и спецов по прикладным системам, чтобы те потом проверили и в случае необходимости восстановили зависимые точки отказа.

                                  Ну а что касается «ускорения подъема почтового сервера», то для этого есть несколько критичных условий:
                                  1) Доступность резервов для восстановления.
                                  2) Доступность компетенций для оперативных работ.
                                  3) Проработанность процедуры аварийного восстановления.
                                  И еще пара моментов, о которых речь пойдет в следующей статье.
                                  • 0
                                    Спасибо, теперь понятнее. Не ясно, как же оно будет на практике выглядеть, но может кому-то пригодится )
                                    • 0
                                      Забыл самое главное — данная схема позволяет дополнительно проверить, что вы не пропустили никакую из точек отказа. А то так часто бывает, что приготовились ко всему, а какую-то маленькую деталь из планирования упустили и именно она и стала причиной сбоя. Так, например, регулярно из зоны планирования аварийного восстановления упускаются всякие аппаратные ключи лицензий, которые в компаниях в одном экземпляре и без которых, естественно, ничего не работает.

                                      Именно поэтому я вынес этап анализа в отдельную статью, т.к. в процессе планирования аварийного восстановления по моему опыту этот этап самый важный.
                  • 0
                    Даже в совсем непредсказуемой ситуации разумная бюрократия несколько помогает, в вашем примере — автоматически подымаем недельный бэкап на другой виртуалке, саммоним админа, пока он исправляет ситуацию и ищет причину пользователи могут работать с почтой, когда появилась ясность — объединяем базы.
                    Только на днях словил похожую ситуацию, когда телефония сошла с ума и все звонки начали уходить на одного человека, т.к. был план на такие случаи, дежурный инженер спокойно откатился на суточный бэкап и компания продолжила работу в штатном режиме, я получил оповещение (был в пути и смог добраться только через 4 часа) спокойно нашел причину, починил, объединил базы звонков и записи разговоров, переключил на починенный вариант, ни какой паники и оборванного телефона по случаю что встали почти все процессы на предприятии. На сколько я понял топикстартера система не замена мозгам и прямым рукам, а дополнение.
                    • 0
                      Все верно. Наличие необходимых компетенций и прямых рук — это одно из условий успеха аварийного восстановления. Планирование позволяет прямым рукам спокойно работать даже в случае аварии и не сталкиваться с «приятными» неожиданностями.
                  • 0
                    Хорошее начало, но маловата статья что-то. Даже для прелюдии.
                    • 0
                      Когда написал черновик, было даже много для одной статьи. Затем я выкинул из него булшит, эмоции, «искрометный» юмор, лишние детали, а также то, что все и так знают. После этого выпарил оставшуюся воду, выкинув из статьи выводы, которые все сами могут сделать, и, в конечном итоге, оставил только саму соль. Перестарался?
                      • 0
                        Не знаю, насчёт выкинутого контента, но в остатке из всего полезного осталась только схема. Возможно стоит уменьшить количество частей, но увеличить объём каждой, иначе можно сделать бразильский сериал с одним абзацем в каждой серии. Если я читаю статью, я ожидаю хоть какой-то логически завершённый объём знаний, информации, полезной нагрузки. Даже если статья предполагает продолжение, должна быть пища для размышлений над первой частью.
                        А сейчас ощущения передаются текстом об ошибке известного архиватора «Неожиданный конец архива».
                        • 0
                          Критика принимается. Постараюсь в дальнейшем не совершать таких огрехов.
                    • +1
                      Зависимости точек отказа.


                      В терминологии ИБ это обычно соответствует Модели угроз — раздел целостность и доступность.

                      Вообще все давно рассказано. Есть стандарт Cobit по управлению IT, в нем как раз описаны стандарты эффективного управления IT, описаны уровни зрелости компании. Как правило управляемость ИТ в рядовых компаниях находится на уровне 0-1 — уровень Анархии. Вот как раз пример из комментов показателен.
                      Это когда что-то упало в почтовике и админы с шашкой наголо героически восстанавливают, как бог на душу положит. Никаких формальных процессов как действовать не предусмотрено.
                      В таком режиме пожарника и строится вся работа.

                      Конечно, все возможные ситуации описать и прикрыть невозможно, но можно описать и закрепить действия при выходе ситуации за рамки обычного. Случился крах ядра почтовика? Нет инструкции как это починять? В дело вступает инструкция «нештатная ситуация», по которой сисадмину дается час на попытку устранения «нештатки», после этого проблема уходит в платный саппорт продукта, который подключит все свои ресурсы, разрабов и ожидаемо -быстро- решит проблему.
                      А без такой инструкции сисадмин может и 2 суток пинать почтовик пытаясь понять в чем дело, раздавая обещания «вот щас щас разберусь в чем дело». Может разберется, а может и нет.
                      • 0
                        Вообще стандарт Cobit — это нечто непонятное за семью печатями и в общем случае недоступное обычному обывателю. Такой священный Грааль. Вы сами то его читали?
                        • 0
                          Ну скажем так Cobit, это довольно масштабная высокоуровневая вещь описывающая роли ИТ в бизнесе, поэтому с точки зрения практики может показаться довольно непонятной.

                          В принципе если вы оутсорсеры, то вам полезнее ориентироваться на стандарты ITIL (что вы и так наверняка делаете), Cobit это больше область службы Заказчика (или CIO).

                          • 0
                            Что Cobit, что ITIL — это лучшие практики менеджмента, но в них, увы, содержаться лишь трактовки конечного результата, без инструкцию по их достижению.

                            Ни в коем случае не принижаю ценности и значения этих документов, однако помимо общих терминов в реальной жизни ты сталкиваешься еще и необходимостью разработки методологии по тому как составить ИТ-бюджет, провести анализ рисков, спланировать аварийное восстановление, или же сделать аудит ИТ-инфраструктуры или ИТ-отдела. Т.е. ты всегда стоишь перед вопросом как из состояния где ты находишься сейчас перейти в состояние по ITIL или хотя бы к его подобию. Собственно, эти процессы я и описываю в своих статьях.
                      • +1
                        Вторая часть: habrahabr.ru/post/226681/
                        • 0
                          Заключение: habrahabr.ru/post/228115/

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