Hvad er IT-drift?
IT-drift handler om at holde systemer tilgængelige, sikre og til at vedligeholde. Det gælder både servere, netværksforbindelser, logning, certifikater og de tjenester, som applikationerne bruger. Infrastrukturdrift er ikke kun at starte en server igen efter en fejl. Det er også at forebygge fejl, forstå afhængigheder og sikre, at ændringer kan gentages.
I en teknisk platform er der ofte to ansvarsområder: drift af selve infrastrukturen og ejerskab af applikationernes data og funktioner. De kræver tydelige aftaler. Eksempelvis kan platformteamet stå for Linux, kapacitet, installation og Elasticsearch-klyngens helbred, mens et andet team ejer datafelter, indeksering og anvendelse af data.
Dette er en teknisk vejledning og en del af min faglige profil som IT- og platformingeniør i København. Det er ikke et tilbud om fuld IT-outsourcing.
Linux-serverdrift på Red Hat
En sund Linux-server skal kunne opdateres, overvåges og fejlfindes uden skjulte manuelle ændringer. For Red Hat Enterprise Linux betyder det blandt andet kontrol af systemd-tjenester, diskkapacitet, logfiler, pakkeversioner og netværk.
En enkel driftskontrol
hostnamectl
systemctl --failed
df -h
free -h
journalctl -p warning -n 50 --no-pagerDisse kommandoer giver et hurtigt overblik. De er ikke en komplet helbredstest. Kapacitet skal også vurderes over tid med overvågning, alarmer og viden om den forventede belastning. Et filsystem kan eksempelvis være stabilt i dag, men stadig vokse for hurtigt til næste uge.
Læs også min Linux- og Red Hat-oversigt med kommandoer til tjenester, filsystemer og systemadministration.
Kafka, Logstash og Elasticsearch i drift
En almindelig arkitektur til central logning sender hændelser fra Filebeat eller Auditbeat til Apache Kafka. Logstash læser fra et Kafka-topic, validerer eller omformer data og sender dem videre til Elasticsearch. Andre godkendte logmodtagere kan også indgå i løsningen. Kafka, Logstash og Elasticsearch har forskellige opgaver:
| Komponent | Driftsansvar | Kontrol |
|---|---|---|
| Kafka | Transport og buffering af hændelser | Topics, adgangsrettigheder, forbrugergrupper og lag |
| Logstash | Læsning, filtrering og videresendelse | Pipelinefejl, køer, hukommelse og output |
| Elasticsearch | Indeksering, søgning og lagring | Cluster health, shards, diskforbrug og indekslivscyklus |
| Linux | Servere og tjenester | CPU, RAM, disk, netværk, systemd og patchniveau |
Hvis dokumenter ikke vises i Elasticsearch, er det ikke nok at kontrollere, om Elasticsearch er startet. Fejlen kan ligge i Kafka-adgang, et forkert topic, en forbrugergruppe, en Logstash-filterfejl eller et afvist indeks. Derfor skal hele dataflowet undersøges.
Fejlfinding: Hvor stoppede data?
- Producent: Bekræft, at Filebeat eller den relevante applikation faktisk sender hændelser, og at eventuelle fejl fremgår af loggen.
- Kafka: Undersøg om topic findes, og om den korrekte klient har læseadgang. Se efter forbrugernes lag eller fejl i forbindelsen.
- Logstash: Kontrollér pipeline-status, input, filtrering og output. Kig efter afviste hændelser, køopbygning og højt hukommelsesforbrug.
- Elasticsearch: Kontrollér klyngens helbred, disktærskler, shards, skriveblokeringer og eventuelle fejl i indekseringen.
- Slutkontrol: Bekræft, at en godkendt testhændelse kan følges gennem hele kæden. En grøn klynge alene beviser ikke, at logningen virker.
Et par sikre kontrolpunkter
systemctl status logstash --no-pager
journalctl -u logstash -n 100 --no-pager
# Elasticsearch-API: kræver korrekt adgang
GET /_cluster/health
GET /_cat/shards?vDe to sidste linjer er Elasticsearch API-stier, som bruges med en godkendt HTTP-klient eller i Dev Tools – de er ikke shellkommandoer. Produktionsmiljøer kræver korrekt TLS, autentifikation og adgangsstyring. Del aldrig tokens eller certifikatnøgler i fejlrapporter.
Automatisering af IT-drift med Ansible
Manuelle rettelser på en server er svære at gentage. Derfor er infrastruktur som kode vigtig i professionel serverdrift. Med Ansible kan man beskrive pakker, tjenester, konfigurationsfiler og forventet sluttilstand. GitHub bruges til versionsstyring og faglig gennemgang af ændringer.
En typisk proces er at ændre kode, gennemgå ændringen, teste i et afgrænset miljø og først derefter udrulle til produktion. Følsomme oplysninger hører hjemme i en godkendt secret manager som HashiCorp Vault – ikke i Git-historikken.
Det betyder ikke, at alle ændringer er risikofrie. Genstart af tjenester, nye certifikater eller ændrede Kafka-rettigheder kræver stadig planlægning, kontrol og mulighed for at rulle tilbage. Se min Ansible-guide og Vault-guide.
Stabil drift i produktion
For at vurdere en infrastrukturløsning ser jeg især på fire ting: tilgængelighed, kapacitet, sporbare ændringer og muligheden for at opdage fejl tidligt. Det skal være klart, hvem der reagerer på en alarm, hvor fejlen undersøges, og hvordan ændringer testes.
- Overvågning: Sammenhold aktuelle målinger med normale niveauer og kapacitetsgrænser.
- Indeks og lagring: Følg Elasticsearch-diskforbrug, shard-fordeling og indekslivscyklus.
- Logflow: Overvåg Kafka-lag og Logstash-behandling, ikke kun om processerne kører.
- Adgang og certifikater: Kontrollér rettigheder og udløbsdatoer inden driftsstop.
- Ændringer: Brug gennemgået kode, testmiljøer, dokumentation og en plan for tilbageførsel.
En god leverance er ikke kun en server, som kan startes. Det er en løsning, hvor andre også kan forstå opsætningen, kontrollere den og overtage driften.
IT-infrastruktur og platformdrift i København
Jeg arbejder med implementering, automatisering og fejlfinding af Linux-baserede platforme, blandt andet omkring Elasticsearch, Kafka og Logstash. På min profil kan du læse om min erfaring. På siden med IT-kompetencer findes en oversigt over mine teknologier. Du kan også kontakte mig om relevante IT-stillinger og teknisk samarbejde i Danmark.