Ce face, de fapt,
un inginer DevOps

1 Ce face un DevOps, de fapt

Definiția de manual („cultură care unește dezvoltarea cu operațiunile”) nu te ajută la interviu, pentru că nu spune ce faci luni dimineață. Uite formularea care te ajută:

Rolul are patru coloane. Toate patru apar în anunțurile de job, în ordini diferite:

Ce NU e un DevOps

• Nu e „cel care are acces la producție”. Accesul e o consecință, nu rolul. Un DevOps bun reduce numărul de oameni care trebuie să intre manual pe servere, inclusiv pe el.
• Nu e sysadmin cu nume nou. Sysadminul administrează servere existente. DevOps le creează din cod, le distruge, le recreează identic. Dacă un server nu poate fi recreat de la zero automat, nu e făcut cum trebuie.
• Nu scrie funcționalitatea produsului. Scrie cod, dar cod de automatizare: pipeline-uri, manifeste, module de infrastructură, scripturi.
• Nu e o echipă separată care primește tichete. Când devine asta, s-a reinventat exact zidul pe care DevOps trebuia să-l dărâme.

De ce a apărut rolul

Istoric, existau două echipe cu obiective opuse. Dezvoltarea era plătită să schimbe lucruri. Operațiunile erau plătite ca nimic să nu se schimbe, pentru că orice schimbare putea pica producția. Rezultatul: livrări rare, mari și riscante, la două-trei luni, noaptea, cu toată lumea în ședință.

Răspunsul DevOps e contraintuitiv: livrezi mai des, nu mai rar. O livrare mică, automată, de douăzeci de linii, e ușor de verificat și ușor de dat înapoi. O livrare de trei luni de muncă nu poate fi nici verificată, nici dată înapoi. Riscul nu vine din frecvență, vine din dimensiune.

2 Ziua de lucru a unui DevOps

Asta e ce apare constant în descrierile de rol și în relatările celor din meserie. Nu e o zi tipică — e un amestec care se schimbă zilnic, și întreruperea e parte din meserie.

3 Harta mare: de la commit la producție

Dacă reții o singură imagine din pagina asta, asta să fie. Fiecare capitol care urmează explică o cutie din desenul de mai jos.

4 Git și fluxul de lucru

Git e locul unde stă adevărul. Tot ce urmează — pipeline, imagine, livrare — pornește de la un commit. Dacă nu e în Git, nu există.

Două modele de ramificare

GitOps — ideea care leagă Git de Kubernetes

În GitOps, starea dorită a clusterului stă într-un depozit Git, iar un agent care rulează în cluster (Argo CD sau Flux) compară permanent ce e în Git cu ce e în cluster și corectează diferența. Consecințe practice:

• Nimeni nu mai dă kubectl apply manual în producție. Modifici fișierul, deschizi PR, se aprobă, agentul aplică.
• Dacă cineva modifică ceva direct pe cluster, agentul îl dă înapoi — deviația se autocorectează.
• Revenirea la versiunea anterioară e un git revert. Istoricul livrărilor e istoricul Git.

5 CI/CD — conceptele

Cele trei litere care se confundă

Etapele unui pipeline, în ordine

Strategii de livrare

6 GitHub Actions, în detaliu

E sistemul de automatizare integrat în GitHub. Rulează pe mașini pe care le pune GitHub la dispoziție („runner”), declanșat de evenimente din depozit. A devenit implicit în majoritatea echipelor noi, și e ce cer cele mai multe anunțuri.

6.1 Vocabularul, de la mare la mic

6.2 Un workflow complet, comentat linie cu linie

# Numele care apare în fila Actions
name: Build and deploy

# ---- CÂND rulează ----
on:
  push:
    branches: [main]          # doar pe main
    paths:                    # și doar dacă s-a schimbat ceva relevant
      - 'src/**'
      - 'Dockerfile'
  pull_request:              # și la fiecare PR, ca să prindem devreme
  workflow_dispatch:         # plus un buton manual în interfață

# ---- Permisiuni: minimul necesar, explicit ----
permissions:
  contents: read            # poate citi codul
  id-token: write          # poate cere un token OIDC (pentru cloud, fără parole)

# ---- Un singur rulaj pe ramură; cel vechi se anulează ----
concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true

env:
  IMAGE: ghcr.io/${{ github.repository }}

