Mag ik een vuurtje?
21/11/16 00:42
Inleiding
Dingen gaan soms fout. Iemand wordt ziek. De auto gaat stuk. En soms brandt er iets af. Dat vinden we allemaal niet leuk. En we doen vanalles om te voorkomen dat het gebeurt. Voorkomen is immers beter dan genezen. Maar dingen gáán soms fout. Soms moét je genezen, soms moét je repareren, soms moét je brand blussen.
Bluster
Repareren, genezen en blussen dus. Je ontkomt er niet aan. Maar je kunt nóg iets doen. Je kunt proberen het effect te verkleinen, ofwel zorgen dat het niet uit de hand loopt, dat je reserve-onderdelen op de plank hebt, dat vuur niet al te hard om zich heen grijpt en alles in de as legt voordat je aan blussen toe komt. Je bouwt zekerheden in, je bouwt buffers. Een soort van branddeuren dus.
IT grijpt om zich heen
Als er ergens iets stuk gaat, een computer, een database, opslag, hoe zorg je dan dat je daar weinig last van hebt? Dat niet ineens niemand meer kan inloggen, dat een grote groep niet meer kan werken? (Van sommige groepen wíl je wel es dat ze niet konden werken, maar dat terzijde.) Of wanneer iemand iets verknalt, en dat hoeft niet eens met opzet, hoe zorg je ervoor dat je niet meteen al je gegevens kwijt bent? Wanneer er een boefje bezig is, hoe voorkom je dat je niet ineens zo’n 80 miljoen minder te besteden hebt?
De wereld is plat
Welke zekerheden bouw je in? Veel doen we al door middel van scenario analyses. Die zijn vaak van het type “als dit gebeurt, dan volgt er dat en dan doen wij zus, en dan gebeurt er zo”. Heel slim om te doen. Maar dit is wel gebaseerd op aannames. We gaan er namelijk vanuit dat wij precies weten dat dat volgt op dit en dat zus dat altijd voorkómt, omdat zo ook altijd volgt op zus. Het is een soort van zelfoverschatting. Het gaat uit van lineaire verbanden… het gaat uit van plat.
Mag ik een vuurtje?
De verbanden zijn vaak juist vérre van lineair. En met de huidige ontwikkelingen maken we dit nóg erger. Zeker ook omdat ontwikkelingen van steeds meer kanten komen. Hoe bepaal je dan de maximale impact van bijvoorbeeld een brandje? Brand is eigenlijk vergelijkbaar met het stuk gaan van een cloud-onderdeel, een fintech (bingo!) die op de de fles gaat of een bepaalde oplossing die we gebruiken wordt van de markt gehaald. Met enig inlevingsvermogen zou je brand kunnen zien als een vorm van een 'change' (pyromanen plannen ook).
Change Impact Analysis
Brand is gewoon een 'change'. En van élke 'change' wil je de maximale impact bepalen, vóórdat je 'm uitvoert. Je wilt van élke change op voorhand weten: tot hoever fikt het, hoe ver breidt het vuur zich uit, wat is de maximale uitstraling? Waar zitten de branddeuren? Hierover is een hele bak aan literatuur geschreven, allemaal onder de noemer 'Change Impact Analysis'. Die literatuur is vooral gericht op software ontwikkeling, maar het is ook bruikbaar in de infrastructuur, in cloud bijvoorbeeld (1). En het gaat verder dan dat.
Weg met die handjes!
Da's leuk, zo'n bak literatuur, maar wat héb je daar aan? Nou, het helpt bij het systematisch bepalen van de maximale uitstraling van een 'change'. Het laat zien waar de buffers zijn, de branddeuren, op basis van afhankelijkheden tussen processen, software en onderliggende infrastructuur. Eén nadeel: het werkt alleen als je automatiseert. Geen handmatige installaties dus, maar volautomatische 'deployments' (Gek hè? Dan heet het ineens 'deployments'). Dat kan alleen als je standaardiseert. Dáárom blijven we zo hameren op standaardisatie, niet omdat het kán, maar omdat het moét.
Ja... en nu?
Nu wil ik graag vertellen wat dat betekent. Wat is de volgende stap? Maar dan wordt deze blog wel erg lang. Een tipje van de sluier is: niet meer praten in termen van virtuele machientjes, operating systems, middleware componenten, maar in termen van complete applicatie-topologiën. Ik kom hier op terug!
Richard Bliek.
(1) Bliek, R. (2016). Change Impact Analysis in Cloud. Universiteit Twente.
(2) Perrow, C. (2011). Normal accidents: Living with high risk technologies. Princeton University Press.
Dingen gaan soms fout. Iemand wordt ziek. De auto gaat stuk. En soms brandt er iets af. Dat vinden we allemaal niet leuk. En we doen vanalles om te voorkomen dat het gebeurt. Voorkomen is immers beter dan genezen. Maar dingen gáán soms fout. Soms moét je genezen, soms moét je repareren, soms moét je brand blussen.
Bluster
Repareren, genezen en blussen dus. Je ontkomt er niet aan. Maar je kunt nóg iets doen. Je kunt proberen het effect te verkleinen, ofwel zorgen dat het niet uit de hand loopt, dat je reserve-onderdelen op de plank hebt, dat vuur niet al te hard om zich heen grijpt en alles in de as legt voordat je aan blussen toe komt. Je bouwt zekerheden in, je bouwt buffers. Een soort van branddeuren dus.
IT grijpt om zich heen
Als er ergens iets stuk gaat, een computer, een database, opslag, hoe zorg je dan dat je daar weinig last van hebt? Dat niet ineens niemand meer kan inloggen, dat een grote groep niet meer kan werken? (Van sommige groepen wíl je wel es dat ze niet konden werken, maar dat terzijde.) Of wanneer iemand iets verknalt, en dat hoeft niet eens met opzet, hoe zorg je ervoor dat je niet meteen al je gegevens kwijt bent? Wanneer er een boefje bezig is, hoe voorkom je dat je niet ineens zo’n 80 miljoen minder te besteden hebt?
De wereld is plat
Welke zekerheden bouw je in? Veel doen we al door middel van scenario analyses. Die zijn vaak van het type “als dit gebeurt, dan volgt er dat en dan doen wij zus, en dan gebeurt er zo”. Heel slim om te doen. Maar dit is wel gebaseerd op aannames. We gaan er namelijk vanuit dat wij precies weten dat dat volgt op dit en dat zus dat altijd voorkómt, omdat zo ook altijd volgt op zus. Het is een soort van zelfoverschatting. Het gaat uit van lineaire verbanden… het gaat uit van plat.
Mag ik een vuurtje?
De verbanden zijn vaak juist vérre van lineair. En met de huidige ontwikkelingen maken we dit nóg erger. Zeker ook omdat ontwikkelingen van steeds meer kanten komen. Hoe bepaal je dan de maximale impact van bijvoorbeeld een brandje? Brand is eigenlijk vergelijkbaar met het stuk gaan van een cloud-onderdeel, een fintech (bingo!) die op de de fles gaat of een bepaalde oplossing die we gebruiken wordt van de markt gehaald. Met enig inlevingsvermogen zou je brand kunnen zien als een vorm van een 'change' (pyromanen plannen ook).
Change Impact Analysis
Brand is gewoon een 'change'. En van élke 'change' wil je de maximale impact bepalen, vóórdat je 'm uitvoert. Je wilt van élke change op voorhand weten: tot hoever fikt het, hoe ver breidt het vuur zich uit, wat is de maximale uitstraling? Waar zitten de branddeuren? Hierover is een hele bak aan literatuur geschreven, allemaal onder de noemer 'Change Impact Analysis'. Die literatuur is vooral gericht op software ontwikkeling, maar het is ook bruikbaar in de infrastructuur, in cloud bijvoorbeeld (1). En het gaat verder dan dat.
Weg met die handjes!
Da's leuk, zo'n bak literatuur, maar wat héb je daar aan? Nou, het helpt bij het systematisch bepalen van de maximale uitstraling van een 'change'. Het laat zien waar de buffers zijn, de branddeuren, op basis van afhankelijkheden tussen processen, software en onderliggende infrastructuur. Eén nadeel: het werkt alleen als je automatiseert. Geen handmatige installaties dus, maar volautomatische 'deployments' (Gek hè? Dan heet het ineens 'deployments'). Dat kan alleen als je standaardiseert. Dáárom blijven we zo hameren op standaardisatie, niet omdat het kán, maar omdat het moét.
Ja... en nu?
Nu wil ik graag vertellen wat dat betekent. Wat is de volgende stap? Maar dan wordt deze blog wel erg lang. Een tipje van de sluier is: niet meer praten in termen van virtuele machientjes, operating systems, middleware componenten, maar in termen van complete applicatie-topologiën. Ik kom hier op terug!
Richard Bliek.
(1) Bliek, R. (2016). Change Impact Analysis in Cloud. Universiteit Twente.
(2) Perrow, C. (2011). Normal accidents: Living with high risk technologies. Princeton University Press.