CRM в облаках

Наша компания «Протон» обслуживает сеть автодилеров. И у нашего бизнеса в какой-то момент возникла задача реализовать CRM-систему.

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

В какой-то момент наш бизнес потребовал, чтобы сотрудник в момент общения с клиентом мог заносить эти данные сразу же. И возникла задача реализовать CRM для автодилера.

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

Поскольку у нас в подразделениях используется примерно 30 однотипных баз, 5 достаточно уникальных конфигураций, в которых работает более 1000 сотрудников, у нас появилась идея вытащить весь контур CRM в отдельную базу, чтобы она могла общаться по HTTP-протоколу с любым оборудованием – с любыми планшетами и т.д. – чтобы можно было отвязаться от ограничений 1С.

Преимущества и недостатки отделения контура CRM в отдельную базу

Идея, конечно, хорошая, но надо подумать, что мы с этого получим.

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

• Также появляется независимость от учетного контура. Мы можем поменять свою учетную базу – сегодня мы работаем на Альфа-Авто, завтра поменяли на УТ, потом перешли на ERP – при этом CRM у нас остается одинаковым, мы его не меняем, он у нас как жил, так и живет.

• Для компаний, которые живут в 30-ти базах, было важно консолидировать информацию – в кои то веки мы узнали, сколько у нас клиентов, узнали, что мы толком-то не знаем, как их зовут, потому что приезжая в разные места, они оставляют о себе разные данные, и достаточно сложно однозначно сказать – Олег это или Руслан, например.

• Также в ходе разработки мы столкнулись с тем, что есть финансовая структура (это подразделения, организации и т.д.), а есть реальная структура – где люди находятся, чем занимаются. Когда вы приходите в дилерский центр, вы их воспринимаете, как единое целое, а на самом деле, там сидит несколько юридических лиц, которые между собой должны общаться. И чтобы этим как-то управлять, мы приняли решение, что раз у нас база отдельная, мы же можем создать какую-то собственную структуру, назвать «Дилерский центр», вообще не привязываться никак ни к юридическим лицам – ни к чему.

• Поскольку мы не используем стандартное поддержание сеанса 1С, а общаемся протоколами (HTTP, JSON и т.д.), то базу можно обновлять в любое время, даже с реструктуризацией. Максимальная проблема, которую вы получите – люди, которые в момент обновления отправляли запрос, получат плохой ответ. Все остальные, в принципе, даже не заметят, что произошло какое-то обновление.

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

Но у такого подхода есть и узкие места:

• Самое слабое узкое место – это то, что все звонки и вся CRM-деятельность компании по клиентам теперь сведена в одно место. База падает – компания не может работать.

• Нам пришлось учиться работать с общей НСИ. Эта проблема связана с тем, что данные клиента теперь присутствуют не только конкретно в той базе, где вы заполняли карточку, но и вся группа компаний может зайти туда и что-то поправить. Иногда люди даже сознательно портят данные. Внутри бизнес высококонкурентный – сами понимаете, машины стоят достаточно дорого, клиентов приходит не очень много, а сотрудников нужно кормить. И вот они между собой борются, какие-то ухищрения предпринимают, и нам с этим приходится считаться.

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

• Также мы очень переживали, когда поняли, что не сможем пользоваться СКД в том виде, в котором привыкли. Согласитесь, что это удобно – написал запрос, как-то оформил его, отправил на клиент, базу обновил. А потом зашел, сохранил новый вариант. Причем, ты имеешь примерно те же самые возможности, что и в конфигураторе – группировки поменять, пользовательские поля добавить и т.д. Когда мы отказались от клиентской части 1С, соответственно, эти возможности тоже ушли

• Разработка такой системы очень трудоемкий процесс. Раньше, если вам нужно было получить данные, например, ИНН контрагента – вам достаточно было написать запрос вида Контрагент.ИНН. А сейчас вам нужно данные упаковать, отправить на сервер, распаковать, выполнить запрос, а потом все это отмотать в обратном порядке. И здесь нам приходится очень хорошо думать, какие данные мы будем передавать. Требования к архитектуре вырастают в разы.

Какие возможности нам дает такой подход?

