DevOps érettségfelmérés: hol tart a csapatod?

A DevOps nem egy eszközlista és nem is egy „CI/CD be van kapcsolva” jellegű pipa. A DevOps valójában szállítási képesség: mennyire gyorsan, stabilan és kiszámíthatóan tud a csapat értéket vinni élesbe, majd üzemeltetés közben tanulni belőle.

A „DevOps érettségfelmérés” célja ezért nem az, hogy iskolai osztályzatot adjon, hanem hogy tiszta képet adjon arról:

• hol vannak a legnagyobb fékek a delivery flow-ban,

• mi okoz incidenteket, visszagörgetéseket, túl sok manuális munkát,

• és mely 3–5 beavatkozás hozza a legnagyobb javulást 30–90 nap alatt.

Mikor érdemes DevOps érettségfelmérést csinálni?

Jellemző kiváltó okok (ezeknél a pontoknál a felmérés tipikusan gyors ROI-t ad):

• Lassú release ciklusok, „minden deploy fáj”, túl nagy kockázatérzet.

• Gyakori éles hibák, magas változtatási hibaarány, sok hotfix.

• Üzemeltetési túlterhelés, ticket- és riasztásáradat, alacsony MTTR.

• NIS2, ISO 27001, audit vagy nagyvállalati beszállítói elvárások miatt bizonyítékok kellenek (kontrollok, traceability, naplózás).

• Felhőmigráció, modernizáció vagy legacy bontás előtt szeretnél stabil alapot.

Ha a DevOps nálatok még „alapozás” fázisban van, érdemes a fogalmi és technikai alapokat is áttekinteni. Ehhez kapcsolódóan hasznos kiegészítő olvasmány lehet a DevOps alapok: nulláról az éles környezetig vezető út 2026-ban cikk.

Mit mérjünk? A DORA metrikák mint közös nyelv

A DevOps érettségfelmérés egyik legjobb kiindulópontja a DORA metrikarendszer, mert konkrétan a szállítás és stabilitás eredményét méri. A Google Cloud által gondozott DORA kutatás (State of DevOps) évek óta azt mutatja, hogy ezek a mutatók erősen összefüggenek a szervezeti teljesítménnyel.

• Forrás: DORA metrics (Google Cloud)

A 4 klasszikus DORA mutató:

• Deployment frequency: milyen gyakran telepítetek élesbe.

• Lead time for changes: mennyi idő telik el a commit (vagy merge) és az éles futás között.

• Change failure rate: a változtatások mekkora része okoz hibát, incidentet, rollbacket.

• Time to restore service (MTTR): hiba esetén mennyi idő visszaállni.

Egy jó érettségfelmérésnél ezek nem önmagukban érdekesek, hanem azért, mert rávezetnek az okokra: hol áll meg a flow (jóváhagyásoknál, tesztelésnél, release-nél, infrastruktúránál, kézi lépéseknél, silóknál).

DevOps érettségi modell, ami a gyakorlatban működik

Az érettség modellek akkor hasznosak, ha nem túl elméletiek, és közvetlenül beavatkozási pontokra fordíthatók. A következő 5 szintet sok csapatnál jól lehet használni.

Mely területeket érdemes vizsgálni egy felmérésben?

A DevOps nem csak fejlesztés. A felmérés akkor ad érdemi képet, ha több dimenziót néz:

A security dimenziót érdemes külön kezelni, mert sok szervezetnél ez az a terület, ahol a legnagyobb a kockázat és az auditnyomás. Ha ezt a részét szeretnéd mélyebben építeni, kapcsolódó anyag: DevSecOps gyakorlatban: így építs biztonságos CI/CD-t.

Hogyan néz ki egy jó DevOps érettségfelmérés lépésről lépésre?

A cél az, hogy gyorsan, de bizonyítékokra támaszkodva állítsunk fel képet. A tipikus, jól működő folyamat:

1) Cél és scope tisztázása (0,5–1 nap)

Itt dől el, hogy a felmérés nem lesz „mindenről is”:

• Mely termék(ek)re, csapat(ok)ra vonatkozik?

• Mi a fő üzleti cél: gyorsabb release, stabilitás, audit, költség, skálázás?

• Mi számít sikernek 90 nap alatt?

Gyakorlati tanács: válassz 1–2 kritikus értékáramot (value stream), különben a felmérés túl széles lesz és nem vezet akcióhoz.

2) Adatgyűjtés és artefakt ellenőrzés (2–5 nap)

A „valóság” általában ott van, ahol a nyomok vannak:

• Git (PR-ok, review idők, branch stratégia)

• CI/CD rendszer (pipeline futások, hibák, idők)

• Ticketing (lead time, rework, WIP)

• Incident rendszer (MTTR, gyakori okok)

• Infra (IaC repo-k, környezetek driftje)

• Security tooling (SAST/SCA, secrets, artifact policy)

