Once the Portal authentication system is online, the carriers are confronted with a bunch of abstract states: equipment is not online, links are out of touch, certification is unsuccessful and bandwidth is used. If this information can only be checked by one order, daily inspections will be hard and slow when they fail. The solution is to turn these abstract situations into something that can be read at first glance, so that those on duty know what the network is and where it is not right.
TAP solves the problem of location.
The role of the top-to-line map is to draw out the equipment and connection, so that one can see at first glance what the network looks like, where a device is located, which device is not online. Its core value is positioning: when a region's user is unable to authenticate it, look for the top-to-top to confirm whether the access device in that area is online or nodes abnormal on its path to the authentication platform. Without the top-up, the barrier is only memory and guessing, inefficient and prone to error, especially after the transfer of personnel.
The link map solves the quality problem.
The link chart is concerned with the state and quality of exports and key links, such as how many export routes are inaccessible, bandwidth used, delays and drops. It answers different questions: the map looks at whether it is good or not. In a multi-export environment, the link map is particularly important, showing which lines are the main current flow, which is close to full, and whether there are poor line quality. This type of information can be obtained by command checks but it is much faster than figures.
Monitor screens to select the true action-driven indicators
The most easy mistake to make is the big screen, which puts all the figures that can be thought of in a pile of indicators, looks professional, and actually nobody knows which ones to look at first. The big screen’s indicator selection criteria should be whether it can drive: see how this number changes, you know what to do. Online numbers, certification success rates, average time-consuming certifications, export bandwidth usage, and currently unprocessed alerts are typical drivers.
Different characters see different things.
The visual content should be layered. Watchers look at the screens, and are concerned with whether there are any anomalies or not to process them; those who check malfunctions look at the details of the ping-and-tao equipment and which particular problem is their concern; those who do the retreading and optimization look at trends and how indicators change over time.
More visible under the control and transmission separation structure
In some gateway devices, the control and re-transmission surface are separate and automated deployment and centralized. The benefit of this architecture is centralization, but it also raises a practical problem: the state seen on the management interface and actual re-transmission may not be fully synchronized. If you can visualize only the status of the management side, an anomaly in the trans-shipment will be missed. So when designing the monitoring view, it is best to confirm whether the data source displayed is management or re-transit, which is seen on both sides, depending on the actual transmission if inconsistencies occur.
I can't see it.
Visualization is about the speed of discovery and not the depth of location problems. The screen tells you that the success rate for authentication is falling, but it does not tell you why. Positioning is still based on authentication records, equipment logs, and the sort of screening methods mentioned earlier. So visualization should be sentinel, not detective: it will tell you first where to go, probably in which direction, the underlying causes of subsequent analysis still need to be complete logs and records.
Visual indicators to be reviewed periodically
The monitoring view cannot be kept intact. Business changes, attention changes, and the indicators that were important six months ago may now be meaningless, while new risk points may not be covered. It is suggested to review at intervals whether indicators on screen are still being noticed, if there have been any anomalies but not monitored, or if warning thresholds need to be adjusted.
Don't sacrifice your accuracy for the sake of beauty.
Finally, the first requirement for visualization is accurate and not very good. If the picture shows a deviation in state and reality, such as if the device is offline online, it is worse than if it does not, because it misjudges. So before viewing is on line, check whether the values are identical to actual values, especially if the threshold of state judgement and the frequency of refreshing them are reasonable. The process of updating too slowly reveals an outmoded state, while the process of refreshing too quickly may be misreported by instant shaking.
Visualised limits of competence
The scope of the operating data, which includes information such as user numbers, online situations, and fees, is different. The system itself supports a hierarchy of management, managers, fee collectors, maintenance personnel each see their own range of data, and visualization should follow the same boundaries, not because it is displayed on screen without any difference.