• Всё общение между сервером и клиентом строится в связке HTTP-JSON, а значит выбор платформы для клиентской части уже не стоит. Один раз реализовав все методы, мы можем их передать на сайт, в мобильное приложение. Никаких дополнительных работ не требуется.

• Также за счет того, что мы используем такой протокол, в качестве источников информации мы можем уже использовать любые базы – сейчас, все умеют общаться по HTTP и JSON. Уже не осталось разработок, где эти возможности не реализованы.

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

Угрозы:

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

• И был неизвестен предел возможностей 1С – сколько 1С может выдержать в таком режиме? На данный момент нам тоже достоверно не известно, сколько она выдержит, но некоторыми данными я с вами поделюсь.

На данный момент в течение суток наша база обрабатывает примерно 450 тысяч запросов. На слайде представлен график распределения нагрузки. При этом где-то 200 тысяч – это нагрузка, которую создают пользователи, кликая по форме, совершая какие-то действия. А все остальное – это нагрузка по обмену данными – это телефония, создание документов, первички, еще что-то.

Сейчас в нашей базе 600 пользователей, из них одновременно работают примерно 320 человек. Соответственно, проведя небольшие математически изыскания, мы получим, что один пользователь в среднем создает 650-700 запросов в сутки. Это, согласитесь, очень мало.

Сам по себе блок CRM небольшой. В основном, он ориентирован на то, что люди звонят. Сколько звонков человек может выполнить в сутки? Рядовой менеджер, наверное, 50. Специалист Call-центра – 100. В целом нагрузка оказалась не такой большой, как мы предполагали.

Что по железу.

На слайде представлена наша архитектура – мы используем два выделенных сервера:

• У сервера 1С в кластере 8 ядер, 24 Гб. На верхнем графике представлены показатели всего сервера целиком – не только rphost от 1С, но и самой операционной системы Windows и IIS. При этом потребление оперативной памяти редко бывает выше 40% – обычно нам хватает 7Гб оперативной памяти на все.

• То же самое происходит в СУБД. В качестве СУБД мы используем PostgreSQL на Linux. Здесь уже выделено больше ядер и больше оперативной памяти, но при этом СУБД потребляет всего 5% выделенной мощности, а по оперативной памяти мы также получаем те же 7-8Гб.

То есть нагрузка по тому, как мы вынесли целую подсистему, оказалась не такой большой.Мы посчитали эту практику успешной – можно и дальше брать какие-то блоки, выносить их в отдельные базы и получать какой-то результат.

Почему 1C удобно использовать в качестве back-end

От себя хотел бы отметить, почему мне понравилось работать с 1С в качестве Backend. Что мы имеем и почему это можно использовать?

• Во-первых, язык 1С гораздо проще, чем любой другой язык. Если вы возьметесь изучать тот же JavaScript, то просто на понимании замыканий там потребуется какое-то время, потому что это штука достаточно необычная. А тут у вас тот же самый сотрудник, который поддерживает Бухгалтерию, может буквально за пару часов научиться и написать сервис, позволяющий достаточно быстро обменяться пакетами.

• Также вы сразу имеете готовые интерфейсы доступа к СУБД. Вам не нужно реализовывать так называемые «админки», у вас все уже сразу готово. Вот вам, пожалуйста, списки, регистры – хотите, добавляйте данные, хотите, редактируйте. Это затруднений не вызывает.

• Также 1С относительно недавно, последние года 4 стали поддерживать полностью HTTP и JSON – не только POST-запросы, но и весь цикл RESTful API.

• У 1С есть разнообразные способы доступа к данным – вы имеете готовые мобильные клиенты, интерфейсы oData. Не факт, что они вам потребуются, но они есть – другие языки и фреймворки таких возможностей не дают.

• Хочется отметить кроссплатформенность разработки на 1С. Пока мы делали эту базу, мы успешно мигрировали с Windows и MS SQL на Linux+PostgreSQL. Там есть пара нюансов, но в целом процесс перехода не вызвал затруднений.

• И также встроенный СКД – это очень мощный инструмент по анализу данных, причем довольно простой. Его просто освоить в отличие от, например, Power BI. Это его плюс.

Событийный обмен данными

Решение было принято. Нам потребовались данные. Для CRM требуется достаточно много данных, чтобы понимать, что происходит с клиентом.

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

Поскольку мы об этом договорились, нам удалось существенно сократить количество метаданных, которые нужно перекачивать в CRM. Например, чтобы понять, какие ремонты были осуществлены клиенту, вам не требуется перекачивать весь справочник номенклатуры. Достаточно какое-то описание работ, может быть, какой-то артикул для верификации и т.д. То есть, количество метаданных, которое уходит, и объемы данных, стали меньше.

Дальше мы физически разделили два события – событие создания и событие обновления информации:

• при событии создания мы даем полный пакет со всеми идентификаторами;

• а в дальнейшем при событии обновления нам достаточно передавать только полученный UUID и какой-то набор данных – чтобы сообщить системе о том, что у контрагента поменялось наименование, достаточно передать всего одно поле в формате JSON, где будет просто содержаться имя – это достаточно быстро и легко.

Немного о технологии.

• При записи объекта мы проверяем, изменились ли те реквизиты, которые нам интересны. Если они изменились, мы их записываем в регистр сведений – это будет пакет, уже готовый к отправке. И сохраняем.

• Дальше – раз в какой-то период (у нас это раз в 30 секунд) стартует регламентное задание, которое отправляет не больше 200 объектов. Оно отправляет все на сервер.

• Из-за того, что при обновлении и получении данных мы передаем только идентификаторы, но не передаем ту информацию, по которой можно распознать контрагента, то получаем проблему – если контрагент не ушел (в нем не хватает данных, интересных для CRM), то по нему не уйдет ни один документ, потому что система не сможет распознать ту ссылку, которую мы передаем. По сути, получается остановка обмена. С одной стороны, это плохо. Но, с другой стороны, сотрудники стали оперативно реагировать, исправлять данные. Как пример, зачем нам контрагент, у которого нет номера телефона? Для учетной системы это – ссылка, по ней можно вести документацию, что-то продавать, но что с ней делать в CRM – мы ему позвонить не сможем, отправить email не сможем. Мы его, банально, найти не сможем. Поэтому используем такой подход. Мы отправляем данные на сервер, сервер проверяет – все ли его устраивает. Если его хоть что-то не устраивает, он отвергает данные – идите, разбирайтесь, выдавайте мне только чистые данные.

На что способен такой обмен? На графике представлена нагрузка по количеству объектов в сутки за месяц по нашим базам. То есть одна база одного бренда генерирует нагрузку в виде 10 тысяч объектов.

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

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

• Если в стандартной разработке мы пишем данные – открываем транзакцию, начинаем писать объекты, а потом что-то в конце проверяем и в зависимости от результата откатываем, то здесь уже такое не получится, потому что данные отправили в другую систему, транзакция разорвана. Безусловно, можно на клиенте(для CRM системы) открывать транзакцию, отправлять данные на сервер, и, если пришел плохой ответ, транзакцию откатывать. Но здесь вы рискуете тем, что из-за технических неполадок в виде прослойки веб-сервера, ваша транзакция просто растянется на какое-то неограниченное количество времени. И опять-таки, данные на сервере вы уже никак не откатите. Поэтому требуется более аккуратно продумывать всю логику работы, стараться избегать моментов, когда одновременно нужно записывать два набора данных – в одну и в другую систему.

• Какой еще момент мы попробовали – мы стали использовать переиспользование сеансов. В 16 или 17 году 1С добавила возможность переиспользовать сеансы. Это когда вы подключаетесь по HTTP-сервису и попадаете в уже готовый сеанс – они не затухают в момент отключения, а продолжают работать. Мы включили переиспользование сеансов под одним единственным пользователем. И решили, что всю логику управления мы возьмем на себя, как программисты. Мы всем будем управлять сами. Какой плюс получили – все наши 320 пользователей живут всего в 10 сеансах. То есть одновременно на сервере крутится не больше 10 сеансов. Обычно 5 или 6. Это – существенный плюс. Но получился огромный минус. Так как сеанс выбирается произвольным образом, то человек, который подключается, может оказаться в любом месте. Мы заранее не можем сказать, в каком сеансе он оказался. Соответственно, нам требуется его как-то идентифицировать. Тут мы решили использовать стандартную технологию токенов. Авторизуешься – получаешь токен, тебе предоставляютсяданные твоего окружения, записываются в регистр сведений. Потом, когда ты уже повторно подключаешься, ты передаешь свой токен, мы достаем это окружение и с ним уже работаем. Получилось довольно удобно.

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

