Limit updates to times outside 8 AM - 12 PM and 1 PM to 5 PM
Perform incremental updates in small windows, rather than bundling many changes into a single window
Avoid a situation where we are "afraid" of making changes and then get into a situation where we avoid making changes and fall behind
Try to find a minimal window of exclusion for incremental updates
Service Windows / SLA
Resource: Google SRE (DevOps book). SLA is the contractual (service level agreement) whereas SLO (service level objectives)
Users can become accustomed to long periods of stability, so we must build regular downtime and maintenance into our operating procedures to manage user expectations
We don't have to "force" downtimes, but having something like quarterly downtimes scheduled in advance and at known days/hours enables us to
manage user expectations
give us breathing room to fix issues without needing to communicate in advance (other than a periodic, scheduled reminder)
allow us to give positive news when downtime is unexpectedly not needed, instead of negative news when it IS unexpectedly needed
We can communicate this with an SLO page on our RF docs
Build an issue in RF docs to start this
Limit updates to times outside 8 AM - 12 PM and 1 PM to 5 PM
Perform incremental updates in small windows, rather than bundling many changes into a single window
Avoid a situation where we are "afraid" of making changes and then get into a situation where we avoid making changes and fall behind
Try to find a minimal window of exclusion for incremental updates
Service Windows / SLA
Resource: Google SRE (DevOps book). SLA is the contractual (service level agreement) whereas SLO (service level objectives)
Users can become accustomed to long periods of stability, so we must build regular downtime and maintenance into our operating procedures to manage user expectations
We don't have to "force" downtimes, but having something like quarterly downtimes scheduled in advance and at known days/hours enables us to
manage user expectations
give us breathing room to fix issues without needing to communicate in advance (other than a periodic, scheduled reminder)
allow us to give positive news when downtime is unexpectedly not needed, instead of negative news when it IS unexpectedly needed
We can communicate this with an SLO page on our RF docs
Build an issue in RF docs to start this