|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (51)
просмотр истории страницы| h1. План внедрения |
| {toc} |
| |
| h1. Самостоятельная интеграция Carbon Billing Мы рекоендуем ознакомиться с этим планом и идти в точности по нему, даже если проводите интеграцию самостоятельно. Если Вы интегрируете биллинг самостоятельно, мы подготовили для Вас базовую интструкцию по шагам со ссылками на необходимые статьи документации: [Самостоятельная интеграция Carbon Billing 5] h1. Внедрение вместе с отделом интеграции Carbon Soft h2. План внедрения |
| * План внедрения выработан на основе анализа проблем внедрения и позволил сократить сроки с года до месяца. * *Проблема 1* \- Стоп факторы и зависимости работ, есть определенные работы без которых другие работы или все внедрение невозможно, такие работы делаем в первую очередь. Последовательность крайне важна. * *Проблема 2* \- Если делать все работы сразу или даже 2 работы сразу, то возникает лавина взаимных задач и проблем, и сроки интеграции растягиваются в бесконечность. |
| * *Проблема 3* \- Размытие ответственности. Ответственным за внедрение назначается специалист тех.поддержки сотрудник Карбон Софт. Он ведет проект и контролирует сроки и соблюдение плана. И тех.поддержка CarbonSOft и пользователь должны решать одну и туже задачу, в соответствии с планом. |
| * *Проблема 4* \- Отсутствие концентрации. Необходимо выделить конкретные часы, в которые специалист поддержки CarbonSoft и пользователь будет заниматься только Интеграцией, в непрерывном диалоге и не отвлекаться. |
| * *Проблема 6* \- Если сразу делать пользовательскую схему, то внедрение затягивается неприемлемо долго. Необходимо сначала внедрить похожую стандартную схему и только потом доработка до пользовательской схемы. |
| * *Проблема 7* \- Всю интеграцию должен делать один и тот же специалист поддержки, сотрудник CarbonSoft, остальные специалисты только помогают. Если переключили специалиста поддержки, сотрудника CarbonSoft, то он должен перепроверить все предыдущие пункты лично. |
| * *Проблема 8* \- Если сроки этапа превышены, обязательно возникает Alarm руководителю поддержки/руководителю отдела/руководителю направления. |
| * *Проблема 9* \- Количество этапов Плана 10, количество никогда не меняется, состав может меняться. |
| * *Проблема 10* \- Необходимо делать либо Вариант 1 - внедрение силами тех.поддержки, сотрудников CarbonSoft, либо Вариант 2 - самостоятельное внедрение. Не нужно смешивать эти варианты. |
| h4. При самостоятельном внедрении * При знакомстве с биллингом используем видео-уроки на ютуб-канале [https://www.youtube.com/channel/UC0M3ekdZHPUlONhzUUFnUxg|https://www.youtube.com/channel/UC0M3ekdZHPUlONhzUUFnUxg] |
| * Если договор не подписан, в течение двух месяцев можно пользоваться технической поддержкой на уровне SLA1. помощью сотрудников CarbonSoft по условиям минимальной лицензии. |
| |
| h4. До подписания договора До подписания договора отдел продаж передаёт пользователя в инженерный отдел для уточнения возможности интеграции. * Клиент заполняет анкету с общей информацией о провайдере [http://helpdesk.carbonsoft.ru/index.php?module=Integration&action=index&onlymine=true|http://helpdesk.carbonsoft.ru/index.php?module=Integration&action=index&onlymine=true] * Инженер связывается с клиентом, уточняет детали по анкете из портала HelpDesk * Инженер передаёт пользователю анкету дополнительную анкету с вопросами об особенностях тарификации чтобы исключить возможные проблемы: [^анкета_по_тарификации_carbon_billing_5.docx] Получив максимум данных инженер делает вывод о возможности интеграции и возвращает пользователя в отдел продаж. |
| h4. План 1. ДоговорПодписан-1 |
| *Это триггер, что проект(сделка) передан из отдела Продаж в Тех.поддержку инженерный отдел и она появляется в разделе Alarm сделок поддержки.* инженерного отдела.* |
| * Назначение выделенного специалиста тех.поддержки. инженера. |
| * Специалист поддержки Инженер звонит пользователю и представляется. |
| * Согласовываем дату начала Интеграции. * Задаем доп.вопросы по опросному листу(анкете) [http://helpdesk.carbonsoft.ru/index.php?module=Integration&action=index|http://helpdesk.carbonsoft.ru/index.php?module=Integration&action=index]. |
... |
| *Оценка возможности интеграции и миграции. Установка Биллинга.* |
| * Системные требования. Выбираем сервер по инструкции [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=48693408] |
| * Скачиваем Carbon Billing 5 со страницы [https://www.carbonsoft.ru/download/|https://www.carbonsoft.ru/download/] |
| * Устанавливаем Carbon Billing 5 на сервер по инструкции [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=65799386] |
| * Очищаем базу биллинга от демо-данных по статье [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=67404041] |
| * Для поддержки, инженеров, проверка установки биллинга: |
| ** Правильная версия и бренч. ** Проверка регистрации и активации, рег.номер в сделке верный. |
... |
| *Максимально исключая сложные схемы* * Создаем или выбираем из поставки самый простой тариф без блокировки. |
| * Создаем и настраиваем NAS. Инструкция Интеграция с серверами доступа [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=50364669] |
| * Заливаем стандартную схему на оборудование по шагам Мастера. Никогда не создаем пользовательскую схему на этом этапе и не меняем стандартную, до проведения испытаний. * Нельзя настраивать коммутатор и привязки и стараемся без dhcp. |
... |
| * Опрашиваем бизнес логику заведения абонентов, оплаты, тарифов, физ.подключение, авторизация, блокировка, смена скорости, списания и т.д. * Анализируем текущую схему авторизации и блокировки. |
| * Создаем *Основной* тариф с услугами одноименный со старым, в карбон биллинге с учетом переноса логики оплаты, авторизации и блокировки. По статье [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=48693347] |
| * Отлаживаем на тестовом абоненте авторизацию, отключение, включение, еще раз отключение, еще раз включение, уход в минус, оплаты, еще раз уход в минус, еще раза оплата. * Отлаживаем на тестовом абоненте привязку и подстановку IP MAC и тп на коммутаторе, если нужно. |
| * Настраиваем платежные системы [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=48398393] |
| * Настраиваем оповещения абонентов http://docs.carbonsoft.ru/pages/viewpage.action?pageId=65798393 [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=49087090] |
| * Создаем все необходимые одноименные тарифы и nas-ы для миграции. |
| * Создаем группы абонентов (шаблоны), это упростит в дальнейшем добавление абонентов. http://docs.carbonsoft.ru/pages/viewpage.action?pageId=48398393 [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=49315940] |
| * Стандартные схемы используются у большинства провайдеров и они проверены временем. Если нужно разработать пользовательскую схему, необходимо согласовать с руководителем направления и разрабатывать с участием руководителя разработки. h4. План 7. Предварительная Миграция-3 |
| * Мигрируем абонентов с помощью скрипта импорта из CSV-файла по статье [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51708975]. Можно вручную силами абонентского отдела, если абонентов совсем немного. |
| * CSV-файл готовит пользователь, тех.поддержка и программисты инженеры могут помочь при возможности. |
| * Импорт CSV-файл. Анализ верности импорта данных поддержкой инженерами и пользователем. |
| * При ошибках, восстанавливаем чистую БД из бекапа, стараемся не решать проблему sql_update-ом. |
| * Вывод реального абонента или части сети в Интернет. |
... |
| *Крайне важный пункт, пользователь должен уметь сам провести испытания. Подпись обязательна.* |
| * Инструкция [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51708918] |
| * При невозможности или отказе провести испытания, мы не можем гарантировать верную работу, обращаемся к рук.направления. * Если нужно внедрять телефонию или IPTV, то после испытаний переходим к *План 2*. По телефонии и IPTV проводим отдельные испытания |
| {code}Испытания схемы интеграции интернет оборудования с Carbon Billing 5 |
| {code}Испытания Схемы интеграции оборудования с Carbon Billing 5. Нужное подчеркнуть: Стандартная Схема или Пользовательская Схема. |
| Способ авторизации: IPoE/PPPoE/IP/DHCP82 Испытательные работы в сети оператора связи: ______________________ |
... |
| 2 Авторизация, подключение абонента, выход в Интернет (успешно/ошибка) 3 Отключение абонента администратором, Интернет отключился (успешно/ошибка) |
| 4 Доступ к ресурсам разрешенным при блокировке администратором - Сайт провайдера (успешно/ошибка/не требуется) |
| 45 Отключение абонента при превышении лимита (успешно/ошибка) |
| 6 Доступ к ресурсам разрешенным при превышении лимита - Банки и Платежки (успешно/ошибка/не требуется) |
| 57 Подключение абонента при пополнении баланса (успешно/ошибка) |
| 68 Редактирование абонента, в т.ч. смена логина и IP (успешно/ошибка) |
| 79 Изменение скорости доступа при смене тарифа (успешно/ошибка) |
| 8 Изменение 10 Изменение скорости в тарифе «лестница» (успешно/ошибка/не требуется) |
| 11 Экстренное отключение абонента - вынуть кабель и перезагрузить ПК (успешно/ошибка) 12 Проверить экстренный сброс оборудования (успешно/ошибка) |
| 9 Удаление 13 Удаление абонента (успешно/ошибка) |
| |
| После завершения интеграции биллинг запускается в эксплуатацию в тестовом режиме на срок 35 дней, по истечении этого срока проводятся повторные испытательные работы, по результатам которых производится окончательный ввод биллинга в эксплуатацию. |
| Внимание, обязательно проведите повторные испытания через 35 дней, для контроля закрытия месяца. |
| Лицо из тех.поддержки, инженерного отдела, проводившее интеграцию ФИО: _____________ |
| Лицо от оператора, проводившее проверку ФИО: ___________________ Лицо от оператора, дата_________________ подпись________________{code} |
| h4. План 9. Окончательная Миграция-2 Тестовая эксплуатация-37 |
| |
| * Миграция(3 дня) - Обычно балансы и новые абоненты, либо новых руками. |
| * Обязательно закрытие периода и анализ верности закрытия нами и пользователем. |
| |
| h4. План 10. Тестовая эксплуатация-32 Опытная эксплуатация-64 |
| |
| * Обязательно закрытие периода и анализ верности закрытия нами и пользователем. |
| * Анализ каждого закрытия периода * Раз в 7-10 дней спрашиваем как дела и обсуждаем на скраме. * Внимательно наблюдаем за работой схемы интеграции и учета баланса, что не возникает артефактов. |
| h4. Закрыта удачно |
| * Рабочая эксплуатация, первые 3 месяца внимательно наблюдаем за работой схемы интеграции и учета баланса, что не возникает артефактов. |
| * Рабочая эксплуатация. |