Vanlige DevOps-feil i Azure DevOps | Unngå produksjonsstans

21.03.2025

DevOps handler om samarbeid, automasjon og kontinuerlig forbedring. Likevel opplever mange team at én liten glipp kan føre til produksjonsstans og høyt stressnivå. En anonym kollega fortalte:

«Vi deployet direkte til produksjon uten staging, og brukerne opplevde to timers nedetid.»

Det er helt normalt å feile, men med noen målrettede grep kan du minimere risikoen drastisk. Gå gjennom de fem største tabbene — og svar på refleksjonsspørsmålene underveis!

Innholdsfortegnelse

  1. Pull requests uten review

  2. Mangelfull testing i CI/CD

  3. Produksjonsutrulling uten staging

  4. Svak observability

  5. Rollback-strategier som ikke virker

  6. Uventede kostnadsalarmer

  7. Oppsummering

  8. Ofte stilte spørsmål (FAQ)

  9. Del dine erfaringer!

Pull requests uten review

Mange team merger direkte til main uten å vente på godkjent code review. Det øker risikoen for uoppdagede bugs og uventede konflikter.

  • Aktiver Require pull request reviews before merging i Azure DevOps eller GitHub.

  • Kjør linters og automatiserte tester i PR-pipeline.

  • Sørg for at minst én seniorutvikler godkjenner før merge.

Ved å kreve review tidlig fanger du opp feil før de når produksjon.

Refleksjon

Hvordan ser deres nåværende reviewer-prosesser ut, og hva kan forbedres?

Mangelfull testing i CI/CD

Å hoppe over tester er en klassisk feil. Uten høy dekningsgrad oppdages feil ofte først i produksjon — med høye kostnader og tapt tillit.

  • Del testene i nivåer:

    1. Enhetstester for små, isolerte kodebiter.

    2. Integrasjonstester mot simulerte miljøer.

    3. End-to-end-tester i staging.

  • CI/CD (Continuous Integration/Continuous Deployment) sikrer at tester kjører ved hver push.

trigger: none 

  pr: 

        branches: [ main ] 

  jobs: 

   - job: TestOgLint 

       steps: 

           - task: DotNetCoreCLI@2 

               inputs: 

                  command: 'test' 

           - task: Bash@3 

               inputs: 

                   script: 'npm run lint' 

Refleksjon

Hvilket testnivå er svakest i deres pipeline i dag?

Produksjonsutrulling uten staging

Direkte deploy til produksjon skaper uklare roller og høyt prestasjonspress. Staging-miljøet er ditt siste sikkerhetsnett.

Terraform-eksempel

