В прошлый четверг наш сервис пережил крупнейшую аварию в своей истории. Одна из инсталляций на М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 и спокойствие операторов связи, что в случае проблем есть служба эксплуатации ответственного вендора, реагирующая на опережение и устраняющая все проблемы.

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

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