Underhåll av DevOps-verktyg på AWS: 5 steg för maximal effektivitet

Hur nätverkar, driver och underhåller du dessa helt olika verktyg så att de fungerar tillsammans? Och hur gör du det utan att dina molnkostnader skenar?

Din DevOps-verktygskedja kan lätt bli ditt mest kritiska system, eftersom allt går genom den. Om systemet ligger nere kan du inte driftsätta något någonstans.

Underhållet tar aldrig slut, så det finns gott om möjligheter att göra helt fel – både i dag och i morgon. Tro mig, jag har hjälpt företag att hantera sina DevOps-verktyg i många år och vet var företagen går fel när det gäller DevOps-verktyg på AWS.

Följer du mina fem steg nedan sparar du både dig själv och ditt företag mycket pengar och huvudbry när du underhåller dina verktyg på AWS.

Vi går direkt till det första:

Steg 1: Utforma ditt molnnätverk och dina funktioner

Precis som andra system är AWS inte perfekt. Du har lastbalanserare, subnät och olika nätverk som behöver kommunicera med varandra.

Du vill begränsa hur exponerat ditt nätverk är. Alla tjänster ska inte vara synliga överallt för alla, så du delar upp det i olika delar.

Ett exempel

I AWS finns det olika sätt att koppla samman två konton i ett nätverk så att två team kan arbeta i sina egna konton. Vissa av dessa sätt är bra och andra är dåliga.

Du skulle kunna använda ett virtuellt privat moln som kopplar ihop två konton. Problemet med det här tillvägagångssättet är att nätverken kommunicerar för mycket med varandra. Du kan inte enkelt styra trafiken, så när du börjar göra detta i stor skala kan allt fallera helt. Alla nätverk kommunicerar med varandra.

Det finns nu en bättre teknik för detta som vi använder och som löser problemet i stor skala: transit gateways. Nya tekniker som denna dyker upp hela tiden för att lösa molnets problem.

Viktiga områden inom molnnätverk och funktioner

När vi pratar om att utforma ditt molnnätverk och dina funktioner är följande områden viktigast att titta på:

• Användaråtkomst: hur användare får åtkomst till ditt system.

• Internt system: hur systemet kör sig självt och vad som finns i det.

• Maskin-till-maskin-nätverk: du kanske har sådant som exempelvis Jenkins och GitLab behöver driftsätta.

• Anslutningar till on-premise: även om detta blir mindre viktigt med tiden kanske du har något som behöver ansluta till on-premise.

Nätverk är grunden för all säkerhet. Gör du det rätt är allt säkert redan från början. Men gör du fel är ingenting längre säkert, eftersom allt är öppet för alla. Det spelar ingen roll vad du gör: om dina nätverk är öppna kan du inte lösa problemen i efterhand. Du måste också rätta till anslutningarna, vilket innebär att du får skriva om saker om och om igen.

Gör du fel ökar dina kostnader i AWS, och felsökningen blir svår. Du kommer aldrig att veta vad som fick systemet att sluta fungera.

Konkreta råd

• Säkra dina endpoints! Skydda dem bakom lastbalanserare och exponera dem aldrig direkt.

• Skapa grupper med minsta möjliga åtkomst.

• Skapa ramverk och mallar som människor kan använda, samt färdiga behörighetsmodeller.

• Skanna och testa kontinuerligt för att upptäcka vad som fortfarande är öppet.

• Gör Infrastructure-as-Code till er grundprincip.

• Inför inte allt på en gång – gör det stegvis när ni vet att något fungerar.

Säkra era endpoints! Skydda dem bakom lastbalanserare och exponera dem aldrig direkt.

Skapa grupper med minimal behörighet.

Skapa ramverk och mallar som andra kan använda, samt färdiga behörighetsmodeller.

Skanna och testa kontinuerligt för att upptäcka vad som fortfarande är öppet.

Gör Infrastructure-as-Code till er grundprincip.

Inför inte allt på en gång – gör det stegvis när ni vet att något fungerar.

Steg 2: Få ordning på er Infrastructure-as-Code

