... {toc}
h1. План внедрения
* План внедрения выработан на основе анализа проблем внедрения и позволил сократить сроки с года до месяца.
* *Проблема 1* \- Стоп факторы и зависимости работ, есть определенные работы без которых другие работы или все внедрение невозможно, такие работы делаем в первую очередь. Последовательность крайне важна.
* *Проблема 2* \- Если делать все работы сразу или даже 2 работы сразу, то возникает лавина взаимных задач и проблем, и сроки интеграции растягиваются в бесконечность.
* *Проблема 3* \- Размытие ответственности. Ответственным за внедрение назначается специалист тех.поддержки Карбон Софт. Он ведет проект и контролирует сроки и соблюдение плана. И тех.поддержка и пользователь должны решать одну и туже задачу, в соответствии с планом.
* *Проблема 4* \- Отсутствие концентрации. Необходимо выделить конкретные часы, в которые специалист поддержки и пользователь будет заниматься только Интеграцией, в непрерывном диалоге и не отвлекаться.
* *Проблема 6* \- Если сразу делать пользовательскую схему, то внедрение затягивается неприемлемо долго. Необходимо сначала внедрить похожую стандартную схему и только потом доработка до пользовательской схемы.
* *Проблема 7* \- Всю интеграцию должен делать один и тот же специалист поддержки, остальные специалисты только помогают. Если переключили специалиста поддержки, то он должен перепроверить все предыдущие пункты лично.
* *Проблема 8* \- Если сроки этапа превышены, обязательно возникает Alarm руководителю поддержки/руководителю направления.
* *Проблема 9* \- Количество этапов Плана 10, количество никогда не меняется, состав может меняться.
* *Проблема 10* \- Необходимо делать либо Вариант 1 - внедрение силами тех.поддержки, либо Вариант 2 - самостоятельное внедрение. Не нужно смешивать эти варианты.
h4. При самостоятельном внедрении
* При знакомстве с биллингом используем видео-уроки на ютуб-канале [https://www.youtube.com/channel/UC0M3ekdZHPUlONhzUUFnUxg|https://www.youtube.com/channel/UC0M3ekdZHPUlONhzUUFnUxg]
* Если договор не подписан, в течение двух месяцев можно пользоваться технической поддержкой на уровне SLA1.
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]
|
... h4. План 1. ДоговорПодписан-1
*Это триггер, что проект(сделка) передан из отдела Продаж в Тех.поддержку и она появляется в разделе Alarm сделок поддержки.*
* Назначение выделенного специалиста тех.поддержки.
* Специалист поддержки звонит пользователю и представляется.
* Согласовываем дату начала Интеграции.
* Задаем доп.вопросы по опросному листу(анкете) [http://helpdesk.carbonsoft.ru/index.php?module=Integration&action=index|http://helpdesk.carbonsoft.ru/index.php?module=Integration&action=index].
h4. План 2. Подготовка и Установка-2
*Оценка возможности интеграции и миграции. Установка Биллинга.*
* Системные требования. Выбираем сервер по инструкции [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]
* Для поддержки, проверка установки биллинга:
** Правильная версия и бренч.
** Проверка регистрации и активации, рег.номер в сделке верный.
** Проверка системных требований.
* Предварительный анализ совместимости сетевого оборудования и схемы авторизации. Анализ производительности оборудования. Обсуждение возможности смены оборудования и коррекции схемы авторизации.
* Оценка возможности миграции тарифов. Обсуждение коррекции тарифов и схемы учета.
* Анализ других стоп факторов от пользователя.
h4. План 3. Подготовка сетевого оборудования-5
* Проверка, что установлена последняя стабильная прошивка и у NAS и у коммутатора или прошиваем. (Экономия месяца, чтоб не ловить с глюки старых прошивок)
* Спрашиваем есть ли выделенное оборудование (экономия месяца, если есть отдельная железка. Иногда можно взять на тест у дилера)
* Если нет выделенного оборудования, продумываем и подготавливаем параллельную схему, чтоб и текущие абоненты работали и тестовые абоненты работали. (логические маршрутизаторы и т.п.)
h4. План 4. Вывод абонента без авторизации-2
*Необходимо разделить проблемы маршрутизации и сети от проблем авторизации, иначе ничего не получится. При этом обязательно формируется тестовый стенд (это экономит 1 месяц)*
* Ставится отдельный тестовый компьютер или ноутбук - это *тестовый абонент*
* Отдельный коммутатор, если потребуется привязка к портам и тп.
* Настраивается маршрутизация и nat на маршрутизаторе в соответствующем логическом подмаршрутизаторе/подсхеме, который будет использоваться.
* *Тестовый абонент* выводится в Интернет, без авторизации в биллинге. Можно без впн без радиуса, просто голая маршрутизации и nat.
* Считаем, что *Тестовый стенд* и *Тестовый абонент* созданы
h4. План 5. Настройка авторизации абонента-2
*Максимально исключая сложные схемы*
* Создаем или выбираем из поставки самый простой тариф без блокировки.
* Создаем и настраиваем NAS. Инструкция Интеграция с серверами доступа [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=50364669]
* Заливаем стандартную схему на оборудование по шагам Мастера. Никогда не создаем пользовательскую схему на этом этапе и не меняем стандартную, до проведения испытаний.
* Нельзя настраивать коммутатор и привязки и стараемся без dhcp.
* Выводим авторизованного абонента в Интернет.
* Экватор.
h4. План 6. Бизнес-логика и команды-2
* Опрашиваем бизнес логику заведения абонентов, оплаты, тарифов, физ.подключение, авторизация, блокировка, смена скорости, списания и т.д.
* Анализируем текущую схему авторизации и блокировки.
* Создаем *Основной* тариф с услугами одноименный со старым, в карбон биллинге с учетом переноса логики оплаты, авторизации и блокировки. По статье [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=49087090]
* Создаем все необходимые одноименные тарифы и nas-ы для миграции.
* Создаем группы абонентов (шаблоны), это упростит в дальнейшем добавление абонентов. [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-ом.
* Вывод реального абонента или части сети в Интернет.
h4. План 8. Лист Испытаний-2
*Крайне важный пункт, пользователь должен уметь сам провести испытания. Подпись обязательна.*
* Инструкция [http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51708918]
* При невозможности или отказе провести испытания, мы не можем гарантировать верную работу, обращаемся к рук.направления.
* Если нужно внедрять телефонию или IPTV, то после испытаний переходим к *План 2*. По телефонии и IPTV проводим отдельные испытания
{code}Испытания Схемы интеграции оборудования с Carbon Billing 5. Нужное подчеркнуть: Стандартная Схема или Пользовательская Схема.
Способ авторизации: IPoE/PPPoE/IP/DHCP82
Испытательные работы в сети оператора связи: ______________________
1 Создание абонента (успешно/ошибка)
2 Авторизация, подключение абонента, выход в Интернет (успешно/ошибка)
3 Отключение абонента администратором, Интернет отключился (успешно/ошибка)
4 Доступ к ресурсам разрешенным при блокировке администратором - Сайт провайдера (успешно/ошибка/не требуется)
5 Отключение абонента при превышении лимита (успешно/ошибка)
6 Доступ к ресурсам разрешенным при превышении лимита - Банки и Платежки (успешно/ошибка/не требуется)
7 Подключение абонента при пополнении баланса (успешно/ошибка)
8 Редактирование абонента, в т.ч. смена логина и IP (успешно/ошибка)
9 Изменение скорости доступа при смене тарифа (успешно/ошибка)
10 Изменение скорости в тарифе «лестница» (успешно/ошибка/не требуется)
11 Экстренное отключение абонента - вынуть кабель и перезагрузить ПК (успешно/ошибка)
12 Проверить экстренный сброс оборудования (успешно/ошибка)
13 Удаление абонента (успешно/ошибка)
Внимание, обязательно проведите повторные испытания через 35 дней, для контроля закрытия месяца.
Лицо из тех.поддержки, проводившее интеграцию ФИО: _____________
Лицо от оператора, проводившее проверку ФИО: ___________________
Лицо от оператора, дата_________________ подпись________________{code}
h4. План 9. Тестовая эксплуатация-37
* Миграция(3 дня) - Обычно балансы и новые абоненты, либо новых руками.
* Обязательно закрытие периода и анализ верности закрытия нами и пользователем.
h4. План 10. Опытная эксплуатация-64
* Анализ каждого закрытия периода
* Раз в 7-10 дней спрашиваем как дела и обсуждаем на скраме.
* Внимательно наблюдаем за работой схемы интеграции и учета баланса, что не возникает артефактов.
h4. Закрыта удачно
* Рабочая эксплуатация, поддержка по SLA.
|
