Objectives help monitor different aspects of your services and systems such as latencies, error rates, PRs that are open, the age of a bug, and more. These are examples of things that drift away from what we think is good; which is essentially what an objective is. Objectives help us to define what ‘good’ looks like.
Technical debt is one of the trade-offs today’s software teams make to speed up development, which helps go-to-market time in return. That is mission-critical for most start-ups. Instead of dwelling on implementation details, or trying to cover edge cases that may affect a small fraction of the end-users in an early development stage, agile teams prioritize early and continuous delivery.
The role of SRE, Site Reliability Engineer, was first created by Benjamin Treynor in 2003 at Google after he was tasked with ensuring that their websites were available and reliable. The SRE is a multi-disciplined role that needs to have the ability to automate monitoring and observability across hundreds and thousands of complex systems.
Whether you’ve heard of or fully jumped on the DevOps or SRE bandwagon, you may have also wondered how the two relate. What’s the difference? Are they really just different ways of looking at the same problem? The term DevOps hit the market first, but SRE wasn’t too far behind. And though they have different origin stories, they both focus on autonomy, automation, and iteration. So why do these paradigms exist? And why do we need both? Let’s look at this further.
‘OKR’, which stands for ‘Objectives and Key Results,’ is a goal management framework designed to define goals and track outcomes. It differs from typical goal-setting techniques because the aim is to set very ambitious goals that encourage teams to flex their creativity. OKRs are used by Google, LinkedIn, Twitter, and other successful companies to create measurable goals, and to make sure team members are aligned and engaged.
Site reliability engineering (SRE) does the work that would typically be done by operations but instead uses engineers with software experience to solve problems. The concept of SRE was created by Google in 2003 after a team of software engineers was asked to make Google’s sites more scalable, reliant, and efficient. They described SRE as ‘when you treat operations as if it’s a software problem’.
To embed or not to embed: That is the question. At least, that’s one of the questions that companies have to answer as they decide how to implement Site Reliability Engineering. They can either embed SREs into existing teams, or they can build a new, separate SRE team. Both approaches have their pros and cons. The right strategy for your company or team depends, of course, on your needs and priorities.
Reliability testing is a software testing technique designed to make sure that a piece of software meets customer requirements, and to identify any faults within the product before it is delivered to the customer. It is the key to improving the design, functionality, and ultimately the quality of software. It should be performed at each level of software creation, and it encompasses everything from unit testing, to full system testing.
This is Part 1 of a two-part series on Blameless Postmortems. Today, we'll discuss why blameless postmortems are so important and their implications for your team; the second part will go into detail on how to set them up as a process and make them successful. Somebody wise may have once told you that how we handle adversity shows our character. Being able to acknowledge and admit mistakes is the first step towards learning - it's a key part of success both in personal relationships and in large companies.
