diff --git a/docs/training/scribe.md b/docs/training/scribe.md index b45c124..7230abb 100644 --- a/docs/training/scribe.md +++ b/docs/training/scribe.md @@ -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