OSSForks/opsschool-curriculum
1
0
Fork 0
mirror of https://github.com/opsschool/curriculum.git synced 2026-01-15 12:15:03 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fixing a few typos

Browse Source
This commit is contained in:
Povilas Daukintis
2013-07-16 00:29:48 +03:00
parent feefb9e093
commit 73da70cd50
8 changed files with 11 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
outages.rst
View File

@@ -2,7 +2,7 @@ Outages
#######
When outages happen (and they will) it is incredibly useful to have a point person that will handle communcations while the admin focuses on resolving the issue.
When outages happen (and they will) it is incredibly useful to have a point person that will handle communications while the admin focuses on resolving the issue.
A common communication forum (conference call, irc, etc) that affected users can jump in get a quick status and pass along any information is useful.
On a larger scale you would want to have a status page that is constantly updated.
@@ -12,7 +12,7 @@ Once an outage takes place as an Admin you have to primary functions:
2. Document what caused the failure.
Depending on the failure and the impact #2 may actually be more important than #1.
Assuming you have a proper DEV / QA / PROD / DR enviroment setup you should fail over to your DR systems.
Assuming you have a proper DEV / QA / PROD / DR environment setup you should fail over to your DR systems.
Then take your time investigating the PROD systems to identify root cause (and build a test so you can replicate the problem at will) and come up with a proper resolution that can be documented and isn't considered a "band-aide" fix.
Apply the change up through DEV & QA and the then to your PROD, assuming all goes well fail back from DR and run your replicated failure test to show PROD isn't going to fail from that issue again.
Then you are safe to make the change on your DR side.