• Следующее, что выстрелило – это модуль с повторным использованием. Так как человек каждый раз попадает в разные сеансы, соответственно, каждый вызов повторного использования идет заново. И здесь нужно учитывать, что повторное использование можно использовать либо в том случае, когда контекст не зависит от конкретного пользователя – какие-то глобальные вычисления по системе, еще что-то. Либо же когда количество обращений, деленное на количество сеансов, которое существует в базе, будет каким-то существенным. С токенами получается вообще отлично.

• Следующая задача, которую мы решали – мы хотели, чтобы токен не жил бесконечно, а примерно через час после последнего обращения прекращал свое действие, как во всех остальных системах. Самый простой способ – при любом обращении, по сути, обновлять данные в регистре сведений. Но здесь мы получаем проблему – каждое обращение к базе приводит к записи в регистре сведений. А от этого хотелось бы избавиться. И тут я хочу с вами поделиться небольшой хитростью, как из модулей повторного использования делать некие таймеры. Можно одним из параметров передавать некое число, которое завязано на время. В данном случае, мы беру текущую дату и делим на пять. Получается, что модуль повторного использования у меня вызывается только каждые пять секунд, потому что второй параметр меняется. Таким образом, я могу не пять раз записать «Изменить данные» токена, а всего лишь один, когда у меня сработал этот таймер. В нашем случае, мы записываем раз в 10 минут. Это не так критично.

• Что еще стоит отметить? Так как мы используем одного-единственного пользователя, то у нас появляется проблема – ролевая модель не работает, роли выдавать некому, пользователь всегда один и тот же. Здесь обход такой – просто программно управлять доступом. Это возможно, это не очень сложно.

Сложности программирования без «ссылок»

Следующее, с чем пришлось столкнуться – когда мы данные передали, нам нужно ими дальше обмениваться, а для этого надо как-то передавать ссылки.

Самый простой вариант – передавать поле с GUID и наименованием.

После реализации где-то сотни таких пакетов нам захотелось большей универсализации. Поэтому мы предлагаем использовать ссылку ровно так же, как ее использует 1С – хранить имя таблицы, GUID, наименование и, возможно, еще какие-то данные. Поэтому все объекты в пакетах обмена у нас представлены именно ссылками. В лучшем случае, это будет GUID глобальной базы, в худшем случае – UUID локальной базы

Также выяснился интересный момент – пользователю нельзя показать ссылку. Поскольку ссылка – это GUID, пользователь не поймет, что это, ему нужно получить наименование. И получение этих наименований стало достаточно большой проблемой.

Когда мы работаем в 1С, мы, наверное, вообще никогда не задумываемся, как 1С получает эти ссылки. Кто-нибудь использует в запросе конструкции ПРЕДСТАВЛЕНИЕ() или ПРЕДСТАВЛЕНИЕССЫЛКИ()? Согласитесь, вы это делаете не часто. Но если вы посмотрите верхний пример, где просто выполняется какая-то выборка РезультатЗапроса.Выгрузить(), то в момент, когда вы делаете ТЧ.Загрузить(), 1С сама формирует запрос, в котором получает все эти ссылки, которые она не распознала.

В случае же с нашей системой, 1С такого не делает – она нам не помогает, поэтому нам приходится получать представление дополнительно. Ниже приведен пример, когда по каждой ссылке генерируется микрозапрос на получение представления. Таким образом, можно создавать хорошую нагрузку именно по количеству обращений к базе данных, просто не учитывая получение этих ссылок.

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

Клиент для нашей системы на 1С

Первый клиент, который мы реализовывали – это был клиент непосредственно на 1С. Мы организовывали общение между двумя 1С-ными системами и строили все свои интерфейсы в нашу родную учетную систему.

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

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

• Также проблемой стала необходимость хранить ссылки на объекты чужой системы. Ссылка у нас представлена как Ссылка + Наименование. Самый простой способ – засунуть это все в реквизиты (Автомобиль и АвтомобильГУИ). Но таких реквизитов на форме будет сотня, потому что на каждый классический реквизит 1С вы получаете их дублирование – это не очень хорошо. Простым способом оказалось то, что мы храним в реквизите GUID, а в список выбора поля добавляем представление – 1С сама его отображает. При этом получается все красиво. Также те данные, которые необязательно должны быть интерактивными, их можно хранить просто в качестве декорации.

