Use multiple zones within a region

For highly critical services (and their data), configure and enable
them to run across multiple zones. This should give a bump to your
system availability, and increase your resiliency in the case of
disruption (within a zone).

Specify appropriate computing instance types and specifications

Business critical services should have computing capacity
appropriately assigned to them. If services are required to run 24/7,
your infrastructure should reflect those requirements.

Match investment to critical service tiers

Many organizations manage investment by identifying critical
service tiers, with the understanding that not all business systems
share the same importance in terms of delivering customer experience
and supporting revenue. Identifying service tiers and associated
resilience outcomes informed by service level agreements (SLAs), paired with architecture and
design patterns that support the outcomes, provides helpful guardrails
and governance for your product development teams.

Clearly define owners across your entire system

Each service that exists within your system should have
well-defined owners. This information can be used to help direct issues
to the right place, and to people who can effectively resolve them.
Implementing a developer portal which provides a software services
catalog with clearly defined team ownership helps with internal
communication patterns.

Automate manual resilience processes (within a timebox)

Certain resilience problems that have been solved by hand can be
automated: actions like restarting a service, adding new instances or
restoring database backups. Many actions are easily automated or simply
require a configuration change within your cloud service provider.
While in the bottleneck, implementing these capabilities can give the
team the relief it needs, providing much needed breathing room and
time to solve the root cause(s).

Make sure to keep these implementations at their simplest and
timeboxed (couple of days at max). Bear in mind these started out as
bandaids, and automating them is just another (albeit better) type of
bandaid. Integrate these into your monitoring solution, allowing you
to remain aware of how frequently your system is automatically recovering and how long it
takes. At the same time, these metrics allow you to prioritize
moving away from reliance on these bandaid solutions and make your
whole system more robust.

Centralize your logs to be viewable through a single interface

Aggregate logs from core services and systems to be available
through a central interface. This will keep them accessible to
multiple eyes easily and reduce troubleshooting efforts (potentially
improving mean time to recovery).

Define a clear structured format for log messages

Anyone who’s had to parse through aggregated log messages can tell
you that when multiple services follow differing log structures it’s
an incredible mess to find anything. Every service just ends up
speaking its own language, and only the original authors understand
the logs. Ideally, once those logs are aggregated, anyone from
developers to support teams should be able to understand the logs, no
matter their origin.

Structure the log messages using an organization-wide standardized
format. Most logging tools support a JSON format as a standard, which
enables the log message structure to contain metadata like timestamp,
severity, service and/or correlation-id. And with log management
services (through an observability platform), one can filter and search across these
properties to help debug bottleneck issues. To help make search more
efficient, prefer fewer log messages with more fields containing
pertinent information over many messages with a small number of
fields. The actual messages themselves may still be unique to a
specific service, but the attributes associated with the log message
are helpful to everyone.

Treat your log messages as a key piece of information that is
visible to more than just the developers that wrote them. Your support team can
become more effective when debugging initial customer queries, because
they can understand the structure they are viewing. If every service
can speak the same language, the barrier to provide support and
debugging assistance is removed.

Add observability that’s close to your customer experience

What gets measured gets managed.

— Peter Drucker

Though infrastructure metrics and service message logs are
useful, they are fairly low level and don’t provide any context of
the actual customer experience. On the other hand, customer
notifications are a direct indication of an issue, but they are
usually anecdotal and don’t provide much in terms of pattern (unless
you put in the work to find one).

Monitoring core business metrics enables teams to observe a
customer’s experience. Typically defined through the product’s
requirements and features, they provide high level context around
many customer experiences. These are metrics like completed
transactions, start and stop rate of a video, API usage or response
time metrics. Implicit metrics are also useful in measuring a
customer’s experiences, like frontend load time or search response
time. It’s crucial to match what is being observed directly
to how a customer is experiencing your product. Also
important to note, metrics aligned to the customer experience become
even more important in a B2B environment, where you might not have
the volume of data points necessary to be aware of customer issues
when only measuring individual components of a system.

At one client, services started to publish domain events that
were related to the product experience: events like added to cart,
failed to add to cart, transaction completed, payment approved, etc.
These events could then be picked up by an observability platform (like
Splunk, ELK or Datadog) and displayed on a dashboard, categorized and
analyzed even further. Errors could be captured and categorized, allowing
better problem solving on errors related to unexpected customer
experience.

Figure 2:
Example of what a dashboard focusing on the user experience could look like

Data gathered through core business metrics can help you understand
not only what might be failing, but where your system thresholds are and
how it manages when it’s outside of that. This gives further insight into
how you might get through the bottleneck.

Provide product status insight to customers using status indicators

