[vlad11]

Сабж.

Возникла необходимость сменить очень древний биллинг A.

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

 

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

[vop]

Зачем так много людей для миграции биллинга?

[vlad11]

Зачем так много людей для миграции биллинга?

Сконвертировать данные с одного формата (базы) в другой недостаточно.

[myth]

А что еще?

[vlad11]

А что еще?

 

Нужно поддерживать пополнение баланса в старом биллинге. И только после полного перехода всех абонентов на новые сетевые настройки в новом биллинге можно выключать старый биллинг.

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

[~AsmodeuS~]

1 тестируете новый биллинг

2 делаете выгрузку с старого биллинга (для предварительного теста)

3 тестово выгрузку загружаете в новый

4 тестируете

5 делаете окончательную выгрузку из старого и загружаете в новый

[Svyatoybog]

Как по мне написали скрипт перезда на новый Билл, за тем проверили как все лягло на новую базу и последний штрих после теста залить последнюю свежую базу

[vlad11]

Как по мне написали скрипт перезда на новый Билл, за тем проверили как все лягло на новую базу и последний штрих после теста залить последнюю свежую базу

 

Еще раз.

Сконвертировать данные с одного формата (базы) в другой недостаточно.

[vop]

Еще раз.

Сконвертировать данные с одного формата (базы) в другой недостаточно.

 

Очень плохо, когда от биллинга зависит технология предоставления услуги.

[Red_Sam]

vlad11, из опыта могу сказать следующее:

- плавно, влан по влану, перевести абонентов можно (и делал даже что ISG цисковский работал с 2-я биллингами)

- а перенести информацию об абонентах по частям получится при остановке приема платежей

Поддерживаю вариант

1 тестируете новый биллинг

2 делаете выгрузку с старого биллинга (для предварительного теста)

3 тестово выгрузку загружаете в новый

4 тестируете

5 делаете окончательную выгрузку из старого и загружаете в новый

[NiTr0]

а перенести информацию об абонентах по частям получится при остановке приема платежей

перенести инфу одним махом, + костыль (по крону или как) для синхронизации платежей между БД, для поддержки актуального состояния...

[ichthyandr]

сетевые настройки в новом биллинге

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

[myth]

с пппое на ipoe переезжают, вестимо.

[amurblaga]

Биллинг должен считать деньги и не более. и работа пользователей не должна от него зависеть.

 

Я приводил пример нашего биллинга.

 

У нас перевод занял около дня. Вместе с обучением персонала. И википедия в нем, где написаны описания для разных жизненных случаев.

[Володя]

Когда переезжали с Nodeny на Mikbill, то делали так:

1. Подготовили машину с биллингом, протестировали

2. Делали рано утром перенос базы, убирали вланы с одного биллинга и добавляли на другой (биллинг с сервером доступа на одном тазе), проверяли под нагрузкой и искали косяки

3. Через часа 2-3 возвращали вланы на старый сервер и исправляли косяки

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

 

Делал это наш админ и пару человек из Mikbill. Больших проблем не было. С первого раза не получилось, так как были проблемы с регистром логинов, некоторые в роутере писали с большой буквы логины. Сейчас поставили еще один сервер для ipoe

[s.lobanov]

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

 

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

 

а при наличии 6 ролей как у ТС в проекте это будут бесконечные согласования и оттягивания

[SergeiK]

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

 

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

 

а при наличии 6 ролей как у ТС в проекте это будут бесконечные согласования и оттягивания

Тут зависит от масштаба процесса :).

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

Но и один админ не справится с задачей.

 

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

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

[~AsmodeuS~]

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

 

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

 

а при наличии 6 ролей как у ТС в проекте это будут бесконечные согласования и оттягивания

Тут зависит от масштаба процесса :).

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

Но и один админ не справится с задачей.

 

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

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

 

 

если идти по этапам которые были описаны выше и правильно прошло тестирование

то один админ нормально делает миграция при контроле поставщиков биллинга