jobs:

  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:                 # același job, pe 3 versiuni de Node, în paralel
        node: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm          # păstrează dependențele între rulaje = build mai rapid
      - run: npm ci
      - run: npm test

  build:
    needs: test                # pornește doar dacă „test” a trecut
    runs-on: ubuntu-latest
    outputs:
      tag: ${{ steps.meta.outputs.tag }}
    steps:
      - uses: actions/checkout@v4
      - id: meta
        run: echo "tag=${GITHUB_SHA::7}" >> $GITHUB_OUTPUT
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ${{ env.IMAGE }}:${{ steps.meta.outputs.tag }}

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'   # NU livrăm din PR-uri
    runs-on: ubuntu-latest
    environment: production    # aici se cere aprobarea umană
    steps:
      - uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: ${{ secrets.WIF_PROVIDER }}
          service_account: ${{ secrets.GCP_SA }}
      - run: |
          kubectl set image deployment/api \
            api=${{ env.IMAGE }}:${{ needs.build.outputs.tag }} -n prod
          kubectl rollout status deployment/api -n prod --timeout=180s

6.3 Secretele și autentificarea

Trei niveluri, în ordinea în care sunt căutate: organizație (partajate de mai multe depozite), depozit, mediu (cele mai restrânse — există doar în joburile care declară environment:). Cele de mediu sunt cele mai sigure pentru producție, fiindcă se pot lega de aprobatori.

Ce trebuie știut:

• Secretele sunt criptate și ascunse în loguri, dar un pas care rulează cod arbitrar le poate scoate. De aceea contează în ce pași le dai.
• Nu se transmit automat către workflow-uri din alte depozite (fork-uri) — asta e protecția împotriva unui PR malițios.
• secrets.GITHUB_TOKEN e generat automat pentru fiecare rulaj și expiră la final. Setează-l implicit pe „read-only” la nivel de organizație și cere explicit mai mult cu permissions:.

OIDC — cum scapi complet de chei

Varianta veche: pui un AWS_SECRET_ACCESS_KEY în secretele depozitului. Cheia e permanentă; dacă scapă, e valabilă până o rotești manual. Varianta actuală, recomandată: OpenID Connect. Workflow-ul cere de la GitHub un token cu durată scurtă care descrie cine este („depozitul X, ramura main”), iar cloudul e configurat să aibă încredere în GitHub și să dea un rol temporar în schimbul acelui token. Nicio parolă nu mai stă nicăieri.

6.4 Securitatea acțiunilor externe

• Fixează pe hash, nu pe etichetă. uses: cutare/actiune@v3 înseamnă „ce e acum în v3” — iar eticheta poate fi mutată de autor peste cod nou. uses: cutare/actiune@a81bbbf... înseamnă exact acel cod. Lași Dependabot să-ți propună actualizările.
• Evită pull_request_target dacă nu știi exact ce faci. Spre deosebire de pull_request, rulează cu secretele depozitului și cu permisiuni de scriere, în contextul PR-ului — inclusiv al unuia venit de la un străin.
• Nu pune date din PR direct în run:. Un titlu de PR care conține caractere de shell devine cod executat. Trece valoarea printr-o variabilă de mediu și folosește variabila.

6.5 Refolosire: două mecanisme diferite

6.6 Depanare

• Adaugă secretul de depozit ACTIONS_STEP_DEBUG=true și logurile devin mult mai detaliate.
• Un job care „nu pornește” are aproape întotdeauna o condiție if: falsă sau un filtru paths: care nu s-a potrivit — nu o defecțiune.
• „Merge local, nu merge în CI” înseamnă de obicei o dependență instalată pe calculatorul tău și absentă pe runnerul curat, sau o variabilă de mediu care există doar la tine.
• Pentru un rulaj lent, uită-te întâi la cache: fără actions/cache sau fără cache: în acțiunea de setup, reinstalezi tot de fiecare dată.

7 Jenkins și Azure DevOps — ce ai tu deja

Jenkins e sistemul clasic de automatizare, din 2011, instalat pe servere proprii. Are un controler și agenți care execută. Diferența majoră față de GitHub Actions: Jenkins e o aplicație pe care o administrezi tu — cu pluginuri, cu actualizări, cu backup — în timp ce Actions e un serviciu.

7.1 Anatomia unui Jenkinsfile

