Provoking IT from Good to Great
Unified Computing Operational Processes
UCS Production Line Procedures
Processes schmo-cesses. If you use processes does it mean you are “doing” ITIL? Do you believe in ITIL? Are you for or against? Love ITIL or Loath ITIL? Is ITIL Yet Another Framework (YAF) that just detracts from your laser focus on delivering brilliant service to the business? Or is it something you can hide behind? Surely if you “use” ITIL, then you need to spend $$$ on a tool to be successful. Do I need to go on?
Forget about ITIL for a moment, and instead think “What are the essential things I need to do to be successful with Unified Computing?” The successful things (processes) are as follows:
Operations
These are the core processes wrapped around the technology that everything else has to link to. These processes are owned by the IT Operations staff, and nobody by-passes them – most of all, not the VCP/VCDX expert!
First you need to secure the Access Control, which means start with No Access for anyone and then build up access from there, starting with the core operations staff. This is not just role authentication and authorization, but network access points. Can anyone access the UCSM GUI? What about “telnet ucsm.my.com”?
Second, you need effective Event Management, which means sending ALL events from ALL components to a central source, restricting access to those central logs and providing tools like Splunk’s IT Search to interrogate them. UCSM provides the configuration for sending syslog externally, and using DMTF standards.
Lastly, in Operations, the key to mature operations is Standard Operating Procedures, supported by detailed Standard Technical Procedures. Don’t think of these as static, boring-to-follow screenshots: think of these as dynamic, creative scientific experiments where the Operations staff can create more efficiency without increasing risk. You can use the UCSM GUI, or the UCS CLI, or a Manager of Managers – whatever you do, capture (and continuously improve) the things that you do.
Controls
Wrapped around your Operations are two key controls.
First, in terms of UCS, you need to integrated the UCS Manager with your federated/enterprise CMDB. The UCS Manager IS a CMDB, but it isn’t integrated with change management out of the box – the Cisco-BMC alliance can help you here.
Second, in terms of UCS, you need to build a Change Matrix that details each SOP and the change profile. Deployment, maintenance and decommissioning – anything that people do should be captured in SOPs and in the Change Matrix.
More importantly, you need an effective (i.e. communicated and enforced) Change Policy, like the one advocated in Visible Ops.
Release
There are many logical components in UCS, and each needs a Release Lifecycle that covers deployment, maintenance and decommission.
Each component Release Lifecycle describes how that component has been proven to be deployed, configured, maintained and decommissioned. That is, it links together procedures and change activities, or maybe you call these Work Packages?
Resolution
This is a significant operational area where Fault Isolation and Root Cause Analysis live: for UCS, you need to make sure the system is prepared for both with correct configurations for logging and sub-systems like Call Home.
You also need to make sure these procedures are linked in with internal knowledge systems and Cisco’s own knowledge base.
Next Steps
With these core processes in place – Operations, Controls, Release, Resolution – then you can do things like Capacity Management, Service Level Management – and all the other ITIL-y things that might be possible – but hey, this might not follow the ITIL v3 timeline but do you care about ITIL?
Related posts:
| Print article | This entry was posted by Steve Chambers on 14 July, 2009 at 21:26, and is filed under Operations, UCS, good2great. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