Det är här er kod redan finns, i ert Git-repository (eller repository utan Git) – er infrastruktur bör finnas på samma plats. Ni vill kunna se vad som har ändrats, vem som gjorde ändringen och vad den påverkar. Då kan ni planera, skapa ett granskningsspår och enklare återskapa saker.

Om ni gör fel här kommer ni att ägna er åt ClickOps, klicka runt i användargränssnittet och sedan går allt sönder. Ni vet inte vad som har ändrats och kan inte enkelt gå tillbaka till er IaaC.

I det här scenariot styr infrastrukturen er, i stället för att ni styr infrastrukturen. Om systemet inte versionshanteras måste ni göra det oföränderligt. Men det är inte oföränderligt.

Viktiga områden inom Infrastructure-as-Code

Ni bör se över hela er infrastruktur, men mycket handlar i slutändan om:

• Moduler: mallarna som ni återanvänder, eftersom ni inte vill skriva om allt från början – det leder till fel. Ni kan skapa egna moduler, men jag rekommenderar att ni använder de officiella för att göra det enklare för andra att skapa liknande mallar.

• Tydliga filer: standardisera filnamnen och sättet ni driftsätter allt på. Om ni till exempel bestämmer er för att använda Terraform ska ni bara använda Terraform, inte ha hälften i ett annat system. Försök inte hantera två språk i ett och samma team.

• Kodgranskningar: ha någon form av automatisering och se till att den finns kvar i systemet. Terraform använder till exempel ”states”, där ni kan se vad som ändras medan ni gör det. Det hindrar er från att råka ta bort något.

• Uppgraderingar: er IaaC kan snabbt bli inaktuell. Uppdatera den löpande så att ni inte fastnar på en gammal version som saknar support eller helt enkelt inte längre fungerar.

Om ni inte gör detta kan det orsaka alla möjliga problem. Er IaaC är något levande som ni ständigt behöver uppdatera och utveckla.

Det här är inte enkelt. Ni dokumenterar hela er infrastruktur i förväg. I stället för att förlita er på automatisering måste ni definiera och specificera hur er infrastruktur ska se ut. Från början behöver ni besluta: ”det här ska vi driftsätta” och ”så här ska det vara”.

Praktiska råd

Följ vedertagna kodstandarder i stället för att se detta som skriptning. Med bra kodstandarder får ni god ordning på er IaaC.

Steg 3: Planera trafik och migrering

Som jag nämnde i steg 1 ovan blir det snabbt dyrt om ni får fel på nätverket. Trafik handlar också om nätverk: vad som går in och ut på övergripande nivå.

Om ni har många artefakter – säg 6 TB data – och kontinuerligt flyttar 2 TB in och ut ur molnet, kommer kostnaderna att skjuta i höjden. Det är billigare att lägga data i molnet, men dyrt att hämta ut den ur molnet.

Du behöver alltså fundera på ”vad försöker jag göra?” och ”kan jag planera trafiken bättre?”.

Detta hänger också ihop med migrering, eftersom du behöver fundera på ”hur ska jag migrera data från on-premise till molnet?”. Allt kommer så småningom att hamna i molnet, så du behöver planera hur du kan få det att ske så kostnadseffektivt och effektivt som möjligt.

Viktiga områden inom trafik och migrering

Det finns många mindre delar att hantera, men låt oss fokusera på de viktigaste områdena som du har störst nytta av. De är:

• Anslutningar och integrationer: vilka har du? I dagens DevOps är du ansluten till flera olika punkter. Vad driftsätter du och vad går genom CI/CD-systemet? Vad finns, och vad bör finnas, i molnet? Och om något inte bör finnas i molnet behöver du en smart plan för det.

• Åtkomsthantering: du behöver en tydlig metod för att avgöra vem som ska ha åtkomst till vad och var.

Anslutningar och integrationer: vilka har du? I dagens DevOps är du ansluten till flera olika punkter. Vad driftsätter du och vad går genom CI/CD-systemet? Vad finns, och vad bör finnas, i molnet? Och om något inte bör finnas i molnet behöver du en smart plan för det.

Åtkomsthantering: du behöver en tydlig metod för att avgöra vem som ska ha åtkomst till vad och var.

Om du inte planerar för trafik och migrering kommer du att få stora, onödiga kostnader.

