Моя работа — ждать IT-катастрофы



    Лучшее, что может случиться, — это если результаты того, что я делаю, никогда и никому не пригодятся.

    Можно сказать, что я профессиональный параноик: моя задача — разрабатывать планы действий на случай чрезвычайных ситуаций и обучать людей грамотно реагировать в таких случаях. Зачем это нужно? Довольно просто — чтобы в случае непредвиденных ситуаций всегда была страховка.

    Вот, например, знаете что будет, если землетрясение уничтожит основной московский ЦОД?


    1. Сработает автоматика и перебросит часть сервисов на другие ЦОДы. Всё то, что было active-active, продолжит работу (это базовые функции сети, вроде звонков и SMS).
    2. Затем включается базовый сценарий реакции. Сразу после происшествия формируются команды восстановления из специально обученных людей на объекте, имеющих подготовку по всем аспектам работы этого объекта. Например, из инженера на смене, охранника, системного администратора и так далее. Они бросают все свои текущие дела и занимаются только восстановлением.
    3. В течение первых 10 минут «бронзовая» команда восстановления анализирует ситуацию. На 11-й минуте руководитель команды докладывает команде более высокого уровня («серебряной», как правило, не присутствующей на объекте), например, главному инженеру и руководителю подразделения.
    4. «Серебряная» команда принимает решение на своём уровне. В нашем случае проблема явно особенно важная, поэтому команда связывается с «золотой» командой — руководителями самого высокого уровня. На принятие решения о том, что ситуация является чрезвычайной, уходит ещё 10 минут (это очень быстро). В течение ещё 5 минут активируются составленные нами планы аварийного восстановления.
    5. Руководители «бронзовых» команд собирают людей и идут восстанавливать, что могут, на месте. Параллельно собирается кризисный комитет, включающий известных специалистов, описанных в плане на этот случай.
    6. Далее кризисный комитет взаимодействует с HR, PR, безопасниками и другими службами. В частности, совершенно точно PR к этому моменту будет остро нуждаться в информации — абоненты уже полчаса без мобильного интернета, нужно выступить с данными о сроках восстановления.
    7. Разворачивается резервная точка. В течение 20-30 минут восстанавливается инфраструктурный слой. Затем идет восстановление СУБД и там, где надо, восстановление из архива с ленты. Далее — восстановление приложений (от получаса до дня).
    8. Параллельно в течение первого часа проверяется, как всё переехало.
    9. Затем появляются детальные отчёты. План аварийного восстановления заканчивается, и мы снова «засыпаем» до следующей ситуации.


    Риски, планы, резервирование


    Есть базовые риски (например, остановка дата-центра или пожар в главном офисе), есть известные риски от руководства, есть наш анализ критичности технических систем. Этот список рисков постоянно обновляется, и каждая из угроз должна быть закрыта.

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

    Важно понять, что мы не строим отдельные планы на каждый случай. Наши планы нацелены на устранение самой плохой ситуации. В документах есть указания на все стороны участников, просто в зависимости от ситуаций некоторые ветви планов могут быть не использованы. Это значит, что мы не делаем специальный план на случай прилёта агрессивных пришельцев, но команды восстановления смогут работать по веткам «повреждение ЦОДа» и так далее.

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

    Кроме того, что мы строим всевозможные планы по восстановлению и резервированию систем, ещё мы же делаем предварительную работу, в частности, инициируем внутри компании проекты по резервированию систем.

    Подходы к резервированию


    • Load balancing — это географически разнесённые active-active сервисы, если одна точка отключается, вторая продолжает работать. В примере выше балансировка просто перенесла основной функционал сети в другой ЦОД. Это так называемые непрерывные решения.
    • Full, Enhanced и Basic DR — это приложения высокой доступности. Класс Basic — это восстановление из бекапа (занимает несколько минут), Enhanced — это уже не бекап, а синхронная репликация, а Full — это репликация на полностью готовую систему, на которую можно переключиться за считанные секунды.
    • Best Endeavours — класс, предполагающий наличие выбранного и предустановленного оборудования.


    Таблица ниже иллюстрирует процесс присвоения ИТ-приложениям класса восстановления и технических решений по резервированию, в соответствии с RTO (допустимым временем восстановления) и RPO (допустимой точкой возврата).


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

    Срок жизни плана


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

    Пример аварии


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

    Из последних крупных примеров реальных ситуаций: в 2010 году, летом, во время аномальной жары, в основном ЦОД стали отказывать кондиционеры и останавливаться один за другим. Температура внутри ЦОД стала опасно расти.

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

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

    Как всё начиналось


    На первых этапах к нам относились только как к параноикам.

    В 2003-2004 годах тема аварийного восстановления в IT была абсолютно не известна в России (а уж про аварийное восстановление бизнеса как таковое вообще никто не слышал). Развитие пошло от безопасников: инициативные люди в подразделении информбезопасности начали продвигать эту идею. Показывали кучу презентаций, взяли в помощники консультанта, который помогал рисовать и убеждать. Ключевым моментом был пожар у одного из интеграторов, который тогда плотно работал с «ВымпелКомом». После того, как у них сгорел ЦОД, руководство всерьез задумалось. Позвали из Англии специалистов, которые разработали первые политики и стратегии, плюс дали векторы движения.

    Одним из первых шагов было введение тотального бекапа. Идея простая: вся информация подлежит резервному копированию. Даже бумажные документы сканируются и также складываются на ленту. Есть схема cross site backup, когда все, что подлежит резервному копированию, также дублируется в резервный ЦОД и там хранится по тем же политикам.

    Мы регулярно проводим обучение и проверки работы команд восстановления сервисов — это как учебные тревоги. Проводим курсы, сертифицируем, даём практику. Готовых специалистов на рынке просто нет.

    Итак, если вначале мы были параноиками, и нас не очень понимали, то сейчас всё изменилось. Во многих документах наши требования становятся блокирующими. Руководители подразделений серьёзно относятся к возможным рискам — и при этом понимают, что отчасти благодаря нашей работе, в случае любых сложных IT-проблем есть возможность быстро восстановиться. Думаю, это очень бережет нервы.
    ВымпелКом (Билайн)
    77,00
    Компания
    Поделиться публикацией

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

      +29
      Все профессии нужны, все профессии важны!
        +2
        А за что Вас минусуют?
          +6
          Походу за комплимент автору статьи.
            +4
            Суров нынче Хабр. А мой коммент неактуален, в этом тоже плюс)
              +1
              А вот за это минусуют уже вас)
          +39
          … кроме сеошников, маркетологов и биржевых трейдеров.
            +10
            И риэлторов…
          +6
          Когда на работу людей ищете в требуемых навыках параноя >9000? Крутая у вас работа.
            +6
            А параноики с нестандартным мышлением там, небось, еще в особом почете.
            P.S.: а работа описана офигенно, прям завидовать стал. :)
              +5
              Люблю вот этот Ералаш, мальчик явно годится автору поста в коллеги: www.youtube.com/watch?feature=player_detailpage&v=jh6gf0kiTlk#t=160s
              +1
              Мне как-то страшно представлять такие ситуации, но хорошо когда готов к любому.
              Думаю, это очень бережет нервы.
                +2
                Очень интересный опыт! Думаю, он будет очень полезен в той или иной мере для многих компаний крупных и не очень. Спасибо за статью!
                  +11
                  Сразу после происшествия формируются команды восстановления из специально обученных людей на объекте, имеющих подготовку по всем аспектам работы этого объекта
                  Скажите, а ваш план предусматривает резервную систему связи с этими людьми? Я так понимаю у них корпоративные билайновские симки, и по вашему сценарию они останутся без связи.
                    +1
                    Дежурства в офисе решают проблему связи
                      +7
                      Во-первых, связь, скорее всего, не ляжет, основные сервисы active-active. Во-вторых, уточню, как это происходит. Представим, что вы инженер на объекте. Что-то жахнуло, у вас на мониторинге всё отключилось, вы выглянули в окно и увидели, что машинного зала нет. У вас уже есть сценарий действий на этот случай (в примере с ЦОДом), либо, грубо говоря, конверт, который надо вскрыть и делать как там написано. Связь нужна чтобы доложить о ситуации команде более высокого уровня, и да, в этом случае мы используем и резервные каналы, самый простой из которых — обычная городская сеть (есть и другие каналы). Ещё один момент — для членов команд восстановления выход на связь всегда бесплатен, пусть даже по межгороду (если специалист, например, на Алтае).
                        +4
                        Ясно, спасибо. Но если уж параноить до конца, некоторым ключевым фигурам наверное есть смысл выдать спутниковые телефоны. Или где-то их хранить в подзаряженном виде.
                          +1
                          Нет в этом смысла, если «конверты» на местах есть и раз в полгода хотя бы тренировки проводятся. Все и так всё знают и наверх пойдёт доклад по уже восстановленым каналам связи.
                      –9
                      абоненты уже полчаса без мобильного интернета, нужно выступить с данными о сроках восстановления.


                      Хаха, абоненты все равно смогут это прочитать только после включения интернета.
                      А смогшим найти альтернативный интернет, ваши проблемы будут до лампочки.
                        +4
                        Хаха, абоненты все равно смогут это прочитать только после включения интернета.

                        В этом случае абоненты обращаются в колл-центры.
                          +1
                          Смс надо высылать, а не в интернете размещать новости. Или в виде спец сообщений выводить на экран телефонов.

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

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

                            а не в интернете размещать новости

                            Колл-центр находится в реаллайфе.

                            падает и офисная айпи-телефония.

                            Опсос и проводной провайдер всё-таки отличаются.
                              –1
                              И слону понятно, что отличаются. Просто о сбое нужно доступными методами сообщать, а не как в моем случае. Толку мне от пресс-релиза, если я его не могу прочесть.

                              Широковещательные сообщения тоже трудно разослать?
                                +3
                                Толку мне от пресс-релиза, если я его не могу прочесть.


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

                                Широковещательные сообщения тоже трудно разослать?

                                «Широковещательное сообщение» — это точно то же SMS. Отправить SMS всем абонентам не сложно, но будет дикая перегрузка SMSC.
                                  +2
                                  Вообще-то, SMS и Cell Broadcast (Широковещательные сообщения) — это «две большие разницы» с точки зрения технологии доставки на телефоны, хотя в обоих случаях рассылается текст.
                                  Тексты SMS и Cell Broadcast могут быть разной максимальной длины и на телефоны они доставляются разными путями.
                                  SMS действительно доставляется с платформы через SMS-центр в тот MSC (иногда SGSN), который обслуживает телефон-получатель, затем в BSC/RNC и BTS/NodeB. обслуживающие телефон-получатель.
                                  А текст для рассылки через Cell Broadcast доставляется с платформы через специальные шлюзы сразу в BSC/RNC.
                                  Соответственно рассылка текстов через Cell Broadcast не может вызвать перегрузку SMSC, ибо Cell Broadcast через них просто не проходит!
                                    +2
                                    Вот она, хабра, завсегда найдётся, кому уесть =)
                                    Вы абсолютно правы, а я, соответственно, ошибся.
                              +4
                              Обычно неполадки затрагивают небольшой процент абонентов, и не всегда можно точно определить какой, чтобы сделать целевую рассылку. А рассылать извинения по всем клиентам, кого это могло теоретически затронуть — это сильно вредить имиджу компании: у большинства проблемы не было, а осадочек остается.
                          +3
                          Я занимался примерно тем же, что и топикстартер, только в другом опсосе тройки. Самый большой аларм на моей памяти — когда во время очередной прямой линии с Пу упала телефония во всём регионе. Починили конечно, но в тот день стратегические запасы лечебного коньяка под фальшполом были опустошены.

                          Другой, даже в чём-то забавный, случай — когда произошла авария на электростанции. Оборудование в ЦОДе переключилось на резервное питание, но на несколько минут потерялась любая связь за пределами области, мониторинг пищал алармами по всем точкам. Ощущение было — как при атомной войне: в одну секунду сдохло сразу всё, и непонятно почему. Но тогда быстро разобрались, к счастью, буквально за пять минут.
                            +2
                            > упала телефония во всём регионе

                            Да-да, а потом ползут слухи о всеобщем заговоре, и что простым людям общение пообещали, но операторам сказали звонки не пропускать — мол, нет звонков, значит нет и проблем :)

                            Интересно, Администрация Президента мониторила, из каких регионов нет звонков?
                              0
                              Интересно, Администрация Президента мониторила, из каких регионов нет звонков?

                              Это мне неизвестно, я занимался только техническим расследованием.
                                0
                              +14
                              Вы не могли бы несколько часов пообщаться с администрацией livejournal в воспитательных целях? )
                                +13
                                Этого мало… Тоже озадачивался этим вопросом — почему на фоне внешнего лоска у нас так похабно реализуется непрерывность работы. Например

                                1) Летом 2010 года была потеряна БД загранпаспортов за ~ 2 недели (а тогда был сезон — до 15 тыс. заявок ежедневно). Позиция ФМС была обычная — потек кондиционер, а эти людишки пусть заново свои анкеты перебивают.
                                2) БД одного ОПСОСа — работает на пределе возможностей с NNNNNN-террабайтными базами. Ясно — что при таких объемах ни один Oracle работать не сможет. На вопрос — а как это делается «там» — ответ был простой — а «там» так работать запрещено. Хотя бы по закону о защите личных данных — нельзя хранить историю глубже 3 месяцев. Наши же «инициативщики» любят копить базы, логи, SMS, разговоры и пр — чуть не от рождества Христова
                                3) Еще один оператор ОПСОС — по слухам до 20% вышек связи существуют лишь на бумаге, при этом на них регулярно списываются затраты за эксплуатацию, электричество, а потом через несколько лет вписывают вчистую и заменяются новыми
                                4) В 2012 году «умер» Мегаплан — с сотнями бухгалтерий юрлиц. Официально извинились, но данные были безвозвратно потеряны.

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

                                Как же создать конкуренцию? Она не нужна государству — ему проще работать с сотней-другой олигархов, а не миллионами предпринимателей. Она не нужна коммерсантам (думаю что Билл Гейтс, что хозяин палатки с рынка спит и видит — чтобы все его конкуренты сгорели в аду — а он остался один). Конкуренция нужна только _потребителям_. Чем чаще вы будете «вякать» о своих правах, использовать все легальные механизмы для защиты своих интересов — тем быстрее мы в эту сторону пойдем.
                                  0
                                  Ну, у наших ОПСОС-ов нечто вроде вполне комфортабельно монопольного сговора, а это все следствие. Свалить все журналы в одну единую базу это, конечно, сильно.

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

                                  LJ вроде была крупным игроком, хороший рынок вроде как с конкуренцией, с ресурсами вроде нормально, аудитория большая, лояльная и тут компания берет и старательно делает все, чтобы ее на рынке не было из-за технологического долга для устранения которого нужды совершенно очевидные для соответствующих специалистов и не очень накладные меры. Это все… бессмысленно как-то. Зачем дохнуть, когда можно жить?
                                    +1
                                    У LJ насколько я знаю — отрицательная рентабельность. Отцы-основатели и те кто занимаются ее развитием — никак не могут договориться относительно инструментов зарабатывания на LJ, а без стабильного кэша такие системы не развиваются
                                      0
                                      Ничего себе, у них же за 10 зеленых лямов инкам вроде, куда стабильнее. Уж на работу кластера должно хватать.
                                    0
                                    А про Мегаплан можно по подробнее?
                                      +1
                                      Вот megaplan.ru/service/security/
                                      ===
                                      23—25 ноября 2012 г.: Авария на восемнадцатой ферме (пользователи бесплатного Мегаплана)

                                      Из-за ошибки в БД PostgreSQL были испорчены базы данных одновременно на основном сервере и на «реплике». Доступ к аккаунтам на этой ферме был ограничен. В течение 48 часов сотрудники Мегаплана восстановили, базы данных и устранили причину ошибки на всех серверах Мегаплана.

                                      К сожалению, мы не смогли восстановить данные 12 бесплатных аккаунтов до состояния 23 ноября. Эти аккаунты были восстановлены из резервной копии недельной давности.

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

                                      Насколько информация об ущербе соответствует реальности — не знаю. Но инфа вроде официальная
                                        +2
                                        последняя фраза в их тексте звучит дико смешно и голословно…
                                      +2
                                      Выходит — что многим компаниям просто тупо выгодно (либо акционерам, либо менеджменту) — экономить на дизастерных процедурах, списывают прибыль в личные доходы.

                                      Классический случай бритвы Хэнлона: «Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью.»
                                        0
                                        И такое тоже может быть. Однако на то «офицеры по процессам» и нужны — чтобы в случае тотальной глупости исполнителей система управления качеством не позволила провалиться ниже заданного уровня. Критически важные функции должны быть разбиты на фазы один настраивает — другой верифицирует), есть объективность в оценке (контролирующее и исполняющее подразделения независимы), критические требования открыты и формальны (все шаги записаны, важне цифры, режимы запротоколированы), есть единый центр ответственности (за результат коллективной работы всегда несет ответственность _один_ человек), есть баланс компетенции и полномочий (умный эксперт имеет права повлиять на процесс, а вот дурак остается без генеральских звездочек). и главное — вся эта организационная пирамида — клиентоориентирована — т.е. служит удовлетворению целей и интересов внешнего клиента, замыкая все обратные связи на его критерии успешной работы.
                                          0
                                          Можно я вас полюблю? Это наконец-то найденная хорошая формулировка моего мнения по поводу «откатов и распилов». Спасибо.
                                      +21
                                      IMHO недостаток подобных планов, что в них слишком много внимания уделяется «человеческому» согласованию. Как уже писали — сначала нужно оповестить команду восстановления (а как — если связь тоже разрушена ?), затем принимать решение во всяких точках развилки — поднимать резервный дамп или нет, запускать второй ЦОД или нет, переключаться на резервные каналы связи и электропитания или нет.

                                      И в каждой из этих точек, как правило работа идет в «gray zone» — «серой зоне», — когда нет ни одного характеристического параметра — позволяющего однозначно принять решение, а приходится принимать решение по совокупности у целом малозначащих параметров. А человек в такой ситуации работает крайне плохо — удерживая во внимании не более 5-7 факторов. Если больше — начинаются ошибки — как технические — так и ментальные. Один из клиентов — спасая свою БД с архиважными данными — просто тупо вместо снятия дампа с боевой системы и переноса ее на резервный, сделал все наоборот — поднял на боевую БД копию с резервного сервера… Вообще ошибок масса — и чем глупее, тем они более ожидаемы — другой сисадмин случайно не сменил дату — и система весь день работала на старых курсах валют, третий — изменил системный пароль — под которым проходит восстановление и сам уехал в отпуск — в итоге восстановительные процедуры не смогли перехватить управление, у четвертого — отсоединился кабель монитора — и он думая что система ушла в BSOD — грубо ресетнул многотеррабайтную БД.

                                      Как поступать? Сделать систему более адаптивной и обладающей навыками самовосстановления. Большую часть ума переложить на ИТ, а не на человека — который по сути будет выполнять роль статиста. Он будет помогать системе только — когда будет случаться явно непредвиденная история, которую нельзя отследить по датчикам — в одном из банков в жаркое лето — сисадмин решил переставить 50 л аквариум с рыбками в холодную серверную, да забыл про порожек…

                                      Например — если была обнаружена просадка по времени отклика — переходить на резервные каналы не тогда, когда основной уже на 99% заполнился, а например всего лишь на 20% перегрузке относительно среднего. Считается (по принципу Парето) — на таком отклонении начинают проявляться новые качественные изменения, которые невозможно заметить. Но можно делать не по фиксированной границе, а на нелинейной модели (чаще всего применяется fuzzy logic)

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

                                      В чем можно «погореть» в адаптивной самовосстанавливаемой системе? Практически ни в чем — одно «но» — нужно быть максимально автономным и независимым от объекта восстановления. Нужно развязываться по сигнальным цепям, питанию — так чтобы сохранить «свежесть ума» на протяжении процесса восстановления. Любая завязка может дать ненужный поток дерьма, плывущий в обратную сторону… Как-то коллеги рассказывали — что Газпром для питания своих транзитных насосных станций использовал только попутный газ. Что произойдет — если в магистрали будет ледяная пробка !? Правильно — «умрет» вся автоматика вниз по цепочке из всех станций… Схожая история была и в астраханских сетях — когда сигнальный провод вдоль трубопроводов очень понравился местным сусликам…

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

                                        0
                                        Системы, может, и будут умнее, но есть ещё люди, которые их проектируют, устанавливают, настраивают, меняют по ходу развития проекта. Сумеют они учесть все возможные нештатные ситуации — всё будет работать отказоустойчиво. Знать бы только ещё их все…
                                        +2
                                        Вот, например, знаете что будет, если землетрясение уничтожит основной московский ЦОД?

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

                                        На каком именно объекте? На только что разрушенном землетрясением? Предположим, здание ЦОД действительно будет полностью уничтожено, — как именно и в какой срок вы об этом узнаете?
                                          +2
                                          Подозреваю, что узнают первыми, только сказать никому не успеют.
                                            0
                                            Основная команда — на резервном объекте.
                                            Первая задача людей на месте — понять, нельзя ли сделать что-то локально. Если это не выходит, разворачивается резервная площадка. Поэтому даже в том крайне маловероятном случае, когда на объекте никого не останется, и с ближайшего будет очень долго добираться, восстановление пойдёт в примерно те же сроки.
                                              +4
                                              Если Московский ЦОД уничтожит землятресение, это будет меньшая из всех бед ) В Москве при строительстве нормативы для сейсмоопасных зон не используются. Если у ЦОД 5-10 этажей и у него обвалились перекрытия, то полгорода при этом тоже будет в руинах.
                                                +1
                                                Да полгорода то ладно. Я вот с трудом представляю, что такого может случиться, чтобы в Москве вообще было землетрясение такой силы.
                                                Разве что подземный ядерный взрыв очень большой мощности, или глобальные подвижки литосферы. Но в обоих случаях «полгорода в руинах», не говоря уж об уничтожении ЦОДа — станет настолько малозначительно.
                                                  +3
                                                  Прилетит метеорит как в Челябинске и жахнет прям в ЦОД. Город вроде цел, а ЦОДа нет. Год назад это казалось бы паранойей, но теперь… ))
                                              +1
                                              Судя по картинке к посту, ни IT ни более важные вещи, нам, в этом случае, уже не пригодятся.
                                                +4
                                                А вы учитываете, что в случае землятресения, которое уничтожит ЦОД ни одной из ваших команд может просто-напросто не существовать ко времени запланированного старта работ?

                                                Или, если _действительно_ такая бяка случится (например, мега-землятресение) все люди, задействованные в вашем плане попросту не смогут/не захотят заниматься восстановлением ЦОД-а?

                                                Или такие действи автоматически считаются форс-мажорными и что будет в таких случаях вообще никто не рассматривает?
                                                  0
                                                  Когда комманде будет не до связи, то остальным абонентам скорее всего тоже уже связь не пригодится.
                                                    +6
                                                    у связистов есть такое понятие как «мобилизационный план». Как раз для обеспечения связи в такие форс-мажорах. Правда — это не мешает им на него класть болт. Например — у меня дома снесли медный провод и поставили в квартиру GPON маршрутизатор ч/з оптоволокно. Вопрос на засыпку — если не будет электричества в подъезде — как дозвониться до скорой, пожарников, газовщиков и пр.?
                                                      0
                                                      Вопрос на засыпку — если не будет электричества в подъезде — как дозвониться до скорой, пожарников, газовщиков и пр.?

                                                      Ответ — никак, если вы не озаботились включением маршрутизатора через ИБП, это вам даже оператор связи скажет.

                                                      Раньше была такая штука как АВУ (абонентское высокочастотное уплотнение), которая позволяла по одной паре подключить два неспаренных номера. При этом у одного абонента все выглядело обычно, а у другого стояла серая коробка, которая не работала без сетевого питания, и телефонный аппарат с трехпорводным подключением к этой коробке.

                                                      Проблема «как позвонить в диспетчерскую, когда неожиданно прекратилась подача электроэнергии» не нова, но она все еще мало кого волнует.
                                                      0
                                                      Ещё раз — при потере критичного объекта восстановление идёт на резервной площадке. Речь о команде на этом объекте, способной за минуты сделать всё необходимое, а не бегать и паниковать. Обучение их — наша работа. Для восстановления основного ЦОДа — это резервный ЦОД в другой географической точке. Грубо говоря, резервная точка тоже появляется в результате нашей работы, поскольку мы заранее думаем об этом.
                                                        0
                                                        Мне такая ситуация напоминает анекдот про бензопилу и рельс. Понятно, что если здание физически будет уничтожено, или будет в аварийном состоянии на грани разрушения — никто ничего не восстановит. Но такая ситуация всё-равно, что стихийное бедствие. Все знают, что такое может быть, но вот подготовиться к нему невозможно.
                                                        P.S. сам пытаюсь выбить «железо» на резервные точки для бэкапов, но гос.контора…
                                                        P.P.S Промахнулся с веткой.
                                                        +3
                                                        Я не понимаю, почему по вашему плану понять, что ситуация чрезвычайная, занимает 20 минут и это ещё «очень быстро».
                                                          0
                                                          Человеческий фактор — если все начнут пониковать и пытаться разобраться уйдет несколько часов
                                                          0
                                                          Как вы доказываете руководству, что восстановительные процедуры, описанные для чрезвычайной ситуации, корректно валидируются при учениях? Например, при учениях, очевидно, нет возможности вырвать питание из сервера и системы хранения — во-первых, они могут быть задействованы в других системах, во-вторых, если повредятся «живые» данные, то начальство по голове не погладит. Значит, процедура для учений должна предполагать корректное отключение систем для имитации катастрофы. И тогда где гарантия, что при настоящей катастрофе по протестированному плану удастся восстановить производство?
                                                            +1
                                                            нет возможности вырвать питание из сервера и системы хранения

                                                            Почему нет? Отключают питание, сеть, без проблем, это не страшнее, чем любые другие работы. Но делается это по ночам, вот и всё.
                                                              0
                                                              Предположим, у вас система хранения, на которую пишет биллинг. Вы вырываете питание, база повредилась, восстановиться можно только из бэкапа с потерей, например, 1 часа данных. Это какой же бизнес разрешит вам выкинуть десятки тысяч долларов просто для того, чтобы посмотреть «чё будет»?
                                                                +1
                                                                Ужа давно существуют базы данных которые при правильном бекапировании позволяют не терять вообще никаких данных.
                                                                  +2
                                                                  Такой биллинг находится не на одном сервере, а на кластере минимум из двух разнесённых географически серверов + стендбай, на который в онлайне реплицируется БД. Ноды в кластере находятся в идентичном состоянии. При пропадании связи с боевым сервером, внутренний мониторинг тут же переключает систему на резервную ноду, для внешних подсистем это абсолютно прозрачно, не меняется ничего (разве что установленные коннекты к базе рвутся, но это не страшно). Инженеры разбираются со сбоем, синхронизируют сервера, и всё возвращается на круги своя.

                                                                  Больше того, данные с коммутаторов, перед тем, как попасть в базу, тоже бекапятся. И даже если чпокнется весь кластер (такое, на моей памяти, тоже бывало), максимальный ущерб будет в потере реалтайм-тарификации, т.е. деньги со счетов спишутся не моментально, а после починки. И то, только в том случае, если кластер проваляется достаточно долго, потому что RT занимается ещё одна подсистема, держащая что-то вроде кеша абонентских балансов.
                                                                    0
                                                                    Вы пытаетесь мне доказать, что существует универсальное решение «one size fits all», которое годится для всех видов ИТ-инфраструктур. Возможно, такое решение есть. Но меня интересует не это решение, а то, как можно доказать, что учения адекватно симулируют боевой отказ. Заказчик, для которого мы писали DRP, ещё на стадии согласования сделки спросил, как мы можем гарантировать, что процедуры в плане позволят восстановить продакшн на резервной площадке. Мы сказали, что учения являются гарантией. Однако процедуры учений сильно отличаются от того, что может случиться в реалии, именно потому, что мы не хотим при учениях повредить данные. Увы, у заказчика не «идеальная» архитектура.
                                                                      0
                                                                      Про универсальность вы сами придумали. Было конкретное предположение, цитирую:
                                                                      Предположим, у вас система хранения, на которую пишет биллинг.

                                                                      Я рассказал о том, как в подобной системе можно минимизировать потери.

                                                                      Но меня интересует не это решение, а то, как можно доказать, что учения адекватно симулируют боевой отказ.

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

                                                                      Но на практике проблема не в адекватной симуляции отказа, а в том, что при авариях случается то, чего никто и предположить не мог (начиная от неизвестного бага в прошивке коммутатора, заканчивая нерегламентированными действиями техников). Для того и нужны сотрудники, вроде топикстартера.
                                                              +1
                                                              Для хранения в бэкапе всего и вся какие вы можете порекомендовать решения для систематизации?
                                                                +1
                                                                Мы используем Symantec (Veritas) Net Backup. Но также неплохо себя показывают и другие backup-решения (рассматриваем кроссплатформеные решения) от IBM (Tivoli), BMC, HP и CA.
                                                                0
                                                                Можете подробнее рассказать про систему хранения, при помощи которой делается репликация данных во второй ЦОД?
                                                                Какой вендор, какие модели?
                                                                  0
                                                                  СХД у нас построена на базе массивов HP и Hitachi. Репликация у нас на аппаратном уровне средствами массивов HP и Hitachi (True Copy) и на софтверном уровне средствами Oracle (DataGuard).
                                                                  0
                                                                  Ну на поверхностный ( без изучения реальных документов :) ) взгляд

                                                                  — не надо говорить об анализе через 10 минут. Хорошо если на месте «команда» соберется, а удаленные команды созвонятся. И пока они реально в работу войдут. Все что можно ожидать через 10 минут — тупо прочитать инструкцию и принять формальное решение об эскалации.

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

                                                                  С другой стороны любая попытка выдержать катастрофу, позволяет решить обычные проблемы с отказами и прочими мелочами.
                                                                    0
                                                                    Удивительно, что никто не помянул недавнюю «катастрофу», когда билайн в центре Москвы практически выключился, включая ту самую active-active голосовую связь.
                                                                      0
                                                                      Каждый новый год у вас авария. Что идет не так?

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

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