The campus network billing system is upgraded, both in terms of the length of the version and the replacement of the factory, to a high risk operation. If the upgrade fails, students are unable to access it, complaints and stress are high.
Must do before upgrade: current network traffic model and user count
Many of the integrators get to the project and ask directly."What version are you using? We'll make it to the latest edition."The question is wrong.
The correct answer is:"What do you have on-line users peaking? What's the maximum traffic in dormitories? Are there more operators? How many are the billing strategies?"——These questions are clear before the feasibility of direct upgrading can be judged.
I've had a case of an old version that supports up to 5,000 and sends a billing session, with the school expanding up to 8,000 and then it's going down.——Since the new version of the structure changed how billing sessions were managed, the 5,000-sum limit was lifted, but CPUs for single servers became a new bottleneck. If a flow count is done before upgrading, server expansion should be planned in advance, rather than being remediated after upgrades.
Parallel deployments are more secure than direct coverage
The most secure way to upgrade the billing system is"Parallel deployment": The new system is deployed on another server (or virtual machine) to import configurations and user data from the old system without access to the current network. Then, using a small number of test accounts, verify bill logic, bill accuracy, and interact with NATSHEL_AUTH_GATEWAY protocols on the new system.
After validation, find a window with the lowest flow time (usually 6-8 a.m. on Sunday morning) that points NATSHEL_AUTH_GATEWAY to the transfer from the old system to the new one. The switch process is 5-10 minutes and if there is a problem, just the old system can be returned.
The program of direct coverage for installation is considered only on a small campus network (less than 1,000 people).
Pocket for data migration: user status and bill continuity
At the time of upgrading, user online status and bill continuity were two of the most problematic places.
User status online: 3,000 active billing sessions in the old system, how do you switch them to instantaneous? If you clear up, students who are online will be forced offline and experience a bad experience. Good thing is that the new system supports them."Import Active Sessions"——Export the online user list of the old system, import it into the new system and switch to a non-received user.
Bills continuity: How do the bills go back to and forth of the upgrade point? If the last bill in the old system is 23:59 May 15, the first bill in the new system should start at 00:00 May 16. There can be no gaps or overlap. This connection logic must be measured before upgrading.
Rollback program has to be verified in advance.
Any upgrades must have a rollback plan. And the rollback plan cannot be written in a document, but it has to be practiced in a test environment.
The drills include: How does a user charge the flow during the switch when the new system is cut back to the old system? Is it counted in the new system (moved manual import after the cut back) or simply discarded (user experience impaired). Different rollback strategies affect users differently, and they have to be identified with clients well in advance.
There is also a detail: the old version of the system, if it is needed for upgrades, whether it needs to be downgraded. If so, have the demotion steps been validated? I saw a project that failed to upgrade and rolled back. The old version of the installation package was found to be missing, and only the old version could be re-enacted and recovered from backup data, which took six hours.
The observation period after the upgrade is at least one week.
The billing system is upgraded to prevent immediate departure."The traffic's not working properly.", check whether the system resources are occupied (CPU/RAM/disk) in line with expectations.
The problems that are observed during the observation period, usually."It's not triggered until it's measured."Border problems. These are difficult to re-emerge in a test environment and can only be exposed in real traffic after the line is up.
If you see a serious problem during the observation period, there are windows that roll back fast. If you see no problem, this project is really finished.
Additional workload in replacement of plant
If the same manufacturer upgrades the version, data migration is relatively simple and there are usually readily available import export tools.——User accounts, billing strategies, package configurations, historical bills, interface parameters with Authentication Gateway, all of which require reconfiguration.
In practice, the most time-consuming thing is not to configure new systems, but rather to..."Translating old system billing strategies into new system configurations". Each manufacturer has a different name and logic for its costing parameters, the same one"30 bucks a month. 100 G."The package may have eight parameters in system A and 12 in system B. This translation process must not be lazy, each parameter corresponds to the other, otherwise the billing results will vary.
It is suggested that the contract should be clear: when replacing a manufacturer, the old factory has an obligation to cooperate with the provision of complete billing strategies for export and interface documents. Some manufacturers do not write this in their contracts, and by moving around they are passively reacting to new plants and schools.