It can be difficult to manage incoming customer inquiries of
different issues they are facing, with support services quickly finding
they are fighting fire after fire. Managing issue volume can be crucial
to a startup’s success, but within the bottleneck, you need to look for
systemic ways of reducing that traffic. The ability to divert call
traffic away from support will give some breathing room and a better chance to
solve the right problem.

Service status indicators can provide customers the information they are
seeking without having to reach out to support. This could come in
the form of public dashboards, email messages, or even tweets. These can
leverage backend service health and readiness checks, or a combination
of metrics to determine service availability, degradation, and outages.
During times of incidents, status indicators can provide a way of updating
many customers at once about your product’s status.

Building trust with your customers is just as important as creating a
reliable and resilient service. Providing methods for customers to understand
the services’ status and expected resolution timeframe helps build
confidence through transparency, while also giving the support staff
the space to problem-solve.

Understand the costs of service failure

For a startup, the consequences of not hitting a revenue target
this ‘quarter’ might be different than for a scaleup or a mature
product. But as often happens, the initial “new features are more
valuable than technical debt” decision becomes a permanent fixture in the
organizational culture – whether the actual revenue impact is provable
or not; or even calculated. An aspect of the maturity needed when
moving from startup to scaleup is in the data-driven element of
decision-making. Is the organization tracking the value of every new
feature shipped? And is the organization analyzing the operational
investments as contributing to new revenue rather than just a
cost-center? And are the costs of an outage or recurring outages known
both in terms of wasted internal labor hours as well as lost revenue?
As a startup, in most of these regards, you’ve got nothing to lose.
But this is not true as you grow.

Therefore, it’s important to start analyzing the costs of service
failures as part of your overall product management and revenue
recognition value stream. Understanding your revenue “velocity” will
provide an easy way to quantify the direct cost-per-minute of
downtime. Tracking the costs to the team for everyone involved in an
outage incident, from customer support calls to developers to management
to public relations/marketing and even to sales, can be an eye-opening experience.
Add on the opportunity costs of dealing with an outage rather than
expanding customer outreach or delivering new features and the true
scope and impact of failures in resilience become apparent.

Manage resilience as a feature

Start treating resilience as more than just a technical
expectation. It’s a core feature that customers will come to expect.
And because they expect it, it should become a first class
consideration among other features. Part of this evolution is about shifting where the
responsibility lies. Instead of it being purely a responsibility for
tech, it’s one for product and the business. Multiple layers within
the organization will need to consider resilience a priority. This
demonstrates that resilience gets the same amount of attention that
any other feature would get.

Close collaboration between
the product and technology is vital to make sure you’re able to
set the correct expectations across story definition, implementation
and communication to other parts of the organization. Resilience,
though a core feature, is still invisible to the customer (unlike new
features like additions to a UI or API). These two groups need to
collaborate to ensure resilience is prioritized appropriately and
implemented effectively.

The objective here is shifting resilience from being a reactionary
concern to a proactive one. And if your teams are able to be
proactive, you can also react more appropriately when something
significant is happening to your business.

Requirements should reflect realistic expectations

Knowing realistic expectations for resilience relative to
requirements and customer expectations is key to keeping your
engineering efforts cost effective. Different levels of resilience, as
measured by uptime and availability, have vastly different costs. The
cost difference between “three nines” and “four nines” of availability
(99.9% vs 99.99%) may be a factor of 10x.

It’s important to understand your customer requirements for each
business capability. Do you and your customers expect a 24x7x365
experience? Where are your customers
based? Are they local to a specific region or are they global?
Are they primarily consuming your service via mobile devices, or are
your customers integrated via your public API? For example, it is an
ineffective use of capital to provide 99.999% uptime on a service delivered via
mobile devices which only enjoy 99.9% uptime due to cell phone
reliability limits.

These are important questions to ask
when thinking about resilience, because you don’t want to pay for the
implementation of a level of resiliency that has no perceived customer
value. They also help to set and manage
expectations for the product being built, the team building and
maintaining it, the folks in your organization selling it and the
customers using it.

Feel out your problems first and avoid overengineering

If you’re solving resiliency problems by hand, your first instinct
might be to just automate it. Why not, right? Though it can help, it’s most
effective when the implementation is time-boxed to a very short period
(a couple of days at max). Spending more time will likely lead to
overengineering in an area that was actually just a symptom.
A large amount of time, energy and money will be invested into something that is
just another bandaid and most likely is not sustainable, or even worse,
causes its own set of second-order challenges.

Instead of going straight to a tactical solution, this is an
opportunity to really feel out your problem: Where do the fault lines
exist, what is your observability trying to tell you, and what design
choices correlate to these failures. You may be able to discover those
fault lines through stress, chaos or exploratory testing. Use this
opportunity to your advantage to discover other system stress points
and determine where you can get the largest value for your investment.

As your business grows and scales, it’s critical to re-evaluate
past decisions. What made sense during the startup phase may not get
you through the hypergrowth stages.

Leverage multiple techniques when gathering requirements

Gathering requirements for technically oriented features
can be difficult. Product managers or business analysts who are not
versed in the nomenclature of resilience can find it hard to
understand. This often translates into vague requirements like “Make x service
more resilient” or “100% uptime is our goal”. The requirements you define are as
important as the resulting implementations. There are many techniques
that can help us gather those requirements.

Try running a pre-mortem before writing requirements. In this
lightweight activity, individuals in different roles give their
perspectives about what they think could fail, or what is failing. A
pre-mortem provides valuable insights into how folks perceive
potential causes of failure, and the related costs. The ensuing
discussion helps prioritize things that need to be made resilient,
before any failure occurs. At a minimum, you can create new test
scenarios to further validate system resilience.

Another option is to write requirements alongside tech leads and
architecture SMEs. The responsibility to create an effective resilient system
is now shared amongst leaders on the team, and each can speak to
different aspects of the design.

These two techniques show that requirements gathering for
resilience features isn’t a single responsibility. It should be shared
across different roles within a team. Throughout every technique you
try, keep in mind who should be involved and the perspectives they bring.

Broadly look at your architecture and determine appropriate trade-offs

Either implicitly or explicitly, when the initial architecture was
created, trade-offs were made. During the experimentation and gaining
traction phases of a startup, there is a high degree of focus on
getting something to market quickly, keeping development costs low,
and being able to easily modify or pivot product direction. The
trade-off is sacrificing the benefits of resilience
that would come from your ideal architecture.

Take an API backed by Functions as a Service (FaaS). This approach is a great way to
create something with little to no management of the infrastructure it
runs on, potentially ticking all three boxes of our focus area. On the
other hand, it’s limited based on the infrastructure it’s allowed to
run on, timing constraints of the service and the potential
communication complexity between many different functions. Though not
unachievable, the constraints of the architecture may make it
difficult or complex to achieve the resilience your product needs.

As the product and organization grows and matures, its constraints
also evolve. It’s important to acknowledge that early design decisions
may no longer be appropriate to the current operating environment, and
consequently new architectures and technologies need to be introduced.
If not addressed, the trade-offs made early on will only amplify the
bottleneck within the hypergrowth phase.

Enhance resilience with effective error recovery strategies

Data gathered from monitors can show where high failure
rates are coming from, be it third-party integrations, backed-up queues,
backoffs or others. This data can drive decisions on what are
appropriate recovery strategies to implement.

Use caching where appropriate

When retrieving information, caching strategies can help in two
ways. Primarily, they can be used to reduce the load on the service by
providing cached results for the same queries. Caching can also be
used as the fallback response when a backend service fails to return
successfully.

The trade-off is potentially serving stale data to customers, so
ensure that your use case is not sensitive to stale data. For example,
you wouldn’t want to use cached results for real-time stock price
queries.

Use default responses where appropriate

As an alternative to caching, which provides the last known
response for a query, it is possible to provide a static default value
when the backend service fails to return successfully. For example,
providing retail pricing as the fallback response for a pricing
discount service will do no harm if it is better to risk losing a sale
rather than risk losing money on a transaction.

Use retry strategies for mutation requests

Where a client is calling a service to effect a change in the data,
the use case may require a successful request before proceeding. In
this case, retrying the call may be appropriate in order to minimize
how often error management processes need to be employed.

There are some important trade-offs to consider. Retries without
delays risk causing a storm of requests which bring the whole system
down under the load. Using an exponential backoff delay mitigates the
risk of traffic load, but instead ties up connection sockets waiting
for a long-running request, which causes a different set of
failures.

Use idempotency to simplify error recovery

Clients implementing any type of retry strategy will potentially
generate multiple identical requests. Ensure the service can handle
multiple identical mutation requests, and can also handle resuming a
multi-step workflow from the point of failure.

Design business appropriate failure modes

In a system, failure is a given and your goal is to protect the end
user experience as much as possible. Specifically in cases that are
supported by downstream services, you may be able to anticipate
failures (through observability) and provide an alternative flow. Your
underlying services that leverage these integrations can be designed
with business appropriate failure modes.

Consider an ecommerce system supported by a microservice
architecture. Should downstream services supporting the ordering
function become overwhelmed, it would be more appropriate to
temporarily disable the order button and present a limited error
message to a customer. While this provides clear feedback to the user,
Product Managers concerned with sales conversions might instead allow
for orders to be captured and alert the customer to a delay in order
confirmation.