provider "azurerm" { 

  features {} 

resource "azurerm_resource_group" "rg" { 

    name = "rg-devops-demo" 

    location = "northeurope" 

resource "azurerm_app_service_plan" "asp" { 

   name = "asp-demo" 

   location = azurerm_resource_group.rg.location 

   resource_group_name = azurerm_resource_group.rg.name 

   sku { 

       tier = "Standard" 

       size = "S1" 

   } 

resource "helm_release" "myapp" { 

     name = "demo-app" 

     repository = "https://charts.mycompany.com" 

     chart = "demo-chart" 

     values = [file("${path.module}/values.yaml")] }

Helm-oppsett (values.yaml)

replicaCount: 2 

image: 

  repository: myregistry.azurecr.io/demo-app 

  tag: latest 

resources: 

    limits: 

       cpu: 500m 

       memory: 256Mi 

ingress: 

    enabled: true 

    hosts: 

         - host: demo.mydomain.com 

             paths: ["/"] 

Ved å klone produksjons­miljøet i staging får teamet den tryggheten de trenger før siste utrulling.

Refleksjon

Hva er hovedutfordringen dere møter når staging-miljøet skal reprodusere produksjon?

Svak observability

Logging alene gir ofte for lite innsikt. Du trenger metrics, logging og tracing for å feilsøke raskt og effektivt.

  • Kombiner tre pilarer:

    1. Metrics med Prometheus (PromQL-eksempel):

      sum(rate(container_cpu_usage_seconds_total[5m])) by (pod) > 0.8
    2. Logging med ELK eller EFK.

    3. Tracing med Jaeger eller OpenTelemetry.

  • Alertmanager-regel (Prometheus)

    groups: 

                  - name: kubernetes-pods 

                      rules: 

                          - alert: HighCpuUsage 

                              expr: sum(rate(container_cpu_usage_seconds_total[5m])) by (pod)                                > 0.8 

                              for: 5m 

                              labels: 

                                 severity: warning 

                              annotations: 

                                   summary: "Høy CPU-bruk for pod {{ $labels.pod }}"

  • OpenTelemetry-integrasjon
    Installer OpenTelemetry SDK i applikasjonen (eksempel for Node.js):

    npm install --save @opentelemetry/api @opentelemetry/node @opentelemetry/exporter-collector

    Legg til i app.js:

    const { NodeTracerProvider } = require('@opentelemetry/node'); 

                const { CollectorTraceExporter } = require('@opentelemetry/exporter-                              collector'); 

                 const provider = new NodeTracerProvider();            

                 provider.addSpanProcessor(new        SimpleSpanProcessor(new        

                 CollectorTraceExporter())); 

                 provider.register();

En helhetlig observability-stack gir raskere rotårsaksanalyse.

Refleksjon

Hvilken pilar i observability-stacken skuffer dere mest i dag?

Rollback-strategier som ikke virker

«Revert commit» er ikke nok om databasen allerede er migrert. Uten robuste rollback-mønstre sitter du igjen med halvfunksjonell kode.

  • Blue-green-utrulling: to parallelle produksjonsmiljøer.

  • Canary-utrulling: gradvis utrulling til 5–10 % av brukerne.

stages: 

  - stage: Canary 

      jobs: 

         - deployment: AppCanary 

              environment: production-canary 

              strategy: 

                  runOnce: 

                      deploy: 

                          steps: 

                              - script: az webapp deployment slot swap --name demoApp --     

                                  resource-group RG --slot staging

Refleksjon

Hvilken utrullingsstrategi bruker dere — og hvorfor?

Uventede kostnadsalarmer

Skyregningen kan skyte i været dersom ingen følger med. En mis­konfigurert VM-skala kan koste titusenvis ekstra.

  • Set up Azure Cost Management-alarmer:

    { "name": "high-spend-alert", 

                   "properties": { 

                        "description": "Varsle ved månedlig kostnad > 5000 NOK", 

                        "condition": { 

                            "threshold": 5000, 

                            "timeGrain": "Monthly", 

                            "operator": "GreaterThan" 

 }, 

 "actions": [ 

      { 

          "actionGroupId": "/subscriptions/.../actionGroups/spend-alert" 

      } 

     ] 

    } 

}

  • Bruk autoscaling med konservative terskler.

  • Les mer: Sky-kostnadskontroll i Azure.

Refleksjon

Har dere satt opp varsler for uventet forbruk?

Oppsummering

Med god pull request-prosess, grundig testing, staging-miljø, fullstendig observability, robuste rollback-strategier og kostnadsalarmer løfter du teamets DevOps-praksis til neste nivå. Disse grepene reduserer risiko, øker tillit og gir ekte psykologisk trygghet i utviklingshverdagen.

Ofte stilte spørsmål (FAQ)

Hvorfor er code review så viktig?

Review avdekker feil tidlig, sprer kunnskap og øker kodekvaliteten.

Hva er forskjellen på staging og produksjon?

Staging er en klone av produksjonsmiljøet for siste test før deploy.

Hvordan velge mellom blue-green og canary?

Blue-green gir null nedetid, mens canary gir gradvis utrulling med lav risiko.

Del dine erfaringer!

Vi lærer best av hverandres feil og suksesser. Kontakt oss med dine mest overraskende DevOps-øyeblikk, så løfter vi miljøet sammen!

Les også