You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Do we need a sub-bullet under "Understand reliability requirements" around what level of out-of-hours support should be made available? (Software devs are not routinely on call OOH in all parts of Product Development)
Example:
"Gold-level" services must have at least two software engineers and one infrastructure engineer available 24/7/365, all of whom must have experience in operating the system. Additional support/escalation must be available if service cannot be restored after 1 hour.
...
"Bronze-level" services are supported through normal office hours on a "reasonable efforts" basis. Outside these hours, no guarantees of availability are made.
The text was updated successfully, but these errors were encountered:
@arctangent Interesting point. But I would consider for example "services must have at least two software engineers and one infrastructure engineer available" as being product/team-specific, depending on the needs of the business. Usually, that conversation follows after the "Agree an incident severity classification and the response" activity.
This is an area we're looking to expand, @arctangent, but I'm not sure we'd want to include quite that level of detail in here. Anyway, a could point. Let's leave this one open until we do something to this section.
Regarding https://github.com/NHSDigital/software-engineering-quality-framework/blob/master/practices/service-reliability.md
Do we need a sub-bullet under "Understand reliability requirements" around what level of out-of-hours support should be made available? (Software devs are not routinely on call OOH in all parts of Product Development)
Example:
...
The text was updated successfully, but these errors were encountered: