Final Part 2

Question 1

What are two common architecture structures in modern applications?

Answer 1

Monoliths and Microservices

Question 2

What type of architecture are microservices?

Answer 2

Service-oriented architecture(SOA)

Question 3

Key characteristics of Service-oriented architecture (SOA)

Answer 3

– Components or units of functionality that logically manage business functions.

– Every unit is self-contained.

– Users don’t need to know how a component works, only how to interact with it.

– Other services can exist within a unit, but components are loosely coupled.

Question 4

Beyond the decoupling of logic, well-architected microservices offer large engineering organizations what?

Answer 4

The capability to split teams by components in which each group of engineers “owns” a service (or group of services) from ideation to production.

Question 5

What is the contrast between microservices and a monolith?

Answer 5

Microservices can interact freely with each other and those services will pass information around until data needs to
be saved or retrieved from the database.

Microservices involve a much more free-form architecture

Question 6

From an operations perspective what do microservices simplify?

Answer 6

Deployments

Question 7

Because microservices are typically smaller in nature, with fewer lines of code, than a monolith what can you do?

Answer 7

You can more easily deploy small changes frequently, thus eliminating a common challenge in adopting continuous delivery or continuous deployment.

Question 8

Microservices enable refine and targeted ____?

Answer 8

Scaling

Question 9

Fail-fast system

Answer 9

A system that immediately reports at its interface any condition that is likely to indicate a failure. A fail-fast component will fail at the first sign of a problem.

Question 10

In modern development, system components act independently and can change behavior if?

Answer 10

A failure is detected in a neighboring component.

Question 11

Fail-fast systems features can do what?

Answer 11

Make your system more fault tolerant, allowing it to function even as failure is occurring.

Question 12

If you implement your system well with failure checks at each potential breaking point

Answer 12

It will show failure earlier than would be typical because you’re made aware of the failure far before a cascading series of failures can cause catastrophic consequences.

In other words, each component is treated independently in failure
detection, so a domino effect is less likely to occur.

Question 13

Fail-safe system

Answer 13

A system that shuts down operation immediately on discovering a failure to ensure the safety of humans, equipment, data, and any other assets that could be damaged.

Question 14

Kaizen

Answer 14

The Japanese word for improvement or change for the better.

Question 15

The most important aspect of A DevOps-focused engineering team is the ability to?

Answer 15

Fail well

Question 16

The ability to fail well has more to do with people or tooling?

Answer 16

People

Question 17

What is the most interesting aspect of Kaizen?

Answer 17

It embraces non-catastrophic failure and accepts that the process isn’t perfect and you always have room to refine and improve.

Question 18

What is accountability in DevOps?

Answer 18

Accountability means taking ownership over your work, your team, and
your organization.

Everyone has a role to play in continuous improvement.

Question 19

Ergonomics

Answer 19

The study of human psychology and physiology in design.

Question 20

Cognitive ergonomics

Answer 20

The study of how humans perceive and reason about
their environment.

How do people make decisions or react to certain
stimuli? What makes one person extremely reliable and another flaky?

Question 21

Organizational ergonomics

Answer 21

The study of systems and structures inside organizations.

How do teams communicate and work together? What makes some teams cooperative and others competitive?

Question 22

Overengineering

Answer 22

Code that’s overworked or solutions that are unnecessarily verbose or complex.

Question 23

What are the warning signs that a solution is overengineered.

Answer 23

The problem is more easily managed manually.
The code is unusually verbose. (expressed in more words than needed)
The solution wasn’t peer-reviewed.
The code is difficult to understand.
A free or cheap tool exists that solves the problem.

Question 24

What to include within an incident checklist?

Answer 24

Notify appropriate colleagues.
Deploy a status page to customers
Rate the incident to help the first responders appropriately.
Schedule a post-incident review.

Question 25

What are services?

Answer 25

A set of related systems operated for users

Question 26

Who are responsible for the health of the services?

Answer 26

Site Reliability Engineers(SRE)

Question 27

