×
Россия +7 (495) 960-65-87

Кейс amoCRM: как и почему мы сделали MCS основной облачной площадкой для хранения файлов клиентов

Россия +7 (495) 960-65-87
SEOnews
Кейс amoCRM: как и почему мы сделали MCS основной облачной площадкой для хранения файлов клиентов
Шрифт:
0 3297

«Облака лишними не бывают, когда файлов много и клиенты хотят, чтобы они были всегда доступны». Так решили в онлайн-сервисе amoCRM и сделали платформу Mail.ru Cloud Solutions (MCS) основной облачной площадкой для хранения файлов, сократили время доступа к ним и адаптировали работу под требования российского законодательства (152-ФЗ). О переезде в облако и пользе, которую получили клиенты сервиса, рассказывает Никита Бессуднов, SRE-инженер amoCRM.


Что дает amoCRM? Эта система помогает выстроить прозрачные, эффективные отношения с клиентами и повысить эффективность отдела продаж. Она автоматически фиксирует заявки и запросы клиентов по всем каналам, потому клиенты не теряются, а коммуникации всегда под рукой.


Предыстория

В начале пути мы работали с bare metal, но позже избавились от физических серверов. Нам нравилось, что мы могли влиять на железо и не зависели от виртуализации, но не устраивало, что у этой инфраструктуры не было ни гибкости, ни мобильности.

С облаками мы близко знакомы последние шесть лет. До этого мы подсчитали: файлы на дисках обойдутся нам дороже, чем облако. Раньше нашим облачным провайдером была компания Amazon, на мощностях которой мы хранили все файлы, которые загружают наши клиенты в систему. Параллельно мы работали с американским провайдером Rackspace. У него мы хранили и продолжаем хранить файлы наших клиентов из США.

Зачем нам еще один облачный провайдер

Впервые мы задумались о новом провайдере с серверами в РФ, когда начались блокировки Telegram’a. Тогда под раздачу попали IP-адреса Amazon’а. Клиенты жаловались на недоступность данных, и мы поняли, что нужно оперативно решать эту проблему. Amazon был не основной, а резервной площадкой, но ситуация оказалась очень неприятной и для нас, и для наших клиентов. Они не могли загрузить или, наоборот, скачать файлы со своих аккаунтов. По временной ссылке, которую мы генерировали специально для Amazon, они не получали то, что им нужно. Это первая и основная причина, по которой мы начали думать об альтернативном облачном провайдере.

Вторая причина – необходимость хранения данных на территории Российской Федерации. 152-ФЗ накладывает определенные ограничения, и мы вынуждены выполнять его требования. Соответственно, нужен был провайдер с серверами именно в РФ.

Третьей причиной стали проблемы с хранением статических файлов. Когда у Amazon’а появились проблемы с доступом, интерфейс amoCRM начал некорректно работать на клиентской стороне. Например, слетали шрифты и не подтягивались изображения, которые тоже хранились в амазоновском облаке.

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

Как мы выбирали наше третье облако

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

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

Второе: возможность быстрого переезда. У нас скопился довольно большой объем файлов – 20 терабайт. Нам было важно перевезти их в новое облако как можно быстрее, чтобы наши клиенты это не почувствовали.

Третье: высокая доступность и нахождение на территории РФ. В идеале сервис должен быть доступен 100 % времени, но это нереальные показатели. Amazon гарантировал нам доступность 99,8 %. Это много и хорошо, но проблемы настигли нас с территории РФ – начались блокировки. Плюс хранилища Amazon’а, которыми мы пользовались, находились в Амстердаме, а этот вариант не подходил под требования закона «О персональных данных».

Какие альтернативы мы рассматривали

Вначале мы смотрели в сторону облака нашего провайдера. Но нас предупредили, что оно находилось в тот момент в стадии тестирования. По разным причинам не подошло решение от Яндекса. В тот момент его облако только запускалось, также находилось в стадии beta и в первую очередь несло в себе облачные вычисления, нам же нужно было облако для файлов. И на третьем провайдере мы остановились окончательно – это было облако Mail.ru Cloud Solutions. Оно подошло под наши требования, плюс из документации мы узнали, что это хранилище совместимо с протоколом S3, который используется в Amazon. Значит, нас ждал (в теории) более-менее безболезненный переезд.

