vlad11 Posted May 7, 2016 Сабж. Возникла необходимость сменить очень древний биллинг A. Но нужно разбить по этапам и разграничить ответственность между: контрактным сисадмином, контрактным программистом, разработчиками нового биллинга, местным сисадмином, бухами и руководителем проекта миграции. У кого есть подобное, хоть в частичном виде, прошу поделиться. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vop Posted May 7, 2016 Зачем так много людей для миграции биллинга? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vlad11 Posted May 7, 2016 Зачем так много людей для миграции биллинга? Сконвертировать данные с одного формата (базы) в другой недостаточно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
myth Posted May 7, 2016 А что еще? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vlad11 Posted May 8, 2016 А что еще? Нужно поддерживать пополнение баланса в старом биллинге. И только после полного перехода всех абонентов на новые сетевые настройки в новом биллинге можно выключать старый биллинг. Миграцию на новые брасы и биллинг предполагается делать поочередно каждый влан. Обычно там от нескольких десятков до полуторы сотни пользователей. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
~AsmodeuS~ Posted May 8, 2016 1 тестируете новый биллинг 2 делаете выгрузку с старого биллинга (для предварительного теста) 3 тестово выгрузку загружаете в новый 4 тестируете 5 делаете окончательную выгрузку из старого и загружаете в новый Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Svyatoybog Posted May 8, 2016 Как по мне написали скрипт перезда на новый Билл, за тем проверили как все лягло на новую базу и последний штрих после теста залить последнюю свежую базу Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vlad11 Posted May 8, 2016 Как по мне написали скрипт перезда на новый Билл, за тем проверили как все лягло на новую базу и последний штрих после теста залить последнюю свежую базу Еще раз. Сконвертировать данные с одного формата (базы) в другой недостаточно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vop Posted May 8, 2016 Еще раз.Сконвертировать данные с одного формата (базы) в другой недостаточно. Очень плохо, когда от биллинга зависит технология предоставления услуги. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Red_Sam Posted May 8, 2016 vlad11, из опыта могу сказать следующее: - плавно, влан по влану, перевести абонентов можно (и делал даже что ISG цисковский работал с 2-я биллингами) - а перенести информацию об абонентах по частям получится при остановке приема платежей Поддерживаю вариант 1 тестируете новый биллинг 2 делаете выгрузку с старого биллинга (для предварительного теста) 3 тестово выгрузку загружаете в новый 4 тестируете 5 делаете окончательную выгрузку из старого и загружаете в новый Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted May 8, 2016 а перенести информацию об абонентах по частям получится при остановке приема платежей перенести инфу одним махом, + костыль (по крону или как) для синхронизации платежей между БД, для поддержки актуального состояния... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ichthyandr Posted May 10, 2016 сетевые настройки в новом биллинге ??? биллинг считает деньги, причем тут сетевые настройки ??? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
myth Posted May 10, 2016 с пппое на ipoe переезжают, вестимо. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
amurblaga Posted May 11, 2016 Биллинг должен считать деньги и не более. и работа пользователей не должна от него зависеть. Я приводил пример нашего биллинга. У нас перевод занял около дня. Вместе с обучением персонала. И википедия в нем, где написаны описания для разных жизненных случаев. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Володя Posted May 11, 2016 Когда переезжали с Nodeny на Mikbill, то делали так: 1. Подготовили машину с биллингом, протестировали 2. Делали рано утром перенос базы, убирали вланы с одного биллинга и добавляли на другой (биллинг с сервером доступа на одном тазе), проверяли под нагрузкой и искали косяки 3. Через часа 2-3 возвращали вланы на старый сервер и исправляли косяки 4. Опять запускали новый биллинг рано утром, делали еще один перенос базы и убедившись что все впорядке, мы уже запускали оплаты на новый биллинг Делал это наш админ и пару человек из Mikbill. Больших проблем не было. С первого раза не получилось, так как были проблемы с регистром логинов, некоторые в роутере писали с большой буквы логины. Сейчас поставили еще один сервер для ipoe Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted May 11, 2016 да ему надо другое - некий формальный документ с разделениями зон ответственности. но на деле же, каждая миграция биллинга это очень индивидуальный проект и вообще оно зависит от предварительных договорённостей. наиболее 2 популярных сценария: миграцию делает производитель нового биллинга, заказчик только наблюдает и говорит так-не так, очень дорогое удовольствие. 2ой - миграцию делает админ, предварительно изучив новый биллинг. на практике это быстрее, но мало у кого квалификации хватает на это а при наличии 6 ролей как у ТС в проекте это будут бесконечные согласования и оттягивания Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SergeiK Posted May 11, 2016 да ему надо другое - некий формальный документ с разделениями зон ответственности. но на деле же, каждая миграция биллинга это очень индивидуальный проект и вообще оно зависит от предварительных договорённостей. наиболее 2 популярных сценария: миграцию делает производитель нового биллинга, заказчик только наблюдает и говорит так-не так, очень дорогое удовольствие. 2ой - миграцию делает админ, предварительно изучив новый биллинг. на практике это быстрее, но мало у кого квалификации хватает на это а при наличии 6 ролей как у ТС в проекте это будут бесконечные согласования и оттягивания Тут зависит от масштаба процесса :). При существенном масштабе и значительных рисках возлагать ответственность на производителя нового биллинга, действительно, очень дорого. Но и один админ не справится с задачей. В этом случае и включается сложный, но, все же выполнимый путь поэтапной миграции, с вовлечением разных подразделений, с многоплановым тестированием, и прочими сложными процессами. Вопрос в том, что такой процесс каждый раз уникальный, написать общее правило нельзя. Хотя технологий, оборудования и биллингов счетное количество, количество возможных комбинаций очень велико. А если наложить сверху более менее уникальную внутреннюю организацию у всех, то даже примерно что-то предложить трудно без погружения в суть. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
~AsmodeuS~ Posted May 12, 2016 да ему надо другое - некий формальный документ с разделениями зон ответственности. но на деле же, каждая миграция биллинга это очень индивидуальный проект и вообще оно зависит от предварительных договорённостей. наиболее 2 популярных сценария: миграцию делает производитель нового биллинга, заказчик только наблюдает и говорит так-не так, очень дорогое удовольствие. 2ой - миграцию делает админ, предварительно изучив новый биллинг. на практике это быстрее, но мало у кого квалификации хватает на это а при наличии 6 ролей как у ТС в проекте это будут бесконечные согласования и оттягивания Тут зависит от масштаба процесса :). При существенном масштабе и значительных рисках возлагать ответственность на производителя нового биллинга, действительно, очень дорого. Но и один админ не справится с задачей. В этом случае и включается сложный, но, все же выполнимый путь поэтапной миграции, с вовлечением разных подразделений, с многоплановым тестированием, и прочими сложными процессами. Вопрос в том, что такой процесс каждый раз уникальный, написать общее правило нельзя. Хотя технологий, оборудования и биллингов счетное количество, количество возможных комбинаций очень велико. А если наложить сверху более менее уникальную внутреннюю организацию у всех, то даже примерно что-то предложить трудно без погружения в суть. если идти по этапам которые были описаны выше и правильно прошло тестирование то один админ нормально делает миграция при контроле поставщиков биллинга Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
