devopsy.kinsta.cloud

Tag: CMDB

  • AIOps in Service Management: Removing the Noise

    AIOps in Service Management: Removing the Noise

    AIOps (artificial intelligence for IT ops) refers to the automation of IT operations through AI and machine learning. With every organization working rapidly toward the ultimate goal of digital transformation, there is a natural place for AIOps within service management as a means to automate processes and automatically spot and react to issues in real-time. But what exactly is AIOps, and how does it remove the noise from service management?

    AIOps: Taming the Growing Complexity of IT

    Digital transformation has resulted in IT infrastructure complexity growing at an astronomical rate. The resultant increases in infrastructure data and alarms at the service desk far exceed the capacity of any human to meaningfully read, analyze and respond to them. The infrastructure itself is also constantly morphing and changing, yet service desks are still expected to resolve requests, incidents, and performance issues in seconds – an impossible task, given the volume of data.

    AIOps provides the necessary firepower to address this exponential rise in data, using artificial intelligence to continually monitor and analyze changes in the IT infrastructure in real-time. By combining these insights with service desk automation, organizations can benefit from a closed loop of discovery, analysis, detection, prediction and automation which, combined, bring us closer to the enviable goal of self-healing IT.

    Two Phases of AIOps Implementation

    The implementation of AIOps falls into two phases: discovery and analysis.

    Discovery

    The discovery phase involves uncovering all of the compute, network and storage entities across your ever-changing IT environment and ensuring your configuration management database (CMDB) is always kept up to date. But just knowing what is on your network is only the first step – you then need to determine how each asset relates to, or depends on, each other. This dependency mapping stage requires tracking of dynamic, multilayered relationships between applications and hybrid infrastructure, and creating rich, visual topology maps so that you can immediately see where dependencies lie within the network, and, therefore, where potential bottlenecks or risks reside.

    Analysis

    With your CMDB now kept up to date with automated discovery and dependency mapping, you now need to make sense of this data. After all, data is useless if you can’t use it to make informed decisions. By applying machine learning algorithms to analyze this data, AIOps can identify patterns, spot anomalies and predict future outages.

    Why AIOps in Service Management?

    AIOps has many benefits within the larger service management context. AIOps can:

    1. Support, not hinder, rapid digital transformation – with automatic discovery and dependency mapping, AIOps allow the business to continue to invest in new IT services without upsetting those in operations that need to keep the lights on.
    2. Reduce downtime – with automatic reporting of anomalies, operations can address potential issues before they result in a service outage.
    3. Automatically update the CMDB – An accurate CMDB is the foundation of successful IT operations. If your CMDB is out of date, then you are left trying to solve problems blindfolded. Just make sure your AIOps supports hybrid environments, so it can discover all IT assets from physical to virtual infrastructure, on-premises to public cloud, etc.
    4. Remove noise from the service desk – AIOps helps the service desk to overcome alarm noise and determine which events need their attention by eliminating false positives, performing advanced event correlation, reviewing time-series event playbacks and determining probable root cause.
    5. Actualize self-healing IT – no longer a myth or an IT operator’s dream, self-healing IT can be realized through AIOps. By automatically triggering actions based on the findings of the machine learning engine, AIOps can quickly fix issues or prevent them from happening, whether it’s a network link that’s gone down, an over-utilized disk or a service that simply requires a restart.

    Operations is not known for being a calm and relaxing environment in which to work. When your role is primarily a reactive one, there is rarely time to be proactive. You are bombarded with alarm bells and error reports all day long. How can you tell the difference between a false alarm, an isolated incident or the early indicators of a bigger problem? AIOps, leveraging machine learning, has finally provided IT operations with the tools needed to make sense of this growing barrage of data.

  • The CMDB Is Dead – Long Live the CMDB

    The CMDB Is Dead – Long Live the CMDB

     Many enterprise IT organizations have a configuration management database, or CMDB, in place. These systems are important for overall configuration management, governance and DevOps coordination. Yet, these legacy data repository systems can fall short in our dynamic IT environment. They require manual updating and can’t always support real-time decision-making. Furthermore, we have new requirements since the onset of widespread WFH workplaces. In this article, we talk about the past and current role of the CMDB, how it is evolving and how integrating it with other IT operations systems can modernize infrastructure monitoring and configuration management.

    History Lesson

    Remember the enormous fuss over Y2K? IT execs were concerned that the new century turnover would break their systems, which led to a secondary concern that they weren’t sure what was even on the network. The 2001 release of ITIL v2 best practice led to the notion of a CMDB, which would enable the tracking of every technology asset and its configurations and show the relationship between those assets. But getting all that data in one place proved to be a problem—and one that has persisted to this day.

    Is the CMDB Still Relevant?

    CMDBs have been around for a long time, and they still play a valuable role in the enterprise IT organization. In fact, a CMDB has never been more essential than now. The year 2020 has been chaotic for most IT organizations as employees quickly transitioned to working from home and are using a wide array of personal devices and networks, all of which need to be monitored, maintained and secured. As shadow IT persists and organizations move increasingly toward rapid deployment and release models that incur frequent, ongoing change, governance and control become critical.

    Contrary to what some may think, you can’t safely go faster without a level of control. This is a balance that DevOps practitioners must strike, and it entails a deep understanding of all elements within the IT environment and how they relate to one another. If the enterprise doesn’t have a CMDB (or something akin to it) to provide visibility into infrastructure components, configurations and relationships, the IT operations team is working at a disadvantage. Such lack of knowledge slows down developers—and nobody wants that. Even worse, without always updated, reliable infrastructure data, DevOps teams risk a catastrophic result with each software release.

    Modern CMDB Requirements

    Today’s CMDB is critical for incident management and must be supported by a mature, well-understood change enablement practice in multi-cloud and hybrid environments, yet legacy platforms aren’t designed to monitor systems residing outside of the corporate firewall. More importantly, modern applications are built on containers and ephemeral microservices that appear and disappear frequently. It is nearly impossible for IT staff to manually update the CMDB under such constraints, and the truth is, people weren’t typically doing this regular updating years ago. Today, the only viable way to maintain state and configuration data to support accurate, real-time decision-making is through automation.

    Most CMDBs on the market today lack automation; they still look and act much like a data repository. The appetite for heavy manual work is razor-thin, and IT organizations simply don’t have the people power to do it regardless. Simultaneously, the role of the IT operations professional has evolved dramatically—it is no longer as focused on installing, patching and rebooting systems. Rather, these individuals are now expected to manage applications and platforms in an end-to-end fashion, serving the business with their unique requirements spanning distinct business units and use cases. Therefore, the more we can use technology to reduce the load of traditional incident management tasks and enable operations to be a true partner with development, the better we can serve the business and end customers.

    So, What Now?

    Integrating modern and legacy tools is one practical solution for resolving these issues. Newer IT operations management (ITOM) technologies that incorporate artificial intelligence and machine learning (AIOps) to automate the discovery of assets and topology mapping can bring the CMDB into the modern age. An open ITOM framework for integrations can keep the CMDB always up-to-date, without manual intervention. This enables IT operations staff to focus on optimizing and improving infrastructure for reliability and performance, versus digging into one dashboard after another to make sense of the status quo.

    Understand the requirements and scope of your CMDB. Tracking the configurations of components that are not business-critical only expands on the effort and resources needed to successfully maintain the CMDB, creating waste in the process. Keep it simple and iteratively improve the CMDB over time. Most importantly, get started now. Even seemingly small, simple improvements can have a positive cascading effect down the road.

    IT environments will only get more complex—even though the end goal is simplicity, cost savings and efficiency. To keep pace, enterprise IT organizations will need to rethink the traditional CMDB. By integrating the CMDB with modern IT operations monitoring, management and automation systems, IT operations teams can finally have a reliable repository of data on all of the company’s on-premises assets and multi-cloud resources, while also gaining the ability to automate manual tasks that impair productivity and eventually remediate where appropriate with the right approach to AI and machine learning.

     

    This article was co-authored by Curt Thorin, a solutions consultant at OpsRamp. He has 20+ years’ experience in enterprise IT software and services. Curt can be reached online at LinkedIn.

  • Resurrecting the CMDB Through a Singular Path to Production

    Resurrecting the CMDB Through a Singular Path to Production

    Change consistency (or the predictability of how change is deployed) followed by change transparency (or the visibility into the state of change at any stage in the software development life cycle [SDLC]) are two key benefits of embracing a highly functioning enterprise-class DevOps set of services. Most organizations are attempting to transform themselves from a widely varied manual delivery system to an automated, template-based delivery model that DevOps relies upon.

    Along this journey a key fact soon emerges: We cannot allow “manual” tweaks to our environments and maintain the predictability, visibility or the stability we want. To be truly consistent, process must be fully automated. A process that relies upon human interaction (whether planned or unplanned), is subject to human variability that can impact its success. In short, we do not want a deployment process that has humans coming along after it, to “clean it up.”

    Thus a key principle of DevOps, is that it becomes “the singular path to production.” We want all changes going in to production to have gone through our DevOps systems and processes. Our goal becomes to reduce and eliminate human reliance in every interaction. As an example, we automate test execution, then test evaluation, then test gated change progression. We use “smart” deployment technologies to overwrite what is different in the destination environment, forcing it into compliance with our stated version of changes that “should” be there.

    In effect, we “step on” variations, overwriting them every time we initiate a deployment. This quickly teaches our freestyle engineers who make changes on the fly that their work will get “stepped on” with each new deployment (perhaps daily or hourly). Most engineers quickly get the hint that to preserve their work, they need to include it in the deployment process itself (updating the proper configuration file, or adding the right series of steps in the deployment execution automation itself). Otherwise, they will face a daily onslaught of repetitive tasks that inevitably will overwhelm them.

    In this sense, a properly implemented DevOps system is “self-cleaning.” Paired with an executive mandate to have all change go into production through DevOps, another benefit emerges that may bring the CIO glee. Just a few years ago, IT organizations were bent on the idea of documenting change (therefore understanding it better) through the means of a configuration management database (CMDB). Those projects tended to be large, costly, and doomed to minimal success. Typically, the CMDB effort was great for 90 days after its first instantiation, then over six months its data became “suspect,” then after a year or two its data became prehistoric and close to useless.

    The simple truth is, engineers (of nearly every variety) are toxically allergic to documentation. Asking engineers to have the human discipline of keeping up with documentation is like asking the sun not to shine. No matter what set of inducements is offered, or punishments threatened, the engineer simply remains toxically allergic to documentation and its maintenance (probably a DNA thing).

    Industry tried to solve this problem by producing “discovery tools,” or tools that could determine automatically what our state of change was environment by environment. The idea being that if we ran discovery tools on regular intervals we could at least renew our CMDB baseline from time to time. It was an improvement, but discovery still lacks context for change and often is not thorough enough to generate real value beyond asset location and basic configuration.

    Enter DevOps, which inherently has an artifact database capability to track versions of builds, deployments and releases over time. DevOps understands the need for artifact identification, articulation, compilation and history. Most early DevOps tooling has some form of it built into the products. But this is where a perfect storm becomes possible.

    If our DevOps systems have achieved transparency; that is, if we are able to connect the context of change outlined from ideation (in the business requirements) through production release (including the history of testing, etc.) by version, we now have a great deal of wealth we could plug into a resurrected CMDB. And we could maintain the CMDB automatically (requiring no engineers to have to do manual things to keep it up to date). Our CMDB becomes a repository, or master repository of the artifacts of change we implement through DevOps.

    This is more than just baseline or the ability to establish a “golden copy” of what change should look like. It is the ability to establish “relative” golden copies by development version while it progresses through environments of even highly complex SDLC systems. We have thus increased the value of a CMDB exponentially beyond its use in just production, but can integrate it, into the SDLC process and watch change become documented in real time no matter how fast or how often we move change.

    This should be groundbreaking. Even if the CIO has burned all his funding and political capital on a former CMDB project that has had less-than-desirable results, he or she can salvage what is left of it and quietly use DevOps to resurrect the CMDB, making it an integrated step of moving change. Once the CIO has demonstrated success doing this, he or she can offer this reclamation project to the business and begin exploring ways of creating CMDB valuation to the business (beyond asset location and valuation).

    What emerges is a DevOps-centric CMDB. DevOps, having become the singular path to production, has both insight and context into all change progression and simply updates the CMDB (master artifact repository) as needed automatically. In this way, an integrated CMDB becomes part of the DevOps continuum. And perhaps the greatest benefit or win is the simultaneous recognition of engineer’s allergy to documentation already baked into this sustainable solution. I would call that win-win—or, at least, a recognition of reality.

    To continue the conversation, feel free to contact me.