Taxonomy of failsafe levels

[josephineSei]

closes #527

[markus-hentsch]

Good write-up. I added some spelling, phrasing and terminology adjustment suggestions.

[anjastrunk]

IMO, this DR is not in a final state and we should go for another round on discussion

[anjastrunk]

Some glue text is missing here. I would re-phrase the sentence, as follows

Suggested change

	Some standards provided by the SCS will talk about or require procedures to backup resources or have redundancy for resources.
	This decision record should discuss, which failure threats are CSP-facing and will classify them into several levels.
	Some standards provided by the SCS project will talk about or require procedures to backup resources or have redundancy for resources. As these terms are neither officially defined nor intuitive, this decision record tries to get some clarity in this topic. It discuss, which failure threats are cloud service provider facing and classifies them into several levels.

[anjastrunk]

Suggested change

	First there needs to be an overview about possible failure cases in infrastructures:
	First there needs to be an overview about possible failure cases in infrastructures as well as their probability of entry and the damage they may cause.

[anjastrunk]

In favor to simplicity, I would assume disk loss/failure will cause permanent loss of data on this disk.

Suggested change

	| Disk Failure/Loss | High | Data loss on this disk. Impact depends on type of lost data (data base, user data) |
	| Disk Failure/Loss | High | Permanent data loss in on this disk. Impact depends on type of lost data (data base, user data) |

[anjastrunk]

I prefer to differ between Node Failure/Loss, meaning hardware is irrecoverable damaged and node outage, caused by electricity outage, as both use cases cause different implications. Furthermore, we should define node as computation hardware without disks. This facilitates classification of use case.

Suggested change

	| Node Outage | Medium to High | Data loss on node / (temporary) loss of functionality and connectivity of node (impact depends on type of node) |
	| Node Failure/Loss (without disks) | Medium to High | Permanent loss of functionality and connectivity of node (impact depends on type of node) |
	| Node Outage | Medium to High | Temporary loss of functionality and connectivity of node (impact depends on type of node) |

[anjastrunk]

Rack outage means outage of all nodes. As disks are not damaged, I prefer to limit consequences to

Suggested change

	| Rack Outage | Medium | similar to Disk Failure and Node Outage |
	| Rack Outage | Medium | Outage of all nodes in rack |

[anjastrunk]

As I said, I would omit "data loss" and focus on big consequence. Most protocols are working with acknowledgments. Hence, we can assume, that data loss is temporary. What we really lost are CPU and RAM data, but we should omit these consequences, as we can not prevent or avoid them.

Suggested change

	| Power Outage (Data Center supply) | Medium | potential data loss, temporary loss of functionality and connectivity of node (impact depends on type of node) |
	| Power Outage (Data Center supply) | Medium | temporary outage of all nodes in rack (impact depends on type of node) |

[josephineSei]

I am still thinking about the "user hints" column. Putting it next to the other columns is good from some perspectives, as it can be read: I want to achieve 2. Level of failuresafeness, which can be triggered by these failure causes that will result in these losses on IaaS level, so I can do, what is shown in the user hints.
But we wanted the classification not for examples for users, but mainly as a definiton for standards, so maybe we should not reference those standards here.
We could rather use an extra table with example actions(standards, "user has to to things",..) for each level/class or maybe this should rather not be in a decision record, but rather in a guide or so.

[anjastrunk]

I agree with you, @josephineSei. Linking SCS standards in this table may cause a huge synchronization effort. We always have to update this DR, if referenced standards change. I appreciate the column user hints, but would limit to a textual explanation. See my suggestions below...

[anjastrunk]

I a key encryption key really an IaaS resource? I thought key encryption keys are stored in configuration files and if this is the case, it is a configuration setting.

[josephineSei]

The Glossary is for all maybe unknown phrases to be described. As this standard also concerns Key Encryption Keys, it should be noted in the glossary

[anjastrunk]

Suggested some minor changes, but do not want to block PR.

[josephineSei]

Hey @jschoone or @tonifinger or @DEiselt could someone of you help with the KaaS part of this document (or do you know someone who can?) until the end of the week?

[DEiselt]

Hey @jschoone or @tonifinger or @DEiselt could someone of you help with the KaaS part of this document (or do you know someone who can?) until the end of the week?

Hi Josephine, Jan and i will meet today to discuss this and provide feedback :)

[anjastrunk]

@mbuechse @kgube @michal-gubricky @jschoone: Please review, request changes and/or approve. We want to merge this PR as soon as possible.

[josephineSei]

@jschoone @bitkeks @DEiselt @michal-gubricky If you are okay with the total of this decision record, please approve this PR, otherwise please tell me what you think is still missing.

[kgube]

Some small fixes and suggestions

[bitkeks]

LGTM, left one comment regarding the usage of RTO.

Good approach of defining the levels, then the potential influences and the many components that are affected. Mapping this all to the SCS technology parts will help CSPs and users to identify those parts of their instance they need to have a look at more specifically.

Of course this document will probably evolve with more empirical data - you could for example discuss, if river floods in Germany are really "very low" probability 😃

Very important also to highlight the need for a CSP-internal risk analysis. There cannot be a generalized approach that applies everywhere!

[kgube]

LGTM