pipeline {
  agent { label 'linux-docker' }        // pe ce agent rulează

  environment {                           // variabile pentru tot pipeline-ul
    IMAGE = "registry.intern/api"
    REG   = credentials('registry-creds') // secret din Jenkins Credentials
  }

  triggers { pollSCM('H/5 * * * *') }    // sau webhook din Git

  stages {
    stage('Build') {
      steps { sh 'mvn -B clean package' }
    }
    stage('Test') {
      steps { sh 'mvn test' }
      post { always { junit 'target/surefire-reports/*.xml' } }
    }
    stage('Image') {
      steps { sh "docker build -t $IMAGE:${GIT_COMMIT} ." }
    }
    stage('Deploy green') {
      steps { sh './deploy.sh green' }
    }
    stage('Switch traffic') {
      input { message 'Comut traficul pe green?' }  // aprobare umană
      steps { sh './switch.sh green' }
    }
  }

  post {
    failure { mail to: 'echipa@firma.ro', subject: "Pipeline picat: ${env.JOB_NAME}" }
    always  { cleanWs() }
  }
}

7.2 Traducerea Jenkins → GitHub Actions

Dacă te întreabă „ai lucrat cu GitHub Actions?”, răspunsul bun nu e da sau nu. E să arăți că știi corespondența — pentru că exact asta face cineva care migrează, iar migrarea e o sarcină frecventă în anunțuri.

7.3 Azure DevOps, pe scurt

Suita Microsoft: Repos (Git), Pipelines (CI/CD), Boards (tichete), Artifacts (pachete), Test Plans. Pipeline-urile sunt YAML, apropiate de Actions ca formă: trigger, pool, stages, jobs, steps. Ce e specific: service connection (identitatea cu care pipeline-ul intră în Azure), variable group (variabile partajate, legate opțional de Key Vault), environment cu approvals and checks — echivalentul porții de producție.

8 Docker și containerele

8.1 Ce e, de fapt, un container

Un container este un proces obișnuit pe mașina gazdă, care vede doar o felie din sistem: propriul său sistem de fișiere, propria rețea, propria listă de procese. Izolarea e făcută de nucleul Linux (namespaces și cgroups). Nu are nucleu propriu — îl folosește pe al gazdei.

8.2 Imagine și container

Imaginea e șablonul: un pachet nemodificabil cu aplicația și tot ce-i trebuie. Containerul e o instanță care rulează din acea imagine. O imagine, oricâte containere. Analogia care se reține: imaginea e clasa, containerul e obiectul.

8.3 Straturi și de ce contează ordinea

Fiecare instrucțiune din Dockerfile creează un strat. Straturile se pun în memoria-tampon și se refolosesc — dar când un strat se schimbă, toate cele de după el se reconstruiesc. De aici regula practică: pune întâi ce se schimbă rar.

FROM node:20
WORKDIR /app
COPY . .           # orice fișier schimbat
RUN npm install    # invalidează asta
CMD ["node","server.js"]

FROM node:20
WORKDIR /app
COPY package*.json ./   # se schimbă rar
RUN npm ci
COPY . .               # se schimbă des, dar e ultimul
CMD ["node","server.js"]

8.4 Build în mai multe etape

Construiești într-o imagine mare, cu compilator și unelte, apoi copiezi doar rezultatul într-o imagine mică. Imaginea finală nu conține compilatorul, deci e mai mică și are o suprafață de atac mai redusă.

# --- etapa 1: construire ---
FROM golang:1.23 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /out/api ./cmd/api

# --- etapa 2: rulare ---
FROM gcr.io/distroless/static:nonroot
COPY --from=build /out/api /api
USER nonroot:nonroot      # NU rulăm ca root
EXPOSE 8080
ENTRYPOINT ["/api"]

8.5 Reguli de securitate pentru imagini

• Nu rula ca root. Implicit, procesul din container e root. Dacă cineva iese din container, iese ca root.
• Sistem de fișiere doar-citire pentru procesul principal, plus volume pentru ce chiar trebuie scris.
• Nu băga secrete în imagine. Chiar dacă le ștergi într-un strat ulterior, stratul în care au fost adăugate rămâne și poate fi extras. Secretele se injectează la rulare.
• Fixează versiunile de bază. FROM node:20.11.1-alpine, nu FROM node:latest — altfel build-ul de azi diferă de cel de ieri.
• Scanează imaginea (Trivy, Grype) ca pas în pipeline.

8.6 Ce se pierde când moare containerul

Sistemul de fișiere al containerului e efemer: dispare odată cu el. Ce trebuie să supraviețuiască merge într-un volum sau într-un serviciu extern (bază de date, obiect storage). Logurile se scriu pe ieșirea standard, nu în fișiere din container — le colectează platforma.

9 Kubernetes — fundamentele

9.1 Problema pe care o rezolvă

