04 · Drift

Drift, overvågning og vedligehold af automatiseringer.

En automatisering er ikke færdig, når den er bygget. Systemer ændrer sig, nøgler udløber, og data er sjældent perfekte. Det er her, piloten gør forskellen.

Hvad vi holder øje med

Fejlede kørsler

En kørsel, der stopper med fejl, giver straks en alarm.

Udeblevne kørsler

Vi kontrollerer, at planlagte kørsler faktisk er startet.

Uventede resultater

Data, der ikke stemmer, får automatiseringen til at stoppe og melde fra.

Nøgler og adgange

Udløbsdatoer og ændrede rettigheder fanges, før de stopper driften.

Forbrug

Budgetalarmen giver besked ved usædvanligt Azure-forbrug.

Når noget fejler

Automatiseringerne er bygget til at stoppe sikkert frem for at fortsætte med forkerte data.

  1. Trin 1Kørslen stopper

    Fejlen og konteksten skrives i jobloggen. Halvfærdige ændringer undgås, hvor det er muligt.

  2. Trin 2Alarm udløses

    Azure sender alarmen til vores support, hvor den automatisk bliver til en sag.

  3. Trin 3Vi undersøger

    En tekniker finder årsagen: data, adgang, et ændret API eller noget fjerde.

  4. Trin 4Rettelse og genkørsel

    Rettelsen testes i læse- eller testtilstand, før kørslen gentages.

  5. Trin 5I får besked

    Påvirker fejlen jer, får I besked om årsag, løsning og eventuel opfølgning.

Vedligehold

Det, der ellers får automatiseringer til at gå i stå.

Ændringer fra Microsoft

Vi følger med i udfasede funktioner og nye krav – og tilpasser i god tid.

Leverandørernes API’er

Når et system ændrer sit API, opdaterer vi integrationen.

Moduler og runtime

Biblioteker og sprogversioner holdes opdaterede og understøttede.

Rotation af nøgler

Nøgler og certifikater skiftes, før de udløber.

Jeres forandringer

Nye afdelinger, licenser eller systemer? Så justerer vi reglerne.

Maskiner

Eventuelle maskiner opdateres kontrolleret uden for kørselstidspunkter.

Sådan ændrer vi noget

Ingen ændring går direkte i drift. Den samme proces bruges, uanset om det er en rettelse eller en ny funktion.

  1. Trin 1Ønske registreres

    Behovet oprettes som en sag med beskrivelse.

  2. Trin 2Ny version bygges

    Den gamle version kan altid genskabes.

  3. Trin 3Læsetilstand

    Viser, hvad ændringen ville gøre.

  4. Trin 4Testtilstand

    Kører på én post, som kontrolleres.

  5. Trin 5Godkendelse

    Af jer, når ændringen påvirker jeres processer.

  6. Trin 6I drift

    Dokumentationen opdateres.

Det står i dokumentationen

Hver automatisering har sit eget dokument – skrevet, så en anden tekniker kan overtage.

Formål

Hvilken opgave den løser, og for hvem.

Systemer og data

Hvad den læser, og hvad den ændrer.

Rettigheder

Præcis hvilke adgange den har – og hvorfor.

Tidsplan og udløser

Hvornår og hvordan den starter.

Ejer hos jer

Hvem der godkender ændringer.

Nødprocedure

Hvordan den stoppes, og hvad der gøres manuelt imens.

Versionshistorik

Hvad der er ændret, hvornår og hvorfor.

Kendte begrænsninger

Hvad den bevidst ikke håndterer.

Ansvarsfordeling

Fisker IT

  • Bygger, tester og dokumenterer automatiseringerne
  • Overvåger kørsler og håndterer fejl
  • Vedligeholder kode, nøgler og afhængigheder
  • Rådgiver om nye muligheder og risici

Jer

  • Ejer Azure-abonnementet og betaler forbruget
  • Udpeger en kontaktperson og ejere af processerne
  • Godkender nye automatiseringer og større ændringer
  • Giver besked om ændringer i jeres organisation

Vil I have nogen til at holde øje?

Vi overtager også drift af automatiseringer, I allerede har.