Community på Sveriges dataportal
DevOps (anteckningar)
-
Mitt första inlägg här och jag vill höra mig för om hur det tänks och tycks kring DevOps och DevSecOps?
Jag har följt rörelsen under ett antal år som serverdriftare och utvecklare och har väl en del tankar och åsikter.
Några formuleringar om DevOps och DevSecOps:
Cloud Native Computing Foundation:
"En metodik där team tillsammans äger hela processen från systemutveckling till drift i produktion, därav namnet DevOps. . . . DevOps kräver att utvecklare och drifttekniker fokuserar på mindre komponenter (inte större funktioner) vilket leder till mindre överlämningar (en vanlig felkälla)."Google Cloud:
“En organisatorisk och kulturell rörelse som syftar att öka takten på mjukvaruleveranser, förbättra tillgängligheten och pålitligheten för tjänster och att bygga ett delat ägarskap emellan intressenter.”Department of Defense:
"DevSecOps är en samling aktiviteter och förmågor inom systemutveckling som kombinerar utveckling, säkerhet och IT-drift med syftet att göra leveranser säkrare och att korta ned utvecklingsprojektens livscykler. Ny funktionalitet, buggrättningar, säkerhets- och andra uppdateringar ska kunna ske oftare och på ett mer automatiserat sätt. Säkerhet appliceras i alla faser av utvecklingsprojekten."DevOps är ju inget som ersätter Lean och Agile, men delar av det kan (potentiellt) hjälpa oss att jobba enligt Lean- och Agile-principer.
Den årliga State of DevOps Report som gjorts sedan 2014 menar att de bästa måtten för en organisations utvecklingskapacitet är:
- Ledtid till release (från incheckad källkod till driftsättning)
- Hur ofta driftsätter vi nya releaser
- Tid det tar att återställa en tjänst (MTTR - Mean Time To Restore)
- Hur ofta orsakar en förändring/release problem
Och det låter väl i alla fall sunt?
Jag läste boken Accelerate förra hösten (från initiativtagarna bakom rapporten) och skrev ner några meningar...
Några dåliga sätt att mäta utvecklingskapacitet i organisationer:
-
Vad man använder för teknik. Det spelar en viktig roll men kultur och processer är viktigare föga förvånande, sedan kan verktyg hjälpa till i en kulturförflyttning
-
Om man har en CAB-funktion. Det visade sig t.o.m. att många org som förlitade sig på mer flexibla processer som parprogrammering eller peer review ofta var bättre både på att leverera OCH tillgänglighet och stabilitet i drift
-
Att mäta antal rader kod. Föga förvånande är det ett ruskigt dåligt mått. En lösning med 10 rader kod är - givetvis - ofta att föredra än samma lösning med 1000 rader kod (om den korta lösningen samtidigt är läsbar och inte för komprimerad). Det bästa är förstås om vi kan lösa ett problem helt utan kod eller genom att ta bort kod! Vem älskar inte att få radera kod ibland?
-
Snabbaste leveranserna. Undvik att fokusera så mycket på det. Det kan leda till att team nedprioriterar samarbete med andra team för att det tar tid från kodknackning och leverans.
Undvik att belöna utvecklare för mängden mjukvara som levereras och att belöna driftteam för stabilitet. Det leder gärna till att utvecklare "kastar kod" på drift och drift sätter upp plågsamma processer för att förhindra förändring.
Vad ger det att ha en hög utvecklingskapacitet då? God förmåga att ta fram och bygga nya lösningar, anpassa sig till förändring, leverera värde till användarna, osv.Man kom fram till att mått på utvecklingskapacitet bör fokusera på två nyckelaspekter:
- Maximal verksamhetsnytta
- Goda resultat, inte hur mycket det jobbas.
En bör inte uppmuntra att maximera mängden utfört arbete om det ändå inte hjälper organisationens mål (vad sa ni?!
)
Därav är genuin förståelse för vision och mål så himla viktigt!Något som inte är med bland dem måtten är tiden det tar att identifiera problem och att designa/ta fram potentiella lösningar. De kom fram till att det var många variabler i denna fas så att det var svårt att följa metodiskt (inte att det är mindre viktigt). Det är hög osäkerhet på estimat och resultat.
Det får bli en annan tråd en annan dag...Hur ser ni på DevOps? Anammar ni denna lära? Tycker ni mest att det är ett nytt modeord på vad ni redan gjort i 3000 år? (vilken sorts vampyr är du?!)
Låter det som namnet på en hel massa produkter som leverantörer försökt sälja in för att lösa alla era problem?
Personligen tycker jag nog att det är på tok för mycket brus kontra signal. Men känner ändå att det finns mycket bra stoff här som jag gärna ställer mig bakom och drar nytta av. Som sagt, intressant att höra era tankar! -
@davidlars vilket trevligt inlägg! Du förklarar på ett enkelt och pedagogiskt sätt ett begrepp som har använts som ett buzzword, de senaste åren.
Gillar särskilt det du skriver att hålla kodraderna få samt att satsa på stabilitet före mer mjukvara (funktioner). Jag tror att många upplever att vi mäts på de ”synliga” leveranserna, fler funktioner. Men det finns andra leveranser som vi kan synliggöra såsom prestanda, låga förvaltningskostnader och välpaketerade tjänster som andra kan återanvända.
Någonstans känns det som att detta är det nya svarta, i tider där vi utgör del av ett ekosystem, och där andra förväntas att använda och modifiera det vi tar fram.Hoppas att fler vill reflektera över och diskutera hur vi bygger bra öppna system och lösningar!
-
@davidlars Jag har jobbat en del tillsammans med DevOps-team. Senast hade vi en ganska bra kombination av ITIL och agila arbetssätt. Vi hade precis börjat fundera på hur det funkar ihop med containerplattform, som ju också för med sig en del vad beträffar arbetssätt. Det var också lite stökigt att få ihop det hela vägen från metodiken för innovation och ända ut till prodsättning av innovativa förändringar.
Hur ser du på saken? -
@Nina_Berlin Jo men det finns en hel massa best practice och tekniska förmågor som brukar förknippas med DevOps som jag tror på. Versionshantering av allt: kod, konfiguration, dokumentation, infra som kod m.m. Kontinuerlig integration (trunk based, med testautomation), kontinuerliga leveranser i pipelines som är förståeliga för både drift och utv (oavsett hur du bygger upp det tekniskt).
I slutändan vill vi leverera värde och vi vill att utvecklare/designers/UX får möjlighet att fokusera på affärslogik/användbara gränssnitt och att göra det iterativt med massor av actionable feedback från både driftsystem och användare (med mycket kontext). Sen behöver vi kunna byta kurs och pivotera vid nya insikter. Om vi gör det bäst i någon form av low code plattform, varför inte! Men jag tror mer på en mix av REST API:er uppepå plattformar som abstraherar underliggande infra (tänk serverless, även om begreppet används rätt slarvigt och kanske bara kan realiseras mha en ganska komplex Kubernetes-plattform om du behöver köra in prem, likt som många av oss ju måste).
Containers i sig är nyttigt för utvecklare för att få mer empati och förståelse för drift, med fördelar som att slippa "works on my computer" osv. Jag är själv rätt djupt insatt i Kubernetes och tycker att det har varit fantastiskt värdefullt att lära sig - både för att lära sig hur big tech & friends gör och att se hur folk mycket smartare än mig och med en helt annan skala än jag kanske någonsin kommer att vara i närheten av löser en hel del svåra problem. Och jag uppskattar verkligen alla barriärer som k8s tar bort när man väl kommit över inlärningströskeln. Så, om man inte kastar sig in i k8s och micro services för egen del, lär dig iaf vad det handlar om. Det är ett svindlande lyckat OSS projekt om inte annat! Även ekosystemet runt.
Hm.. stannar där för ikväll
Blir svårt att hålla sig inom ämnet Arbetssätt här
-
@davidlars Jag håller med om det här!
Det är mycket lättare att springa på incidenter när folk har koll på det här. Annars kan det nästan bli omöjligt.
Det jag tycker är det svåraste är att koppla på verksamheten i det här, att hitta vilken roll de behöver ha för att det ska fungera. För att de automatiserade (funktionella) testerna ska funka behöver verksamheten vara med och skriva given-when-then, eller åtminstone förstå testfallen och verifiera att de stämmer. Och det går inte att göra en bra pivot om man inte har med sig både verksamhet, utveckling och drift.
Min erfarenhet är att verksamheten ofta kommer med en briljant innovativ idé som man från IT-sidan inte orkar ge dem en miljö att hålla hus i för att utveckla, eftersom man är nedlusad med förvaltning av heritage.
Eller, att IT-sidan kommer med en briljant innovativ idé som verksamheten inte orkar ta till sig eftersom den inte kommer från verksamheten och man därför får för sig att den inte kopplar till ett verkligt behov hos slutanvändarna.
Jag tror på att vi behöver ett gemensamt samarbetsverktyg att hålla hus i, både verksamhet och IT. Det funkade ganska bra när vi körde Enterprise över hela linjen, även Atlassian funkade bra tills de låste in allt.
Jag jobbar på att få in verksamheten i GitHub men det är verkligen inte helt enkelt. Verktyget är inte gjort för att passa behov man har i en verksamhet. -
Hej på er!
Jag skrev precis ett mail till @Maria_Dalhage där jag frågade om det inte var dags för ett seminarium om DevOps. Vårt team har haft visst utbyte med bl a PM (Pensionsmyndigheten) men jag tror att det finns stor potential om vi kan dela med oss mer.
Maria bad mig därför skriva ett post och jag funderar på om jag ska skriva här eller om vi ska påbörja en ny tråd så att det är tydligt att det gäller ett DevOps-seminarium och att folk gärna får fylla på med vad de önskar för innehåll.
Vårt team försöker nyttja DevOps så mycket det bara går (automatisera och effektivisera) och vi har förhoppningsvis något vi kan bidra med på ett seminarium som kan vara till gagn för andra.
-
L lfvjimisola referenced this topic on
-
@lfvjimisola har jobbat med DevSecOp en del de sista 10 åren.
Använt Riksdagsmonitor som exempel och pratat om säkerhets testningen en del
How to secure your development pipeline with static application security test (SAST) / Dynamic application security test (DAST), software composition analysis (SCA) using Sonarqube.
Talk at Javaforum Göteborg https://www.youtube.com/watch?v=A_hq2Y03d6I
Security podcast "Shift Left Like A Boss" https://www.youtube.com/watch?v=aYwSd1Wu28Q&ab_channel=Soluble
Presentation/slides at https://github.com/Hack23/talks/raw/master/SecureDevelopmentPipeline20190919.pptx and https://github.com/Hack23/talks/raw/master/SecureDevelopmentPipeline20190919.odp
Mvh
-
Intressanta länkar och intressant att höra om era erfarenheter!
Förra hösten letade jag efter strukturerad dokumentation kring detta (mycket brus och svårt att pejla in signal med allt säljsnack om DevOps-produkter!). Jag hittade till slut Fundamentals Playbook för DevSecOps från Department of Defense.
Och deras DevSecOps Reference Design.
Så under en tid har jag översatt den senare (så gott jag kunnat) och lagt in den i ett exceldokument för att börja prata om det här med en större förståelse för helheten. Och för att kunna se kopplingar mellan en given aktivitet (ex versionshantering av källkod) till ett lämpligt verktyg (git) och hitta en realistisk väg framåt för en organisation som vill anamma arbetssättet. Excel har väl inte riktigt visat sig vara det roligaste formatet, varken att jobba i eller som diskussionsunderlag. Och inte optimalt för ev publicering och samarbete/diskussion externt. Så jag bestämde mig för att knacka ner innehållet i webbformat istället. Initialt mha dokumentationsgeneratorn mkdocs (men jag är inte övertygad än om att jag gillar verktyget).
Jag har valt att kalla resultatet för DevOpsGuiden.Först och främst är jag bara väldigt tacksam att höra er tankar om formatet och innehållet och om det finns intresse att tillsammans ta det här vidare i det öppna. Jag känner att jag uppnått mitt första mål som var att lära mig om hur DevOps/DevSecOps bedrivs inom en offentlig verksamhet där detta är livsviktigt (bokstavligen). Och det har hjälpt mig med det interna arbetet med att forma rutiner och se oss om efter nödvändiga verktyg. Jag tänker att detta eller något liknande behöver underhållas och säkert kan ta nya former och uppfylla syften som jag inte tänkt på.
Jag tänker, pragmatiskt, att en konkret koppling till faktiska verktyg och varför man behöver dem är det som verkligen skulle vara värt att jobba vidare med. Företrädelsevis med tips på öppen källkodsmjukvara.
-
@davidlars Skulle vilja trycka på gilla-tummen minst 2 ggr för detta!
@davidlars, skriv den i markdown. Gärna basic syntax. @jonass , @Maria_Dalhage , kan ni hjälpa @davidlars så han kan publicera det här på NOSAD så vi når det allihop?
https://www.markdownguide.org/basic-syntax/ -
@Nina_Berlin den är redan skriven i markdown
-
@davidlars klockren!
Och jag håller med @Nina_Berlin att denna bör längas upp som Nosad lästips. Men jag gillar konceptet Playbook och kanske kan fler bidra till att komplettera med intressanta kapitel.Vore skoj med kommentarer i forumet på denna guide.
-
@Maria_Dalhage kompletterar mitt svar till hela community: ni alla som har bra saker att dela. Gör precis som @davidlars och pinga nosad.se så lägger vi upp det läsbara där. Vi jobbar med att kurera det som vi lägger upp och skapar gärna en dialog om olika lästips i detta community. Vi kan hantera de mesta i formatväg.
-
Jag gillar enthusiasmen!
Hjälper gärna till att publicera den på nosad, ge den ett "neutralt hem". Allt är som sagt i markdown redan https://github.com/devopsguiden/devopsguiden.Jag är inte förtjust i byggsteget som krävs för mkdocs, men ni har väl redan automatik för stacket som körs på nosad.
-
@davidlars NOSAD lästips är kurerade länkar och bilagor. Det viktigaste är att ha ett ställe som är en naturlig samlings-/visningsplats. På sikt vore det ju toppen med API:er av metodstöd, goda exempel, mallar o.s.v. men för att inte fastna i goda intentioner att ha den bästa av strukturer så laddar vi upp länkar och artefakter på nosad.se i ett första steg.
-
@davidlars https://nosad.se/tips här ligger nu DevOpsGuiden. Följ redigeringsanvisningarna om du vill göra förändingar i texten om DevOpsGuiden eller maila mig på maria.dalhage@digg.se. Om det är ok gör tummen upp
-
@Maria_Dalhage Precis, NOSAD i ett första steg
sedan kanske vi kommer vilja lyfta över vissa playbooks/guider till digitala arenan. Men jag tror ändå vi kommer vilja behålla en del guider på NOSAD. -
@Nina_Berlin Semantikdiskussion nu när vi närmar oss lansering av "Den Digitala Arenan"
Enligt min definition av den Digitala arenan så är NOSAD.se en del av den digitala arenan liksom Energimyndigheten.se, DIGG.se, SCB.se och andra organisationers webbsidor. Vi bygger tillsammans ett skyltfönster som leder tillbaka till organisationerna bakom resurserna. Vi kommer att behöva skruva på flera gånger på vår layout och design för att det ska bli så enkelt som möjligt att hitta det man letar efter och dela det som andra kan ha nytta av.
Dataportalen kommer alltså att uppdateras med andra viktiga artefakter utöver data för att nå datadriven utveckling och innovation såsom öppen källkod , metodstöd från olika organisationer samt bl.a. en AI-samlingsyta.
Community blir ett nav för alla dialoger kring data, API:er och digitala resurser som öppen källkod, begrepp och specifikationer och standarder.Vi (Sverige/DIGG/Community) har ännu inte landat i alla frågor om tillit till innehåll och förvaltning av innehåll så vi provar oss fram. Nätverket NOSAD kan ha en lite mer experimenterande karaktär. Men samtidigt så speglar NOSAD bättre än någon annan organisation det decentraliserat styrda Sverige.
NOSAD är en DIGG-leverans, men också Arbetsförmedlingens och Internetstiftelsens leverans, utifrån Plattformar och därmed infrastruktur. Innehållsmässigt (content) så är NOSAD allas leverans och vi har än så länge 80 föredömliga organisationer som delat med sig av goda exempel och erfarenheter på NOSAD.se förutom alla 600+ personer som deltagit på våra digitala workshops.
-
@Maria_Dalhage
Har inte läst allt här än men tänkte be dig ändra i texten till David, inte Anders Berglund. Jag är visserligen också musikintresserad så det var en glad överraskning att se namnet. 
-
@davidlars hahaha. Sorry. Min hjärna var inte med mig riktigt. I fix!