Ai cincizeci de containere care trebuie să ruleze pe douăzeci de mașini. Cine decide pe care mașină merge fiecare? Ce se întâmplă când o mașină moare la trei noaptea? Cum trimiți trafic către containere care apar și dispar și își schimbă adresa? Cum livrezi o versiune nouă fără să oprești serviciul? Kubernetes e răspunsul la toate astea, la un loc.

9.2 Ideea centrală: stare dorită și reconciliere

9.3 Arhitectura clusterului

10 Kubernetes — obiectele

10.1 Pod

Cea mai mică unitate pe care Kubernetes o poate programa pe un nod. Conține unul sau mai multe containere care împart aceeași adresă IP, aceleași porturi și pot împărți volume — containerele dintr-un pod se văd între ele pe localhost. În practică, un container principal, plus eventual unul ajutător (sidecar): colector de loguri, proxy de rețea.

Un pod este de unică folosință. Nu se repară: se șterge și se creează altul, cu alt IP. Asta e și motivul pentru care nu te conectezi niciodată direct la IP-ul unui pod, ci la un Service.

10.2 Deployment

Obiectul cu care lucrezi zilnic. Îi spui ce imagine, câte copii și cum să facă actualizarea; el creează un ReplicaSet, care creează podurile. La fiecare versiune nouă creează un ReplicaSet nou și îl reduce pe cel vechi — de aici vine și posibilitatea de revenire.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: prod
spec:
  replicas: 3                 # câte copii vreau
  selector:
    matchLabels: { app: api }  # ce poduri îmi aparțin
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1             # am voie cu 1 pod în plus în timpul livrării
      maxUnavailable: 0       # dar NICIUNUL în minus → zero downtime
  template:                    # de aici în jos e rețeta unui pod
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry/api:9f2c1ab   # NU „latest”: vrei să știi ce rulează
          ports: [{ containerPort: 8080 }]
          env:
            - name: DB_HOST
              valueFrom:
                configMapKeyRef: { name: api-config, key: db_host }
            - name: DB_PASS
              valueFrom:
                secretKeyRef: { name: api-secret, key: db_pass }
          resources:
            requests: { cpu: "200m", memory: "256Mi" }  # pentru planificare
            limits:   { cpu: "1",    memory: "512Mi" }  # plafon la rulare
          readinessProbe:                            # pot primi trafic?
            httpGet: { path: /ready, port: 8080 }
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:                             # mai sunt viu?
            httpGet: { path: /healthz, port: 8080 }
            initialDelaySeconds: 20
            periodSeconds: 10

10.3 Service — cele patru tipuri

Serviciul găsește podurile prin etichete (selector), nu prin nume. Dacă schimbi eticheta din pod și uiți selectorul, serviciul rămâne fără destinații și primești eroare de conectare deși toate podurile rulează perfect. E una dintre cele mai frecvente cauze de „merge pe podul X, nu merge prin serviciu”.

10.4 Ingress

Un Service de tip LoadBalancer per aplicație devine scump și greu de administrat. Ingress e stratul de deasupra: un singur punct de intrare, care rutează după numele domeniului și după cale către servicii interne diferite, și care termină TLS-ul într-un singur loc. Are nevoie de un ingress controller instalat în cluster (nginx, Traefik, cel al furnizorului) — obiectul Ingress singur nu face nimic.

10.5 ConfigMap și Secret

Configurația nu se pune în imagine. Se pune în ConfigMap (setări obișnuite) sau Secret (parole, chei, certificate) și se injectează în pod, fie ca variabile de mediu, fie ca fișiere montate.

10.6 Celelalte tipuri de workload

10.7 Stocare

Trei obiecte legate: PersistentVolume (discul propriu-zis), PersistentVolumeClaim (cererea aplicației: „vreau 20 GB rapizi”) și StorageClass (rețeta prin care se creează automat discul la furnizor). În practică scrii doar PVC-ul; restul se rezolvă singur. De reținut: un disc în cloud e de obicei legat de o zonă — un pod care are nevoie de el poate fi programat doar în acea zonă.

11 Livrare și sănătate: cele două lucruri care se întreabă cel mai des

11.1 Rolling update, pas cu pas

# schimbă imaginea
kubectl set image deployment/api api=registry/api:9f2c1ab -n prod

# urmărește — iese cu cod diferit de zero dacă nu reușește în 180s
kubectl rollout status deployment/api -n prod --timeout=180s

# istoricul versiunilor
kubectl rollout history deployment/api -n prod

# revenire la versiunea anterioară
kubectl rollout undo deployment/api -n prod

