Category — automation

Just some rambling thoughts here…feel free to join in.

Is another tool what’s really required here? What should/could be done in domain specific resource monitoring solutions that addresses the problems at the edge? Should I really be monitoring everything that comes out of the box in a default configuration? Why do I have all of these profiles, situations, thresholds, events, etc. in the first place? Do I even now what I’m monitoring and why?

What if I have a multi-vendor, multi-sourced environment where I may or may not have visibility? What if I don’t have a CMDB or other source of topology, relationships and dependencies? What if I don’t even know the state and status of the applications, databases or services to begin with? What will I be able to do with investments into these technologies?

What if I have adopted a “manager of managers” concept where I have a consolidated operations eventing environment with feeds from across the entire business environment (facilities, plant, IT, datacenter, logistics, telephony, manufacturing, contact centers, etc.)? Shouldn’t this dynamic “learning” and “thresholding” concept be really applied at this level for some sort of “intelligent event management” free from manual intervention, policies, codebooks, etc? How about the context of the business calendar and schedule merged with the IT operations calendar and schedule? I doubt that this can all be “learned” magically.

If I invest in a BMC ProactiveNet, Netuitive or Integrien (or other fundamental dynamic “learning” or “trending” tool - my favorite was a company called Premonitia - now defunct, based on research from accoustic modelling of whales and shrimp IIRC), how will I recognize and measure the value from that investment? How should the operations environment change to adopt the promises of the “secret sauce” within these emerging technology areas? Will IT operations and second/third tier support teams need to change the ways they work today? If so, how? Does IT operations know how to respond to a future state that hasn’t occurred or someone stating that a service is “slow”? I think most operations and support teams are still in their infancy here.

I’m all for emerging technologies that speak towards making the lives of the folks on the front line better and for sensing, isolating and resolving issues within complex IT environments before they impact the business services, but will investing in these tools really improve the status quo within the typical operations environment? The Next Generation Operations Center, Command Center, Service Management Center or whatever we want to call it must be enabled with these types of technology, but also must prepared to think, operate and respond differently than they do today.

How are you changing? Will you change? Where’s your value proposition? Is it at the front line, second/third line of the support process, at the LoB? Is it about efficiencies in workflow? Do more, with less? Automation? Availability? Becoming proactive? Do you know the real root causes prompting your interests in this technology? What are your vendors doing about it? What is your monitoring tools group doing about it? Should they be doing something different?

Please share your thoughts on how best to operationalize and really recognize value from your investments into these technologies or what you’re doing to address the real root causes of the symptoms this technology addresses.

These topics are all the rage now and have taken center stage in the virtualization, utility, cloud and next generation datacenter discussions. Great stuff, good things to shoot for, but on an even more fundamental level, anyone who’s attempting automation, autonomics, run book automation, etc. without having a solid implementation of the fundamentals of network, systems, application and service management and monitoring in place is, frankly, F-O-O-L-I-S-H.

You’ve absolutely got to have the right level of visibility into the environment first. When some automated activity takes place, you’ve got to know if it was successful, and the impact it may have had on the bigger end-to-end service or application, system or network environment. The only way for this to happen is to ensure instrumentation and eventing is in place, have a consolidated (network, server, application, service, mainframe, distributed, middleware, transactions, virtual, vmware, cloud, etc.) event view with analytics in place to ensure that operations focus is on the right events and a presentation layer that ties everything together into a business service context.

That’s hard to do. It’s no wonder that the things that are first to go are patch management, operating system or core system (CPU, Memory, Disk/Storage) automation activities. They’re low(er) risk, repetitive and time consuming tasks. What group owns these tools? The systems administration groups for the most part. Do they have an end-to-end business service focus? Do they understand (or care) about the impact on the bigger picture? Do the tools used provide eventing, status and insight into what they’re doing? Are they integrated into the broader IT management and monitoring architecture? Would the operations group know how to respond to a “CPU Provisioning Event” if they even got one? Would they know what system, application or business service it’s impacting? Would they know how to prioritize this event against the hundreds of others they are faced with?

What are your thoughts or experiences here? How are you operationalizing investments into automation, autonomics or run book automation beyond the systems administration groups? Can you get useful eventing from these tools? What’s the level of effort required to instrument an “autonomic lifecycle”? What’s being done to align these “sexy” buzz words into the Business Service Management (BSM) story?