Du riskerar också långsamma svarstider och en sämre användarupplevelse, vilket sannolikt är motsatsen till vad du ville uppnå när du från början bestämde dig för att flytta till molnet. I stället för att förenkla saker lägger du till fler komplexitetsnivåer i molnet och saktar ner allt.

Det svåraste med att planera för trafik och migrering är att … tja, det är förmodligen inget du har tänkt särskilt mycket på tidigare. Det är alltså inte raketforskning, men det är nytt. Och nya saker är svårare.

Konkreta råd — en enkel process i tre steg:

1. Börja med att analysera vilka integrationspunkterna är och var de finns.

2. Se hur mycket data som berörs — det kan du mäta.

3. Fundera på vad du försöker åstadkomma, vad som är viktigt vid varje integration och vilket som är det enklaste sättet att nå dit. ”Kan vi enkelt flytta det dit, och påverkar det användarupplevelsen?”

Börja med att analysera vilka integrationspunkterna är och var de finns.

Se hur mycket data som berörs — det kan du mäta.

Fundera på vad du försöker åstadkomma, vad som är viktigt vid varje integration och vilket som är det enklaste sättet att nå dit. ”Kan vi enkelt flytta det dit, och påverkar det användarupplevelsen?”

Steg 4: Hantera övervakning, åtkomst och loggar

Det här är ganska självklart, men i grunden behöver du kontroll och spårbarhet i molnet. Du behöver veta vad som händer i systemet. Vem fick åtkomst till vad och när, och vad gjorde de? För det behöver du loggar och åtkomsthantering.

För att veta om något har slutat fungera behöver du också övervakning. Om du flyttar till molnet och till exempel använder ett system för automatisk skalning, behöver du ha övervakningen på plats. I molnet övervakar du inte ”bara” något: du använder övervakningsdata för att styra vad din infrastruktur faktiskt gör.

Om du inte hanterar din övervakning kan du till exempel få driftstopp under ett större evenemang, eftersom du inte tog hänsyn till att du behövde skala upp före evenemanget.

Viktiga områden inom övervakning, åtkomst och loggar

Vi kan enkelt dela upp dessa nyckelaktiviteter i två delar:

• Observerbarhet: du följer hur saker fungerar.

• Spårbarhet: du tar reda på vem som gjorde vad. Om systemet till exempel blir långsamt och det inte finns något i spårbarhetsloggarna, pågår det sannolikt något annat i systemet som behöver din uppmärksamhet.

Observerbarhet: du övervakar hur saker fungerar.

Spårbarhet: du tar reda på vem som gjorde vad. Om systemet till exempel blir långsamt och det inte finns något i spårbarhetsloggarna, pågår det sannolikt något annat i systemet som behöver din uppmärksamhet.

Om du inte gör detta vet du helt enkelt inte om ditt system ligger nere eller vem som orsakade det. Du vet inte heller vilka säkerhetshot du står inför.

En av poängerna med molnet är att du har ett system som kan driftsättas på nytt flera gånger. En del av arbetet går inte att hantera om informationen inte lagras någon annanstans. Du kan inte övervaka systemet om det ligger nere, eller veta vad som hände precis innan det gick ner, eftersom du redan har tagit bort den felaktiga delen. Och om systemet blir långsamt kan du inte reagera i tid för att åtgärda det, eftersom det redan har tagits bort genom auto-skalning. Därför behöver du lagra mätvärden och loggar utanför systemet för att effektivt felsöka eventuella problem i systemet.

Men övervakning är inte enkelt. I grund och botten har du två alternativ:

1. Du har alldeles för mycket information

2. Du har för lite information

Du har alldeles för mycket information

Du har för lite information

Om du har för mycket information kommer du inte att göra något med den – som med en bok på 10 000 sidor som du knappt vågar öppna. Jämför det med en bok på 50 sidor som inte ger dig tillräckligt med information för att vara värd besväret.

Utmaningen är att få rätt mängd användbar information utan att den förvirrar dig.

Det finns mängder av ”beprövade metoder” på internet, men här är några enkla och:

Handlingsbara råd

• Tricket är att börja med ”för mycket” information och sedan skala ner tills du har för lite. Därefter skalar du upp igen tills du upptäcker hur mycket som är ”tillräckligt”. Det här är en process av försök och misstag. Det finns inga gyllene regler, så du måste hitta det som fungerar i varje enskilt fall.

