Site Reliability Engineering (SRE) is al bijna twintig jaar een veelgebruikte methode voor het verbeteren van de betrouwbaarheid, efficiëntie en veiligheid van hooggeschaalde platforms. Toch is deze methode niet zo bekend als DevOps, dat er wel aan verwant is. Vladyslav Ukis, hoofd R&D bij Siemens Healthineers, heeft een boek over dit onderwerp geschreven. We spraken met hem over SRE, digitale transformatie, DevOps, cyberbeveiliging en hoe je de voordelen van SRE effectief kunt communiceren richting hoger management.
Wat is de plaats van SRE binnen je carrière?
“Ik heb binnen Siemens Healthineers veel transformaties begeleid met betrekking tot de introductie van continuous delivery, SRE, developer relations, portfolio management en data-driven engineering management; allemaal disciplines die nodig zijn als je grote digitale transformaties aanpakt in een grote onderneming. Ik heb daar dus veel ervaring opgedaan, zowel op het gebied van platformen als op het gebied van applicaties.”
“Ongeveer tien jaar geleden zijn we begonnen met het bouwen van het Siemens Healthineers digitale gezondheidsplatform – teamplay – ons eerste software-as-a-service product. Daarvóór werd alle software verkocht als product, niet als dienst. Het was ook ons eerste cloudgebaseerde product. Als bedrijf begonnen we te leren wat het betekent om software-as-a-service aan te bieden in plaats van software als product. En daarmee realiseerden we ons dat we de service moesten exploiteren om een kwaliteit van dienstverlening te kunnen bieden die verkocht kan worden.”
“SRE is een opiniërende implementatie van de DevOps-filosofie op operations-gebied”
“We begonnen nogal wat problemen te krijgen met het exploitatie van de diensten, vooral toen de vraag toenam. We realiseerden ons dat de manier waarop we de diensten exploiteerden ons niet de toekomst zou brengen. En op een gegeven moment begon ik me te verdiepen in SRE. Veel bedrijven claimden succes in de bedrijfsvoering door het in te zetten. Het was nieuw terrein voor ons. We wilden graag iets nieuws proberen.”
“Nadat ik veel ervaring had opgedaan met onze SRE-implementatie, begon ik artikelen te publiceren over de verschillende aspecten van SRE-implementatie op infoq.com. En op een gegeven moment kwam er een uitgever langs die vroeg: “Wil je dat artikel niet uitbreiden tot een boek?”. Ik zei: ‘Nou, ik ben geen schrijver, en ik heb geen tijd.’ Toen kwam Corona. En toen realiseerde ik me ineens dat ik tijd had omdat ik niet hoefde te pendelen, wat een uur enkele reis is. Zo is het boek tot stand gekomen.”
Site Reliability Engineering kan een verwarrende term zijn. Wat houdt het in, waar dient het niet voor en wie kan het gebruiken?
“SRE is een discipline binnen de informatica die uitlegt hoe je services betrouwbaar op schaal kunt laten draaien. Dus als je services beheert, is SRE waarschijnlijk een heel goede methodologie om ze betrouwbaar te laten werken. Google heeft de operationele praktijken die ze hadden, samengebracht onder de paraplu van SRE. Zij zijn de vader van de discipline.”
“Als je veel legacy hebt, ben je vast op de een of andere manier op weg naar digitale transformatie. Je gaat waarschijnlijk dat wat je hebt, transformeren tot iets dat beter te beheren is. En daarbij zet je meestal diensten in de cloud in, die je vervolgens als dienst aanbiedt aan je gebruikers. Als je eenmaal diensten in de cloud aanbiedt, ga je vroeg of laat nadenken over hoe je ze moet beheren. Hier komt SRE van pas, omdat het een methodologie is om services betrouwbaar op schaal te laten werken.”
SRE is niet zo bekend als DevOps. Kun je de verschillen tussen de twee begrippen uitleggen?
“Ze zijn aan elkaar gerelateerd. DevOps is een overkoepelende filosofie om ontwikkelaars en operations engineers te laten samenwerken en veel frequenter producten op te leveren. Maar DevOps vertelt je niet hoe je dit precies moet doen – dit is waar SRE om de hoek komt kijken. SRE is een opiniërende implementatie van de DevOps-filosofie op operations-gebied. Het geeft specifieke richtlijnen over wat elke partij moet doen om die samenwerking tot stand te brengen. DevOps is de filosofische basis: ontwikkelaars en operations engineers moeten niet in silo’s werken, maar samenwerken. SRE komt bovenop dit fundament.”
Kun je verduidelijken wat SRE-transformatie is en hoe het zich verhoudt tot digitale transformatie?
“Als onderdeel van een digitale transformatie zal je veel dingen behandelen, beginnend bij het bedrijfsmodel en ergens eindigend bij operations. En waar je met operations naartoe gaat, daar komt SRE om de hoek kijken. Wat bedrijven meestal niet hebben als ze nog niet zijn begonnen met het transformeren van operations als onderdeel van hun digitale transformatie, zijn ontwikkelingsteams met operations-capaciteiten. Hun ontwikkelingsteams ontwikkelen alleen software. En hun operationele teams beheren meestal alleen de diensten. Het is de typische kloof tussen ontwikkeling en operations.”
“Als onderdeel van de digitale transformatie ga je richting DevOps. En dat betekent dat je operationele aspecten naar de ontwikkelingsteams brengt en dat je ontwikkelingsaspecten naar de operationele teams brengt. Waarom? Volgens de DevOps- en SRE-filosofie wil je dat ontwikkelaars en operations engineers samenwerken. Operations engineers zijn niet meer noodzakelijkerwijs volledig verantwoordelijk voor de werking van de services. Ze zijn verantwoordelijk voor het leveren van een framework of SRE-infrastructuur voor de ontwikkelteams, zodat ze de services in productie kunnen draaien.”
Vladislav Ukis
“Aan de ontwikkelkant transformeer je dan de ontwikkelaars; ze ontwikkelen niet alleen maar om de services vervolgens over te dragen aan het operations team, maar ze ontwikkelen de services en doen ook de operatie. Om hun leven gemakkelijker te maken, gebruiken ze de SRE-infrastructuur die door de operations-teams wordt geleverd om de operaties efficiënt uit te voeren. Dat gezegd hebbende, hoeven ze niet per se midden in de nacht wakker te worden om hun diensten te draaien. Dit kan anders worden geregeld op basis van afspraken met de operations-teams.”
“Het is dus een grote verschuiving, omdat je in de operations-teams opeens ontwikkelingsvaardigheden moet stoppen, zodat ze de SRE-infrastructuur kunnen ontwikkelen die de ontwikkelingsteams in staat stelt om operations te doen. De operations-teams komen meestal uit de wereld waar ze de services exploiteren. En nu wordt hen niet meer gevraagd om de services te doen, maar om anderen in staat te stellen de operations te doen. Aan de kant van het ontwikkelteam vraag je ze dan om ontwikkeling, testen en operations te doen. Ze zijn volledig verantwoordelijk voor de werking van de diensten in productie.”
“Maar de wereld is natuurlijk niet zwart-wit. Er zijn tussenvormen mogelijk. De ontwikkelteams zijn bijvoorbeeld op afroep beschikbaar voor hun diensten, maar alleen tijdens kantooruren. Daarbuiten kan er een regeling zijn waarbij het operations-team de diensten ondersteunt, of een andere regeling tussen de ontwikkel- en operations-teams.”
“Operations engineers zijn niet meer noodzakelijkerwijs volledig verantwoordelijk voor de werking van de services”
Bovendien betrek je als onderdeel van de SRE-transformatie ook het productmanagement bij de operations, wat traditioneel nooit het geval is geweest. In het SRE-model krijgt het productmanagement de juiste zichtbaarheid in hoe de services in productie draaien, zodat ze datagestuurde, geïnformeerde beslissingen kunnen nemen over wanneer te investeren in betrouwbaarheid versus wanneer te investeren in nieuwe functies.
Kun je de relatie tussen SRE en cyberbeveiliging uitleggen? Is die er?
“Absoluut. SRE houdt zich dus bezig met operaties in het algemeen. En natuurlijk is een groot deel daarvan het veilig uitvoeren van de services. Wanneer er zich incidenten voordoen in de productie, kunnen dat cyberbeveiligingsincidenten zijn. Wanneer deze zich voordoen, zal er binnen het SRE-raamwerk een incident-responsproces zijn dat bepaalt hoe de organisatie de mensen mobiliseert voor een bepaald incident. Hoe lost de organisatie het incident op? Hoe leert de organisatie van post-mortems? En in dat incident-responsproces kunnen er aanvullende bepalingen zijn. Overheidsorganisaties of sector-vertegenwoordigende organisaties moeten mogelijk op de hoogte worden gebracht als er sprake is van een ernstige inbreuk. Dit valt onder het algemene incident-responsproces dat nodig is als onderdeel van de introductie van SRE in de organisatie.”
Hoe ‘verkoop’ je SRE aan het leiderschap van de organisatie?
“Een manier om dit te doen is om je investering in SRE te presenteren als een inkomstenverzekering. Je krijgt alleen inkomsten uit je diensten als deze betrouwbaar zijn. Als je diensten vaak uitvallen, zal niemand ervoor betalen. Je hebt een verzekering nodig om je inkomsten te beschermen. De verzekeringspremie – een investering in SRE – zal net zo hoog zijn als je betrouwbaarheidseisen. Dus als je net zo betrouwbaar moet zijn als Google, dan zal het meer kosten dan wanneer je zo betrouwbaar moet zijn als Expedia. Je moet dus de juiste verzekering kopen om je inkomsten te beschermen.”
Equal Experts
Via teams in Duitsland, Bangalore en Lissabon werkt Equal Experts sinds 2018 met Siemens Healthineers samen aan het verbeteren van testautomatisering en het inbouwen van ‘compliance in de (CI/CD) pipeline’. Na een eerste discovery-periode gericht op het helpen van interne teams met een continuous delivery health check, bood Equal Experts coaching, ondersteuning en delivery capabilities voor de ontwikkeling van het Siemens Healthineers teamplay-platform – een suite van tools en applicaties voor het prestatiebeheer van medische-beeldapparatuur in de gezondheidszorg.
Teams van ontwikkelaars van Siemens Healthineers en Equal Experts leverden CI/CD-pijplijnen met infrastructure as code, hoge niveaus van geautomatiseerd testen, geautomatiseerde BDD-tests met SpecFlow en ontleding van systemen in eenvoudig te implementeren microservices: allemaal met het doel om compliance in the pipeline in te bouwen en de ontwikkelaarservaring te verbeteren, zodat teams zich minder hoefden te richten op ‘busywork’ en meer op de hoge innovatieniveaus die Siemens Healthineers tot marktleider maken.
Aangetoond is dat continuous delivery een aanpak is die enorme voordelen kan bieden op dit gebied en teams een hoge mate van wendbaarheid en vertrouwen kan geven bij het omgaan met de uitdagingen van het werken volgens strenge medische regelgeving. De teams zagen verbeteringen in de snelheid, maar ook in de kwaliteit van audits en operaties.
De teamleden van Siemens Healthineers hebben boeken geschreven en lezingen gegeven over hun successen.
