В прошлый четверг наш сервис пережил крупнейшую аварию в своей истории. Одна из инсталляций на М9 оставалась недоступной из внешней сети в течение нескольких часов. Что случилось? Что делать? Как должен поступить ответственный вендор? Как сохранить репутацию вендора телефонной платформы №1?

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



Что произошло?


Так случилось, что кластер, в котором живет ITooLabs Communications Server, упал. Правда, упал не полностью. В нашем облаке “крутится” более 40 больших операторских платформ и сбой даже одного сегмента — это отсутствие “Алло”, навскидку, у пяти тысяч компаний. Быть вендором с 10% рынка — это не только удовольствие, это еще и огромная ответственность. Мы никогда не питали особенных иллюзий, считая что рынок наш и можно расслабиться, но происшедшее в полной мере дало ощутить ответственность за “телефонную” жизнь огромного количества абонентов. Все предыдущие аварии проходили по большей части прозрачно для наших партнеров и оперативно устранялись, uptime соответствовал заявленным в Договорах показателям. Серьезных оснований считать, что отказоустойчивость ITooLabs требует переосмысления, не было. Не было до последнего события.

Все узлы нашей платформы резервированы. Некоторые находятся в режиме горячего резерва, некоторые разделяют общую нагрузку, но единой точки отказа нет. Это, конечно, касается и сетевой инфраструктуры — все коммутаторы установлены попарно, все сервера включены в два коммутатора, все внешние линки дублируются. Для серьезного сбоя нужно либо что-нибудь экстраординарное, типа DDoS, или Великого Блэкаута 2005 года,… либо тупая, маленькая ошибка. Мы сделали ошибку. Не будем вдаваться в технические подробности. Для тех, кто в теме, скажем лишь, что в описаниях процессов для инженеров инфраструктуры появилась запись (сделанная, разумеется, кровью) — “убедиться, что на внешнем линке отключен VTP”. Но так получилось, что в районе полудня по московскому времени сразу на двух внешних коммутаторах легли VLAN. Все VLAN. Вероятнее всего, нам прилетел осколок случившейся в тот день проблемы вышестоящего оператора — мы смогли воспроизвести похожую ситуацию на симуляторе, но в результате сервис перестал быть доступен откуда бы то ни было.

Коллегам из SaaS, без сомнения, знакомо это леденящее чувство, когда, внезапно, все ломается и остается только рёв сирены (конечно же, у нас в офисе на такие случае есть сирена), паника, первый звонок от клиента и пустая голова, в которой мечутся, почему-то, только два слова —начинающиеся с букв “Ж” и “П”.

Мы проводим много разных учений. Выпадение узла. Выпадение коммутатора. Срочный ввод нового узла для утилизации предновогодней нагрузки. Но сценария “умерли сразу два дублирующих друг друга коммутатора” у нас никогда не было.

Нам потребовалось время, несколько часов, чтобы достучаться через аварийный каналы до консоли; чтобы понять что случилось; чтобы, наконец, физически добраться до площадки. И всё это время все силы были брошены на поиск и устранение неисправности, а поддержка могла сказать лишь “У нас проблемы со связью с внешним миром. Пока не можем сообщить время восстановления.” Это вызывало у наших операторов крайнее чувство неудобства, а затем — негатив.

После осознания проблемы починка заняла считанные минуты. Сразу пошли звонки, и еще через час вернулись интерфейсы.

Но ущерб был нанесен.

Что мы предприняли?


