Стенограмма вебинара «Шенген для серверов: грамотная миграция в облако»

Вебинар состоялся 27 марта 2013 года.
Стенограмму подготовил Сергей Проуторов

Полный отчет о вебинаре находится здесь.

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

«Жизнь после жизни» есть и эта жизнь в облаке вполне хорошая. Как осуществляются первые шаги миграции? Каковы сценарии внедрения, перехода и что в каком сценарии бывает? Начнем именно с этого.

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

В этой ячейке, как правило, создается по умолчанию один либо два сервера в зависимости от того, что попросил клиент, и устанавливается из шаблона какая-нибудь ОС в зависимости от задач клиента. Если клиенту нужно протестировать работу веб-сервера, из шаблона разворачивается идеальный сферический веб-сервер. Если клиенту интересно пощупать, как будет происходить работа в терминальной среде, то из шаблона создается терминальный сервер под управлением MS Windows.

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

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

По истечении семи дней мы снова связываемся с клиентом, интересуемся, все ли было протестировано, и можно ли уничтожать тестовую среду, которая была для него создана. Если у клиента сохранились какие-то данные, то ему нужно успеть их извлечь до удаления нами. После того, как среда была протестирована, клиент может сказать: «Давайте все оставим как есть», и проводить дальнейшую работу с этой средой, которая у нас получилась. Мы говорим: «ОК», тестовую среду оставляем и начинаем обмен разного рода документами — присылаем для ознакомления шаблон договора, получаем от клиента его юридические реквизиты для заключения договора и т.п. Дальнейшие движения по миграции осуществляются по нескольким сценариям. Вот два наиболее характерных.

Либо клиент сразу начинает использовать те ресурсы, которые он тестировал — это, как правило, либо небольшие компании с простой IT-инфраструктурой, либо большая компания, но которая не стремится выносить в облако сразу много всего. То есть, они заказали какой-то один сервис, хотят на нем какое-то время поработать, а потом принимать решение, стоит ли переносить остальные сервисы в облако и в каком порядке.

Сценарий второй — это тот путь, по которому идут более крупные компании. Он подразумевает более сложную миграцию достаточно разветвленной IT-инфраструктуры, которую за 1-2 дня не перенесешь. И в этом случае мы составляем дорожную карту миграции. У нас есть определенного рода типовые шаблоны миграции, но иногда бывает необходимо с IT-специалистами компании-заказчика совместно подкорректировать процесс, чтобы миграция больше соответствовала их требованиям и ожиданиям.

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

Если компании не нужен сложный сценарий выполнения миграции, тот здесь все просто — с предварительным ли тестированием, либо без него. Клиент сделал заказ, мы выделили ресурсы и компания начинает пользоваться ими. Ресурсы мы выделяем до заключения договора и оплаты — на это есть потом некоторое время. Компания захотела получить услугу — она ее получила. Мы развернули ту инфраструктуру, которая компании необходима, а заключение договора и оплата производятся уже в процессе работы. Мы прекрасно понимаем, что облачная услуга должна быть быстрой.

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

Что касается более сложного, трудоемкого и разветвленного процесса миграции, то здесь есть несколько этапов внедрения — очень важных и обязательных. Их выполнение позволит миграции пройти быстрее и легче, а ее последствия будут благоприятны для самих пользователей. Как говорится: «Как миграция пройдет, таковы будут и результаты».

Вопрос: Среднее предприятие использует Access и Excel. Причем, имеют место подключенные таблицы и хранилища данных, то есть, имеют значение адреса файлов в сети. Возможно ли сохранение сетевых адресов или придется переконфигурировать источники данных?

Спасибо за вопрос. Оставить все адреса действующими можно очень легко — следующим образом. Пока идет миграция, мы создаем VPN-соединение между облачной инфраструктурой клиента и его текущей инфраструктурой, существующей на данный момент. Если у него есть адреса, к которым обращаются те или иные программные продукты — IP, локальные домены — то они работают так же, потому что облачную и текущую инфраструктуры объединяет VPN-туннель, который протягивается между облаком и инфраструктурой клиента.