# revenire la o revizie anume
kubectl rollout undo deployment/api --to-revision=4 -n prod

# repornire curată, fără schimbare de imagine (util după schimbarea unui Secret)
kubectl rollout restart deployment/api -n prod

11.2 Probe — cele trei și la ce folosesc

11.3 Oprirea elegantă

Când un pod e oprit, Kubernetes face două lucruri în paralel: îl scoate din lista destinațiilor Service și trimite SIGTERM procesului. Fiindcă sunt în paralel, există o fereastră de câteva sute de milisecunde în care podul încă primește cereri noi dar deja a început să se oprească. Soluția standard e un preStop care așteaptă câteva secunde înainte de oprire, plus o aplicație care tratează SIGTERM: nu mai acceptă conexiuni noi, termină ce are în lucru, apoi iese. terminationGracePeriodSeconds (implicit 30) e răbdarea; după el vine SIGKILL.

12 Resurse și scalare

12.1 requests și limits

12.2 Cele trei feluri de scalare

12.3 Unde pun podurile — plasare

• nodeSelector / nodeAffinity — „pune podul doar pe noduri cu GPU” sau „preferabil în zona A”.
• podAntiAffinity — „nu pune două copii ale aceluiași serviciu pe același nod”. Fără asta, cele trei replici pot ajunge pe un singur nod și un nod căzut înseamnă serviciu căzut.
• topologySpreadConstraints — distribuie uniform peste zone de disponibilitate.
• taints și tolerations — mecanismul invers: nodul respinge tot, mai puțin podurile care „tolerează” explicit. Așa se rezervă noduri pentru sarcini speciale.
• PodDisruptionBudget — „minimum două poduri disponibile oricând”. Protejează în timpul operațiunilor planificate, ca actualizarea nodurilor.

13 Securitate în cluster

13.1 RBAC — cine are voie ce

Patru obiecte, două perechi. Role dă permisiuni într-un singur namespace; ClusterRole în tot clusterul. RoleBinding și ClusterRoleBinding leagă rolul de cineva: un utilizator, un grup sau un ServiceAccount (identitatea cu care rulează un pod).

kind: Role
metadata: { namespace: echipa-a, name: dezvoltator }
rules:
  - apiGroups: [""]
    resources: [pods, pods/log, services, configmaps]
    verbs: [get, list, watch]          # doar citire
  - apiGroups: [apps]
    resources: [deployments]
    verbs: [get, list, watch, patch]   # poate schimba imaginea, nu poate șterge

Comanda pe care o folosești ca să verifici: kubectl auth can-i delete pods --as=ana -n prod.

13.2 Pod Security Admission

PodSecurityPolicy a fost scos din uz în versiunea 1.21 și eliminat în 1.25. Înlocuitorul integrat e Pod Security Admission: pui o etichetă pe namespace și clusterul refuză podurile care nu respectă nivelul.

Se aplică în trei moduri: enforce (respinge), audit (scrie în jurnal) și warn (avertizează utilizatorul). Calea obișnuită de adopție e să pornești cu warn, să vezi ce s-ar strica, apoi să treci pe enforce. Pentru reguli mai complexe se folosesc OPA Gatekeeper sau Kyverno.

13.3 NetworkPolicy

Implicit, în Kubernetes orice pod poate vorbi cu orice pod, din orice namespace. E cea mai surprinzătoare valoare implicită din sistem și un răspuns bun la „ce ai îmbunătăți într-un cluster moștenit”. NetworkPolicy schimbă asta: descrii ce trafic e permis, iar restul e blocat. Atenție: are efect doar dacă plugin-ul de rețea îl susține (Calico, Cilium; unele configurații simple îl ignoră tăcut).

13.4 Namespace-ul nu e graniță de securitate

13.5 Restul listei de igienă

• Dezactivează montarea automată a tokenului de ServiceAccount în podurile care nu vorbesc cu API-ul (automountServiceAccountToken: false).
• Criptează etcd în repaus, sau ține secretele într-un seif extern.
• Nu folosi :latest. Nu poți ști ce rulează și nu poți reproduce o problemă.
• Scanează imaginile în pipeline și blochează pe vulnerabilități critice.
• Ține jurnalul de audit al API-ului pornit. E singura sursă care îți spune cine a schimbat ce.

14 Depanare pe cluster — partea cea mai întrebată

La interviurile de Kubernetes din 2026, întrebările de tip „ce e un pod” sunt doar încălzirea. Partea care contează e scenariul: „ți se spune că serviciul e căzut, ce faci?”. Se testează metoda, nu memoria.

