Writing a Post-Mortem

Loading...

Google의 강좌에서

System Administration and IT Infrastructure Services

3073개의 평가

Google

System Administration and IT Infrastructure Services

3073개의 평가

Specialization Google IT Support Professional Certificate에서 5의 강좌 4

This course will transition you from working on a single computer to an entire fleet. Systems administration is the field of IT that’s responsible for maintaining reliable computers systems in a multi-user environment. In this course, you’ll learn about the infrastructure services that keep all organizations, big and small, up and running. We’ll deep dive on cloud so that you’ll understand everything from typical cloud infrastructure setups to how to manage cloud resources. You'll also learn how to manage and configure servers and how to use industry tools to manage computers, user information, and user productivity. Finally, you’ll learn how to recover your organization’s IT infrastructure in the event of a disaster. By the end of this course you’ll be able to: ● utilize best practices for choosing hardware, vendors, and services for your organization. ● understand how the most common infrastructure services that keep an organization running work, and how to manage infrastructure servers. ● understand how to make the most of the cloud for your organization. ● manage an organization’s computers and users using the directory services, Active Directory, and OpenLDAP. ● choose and manage the tools that your organization will use. ● backup your organization’s data and know how to recover your IT infrastructure in the case of a disaster. ● utilize systems administration knowledge to plan and improve processes for IT environments.

수업에서

Data Recovery & Backups

In the fifth week of this course, we'll learn about data recovery and backups. In any tech role, it's important to know how to backup and recover data -- it's even more important for system administration. We will also learn about common corporate practices like designing a disaster recovery plan and writing post-mortem documentation. By the end of this module, you'll know the tradeoffs between on-site and off-site backups, understand the value and importance of backup and recovery testing, know different options for data backup (as well as the risks) and understand the purpose and contents of a disaster recovery plan.

What's a post-mortem?2:35

Writing a Post-Mortem4:40

Interview Role Play: Sys Admin2:54

강사 만나기

Google

Now that we know the benefits of a postmortem,

let's take a closer look at what goes into one.

A typical postmortem for an incident begins with a brief summary,

just a short paragraph,

that summarizes the incident.

It should include: what the incident was?

How long it lasted?

And what the impact was? And how it was fixed?

Be mindful of time zone when listing times and dates in the postmortem.

Always clearly state the time zone to be absolutely clear.

Next, you need a detailed timeline of key events.

This should include everything that happened throughout the event like when it started,

and when people involved were notified or realized what was going on.

Every action taken in an attempt to resolve this situation should also be identified.

These could contain times and dates along with time zones, and who did what.

The timeline should wrap up with the actions

taken that resolved the outage and restored services,

signaling the end of the event.

Next, a very detailed and honest account of the root causes covered.

This should go into detail explaining what led to the issue.

It could be something like

a configuration change that was pushed live without proper testing,

or a command that was typoed.

Remember that the intent isn't to blame or shame,

is to be honest with what went wrong so that a lesson can be learned from it.

If the cause stemmed from a lack of testing,

this might indicate areas for improvement in test verification.

If it was from a typoed command,

this may reveal the need to automate a manual process.

A more detailed explanation of the resolution and

recovery efforts should be documented next.

This is similar to the timeline covered earlier and should include the dates,

times, and time zones.

But it should go into more detail about what steps were taken to recover,

the rationale and the reasoning behind those actions,

and what the outcome of each that was including

the rationale gives those reading the report more context on how the event played out.

Lastly, close out the report with a list of

specific actions that should be taken to avoid the same scenario from happening again.

This should include any actions or efforts aimed at improving the response handling too.

Steps to reduce response time when monitoring would help.

When you spin up a list of things to improve,

look out for things like improvements to monitoring systems.

Maybe the incident investigation revealed a gap in visibility into critical systems,

or the cause investigating turns out that

automation system isn't functioning as intended.

While it's outside the scope of

a postmortem report to come up with solutions to these gaps,

they should be listed in areas for improvement.

Based on these discoveries,

new parties can start to address the deficiencies found.

One thing that often gets overlooked in postmortem is what went well.

But this is just as important as analyzing what went wrong.

During the post-incident analysis,

it's also good to highlight things that went well.

These include: fail safe or fail of a system that worked as designed,

and prevented a large outage,

or minimized the severity of the outage.

This helps to demonstrate the effectiveness of our systems in place.

For some folks, like those in finance, this is good news.

It justifies any cost associated with

these systems by clearly demonstrating a tangible benefit.

This is important for any preventative system since they are frequently

viewed as unnecessary costs by those that may not fully understand their benefit.

These examples of systems working to prevent or

reduce the impact of outages make that benefit very clear.

Hopefully, you're better prepared now to learn

from any mistakes you might make in your career.

And mistakes will be made because you are human after all.

Own them, learn from them,

and do better next time.

Such is true in IT,

work, and in life.

Well, that brings us to the close of our sysadmin course.

We hope you have a better understanding of the responsibilities of a sysadmin,

and how closely they relate to the work of an IT support specialist.

Feel free to review any sections that might have been a bit heavy on the technical side.

First up, we've brought a quiz for you that

would touch on everything we've learned in this module.

Then, when you're ready,

you can jump into the course project to put your new knowledge to work.

We have some fictional companies that you are going to play system administrator for.

You need to take a look at

their current infrastructure and make recommendations for improvements.

I wish you the best of luck.

Coursera 카탈로그 살펴보기

무료로 참여해 맞춤화된 추천, 업데이트 및 제안을 받아보세요.

Coursera는 세계 최고의 교육에 대한 보편적인 접근 기회를 제공하며, 최고의 대학 및 기관들과 제휴하여 온라인 강좌를 제공합니다.

© 2019 Coursera Inc. All rights reserved.

앱스토어에서 다운로드하기

구글 플레이에서 받기