Build - Run - Improve - Repeat
Hoe leg je aan iemand (je manager?) uit dat je nog niet moet beginnen dromen van sneller nieuwe software op te leveren als je nog niet in staat bent betere kwaliteit op te leveren? Hoe vertel je hen continuous delivery nog even te vergeten en eerst in te zetten op continuous integration, vooral dan als ze al hun zinnen hebben gezet op een bepaalde toolsuite of een bepaalde tool vendor?
​
Wat als je hen de impact van hun beslissingen kon doen ervaren? In een veilige omgeving? Dat is exact de doelstelling van dit spel. Het ondersteunt ervaringsgericht leren over agile en DevOps, geïnspireerd door de quote van Amazon's CTO Werner Vogels: you build it, you run it.
-
Build: agile development practices, de linker kant van de DevOps cyclus
-
Run: alle activiteiten om wijzigingen in productie te brengen en ervoor te zorgen dat deze correct (blijven) werken
-
Improve: gradueel je manier van werken verbeteren, door te investeren in de verschillende activiteiten van alle stadia van de DevOps cyclus
It's all in the game...
Dit spel is ontworpen als een bordspel, waarin je nieuwe functionaliteit moet opleveren, door alle activiteiten van de verschillende stadia van de DevOps cyclus te doorlopen.
Nieuwe functionaliteit opleveren betekent inkomsten die je kan investeren in verbeteringen. Aanvankelijk gaat het opleveren van nieuwe functionaliteit eerder traag, maar met de juiste investeringen en verbeteringen word je stapje voor stapje matuurder. Je bouwt een stevig fundament van goede practices op die zich later dik terugverdient. Je kan dit doen door de maturiteit van de verschillende activiteiten van de cyclus te verbeteren. Je begint met maturiteitsniveau 0, maar je kan voor de start al investeren om bepaalde activiteiten te verbeteren.
Dit spel laat je ervaren wat er gebeurt als je de foute investeringen doet, of investeert in de verkeerde volgorde... En geloof me: er kan heel wat fout lopen! Voornamelijk incidenten, waarvan de aanleiding niet altijd bij jezelf ligt.
Wat kan er eigenlijk fout lopen?
Een nieuw beveiligingslek werd gerapporteerd. Dit moet je zo snel mogelijk zien te dichten.
Er werd een bug gevonden in je code. Afhankelijk van hoe snel je deze bug ontdekt (wordt bepaald door je performance niveau), zal dit meer of minder financiële schade toebrengen. En je moet de bug nog altijd oplossen, natuurlijk.
Je systemen kunnen gehackt worden. Opnieuw, afhankelijk van hoe snel je deze aanval ontdekt (wordt bepaald door je performance niveau), zal dit meer of minder financiële schade toebrengen. En ook hier moet het probleem ook opgelost worden, natuurlijk.
Je systeem is gecrasht. Dit heeft zeker financiële impact, afhankelijk van je performance niveau, hoe snel je het probleem kan detecteren en hoe snel je het systeem weer op krijgt. Ja, je moet je systeem zo snel mogelijk weer op krijgen.
Je systeem kreeg uitzonderlijk meer load te verwerken. Is je systeem correct geschaald? Kan je gemakkelijk aanpassen aan de wijzigende load? Zorg dat je systeem zo snel mogelijk weer normaal werkt want door timeouts en geweigerde connecties ben je al inkomsten verloren.
Je systeem heeft een performantieprobleem. Dit kan een infrastructuurprobleem zijn - onvoldoende resources om de load te verwerken - maar dit kan ook een designprobleem zijn. In ieder geval, wanneer te antwoord- en verwerkingstijd van je systeem oploopt, lopen je klanten weg en verlies je inkomsten. Los dit zo snel mogelijk op.
Het feit dat alle incidenten, behalve het gerapporteerde beveiligingslek, financiële schade kunnen toebrengen aan je organisatie, betekent dat je omzichtig moet omspringen met je investeringen: niet investeren is sowieso dodelijk, maar te veel investeringen in één keer doen en niet genoeg financiële reserve hebben, kan leiden tot bankroet. En je weet nooit vooraf wat de financiële impact van een incident zal zijn...
​