14.1 Ordinea în care investighezi

# 1. Ce stare au podurile? (aici afli 60% din răspuns)
kubectl get pods -n prod -o wide

# 2. De ce e în starea aia? Uită-te la EVENIMENTE, la finalul ieșirii.
kubectl describe pod api-7d9f-x2k -n prod

# 3. Ce spune aplicația?
kubectl logs api-7d9f-x2k -n prod
kubectl logs api-7d9f-x2k -n prod --previous   # logurile containerului MORT — esențial la CrashLoop

# 4. Ce s-a întâmplat recent în tot namespace-ul?
kubectl get events -n prod --sort-by=.lastTimestamp | tail -30

# 5. Serviciul are destinații? (lista goală = selector greșit sau poduri ne-gata)
kubectl get endpoints api -n prod

# 6. Din interiorul unui pod: DNS și conectivitate
kubectl exec -it api-7d9f-x2k -n prod -- sh
  nslookup api.prod.svc.cluster.local
  wget -qO- http://api:8080/healthz

# 7. Consumul real
kubectl top pods -n prod
kubectl top nodes

# 8. Nodurile sunt sănătoase?
kubectl get nodes
kubectl describe node nod-3 | grep -A5 Conditions

14.2 Tabelul de diagnostic

14.3 Un traseu de depanare de rețea, până la capăt

„Serviciul A nu poate ajunge la serviciul B.” Ordinea care găsește problema fără ghicit:

1. kubectl get pods -l app=b — există poduri și sunt READY? Un pod ne-gata nu e în serviciu.
2. kubectl get endpoints b — lista e goală? Atunci selectorul serviciului nu se potrivește cu etichetele podurilor. Asta e cauza cea mai frecventă.
3. Din podul A: nslookup b.namespace.svc.cluster.local — dacă DNS-ul nu răspunde, problema e CoreDNS, nu serviciul tău.
4. Din podul A: wget -qO- http://b:8080/ — dacă DNS-ul merge dar conexiunea e refuzată, verifică portul: port din Service trebuie să corespundă cu targetPort și cu portul real al aplicației.
5. kubectl get networkpolicy -n namespace — există o politică ce blochează? Dacă e prima politică din namespace, a schimbat implicitul din „totul permis” în „doar ce e scris”.

15 Terraform și infrastructura ca și cod

15.1 Ideea

Infrastructura nu se creează cu mâna din interfața cloudului. Se descrie în fișiere, fișierele stau în Git, iar unealta aplică diferența dintre ce e scris și ce există. Consecințe: mediile sunt reproductibile, schimbările trec prin revizie ca orice cod, și există un istoric al motivelor.

15.2 Ciclul

15.3 Starea — subiectul care separă

Terraform ține un fișier de stare care leagă ce ai scris de ce există în realitate. Fără el nu știe dacă trebuie să creeze sau să modifice.

• Starea nu stă local. Stă într-un depozit comun (S3 cu blocare în DynamoDB, un container Azure Storage, GCS), altfel doi colegi care aplică simultan își calcă starea unul altuia.
• Blocarea e obligatorie. Două apply în paralel pe aceeași stare o pot corupe.
• Starea conține secrete în clar. Parola unei baze de date creată de Terraform apare în fișierul de stare. Deci: criptare, acces restrâns, și niciodată în Git.
• Deviația apare când cineva modifică manual în consolă. terraform plan o arată. Remediul tehnic e import sau realiniere; remediul real e organizațional — se scot drepturile de scriere manuală în producție.

terraform {
  required_version = "~> 1.9"
  backend "s3" {                    # starea, la distanță și blocabilă
    bucket         = "tf-state-firma"
    key            = "prod/retea.tfstate"
    region         = "eu-central-1"
    dynamodb_table = "tf-locks"
    encrypt        = true
  }
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.60" }
  }
}

variable "mediu" {
  type    = string
  default = "prod"
}

module "retea" {                     # module = refolosire între medii
  source = "./modules/retea"
  mediu  = var.mediu
  cidr   = "10.20.0.0/16"
}

resource "aws_db_instance" "principal" {
  identifier        = "db-${var.mediu}"
  engine            = "postgres"
  instance_class    = "db.t4g.medium"
  allocated_storage = 50
  lifecycle {
    prevent_destroy = true            # plasă: nu se poate șterge din greșeală
  }
}

output "db_endpoint" {
  value = aws_db_instance.principal.endpoint
}

