Pull to refresh

Comments 5

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

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

Сожалеем, что в последние 2 недели вы столкнулись с недоступностью сервиса. Мы уведомили наших партнеров о причинах сбоев и действиях, которые мы предприняли, чтобы проблемы не повторились. Я думаю, вы согласитесь, что проблемы бывают у всех сервисов (включая Google, Яндекс и других) и, главное, быстро решить проблему «на корню». Важнейшим показателем уровня разработки можно считать и скорость работы саппорта, а она у нас на высоте.

Uptime платформы все-таки правильнее считать за длительный период, а не за две недели. Текущая проблема не связана с проблемой прошлой недели, которую мы решили. Увы, так сложились обстоятельства, что весь год мы работали стабильно (стремились к 99,99%), но за последнее время различные сбои произошли в короткий период времени.

Стоит отметить, что проблемы наблюдались только у одного узла, в котором сейчас работают свыше 25 000 аккаунтов. Практически никто в России не может похвастаться таким крупным кластером. В настоящий момент мы расширяем его и делаем более отказоустойчивым. Обязательно отчитаемся на Хабре, что мы сделали, чтобы гарантировать отказоустойчивость такого высоконагруженного сервиса.

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

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

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

Но раз уж вы написали что проблема все же на вашей стороне, хочу отметить, трехчасовой простой (который продолжается) говорит об отсутствии нормальной отказоустойчивости в вашей системе. 99.99 это всего лишь цифры, в разрезе месяца это позволяет простой 7 часов 24 минуты. Это недопустимый простой телефонии в рабочее время практически для любого бизнеса.
Дмитрий, мы написали отдельной пост про произошедшее. Можем обсудить эту тему там.

локальное инфраструктурное решение это не прошлый век, а более полноценный и надежный вариант для телефонии

Операторы связи и привыкли держать всё у себя. Но вот в плане надежности я вас не поддержку: знаю много историй, когда вендорская платформа легла, а оператор не может её поднять. Две технические поддержки толкаются и не знают что делать. Здесь мы всегда берем ответственность на себя, мы всегда доступны, у нас есть SLA. А что делать среднему оператору, у которого нет инвестиций на железо, лицензии и инженеров, которые поднимут ВАТС? Даже крупнякам сейчас выгоднее стартовать именно по модели revenue sharing (без инвестиций). Обратите внимание на нашем сайте, что мы можем разместить кластер на площадке оператора, если оно того стоит (большая база или требования безопасников). У нас есть множество инсталляций у других операторов и мы также полностью ответственны за их поддержку и обновления. Мы можем предоставить сервис в любом виде, а PaaS — новая история для операторов связи, но которую они уже распробовали и она отлично взлетела.
А все остальное остается на стороне клиента, и, как правило, представляет из себя астериск с конфигом почти по умолчанию…

Давайте разделять. Виртуальные АТС нацелены на малый бизнес (в среднем 5 человек в компании). Вы — айтишник и среди ваших знакомых могут быть специалисты, способные поднять Астериск. Но, поверьте, 98% клиентов ничего не смыслят в Астерисках, не готовы покупать железо, размещать его и тем более приглашать специалиста (я напомню, что рынок ВАТС в РФ насчитывает 80 тысяч клиентов и это не транки). Платить 10-15 тыс. рублей в год — куда выгоднее, причем за функционал, которого не будет в Астериске (подключение SIM-карт по FMC, история с фильтрацией и прослушкой звонков через веб, графические отчеты, уведомления о пропущенных и т.д. и т.п.).

Я бы не хотел искать оправданий (мы все описали в следующем посте), но падают все. Это было крупнейшее падение за нашу историю (сервису — 7 лет), мы описали причины и сделали выводы. Мы по-прежнему считаем нашу надежность одним из главных козырей. При необходимости мы можем выдержать любой SLA, но встает вопрос бюджета. Мы обязательно будем повышать uptime кластера с виртуальной АТС (на которой сейчас свыше 25 тысяч абонентов), но если вы из сегмента крупных корпоративных клиентов, то у нас есть отдельное решение с повышенной отказоустойчивостью и другими плюшками.
Only those users with full accounts are able to leave comments. Log in, please.