7 fundamenten voor geautomatiseerde IT-processen op het spoor
De meeste softwareregelingssystemen voor de spoorwegen zijn nog niet voorgesorteerd op het niveau van automatisering dat in de nabije toekomst haalbaar moet zijn. Dat stelt Julien Schmaltz, Principal Business Consultant bij CGI. Waarom is dat zo? Wat hebben we nodig om automatisering mogelijk te maken en in hoeverre zijn de benodigde technologieën hiervoor nu al voldoende doorontwikkeld? In dit artikel identificeert hij zeven fundamenten waarop het geavanceerde softwareregelingssystemen van de toekomst rust.
Waar gaan we heen met automatisering? Wat kunnen we in de nabije toekomst met processen als Continuous Delivery, CI/CD, Process Automation, Infrastructure-as-Code, Network-as- Code en AI Ops bereiken? Dat wil ik illustreren aan de hand van een toekomstscenario.
Stel je eens een softwarecomponent voor dat gegevens van de spoorse infrastructuur en bijvoorbeeld rijdend materieel doorstuurt naar andere componenten. Deze componenten zetten de ruwe gegevens om in informatie, zoals “trein nummer 123 bevindt zich op spoorsectie 456”. Die informatie is bedrijfskritisch, want zonder deze data kunnen treinbesturingen niet werken.
Hapert de software? Dan worden de treinen teruggestuurd naar de stations. Tot het probleem is opgelost, wordt het verkeer stilgelegd. Het kan dan uren duren voordat de treinen weer rijden. Laten we bij dit voorbeeld het tijdstip waarop het component uitvalt en stopt met het doorsturen van de gegevens ‘tijdstip T’ noemen. Een geautomatiseerd IT-systeem voor de spoorwegen zou dan op tijdstip T twee gebeurtenissen in gang zetten: (1) het starten van een herstelprocedure en (2) het aanmaken van een ticket in het IT Service Management systeem. Vervolgens gebeurt er dit:
- Binnen twee minuten na tijdstip T is de back-up component up & running en is de informatie weer beschikbaar voor de treinbesturing, met de waarschuwing dat het systeem zich in een hersteltoestand bevindt.
- Binnen twee minuten na tijdstip T, wordt het DevOps-team geactiveerd en werkt het aan een oplossing.
- Binnen twee uur na tijdstip T heeft het DevOps-team het probleem verholpen en kan het gerepareerde systeem getest worden. Na elementaire regressietesten is de oplossing binnen vijftien minuten bevestigd. Het gerepareerde systeem neemt het werk van het back-up component over. Na nog eens twee uur is alles grondig getest en het gerepareerde systeem blijft in productie.
7 fundamenten voor het geautomatiseerde spoor van de toekomst
Bovenstaand scenario vindt plaats in de toekomst. Bij grote incidenten staan de treinen dan maximaal twee minuten stil. Een meer dan acceptabel scenario. Want nu, in 2023, zou bij dergelijke gebeurtenissen het verkeer urenlang stilleggen. Waarom is dat zo? Dat is naar mijn mening terug te voeren op zeven fundamenten waarop het geavanceerde systeem uit mijn toekomstscenario steunt.
Test Automation
Het zal geen verrassing zijn dat dit een van de fundamenten is. De mogelijkheid om software automatisch te testen, van unit-tests tot integratie- en acceptatietests, is een must. Voor wie nog niet zo ver is: maak hier dan prioriteit nummer één van.
Continuous Deployment
Mijn toekomstscenario is alleen mogelijk als wijzigingen in de software volledig automatisch doorgevoerd kunnen worden en direct ‘live’ kunnen gaan. Oftewel: zodra een wijziging in de code is goedgekeurd, verlopen alle stappen – van ‘pull request’ tot en met ‘deployment’ en inclusief tests – geautomatiseerd.
Test selection strategies
Om de doorlooptijd te verkorten, zijn verschillende strategieën nodig. In mijn voorbeeld is er een lichtgewicht teststrategie en een zware. De lichtgewicht testsuite bevestigt de probleemoplossing en voert elementaire regressietests uit om ervoor te zorgen dat de kernfuncties beschikbaar blijven.
Smart monitoring
In het voorbeeld is de softwarecomponent up & running; de CPU- en geheugenprofielen zijn zoals gebruikelijk. Het component is weliswaar nog operationeel, maar functioneert niet meer. Het stuurt immers geen berichten meer door. Om verder te gaan met automatisering moet de bewaking zodanig worden opgezet dat deze functionele fouten worden opgevangen.
Hyper automation: Coupling systems together
Om de volgende stappen te nemen in automatisering, is het essentieel om systemen als monitoring, infrastructuur en IT Service Management (ITSM) aan elkaar te koppelen. Deze koppeling van systemen vormt een uitdaging voor het beveiligingsbeleid, bijvoorbeeld het beleid om kritieke netwerkdomeinen te isoleren. Gewoonlijk zijn ITSM en de kritieke infrastructuurdomeinen strikt gescheiden. Deze scheiding kan een belemmering vormen voor automatisering. Organisaties moeten hun architectuur en beleid aanpassen om automatisering mogelijk te maken en tegelijkertijd de veiligheid van de vitale infrastructuren te waarborgen.
Verder zijn er ook ‘event-driven’ architecturen nodig. In het toekomstscenario veroorzaakt de gebeurtenis “component mislukt” de gebeurtenissen “herstelprocedure uitvoeren” en “dringend bugrapport aanmaken”. Ook deze gebeurtenissen moeten netwerkgrenzen overschrijden, bijvoorbeeld om het niet-kritische domein van IT-diensten te verbinden met het kritische domein van de vitale infrastructuur.
Recovery procedures
Het systeem moet worden ontworpen met herstel in gedachten. Wat zijn goede back-up componenten? Dat kunnen eerdere versies zijn, een kale minimale versie, of een gouden versie waarvan bekend is dat die correct is, maar mindere prestaties levert. Zijn deze ‘recovery procedures’ goed genoeg om het werk voor even over te nemen?
Mission critical systems in recovery mode
Wanneer de back-up component werkt, betekent dit niet dat het hele IT-systeem draait zoals het normaal draait. De vereiste informatie wordt weliswaar aan de verkeersleider verstrekt, maar met een lager vertrouwensniveau. Het bedrijfskritische IT-systeem draait immers enige tijd in een “herstelmodus”. Een interessante vraag is wat hier aanvaardbaar is. Het systeem moet veilig genoeg zijn om te kunnen worden gebruikt én tegelijkertijd de gevolgen van het incident zo veel mogelijk beperken.
Een mogelijke strategie
Bovenstaande zeven fundamenten zijn in mijn optiek nodig om het geavanceerde automatiseringssysteem uit mijn toekomstscenario mogelijk te maken. De meeste hiervan zijn geen “rocket science”. De benodigde technologieën zijn nu al beschikbaar. Wat we wel nog nodig hebben, zijn organisaties en mensen die deze processen kunnen toepassen. Daarnaast moeten we diverse essentiële ontwerpuitdagingen aanpakken, zoals de hierboven al aangestipte teststrategieën, herstelprocedures en de koppeling van automatiseringssystemen. Om grote sprongen te maken, moeten we deze uitdagingen parallel aanpakken. Een mogelijke strategie daarbij zou het starten van volgende twee programma’s kunnen zijn:
- Automatisering van test en levering: bij dit programma staan testautomatisering, een continue serie van geautomatiseerde processen en teststrategieën centraal. Dit programma werpt licht op de belangrijkste stappen om het testen en opleveren van software te automatiseren.
- Koppeling systemen en monitoring: bij dit programma werk je aan de koppeling van monitoring, ITSM en je favoriete automatiseringsplatform. Je kunt het beste beginnen met een eenvoudige use-case, want de koppeling zal je huidige architectuur en beveiligingsbeleid flink op de proef stellen. Om verder te bouwen aan automatisering zul je eerst initiële structuren en omgevingen moeten creëren. En juist het leggen van die basis is het moeilijkste deel. Maar wees gerust: zodra je de deur voor automatisering hebt geopend, komt er snel meer!
Deel jouw toekomstbeelden, fundamenten en uitdagingen
In gedachte-experiment schetste ik een futuristisch, maar toch concreet voorbeeld en inventariseerde wat er volgens mij nodig is om van het toekomstbeeld de werkelijkheid te maken. Dat leidde tot zeven fundamenten en een strategie om de volgende automatiseringsstappen te nemen. Ik daag je bij deze uit om ook een toekomstscenario te bedenken waarin automatiseringsprocessen als Continuous Delivery, CI/CD, Process Automation, Infrastructure-as-Code, Network-as- Code en AI Ops de hoofdrol spelen. Wellicht kunnen we samen brainstormen over de mogelijke fundamenten en uitdagingen.
Lees ook:
Dingen automatisch doen kan nooit een doel op zich zijn. Wat vooral voor het spoor relevant is, is het aantrekkelijker maken van het spoorvervoer.
Overigens (maar zeker niet terzijde!) is de huidige stilleggingsproblematiek bij NS bijna niet meer van IT-technische aard, maar van bedrijfslogistieke en beleidsmatige aard.