Continuous delivery — a development approach aimed at building, testing and releasing software with greater speed and efficiency — is about much more than just being quick. It also emphasizes creating the highest-performing (fastest, most reliable) software products possible. DevOps teams are always trying to strike a critical balance — if there are too many shortcuts (i.e., overlooking performance testing anywhere in the software lifecycle), they'll likely compromise quality. However, testing that is too time-consuming or resource-intensive can hamper an organization's agility in incorporating user feedback and delivering innovation.
Many DevOps teams have addressed this by automating software testing throughout the entire product lifecycle. This enables developers and testers to work collaboratively and continuously as software progresses towards production. This reduces the chance for bugs to get deeply embedded, forcing re-work on subsequent code work which leads to costly, wasteful delays.
However, greater testing automation does not reduce the friction that exists when a performance problem rears its head. People by nature are defensive of their own work and respective areas of responsibility, which can lead to skirmishes within the team. The developer side of the house — relentlessly focused on roll-outs — may be quick to point to the Ops team, claiming Ops must be the reason the product is hitting a snag. It couldn't possibly be the code! The Ops team, focused on ensuring stability, is quick to point the finger back — “don't tell us how to do our job, our systems are working just fine; the problem has to be your code.” Meanwhile, the clock is ticking, the roll-out is getting stalled and users are growing impatient.
The high-pressure stakes of continuous delivery environments often require an intervention, a human touch — someone who can keep a cool head, address conflicts judiciously and validate performance assiduously every step of the way. This is fueling momentum behind the role of site reliability engineer, or SRE. Currently there are more than 1,000 U.S.-based SRE job reqs posted on LinkedIn.
The SRE is the ultimate adjudicator when a performance issue is identified
The SRE concept originated at Google in 2003. An SRE straddles the line between the “Dev” and “Ops” sides of DevOps teams, both writing code and supporting existing IT systems. The SRE is the ultimate adjudicator when a performance issue is identified, determining conclusively what factor (code or IT systems) is the root cause and seeing it through to resolution.
Many SREs establish firm rules governing DevOps teams — for example, unless a new solution or feature delivers on a pre-defined performance level — either earlier in the lifecycle, or once in production — all future development is on hold, until the problem is fixed. A highly resolute SRE makes it possible to achieve speedy application builds combined with operational stability and strong performance.
The deeper intricacies of the SRE role are still evolving, and to gain some insights into what the role actually entails we recently conducted a survey aimed at this growing group. The role may vary from organization to organization — for example, SREs at small organizations (where headcount tends to be lower) may do just fine with a broader, more general level of expertise across many technical areas. However, SREs in larger organizations often require and demonstrate more focused technical strengths, given the greater headcount and opportunities for specialization. The commonalities we identified include the following:
SREs are prevalent in continuous delivery environments
65 percent of the SREs we surveyed are deploying code at least once a day, and almost half (47 percent) report deploying new code multiple times per day.
Soft skills are crucial
Most SREs come from an IT Ops background, but they view soft skills as equally important as technical skills. Soft skills refer to a more intangible combination of variables including social and communication skills, character traits, emotional intelligence and other attributes, that enable workers to successfully navigate their work environment and achieve goals. SREs view the following soft skills as the most important, in this order — problem-solving, teamwork, composure under pressure, written and verbal communication.
Automation is critical
92 percent of our survey respondents cited automation as the top required technical skill, but ironically, many report their teams are not doing enough in this area. Only 18 percent said their teams have automated every aspect of their operation, indicating that additional machine-automated practices in areas like monitoring, testing or other disciplines are needed.
Availability is the most important service indicator
Application and service availability is the main concern of SREs
Application and service availability is the main concern of SREs, with 84 percent of respondents ranking end-user availability as one of their most important service-level indicators, ahead of error rate and latency trail. Nothing else matters if a system is unavailable, which makes alerting and notification tools an absolute must-have, according to those surveyed.
There's no substitute for real-time communication
Real-time communication is essential when attempting to resolve problems quickly. During incident resolution, 94 percent of respondents rely on real-time collaboration and communication solutions like Slack over other methods.
Continuous delivery collapses software release cycles dramatically, at a time when users' performance demands are exploding. But there's an upside to this in terms of the bottom-line pay-off for fast, reliable software. A one second improvement in webpage load time enabled Staples to increase conversions by 10 percent. Intuit improved webpage load time from 15 to 2 seconds, with every second of improvement driving a 2-3 percent increase in conversions.
Performance problems — and the conflicts they can invoke — are one of the biggest potential traffic jams in continuous delivery environments. When a problem occurs, the deep levels of collaboration that are a hallmark of DevOps teams become apparent — most of the time for the better, but not always. The SRE can be exactly what a DevOps team needs to drive the most positive, accurate and actionable collaborations possible. While this role is still being defined, we see many exciting opportunities for the right types of candidates, with soft skills being especially crucial.
Michael Olson on the AI+ITOPS Podcast: "I really see AIOps as being a core requirement for observability because it ... applies intelligence to your telemetry data and your incident data ... to potentially predict problems before they happen."
Enterprise ITOM and ITSM teams have been welcoming of AIOps, believing that it has the potential to deliver great value to them as their IT environments become more distributed, hybrid and complex. Not so with DevOps teams. It's safe to say they've kept AIOps at arm's length, because they don't think it's relevant nor useful for what they do. Instead, to manage the software code they develop and deploy, they've focused on observability ...
The post-pandemic environment has resulted in a major shift on where SREs will be located, with nearly 50% of SREs believing they will be working remotely post COVID-19, as compared to only 19% prior to the pandemic, according to the 2020 SRE Survey Report from Catchpoint and the DevOps Institute ...
All application traffic travels across the network. While application performance management tools can offer insight into how critical applications are functioning, they do not provide visibility into the broader network environment. In order to optimize application performance, you need a few key capabilities. Let's explore three steps that can help NetOps teams better support the critical applications upon which your business depends ...
In Episode 8, Michael Olson, Director of Product Marketing at New Relic, joins the AI+ITOPS Podcast to discuss how AIOps provides real benefits to IT teams ...
Will Cappelli on the AI+ITOPS Podcast: "I'll predict that in 5 years time, APM as we know it will have been completely mutated into an observability plus dynamic analytics capability."
When you consider that the average end-user interacts with at least 8 applications, then think about how important those applications are in the overall success of the business and how often the interface between the application and the hardware needs to be updated, it's a potential minefield for business operations. Any single update could explode in your face at any time ...
Despite the efforts in modernizing and building a robust infrastructure, IT teams routinely deal with the application, database, hardware, or software outages that can last from a few minutes to several days. These types of incidents can cause financial losses to businesses and damage its reputation ...
In Episode 7, Will Cappelli, Field CTO of Moogsoft and Former Gartner Research VP, joins the AI+ITOPS Podcast to discuss the future of APM, AIOps and Observability ...