Difference between revisions of "Developing Services"

From Dark Peak
Jump to: navigation, search
(Remove definition of service levels and their requirements as these have their own pages now)
Line 1: Line 1:
Users, and possibly other services, need to be able to understand what they can expect from a service.
+
To deploy a new service:
In particular, how well it can be relied upon.
 
To do that we define maturity levels of services ([[Alpha]], [[Beta]], [[Live]]) and define types of service based upon who/what consumes  them ([[User Service|User]], [[Co-op Service|Co-Op]], [[Infrastructure]]).
 
  
These definitions and processes attempt to keep things:
+
* Decide if your new service will be a [[User Service|User]], [[Co-op Service|Co-Op]] or [[Infrastructure]].
;Minimal
+
* Work to reach [[Alpha]] level, this should take a few hours. This is about validating the idea and thinking through what you'll do and what you need to do it.
:Avoid over specifying
+
* Ask the co-op to verify that you've achieved this
:Limit special cases
+
* Work to reach [[Beta]] level. This should be the bulk of the deployment work, and involves finding some co-maintainers
;Local
+
* Ask the co-op to verify that you've achieved this
:where possible, grant autonomy to the people responsible for the service.
+
* Work to reach [[Live]]. This is mostly about simplifying future maintenance work and ensuring it will get done.
;Clarity of requirements to maintainers
+
* Ask the co-op to verify that you've achieved this
:What is required at each level
+
 
:What is provided by the Co-op to help achieve these requirements.
+
These levels exist so that users of your service are able to understand what they can expect from a service.
;Clarity of service to those outside the set of maintainers
+
There is no requirement that all services reach live, if all your users are happy with something less reliable you can remain at Beta indefinitely.
:What’s used to create the service
+
 
:What’s provided to the users of the service
+
 
:How the service aligns with co-op principles
+
Running Services are expected to provide an annual update (via the AGM) that indicates whether the service continues to meet the requirements for the maturity level it is operating at.
;End-user focused
+
Services which start to fail to meet their requirements are given a reasonable period of time to correct the deficiencies (until the next general meeting); continue to fail to meet the requirements means the service descends one maturity level.
:What the user can expect of the service expect in terms of Service Quality and long term availability
+
Such a degradation may place other services also under scrutiny; for example infrastructure being degraded would also affect any services consuming that infrastructure.
:Build only what’s needed, if indirectly, by the end user
+
In addition, live service maintainers have the responsibility to notify the co-op of a change which would mean that the service no longer meets its live requirements.
+
The board should act on these notifications by following the same process as above (ie - entering the “reasonable” grace period of time to correct the deficiencies).
== Definitions ==
+
 
 +
Level requirements will only change at the the AGM or an EGM.
 +
Services then have until the next AGM to meet these requirements. If that is failed then the above process is followed.
 +
 
 +
--------
  
 
Types
 
Types
Line 29: Line 31:
 
;User
 
;User
 
:A service that only exists for our members to use
 
:A service that only exists for our members to use
 +
== Meta ==
  
== Process ==
+
These definitions and processes attempt to keep things:
Ascending the maturity levels is validated with a co-op vote checking that the service has met the requirements for the new maturity level.
+
; Minimal
Whilst this is not a subjective vote on the quality of how requirements are met, there is an expectation that discussion will occur between members prior to a vote occurring.
+
: Avoid over specifying, set broad targets that a service can meet many ways
This should ensure that the quality of how requirements are met remains acceptable.
+
: Limit special cases, these should be specific agreements at the service level rather than added to the requirements
 
+
; Local
Services are expected to provide an annual update (via the AGM) that indicates whether the service continues to meet the requirements for the maturity level it is operating at.
+
: Where possible, grant autonomy to the people responsible for the service.
Services which start to fail to meet their requirements are given a reasonable period of time to correct the deficiencies (until the next general meeting); continue to fail to meet the requirements means the service descends one maturity level.
+
; Clarity of requirements to maintainers
\Such a degradation may place other services also under scrutiny; for example infrastructure being degraded would also affect any services consuming that infrastructure.
+
: What is required at each level
In addition, live service maintainers have the responsibility to notify the co-op of a change which would mean that the service no longer meets its live requirements.
+
: What is provided by the Co-op to help achieve these requirements.
The board should act on these notifications by following the same process as above (ie - entering the “reasonable” grace period of time to correct the deficiencies).
+
; Clarity of service to those outside the set of maintainers
 
+
: What’s used to create the service
Level requirements will only change at the the AGM or an EGM.
+
: What’s provided to the users of the service
Services then have until the next AGM to meet these requirements. If that is failed then the above process is followed.
+
: How the service aligns with co-op principles
 +
; End-user focused
 +
: what can the user of the service expect in terms of Service Quality and  how likely the service is to still be available in the future.
 +
: Build only what’s needed, if indirectly, by the end user

Revision as of 12:03, 14 October 2017

To deploy a new service:

  • Decide if your new service will be a User, Co-Op or Infrastructure.
  • Work to reach Alpha level, this should take a few hours. This is about validating the idea and thinking through what you'll do and what you need to do it.
  • Ask the co-op to verify that you've achieved this
  • Work to reach Beta level. This should be the bulk of the deployment work, and involves finding some co-maintainers
  • Ask the co-op to verify that you've achieved this
  • Work to reach Live. This is mostly about simplifying future maintenance work and ensuring it will get done.
  • Ask the co-op to verify that you've achieved this

These levels exist so that users of your service are able to understand what they can expect from a service. There is no requirement that all services reach live, if all your users are happy with something less reliable you can remain at Beta indefinitely.


Running Services are expected to provide an annual update (via the AGM) that indicates whether the service continues to meet the requirements for the maturity level it is operating at. Services which start to fail to meet their requirements are given a reasonable period of time to correct the deficiencies (until the next general meeting); continue to fail to meet the requirements means the service descends one maturity level. Such a degradation may place other services also under scrutiny; for example infrastructure being degraded would also affect any services consuming that infrastructure. In addition, live service maintainers have the responsibility to notify the co-op of a change which would mean that the service no longer meets its live requirements. The board should act on these notifications by following the same process as above (ie - entering the “reasonable” grace period of time to correct the deficiencies).

Level requirements will only change at the the AGM or an EGM. Services then have until the next AGM to meet these requirements. If that is failed then the above process is followed.


Types

Infrastructure
A service other services rely on
Co-Op
A service the co-op relies on to function, directly or indirectly.
User
A service that only exists for our members to use

Meta

These definitions and processes attempt to keep things:

Minimal
Avoid over specifying, set broad targets that a service can meet many ways
Limit special cases, these should be specific agreements at the service level rather than added to the requirements
Local
Where possible, grant autonomy to the people responsible for the service.
Clarity of requirements to maintainers
What is required at each level
What is provided by the Co-op to help achieve these requirements.
Clarity of service to those outside the set of maintainers
What’s used to create the service
What’s provided to the users of the service
How the service aligns with co-op principles
End-user focused
what can the user of the service expect in terms of Service Quality and how likely the service is to still be available in the future.
Build only what’s needed, if indirectly, by the end user