Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handlers for Incident lifecycle events #139

Open
danpalmer opened this issue Sep 9, 2019 · 2 comments
Open

Handlers for Incident lifecycle events #139

danpalmer opened this issue Sep 9, 2019 · 2 comments

Comments

@danpalmer
Copy link
Contributor

In addition to the slack event handlers provided by response, it would be great to take actions on the opening, closing or comms channel creation for an incident.

These are the sorts of things we'd like to be able to do.

  • Add a link to our runbooks as the first message in the incident channel.
  • Ask incident leads to organise a 5-whys at the end of the incident.
  • Alert #general with a quick summary when impacts are set/changed.

Currently, I don't believe (although happy to be corrected!) that there's a good place to put these. I'm sure something could be hacked together with the cron, but it would be nice to have a set of APIs to handle these.

Here's roughly what I think it could look like:

@incident_closed
def five_whys_reminder(incident: Incident) -> None:
    channel = incident.comms_channel()
    if channel is None:
        return
    channel.post_message("Please organise a 5-Whys")

If this feature would be a good addition I'm happy to have a stab at the first pass at some point, but it would be great to get some feedback on the idea.

@milesbxf
Copy link
Contributor

milesbxf commented Sep 9, 2019

@danpalmer Django signals are a nice generic way of doing this - essentially we can write handlers which hook into various stages of the model lifecycle, e.g. handling updates to models before or after saving them.

See https://github.com/monzo/response/blob/master/response/slack/signals.py for some examples where we use this, e.g. to keep the Slack headline post updated when an incident's details change.

We can also define our own custom signals - this would be an easy way to achieve the @incident_closed annotation you've defined above. Actually, I think this would be a great idea, and a nicer interface for people to use rather than hooking directly into model update signals.

@danpalmer
Copy link
Contributor Author

@milesbxf great idea, I hadn't considered signals. I agree that defining new signals would probably be a better idea here, the model change events might be tricky to decode exactly what's changing. I'll have a go at implementing this sometime. Will update here before I do though in case anyone else wants to take a look first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants