BiTel

Хотелось бы в идеале документ или главу по каждому модулю в документации описывающую что делать если в система был сбой какого то компонента. Ну например, услуга IP телефония, билинг состояит из трех компонент (условно): база данных, ядро, радиус сервер, предположим упало ядро и пролежало 4 часа, подняли... что делать дальше ?

Ситуация из практики: ядро+нетфлоу коллектор+флоу тулс стоят на одной машине, база данных на другой, рухнул канал до сервера с базой данных, провалялся 2 часа. Что я должен сделать в биллинге после востановления канала ? Я, например, вижу что у меня в биллинг не попали два часа трафика по IPN, сижу гадаю.... сделал этим часа "добавить в загрузку", нифига...


Вообщем то хотелось бы документацию по рекавери системы при такого рода сбоям, ибо это требуется не только после пожара, а и для профилактике или во время апгрейда. Очередной пример: система состояит из ядра, БД, IPN коллектора (3 разные сервера), требуется произвести апгрейд БД, рекрейтить рейд скажем и пересобрать (обновить) операционку и софт БД, выльется это все в 5-6 часов даунтайма сервера БД, как востанавливать после этого работу ?
тоже самое если например понадобится переносить или апгрейдить платформу под ядром биллинга...

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

Для случаев, когда собственных знаний недостаточно/нет времени - будет техподдержка.

P.S. Потерянные часы можно подсунуть коллектору точно так же, как и любой другой час - сконвертированный лог поместить в бинарные логи коллектора и дать ему команду isload с параметром.

все просто, подсунуть и все
только возникают вопросы:
что если был сбой коллектора netflow и данные за некоторый час неполные, надо ли удалять залитые в систему данные за этот час ? и если да то как это сделать ?

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

тех поддержка не может решить всех проблем, она, на сколько я понимаю, не круглосуточна, а следовательно большая часть ответсвенности все таки лежит на плечах тех админов что эксплуатируют систему, я не прав ?

Что подразумевается под "залитыми в систему данными"? Система проводит обработку прямо по бинарным часовым логам коллектора.
Меняете лог - переобрабатываете час, наработка за данный час меняется.


правы абсолютно. и поэтому админ должен понимать, как система работает.