Wanneer individuen overwegen om betrokken te raken bij SRE en teams denken aan het invoeren van SRE-procedures, is een veelvoorkomende vraag die wordt gesteld: 'Moet u weten hoe u code moet uitvoeren?'
Het korte antwoord: ja.
Maar het volledige antwoord is iets genuanceerder. Laten we eens kijken naar drie plaatsen waar code in het spel komt in sitebetrouwbaarheidstechniek, samen met het niveau van coderingsexpertise die vereist is voor elke site. Deze lijst is niet voltooid, maar deze scenario's zijn enkele van de meest voorkomende gebruiksvoorbeelden.
Scenario 1: Toil verwijderen via automatisering
Sitebetrouwbaarheidstechnici en anderen die SRE-procedures gebruiken, proberen waar mogelijk toil te verwijderen. "Toil" betekent een specifiek ding in SRE. Toil verwijst naar bewerkingen die worden uitgevoerd door een mens die bepaalde kenmerken heeft. Toil heeft geen meerwaarde op de lange termijn. Het helpt de service niet op een betekenisvolle manier vooruit. Het is vaak repetitief en grotendeels handmatig (hoewel het kan worden geautomatiseerd). Naarmate de service of het systeem groter wordt na verloop van tijd, neemt het aantal aanvragen voor dat systeem waarschijnlijk ook evenredig toe en is er zelfs nog meer handmatig werk vereist.
Als een service bijvoorbeeld vereist dat het SRE-team elke week iets opnieuw instelt, of nieuwe accounts en schijfruimte handmatig inricht, of herhaaldelijk opnieuw opstarten met de hand, is dit een operationele belasting die toil is. Het uitvoeren van deze acties heeft de service niet op een langdurige, permanente manier beter gemaakt. Deze acties moeten waarschijnlijk steeds worden herhaald.
SRE's hebben een hekel aan toil. Ze proberen om het zoveel en indien mogelijk te voorkomen. Dit is een van de gevallen waarin automatisering een rol gaat spelen in SRE. Als deze aanvragen automatisch kunnen worden verwerkt, zorgt dit ervoor dat het team kan werken aan meer belonende en impactvolle dingen.
Coderingsexpertise: automatisering vereist enige coderingsexpertise, maar het hoeft geen volledige vaardigheden op het gebied van software-engineering te vereisen. Als u kleine scripts (mogelijk in PowerShell of Bourne Shell) kunt schrijven of zelfs als u een logische Azure-app met nauwelijks code maakt, kan deze app nog steeds helpen om toil te elimineren.
Scenario 2: Beheren via API's/domeinspecifieke talen (DSL's)/sjablonen
Hoewel SRE niet strikt noodzakelijk is om omgevingen te beheren via API's, DSL's en sjablonen (met name cloudomgevingen), kunnen SRE's hun werk omhoog schalen. Inrichtings-/de-inrichtingsinfrastructuur, het configureren van bewaking en het integreren van verschillende services wordt veel efficiënter via codering.
Coderingsexpertise: net als in het vorige scenario vereist dit enige coderingsexpertise, maar het hoeft geen volledige vaardigheden op het gebied van software-engineering te vereisen. Naast de scripts en logische apps die eerder zijn genoemd, kunnen Azure Resource Manager-sjablonen ook worden gebruikt met minimale coderingservaring.
Scenario 3: De code herstellen
Sitebetrouwbaarheidstechnici willen de betrouwbaarheid van een systeem verbeteren. Dit doel vereist soms graven in de broncode van een systeem, het vaststellen van het probleem en het vaak bijdragen aan een oplossing voor de codebasis. Hoewel het niveau van verfijning van dit werk sterk kan variëren op basis van de situatie, is coderingsexpertise in deze gevallen een absoluut vereiste.
Coderingsexpertise: in dit scenario is vaak volledige expertise op het gebied van software-engineering vereist.
Volgende stappen
Bent u geïnteresseerd in meer informatie over sitebetrouwbaarheidstechniek en werk met weinig code? Bekijk onze site reliability engineering hub, de productdocumentatie die hierboven is gekoppeld.