devopsy.kinsta.cloud

Tag: ITOps

  • PagerDuty Signals Commitment to Adding Generative AI Capabilities

    PagerDuty Signals Commitment to Adding Generative AI Capabilities

    PagerDuty has signaled its intention to add generative artificial intelligence (AI) capabilities to its cloud platform for managing IT operations via integrations with large language model (LLM) providers that it will disclose at a future date.

    These capabilities will make it possible to invoke natural language via PagerDuty Operations Cloud to automatically generate status updates, create drafts of incident postmortem reports and even co-author workflows in any programming language to automate remediation of an issue.

    Damon Edwards, senior director of product for PagerDuty, said as AI continues to evolve, the goal will be to minimize the need for human involvement as much as possible. That doesn’t mean there won’t be a need for humans to be involved, but it does mean that many rote tasks associated with managing an IT incident can be automated, he added.

    For example, the reports that are run to determine the root cause every time there is an incident can be automated, noted Edwards. In addition, summarizations of status reports or postmortems after incidents were resolved can be made readily available to any member of an IT team on demand, he added.

    Those capabilities will also make it easier to onboard new members to an incident management team as required, said Edwards. Today, it’s difficult to add new members to a team after an incident has unfolded because it takes time to bring them up to speed, he noted.

    In addition, generative AI also makes it easier to capture a lot of the tribal knowledge within an IT organization that would otherwise disappear when staff either leave the company or shift roles, said Edwards.

    The generative AI additions to the PagerDuty platform extend an artificial intelligence for IT operations (AIOps) capability that PagerDuty made available this spring. The PagerDuty AIOps platform leverages the data model embedded in its incident management software to reduce the amount of time required for an AI platform to learn how an IT environment operates and begin surfacing valid recommendations to optimize workflows.

    It’s not clear at what pace AI will be adopted within enterprise IT organizations, but it is rapidly becoming pervasive. Each DevOps team will need to decide the degree to which they can rely on AI to manage IT processes, but as IT processes become more complex, there is a clear need for AI to navigate all the dependencies that exist in an IT environment. As more routine tasks are automated, however, there will also inevitably be a realignment of roles and responsibilities within an IT organization. The overall goal is not so much to eliminate IT staff as much as it is to enable them to manage IT environments at a much higher level of scale.

    In the meantime, DevOps teams need to plan for not only what is possible using generative AI today but also tomorrow. After all, there’s not a lot of point in training someone to take on a new task if that task is automated a few months from now.

  • Five Tips for Moving IT Ops to DevOps

    Five Tips for Moving IT Ops to DevOps

    The era of siloed development and operations functions is rapidly coming to an end. The concept of DevOps has already closed the gap between IT and developers, but as I speak with customers around the globe, one theme continues to arise. Many systems administrators are ill-equipped to handle the shift from IT Ops to DevOps and, in some cases, don’t even know the right questions to ask to ensure they are planning accordingly.

    Having the appropriate equipment and software in place means nothing without people trained and ready to implement the shift from IT Ops to DevOps. As IT strives to support and protect developers continuing to innovate with wild-west-style creativity, how can we empower them with the tools and knowledge to ease the transition? This starts with asking the right questions, but requires IT to think about new things: Automating processes, revamping config management, building efficiencies in data orchestration and standardizing a set of APIs with enterprise-level protections.

    Asking the Right Questions About DevOps and Infrastructure-as-Code

    Enterprises need to look holistically at how infrastructure services are created, delivered and managed. Continuing current practices, such as manual provisioning complicated by different interpretations of imprecise instructions, will continue to lead to snowflake architectures and brittle systems. Organizations must modernize or replace this existing infrastructure to exploit cloud architectures and implement true platforms, actualizing the promise of the cloud.

    Infrastructure-as-code is an underlying framework that removes the manual process of managing and provisioning resources and opens doors to enabling DevOps. Using code to define the infrastructure configuration means that there is greater consistency between platforms. That consistency allows IT to seed the agile processes, methods and technical approaches needed to evolve a DevOps culture.

    To get to a point where infrastructure-as-code is facilitating a DevOps culture, it’s important for IT Ops to understand how to develop an early-stage continuous delivery and deployment pipeline. They also need to begin to seed practices and values native to DevOps for software engineering principles and practices with IT Ops. It’s also important to define success criteria–referred to as the “definition of done” in agile and begin to think about how to implement the infrastructure-as-code using DevOps best practices.

    Don’t Expect Developers to Become Expert Sysadmins

    Developers don’t want or need an extra layer of oversight or management, nor do they want to ask for permission before doing what they do best: Innovating. DevOps can more rapidly provision compute and storage resources and provide infrastructure-as-code while automating DevOps processes, empowering developers to become an innovation engine for their businesses.

    So much of what we’ve seen puts pressure on IT to be proactive when protecting developer cycles in containers and beyond. The NSA, as well as other industry data protection companies, offer tips for IT to stay ahead of these threats, but manual patching and scanning is not only handcuffing IT but stifling innovation in DevOps. The challenge is that IT can’t move as fast as developer cycles and often lose sight of what developers are putting into containers or other IT environments.

    While global data protection restrictions might have an impact on things like machine learning and AI from a consumer experience standpoint, it does not affect how IT might use these technologies to automate protection. It’s also not about extending protection to developer workloads, it’s about having an environment that recognizes and automates protection against threats in all environments. This way, developers and IT don’t have to become system admins or data protection experts. They can focus on the innovation at hand.

    Config Management is Critical to Empowering Developers

    As we continue to prioritize the automation of processes in the developer environment, it’s also important to consider how to move beyond just automating protection and infrastructure while allowing IT Ops to still have an eye on identifying, documenting and tracking changes in the DevOps stack. To do this, DevOps should look to configuration management tools to help manage and automate the architecture through strong community support, customization, scalability and the simplification of complex configurations.

    These tools, such as Ansible, Terraform, etc., can be deployed to meet specific needs and preferences. The point is, once you create infrastructure-as-code, you need a way to configure and manage it that fits the model that’s appropriate for your business. While you can use IaC to configure and manage, you still need to determine how to best implement automation and configuration in the most appropriate environment.

    Data Orchestration Eliminates Repetitive Cycles

    Data orchestration tools bring all data together regardless of where it originates or its format. An ecosystem that can collect data efficiently and convert it to a format that is easily understood by any and all endpoints is critical to the app development process. There’s no need to iterate at multiple levels, on multiple platforms or in different environments. IT can enable developers to innovate and learn from any environment, data warehouse or platform and build applications that can do the same.

    In the same way data orchestration can drive efficiency, there are additional benefits. Automating the collection, analysis and formatting of data saves IT countless hours of doing these processes manually. While there are obvious cost benefits, there are also a few other important benefits.

    To allow developers to continually innovate at a wild west pace, IT/DevOps must also ensure they can meet data privacy compliance and governance policies. Data orchestration allows businesses to delete or store data based on policies preset in the environment. It also allows businesses to ensure that internal policy is upheld throughout the development process. Orchestration then takes that data and makes it workable so that any iterative process can be applied without fear of bottlenecks or additional cycles.

    Standardized APIs Trump Those Created by Unaffiliated Coders

    Today’s developer profile expands far beyond the enterprise. In fact, according to Developer Nation, we can expect a whopping 45 million developers in the world by 2030. These numbers don’t include the unaffiliated coders working out of their basements or garages. That’s not to say that creativity isn’t appreciated or eventually adopted by industry leaders. But the code and software created don’t necessarily abide by enterprise governance and privacy standards. Yet we continue to see wild west developers pulling in anything and any kind of API to ensure it meets the needs of the next business application they are developing. How does IT police this?

    They don’t have to. For IT/DevOps to identify a set of APIs that meet business imperatives and certify them for use within the organization is imperative. Think about a scenario in which a developer has not only a comfortable environment to sit in without learning new skills but also an environment that automates protection, orchestration and gives them a preset library of helpful and open APIs. Businesses can begin to focus on delivery rather than policing and upskilling developers to work within the confines of the business ecosystem.

    As data continues to flow in and out of organizations and more data is being created and stored at the edge, a DevOps culture built for tomorrow’s developers is critical. These tips are a great starting point to ensure you’re installing a future-proof culture of innovation. What are some of the obstacles you’ve faced and overcome during the transition to DevOps?

  • How Does IT Management Govern EverythingOps?

    How Does IT Management Govern EverythingOps?

    The number of tools engineers use to provision software architecture in the cloud is starting to get a little out of hand. There are many competing ways to do one thing. Most often, people simply adopt a new tool to solve a DevOps problem in the moment, not always considering the longevity of the solution or how other departments are handling it. This could result in fragmentation and technical debt, making it difficult to find consistency and increase speed simultaneously across all company divisions.

    I recently interviewed Jeff Kukowski, CEO, CloudBolt Software, to explore why these issues persist and how executives should approach cloud management within their organizations. According to Kukowski, many flavors of Ops now permeate large companies. Different approaches often exist per department or interdepartmental, with teams using various software stacks.

    According to Kukowski, a new frame of mind will be necessary to remain agile in the new cloud order and to address this state. Doing so will require organizations to erode false dichotomies around ownership and IT governance.

    Everything’s Going Ops

    At this point, most large suites of digital services have adopted a complex hybrid and multi-cloud modality. And many teams have embraced their own unique form of DevOps to get a handle on the management difficulties of delivering software and maintaining reliability for microservices architectures. Different groups pulling in various directions create an ongoing battle of EverythingOps, explained Kukowski.

    You can think of it as separate Ops approaches emerging around different business functions. For example, FinOps is emerging to control spending, ITOps is about delivering services, DevOps is improving release fluidity and DevSecOps aims to bring security to the forefront of the release process. Lastly, BizDevOps is about increasing observability for business outcomes.

    At a high level, CIOs have committed to digital transformation to move quicker. Yet the problem now is “battles between different Ops can easily lead to broken IT governance,” said Kukowski. This tension introduces several false dichotomies, he explained. In addition to slowing agility, a lack of DevOps unity eschews reusability, contributing to waste and increased IT expenses, said Kukowski.

    Solution: Shifting Governance Left

    There is a belief in IT that true innovation will come if you only give engineers the keys to use anything they want. While that may be true, without better leadership with regard to the basics in this new cloud order, some things can get out of control very quickly, Kukowski warned. Instead, he argued that built-in guardrails for provisioning tools are necessary. “We have too many tools—we need better frameworks to tie this together.”

    Not only would increased cloud governance help tie together disparate tooling decisions, but Kukowski argued it also can reduce the cognitive load necessary to onboard each tool. “Shifting left will increase speed—it won’t slow people down,” he said. Contrary to popular belief, he said that shifting guardrails left can have the effect of increasing speed, which may greatly outweigh the negatives of shackling developers to a single approach.

    CloudBolt predicted siloed management will shift to organizational governance around tools in the coming year. But it’s not only the tooling decisions that require forethought, “it’s the leadership and cultural approach,” said Kukowski. A common area where greater leadership is required is in tagging workloads for applications, he said. “It’s not being done well anywhere.”

    Or, consider containerization. Containers have become fundamental to most modern cloud technology stacks, yet, the cognitive load required to deploy, configure and run a contain remains quite high, explained Kukowski. Do you allow every developer to custom-code each container, or do you enable a self-service repeatable provisioning process? If standard code is not being reused, you’re not getting speed or governance, he explained. Furthermore, with green IT initiatives becoming a priority, companies should be looking at ways to reuse processes and reduce waste where they can.

    Final Thoughts: Shift Left, Automate and Reuse

    For a cloud-native company, the emphasis is constantly on speed and growth. And engineers are absolutely driving this focus and the resulting innovation. Yet, this innovation can’t come at the expense of bringing all departments onto the same level of innovation. “Innovative stuff in the cloud can’t be separated from governance, ESG and security,” said Kukowski.

    A big hurdle of tomorrow’s cloud management will be identifying and uniting these islands of automation, these pockets of tools and preferences that differ between departments. It will also require a different frame of mind across divisions. “There’s a difference between solving the problem for the task and solving the problem for reuse and speed,” explained Kukowski. Delivering on reuse and speed will require less bespoke DevOps automation and better foundations for solving future problems, he said.

    “Shift left, automate and reuse—people shouldn’t have to touch it. That’s the thinking that needs to be applied to this new cloud order,” said Kukowski.

  • A Pro Football Approach to Agile Vs. DevOps

    A Pro Football Approach to Agile Vs. DevOps

    Enterprises and professional football teams have a lot in common. The pressures of being more agile, more resilient while ensuring performance is felt both on and off the field. For CIOs, surviving and thriving requires a serious focus on operations tied to business mandates and growth.

    I am frequently asked questions around infrastructure and operations (I&O) with organizations looking to solve ITOps, DevOps and DevSecOps challenges.

    • How do we shift from legacy ITOps models to transformative digital operations?
    • How do we align process, people and tools for closer integration, consolidation and correlation?
    • How are we structured as teams across functions—ITOps, DevOps, SecOps?
    • How do we transform to analytics-driven operations at speed and efficiency?

    Historically, Agile and DevOps teams face off on the IT playing field as adversaries; both sides want to advance their plans, execute plays and reach the end zone. Disconnects happen when teams are not aligned, goals are not defined and resources are constrained.

    To effectively deliver digital services, teams must focus on the essentials of clear communication, unified culture and measures to ensure resiliency, performance and availability if they are to be effective.

    Traditional I&O teams often operate independently, and knowledge is not shared nor available to cross-functional teams. Attempts to respond and resolve critical incidents can take longer. With DevOps or even DevSecOps, the ideal is for groups to align across functions by breaking down silos of tooling and responsibility.

    In a hybrid ops environment, a lack of integration and coordination between DevOps roles can easily misalign efforts and priorities. Whether it’s hybrid in terms of IT environment or hybrid in support model, there are unique challenges that must be addressed. Not being able to huddle around the same data sets while troubleshooting incidents poses a huge challenge when implementing proper analytics comes into play. Legacy IT operations management (ITOM) tools simply cannot support DevOps’ use of cloud-native services nor support remote IT teams working globally.

    For successful DevOps and traditional Agile teams to coexist and be successful, IT leaders need to change existing mindsets and implement new practices in order to scale.

    • DevOps and ITOps groups have to feel supported by the entire IT organization.

    Often DevOps starts as an experiment with a small group of people working on one application. Everyone in IT, from the leaders to IT workers, needs to understand what the end goals are for integrating new methodologies. Deep realization sets in when DevOps finishes a project and pushes to production which is still supported in traditional ITOps models. It becomes obvious that operations needs to adapt to frequent change.

    • Plan and implement DevOps practices to avoid disruptions.

    With legacy systems still in practice for delivering digital services, DevOps teams cannot disrupt critical day-to-day operations by driving new support models without taking into account migration considerations. Instead, teams will need to work in a hybrid model using application development delivery methods.

    • Collaboration and planning tools are essential.

    The use of collaboration and planning tools alongside automation capabilities is essential in hybrid organizations. Start by automating alerts to generate tickets for the appropriate team(s) to handle versus having Level 1 support process all alerts independently.

    • Build or buy scalable data analysis systems.

    These systems will aggregate and correlate data across infrastructure and digital/cloud-native technologies to deliver contextual insights to problems and provide corrective steps to resolve them.

    Scaling and modernizing operations and creating agile practices is an ongoing process that needs constant planning, testing and adapting. Streamlining DevOps and ITOps processes using automation starts the process as teams begin to work together versus working in traditional silos.

    For winning football franchises, dynasties weren’t built in a single season; the same is true for your digital ops transformation. It takes challenging the status quo—taking a hard look at the deeply embedded ways ITOps has always been done—and reimagining the whole process focused on data-driven digital operations.

  • BMC Acquires StreamWeaver to Advance AIOps Strategy

    BMC Acquires StreamWeaver to Advance AIOps Strategy

    BMC has acquired StreamWeaver, a provider of a platform that makes it simpler to capture streaming data in real-time, as part of an effort to extend the BMC Helix IT operations platform infused with artificial intelligence (AIOps). Financial terms of the transaction were not disclosed.

    Margaret Lee, general manager and senior vice president for digital service and operations management for BMC, said StreamWeaver brings with it a wide range of integrations with multiple data sources that BMC will use to both train AI models and improve overall observability. While connecting to data sources is relatively straightforward, the challenge now is collecting that data in real-time in a way that is easily repeatable for IT operations teams, noted Lee.

    In general, AIOps continues to gain traction as IT environments become increasingly complex. Most IT operations teams are not going to be able to manage highly distributed computing environments without augmenting their IT staff with some AI, said Lee.

    Naturally, many rote tasks that were once performed manually by IT operations professionals will become increasingly automated. However, there will always be a need for IT personnel, noted Lee.

    Arguably, there may come a day when IT professionals will not want to work for organizations that don’t have an AIOps platform in place simply because the tasks assigned to them would otherwise be considered archaic, especially if they involve a series of tedious tasks that not many IT professionals really want to perform.

    At the same time, AIOps should reduce overall risk by making it easier for IT operations teams to proactively identify issues before they disrupt an application service. That’s especially critical as IT environments—increasingly with microservices-based applications constructed using containers—and serverless computing frameworks are being deployed with greater frequency alongside legacy monolithic applications.

    BMC has been making a case for AIOps as far back as 2017. However, since then, a wave of startups and IT operations incumbents have either built an AIOps platform from the ground up or updated an existing platform with AI capabilities. It’s difficult to assess which vendors are now ahead in terms of the AIOps race, but one thing that is certain is that IT organizations now have plenty of options.

    From a cultural perspective, however, not every organization is entirely comfortable with AIOps. While some IT professionals remain skeptical, others view AI as an existential threat to their existence. Most IT teams are also concerned about the potential impact any flawed AI model might have on IT operations—it’s one thing for a human to make a mistake, but an AI model making a mistake at scale could be catastrophic.

    There are few IT organizations that are embracing AIOps across the board, but most do recognize that AIOps platforms, in one form or another, are inevitably here to stay. After all, machine learning algorithms never forget anything they learn. Nor do they ever take a day off or decide to leave when offered higher pay. The challenge is figuring out exactly where the interface between IT staff and algorithms is going to be—not just today, but also in the near future.

  • Achieving Reliable Observability Part 1 – Making Cloud-Native Observability More Robust

    Achieving Reliable Observability Part 1 – Making Cloud-Native Observability More Robust

    I was having a conversation with a CxO level customer as part of an AIOps/Observability workshop, and from what I could tell, most are confused about how to properly operationalize cloud-native production environments – especially the monitoring/observability portion. Here is how the conversation went.

    “Andy, we are thinking about getting [vendor] to use for our observability solution based on your recent research. What do you think?”

    “Well, I don’t want to endorse any specific vendor, as they are all good at what they do. But let’s talk about what you want to do, and what they can do for you, so you can figure out whether or not they are the right fit for you.” The conversation continued for a while, but the last piece is worthy of being called out specifically.

    “So, we will be running our production microservices in AWS in the ____ region. And we are planning to use this particular observability provider to monitor our Kubernetes clusters.”

    “Couple of items to discuss. First, you realize that this particular provider you are speaking of also runs in the same region of the same cloud provider as yours, right?”

    “We didn’t know that. Is that going to be a problem?”

    “Not particularly. However, you may get into a ‘circular dependency’ situation.”

    “What is that?”

    “Well, as an enterprise architect, I always call for separation of duties as a best practice. For example, having your developer testing the code is a bad idea, having your developer figuring out how to deploy is a bad idea. In much the same way as when your production services run in the same region as your monitoring software – how would you know about a production outage if the cloud region takes a hit, and your observability solution goes down at the same time your production services do?”

    “Should we dump them and go get this other solution instead?”

    “No, I am not saying that. Figure out what you are trying to achieve and have a plan for it. Selection of an observability tool should fit your overall strategy.”

    For those who don’t understand the above conversation, here is the reason why this scenario could be a problem.

    Coming from an enterprise architecture background, we were taught, as a best practice, to operationalize production systems to avoid circular dependencies. This includes not having two services depend on each other, or not to colocate monitoring, governance and compliance systems as part of the production systems themselves. If you were to monitor your production system, you would do it from a separate and isolated sub-system (server, data center rack, sub-net, etc.) to make sure that if your production system goes down, the monitoring system doesn’t go down, too.  The same goes for public cloud regions – although it’s unlikely, individual regions and services do experience outages. If your production infrastructure is running on the same services in the same region as your SaaS monitoring provider, not only won’t you be aware that your production systems are down, but you also won’t have the data to analyze what went wrong. The whole idea behind having a good observability system is to quickly know when things went bad, what went wrong, where the problem is and why it happened so you can quickly fix it. You can check out this blog where I explain this in detail.

    The best practice would be to either:

    1. Consider an observability solution that runs in a different region than your production workloads. Better yet, consider something that runs on a different cloud provider altogether. Although it is exceptionally rare, there have been instances of cloud service outages that cross regions. The chances of both cloud providers going down at the same time would be slim.For example, if the cloud region goes down (a region-wide outage in the cloud is quite possible, and seems to be more frequent of late), then your observability systems will also be down. You wouldn’t even know your production servers are down to switch to your backup systems unless you have a “hot” production backup. Not only will your customers find out about your outage before you do, but you won’t even be able to initiate your playbook, as you are not even aware that your production servers are down.
    2. Consider having your observability solution in a different location/region, yet still close enough to your production services so latency is very low. Most cloud providers operate in close proximity, so it is easy to find one.
    3. Another option is to get a solution that gives you deployment flexibility. For example, there are a couple of observability solutions that allow you to deploy it in any cloud and observe your production systems from anywhere – both in the cloud and on-premises.
    4. You can also consider sending the monitoring data from your instrumentation to two observability solution locations, but that will cost you slightly more. Or, ask what the vendor’s business continuity/disaster recovery plans are. While some think the costs might be much higher, I disagree, for a couple of reasons. First, because monitoring is mainly time-series metric data, so the volume and the cost to transport is not as high as logs or traces. Second, unless your observability provider is VPC peered, the chances are your data will be routed through the internet even though they are hosted in the same cloud provider. Hence, there will not be much more additional cost. Having observability data, all the time, about your production system is very critical during outages.
    5. A very commonly overlooked consideration is monitoring your full-stack observability system. While it is preferable to have the monitoring instance in every region where your production services run, it may not be feasible either because of cost or manageability. On such occasions, monitor the monitoring system. You could do synthetic monitoring by checking the monitoring API endpoints (or do random data inputs and check to ensure it worked) to make sure that your monitoring system is properly watching your production system. Better yet, find a monitoring vendor that will do this on your behalf.

    When/if you get the dreaded 2 a.m. call, what is your plan of action? Just think it through thoroughly before it happens and have a playbook ready, so you won’t have to panic in a crisis.

  • Accelerating AIOps with the Mainframe

    Accelerating AIOps with the Mainframe

    AIOps uses artificial intelligence by combining big data, analytics and machine learning to enhance IT operations. To successfully adopt and scale AIOps, it is critical for enterprises to add the mainframe to the equation. Adopting AIOps requires a holistic approach focused on business processes and workflows. The resiliency of a workflow depends on the health of every link in the chain. In order to be successful, you need visibility and insight throughout the entirety of the workflow.

    In this interview, Maneesh Goyal, AIOps Offering Management program director at IBM, explains how AIOps is changing IT operations and why the mainframe is so critical to the success of AIOps adoption.

    Maneesh is a DevOps expert with over 24 years of experience leading operations and management across hybrid and public cloud environments, including IBM Z. He is also one of the distinguished speakers presenting at Open Mainframe Virtual Summit, along with Mürsel Taşgın, mainframe systems manager at Credit Bureau of Turkey. During their session, Maneesh and Mürsel will discuss how organizations such as Credit Bureau of Turkey are accelerating AIOps by leveraging the wealth of operational data on IBM Z to make quick and accurate decisions in order to improve resiliency.

    Learn more about IBM’s AIOps framework and assessment to determine the next step for your business by attending Maneesh and Mürsel’s session at Open Mainframe Virtual Summit on Feb. 11. To check out the full agenda or to register for free, visit the Open Mainframe website.

  • Operations Model: DevOps, NoOps, AIOps or None of the Above Ops?

    Operations Model: DevOps, NoOps, AIOps or None of the Above Ops?

    Within an organization, an operations model must be fit-for-purpose and be able to adapt as business needs change. At the same time, changing technology necessitates an advancement in how an organization operates. Small and medium-sized enterprises are faced with the difficult choice of how much to invest in operations and which approach to choose. In light of the numerous possibilities, companies need to identify the right upgrades for their needs. For instance, should a company now using a traditional operations model invest significantly to reach DevOps? Or would AIOps better fit customers’ needs? Is NoOps an option?

    There is no “correct” answer. Each option comes with pros and cons and important budget considerations. That is why every business needs to evaluate the appropriate system for its products and its customers with three concepts in mind: cost, goals and experimentation.

    Operations Models

    Traditional IT operations (ITOps) is the process of designing, developing, deploying and maintaining the infrastructure and software components of a specific product or application. It also ensures the customer experience is delivered through traditional means of support such as tickets and escalated paths for resolutions.

    DevOps is a process for accelerating the delivery of features to the application or product infrastructure in a consistent model with less human intervention, while also providing a better quality product through automation in the software development life cycle.

    An AIOps process introduces data science into the operating model by learning the behavior of the systems, scaling according to the needs of a platform (both infrastructure and customer usage of the platform). It expands the horizon of DevOps through the introduction of machine learning, focusing on data generated from the hardware and software systems, and allows organizations to grow organically based on demand.

    NoOps, although the name suggests otherwise, is an advanced approach to managing IT operations through the mindset that everything is derived as development. This model is best applied with startups and companies with high technological maturity.

    Typically, these companies have advanced skill levels to deliver the best experience by adapting to the new industry trends of both software and hardware maintenance practices. NoOps is at the opposite end of the spectrum from traditional operations, and it’s largely a theoretical concept at this point.

    NoOps is a fully automated, cloud-based approach that eliminates the operations team, aside from an integrated team focused on life cycle. The self-managed system requires resiliency and a high level of maturity with fail points that have already been addressed. NoOps, or high maturity structures, will also provide quick learning on drawbacks, customer and product needs. However, moving toward a self-maintained system requires upkeep for advances and innovation.

    Invest in an Operations Model to Reach Higher Levels of Maturity

    The first factor to consider in evaluating an operational approach is cost. Each level of IT maturation is gradual, incremental and expensive. Costs vary depending on the size of the company and the type and number of products. A small company that seeks to move from a level 2 to 4 maturity would need to make a significant financial investment.

    Some questions to consider when looking at operations model upgrades include:

    • Does this make sense for the business?
    • Will the investment allow for scaling?
    • Will it increase customer loyalty and trust in the brand?

    Next, it’s important to consider overarching goals and brand identity. The appropriate level of maturity might depend on the company’s value proposition. If, in the company’s vision, technology is at the heart of its journey, the company needs to invest, at a minimum, in a DevOps operating model to have the competitive edge to grow the business and meet its needs. If the company’s vision is to retain existing business and gain customers through continued investment in innovation based on the trend analysis of their core business, then AIOps will have the best ROI. If the company’s vision, culture and mission are intertwined with technology, adapting to NoOps is the right move.

    Know the Product, Customer and When to Halt

    Still, it’s important not to overreach with an operations model that might not fit the customer. To make a sound decision for the organization, it is important to understand the model, the product, customer base and when to halt an operational model and invest in a new one. The leadership team needs to ask how adaptable its end users are before implementing changes. Take, for instance, the poor consumer response to replacing live customer service representatives with automated features. Some end users were not prepared to adapt to the massive change in the platform or service offerings this move entailed.

    Product-driven businesses often don’t see investing in new operations models as worthwhile. This mindset can result in continual churn that creates a backlog and increased operating costs for maintaining systems and services. Another important consideration in deciding which operating model meets the company’s needs comes through experimentation. That is because finding the right operating model for an enterprise can’t be done with a cookie-cutter approach. The point is to maintain the existing quality and productivity while investing in outcomes that will garner more trust and confidence in the company. If you do this right, the end user will appreciate the changes, and the company will outperform the competition.

    Allow for Operations Failure

    Enterprises should expect failures during experimentation with different models and plan to pressure-test an advancing model for the cracks that will emerge. It is important to invest in failure to understand why and how the model did not perform to expectations. Those failures provide valuable insight and important data, result in significant learning about products and customers and help you know what to improve or modify going forward.

    An operations model serves as the backbone for any business that wants to grow. Smart operations investments will ensure adaptability, competitive advantage and customer loyalty. But there’s no one-size-fits-all, easy-to-follow recipe for each enterprise. Whether the investment results in AIOps, NoOps, DevOps or traditional operations is unique to each organization and needs to be calculated with the brand, customer and end goal in mind.

  • Are We Nearing the End of IT Service Outages?

    Are We Nearing the End of IT Service Outages?

    Over the last two decades, the evolution of IT has been more like something a revolution—in some cases, the transformation even unpinning real-life uprisings. Today we’re acutely aware of advances in technology and the internet, particularly as the global COVID-19 pandemic creates a sweeping reliance on tele-everything and online commerce to sustain companies’ livelihood.

    The current surge in online traffic underscores the massive strides made across IT, ensuring critical support functions largely go uninterrupted—quietly impacting millions of lives. Behind the scenes, ITOps teams continue working to ensure the customer experience is resilient and incidents are addressed even before end users notice an issue. The irony of these seamless digital experiences, though, is that the delivery is built on escalating complexity. Providers seeking agility, speed and efficiency are increasingly adopting virtualization, microservices, containerization and cloud-based services. These capabilities often meet their designated needs, but the trade-offs can be costlier than expected.

    IT Complexity Demands Smart, Machine Intelligence

    The industry has rallied around AIOps, looking to AI and machine learning to scale to modern complexity. The goal is to evolve from human-driven monitoring and analysis to automated detection and remediation. The human inability to keep up with service alerts derived from machine-driven operations has created a gulf between machine speed and the traditional, event-correlation approach to troubleshooting.

    The issue is clearly—and commonly—illustrated by the war room-style positioning assumed when a service degradation occurs and ITOps teams are besieged by demands for situation reports, impact assessments and projected resolution timelines. Amid a “sea of red,” when the operator has no idea which of the volumes of trouble tickets to work on first or where to focus attention, it’s undeniable that events correlation is wholly inadequate in navigating the modern-day minefields of data exhaust. It’s like diagnosing an illness solely by taking a patient’s temperature.

    Applying advanced AI/ML will improve the thermometer, but it won’t fundamentally improve the patient’s diagnosis. Similarly, it’s much more promising to work through service interruptions by taking a holistic approach, tracking and connecting behavioral attributes and anomalies across the IT estate instead of solely relying on event data.

    Behavioral correlation provides a deeper, more contextual understanding of what’s happening at the service level, starting with dynamic baselines of “normal” activity levels upon which ML is applied to detect and flag anomalies captured across a broad variety of real-time data. With an aggregated, service-level topology, it’s much easier to assess service health through availability and risk, so that decision-makers can prioritize what’s most pressing and visualize potential business impact.

    Traversing New Realities: Technology as a Front-Line Offense

    As the global COVID-19 pandemic continues to transform how people live and work, it’s clear that technology is the most common and often the most important tool in moving forward. By now most of the workforce has straightened out the initial kinks in telework and figured out general best practices. With some sense of stability now in place, leaders are shifting their focus to ensuring business continuity and instituting the necessary infrastructure to sustain new operational models indefinitely.

    In organizations where digital transformation is already underway, adopting new tools and protocols will benefit from foundational support. Companies and agencies already making strides in harnessing IT to boost operations and outcomes will already be on their way to achieving better visibility and improved efficiency. Implementing behavioral correlation will, in those cases, apply the power of ML to aid in faster root-cause analysis and resolution—and a better overall customer experience.

    That’s not to say that organizations less mature in their digital transformation won’t also benefit from eschewing the ineffective methodologies of event correlation and reactive ITOps. By evolving beyond legacy systems of piecemeal products and services, IT teams instead can leapfrog ahead to sophisticated analytics, data synthesis and comprehensive modeling that monitors for and detects anomalous activity—correlating broader behaviors, not just events. By jettisoning the focus on events and instead incorporating behavioral correlation into IT service, troubleshooting and remediation become fluid.

    Amid seismic shifts in the demands on IT services, it’s more crucial than ever to deliver reliable services and capabilities. That means getting to the root causes of problems quickly and resolving them faster—a feat that’s now a reality through the integration of service metrics and IT automation.

    The world of IT has changed dramatically over the past 10 years, and especially in the past few months. Traditional processes and tools are inadequate to manage the speed and complexity of the modern IT environment. A new era is arriving, and not a moment too soon.

  • Fostering Better Collaboration Between ITOps and Security Teams Should Be Top Priority

    Fostering Better Collaboration Between ITOps and Security Teams Should Be Top Priority

    Last year, the average business lost $13 million to cybercrime, which is 12% more than in 2017 and 72% more than in 2014. When Tanium recently asked IT decision makers how they planned to reduce that risk in 2020, they reported making multi-million dollar investments across operations and security. Over the last two years, they increased operations budgets by 11% and allocated 18% more funding to security teams.

    However, despite massive budget increases, both operations and security teams continue to struggle. Only half of the teams that Tanium surveyed said they had full visibility into their environments’ vulnerabilities and risks (51%), and less than half said they had full visibility into all of the hardware and software connected to their networks.

    Businesses are investing more in tools than ever before, but the issue isn’t more investment — it’s the right investment. “More tools” aren’t bringing siloed IT teams closer together, and aren’t achieving the kind of total visibility and control of all endpoints needed for effective risk mitigation.

    Here are some ways to reconsider the crucial collaboration between IT operations and security teams.

    Find Areas to Align

    While just 27% of the enterprises we consulted on these issues would describe their IT teams as “embedded,” as many as 67% said that coordination among teams is extremely challenging. Aligning the security and operations teams is one way to overcome this challenge. Different teams using different tools and receiving different data sets have little room for compromise, but teams united by a common toolset are not only more likely to collaborate; they are also better resourced to mitigate risk and protect valuable data. As teams do away with the point tools and invest in coordinated, platform-based solutions, their ability to easily verify the quality of their data, trust their vulnerability scans and remediate threats at scale will significantly improve.

    Prioritize Visibility Across the Environment

    While most IT decision makers (80%) believed they could instantly act on the results of their own vulnerability scans, fewer than half (49%) thought they had full visibility into all the hardware and software assets. But without full visibility, the vulnerability scans are merely good enough, and unable to account for areas managed by other teams. That false confidence is even worse in IT departments that have a rift between security and operations.

    If businesses fail to gain a view of the entire environment, it could take them two weeks longer to patch IT vulnerabilities (37 business days versus 27.8 business days for teams with a healthy relationship). By implementing an end-to-end view of the entire environment, both teams will be able to gain the visibility of the computing devices they need to protect organizational data.

    Reduce Complexity Between Teams

    More tools lead to a more complex environment. Tanium’s research showed that IT operations and security purchased an average of five new tools each within the last two years, and large organizations reported using as many as 40 to 50 point solutions. It’s no wonder why this happens: As new problems emerge, each team seeks a new solution based on that individual problem, ultimately creating an environment too difficult to manage. To keep an organization nimble and responsive, ITOps and security must work together to select solutions that are capable of solving the range of problems that both teams face, and agree on what data is most important.

    Create a Culture of Improved IT Hygiene

    As many as 80% of the organizations we spoke to said that maintaining IT hygiene was the most challenging task for IT operations and security teams. Once the entire department begins to prioritize the fundamentals, response times will improve and prevention and detection methods will sharpen.

    Conclusion

    Businesses that do not take these steps are vulnerable to disruption. It is essential that IT operations and security teams unite around a common set of actionable data and are empowered to ask questions about the state of every endpoint across the enterprise, retrieve data on their current and historical state, and execute change as necessary. These teams must come together from day one to maintain performance and security within their organizations — or continue to face the threat of cyberattacks, outages and other business-crippling disruptions.