Как мы перевезли 20 ТБ в облако MCS…

Кейс получился интересным, потому расскажу о нем подробнее. Как я говорил, нам предстояло перевезти 20 терабайт. Наш обычный интернет-канал не давал возможности быстро передавать такие объемы, потому мы договорились с провайдером о том, чтобы временно его расширить.

Дальше был еще один интересный момент. Изначально шла речь о том, чтобы передавать файлы из Амстердама в Москву, а затем направлять их на площадку MCS, которая находится где-то в центральной части РФ. Но этот вариант нам не понравился – слишком долго и затратно по ресурсам. Потому мы пошли другим путем: взяли промежуточный сервер нашего провайдера (нам повезло, у него часть оборудования находилась как раз в Амстердаме), который по выделенному внутреннему каналу вначале скачивал файлы из Amazon’а, передавал их на свой сервер в Москву, а уже оттуда – в облако MCS.

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

А теперь представьте: мы переехали за 6–7 дней (цифры плавающие, так как мы несколько раз временно останавливали передачу данных) и сравнительно небольшие деньги. Один рабочий день ушел на проверку целостности файлов – к счастью, битых среди них не оказалось. Если бы мы перевозили данные на физических носителях, нам бы понадобилось 45 SSD-накопителей стоимостью 25 000–30 000 каждый, или суммарно около 2 млн рублей! Получается, мы неплохо сэкономили ☺

Кстати, у Amazon’а есть решение для тех, кто хочет переместить данные физическим способом. Они копируют эти данные на диски, а мы перевозим их так, как нам удобно. Но нам было совсем не выгодно лететь в Амстердам, подавать заявку, заниматься там бюрократическими вопросами, а затем с физических носителей переносить данные в облако.

…И что из этого получилось

Сейчас у нас три облачных площадки для хранения клиентских файлов amoCRM и основная – это как раз Mail.ru Cloud Solutions. Нам нравится, что у нее высокая доступность, а данные хранятся на территории РФ, соответственно, мы не нарушаем закон. Площадка Amazon’а осталась резервной, а в Rackspace мы по-прежнему храним файлы американских клиентов.

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

Если перевести профит в цифры, то получится, что мы ускорили работу с файлами в 2–2,5 раза – это разница в скорости, с которой отдают файлы облака MCS и Amazon. Вспоминаем блокировки Telegram’a и связанные с ними сложности доступа к Amazon’у. Теперь проблема исчерпала себя, и нашим клиентам не приходится устраивать танцы с бубном и скачивать свои же файлы VPN только потому, что мы хранили их не в России.

Еще один приятный бонус – экономия. Мы не просто получили аналогичное по стоимости решение, а теперь тратим на хранение и скачивание столько же, сколько раньше уходило только на одно хранение в облаке Amazon.

Нам приятно, что удалось улучшить user experience при загрузке и скачивании файлов. Это хорошо заметно на большинстве файлов размерами 10–15 МБ. Если раньше для их загрузки требовалось от 1 до 5 секунд, то теперь уходит не более 0,5 секунды. На скачивание такого же объема раньше уходило до 15 секунд, сейчас этот параметр не превышает 1–2 секунды. Более тяжелые файлы весом до 1 ГБ – это скорее исключение, и в их случае загрузка и скачивание длятся чуть дольше.

Облакам быть!

Мы не новички в облаках, но заново открыли для себя их преимущества после переезда на платформу MCS. Наш главный приоритет – хранилище S3. Облачную инфраструктуру используем только для внутренних проектов. У нас пока нет реального сценария для ее применения в продакшене, но планы на будущее есть. Нам нравятся контейнеры: они гибкие, быстро разворачиваются в облаке и сразу готовы к работе. На них мы экспериментировали с нейросетями для отработки действий в системе – учились предсказывать ответы на вопросы в чате с пользователями. Пока это было разовое мероприятие, но есть вероятность, что в будущем мы снова вернемся к самообучающимся системам и тогда потребуются уже полноценные облачные вычисления, в том числе на графических картах.

