# DevOps ## Vad det är DevOps är ett sätt att organisera arbetet med mjukvara där de som skriver ett system också äger hur det byggs, släpps och hålls igång, och där stegen mellan att skriva kod och att köra den är automatiserade i stället för att lämnas över från ett team till ett annat. Namnet är en sammandragning av development och operations, utveckling och drift, de två grupper som ordet myntades för att föra samman. NIST, det amerikanska institutet för standarder och teknik, definierar DevOps som metoder för att automatisera processerna mellan utvecklingsteam och driftteam, så att teamen kan bygga, testa och släppa mjukvara snabbare och mer tillförlitligt. Definitionen är användbar eftersom den pekar ut den del som avgör: processerna däremellan. Ett företag kan ha utmärkta utvecklare och utmärkta driftstekniker och ändå förlora dagar i det ögonblick då den ena gruppen lämnar en release till den andra. I praktiken märks DevOps som en handfull vanor som stöttar varandra: - **Delat ägarskap av produktionen.** Den som ändrar koden ser vad ändringen gör när den väl körs, genom övervakning, loggar och larm, och svarar för den. - **En automatiserad väg till release.** Bygge, test och driftsättning körs som en pipeline, på samma sätt varje gång, oftast ovanpå [CI](https://martinfowler.com/articles/continuousIntegration.html). - **Infrastruktur skriven som filer.** Servrar, nätverk och databaser beskrivs i mallar eller playbooks som ligger bredvid koden, så att en miljö kan byggas upp på nytt i stället för att minnas. - **Ett bygge, många miljöer.** Artefakten som klarade sina tester i staging är samma artefakt som når produktion, och bara dess inställningar har ändrats. - **Små, täta releaser.** Var och en bär få ändringar, så ett fel är lätt att hitta och lätt att rulla tillbaka. DevOps är ett arbetssätt snarare än en produkt, och en yrkestitel bara i lös mening. Leverantörer säljer verktyg under namnet och företag anställer ”DevOps-ingenjörer”, men varken verktygen eller titeln är själva saken. En DevOps-ingenjör bygger och sköter oftast de pipelines och den infrastruktur som låter andra utvecklare leverera på egen hand, vilket är en roll inom arbetssättet och ingen ersättning för det. ## Varför det spelar roll Varje överlämning mellan team tappar något på vägen. Utvecklaren vet varför en ändring gjordes och vad den är beroende av; driftteknikern vet hur servrarna ser ut och vad som gick sönder förra månaden. När en release går från den ena till den andra som ett ärende och ett paket kommer båda halvorna av den kunskapen fram ofullständiga, och luckorna visar sig under driftsättningen, som är den dyraste tidpunkten att hitta dem. [The Twelve-Factor App](https://12factor.net/), en metod för att bygga applikationer som levereras som tjänst, sätter exakta namn på tre av de luckorna. Det finns en lucka i tid, när kod som skrivs i dag når produktion flera veckor senare. Det finns en lucka i personer, när en grupp skriver koden och en annan driftsätter den. Och det finns en lucka i verktyg, när en bärbar dator kör en databas och produktionen kör en annan. DevOps är i stor utsträckning ett projekt för att stänga alla tre: driftsätt några timmar efter att koden skrevs, låt dem som skrev den driftsätta den, och håll varje miljö så lik de andra som möjligt. Releasernas storlek är det andra argumentet. Boken från Google om site reliability engineering säger det rakt ut: täta releaser innebär färre ändringar mellan versionerna. En release med tre ändringar i är lätt att resonera kring när den går fel. En release med trehundra är ett sökarbete. Det tredje är det som boken kallar toil, ungefär manuellt rutinslit. Den definierar toil som arbete knutet till att driva en tjänst som är manuellt, repetitivt och går att automatisera, som saknar bestående värde och som växer i takt med tjänsten. Ett team som startar om en process för hand varje tisdag, förnyar certifikat efter en påminnelse i kalendern och förstorar diskar när ett larm går ägnar sin tid åt arbete som ett skript skulle utföra mer tillförlitligt. Att automatisera det arbetet är hur ett litet team hinner med ett system som växer. Vägledningen inom informationssäkerhet har landat i samma form. [Vägledningen från NIST om DevSecOps för molnnativa applikationer](https://csrc.nist.gov/pubs/sp/800/204/c/final) utgår från en pipeline med steg för bygge, test, paketering, driftsättning och drift, och räknar infrastruktur, policyer för körning och övervakning till de slags kod som pipelinen beskriver. ## Så ser det ut i praktiken Sidorna på den här webbplatsen visar DevOps mindre som en titel än som ett ansvarsområde: samma ingenjör utformar ett system, får ut det i produktion och håller det kvar där. På ett startupföretag inom grön energi i ett tidigt skede, utan något infrastrukturteam, [spände arbetet över plattforms- och datateknik, DevOps och site reliability i två år](/sv/portfolio/architected-developed-implemented-supported-infrastructure-data-processing-and-55/). Sidan säger uttryckligen att det innebar att äga produktionen och inte bara skriva mjukvaran: att provisionera och härda infrastrukturen, automatisera provisionering, övervakning och larm så att problem hittades och åtgärdades snabbt, och att leverera releaser stegvis. Det är DevOps i sin mest bokstavliga form, med utveckling och drift i en och samma persons händer. På en databasmiljö med 10 instanser av PostgreSQL och MS SQL Server på VPS:er med Ubuntu Linux automatiserades driften bit för bit: [säkerhetskopior med `pg_dump` och jobb i SQL Server Agent, övervakning i Prometheus och Grafana](/sv/portfolio/designed-deployed-and-maintained-10-postgresql-and-ms-13/), regelbunden patchning, brandväggar med UFW, rollbaserad åtkomstkontroll och dokumenterade rutiner för katastrofåterställning. Sidan redovisar 99,9 % upptid på alla tio servrar och 50 % mindre manuellt underhåll tack vare automatisering, vilket är argumentet om rutinslit mätt i en enda miljö. På en plattform i Azure med miljöer för utveckling, staging och produktion [ägdes driftsättningen från början till slut längs en fast väg](/sv/portfolio/owned-end-to-end-deployments-of-the-platform-71/). CI/CD-pipelinen bygger avbildningarna, mallar i Bicep håller infrastrukturen likadan från en miljö till nästa, och den konfiguration som skiljer sig mellan miljöerna hålls åtskild från hemligheterna. Det låter samma byggda artefakt föras vidare genom miljöerna i stället för att byggas om för var och en, och sidan redovisar releaser helt fria från manuella ad hoc-driftsättningar. ## Var det går fel DevOps töms oftast på innehåll i det tysta: orden blir kvar medan vanorna försvinner. **Titeln kommer och muren står kvar.** Ett driftteam byter namn, eller så anställs ett ”DevOps-team” som ska sitta mellan utvecklarna och produktionen. Releaserna passerar fortfarande en överlämning; den har bara fått ett nytt namn på andra sidan. Testet är enkelt: fråga vem som kan leverera en ändring och vem som blir väckt när den går sönder. Är det olika personer med olika information har arbetssättet ännu inte kommit på plats. **Driftsättningen är fortfarande en person med en checklista.** Pipelinen bygger och testar, och sedan loggar någon in på en server och kör de fem sista stegen ur minnet, lite olika varje gång. Lägg även de sista stegen i pipelinen, ge releaserna en enda väg genom miljöerna och behandla en manuell push till produktion som en incident som ska förklaras. **Varje miljö får sitt eget bygge.** Att bygga om för staging och sedan igen för produktion innebär att det som testades är en annan sak än det som levererades. Ett beroende som löstes upp annorlunda vid det andra bygget dyker upp som ett fel som ingen kan återskapa. Bygg en gång, tagga artefakten med den commit den kom från och för den artefakten vidare, med inställningarna hämtade från miljön: ```sh tag="$(git rev-parse --short HEAD)" docker build -t "registry.example.com/app:$tag" . docker push "registry.example.com/app:$tag" # staging and production run this same tag; # only the settings they start it with differ docker run --env-file staging.env "registry.example.com/app:$tag" ``` **Staging glider ifrån produktionen.** En inställning som ändrats för hand på en server, en databas som uppgraderats i produktion först, en biblioteksversion som är låst på ett ställe och flytande på ett annat: var och en gör staging lite mindre användbar som generalrepetition. Beskriv infrastrukturen i mallar, tillämpa samma mallar överallt och kör samma bakomliggande tjänster i utvecklingsmiljön som produktionen kör. **Rutinslitet växer med systemet.** Manuella jobb som tog tio minuter i veckan för en server tar timmar för tjugo. Om ingen avsätter tid för att automatisera dem går teamets dagar åt till att hålla lamporna tända. Räkna det återkommande manuella arbetet och sätt ett tak för hur stor andel av tiden det får ta. ## Läs mer - [DevOps](https://csrc.nist.gov/glossary/term/development_operations) — definitionen från NIST, med de specialpublikationer den bygger på. - [Build, release, run](https://12factor.net/build-release-run) — varför ett bygge görs en gång och kombineras med konfiguration till en release. - [Dev/prod parity](https://12factor.net/dev-prod-parity) — luckorna i tid, personer och verktyg mellan utveckling och produktion, och hur de stängs. - [Config](https://12factor.net/config) — att hålla allt som skiljer sig mellan driftsättningar borta från koden och i miljön. - [Eliminating Toil](https://sre.google/sre-book/eliminating-toil/) — definitionen av toil från Google och argumenten för att sätta ett tak för det. - [Release Engineering](https://sre.google/sre-book/release-engineering/) — hermetiska byggen, releaser i självbetjäning och policyer som releaseverktygen själva upprätthåller.