What is a Service Wrap?

“A service wrap is a set of non-core services which are bundled with a core service to form a complete package of services that are sold. For example, if the service sold is an IT service (such as a cloud computing service), the service wrap included the governance of that service, such as service monitoring tools.” – Wikipedia

It is much more important than Wikipedia states. In this instance the service wrap is critical to the success, understanding and performance of the environment.

The customer demands assurance, the customer needs to be confident in the service provided.

Discovering how the applications function while inside an environment is critical to success.

How often when a server is built, does an architect/engineer examine every application service and process that runs on a server?

The answer is, not very often.

All too often, teams are too stretched, to fully understand every single element of an environment.

The install is focussed on getting the application working as quickly as possible.

Fully understanding what makes an application functional is critical to success.

What does a state of failure look like?

Is the performance acceptable?

When a fully assured solution is provided to a customer, the monitoring team has to make sense of what has been built in terms of functional elements and has to be able to explain this new service to others.

This is where a “service wrap” becomes a necessity.

The service wrap is a guide and a tool for the service deliverable that is handed over to the customer.

A service wrap gathers and provides a functional overview of the environment that promotes understanding and assurance.

Using the service wrap we can generate a dashboard to be displayed to those dedicated to the environments support. Alerts can be generated for a support team and the service wrap guarantees that every requirement is captured and documented.

Service elements will be prioritised in terms of criticality and thresholds and alerts based around these requirements will be provided.

A well-designed service wrap will contain every detail of the service, including the components that make up the service, so that a system admin can read through the service wrap documentation and instantly know what is important to keep the application environment running efficiently.

The service wrap information can then be applied into the monitoring system to provide 100% environmental confidence about every aspect of the infrastructure.

So how do we start? We start here…

The Nodes

Starting with the nodes that make up the application. These are the building blocks of your environment. Each server and each network device, the operating system running on the node, the function of the server or device documented. The IP addresses, subnet mask and the preconfigured VLAN information are specified and documented.

The Applications

The application components and services / processes will be specified here so that understanding about the details of the application is at the fingertips of all the engineers.

Any application can be monitored:

  • A service.
  • A process.
  • An AppInsight template.

The Database

The database is a very important part of any environment. What business critical system doesn’t have a database?

To monitor the database effectively, the database type must be specified so that we can install a connection client onto the SolarWinds poller to allow connectivity.

A connection string must be specified and documented containing the database files and the username and password.

A template containing a suitable select statement should be assigned to the database in SolarWinds to determine the status of the database.

The database can also be added to SQL AppInsight or Database performance analyser for more specific information.

Dependencies

Applications rely upon servers, databases, storage, network to function. This is where dependencies are specified and documented. A dependency can help form alerts and increase the awareness in Orion Maps.

Synthetic User Journeys

Web applications require testing. Testing them as a “real life” user, is critical in terms of keeping them available and performing for users. This is where the WPM synthetic user journey is specified. Each step documented and recorded to allow for changes in future when the application is adjusted.

Alerts

Alerts are important. Is your application up / down? Is it performing? Are the nodes / interfaces up? Are the databases up / down? This is where all alerts are specified, recorded and can be referenced when requirements are updated by NOC teams who need more alerts.

Reports

Reports will be specified and documented based upon requirements. Reports such as availability of the application to meet your 99.9% uptime requirements. If a metric can be captured over time, a report can be produced to demonstrate the metric graphically. Please see Operational Readiness Check and Daily Reports.

The Service Wrapper Documentation

As a simple guide this documentation means that anyone can check to see what is monitored in terms of a delivered application and when this document is filled in, we can simply place an X next to each of the requirements once its monitored. There are other modules not included in this wrapper and I may edit this post later on to include more products as requirements grow.

  • Node Status – What will affect the status of the node?
  • CPU – What CPU monitoring do we offer this service?
  • Memory – What Memory monitoring do we offer this service?
  • Volumes – What Volume / Disk Space monitoring do we offer this service?
  • Storage – Does the service run a storage device? If so what do we offer in terms of monitoring?
  • Interfaces – What interface monitoring do we offer this service?
  • Perf Metrics for the basic elements of the node – Do we offer performance metrics for the service?
  • Database Performance – Do we measure the performance of the databases within this service?
  • Capacity and forecasting – Do we offer this service forecast and capacity management?
  • NCM Backup – Do we need to backup the network devices within this service?
  • Do we want to monitor the dependencies of this service?
  • Do we want to measure the experience of the end user against this web service?
  • Are we monitoring events for this service, to netperfmon, email, servicedesk software?
  • Are we running templated, custom process monitors against this service?
  • Are we running templated, custom service monitors against this service?

Environment Awareness

  • Each section of the deliverable environment has been considered.
  • We know how the environment works.
  • We have mapped dependencies, drawn diagrams/maps.
  • We know what is a good state and what is a bad state.
  • We recognise how the nodes work together and we understand their functions.
  • We have relevant alerts and a list of useful reports ready to go.
  • We are evaluating performance across the network, the devices, the databases and the applications.
  • We are managing the capacity and we are forecasting for capacity growth and performance.

You can download this service wrap template to edit and add your own information to it.

Click the link below to download.

The Delivered Monitored Solution

Alongside the service wrapper document, a view (the NOC dashboard) should be created within SolarWinds to contain several resources:

  • An Orion Map is created to display the environment with all components, limited to just the nodes for this application specified and linked together to display latency.
    • Nodes
    • Applications
    • Databases
  • Availability of the nodes and applications.
  • Events and active alerts limited to the nodes that run the application and database.

By creating this service wrap and accompanying view we have a fully documented, monitored, deliverable solution.

  1. We gain a better understanding about what we are monitoring, supporting, maintaining and delivering.
  2. We can see the environment in a clear NOC display/dashboard.
  3. Knowledge transfer is made easier about the application and the environment between the team and other teams.
  4. If there are any critical environment issues or performance issues we are alerted immediately via a number of different methods (email), (traps), or direct integration into a service desk system.
  5. Relevant reports and dashboards provide information about environmental health and make it easier to carry out targeted root cause analysis.
  6. The overall SolarWinds experience is increased because it becomes a much better tool in the hands of a service wrap creator.

That’s a wrap! A service wrap!