Онлайн-сервисам, одним из которых является наш продукт amoCRM, можно начинать работать с облаком с самого начала – тогда, когда встает вопрос о хранении клиентских файлов. Использовать для этого физические носители неудобно и невыгодно: они дорого стоят и их нужно постоянно докупать. То же самое для сервисов, которым нужны вычисления – лучше переносить их в облачную инфраструктуру, которая дает больше мобильности. Мы в свое время пропустили подходящий момент для разворачивания инфраструктуры в облаке, что обернулось большими денежными и трудозатратами. Чтобы сделать это сейчас, придется перепрограммировать систему и переделать под нее часть хранилищ, а это долго и дорого.

Какие выводы мы сделали

  • Не все облака одинаково полезны.
  • В России есть достойные альтернативы Amazon’у.
  • Переехать в новое облако можно быстро и недорого.
  • Хранить данные в облаке надежно и удобно.
  • Чем ближе хранилище, тем лучше uptime и UX.

(Голосов: 3, Рейтинг: 3.67)
Читайте нас в Telegram - digital_bar

Есть о чем рассказать? Тогда присылайте свои материалы Даше Калинской


Новые 
Новые
Лучшие
Старые
Сообщество
Подписаться 
Подписаться на дискуссию:
E-mail:
ОК
Вы подписаны на комментарии
Ошибка. Пожалуйста, попробуйте ещё раз.
Отправить отзыв
ПОПУЛЯРНЫЕ ОБСУЖДЕНИЯ НА SEONEWS
Google Data Studio: делаем красивые отчеты по контекстной рекламе для клиентов
Светлана Зубрицкая
1
комментарий
0
читателей
Полный профиль
Светлана Зубрицкая - Нужно убрать пробелы между строк и заменить кавычки на вот такие "
#SEOnews14: мы празднуем – вы получаете подарки!
Анна Макарова
358
комментариев
0
читателей
Полный профиль
Анна Макарова - Гость, добрый день! С победителями мы связывались сразу после розыгрыша. Если мы вам не написали, значит, ваш номер не выпал. Но не расстраивайтесь, у нас обязательно будут новые розыгрыши!
Как ускорить сайт на WordPress, чтобы получить 100/100 в Google PageSpeed Insights
Георгий
1
комментарий
0
читателей
Полный профиль
Георгий - Все что рекомендуется в этой статье есть у w.tools. Ни разу не пожалел что подключился. Своя CDN сеть, кеш статики и динамики, минификация js\css и кешируемого html, оптимизация всех типов картинок и еще куча всего полезного. Сайт летает и я не знаю проблем. Могу рекомендовать от души.
Война с дубликатами. Как нужно и как не нужно канонизировать URL
Ann Yaroshenko
5
комментариев
0
читателей
Полный профиль
Ann Yaroshenko - Дмитрий, добрый день! Если вы проставили на странице с автозапчастями rel=canonical ( а я вижу в коде, что не проставили) или в HTTP хедере, то бот, как правило: выберит ту страницу главной, которую вы указали в rel=canonical ссылке. Eсли же вы этого не сделали, то бот сам выберит оригинал (алгоритмы, по которым бот это делает, скрыты Googl-ом)
«Аудит, чтобы ты заплакала…», или Что делать, когда получил сторонний аудит сайта
Евгений
1
комментарий
0
читателей
Полный профиль
Евгений - Воообще, на самом деле здесь двоякое впечатление от таких аудитов. Конечно, для полного глубокого анализа и подготовки рекомендаций по сайту - нужны доступы к системам аналитики и инструментам вебмастера. Но если оценивать подобные аудиты с точки зрения чистого SEO (которое все больше и больше становится лишь малой частью digital-маркетинга, лишь одним из каналов) - они имеют место быть. Но с оговоркой, что они сделаны с учетом анализа конкурентов/отрасли. Современные инструменты и алгоритмы позволяют делать это маркетологам в автоматическом режиме, и даже давать рекомендации - возможностями машинного обучения уже никого не удивишь. Да, полное перечисление "мифического" списка ошибок, построенного по предикативным правилам, да еще и с учетом устаревших особенностей ПС - это явный признак некачественного аудита. В первую очередь потому, что эти "ошибки" следует рассматривать в качестве рекомендаций от ПС (как и говорится в справочнике вебмастера у Яндекса/Google). Однако если эти данные даются с отсылкой на данные о конкурентах, об отрасли, используются методы ML и Natural language processing для обработки исходных данных, кластеризации запросов, классификации страниц/запросов/сайтов, определения структуры документа - такие отчеты имеют право на существование. Но ключевым моментом является то, что подобные инструменты достаточно сложны в разработке, а значит требуют квалифицированных специалистов для их разработки. Которых просто нет у студий рассылающих подобные "сео отчеты". Подобные отчеты по "ошибках" тоже неплохой источник информации, но лишь на 0 этапе анализа сайта. И в принципе, теоретически, возможно почти полное составление "хороших аудитов" без участия маркетолога, на основе лишь открытых данных сайта/внешних источников, но только при соответствующем применении всех современных возможностей анализа данных и рекомендательных систем. И в любом случае подобный "хороший отчет" требует конечного заключения от эксперта.
От мечты стать юристом к собственному SMM-агентству. Как найти себя в современном цифровом мире
Гость
1
комментарий
0
читателей
Полный профиль
Гость - Статья выглядит, как резюме студента - когда рассказать нечего, рассказываешь все подряд: "а потом я школу закончил, о жизни, о том, о сем..." Удачи, конечно, ребята, вам! Но, видимо, гранит науки ещё грызть и грызть, опыт нарабатывать и нарабатывать... Дерзайте.
BDD 2019: Как перестать убивать время на сбор и обработку тонны данных для SEO-аудита
Feth
1
комментарий
0
читателей
Полный профиль
Feth - Тот момент, когда от статьи в интернете получаешь больше полезных знаний и навыков, чем от своего начальства. По статьям нетпиковцев можно учебник про SEO уже сшивать, ребята молодцы. Спасибо, что делитесь информацией.
10 элементов сайта, которые гарантированно отпугнут посетителей
Андрей
2
комментария
0
читателей
Полный профиль
Андрей - Ну типа потому что клиентское seo больше для коммерции предназначено. Типа контентники и сами знают что делать. В коммерции можно тысячу причин найти чтобы поработать с сайтом, а с контентными такие фокусы уже не прокатят, поэтому и не пишут. Всё продвижение для контентников сеошники описывают в трех словах: скорость, качество, систематичность. А, ну ещё конечно же СЯ, как же я про него забыл (фундамент жеть!).
Как вывести сайт в ТОП 10 Google в 2019 году
Анна Макарова
358
комментариев
0
читателей
Полный профиль
Анна Макарова - Сергей, в нашей отрасли много заимствований из английского, иногда с ними быстрее, проще .Но будем стараться ))
Как улучшить репутацию сайта недвижимости с помощью крауд-маркетинга
Евгений
2
комментария
0
читателей
Полный профиль
Евгений - а у вас какое впечатление от статьи?
ТОП КОММЕНТАТОРОВ
Комментариев
910
Комментариев
834
Комментариев
554
Комментариев
540
Комментариев
483
Комментариев
373
Комментариев
358
Комментариев
262
Комментариев
249
Комментариев
171
Комментариев
156
Комментариев
137
Комментариев
121
Комментариев
106
Комментариев
97
Комментариев
97
Комментариев
96
Комментариев
80
Комментариев
77
Комментариев
73
Комментариев
67
Комментариев
60
Комментариев
59
Комментариев
57
Комментариев
55

Отправьте отзыв!
Отправьте отзыв!