Cik maksā Tavs mākonis? Zeiss integrē DORA metrikas un FinOps!

Ievads sarežģītajā mākoņpasaulē

Mūsdienu tehnoloģiju pasaulē uzņēmumi arvien vairāk paļaujas uz mākoņpakalpojumiem, taču ar to nāk liels datu apjoms - telemetrija, žurnāli, metrikas un, protams, izmaksu dati. Kā orientēties šajā informācijas jūrā? Uzņēmums Zeiss, kas pazīstams ar savām optiskajām inovācijām, ir atradis veidu, kā savienot programmatūras izstrādes veiktspējas mērījumus (DORA metrikas) ar finanšu pārvaldību (FinOps), izmantojot metadatus un automatizētus rīkus. Tas palīdz nodrošināt, ka katrs eiro, kas iztērēts mākonī, tiek izsekots un saprasts.

Problēma ir tā, ka bez skaidras datu piesaistes konkrētām komandām, sistēmām, vidēm un izmaksu centriem ir gandrīz neiespējami iegūt uzticamus DORA metrikas datus vai veikt precīzas FinOps analīzes. Alexander Troppmann, Zeiss mākoņarhitekts, konferences “Mastering GitOps 2026” ietvaros uzsvēra, ka metadatu saskaņotība ir būtiska, lai izvairītos no “datu drifta” un nodrošinātu precīzu pārskatu.

Backstage kā Patiesības Avots

Zeiss izmanto Backstage kā “vienoto patiesības avotu” (Single Source of Truth) visu atribūtu pārvaldībai. Šeit tiek uzturēti tādi svarīgi datu elementi kā īpašnieks/komanda, sistēma, domēns, komponenti, vide (DEV, STG, PRD), izmaksu lietotājs un izmaksu centrs. Nākotnē plānots pievienot arī SRE (Site Reliability Engineering) īpašniekus, kritiskuma rādītājus un mērogošanas profilus. Šo metadatu precīza uzturēšana Backstage ir izšķiroša, jo tā ir visa procesa sirds.

Daži atribūti ir svarīgāki DORA metriku, piemēram, komanda, komponents un vide, lai varētu salīdzināt komandas un atšķirt ražošanas un testēšanas kļūdas. Savukārt izmaksu lietotājs, izmaksu centrs un klients ir kritiski FinOps vajadzībām, veidojot pamatu iekšējai norēķinu sistēmai, budžeta plānošanai un izmaksu grupēšanai.

GitOps un automatizācijas spēks

Lai savienotu Backstage datus ar Kubernetes un Argo CD, Zeiss izstrādājis unikālus rīkus:

• Argo CD Annotator: Šis Kubernetes CronJob klonē GitOps repozitorijus, identificē Argo CD Application manifestus, iegūst metadatus no Backstage un ieraksta tos atpakaļ kā anotācijas. Tas notiek, izmantojot Kustomize Components un JSON-Patches, kas nodrošina, ka esošie YAML faili netiek tieši mainīti, tādējādi saglabājot GitOps konfigurācijas tīrību.
• DORA Metrics Collector for Argo CD: Go mikropakalpojums, kas darbojas mākoņvidē. Tas novēro Argo CD Application CRD (Custom Resource Definitions) un deterministiski klasificē izvietojumus (deployments), kļūdas un atjaunošanas procesus. Pēc tam tas eksportē Prometheus metrikas un nodrošina REST pārskatus Backstage, Grafana un vadības paneļiem. Šis rīks ir plašs, ar aptuveni 15 000 ražošanas koda rindu un vairāk nekā 600 testa funkcijām, nodrošinot pilnīgu determinismu bez atkarībām no AI izpildlaikā.

DORA metriku precizitāte

Zeiss ir ļoti stingras definīcijas, kas nodrošina DORA metriku uzticamību:

• Veiksmīgs izvietojums: Izvietojums tiek uzskatīts par veiksmīgu tikai tad, ja jauna revīzija vienlaicīgi sasniedz stāvokļus “succeeded”, “synced” un “healthy”. Tas ir daudz uzticamāks par vienkāršu “synced” statusu, kas varētu slēpt kļūdas, kurās lietojumprogramma vēl nav “vesela”.
• Kļūda: Kļūda tiek apstiprināta tikai tad, ja lietojumprogramma saglabājas kļūdas stāvoklī (“degraded”, “unknown”) vismaz 60 sekundes. Tas ignorē īslaicīgas problēmas, kas pašas atrisinās, nodrošinot, ka Change Failure Rate mēra tikai būtiskus traucējumus.
• Vidējais atjaunošanas laiks (MTTR): Mēra laiku no apstiprinātas kļūdas līdz atgriešanās “veselīgā” stāvoklī. To analizē kā histogrammu ar percenilēm (p50, p75, p95), lai precīzāk noteiktu problēmas, nevis vienkāršu vidējo rādītāju.
• Izmaiņu sagatavošanas laiks (Lead Time for Changes): Saista izvietojumu ar avota izmaiņām. Tam nepieciešamas labi definētas CI atzīmju konvencijas un uzturēti Backstage dati.

FinOps un izmaksu pārredzamība

Tās pašas metadatu dimensijas (klients, īpašnieks, komanda, sistēma un izmaksu centrs), ko Zeiss izmanto DORA vajadzībām, tiek izmantotas arī FinOps analīzē. Kubernetes nosaukumvietas (namespaces) tiek anotētas, lai Azure izmaksas varētu analizēt klientu līmenī. GitOps nodrošina, ka šī informācija deterministiski un versijveidīgi tiek izplatīta no Backstage uz repozitorijiem, Argo CD, nosaukumvietām un galu galā uz mākoņa izmaksu pārskatiem. Tas samazina risku, ka datu neatbilstība var padarīt skaitļus neprecīzus. Tiek ierobežotas arī ārpusjoslas izmaiņas tieši klasterī, un Argo CD tās atpazīst un labo.

Interesanti, ka Zeiss izmanto AI rīkus, piemēram, Claude Code un GitHub Copilot, lai paātrinātu specifikāciju izstrādi, refaktorēšanu un kodēšanu, taču izpildlaiks paliek brīvs no AI atkarībām. Uzņēmums stingri ievēro specifikācijās balstītu attīstību ar obligātu koda pārskatīšanu un dokumentētiem arhitektūras lēmumiem, kas saskan ar ES AI akta prasībām.

Nobeigums un galvenās mācības

Alexander Troppmann secina, ka datu kvalitāte ir vadības uzdevums. Bez skaidrām atbildībām par Backstage ierakstiem visa analīzes sistēma zaudē savu jēgu, jo paši rīki vien nav pietiekami. Turklāt, tā kā YAML komentāru direktīvas ir trauslas, Zeiss dod priekšroku Kustomize un JSON-Patch. Automatizētām GitOps cauruļvadiem nepieciešamas spēcīgas, bet stingri ierobežotas piekļuves tiesības. Gala secinājums ir skaidrs: lai DORA un FinOps būtu efektīvi, ir ne tikai jāmēra, bet vispirms jāzina, kam kas pieder. GitOps nodrošina stāvokli, Backstage - kontekstu, un tikai šie divi kopā nodrošina uzticamu pārredzamību.

Kā Tu domā, vai šāda pieeja varētu palīdzēt arī Tava uzņēmuma mākoņa izmaksu un veiktspējas pārvaldībā?