пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Интеграция CRM – системы и корпоративной системы связи (телефонии) позволяет значительно улучшить параметры обслуживания ваших клиентов. Диапазон возможностей очень широк: прослушивание звонков в интерфейсе CRM, всплывающая карточка при входящем звонке от клиента, умная маршрутизация, которая позволяет адресовать звонок на ответственного менеджера, который закреплен за клиентом в CRM, исходящие звонки «по щелчку» мышки на номер клиента, или как его часто называют click – to – call и история звонков по каждому конкретному клиенту – все это доступно для бизнеса, который решил объединить систему управления взаимоотношениями с клиентом и офисную телефонию.
.
Интересно? Тогда мы рады поделиться обзором возможностей интеграции 1С CRM и IP – АТС Asterisk.
Всплывающая карточка клиента
При входящем звонке от клиента, в интерфейсе 1С, при совпадении номера звонящего появляется карточка контрагента. Параллельно, создается документ «событие» типа «телефонный звонок». Как видно на скриншоте, у контрагента настроен персональный менеджер. При включенной функции «Умная маршрутизация», звонок приходит прямо на указанного менеджера, минуя настроенные в Asterisk правила маршрутизации. Это означает, что если в вашей организации настроено интерактивное голосовое меню (IVR), или простое голосовое приветствие, то клиенту, у которого настроен персональный менеджер не придется слушать его – звонок сразу отправится на внутренний номер ответственного менеджера.
В другом случае, если клиент звонит вам впервые, то оператору будет предложено создать нового контрагента. Важный момент, что когда вы нажмете на кнопку «Добавить контрагента», в появившейся карточке будет автоматически добавлен номер звонящего:
Кстати, мы посчитали: при условии интеграции 1С и телефонии, время обработки входящего звонка уменьшается на 2 минуты – вам просто не нужно идентифицировать клиента, а затем вручную вбивать его пользовательские параметры для поиска карточки – система сразу покажет всю необходимую информацию.
История звонков
История звонков хранится по каждому контрагенту отдельно, а так же, есть унифицированный интерфейс, в котором можно посмотреть статистику звонков по всем операторам. В интерфейсе будут доступны как входящие, так и исходящие звонки. Помимо этого, вы можете прослушать аудио запись разговора.
Важно:Сами аудио файлы хранятся на сервере IP – АТС Asterisk. По факту, на копке прослушать, будут расположены ссылки на аудио – записи в папке /var/spool/asterisk/monitor
Итак, переходим во вкладку «История звонков», как показано ниже:
Откроется список звонков. Значком слева, обозначено направление звонка – входящее, или исходящее. Помимо этого, в таблице мы видим дату и время начала и окончания вызова, его продолжительность в секундах, направление, ссылка на аудио – запись, ответственного пользователя, которые обработал вызов, и контрагента, с которым этот вызов связан. Вся информация представлена в наглядном и интуитивно понятном исполнении.
Звонки из 1С
Мы снова все посчитали, и можем сказать, что набор номер из 1С экономит от 15 секунд на исходящем звонке. Цепочка получается следующая: оператора нажимает на карточке контрагента на кнопку «Позвонить»
В открывшемся окне видим все контакты по указанному контрагенту. Чтобы позвонить по номеру, достаточно левой кнопкой мыши нажать на телефон:
Как только мы нажмем на номер телефона контрагента, зазвонит наш настольный телефон. Как только мы поднимаем трубку, происходит соединение с контрагентом.
Умная маршрутизация
Настройка умной маршрутизации происходит на уровне IP – АТС Asterisk. Для корректной работы функционала переключения вызова на менеджера, достаточно просто поставить галочку в настройках входящего маршрута.
Операционные системы Unix традиционно используют такие понятия, как стандартный ввод, вывод и вывод ошибки. Чаще всего ввод — это клавиатура, а вывод это на кран. Но конечно же мы можем выводить исполнение какой-то команды в файл и передавать другой команде, потому что работая в Linux, создается такая последовательность из команд, т.е результат предыдущей мы отправляем следующей и т.д
Целью данной статьи является рассмотреть:
Перенаправление стандартных ввода, вывода и ошибок;
Передача вывода одной команды в качестве аргументов другой;
Получение выходных данных в файл и на стандартный вывод;
Основные понятия:
Stdin (0) – ввод
Stdout(1) – вывод
Stderr (2) – вывод ошибки
> - передать в
>> - дописать в
list.txt. По сути означает выполнить команду, а результат передать в файл. Фал можно посмотреть командой cat list.txt.
И мы можем убедится, что в данном файле находится перечень, всего что находилось в данной папке. Если мы выполним еще раз команду ls > list.txt, то данный файл каждый раз будет перезаписываться. Если же мы хотим, чтобы наш файл не перезаписывался, а дописывался, используем другую стрелочку ls >> list.txt.
И теперь вы можете видеть, что файл стал больше. Т.е. у нас записалось, то что было, а затем еще раз добавилось. Если опять выполнить команду со стрелочками >> , то опять допишется информация в файл. Вот таким образом работают “стрелочки”.
Стандартный вывод ошибок.
Мы можем, например, сказать машине, выведи нам содержимое папки bob, которая не существует ls bob > result.txt, естественно мы получим ошибку которую система вывела на экран. Экран является стандартным выводом ошибок. В нашем случае нет папки bob и нет файла resut.txt. Если мы хотим отправить ошибку в файл, так же как результат выполнения команды, то ls bob 2> result.txt, вспоминаем основные понятия, в которых было указанно, что 2 – это стандартный вывод ошибки.
Следовательно, на экране мы уже не видим ошибки, потому что она отправилась в указанный файл.
Кстати мы можем объединить стандартный вывод команды и стандартный вывод ошибки. Например: ls bob > result.txt 2> error.txt. Выведи содержимое папки bob в файл result.txt, а если возникнет ошибка внеси в файл error.txt.
В таком случае и команда выполнится и что-то будет в файле и если ошибка возникнет, то она будет записана в файл error.txt. Это можно применять на практике, когда мы что-то делаем и предполагаем, что в процессе выполнения возникнут ошибки, то используя данную конструкцию данные ошибки мы все можем отправить в отдельный файл.
Конвейер
Конвейер умеет передавать выходные данные из одной программы, как входные данные для другой. Т.е. выполняется команда, мы получаем результат и передаем эти данные далее на обработку другой программе.
Например, выполнить команду ls и далее мы могли стрелочкой отправлять результаты выполнения команды в файл, т.е. мы меняли только стандартный вывод, а не передавали другой программе. А можем выполнить ls | grep r , т.е. получить содержимое и передать по конвейеру команде сортировки и сказать отсортировать по наличию буквы r, а если перенаправить еще вывод в файл, то cat имя файла , мы сможем увидеть информацию в файле.
Но есть другая команда tee которая позволяет работать немного удобнее. Например: ls | tee output.txt. Те данная команда выводит информацию сразу на экран и в указанный файл. Что достаточно удобно с точки зрения работы с выводами.
И еще одна команда xargs – она построчно работает с выводами. Если у нас есть какая-то команда, которая выдает нам вывод в виде нескольких строк ответа, то мы можем эти строки построчно передавать этой команде, т.е. не одной кашей, а построчно. Например find . –name “*.txt” найти все файлы в текущем каталоге с расширением txt. И если бы мы захотели удалить все эти файлы нам бы пришлось построчно их удалять, но мы можем сказать, чтобы выходные данные были переданы по конвейеру xargs и удалить.
find . –name “*.txt” | xargs rm -f
Как видите после данной конструкции команд файлов не осталось. Т.е. данные построчно передались на команду удаления, которая построчно каждый файл с ключом –f (принудительно) их и удалила.
Обычные так называемые революционные подходы к разработке программного обеспечения противоречат требованиям современных облачных платформ и программных платформ DevOps, в том числе требованиям гибкости, быстроты адаптации и непрерывного развертывания.
Недостаточно просто подготовить чек-лист действий, которые необходимо выполнить во время развертывания рабочей версии. Если вы так делаете, то вы никогда не станете достаточно гибким и, тем более, истинным DevOps-инженером.
1. Сине-зеленое развертывание: что это такое?
Сине-зеленое развертывание – это подход к развертыванию программного обеспечения, который позволяет сократить время простоя и риск появления новых версий программного обеспечения за счет создания двух идентичных сред: активной (синей) и неактивной (зеленой).
В активной среде запускается текущая версия программного обеспечения, и пользовали генерируют в ней рабочий трафик. В неактивной среде развертывается и тестируется новая версия программного обеспечения.
После того, как новая версия будет полностью протестирована и готова к релизу, трафик переключается с активной среды на неактивную, превращая ее таким образом в новую активную среду. При необходимости этот процесс можно повторить.
Связь с DevOps
Сине-зеленое развертывание хорошо согласуется с идеологией и процессами DevOps, а все потому, что оно поддерживает непрерывную доставку и развертывание программного обеспечения, минимизируя при этом время простоя рабочих пользователей и устраняя риск сбоя в рабочей версии.
Наличие двух идентичных сред позволяет тестировать и развертывать новые версии программного обеспечения без ущерба для текущей рабочей среды. Это значит, что релизы станут более быстрыми и частыми, что является ключевым аспектом DevOps.
Помимо этого, вы можете быстро переключать трафик между средами, что позволяет выполнить быстрый откат в случае возникновения каких-либо проблем, что также важно в DevOps-среде.
2. Важнейшие концепции сине-зеленого развертывания
#1. Две идентичные среды
Сине-зеленое развертывание требует от вас создания двух идентичных сред: активной (синей) и неактивной (зеленой). В данном случае понятие «идентичность» относится к данным и процессам.
Синяя среда – это место, где пользователи выполняют свою повседневную работу. Зеленая среда постоянно синхронизируется с синей, но на ней тестировщики запускают свои тестовые сценарии. Несмотря на то, что эта среда не является рабочей, вы запускаете тесты в реальных условиях, так как она очень похожа на рабочую.
#2. Переключение трафика
После того, как новая версия программного обеспечения будет полностью протестирована и готова к релизу, трафик переключается с активной среды на неактивную, превращая ее таким образом в новую активную среду.
Переключение происходит мгновенно. Все развертывания остались далеко в прошлом, и никаких простоев. Пользователям даже не нужно ничего делать, чтобы переместиться в новую среду – они перенаправляются туда автоматически.
#3. Быстрый откат
То, что вы можете быстро переключать трафик, также означает, что вы можете выполнить быстрый откат в случае возникновения каких-либо проблем. Таким образом, вы можете обеспечить минимальное время простоя и сохранить доступность приложения.
#4. Автоматизированное тестирование
Автоматизированное тестирование – это ключевой аспект сине-зеленого развертывания. Это значит, что новая версия программного обеспечения будет протестирована от и до, прежде чем будет развернута в активной среде.
Если вы не автоматизировали большую часть тестов в своих системах (как минимум модульные, функциональные и регрессионные тесты), то, возможно, вам не стоит задумываться о реализации сине-зеленого развертывания.
Отсутствие такой вещи, как автоматизация тестирований, существенно замедлит вашу работу. Количество времени, которое вы потратите на тестирование новой (зеленой) среды, будет настолько большим, что к тому моменту, как вы сможете переключиться на зеленую среду, она уже будет «слишком старой» с точки зрения жизненного цикла разработки программного обеспечения.
#5.
Непрерывное
развертывание
Сине-зеленое развертывание является частью конвейера непрерывного развертывания, а это значит, что релизы программного обеспечения будут более быстрыми и, соответственно, более частыми.
Вы можете переключаться с одной среды на другую, как только будете готовы протестировать новую версию ПО в «зеленой» среде. Поскольку само развертывание уже было выполнено, от вас требуется лишь переключить трафик, что довольно быстро. Вы можете это делать хоть каждый день, если, конечно, также быстро тестируете.
3. Стандартный жизненный цикл
Платформа, на которой выполняется сине-зеленое развертывание, имеет свой собственный жизненный цикл – набор этапов и процессов. Как правило, он состоит из следующих этапов:
Создание новой версии программного обеспечения. Сюда входит компиляция кода, запуск автоматизированных тестов и создание развертываемого артефакта.
На следующем этапе вы развертываете новую версию ПО в неактивной (зеленой) среде. Сюда входит настройка среды, развертывание артефакта и настройка всех необходимых параметров.
После того, как вы развернете новую версию ПО в «зеленой» среде, вы запускаете автоматизированные тесты с целью убедиться, что новая версия работает правильно. К этим тестам относятся функциональные, регрессионные, интеграционные и, если вы очень продвинуты, даже тесты производительности.
Теперь вы переключаете трафик с активной (синей) среды на неактивную (зеленую). В данном случае, чтобы направить трафик в зеленую среду, необходимо выполнить обновление балансировщика нагрузки или настроек DNS. Разумеется, вы захотите, чтобы все это тоже было выполнено автоматически.
После того, как трафик будет переключен, проверьте приложение с целью убедиться, что оно работает правильно. Сюда относится отслеживание ошибок, проблем с производительность и прочих проблем.
Этот этап не является обязательным, и в целом не стоит доводить ситуацию до него. Но в случае если кто-нибудь обнаружит какие-либо существенные проблемы, просто переключите трафик обратно на синюю среду. Таким образом, вы выполните откат. Снова повторюсь, никаких простоев или разъединений связи. Вам нужно просто обновить балансировщик нагрузки или настройки DNS, чтобы направить трафик в «синюю» среду.
Как только вы решите все проблемы и будете готовы вернуться к новой версии, переключите трафик обратно на «зеленую» среду. И снова – обновите балансировщик нагрузки или настройки DNS, чтобы направить трафик обратно в «зеленую» среду.
И наконец, как только новая версия ПО станет стабильной и будет правильно функционировать, вы должны «списать» старую версию ПО, работающую в «синей среде. Она вам понадобиться для создания еще одной новой версии вашей системы.
4. Внедрение конвейеров CI/CD
Внедрение сине-зеленого развертывание в CI/CD-конвейер DevOps должно стать обычной практикой.
Обязательным условием является наличие двух описанных выше идентичных сред. И так как это автоматизированный процесс, в качестве инструмента написания кода вы можете использовать инфраструктуру, например, AWS CloudFormation, или даже облако-независимые сценарии Terraform для создания/воссоздания/обновления сред в рамках автоматизированных контейнеров.
Если у вас все это есть, то этот шаг к созданию полностью автоматизированного процесса развертывания будет относительно простым. Вы просто должны повторно воспользоваться уже существующими конвейерами и создать синюю и зеленую среды. Однако сейчас вам нужно добавить в конвейер процесс тестирования.
Процесс переключения трафика тоже можно автоматизировать. Это можно сделать с помощью таких инструментов, как AWS Elastic Load Balancer или NGINX. Этот этап подразумевает обновление балансировщика нагрузки и настроек DNS для направления трафика в зеленую среду после того, как новая версия ПО будет полностью протестирована и готова к релизу.
Следующее звено в этой цепочке – отслеживание. Для этого рекомендуется использовать такие инструменты, как AWS CloudWatch, New Relic или Datadog.
И наконец, вы можете повторно использовать уже существующие конвейеры для того, чтобы «списать» старую синюю среду. Здесь уже выбор за вами, будете ли вы уничтожать все службы и компоненты и воссоздавать их с нуля, или обновлять сценарии для каждой службы в этой цепи. В большинстве случаев первый вариант является более безопасным, так как, обновляя сценарии, вам придется разбираться с гораздо большим количеством тупиковых ситуаций.
5. Рекомендации по сине-зеленому развертыванию
Вам интересно, как использовать сине-зеленое развертывание самым выгодным для вас способом? Тогда вот вам несколько практических советов.
Разработайте надежную стратегию миграции базы данных
Когда вы разворачиваете новую версию ПО, вы должны быть уверены, что схема базы данных была обновлена корректно. Используйте стратегию миграции базы данных, например, Flyway или Liquibase, для того, чтобы управлять изменениями схемы базы данных.
Используйте инструменты канареечного анализа
Несмотря на то, что канареечное (Canary) развертывание – это контрпример сине-зеленого развертывания, мы все равно можем использовать некоторые из его технологий для совершенствования последнего.
Вы можете использовать инструменты канареечного анализа, например, Kayenta или Spinnaker, для того, чтобы анализировать производительность новой версии ПО в реальной среде. В данном случае речь идет о сравнении производительности новой версии ПО с производительностью старой.
Вы также можете использовать библиотеку переключения функциональности, например, Togglz, для того, чтобы включать/отключать какие-то функции в новой версии ПО. Таким образом, вы можете внедрять новые функции постепенно и в случае необходимости быстро их откатывать.
Используйте балансировщик нагрузки с проверками состояния
Используйте балансировщик нагрузки с проверками состояния, например, AWS Elastic Load Balancer или NGINX, для того, чтобы быть уверенным в том, что трафик направляется только в работоспособные экземпляры. Таким образом, вы можете гарантировать высокий уровень доступности приложения и минимизировать время простоя.
Используйте план откатов с автоматизированными откатами
Разработайте план отката на случай возникновения каких-либо проблем и автоматизируйте процесс отката с помощью специального инструмента, например, AWS CodeDeploy или Octopus Deploy. Таким образом, вы сможете минимизировать время простоя и сохранить высокий уровень доступности приложения.
Всякий раз, когда вы обнаруживаете какую-либо серьезную проблему в новой версии, в большинстве случаев это связано с «зеленой» средой.
Вам не нужно разрабатывать план отката для «синей» среды, так как она остается нетронутой, и вы можете вернуться к ней в любой момент, как захотите.
6. Проблемы сине-зеленого развертывания
Реализация сине-зеленого развертывания может создать некоторые проблемы для команд разработчиков. Вот некоторые стандартные проблемы:
Настройка и управление двумя идентичными средами может быть довольно сложной и времязатратной задачей. Для этого требуются знания в области инфраструктуры, например, знание инструментов написания кода (Terraform или CloudFormation). Вам потребуется команда старших разработчиков, которая будет способна справиться с такими техническими задачами.
Когда вы разворачиваете новую версию ПО, вы должны быть уверены, что схема базы данных была обновлена корректно. Это может оказаться не самой простой задачей, особенно если схема базы данных довольно сложна. Вам нужны надежные способы развертывания баз данных, которые бы позволили безошибочно обрабатывать действия по обновлению схем баз данных в автоматическом режиме.
Сложным может оказаться анализ производительности новой версии ПО. Для этого требуется опыт работы с инструментами канареечного анализа, например, Kayenta или Spinnaker.
Реализация переключения функциональности также может оказаться довольно сложной, особенно если приложение имеет огромное количество функций. Это требует подготовки хорошего плана и слаженной работы разработчиков.
Тестирование новой версии ПО в реальной среде также может оказаться не самой простой задачей, особенно если у приложения довольно большое количество пользователей и серверов. Вам необходимо автоматизировать тестовые сценарии по максимуму. Кроме того, к вашим привычным обязанностям добавится координирование действий команды разработчиков и команды тестировщиков.
Наличие хорошего программного решения для отслеживания – явление крайне редкое, но для правильной работы DevOps это необходимо. Как только это станет возможным, потратьте на это время и создайте решение с помощью проверенных служб (AWS CloudWatch, New Relic, Datadog).
7. Разница между сине-зеленым и канареечным развертываниями
Несмотря на то, что отличие от обычных методов развертывания вполне очевидно (в обычных процессах развертывания нет двух параллельно существующих сред с разными версиями ПО), отличие от канареечного развертывания будет несколько поинтересней.
Сине-зеленое развертывание подразумевает наличие двух сред (синюю и зеленую), которые постоянно синхронизируются в отношении данных. После того, как новая версия была протестирована и признана готовой к релизу, трафик переключается с активной среды на неактивную, превращая ее таким образом в новую активную среду. Вы не тратите ни капли времени на развертывание нового кода, а рабочая среда не простаивает. Все пользователи так и продолжают работать в текущей активной среде; переключение происходит для них незаметно.
Канареечное развертывание подразумевает развертывание новой версии ПО для небольшой группы пользователей, тогда как большая часть пользователей или серверов продолжают использовать текущую версию. Это постепенное развертывание, а не резкий переход. В данном случае непосредственными пользователями продукта являются тестировщики, хоть и являются лишь их частью. Эта группа активно тестирует новую версию ПО в рабочей среде и, когда она наконец станет стабильной, ее распространят среди остальных пользователей.
Что же все-таки лучше?
Ответ любого эксперта начнется с «это зависит от…», и как бы тривиально это не звучало, он подходит сюда больше всего.
Если для вашей системы на первом месте стоит высокий уровень доступности, то сине-зеленое развертывание для вас.
Если же вы предпочитаете более быструю обратную связь и более контролируемые (хотя и более медленные) откаты новой версии ПО, то вам больше подойдет канареечное развёртывание.
Важно здесь то, что они оба достаточно быстрые и гибкие для того, чтобы считать себя хорошими вариантами для создания серьезной DevOps-системы.
8. Конкретные примеры
Netflix использует сине-зеленое развертывание для развертывания новых версией своего онлайн-кинотеатра. Таким образом, Netflix может развертывать новые версии своего сервиса, не влияя на взаимодействие пользователей с ним. По сути, одновременно с этим Netflix также использует канареечное развертывание для других своих сервисов. Так что, это вполне нормально использовать разные подходы к развертыванию DevOps.
Кроме того, сине-зеленое развертывание используют Amazon и Etsy. С его помощью они развертывают новые версии своих онлайн-магазинов.
Вот еще один пример – LinkedIn. Он использует сине-зеленое развертывание для развертывания новых версий своей социальной сети.
И последнее, но от того не менее важное: IBM использует сине-зеленое развертывание для развертывания новых версий своей облачной платформы.
Все эти компании успешно внедрили сине-зеленое развертывание в инфраструктуру своих платформ. Можете брать с них пример.
Заключение
Как и канареечное, сине-зеленое развертывание нацелено на наилучшую оптимизацию уже существующих гибких процессов и методов бесперебойного незаметного развертывания нового ПО. Для таких подходов это задача максимум. Вы постоянно и довольно часто выполняете развертывание, но никто об этом не знает, никто этого не замечает и, в итоге, никому нет до этого дела.
Конечно, команду разработчиков может немного расстраивать, что никто не судачит об их новых релизах. Но если вы спросите меня, почему такой расклад наилучший, я вам отвечу: никто об этом не говорит, но все это используют.