Ключевые этапы внедрения облака таковы. Мы начинаем с постановки задачи — нам нужно узнать у клиента, какие задачи он собирается решать с помощью нашего облака, что именно он хочет перенести и запустить. И самое главное, чего хочет клиент в результате этого переезда добиться, какова его цель. Целей может быть много: обеспечение мобильности, информационной безопасности, быстрого доступа к ресурсам, экономические выгоды — целей может быть много. И нам важно понять не только «задачу создания сервера под Windows-2008 с такой-то конфигурацией и программным обеспечением» (мы это, конечно, сделаем с удовольствием). Но для нас важно также понять, какие цели тем самым преследуются, потому что зачастую, узнав об этих целях, мы можем предложить те решения, которые у нас уже являются более накатанными.

На слайде показаны основные этапы внедрения: анализ IT-среды, выбор сегмента для миграции, формирование технических требований и их утверждение, выбор уровня сервиса, согласование условий, подписание договора, акцептирование SLA, правил и тарифов, внесение первичного платежа.

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

Следующий этап — выбор решения. Мы предлагаем заказчику несколько вариантов: «Вот конфигурация, которую вы запросили. У нее есть ряд преимуществ. Но мы предлагаем рассмотреть другую конфигурацию, имеющую дополнительные преимущества. Например, лучшее соединение с текущими источниками данных». То есть, выбор решения в зависимости от того, как мы понимаем задачу и какие ресурсы можем предложить. И когда клиент одобряет какой-либо ваариант, мы закрепляем отношения, обменявшись документами. Мы высылаем подготовленный договор о предоставлении услуги, а также: SLA-соглашение об уровне сервиса, в котором прописаны цифровые показатели доступности и скорости; общее правило предоставления и использования услуг; действующие тарифы. Договор подписывается и после этого мы выделяем ресурсы в нужном объеме.

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

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

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

После этого заказчик еще раз проводит первичное тестирование системы, если оно не производилось, а также — определенную отладку системы. Это означает, что компания-заказчик разворачивает на выделенных нами ресурсах то ПО, которое будет там работать, и отлаживает его работу. В случае необходимости заказчик осуществляет интеграцию «облачного» ПО со своим программным обеспечением и с теми источниками данных, которые работают у него сейчас. Это тоже может занять какое-то время. Отладка системы — это важный процесс перед тем, как начинать миграцию. Если компания-заказчик не убедится, что все полностью готово и систему можно использовать уже сейчас, то миграцию начинать не стоит.

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

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

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

Вопрос: Если ночь может оказаться больше, чем одна ночь, то может ли это быть ночь с пятницы на понедельник?

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

Что происходит дальше? А дальше происходит «жизнь после жизни»: вы успешно мигрировали, попали в облако и дальше вам необходимо всем этим управлять. Есть два органа взаимодействия между нами как компанией-провайдером и компанией-клиентом. Один из них отвечает за управление облачной инфраструктурой — изменение конфигурации, получение статистических данных, получение данных от службы мониторинга, грубо говоря, это управление услугой. Для этого есть подорганы — это портал управления, который многие из присутствующих уже видели. Кто не видел — пожалуйста, заполните форму на сайте и мы будем рады предоставить вам тестовую инфраструктуру на семь дней. Кроме того, есть служба технической поддержки, оперативно и четко отвечающая на запросы, особенно если они связаны с изменениями, которые необходимо срочно произвести. Грубо говоря, если не хочется работать с порталом управления, можно написать с авторизованного адреса в службу технической поддержки и эти изменения мы произведем самостоятельно.

И, конечно же, есть такая штука как API — это простой интерфейс, с помощью которого ваши сервера могут самостоятельно управлять своей конфигурацией и конфигурацией других серверов. Что я имею в виду? Предположим, у вас есть сервер, который выполняет функции веб-сервера. И вдруг на вас пошел очень большой поток трафика, притом это не DDoS-атака, а трафик полезный. Например, ссылку на ваш сайт разместили где-нибудь на Slashdot’е. Тут же пошел трафик и хорошо, если системный администратор успел это заметить и изменить конфигурацию виртуальной машины. Но если он в это время спит — что делать? Для таких случаев предусмотрено API, с помощью которого сервер может управлять своей конфигурацией самостоятельно. С помощью простейших скриптов, увидев, что у сервера заканчивается, например, оперативная память и он начинает слишком часто лезть в swap, или нагрузка на сервер возросла настолько, что все ядра сервера постоянно загружены, он может отдать команду нашей системе управления в автоматическом режиме на изменение конфигурации. То есть, он может выбрать новую конфигурацию, в которой у него будет больше ядер или оперативной памяти — взять себе больше ресурсов. И когда нагрузка снова спадет, в зависимости от конфигурации скрипта, он сможет вернуть все обратно на предыдущую конфигурацию.

