Servicii DevOps CI/CD și monitorizare în România

De la commit la producție, fără pași manuali

Un pipeline bun face aceleași lucruri de fiecare dată, în aceeași ordine. Construim imaginea, rulăm testele, verificăm dependențele și configurația, semnăm artefactul, apoi promovăm în staging și în producție prin GitOps. Nimeni nu copiază fișiere pe server și nimeni nu ține secrete în repozitoriu. Dacă echipa ta lucrează pe mai multe ramuri, punem protecție pe ramura principală și verificări obligatorii, ca un merge să nu treacă peste teste.

• Pipeline definit în repozitoriu, versionat împreună cu aplicația
• Teste, linting și verificare de dependențe ca porți obligatorii
• Secrete în seif, injectate la rulare, niciodată în cod
• Promovare în medii prin GitOps, cu istoric al fiecărei schimbări

Bune practici pe care le aplicăm în pipeline

Diferența dintre un pipeline care ajută și unul care încurcă stă în câteva reguli pe care nu le negociem. Le aplicăm la fiecare livrare și le lăsăm în documentația echipei tale, împreună cu runbook-urile pentru fiecare alertă configurată. Scopul este simplu de formulat și greu de obținut: o lansare trebuie să fie plictisitoare, iar o alertă primită la trei dimineața trebuie să însemne că un client chiar are o problemă reală.

• Pipeline ca cod, cu protecție pe ramura principală și porți de test
• Semnarea artefactelor și listă de componente software (SBOM) la fiecare build
• Secrete în afara repozitoriului, în seif, cu rotație documentată
• Livrare prin GitOps: starea dorită în git, nu comenzi rulate manual
• SLO cu buget de eroare și rutare a alertelor către persoana potrivită

Observabilitate care se folosește

Un dashboard pe care nu se uită nimeni nu este observabilitate. Punem metrici cu Prometheus, loguri centralizate cu Loki și, când e nevoie, urmărirea cererilor cu Tempo, apoi construim doar panourile pe care echipa ta le deschide în timpul unui incident: cereri, erori, timpi de răspuns, saturație. Alertele pornesc din obiective de disponibilitate, cu buget de eroare, ca să nu ajungi să ignori notificările din obișnuință.

• Metrici, loguri și urmărire a cererilor, în același loc
• Panouri construite pe cele patru semnale de bază
• Runbook pentru fiecare alertă, cu pași verificați

Cum intră în abonament

Construirea pipeline-ului și punerea monitorizării se fac din orele incluse: 1–8 ore pe lună pe planurile VPS, 5–10 ore pe servere dedicate, în funcție de plan, și 10 ore pe GPU, 1 oră pe cPanel începând cu planul Advanced. Ceri lucrarea din panoul de client, la Servicii DevOps, și propui termenul. Fiind lună calendaristică și fără reportare, împărțim de obicei pe etape: într-o lună pipeline-ul, în următoarea monitorizarea și runbook-urile. Peste cotă lucrăm cu facturare separată.

Cum lucrăm

1. Ceri lucrarea din panou

   Deschizi o cerere la Servicii DevOps, spui unde stă codul, cum lansați acum și ce te-ar ajuta cel mai mult luna asta.

2. Stabilim scopul și termenul

   Convenim etapele pipeline-ului, mediile și obiectivele de disponibilitate, apoi împărțim munca în orele disponibile din cotă.

3. Livrăm și rulăm în paralel

   Construim pipeline-ul, îl rulăm alături de procesul vechi până devine de încredere, apoi punem metricile, logurile și alertele.

4. Predăm cu documentație

   Primești pipeline-ul în repozitoriu, panourile exportate, definițiile de alertă și runbook-urile, ca echipa să poată reacționa fără noi.

Cazuri de utilizare

Tehnologii

• GitHub Actions
• GitLab CI
• Argo CD
• Prometheus
• Grafana
• Loki
• Tempo
• Alertmanager
• Renovate

Întrebări frecvente

• Ce este DevOps și ce face concret un inginer DevOps?

  DevOps este modul de lucru în care dezvoltarea și operarea folosesc aceleași unelte și aceleași reguli. Concret, inginerul construiește pipeline-ul de livrare, automatizează infrastructura, pune monitorizarea și alertarea, apoi intervine la incidente și reduce cauzele care le produc.

• Ce este CI/CD și de ce contează pentru o echipă mică?

  CI înseamnă că fiecare modificare este construită și testată automat, CD că trece în medii fără pași manuali. Pentru o echipă mică valoarea este mai mare: nu depinzi de persoana care știe să facă deployul și poți lansa des, cu risc mic.

• Cum monitorizezi infrastructura cu Prometheus și Grafana?

  Prometheus colectează metrici de la servere, containere și aplicație, Grafana le afișează, Alertmanager trimite notificările. Adăugăm Loki pentru loguri, ca în timpul unui incident să vezi graficul și liniile de log în același loc, fără sesiuni de SSH.

• GitLab CI sau GitHub Actions?

  Alegem în funcție de locul unde stă codul tău. GitHub Actions este mai simplu de pornit și are un ecosistem mare de acțiuni. GitLab CI oferă control mai fin pe rulări proprii și se potrivește echipelor care își găzduiesc singure instanța. Pipeline-ul rămâne portabil în ambele cazuri.

• Ce se întâmplă când trec peste orele incluse?

  Lucrarea continuă. Orele care depășesc cota lunară se acceptă și se facturează separat, la oră, iar tu vezi în panou ce s-a consumat. Când planificăm din timp, de obicei încadrăm în cotă etapele mari și lăsăm ajustările pentru luna următoare.

• Cum scalezi monitorizarea la sute de servere?

  Separăm colectarea de stocare, folosim etichete consecvente și păstrăm agregatele pe termen lung, nu fiecare eșantion. Alertele se definesc pe servicii, nu pe mașini, altfel numărul de notificări crește mai repede decât capacitatea echipei de a le citi.