What range of activities successfully operating a service entails?

Answer 27

Developing monitoring systems,

planning capacity,

responding to incidents,

ensuring the root causes of outages are addressed

Question 28

How can we characterize the health of a service?

Answer 28

From the most basic requirements needed for a system to function as a service at all to the higher levels of function taking active control of the direction of the service rather than reactively fighting fires.

This understanding is so fundamental to how Google evaluates services
that it wasn’t explicitly developed until a number of Google SREs needed a
way to explain how to increase systems’ reliability.

Question 29

From top to bottom what are the Service Reliability Hierarchy steps?

Answer 29

Product, Development, Capacity Planning, Testing + Releasing procedures, Postmortem / Root Cause Analysis, Incident Response, and Monitoring

Question 30

Why is monitoring important?

Answer 30

Without monitoring, you have no way to tell whether the service is even working; absent a thoughtfully designed monitoring infrastructure, you’re flying blind.

You want to be aware of the issues before your users notice them.

Question 31

What fundamental to running a stable service?

Answer 31

Monitoring

Question 32

What does monitoring enables service owners to do?

Answer 32

Make rational decisions about the impact of changes to the service, apply the scientific method to incident response, and of course ensure their reason for existence: to measure the service’s alignment with business goals.

Question 33

What are the reasons why monitoring a very large system is challenging?

Answer 33

The sheer number of components being analyzed

The need to maintain a reasonably low maintenance burden on the engineers responsible for the system

Question 34

Google’s monitoring systems don’t just measure simple metrics, such as the average response time of a web server what else do they need to do?

Answer 34

They also need to understand the distribution of those response times across all web servers in that region. This knowledge enables us to identify the factors contributing to the latency tail.

Question 35

At the scale our systems operate, why is being alerted for single-machine failures unacceptable?

Answer 35

Such data is too Noisy to be actionable.

Instead, they try to build systems that are robust against failures in the systems they depend on.

Question 36

Rather than requiring management of many individual components, what should a large system do instead?

Answer 36

Be designed to aggregate signals and cut outliers.

They need monitoring systems that allow them to alert for high-level service objectives but retain the granularity to inspect individual components as needed.

Question 37

How did Google’s monitoring systems evolve over the course of 10 years?

Answer 37

From the traditional model of custom scripts that check responses and alerts, wholly separated from the visual display of trends, to a new paradigm.

This new model made the collection of time series the first-class role in the monitoring system and replaced those check scripts with a rich language for manipulating time series into charts and alerts.

Question 38

On-call duty

Answer 38

Being available for calls during both working and non-working hours.

Question 39

In the IT context, on-call activities have historically been performed by?

Answer 39

Dedicated Ops teams tasked with the primary responsibility of keeping the service(s) for which they are responsible in good health.

Question 40

How are the google SRE team different from the purely operational team?

Answer 40

They place heavy emphasis on the use of engineering to approach problems.

These problems, which typically fall in the operational domain, exist at a scale that would be intractable without software engineering solutions.

Question 41

As the guardians of production systems, on-call engineers take care of?

Answer 41

Their assigned operations by managing outages that affect the team and performing and/or vetting production changes.

Question 42

When on-call an engineer is available to do what?

Answer 42

Perform operations on production systems within minutes, according to the paging response times agreed to by the team and the business system owners.

Question 43

What are the typical values for user-facing or otherwise highly time critical services, and for less time-sensitive systems?

Answer 43

5 minutes for user-facing or otherwise highly time-critical services, and 30 minutes for less time-sensitive systems.

Question 44

What are response times for an on-call engineer related to?

Answer 44

Desired service availability

For example: if a user-facing system must obtain 4 nines of availability in a given quarter (99.99%), the allowed quarterly downtime is around 13 minutes.

For systems with more relaxed SLOs, the reaction time can be in the order of tens of minutes.

Question 45

As soon as a page is received and acknowledge, what is the on-call engineer expected to do?

Answer 45

Triage the problem and work toward its resolution, possibly involving other team members and escalating as needed.