Failure modes should be embedded into upstream systems, so as to ensure
business continuity and customer satisfaction. Depending on your
architecture, this might involve your CDN or API gateway returning
cached responses if requests are overloading your subsystems. Or as
described above, your system might provide for an alternative path to
eventual consistency for specific failure modes. This is a far more
effective and customer focused approach than the presentation of a
generic error page that conveys ‘something has gone wrong’.

Resolve single points of failure

A single service can easily go from managing a single
responsibility of the product to multiple. For a startup, appending to
an existing service is often the simplest approach, as the
infrastructure and deployment path is already solved. However,
services can easily bloat and become a monolith, creating a point of
failure that can bring down many or all parts of the product. In cases
like this, you’ll need to understand ways to split up the architecture,
while also keeping the product as a whole functional.

At a fintech client, during a hyper-growth period, load
on their monolithic system would spike wildly. Due to the monolithic
nature, all of the functions were brought down simultaneously,
resulting in lost revenue and unhappy customers. The long-term
solution was to start splitting the monolith into several separate
services that could be scaled horizontally. In addition, they
introduced event queues, so transactions were never lost.

Implementing a microservice approach is not a simple and straightforward
task, and does take time and effort. Start by defining a domain that
requires a resiliency boost, and extract it’s capabilities piece by piece.
Roll out the new service, adjust infrastructure configuration as needed (increase
provisioned capacity, implement auto scaling, etc) and monitor it.
Ensure that the user journey hasn’t been affected, and resilience as
a whole has improved. Once stability is achieved, continue to iterate over
each capability in the domain. As noted in the client example, this is
also an opportunity to introduce architectural elements that help increase
the general resilience of your system. Event queues, circuit breakers, bulkheads and
anti-corruption layers are all useful architectural components that
increase the overall reliability of the system.

Regularly chaos test to validate system resilience

Chaos engineering is the bedrock of truly resilient products. The
core value is the ability to generate failure in ways that you might
never think of. And while that chaos is creating failures, running
through user scenarios at the same time helps to understand the user
experience. This can provide confidence that your system can withstand
unexpected chaos. At the same time, it identifies which user
experiences are impacted by system failures, giving context on what to
improve next.

Though you may feel more comfortable testing against a dev or QA
environment, the value of chaos testing comes from production or
production-like environments. The goal is to understand how resilient
the system is in the face of chaos. Early environments are (usually)
not provisioned with the same configurations found in production, thus
will not provide the confidence needed. Running a test like
this in production can be daunting, so make sure you have confidence in
your ability to restore service. This means the entire system can be
spun back up and data can be restored if needed, all through automation.

Start with small understandable scenarios that can give useful data.
As you gain experience and confidence, consider using your load/performance
tests to simulate users while you execute your chaos testing. Ensure teams and
stakeholders are aware that an experiment is about to be run, so they
are prepared to monitor (in case things go wrong). Frameworks like
Litmus or Gremlin can provide structure to chaos engineering. As
confidence and maturity in your resilience grows, you can start to run
experiments where teams are not alerted beforehand.

Recruit specialists with knowledge of resilience at scale

Hiring generalists when building and delivering an initial product
makes sense. Time and money are incredibly valuable, so having
generalists provides the flexibility to ensure you can get out to
market quickly and not eat away at the initial investment. However,
the teams have taken on more than they can handle and as your product
scales, what was once good enough is no longer the case. A slightly
unstable system that made it to market will continue to get more
unstable as you scale, because the skills required to manage it have
overtaken the skills of the existing team. In the same vein as
technical
debt,
this can be a slippery slope and if not addressed, the problem will
continue to compound.

To sustain the resilience of your product, you’ll need to recruit
for that expertise to focus on that capability. Experts bring in a
fresh view on the system in place, along with their ability to
identify gaps and areas for improvement. Their past experiences can
have a two-fold effect on the team, providing much needed guidance in
areas that sorely need it, and a further investment in the growth of
your employees.

Always maintain or improve your reliability

In 2021, the State of Devops report expanded the fifth key metric from availability to reliability.
Under operational performance, it asserts a product’s ability to
retain its promises. Resilience ties directly into this, as it’s a
key business capability that can ensure your reliability.
With many organizations pushing more frequently to production,
there needs to be assurances that reliability remains the same or gets better.

With your observability and monitoring in place, ensure what it
tells you matches what your service level objectives (SLOs) state. With every deployment to
production, the monitors should not deviate from what your SLAs
guarantee. Certain deployment structures, like blue/green or canary
(to some extent), can help to validate the changes before being
released to a wide audience. Running tests effectively in production
can increase confidence that your agreements haven’t swayed and
resilience has remained the same or better.