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.