 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
The success of digital transformation initiatives hinges on organizations’ ability to streamline software development and delivery pipelines.
It’s key to ensuring products get to market fast with guaranteed high quality and security standards. Site reliability engineering (SRE) teams play a crucial role in this, but manual processes often hinder their productivity. These processes range from reviews of software test results to triaging and resolving issues in production. Critical observability data that provides insight into software quality and security is often siloed across multiple tools and teams. And monitoring solutions can’t keep pace with the change in modern delivery environments.
Observability-driven automation is becoming essential to overcoming these challenges and ensuring the future success of software delivery. According to our 2022 “State of SRE Report,” 85% of organizations say their ability to scale SRE will depend on automation and artificial intelligence (AI). By integrating automated configuration, collection and evaluation of observability data into delivery pipelines, SRE teams can enhance decision-making and become more productive, using automation to drive speed, efficiency, reliability and security.
So how do SRE teams kick off observability-driven automation efforts? Here are five steps to get started.
First, SRE teams need to quickly understand which releases are running at any moment in time, where they’re running and what versions they are. It’s therefore essential to have a solution that provides automatic version-detection capabilities. This will help the SRE team answer important questions, including the following:
With visibility into which versions and software an organization runs, SREs can then work with the various owners of each application to define SLOs to benchmark performance. SLOs provide a common language that enhances collaboration and metrics gathering between these teams and boosts their sense of ownership. To support this collaboration, SREs should also set up real-time dashboards that enable all stakeholders to track and share SLO data continuously.
It’s essential to define error budgets that allow for a small margin of degradation when establishing SLOs so teams have a clear goal for what is an acceptable service level and what is unacceptable. If an organization’s service-level agreement (SLA), for example, demands their service is available 99.9% of the time, they need an SLO with an error budget of 0.1%, which defines the maximum amount of downtime users can experience.
Stakeholders also need to automatically track the remaining error budget for their service, so they can better manage and avoid falling afoul of SLAs. AI-powered observability can enhance these capabilities further by identifying the root causes of SLO violations in real time. That empowers SRE teams to ensure the highest service levels and create more value by equipping everyone in the business with the insights to address issues before they breach SLO thresholds.
As a next step, SREs should create a health score for all services and applications based on a defined range of SLOs. This will help them to understand the quality of each release to ensure it hasn’t degraded code from the prior version. As a result, teams can quickly identify whether a version needs to be rolled back.
Ideally, the continuous analysis and calculation that goes into producing this health score should be automated and easily available for teams to access when they need to dig deeper to understand the cause and effect of a problem. When applied to continuous delivery pipelines, this health score can be used as a minimum quality threshold that prevents a bad release from going into production, thus reducing the business risk of rapid innovation. These scores also help to indicate to DevOps and SRE teams whether they’re on track to meet SLO targets and where recurring issues may cause serious problems.
SREs should also integrate SLO health checks into the delivery pipeline to support multistage delivery and enable greater self-service capabilities for developers. These health checks act as a quality gate, providing much-needed balances at every stage of the product release cycle, from deployment to testing and evaluation. Based on the result of these checks, teams will get a clear answer as to whether it’s safe to progress their code to the next stage of delivery or if they need to go back to make further optimizations. To enhance the effectiveness of these SLO health checks, SREs should ensure support tickets are automatically updated and notifications sent to relevant stakeholders via platforms such as Slack to enhance collaboration and audit trails.
SLO-driven remediation is the final piece of the puzzle, helping teams to address problems that occur after a new release or feature enters production. The end goal is for SREs to ensure SLO results are standardized within incident management workflows, to reduce mean time to repair and encourage faster recovery from incidents. A single, unified set of solutions that support automated releases, notifications and incident management boosts these efforts by embedding SLOs in delivery processes.
As the complexity of modern delivery environments increases, applications continue to scale up and organizations grow, the challenges facing SRE teams rise in kind. Using AI-powered observability to drive DevOps automation based on SLOs has become a critical capability in enabling SREs to succeed. With real-time answers, they can build better automation that enhances productivity, speeds product delivery and improves business results.
