devopsy.kinsta.cloud

Author: Dawn Parzych

  • The Fallacy of Move Fast and Break Things

    The Fallacy of Move Fast and Break Things

    Ever since Mark Zuckerburg uttered the phrase “move fast and break things,” it has become the motto of many development teams. Companies wanting to be the next unicorn decided this must be the way to operate. The race was on to release more, ship faster, never stop. If moving slowly and methodically wasn’t working, doing more had to be the key to success.

    These companies would cherry-pick statistics from reports such as the Accelerate: State of DevOps Report. The 2019 report showed elite companies have 46 times more frequent code deployments than low-performing teams and a 2,555 times faster lead time to move from code commit to deploy to support their initiatives to move faster.

    The problem is moving fast doesn’t work across industries or for all teams. To effectively move fast, you need processes in place to support the velocity. The consequences of moving too fast and not being able to fix things when they break are high. 

    How We Got Here

    What has gotten us to the point where we are moving too fast? In short, we have. How do you feel when it takes months or a week for a PR to be resolved compared to hours or days?  As consumers and end-users of software, our expectations are continually rising. We have to ship quickly because that is what we as consumers expect. As customers, we are pushing companies, which in turn push their employees to meet the increasing expectations.

    What are the consequences when you try to move fast and not just break things, but fail? 

    • It takes longer to resolve incidents.
    • You lose customer confidence and sales.
    • Employees burnout and you have a high turnover rate.

    Let’s go back to the stats from the Accelerate: State of DevOps Report. Yes, elite teams ship faster. But, their changes are 1/7 as likely to fail and they recover from incidents 2,604 times faster than low-performing teams. It’s not just about moving fast and breaking things; it is about having the right systems and processes in place to support this way of working.

    Setting Yourself Up for Success

    You need two things to effectively move fast: a culture of psychological safety and smart investments in tooling. Employees need to feel empowered to speak up if things are moving too fast, if they are concerned about why a feature is being built and to identify gaps in the processes. They need to feel they won’t be blamed when something breaks. Building this requires empathy, open communication and teamwork.  This psychological safety is the foundation of being able to move quickly and quickly recover when things break. 

    Next up is selecting the right tooling and processes. Invest in tools that make things easier. Tools should be useful, usable and change the underlying problems, not create more. 

    Think about the tools in place to quickly resolve incidents when something fails:

    • Observability and monitoring tools to identify and notify when things go wrong.
    • Incident management tools to route, track and escalate issues.
    • Feature management tools to enable circuit breakers and load shedding to turn off features quickly. 

    The culture and tools are part of the equation; the final piece is having the right processes in place to effectively use the tools and support the people. 

    What are some processes you can implement to enable safety at speed?

    You should attempt to move fast, you should try to break things—but only when you have the right protections and processes in place. Using a combination of the right tools and processes, you can deliver more value faster without sacrificing quality or your employees’ health.

    — Dawn Parzych

  • Defining the Role of a SRE

    Defining the Role of a SRE

    Soft Skills are Just as Important as Technical Skills in the SRE role

    Site reliability engineering (SRE) is a relatively new discipline, having only been in existence for about 15 years. It originated at Google and has gained popularity recently with more companies advertising SRE positions or trying to implement SRE practices. In the technology field, 15 years may seem like an eternity, but the SRE role is very much still in its infancy. There are still challenges defining the role and understanding exactly what it is. Just look through one of the 1,000-plus job listings on LinkedIn for an SRE in the United States—you will see many different job expectations and requirements.

    Some may see the SRE role as being similar to DevOps, while others may see them as competing concepts. Liz Fong-Jones and Seth Vargo from Google created a video describing the differences and similarities between DevOps and Site Reliability Engineering. They point out that DevOps is a philosophy and SRE is a prescriptive way of accomplishing that philosophy.

    Earlier this year, Catchpoint conducted a survey of 416 professionals with the title or responsibility of an SRE. The goal was to create a real-world profile of an SRE and their organizations. What we found was that some of the challenges in clearly defining the role may be due to differing needs and priorities based on industry and company size.

    Being a good SRE requires a mix of technical skills and “soft skills.” It was a relief to see there were no variations in the skills required based on whether a person was an individual contributor, manager or executive. Consistency in articulating goals and expectations is crucial to being a successful SRE and this is where some of the soft skills come into play. Someone may be good at automation, know a variety of scripting languages and is well-versed in application and network protocols, but that doesn’t make them a strong SRE. SREs need to know which questions to ask, not just how to apply technology to solve a problem. This requires being adept at problem-solving, working as part of team and having exceptional communication skills.

    The growing importance of soft skills cannot be overstated. West Monroe Partners recently conducted a survey of 600 HR and recruiting professionals who are responsible for hiring IT workers and 650 business professionals who work with IT staff on a regular basis. In the study, 42.9 percent of respondents said a lack of soft skills made it tough to find qualified candidates for technical jobs. When asked which were the most important soft skills for IT, 77.2 percent named teamwork and collaboration, and 63.4 percent named verbal communication.

    The SRE is fast becoming a mandatory position at many organizations, as continuous delivery of software applications becomes the norm. Development teams must work within dramatically condensed time frames, and unexpected performance incidents will arise. The SRE, who is responsible for increasing the reliability of supported services, needs to be able to effectively communicate why and how a proposed code or infrastructure change will impact reliability. This is why strong communications skills are so necessary.

    The Catchpoint survey also highlighted the need for alerting and notification tools. A full 90 percent of SREs responding noted they cannot live without such tools. These enable them to identify conclusively where the source of a problem lies, thus avoiding time wasted blaming or war-rooming, all while supporting a clear communications process.

    If your organization does not yet have an SRE, chances are you may soon. What are some things both employers and employees need to be thinking about?

    Advice for Employers

    Think about your organization’s specific needs, not whether your organization is doing exactly what is in Google’s SRE book. Specifically, for large organizations where there is enough headcount for people to specialize, the SRE role may look very different than at a small startup. Larger organizations generally will have more headcount, which means people are able to specialize in certain areas. If they aren’t familiar with a certain technology or toolset, others on the team with the knowledge can pick up the slack. Smaller organizations, however, require people to do more or potentially know a little bit about many topics, as often they don’t have the ability to hire experts in all areas. A strong SRE candidate for a large organization may only be good at a single technical skill, but they can still be a successful SRE. A strong SRE candidate at a smaller organization may need to have a wider arsenal of technical skills.

    Advice for Potential SRE Candidates

    Workers considering a move to an SRE role should understand that technical skills and soft skills are equally vital. Your job will consist of approximately 50 percent traditional IT ops functions—collecting and analyzing logging and diagnostic information, participating in on-call rotations and proactively monitoring and reviewing application performance, for example. You will also need to have good problem-solving skills and communicate clearly to identify and address incidents with your team. Being able to ask the right questions is critical to determining why systems and applications are not operating correctly. Collaboration is at the heart of the SRE role and that requires flexibility, teamwork and solid verbal skills.

    Also understand that while you may still have one foot in the developer world, your role will be quite different from other roles on the development team. The majority of SREs do not develop new features or contribute to product road maps, a stark difference to other roles on the development team. SREs write software to automate tasks such as configuration management; they also write software or scripts to monitor systems and applications and help scale and build resiliency in these applications.

    Conclusion

    The real-world SRE job requisition is still evolving, and may look different from one organization to another. One thing we know for sure is that today’s high-intensity continuous delivery environments demand a cool head—someone who can toggle seamlessly across IT ops and development and successfully bring together both sides around the common goal of delivering high-performing, innovative software and features. An SRE must possess a blend of technical as well as soft skills and, perhaps most of all, must be adept at communicating effectively and inspiring a teamwide approach to excellence.

    — Dawn Parzych