16 Cloud: ce trebuie să știi din fiecare

Nu-ți trebuie certificare ca să răspunzi la interviu. Îți trebuie harta serviciilor de bază și echivalențele, pentru că anunțurile cer „AWS sau Azure sau GCP”, iar cine știe unul îl învață pe celălalt.

Costul, subiectul care apare la senior

Un DevOps senior e întrebat despre cost, pentru că e o pârghie reală. Principalele surse de risipă și ce faci cu ele:

• Resurse rezervate mult peste consumul real. Se corectează măsurând consumul efectiv și ajustând requests. Aici e cea mai mare economie, de obicei.
• Medii de test care rulează noaptea și în weekend. Se opresc pe program.
• Discuri și adrese IP rămase orfane după ștergerea resurselor care le foloseau.
• Trafic între zone de disponibilitate, care se taxează și pe care nu-l vede nimeni până nu se uită la factură.
• Etichetare pe echipă și pe mediu, altfel factura nu poate fi atribuită nimănui și nimeni nu o optimizează.

17 Monitorizare, loguri și SLO

17.1 Cei trei piloni

17.2 Ce se monitorizează, concret

Două seturi de reguli care se citează des:

17.3 SLI, SLO, SLA și bugetul de erori

17.4 Alertele

Cea mai frecventă problemă în echipele reale nu e lipsa alertelor, ci prea multe. Când primești patruzeci de alerte pe zi și treizeci și nouă nu cer nimic, încetezi să le citești — și o ratezi pe a patruzecea. Regulile care rezolvă:

• Alertează pe simptom, nu pe cauză. „Rata de erori a crescut peste prag” e util. „CPU la 90%” nu e — poate fi perfect normal.
• Fiecare alertă care sună noaptea trebuie să ceară o acțiune umană imediată. Dacă poate aștepta până dimineață, nu e alertă, e tichet.
• Fiecare alertă are un runbook — un document scurt care spune ce verifici și ce faci.
• Alertează pe rata de consum a bugetului de erori, nu pe fiecare vârf.

17.5 Unelte

Prometheus colectează metrici trăgându-le periodic de la aplicații și se interoghează cu PromQL. Grafana desenează. Alertmanager rutează alertele și le grupează. Loki sau ELK pentru loguri. Jaeger sau Tempo pentru urme. OpenTelemetry e standardul de instrumentare care le alimentează pe toate. Alternativa comercială care le face pe toate într-un singur produs: Datadog, New Relic, Dynatrace.

18 Incidente și gardă

18.1 Rolurile într-un incident mare

• Comandantul incidentului — coordonează, nu depanează. Ia deciziile și ține ordinea.
• Responsabilul de comunicare — informează părțile interesate și clienții la intervale fixe, ca nimeni să nu întrerupă echipa tehnică ca să întrebe „cum merge”.
• Cei care repară — se uită efectiv în sistem.
• Secretarul — notează cronologia cu ore exacte. Fără ea, analiza de după e o discuție din amintiri.

În echipe mici, o persoană poate purta mai multe pălării. Ce nu se face niciodată: comandantul să intre și el cu mâinile în sistem, pentru că atunci nimeni nu mai are imaginea de ansamblu.

18.2 Analiza de după, fără vinovați

Principiul: oamenii nu sunt cauza; sistemul care a permis greșeala este. Dacă o comandă greșită a putut șterge producția, problema nu e omul care a scris-o, e faptul că sistemul a acceptat-o fără confirmare, fără limită de rază și fără posibilitate de revenire. Dacă în analiză apare numele cuiva în loc de o cauză de sistem, oamenii vor ascunde incidentele data viitoare, și pierzi exact informația care ți-ar fi trebuit.

Structura documentului: rezumat, impact (cine, cât timp, ce nu a mers), cronologie cu ore, cauze contributive (la plural), ce a mers bine, ce a mers prost, acțiuni cu responsabil și termen. Fără ultima secțiune, e literatură.

19 Securitate în pipeline (DevSecOps)

Ideea într-o frază: verificările de securitate se mută devreme în procesul de dezvoltare, unde sunt ieftine, în loc să fie un audit la final.

Lanțul de aprovizionare software

Subiect tot mai prezent după incidentele din ultimii ani. Punctele principale: fixează acțiunile și imaginile pe hash, nu pe etichetă; semnează artefactele și verifică semnătura la livrare; generează SBOM ca să știi în cinci minute dacă ești afectat de o vulnerabilitate nouă; dă pipeline-ului permisiuni minime, obținute prin OIDC în loc de chei permanente.

