- Coming up, if you're troubleshooting an issue
and wondering whether the problem is on your side
or on the Azure side,
in the next few minutes I'll walk you through
how you can get a personalized view of the health
of your Azure services, regions, and resources,
setting up alerts so you can triage service issues
like outages and planned maintenance,
how you can get official incident reports
to share with your stakeholders and your options
for architecting you work loads
for the appropriate level of resilience.
Now service issues are rare
but it's important to be prepared for the unexpected.
Our goal is to meet or exceed
the control and visibility you have
on prem by providing you
with fast accurate information
about the health of your Azure services.
So here I am, in the Azure Service Health dashboard,
which will help you stay informed
and act quickly when Azure service issues affect you.
If you're used to using status.azure.com,
you're not getting the full picture
because it only shows major issues broadly
impacting Azure customers.
Service Health in the Azure portal, on the other hand,
shows you everything impacting you.
Including both major issues and smaller localized issues.
To get to your dashboard, go to aka.ms/azureservicehealth.
Service Health will inform you about three main types
of health events.
Service issues are problems
in Azure that affect you right now.
For example, outages.
Here you can see a test outage
with information about the impacted services, regions,
an update from our engineering teams,
and ways that you can share
and track the latest information.
Another event type is planned maintenance.
Planned maintenance events can affect your availability.
So, in this example,
you see the impacted service and region,
information about how that'll impact you,
and what you need to do.
Most of these events are performed without any impact
to you and won't be shown here.
In the rare case we do require a re-boot,
we'll allow you to choose when to perform the maintenance
to minimize the impacted downtime.
Next, we give you health advisories.
Health advisories are issues that require you
to act to avoid service interruption,
including service retirements and breaking changes.
In this example, we are removing Easy Tables
and Easy APIs from the Azure portal.
We announce these well in advance to allow you to plan.
In fact, I have a few months
to take the recommended action in this case.
Of course, we don't expect you
to regularly visit this dashboard.
In fact, there are two important things you can do
to avoid that.
Set up service health alerts,
and architect your solutions
for the appropriate level of resilience.
Service Health Alerts automatically notify you
about health events via your preferred channel,
including email, SMS, push notification, and Webhook
so you can know what's happening
and take any necessary action.
Before setting up your alerts,
you'll want to think through your alerting strategy
with your team.
A few key considerations:
First, lets start with criticality.
So, how important is a given subscription, service,
or region to you?
If it's production, you'll want to set up an alert for it.
Dev test might be unnecessary.
Service Health is personalized,
so we won't trigger your alert if the service issue
is affecting a service or region you aren't using.
Next, consider who to inform.
Who is the right person or team
to tell about a service issue, so they can act?
For example, send SQL or CosmosDB issues
to your database team.
Finally, think about how to inform them.
What is the right communication channel for the message?
Email is noisy, so it might take longer
for your teams to respond.
That's fine for planned maintenance that's weeks away
but not for an outage affecting you right now.
In which case, you want to alert your on-call team
using a channel that's immediately seen,
like a push notification or SMS.
If you're configuring your first alert,
it's fine to create a simple, catch-all email alert
for all services, regions, and health events.
However, if your organization does use
a problem management tool like ServiceNow,
we highly recommend integrating it
with your service health alerts
so you can follow your team's
existing ticketing workflow practices.
And I'll show you how to do that in a second.
Back in Service Health, let's set up an alert.
To get started, click "Create Service Health Alert."
The first thing you want to do,
is define your alert target,
which is the condition that will cause the alert to fire.
Choose the Subscription, Services, Regions,
and Event types that you want to get notified about.
Next, select the action to perform
if the alert is triggered.
This will define who gets notified and how.
If you already have Action Group set up,
for example, for your custom Azure Monitor alerts,
you can select one of those and move on.
Otherwise, click, "Create Action Group."
Here you'll define which type or types
of actions you'd like to run.
As discussed before, options include email, SMS,
push notification through the Azure mobile app,
Webhook and ITSM integration, and more
so you can tie into your organization's ticketing systems
like PagerDuty, ServiceNow, or others you might be using.
Finally, you'll want to give your alert a name
and description so it's easier to manage multiple alerts.
Once you click, "Create Alert Rule," you're set up
and ready to go.
Now you're safe in the knowledge
that you'll be better informed
and able to act more quickly
if a service issue ever affects you.
During an outage we're committed to
resolving the issue quickly and keeping you informed.
Now, after an issue is resolved,
you can get an official report from Microsoft.
To do that, in Health History,
you can see past incidents and maintenance
and health advisories.
As soon as they're available,
you'll also find RCAs under each incident.
You can download and share
Microsoft's official issue summary as a PDF.
More important than understanding the impact of an issue,
is avoiding that impact altogether.
Ultimately, the reliability of anything running in Azure,
is a shared responsibility we have with you.
Even though we meet the vast majority of our SLAs,
our engineering teams are constantly investing
in improving the reliability of the platform itself.
As you can see here, in Mark Russinovich's recent blog,
this includes additional redundancies in our platform,
quality assurance throughout our release pipeline,
and automation in our processes.
Now, on your side, there are things you can do
to architect for resilience and up time.
Architecting for resilience means
protecting yourself against different types of failures.
A problem might impact a single host server or server rack,
like an isolated hardware failure.
A more severe problem might impact an entire data center,
like networking or utility feed issues.
Or, in the worst case scenario,
a problem might impact a whole region,
like during a natural disaster.
To protect against isolated hardware failures,
you can, for example, use availability sets so
that your VM runs simultaneously
in two places within the same data center.
If you do that, instead of the usual 99.9% SLA,
for single VM's with premium storage,
we provide a higher SLA, 99.95%,
since you've decreased your risk
by running your VM in a highly available way.
Now, to mitigate data center wide issues,
you can use availability zones,
already available in our 10 largest regions
with more coming soon.
These AZ's represent unique physical locations
within a region with independent power,
network, and cooling.
If you run your VM in two different zones within a region,
we provide an even higher SLA, 99.99%.
Finally, to protect against region-wide issues,
you could use Azure Site Recovery
to replicate an Azure VM to a different Azure Region.
Either manually or in an automated way,
once issues are detected.
We maintain guidance on designing reliable applications,
including best practices for architectural design,
monitoring application health,
and responding to failures and disasters.
This has been a quick overview of Azure Service Health
and architecting for resilience on Azure.
Set up your Service Health alerts today
at aka.ms/azureservicehealth
and learn more about architecting
for resiliency at azure.com/resiliency.
Thanks for watching.
(techno music)