Теперь, собственно, самая важная часть сегодняшнего, поставарийного, поста. Мы абсолютно точно знаем, что блог ITooLabs читают все наши партнеры и хотим в открытом формате отчитаться о том, какие выводы сделаны и что мы собираемся предпринять. Тем самым мы даем понять, что стремимся к открытости и прозрачности и не собираемся заниматься e-mail отписками, отрабатывая бездушный скрипт “работа с претензиями”.

  • Самое первое и важное. Мы не ждем официальных претензий от партнеров, которых задела авария, и их требований о компенсации (и уж тем более по SLA эта компенсация не такая значительная). Мы приняли решение о денежной компенсации в размере 3,5 млн рублей — вот наша цена падения, которую мы вынуждены заплатить. Мы надеемся, что это отчасти поможет вам удержать клиентов и привлечь новых. Только денежной компенсацией мы можем сохранить репутацию вендора №1.

  • ITooLabs, использующий Revenue Sharing как основную бизнес-идеологию, напрямую зависит от успешности своих партнеров. Это наша аксиома, которую мы, тем не менее, не устаем себе повторять. Происшедшее ударило по нам не менее болезненно, чем по вам. Мы это понимаем и понимали всегда. Ваш бизнес — это и наш бизнес тоже, каждый потерянный клиент — это и наш клиент. Происшедшее — это не следствие халатности и расслабленности, это неожиданная, в первую очередь для нас самих, авария. Сейчас мы четко знаем, что нужно сделать, чтобы авария не повторилась на текущем релизе платформы. Работы уже ведутся.

  • Запуску нового релиза ITooLabs Communications Server с переработанной политикой отказоустойчивости, присваивается приоритет номер один. То, что мы планировали сделать в начале 2016 года, мы сделаем в максимально оперативном режиме. Новая платформа уже готова и оттестирована. Все работает, обслуживая на реальной инсталляции до 1500 вызовов в секунду. Обещаем внедрить ее в максимально короткие сроки, поменяв приоритеты в роадмапе. Просим лишь немного подождать.

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

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

  • Мы всегда уведомляли наших партнеров в случае возникновения ЧП и отчитывались о предпринятых действиях. Но раньше у нас не было таких затяжных простоев (и, надеемся, они не повторятся). Однако, мы оптимизировали процессы и будем подробнее освещать ход событий в случае необходимости.


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

Но мы еще раз убедились в правильности моделей PaaS и Revenue Sharing. Ответственность вендора за простой платформы всегда будет максимальной и именно она обеспечит высочайший уровень сервиса. Мы были свидетелями многих аварий в операторах связи, но служба эксплуатации не могла сразу понять, что же произошло, дожидаясь долгого ответа долгой технической поддержки медленного вендора. Мы не хотим и не будем классическим вендором. Мы мониторим все инсталляции и, если происходит что-то нехорошее, немедленно реагируем и оперативно устраняем проблему “на корню”. Это обеспечивает быстрое развитие ITooLabs и спокойствие операторов связи, что в случае проблем есть служба эксплуатации ответственного вендора, реагирующая на опережение и устраняющая все проблемы.

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

Продолжение следует.

Комментарии (10)


  1. Timata
    16.12.2015 01:09
    +4

    Честно. Молодцы. Не хочу никого обидеть и тем более пиарить, но приведу вас в пример вашим конкурентам на букву «Р» (вторая «Т»).


  1. Dagobertus
    16.12.2015 01:44
    +2

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


  1. Snowly
    16.12.2015 03:48
    +1

    Не будем вдаваться в технические подробности.
    Как по мне, так эта самое интересное. Зашел в сюда, что б их прочитать.


    1. rdin
      16.12.2015 07:29

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


  1. tgz
    16.12.2015 09:39

    Вам студенты сеть настраивали? VTP отключают не на внешнем интерфейсе, его отключают везде и НАВСЕГДА!!!


    1. growler
      16.12.2015 13:10
      +1

      Здравствуйте. Нет, настраивали не студенты. Скорее даже, наоборот.

      В нашем кластере используется много разных аббревиатур, которые позволяют, при неосторожности, легко прострелить себе ногу даже более эпичным способом, чем VTP. Мы не считаем это поводом отказываться от их использования совсем; только лишь поводом совершенствовать процессы.


      1. igorsd
        17.12.2015 00:14

        Давайте зарезервируем оборудование N раз, а потом для всех этих N железок организуем единую точку отказа, которая гарантированно кладёт все N железок, без которой, к тому же, можно легко обойтись…

        Ну да, действительно — не повод.


  1. azmar
    16.12.2015 16:55
    +1

    Жаль что у оператора, через которого мы работаем с вашей платформой, не такое чувство ответственности. Связаться с ними во время простоя было невозможно, телефон поддержки не работал, почта не работала, сайт тоже. Впечатление было такое, что они просто исчезли. Особенно на 4ом часу.

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


  1. strib
    16.12.2015 23:19

    “убедиться, что на внешнем линке отключен VTP” — «эта пять!»
    Сам как вспомню, так вздрогну )


  1. Night_Snake
    24.12.2015 15:44

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

    несколько часов? До М9? Are you serious?!
    Есть MOXA с 3G. Есть резервные роутер(вариант: писюк) с подключенным там же интернетом и com-портами. Есть много чего еще, чтобы попасть на ответственный сайт в ситуации «все сломалось».
    Ну и использование VTP это, конечно, пять. При всем моем уважении к Cisco — это технология для офисных сетей (как максимум), но никак не для прод-площадки.