Virtualization news for the channel community and you !

As virtualization provides a new dimension to IT, it also shows a new dimension when it comes to management and maintenance. Virtualization will lower the TCO, increase the ROI, offer the capacity to correctly react to the changing needs of the business, … all nice aspects … but … It is not unthinkable that all these nice benefits go down the drain when your environment is not well prepared. When talking about ‘the environment’ we refer to both the physical infrastructure and software but also to those maintaining the infrastructure.

In order to eliminate the “risks” involved when it comes to maintance & management, setting up ‘Standard Operating Procedures’ are a good start, as long as those that need to execute thse SOPs are properly educated.

What is a SOP ? According to Wikipedia a SOP is a set of instructions (with the force of a directive) covering features of operations that lend themselves to a definite or standardized procedure without loss of effectiveness.

So in plain English it comes to a well structured worflow that consists out of triggers, prerequisites, actors, actions, output, tools and management, that will guide those that need to execute the SOP through a management task without being ‘to lawfully’. The goal is setting up SOPs that click together without be to obligatory.

A practical example of a set of SOPs that flow into a process:

A new employee has been attracted by the company, this involves a number of IT tasks that need to be executed before that employee can start working.  

So all these SOPs flow into a complete process (f.e. Setting up new employees within the IT Department), it is not only the goal to roll out high quality easy to follow SOPs but they can even be combined into (for example) a Six Sigma project that provides you with the capacity to look for (financial) improvements.

Before a SOP gets on the way, there has to be a trigger that crosses a treshold. Within a management context of a virtualized data center, this comes to planned or unplanned maintenance or a project request. What ever type of trigger occurs, it is important that these triggers are recorded in a ticketing system. In general there are three triggers:

• Planned maintenance: upgrades, fixes, rollouts, rollbacks, implementations, … in general these planned triggers occur after the approval of a customer, a business unit or a manager. There is clearly a formal approval necessary before you can start with this planned maintenance.

• Unplanned maintenance: an event that has not been planned (for example hardware failure, …) that requires an immediate action from the operations team. Within this case no formal approval of a customer, business unit or manager.

• Project Request: this is probably the widest of the three triggers, this ranges from setting up a new VM over creating a new vDisk, provisioning of a new server, … In most cases the Project Requests can be planned well in advance and are based on a formal approval of the customer, business unit or manager

Now that the trigges have been defined, it is important to indicate which prerequisites need to be met before the SOP gets to work. These prerequisites are often documents or approvals from the involved party, except for the unplanned maintenance triggers. The prerequisites should also include scheduling (if possible).

Once the prerequisites have been met, it is important to indicate those that need to execute the SOP. This can be a system administrator, an IT manager, a helpdesk coordinator, IT Ops, … make sure that you assign job roles to these actors instead of specific names.

The next step are the action steps, these steps should be prescriptive, actionable and concise, furthermore those tools that need to be used should be documented. It does not help to work out a book of actions, you should have confidence in those that take the actions as you have educated them on the actions.

• Bad example: Login to management console X, click on the server with the issue, right-click, …
• Good example: Login to management console, put host into maintenance mode, verify no VMs running, apply patch, …

• The goal of the SOP has been met (for example applying a patch)
• Ticket status within the ticketing system
• A formal notification
• …

One aspect till now has not been covered: testing. Make sure you test these SOPs before you rmove them from a draft version into a final version. If testing shows errors, issues, … change the SOP before  you move them to the final stage of implementing the SOP. When implementing these SOPs make sure that all involved parties have received the necessary training. If you have the time (you should make the time !), do a testrun with the SOP.

Also it is very smart to implement a prioritization for the SOPs, some SOPs solve bigger issues that other. For example setting up a new VM should have a lower priority than solving a security SOP on a running VM.

Do all SOPs need to be documented, as long as there is no technological solution for this, yes. Within the near future, vendors will provide the necessary tools to automate certain SOPs. For virtualization one of these tools will be Citrixs Workflow Studio. It will offer the capacity to automatically start-up new VMs when the load increases, eventhough this SOP will be automated it might be important to keep a copy of the SOP on paper.

What is the value of a SOP to a channel partner (VAR, reseller, integrator) or even an IT department with internal customers

Not only will SOPs offer, those servicing others, to increase their profitability of the system engineers executing the SOPs (locally at the customer or from remote), it also offers better ‘invoicing capacity’ (SOPs are ticketed, ticketing means timestamping, timestamping means invoicing). Furthermore tasks get documented, which offers the capacity for the SEs to jobrotate increase the satisfaction of the personnel.

On a commercial level it offers the possibility to increase credibility with the customer and it even opens doors when it comes to upsellin. (f.e. SOP for adding a new VM, results in the VM not being created as the hardware does not meet the prerequisites). 

Call to action

If you have any SOPs, which you wish to share with other virtualization professionals, feel free to forward the location where they can be found and we will make sure that they get the necessary visibility. We will publish a number of SOPs in the near future, in the mean time start SOPPING (not meant in literal way). 

Example set of SOPs

• Build VM
• Commission VM
• Decommission VM
• Server maintenance (multiple SOPs)
• Incident respons (multiple SOPs)
• Contact supplier / vendor for support
• Add LUN
• Remove LUN
• Patch template
• Create snapshot
• Revert snapshot
• Disk Add
• Disk Expand
• Disk Remove
• …