RFC: Creating a public facing status page about readme HOT 7 CLOSED

We're still kinda struggling with how to define an incident which requires docs like this internally, but I think having someone outside the org with a fresh eyes might help, so I'm for this

FWIW, we've use https://www.statuspage.io for cocoapods for a few years and it's worked out well

from readme.

FWIW, we've use https://www.statuspage.io for cocoapods for a few years and it's worked out well

Atlassian bought StatusPage a couple years ago. Since then, Atlassian has also released Jira Ops (an internal tool to track incident status) which features integrations with StatusPage for external communications. @sweir27 has been looking into Jira Ops during our recent Hackathon.

Generally, there is only one person on-shift at a time.

Is there always a customer support assocate on call for partner-facing incidents? If so, it might make sense for that associate to handle updates to the status page in collaboration with on-call engineers during an incident.

If there isn't a user-facing customer support representative available, I think a reasonable fallback is to the engineers on call to handle updates to the status page.

from readme.

Agree with @dblandin about the on-call people dealing with updating status page! I still mean to investigate how it hooks into Jira Ops, but hopefully this would be seamless. 😄

from readme.

I'm pro a status page.

In my experience at previous companies, the business side of the house also finds value in being able to attest to platform stability with a well designed status page -- so I think there's a lot of business value, in addition to customer-relations value, in the status page.

You can also provide custom HTML/CSS to statuspage.io pages, so we can make sure the page follows our brand.

from readme.

Is there always a customer support assocate on call for partner-facing incidents?

Not quite. Our hours (in EST) are:

Monday: 10am-6pm
Tuesday: 4am - 6pm
Wednesday: 4am - 6pm
Thursday: 4am -6pm
Friday: 10am-6pm

I'm always here 10am-6pm though (barring illness, vacation, etc). During those hours, I'm happy to help for sure! Otherwise, I tend to agree that it may need to fallback onto one of the on-call engineers.

[[Edit]]:
I should note that on Tuesday/Wednesday/Thursday the 4am to 10am EST times are picked up by our European/Hong Kong Gallery Liaisons. I personally would prefer not letting them make status updates to the page/managing that if possible.

the business side of the house also finds value in being able to attest to platform stability with a well designed status page

This is huge too. We do often get questions/concerns about our stability. Being able to point to something concrete would be huge for that too. A nice added benefit.

from readme.

I gave an update on this RFC during our engineering open standup meeting this morning. @sweir27 and I plan to sync up and discuss an action plan. Will comment again once I have another update!

from readme.

As this is now happening 🎉, I think we can close this RFC!

Resolution

We decided to do it!

Level of Support

2: Positive feedback.

Next Steps

We're now tracking the progress of this (and other incident-related process updates) in a Jira epic: https://artsyproduct.atlassian.net/browse/PLATFORM-1048 🔒

Exceptions

We will not be tracking internal services on the new status page.

from readme.