• Опять-таки, я про обновления я уже говорил. Это довольно удобно. Мы всю свою подсистему выполнили в качестве внешней обработки(для учетной системы). Если нам надо полностью обновить, клиент, мы просто переподключаем внешнюю обработку, Сотрудник в нее перезаходит – без всяких перезагрузок– пожалуйста, вот вам новая система с новой функциональностью. В течение рабочего дня мы можем выпускать эти релизы достаточно быстро – это удобно.

Визуализация данных

Также хотел бы поговорить про визуализацию данных.

Так как мы стали использовать HTTP-протокол, и 1С поддерживает такое поле, как ПолеHTMLДокумента, то – что можно делать? Можно рисовать странички, в 1С передавать просто ссылку на эти странички, 1С их сама отрисует.

Например, мы добавили блок новостей, где сотрудники могут сами вносить данные.

При этом в 1С хранится просто ссылка – http://ДоменСайта/GUIDНовостнойЛенты.

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

При этом 1С достаточно хорошо справляется с визуализацией, сюда можно добавить интерактивность – открытие, разворачивание, движки работают. И это все на платформе 8.3.13, до переработки движка поля HTML и перехода на свой собственный внутренний браузер на основе webkit.

В поле HTML документа можно нарисовать достаточно интерактивные схемы – здесь представлена визуализация timeline клиента – когда он приходил, какие события с ним связаны.

Отдельно хочется затронуть возможность прослушивания данных. В CRM все любят слушать звонки – правильно ли все сказали клиенту. Так вот, можно избежать подхода, когда мы получаем файлик и открываем его в условном Windows Media Player. С помощью HTML-поля можно прямо в 1С встроить полноценный проигрыватель.

В случае с Windows – это Windows Media Player, и на Linux тоже есть возможность проигрывания в браузере с помощью тега audio – все достаточно просто.

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

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

Хочется отметить календарь планирования – то, что реализовано в 1С.

Оказалось, довольно удобная штука для работы. Чаще всего мы работаем со списками – огромные большие данные, которые идут линейно. Реализовать их довольно сложно, потому что момента окончания списка прокрутки 1С не показывает.

И в лучшем случае, это будут какие-нибудь кнопки, где нужно нажимать Далее-Далее-Далее. А мы все свои события разместили в календаре.

Любое взаимодействие сотрудника с клиентом требует какого-то времени – хотя бы 5-10 минут. Отматываете на предыдущий день, смотрите, какая действительно у вас была активность. И такая визуализация гораздо удобнее, чем списки – даже разукрашенные. Буквально просмотреть, какое-то мнение составить о том, как часто к нам приходили клиенты, можно просто промотав эти календари. Большая красная куча неразобранная – сотрудник не работает, у него много задач. Это удобно.

Реализация отчетов в системе без СКД

И последнее, о чем я хотел бы рассказать, – это отчеты. На всех проектах, когда доходит до отчетов, начинаются проблемы, потому что оказывается, что не хватает каких-то данных, что-то не так хранится, и т.д.

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

Соответственно, мы написали процедуру, которая передает табличный документ целиком между сервером и клиентом в 1С. А параметры расшифровки мы обрабатываем автоматически – превращаем их в наши внутренние ссылки и передаем на сторону клиента.

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

Сначала бизнес из-за этого переживал. А потом, когда мы стали строить замеры и смотреть, какие отчеты строятся, насколько они уникальны – оказалось, что отчеты, в лучшем случае, смотрят в конце месяца, когда надо посчитать зарплату и KPI, а в остальное время они никому не нужны. И огромная вариативность, о которой все говорят:”Что мы хотим перегруппировывать, как-то менять данные” – не нужна, никто этим не занимается. Вполне достаточно один раз посидеть, придумать какой-то универсальный вариант и его будет более чем достаточно.

Я постарался осветить те шаги, которые мы проходили, с какими проблемами мы столкнулись. Надеюсь, вам было интересно.

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Kazan.