При этом системный администратор или IT-специалисты компании могут ничего этого не заметить. Так или иначе с помощью API ваша инфраструктура может управлять своей конфигурацией самостоятельно. Приведу классический пример. Когда не было облаков и виртуализации, это было очень важно. Например, есть несколько серверов и один из них является очень важным. Если он по какой-то причине завис (например, на нем работает не очень стабильная версия ОС), то его надо перезагрузить. А как это сделать, если для этого нужно куда-то бежать, потому что он стоит где-то в каком-то подвале. Это так называемый «привет из прошлого» — то, как делалось все лет 10 назад.

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

Техническая поддержка осуществляется тремя методами. Во-первых, есть тикет-система, реквизиты доступа к которой мы высылаем вместе с реквизитами доступа к порталу управления. В тикет-системе можно создавать заявки, отслеживать ход их выполнения, можно общаться со специалистами нашей компании и делать это через простой и удобный веб-интерфейс. Для любителей oldschool есть электронная почта, тоже удобная. Отправка письма инициирует создание тикета. Поэтому с одной заявкой можно работать и через тикеты, и через почту, если не удалять из темы письма номер заявки. И, конечно же, есть телефон — для срочных вопросов и задач. Однако хочу сказать о следующем: для обеспечения определенных гарантий для клиента — что для него не будет никаких сюрпризов, заявки на изменение конфигурации должны быть продублированы по электронной почте и в тикет-системе. Телефон — такая штука: кто-то кого-то неправильно понял, сделал не так и это может привести к нежелательным для клиента последствиям. По телефону оперативный вопрос решить хорошо, но запрос на изменение должен сопровождаться электронным сообщением.

Мы поговорили немного о миграции в облако и о том, что нас ждет в «жизни после жизни». Буду рад ответить на вопросы.

Вопрос: Вопрос по тесту. Заказ автоматизирован и не требует вашего участия? И каково примерное время обработки заказа?

Заказ полуавтоматизирован. Но есть один интересный момент. Он требует нашего участия с той точки зрения, что нам необходимо связаться с клиентом и уяснить для себя, какую конфигурацию будет лучше ему предоставить. Помните, мы говорили в самом начале, что нам нужно понять задачи клиента? Не просто предоставить какую-то инфраструктуру: «На, играйся». Нам нужно понять, какие нужно установить шаблоны, какие серверы должны быть созданы в тестовой инфраструктуре, какая именно у них должна быть конфигурация — после того, как мы это выясняем, мы предоставляем тест в течение одного рабочего дня. Можно и самостоятельно выбрать базовую конфигурацию. Если речь идет о простом продукте, например, TuchaHost, то можно просто написать в заявке: «Выделите TuchaHost». И мы тут же это сделаем без лишних вопросов. То же относится и к другим простым продуктам.

Вопрос: Как обстоит дело с миграцией компаний, которые не располагаются в Киеве?

Есть два пути. Путь первый. Для миграции совершенно не обязательно присутствие наших инженеров на территории заказчика. Для того, чтобы перенести все данные в облако, достаточно простого TeamViewer’а. Пользователь вечером оставил его включенным, а утром его компьютер уже работает в роли тонкого клиента. Но вообще-то, по правде говоря, чтобы провести миграцию максимально плавно, мы все-таки предпочитаем приехать в офис к заказчику чтобы имет возможность вживую пообщаться с пользователями — спросить у них, как протекает работа, какие программы они запускают, какие данные и где лежат, как они привыкли работать и т.п. Это не занимает много времени у пользователей, но дает нам возможность посмотреть на систему глазами пользователя, а не IT-специалиста, потому что у них немного «разные глаза», конечно. И мы стараемся смотреть на систему именно глазами пользователя, чтобы потом ему в этой среде жилось хорошо. Но есть еще один очень важный момент. Даже если клиент находится не в Киеве, а проект не настолько большой и сложный, чтобы заказывать командировку наших специалистов на место, то в этом случае можно прибегнуть к помощи наших партнеров. Мы сейчас сконцентрировались на том, чтобы сделать нашу партнерскую сеть еще более распределенной географически и то, чего мы добиваемся — сделать так, чтобы в каждом из областных центров Украины у нас появилось хотя-бы по одному партнёру. И с ближайшими странами СНГ мы тоже хотим начать взаимодействовать. И для этого уже сделаны первые шаги. Поэтому если через год вы зададите такой же вопрос, то я отвечу: «Да, конечно, наши партнеры находятся в вашем городе — вот название компании и номер телефона, и вообще они перезвонят вам сами».