• Se till att övervaka dina endpoints. Om de ligger nere är dina tjänster inte tillgängliga för användarna, även om tjänsten eller koden fungerar. (Det uppskattar användarna inte alls.)

Steg 5: Hantera löpande underhåll och förvaltning

Du driftsätter inte bara dina tjänster en gång och låter dem sedan köra. Det finns alltid en löpande kostnad för att driva dem.

Den här kostnaden omfattar till exempel tjänstesupport, bibliotek och system som har nått end of life, integrationer och IP-vitlistning – för att bara nämna några av alla löpande underhållsaktiviteter som krävs för din infrastruktur.

Om du bara lämnar din IaaC som den är blir den snabbt gammal och slutar till slut att fungera.

Du behöver löpande underhåll, vilket kräver resurser. De flesta av dessa behov kan tillgodoses med AWS-teknik, men du behöver fortfarande följa upp och hantera dem. Precis som all annan teknik når även dessa AWS-lösningar så småningom sin egen end of life.

Viktiga områden inom underhåll och förvaltning

Ditt ansvar för underhåll och förvaltning kan delas in i följande delar:

• Säkerhet: helt enkelt hur du upprätthåller säkerheten.

• Underhållbarhet/framtidssäkring: precis som med all IaaC behöver du säkerställa att du även framöver kan göra ändringar i systemet. När det blir för gammalt kan du inte ens uppgradera det längre.

• Kunskap om din mjukvara och arkitektur: du behöver veta vad du ska göra för att säkerställa att den fortsätter fungera.

• Säkerhetskopiering och generell datahantering: säkerställ att ditt system säkerhetskopieras och fungerar, samt att data är tillgängliga även om en region slås ut.

• Övervakning: även detta är en del av underhållet. Någon behöver följa vad övervakningsdata visar, kontrollera att den stämmer och se om något behöver åtgärdas.

Om du misslyckas med detta underhåll får du ett system som alla känner till, men som ingen vågar röra. Om du försöker köra en automatisering fungerar den inte längre. Du kanske måste gå tillbaka och undersöka vad du driftsatte för sex år sedan och ge dig in i tidskrävande och kostsam reverse engineering. Och medan du gör det kan du upptäcka att någon har hackat dig i ett år.

Vi lever i en kvartalsekonomi. Om du ansvarar för detta underhållsarbete utvecklar du inte nya funktioner för din tjänst eller hittar nya sätt att tjäna pengar. Även om du sköter underhållet perfekt syns det inte direkt i företagets EBITDA, även om det påverkar den på lång sikt. Det du gör är inte glamoröst och skapar inget värde under nästa kvartal.

Praktiska råd

När det gäller behovet av löpande underhåll har du i princip tre alternativ:

• Outsourcing: Allt fler organisationer väljer att inte lägga sina ingenjörers tid på den här typen av arbete, så att de kan fokusera på att utveckla tjänsterna, och outsourcar det i stället. De tecknar ett långsiktigt underhållsavtal med ett företag som Eficode, som håller verktygen optimerade och underhållna så länge avtalet löper.

• Ett internt underhållsteam: Teamet ansvarar för allt underhåll och har en budget för det.

• Etablera gemensamma arbetssätt som du följer kontinuerligt: När du skapar något nytt utgår det automatiskt från etablerade och välfungerande metoder från andra områden. Detta är det svåraste av de tre alternativen eftersom du behöver säkerställa att allt nytt är bakåtkompatibelt – och allt gammalt är framåtkompatibelt. Annars skapar du ständigt ny teknisk skuld.

Slutsats

Det är verkligen en djungel där ute. Det finns så många DevOps-verktyg, och molnet är fortfarande relativt nytt och utvecklas hela tiden.

Underhåll är oftast inte det mest sexiga – vi fokuserar hellre på det nya och nästa steg – men om du tappar fokus händer dåliga saker. Saker går sönder och pengar kastas ner i ett mörkt hål.

Genom att följa och uppmärksamma mina fem steg slipper du mycket huvudvärk. Huvudvärk som många andra i din situation upplever varje dag.