Safe-to-fail beschrijft een ontwikkelingsaanpak in de IT-sector waarbij fouten en onvoorziene moeilijkheden worden geanticipeerd. De aanpak is het tegenovergestelde van het bekende fail-safe concept. Belangrijk is dat er niet zoiets bestaat als zuivere doctrine.
Safe-to-fail vs. fail-safe uitgelegd in eenvoudige termen
De eenvoudigste manier om de safe-to-fail benadering uit te leggen is door gebruik te maken van de metafoor van het wegverkeer en deze te onderscheiden van het fail-safe concept. Automobilisten kunnen op twee manieren worden onderscheiden: Type 1 wil ongevallen vermijden door zeer voorzichtig te rijden en een beslist veilig voertuig te gebruiken. Type 2 daarentegen is goed verzekerd om de gevolgen van een ongeval op te vangen.
Type 1 is een vertegenwoordiger van het fail-safe concept. Hij doet alles om ervoor te zorgen dat zijn rit “fail-safe” is. Hij heeft echter geen voorzieningen getroffen voor het geval dat er toch iets gebeurt. De type 2-bestuurder daarentegen heeft dit wel gedaan.
De fail-to-safe-benadering heeft brede ingang gevonden als gevolg van een ramp. Ingenieurs waarschuwden NASA dat er problemen konden zijn met het hitteschild van Challenger. De ambtenaren waren echter van mening dat hun systeem voldoende beschermd was en namen geen extra maatregelen om te reageren op de potentiële problemen van het ruimteveer. De verwoestende gevolgen zijn bekend.
Fail-to-safe in IT-ontwikkeling
In IT-ontwikkeling wordt fail-to-safe toegepast op basis van de vooronderstelling dat alleen het resultaat telt, niet de manier om daar te komen. Dit betekent dat bugs mogen voorkomen, zolang het systeem uiteindelijk maar werkt. Concreet verloopt de implementatie als volgt:
- 1. Er wordt een testomgeving gecreëerd. Hierfür wird ein spezieller Testcode geschrieben.
- 2. Jetzt wird der eigentliche Code geschrieben.
- 3. Der eigentliche Code muss sich in der Testumgebung beweisen.
- 4. Der Testcode zeigt an, ob die Funktion des Codes ausreicht.
- 5. Die Tests offenbaren ebenfalls, ob die Performance den Erwartungen entspricht. Ist dies nicht der Fall, deutet dies auf Fehler hin.
Fazit: Es gibt nicht die reine Lehre
Faktisch gibt es kein „entweder oder“ zwischen „Fail-to-safe“ sowie „Fail-save“. Stattdessen findet ein „sowohl als auch“ statt. Die Autofahrer fahren vorsichtig und sind versichert. Entwickler wollen fehlerfrei arbeiten, aber trotzdem darauf vorbereitet sein, dass diese passieren können.