The purpose of service visibility is to reconcile the execution of software with the agreement between the provider & customer of the service. Thus, the service must have customers who are aware that they are in fact customers of the service and furthermore are aware of the expected level of performance. In the case of an e-commerce site, the customers of the service are the visitors to the site and the agreed level of service is such that the customer views pages at some small epsilon + the speed of light. The service level agreement is arbitrary and can be estimated by the service provider. (e.g. 100ms)
Service providers need tools to help reconcile each customer's interaction with the service to understand if there are any breaches in agreement. When the agreement is breached, visibility tooling should provide help in debugging the violating component that lead to the breach. Surfacing information to service operators with the least amount of paing is a challenge accepted by makers of visiblity tooling.
I like that it starts from first principles, but it could use some more
exploration of the implications of those principles. “…visibility tooling
should provide help in debugging the violating component that lead to
the breach”, seems like the crux of the definition; everything else is
just setup.
For the definition itself, I'd add that visibility tooling should provide
help in noticing that the agreement has been breached in the first
place.
For the implications, I'm referring to what comes after the definition.
What, specifically, does that definition entail?