Pull to refresh

Comments 73

Все профессии нужны, все профессии важны!
Походу за комплимент автору статьи.
А вот за это минусуют уже вас)
… кроме сеошников, маркетологов и биржевых трейдеров.
Когда на работу людей ищете в требуемых навыках параноя >9000? Крутая у вас работа.
А параноики с нестандартным мышлением там, небось, еще в особом почете.
P.S.: а работа описана офигенно, прям завидовать стал. :)
Мне как-то страшно представлять такие ситуации, но хорошо когда готов к любому.
Думаю, это очень бережет нервы.
Очень интересный опыт! Думаю, он будет очень полезен в той или иной мере для многих компаний крупных и не очень. Спасибо за статью!
Сразу после происшествия формируются команды восстановления из специально обученных людей на объекте, имеющих подготовку по всем аспектам работы этого объекта
Скажите, а ваш план предусматривает резервную систему связи с этими людьми? Я так понимаю у них корпоративные билайновские симки, и по вашему сценарию они останутся без связи.
Дежурства в офисе решают проблему связи
Во-первых, связь, скорее всего, не ляжет, основные сервисы active-active. Во-вторых, уточню, как это происходит. Представим, что вы инженер на объекте. Что-то жахнуло, у вас на мониторинге всё отключилось, вы выглянули в окно и увидели, что машинного зала нет. У вас уже есть сценарий действий на этот случай (в примере с ЦОДом), либо, грубо говоря, конверт, который надо вскрыть и делать как там написано. Связь нужна чтобы доложить о ситуации команде более высокого уровня, и да, в этом случае мы используем и резервные каналы, самый простой из которых — обычная городская сеть (есть и другие каналы). Ещё один момент — для членов команд восстановления выход на связь всегда бесплатен, пусть даже по межгороду (если специалист, например, на Алтае).
Ясно, спасибо. Но если уж параноить до конца, некоторым ключевым фигурам наверное есть смысл выдать спутниковые телефоны. Или где-то их хранить в подзаряженном виде.
Нет в этом смысла, если «конверты» на местах есть и раз в полгода хотя бы тренировки проводятся. Все и так всё знают и наверх пойдёт доклад по уже восстановленым каналам связи.
абоненты уже полчаса без мобильного интернета, нужно выступить с данными о сроках восстановления.


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С другой стороны любая попытка выдержать катастрофу, позволяет решить обычные проблемы с отказами и прочими мелочами.
Удивительно, что никто не помянул недавнюю «катастрофу», когда билайн в центре Москвы практически выключился, включая ту самую active-active голосовую связь.
Каждый новый год у вас авария. Что идет не так?
А всего то надо строить децентрализованный и интернет и финансовую систему. Все должно быть везде.
Only those users with full accounts are able to leave comments. Log in, please.