Вопрос: Есть ли какие-то ограничения в тестовом доступе — частота ядер, каналы связи?

Как правило на тестовый доступ по умолчанию дается не более 4-х ядер и не более 100 Мбит канала. Оперативная память ограничивается 16 гигами, в которых можно разместить 2,3 или 4 сервера. Но в том случае если в результате анализа мы понимаем, что задача клиента требует выделения бόльших ресурсов, то разумеется, мы выделим столько ресурсов, сколько необходимо.

Вопрос: Ваш саппорт работает только по обращению? Или во время процесса миграции и некотрое время после окончания этого процесса — самостоятельно мониторит процесс и вмешивается в случае необходимости? Помогает ли техподдержка после миграции?

В данном случае эта помощь является больше консультационной. После того, как мы передали ключ от «квартиры» и заказчик переместил в нее всю «мебель», мы уже, согласитесь, не имеем права приходить в нее как в свою и что-то там делать. Но если заказчик скажет: «А как мне сделать, чтобы этот «шкаф» стоял не здесь, а там», то мы, конечно, же подскажем. Или попросит: «Прорубите мне здесь «окно» и подведите «трубу» вот туда». И это мы сделаем. Но это касается внешних вещей, это ведь не содержимое «шкафов» заказчика. У нас есть еще дополнительный пакет услуг, называемый TuchaExpert, который предусматривает, что мы отвечаем не только за работу виртуальных серверов, бэкап данных, работу сети и так далее. Но еще и за то, как работает сама ОС внутри этих серверов, и за прикладное ПО, библиотеки и т.п. То есть, консультируем админов заказчика где и какое обновление лучше поставить, как лучше настроить Firewall и т.п. При этом мы не вторгаемся в то, что происходит внутри, и не берем на себя роль администраторов этой системы, но предоставляем расширенные консультации и в некоторых случаях можем зайти и посмотреть, в чем проблема. Например, нам говорят: «У нас не стартует что-то». А мы заходим, смотрим: «Не стартует, потому что нужно флажок поставить». Такой же флажок надо было бы поставить и не в облаке, а на обычном сервере, но ребята об этом забыли. Они позвонили нам и получили консультацию, хотя она и не касается непосредственно облачных технологий. Их вопрос был связан с функционированием ОС, библиотек, прикладного ПО — всего того, что было бы на обычных «железных» серверах.

Вопрос: Правильно ли я понял, что можно стать вашим партнером? И что для этого нужно?

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

Вопрос: Есть ли возможность быстрее получить готовую конфигурацию даже если мы крупная компания? У вас есть готовые продукты? Как начать работать с ними и насколько это быстро?

Как уже говорилось, есть линейка продуктов, которые являются решениями, «заточенными» под определенного рода задачи. Стоит упомянуть два самых интересных продукта — TuchaBox и TuchaHome. TuchaBox — это среда для виртуализации рабочих столов. Заказчику достаточно выбрать в калькуляторе количество рабочих столов, которые он хочет виртуализировать, калькулятор автоматически считает конфигурацию и выдает цифры стоимости. Такая конфигурация развертывается буквально за 5 минут. Я не шучу и на одном из вебинаров я показывал, как это происходит — развертывание терминального сервера из шаблона. Это действительно занимает не более 5 минут после чего терминальный сервер полностью готов к работе. Администратор заходит, заводит учетные записи пользователей и можно переносить данные. Все легко и просто. И еще один продукт — TuchaHost который тоже очень быстро разворачивается, представляя собой готовое интегрированное решение, в которое входит веб-сервер для хостинга веб-сайтов — своих или клиентских, и хостинг почтовых доменов с настроенным антивирусом, защитой от спама, фильтрацией, правилами роутинга и почты и так далее. Причем, всем этим управлять очень легко через веб-интерфейс.

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