DevOps handlar om återkopplingsloopar och om att föra in information där den gör störst nytta. Därför pratar vi om att skifta vänster som om det vore osjälviskt och välvilligt. I det här inlägget tar jag upp felslutet med att skifta vänster, hur vi misslyckas med det och hur vi kan förbättra sättet vi får och använder återkoppling.
Att få återkoppling och styra den dit där den kan göra nytta är en viktig del av DevOps. Men är snacket om att ”skifta vänster” ett felslut som döljer våra brister?
Johan Abildskov
Johan has been a Continuous Delivery Consultant with Eficode Praqma since 2015. After achieving his BSc in Computing Science he spent his time teaching, coding, hacking and studying. He is an avid gamer and participates in tournaments whenever he has the time. He also plays the bass.
DevOps handlar om att flytta åt vänster och förkorta återkopplingslooparna. Eller åtminstone om att flytta en tredjedel bakåt. Typ.
Men uttrycket ”shift left” bygger på två stora antaganden. För det första antar vi att det finns återkoppling att flytta åt vänster. För det andra antar vi att människor faktiskt kommer att ta till sig återkopplingen och göra den värdefull.
Tyvärr hamnar många team i en eller båda av dessa fällor. De fastnar i det jag kallar shift left-fallacin.
Att inte flytta något åt vänster
När vi pratar om återkoppling i ett DevOps-sammanhang tänker vi vanligtvis på interna och externa mått för kvalitet och användning av en viss produkt. Det kan handla om att mäta vilka delar av våra applikationer som används av flest kunder, eller interna mått för kvalitet och prestanda, såsom minnesanvändning och misslyckade tester.
Att flytta åt vänster handlar om att ta återkoppling och göra den tillgänglig för dem som bygger. Återkopplingen bör komma snabbt och tydligt för att ge störst effekt till lägsta kostnad. Om du pratar om detta med en mjukvaruutvecklare, som jag själv, kan du vara säker på att vi direkt börjar rada upp till synes slumpmässiga kombinationer av coola verktyg för att slå bollen ur parken med en fantastisk mekanism för att leverera återkoppling. Men det finns ett problem. Vad händer när den här bollsparkande roboten driftsätts i produktion och vi inte hittar någon boll att sparka på?
För det spelar egentligen ingen roll hur coola dina Prometheus och Grafana är, eller hur ditt favorit-SaaS-bolag för mätvärden lovar att göra dina data med oändligt många dimensioner enkla att fråga ut. Ta ett steg tillbaka och försök hitta en enda användbar uppgift. Ta reda på hur många serverfel din applikation rapporterade under de senaste 24 timmarna. Gör det manuellt. Upprepa den manuella processen några gånger under en månad och skriv ner resultatet i ett Excel-ark eller liknande. Om du vill gå helt bananas kan du ta en post-it-lapp och sätta upp datapunkten på skrivbordet. Tekniska mätvärden som serverfel är förstås enkla att mäta. För en verkligt värdefull utmaning kan du fråga verksamhetsansvarig vilka mätvärden de bryr sig om. Ännu bättre: hitta en verklig användare av applikationen och fråga hur nöjd personen är med den.
Och om du inte kan hitta någon användbar återkoppling bör du fokusera på att ta reda på hur du får fram den, inte på någon imaginär shift left-process.
Att flytta åt vänster ut i tomrummet
Den andra aspekten av shift left-fallacin är att samla in all värdefull återkoppling, få den till platsen där den har störst effekt och sedan helt misslyckas med att agera på den. Det händer eftersom vi antingen bara ignorerar återkopplingen eller för att vi tekniskt eller organisatoriskt inte kan göra den användbar. Om vi inte kan eller vill agera på återkopplingen är den bortkastad. All tid och energi som lagts på att få fram den är också bortkastad.
Om vi investerar i verktyg som XRay för att skanna efter sårbarheter eller licensöverträdelser kan vi få mycket värdefull återkoppling. Men det kan resultera i en flod av överträdelser, varningar och fel som gör oss paralyserade och avtrubbade inför hur allvarliga problemen är. Det är mycket lättare att ignorera tusen varningar än bara en.
När det gäller licenser bör du till exempel börja med att ta reda på vilka licenser som är godkända för er innan du lägger in kontroller i pipelinen. Gå sedan igenom era beroenden för att hitta en enda överträdelse och agera på den! Ska ni sluta använda den? Kan ni hitta en kommersiell licens eller en alternativ produkt? Eller, i värsta fall, utveckla ett alternativ själva?
Om du inte kan hantera en enda överträdelse bör du inte flytta åt vänster för just den återkopplingsloopen.
Problemet är dubbelt. För det första har du helt enkelt slösat bort arbetet med att möjliggöra den här återkopplingen. Men den verkliga tragedin med shift left-fallacin i det här fallet är att du lär dina team att ignorera återkoppling, vilket hämmar deras uppfinningsrikedom, autonomi och tillit till organisationen. Det säger en hel del om oss att vi kan investera i att få fram den här typen av återkoppling utan att agera på den!
Återkopplingsloopar handlar om återkoppling
Återkoppling handlar om att omvandla resultatet från vårt system till indata för vårt system. Om vi inte gör det, inte matar och förändrar vårt system genom användare eller övervakning, bör vi över huvud taget inte prata om återkopplingsloopar och shift left.
Det bästa stället att börja är alltså med återkopplingen. Sedan kan vi fundera på hur vi skapar en loop kring den.
Här är några sätt att börja arbeta med återkoppling.
Par- eller mobbprogrammera
Det ger dig möjlighet att arbeta internt med din återkoppling och information. När du sedan har fått grepp om mobbprogrammering kan du bjuda in externa personer, exempelvis InfoSec och QA, till sessionerna för att hjälpa dig flytta återkopplingen åt vänster.
Involvera fler personer i den inledande designfasen
När du påbörjar ett större arbete bör du se till att alla med en relevant värdeström är med. Det är inte bara designers och utvecklare som bidrar till att skapa värde och sätter kontexten för utvecklingsarbetet. Det kan vara allt från partners och plattformsteam till QA och säkerhet. Att designa och arkitekta för säkerhet, testning och driftbarhet från början är en stor fördel. Det är också mycket billigare och betydligt roligare än att försöka lägga till det senare i processen, när omfattande förändringar är smärtsamma.
Gör det på det enkla sättet
Börja med att välja ett viktigt affärsmått som du vill agera på. Om det är enkelt att mäta automatiskt, gör det. Men om det ens är lite utmanande, stanna upp och förenkla det ytterligare.
Uppskatta måttet regelbundet och se om det ger dig något värde. Om det gör det är det förmodligen värt att automatisera och flytta åt vänster. Det här är också ett utmärkt tillfälle att experimentera med rätt metoder för visualisering. Visualiseringar kan användas för att framhäva eller dölja trender. Medan du fortfarande experimenterar med datainsamlingen har du god insyn i hur trenden utvecklas, så utnyttja det och se till att du kan visualisera på ett sätt som får genomslag.
Shift left är inte gratis
Vi måste sträva efter shift left om vi vill vara konkurrenskraftiga i den digitala värld vi lever i. Men att bara slänga ur sig shift left som ett buzzword och bortse från de tekniska och organisatoriska förutsättningarna blir slöseri och kan till och med vara direkt destruktivt.
Här är tre tecken på att du har hamnat i shift left-fällan och behöver ta dig ur den:
Du får mycket återkoppling, men den påverkar inte dina handlingar
Du lägger mer tid på verktygen än på att förstå datan
Du önskar ständigt att viss återkoppling hade genererats tidigare
Prioritera alltså shift left, men se upp för shift left-fällan!
- DevOps
- CI/CD
Subscribe to our newsletter
Related blogs