Itt érdemes már megpróbálni a DORA metrikák minimum baseline-ját kinyerni. Nem kell tökéletes adat, de közelítő trendek kellenek.

3) Interjúk és workshop (1–2 nap)

A számok megmondják, hogy baj van, az emberek megmondják, hogy miért.

Jó minta interjú alanyokra:

• fejlesztők és tech lead

• QA vagy test automation

• platform/DevOps mérnökök

• üzemeltetés/on-call

• product owner vagy delivery vezető

• security/compliance (ha van)

A workshop célja: közös kép a bottleneckekről, és közös prioritás a javításokról. Ha érdekel a kiszámítható szállítás „governance” oldala, ide kapcsolódik a Projektmenedzsment IT-ban: így lesz kiszámítható a szállítás cikk.

4) Értékelés és pontozás (1–2 nap)

A pontozás nem a lényeg, hanem az összehasonlíthatóság és a fókusz. Példa egy egyszerű, érthető skálára dimenziónként:

5) Akcióterv és roadmap (0,5–1 nap)

A jó felmérés végterméke nem egy 40 oldalas PDF, hanem egy döntéstámogató csomag:

• 3–5 fő probléma és üzleti hatás (kockázat, költség, átfutás)

• javasolt beavatkozások (effort vs impact)

• 30–60–90 napos terv, tulajdonosokkal

• mérőszámok (DORA + helyi KPI-k)

Milyen kérdésekből áll össze a felmérés? (rövid minta)

Nem kell 200 kérdés. 25–40 jól célzott kérdés sokszor elég. Példák, amelyek gyorsan felszínre hozzák a valós érettséget:

• Mennyi a lead time a „merge”-től az élesig, és hol áll legtöbbet?

• Egy deploy átlagosan mennyi ideig tart, és mi a leggyakoribb hiba oka?

• Van-e standard rollback, feature flag, vagy minden incident „egyedi műtét”?

• A pipeline-ban hol van manuális lépés, és miért?

• Milyen gyakori a flaky teszt, és mi a policy rá?

• Van-e egységes log/metric/trace stratégia, és SLO jellegű célok?

• Hogyan kezelitek a secrets-t, és van-e auditálható hozzáférés?

• Ki a tulajdonosa egy szolgáltatásnak az éles életciklusában?

Tipikus „piros zászlók” DevOps érettségben

Ezek nem ritkák, és jó hír, hogy általában kezelhetők.

• Tooling-first gondolkodás: „vegyünk még egy rendszert”, miközben a flow és ownership homályos.

• Kézi release menetrend: fix éjszakai deployok, sok résztvevő, magas stressz.

• Nincs egységes definíció arra, hogy mi a „kész” (DoD), mi számít release-nek.

• Observability hiány: log van, de nem kereshető; riasztás van, de nem releváns.

• Security utólag: a pipeline végén derül ki, hogy a dependency sérülékeny.

Mitől lesz gyors a javulás? A 30–60–90 napos fókusz

A DevOps érettség javítása sokszor nem nagy átszervezés, hanem néhány jó beavatkozás kombinációja. Tipikus, jól skálázódó fókuszok:

0–30 nap: stabil alapok és mérhetőség

• DORA baseline mérés (akár közelítő, de konzisztens módon)

• standard branch/PR policy, minimális quality gate-ek

• pipeline stabilizálás (gyakori hibák és lassulások kiütése)

• incident review keret (blameless postmortem alapok)

31–60 nap: automatizáció és kockázatcsökkentés

• tesztstratégia rendbetétele (flaky teszt vadászat, gyors integrációs tesztek)

• release kockázatcsökkentés (feature flag, canary, blue-green ahol értelmes)

• IaC baseline (környezet drift csökkentése)

61–90 nap: skálázás és működési modell

• szolgáltatás ownership és on-call rend (értelmes rotáció, runbook)

• alerting racionalizálás (zaj csökkentés, actionability)

• DevSecOps kontrollok beépítése kockázatalapon (secrets, SCA, SBOM, aláírás)

Hogyan tud ebben segíteni a Syneo?

A Syneo fókusza az, hogy üzletileg értelmezhető, mérhető és auditálható módon támogassa a digitalizációs és IT projektek megvalósítását. DevOps érettségfelmérésnél ez jellemzően azt jelenti, hogy a felmérés nem „elméleti diagnózis”, hanem:

• közös baseline a csapattal (mérés + interjú + artefaktumok),

• priorizált javítási backlog és 30–90 napos terv,

• és igény szerint megvalósítás-támogatás (CI/CD, IaC, observability, DevSecOps irányokban).

Ha most szeretnéd gyorsan felmérni, hol tartotok, érdemes a kiindulópontot és a célokat röviden összeszedni, majd ezek alapján egy fókuszált felmérést indítani a legkritikusabb értékáramon.