mpana
/
spearhead-issue-response
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

spearhead specifics

This commit is contained in:
Marius Pana 2017-01-21 15:21:36 +02:00
parent ff15a17843
commit fe5a948988
1 changed files with 8 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
docs/training/scribe.md
View File

@ -8,7 +8,7 @@ The purpose of the Scribe is to maintain a timeline of key events during an inci
It's important for the rest of the command staff to be able to focus on the problem at hand, rather than worrying about documenting the steps.
Your job as Scribe is to listen to the call and to watch the incident Slack room, keeping track of context and actions that need to be performed, documenting these in Slack as you go. **You should not be performing any remediations, checking graphs, or investigating logs.** Those tasks will be delegated to the subject matter experts (SME's) by the Incident Commander.
Your job as Scribe is to listen to the call and to watch the incident Slack room and DoIT card(s), keeping track of context and actions that need to be performed, documenting these as you go. **You should not be performing any remediations, checking graphs, or investigating logs.** Those tasks will be delegated to the subject matter experts (SME's) by the Team Leader.
## Prerequisites
@ -25,9 +25,9 @@ There is no formal training process for this role, reading this page should be s
* Read the rest of this page, particularly the sections below.
* Participate in [Failure Friday](https://www.pagerduty.com/blog/failure-friday-at-pagerduty/) (FF).
* Shadow a FF to see how it's run.
* Be the scribe for multiple FF's.
* Participate in [Friday DoD](https://dod.spearhead.systems/) (DoD).
* Shadow a DoD to see how it's run.
* Be the scribe for multiple DoD's.
## Scribing
Scribing is more art than science. The objective is to keep an accurate record of important events that occurred on the call, so that we can look back at the timeline to see what happened. But what exactly is important? There's no overwhelming answer, and it really comes down the judgement and experience. But here are some general things you most definitely want to capture as scribe.
@ -49,27 +49,24 @@ At the start of any major incident call, you should start our status stalking bo
> !status stalk
This will provide the update and allow the IC to see the status without having to keep asking.
This will provide the update and allow the TL to see the status without having to keep asking.
### Note Important Actions
During a call, you will hear lots of discussion happening, you should not be documenting all of this in the chat room. You only want to document things which will be important for the final timeline. It's not always obvious what this might be, and it's usually a matter of judgement. You generally want to note any actions the IC has asked someone to perform, along with the result of any polling decisions.
During a call, you will hear lots of discussion happening, you should not be documenting all of this in the chat room. You only want to document things which will be important for the final timeline. It's not always obvious what this might be, and it's usually a matter of judgement. You generally want to note any actions the TL has asked someone to perform, along with the result of any polling decisions.
> Polled for decision on whether to perform rolling restart. We are proceeding with restart. [USER_A] to execute.
Some actions might seem important at the time, but end up not being. That's OK. It's better to have more info than not enough, but don't go overboard.
### Note Followup Actions
Sometimes during the call, someone will either mention something we "should fix", or the IC will specifically ask you to note a followup item. You can do this in Slack by simply prefixing with "TODO", this will make it easier to search for later.
Sometimes during the call, someone will either mention something we "should fix", or the TL will specifically ask you to note a followup item. You can do this in Slack and DoIT by simply prefixing with "TODO", this will make it easier to search for later.
> TODO: Why did we not get paged for the fall in traffic on [X] cluster?
The post-mortem owner will find these after and raise tasks for them.
### End of Call Notification
When the IC ends the call, you should post a message into Slack to let everyone know the call is over, and that they should continue discussion elsewhere.
When the TL ends the call, you should post a message into Slack to let everyone know the call is over (and notify customers directly via their preffer communications channel), and that they should continue discussion elsewhere.
> Call is over, thanks everyone. Follow up in Slack.
Don't forget to also stop the status stalking.
> !status unstalk