20 Bash și Python

Aproape orice anunț cere „scripting”. Nu ți se cere să fii programator: ți se cere să automatizezi ceva repetitiv și să nu faci pagubă când scriptul dă greș la jumătate.

20.1 Antetul care te salvează

#!/usr/bin/env bash
set -euo pipefail
# -e  : oprește la prima comandă care eșuează
# -u  : eroare la folosirea unei variabile nedefinite (prinde typo-urile)
# -o pipefail : o conductă eșuează dacă ORICARE element eșuează, nu doar ultimul

IFS=$'\n\t'                  # nu mai despărți pe spații — protejează căile cu spații

# curățenie garantată, orice s-ar întâmpla
TMP=$(mktemp -d)
trap 'rm -rf "$TMP"' EXIT

# argument obligatoriu, cu mesaj clar dacă lipsește
MEDIU=${1:?folosire: $0 <mediu>}

log() { printf '%s [%s] %s\n' "$(date +%FT%T)" "$1" "$2" >&2; }

# reîncercare cu așteptare crescătoare — obligatoriu la orice apel de rețea
retry() {
  local n=0 max=5 delay=2
  until "$@"; do
    n=$((n+1))
    [ "$n" -ge "$max" ] && { log ERROR "eșec după $max încercări: $*"; return 1; }
    log WARN "încercarea $n a eșuat, reiau în ${delay}s"
    sleep "$delay"; delay=$((delay*2))
  done
}

retry curl -fsS "https://api.intern/$MEDIU/status" > "$TMP/status.json"
log INFO "gata"

20.2 Când treci la Python

Regula practică: Bash până la o sută de linii sau până când începi să parsezi JSON serios; de acolo, Python. Semnalele că ai depășit: ai nevoie de structuri de date, de tratare de erori pe cazuri, de apeluri HTTP cu antete și reîncercări, de teste.

import os, sys, json, logging
import requests
from tenacity import retry, stop_after_attempt, wait_exponential

logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s")

TOKEN = os.environ["API_TOKEN"]      # din mediu, NU din cod

@retry(stop=stop_after_attempt(5), wait=wait_exponential(min=1, max=30))
def ia_starea(mediu: str) -> dict:
    r = requests.get(f"https://api.intern/{mediu}/status",
                     headers={"Authorization": f"Bearer {TOKEN}"},
                     timeout=10)          # timeout SIEMPRE — altfel atârnă la infinit
    r.raise_for_status()
    return r.json()

if __name__ == "__main__":
    try:
        print(json.dumps(ia_starea(sys.argv[1]), indent=2))
    except Exception as e:
        logging.error("nu am putut citi starea: %s", e)
        sys.exit(1)                        # cod de ieșire corect, ca pipeline-ul să știe

20.3 Linux — ordinea în care investighezi un server

21 Experiența ta, tradusă în limbajul rolului

Asta e secțiunea de care ai cea mai mare nevoie. Nu îți lipsește experiența — îți lipsește obiceiul de a o numi în cuvintele pe care le caută cel din fața ta. Un om care a ținut producția în picioare la Metro și a migrat cozi de mesaje la Volvo are exact fondul pe care se construiește rolul de DevOps; dacă îl povestește cu termenii din 2012, ascultătorul aude „administrator de sistem”, nu „inginer de fiabilitate”.

21.1 Unde ești tare și unde vei fi presat

22 Plan de învățare

Nu ai nevoie să știi tot. Ai nevoie ca lucrurile pe care le spui să fie susținute de ceva ce ai atins cu mâna. Planul de mai jos e construit pe asta: fiecare bloc se termină cu un lucru care există pe calculatorul tău și despre care poți vorbi la trecut.

Certificări, dacă vrei să pui ceva pe hârtie

CKA (Certified Kubernetes Administrator) e cea mai bine văzută dintre toate, pentru că e examen practic — stai în terminal și rezolvi. KCNA e varianta de intrare, doar cu întrebări. Terraform Associate e ieftin și rapid. Certificările de furnizor (AWS, Azure, Google Cloud) contează mai ales când firma lucrează pe acel furnizor. Nicio certificare nu înlocuiește un cluster stricat și reparat, dar CKA trece filtrele automate de selecție, ceea ce e o problemă reală și separată.

23 Glosar

Termenii care apar în conversație și se presupun cunoscuți. Dacă unul dintre ei te blochează în timpul interviului, ai pierdut firul propoziției — de aceea sunt aici.