Monitoring and Reporting
11. Monitoring and reportingwhether done by the ASP itself or outsourced to an MSPis (ideally) proactive. The ASP should be so adept at scrutinizing the performance metrics that it can predict, say, network congestion; warn you; and fix it before the service is affected.
12. Similarly, the ASP should be able to run test scenariossay, in off hours or on its testing platformto determine whether system performance will degrade in the event you need to upgrade the application, for example, to accommodate additional users.
13. Any ASP should monitor most key components of its infrastructure such as network, servers, databases, and applications. But the ASP should also never overlook any equipment integral to the application's performancefor example, a SAN in the data center. Routine maintenance will usually also entail activities such as managing storage and other assets, as well as administering user access.
14. Reports submitted to you that corroborate SLA performance guarantees must also contain data that's relevant to your typical production work periods. For instance, an ASP submitting a measurement of transactions-per-minute taken at 2 a.m., when two users were on the application, is of no use to a company performing production work from 8 a.m. to 6 p.m., when the system has to accommodate 300 users without performance degradation. Test results from artificially generated data scenarios are also not accurate enough to be relevant.
15. Of course, monitoring should also not interrupt the users' work or the application's performance.
16. The ASP should generate reports analyzing all relevant performance trends. These might vary from customer to customeran FSP might have to monitor transactions-per-second for a customer leasing an e-commerce application, but not have to for one leasing a messaging application.