Molnnativ bankverksamhet befinner sig 2026 i DORA:s revisionsfas. Förordning (EU) 2022/2554 ⧉ har varit i kraft sedan 17 januari 2025. Utpekanderegimen för kritiska tredjepartsleverantörer (CTPP) enligt artiklarna 28-44 har öppnats under 2025-2026, med AWS, Microsoft (Azure), Google (GCP) och Salesforce inom eller nära utpekandeperimetern. De europeiska tillsynsmyndigheterna (EBA, EIOPA, ESMA) publicerade de slutliga RTS och ITS om informationsregistret ⧉ under 2024. ECB Banking Supervision har uttryckliga program för molnstörningsberedskap och hotledd penetrationstestning i tillsynsprioriteringarna 2026-28 ⧉. Den institutionella frågan är inte om molnstrategin ska anpassas till DORA — det är avgjort — utan om institutionens plattformstekniska primitiver producerar bevis i distributionspipelinens tempo snarare än i PDF:er sammanställda veckan före revisionen.
Sammanfattning för ledningen / viktigaste slutsatser
- DORA-molnresiliensen i aktiv tillämpning sedan 17 januari 2025. Artiklarna 6, 8, 18, 26 och 28-44 alla i kraft. Tillsynsfynd från den första revisionsvågen landade Q4 2025. Inramningen "förberedelse" är två cykler för sent.
- CTPP-utpekanderegimen öppnas. AWS, Microsoft, Google, Salesforce — inom eller nära. Utpekande ger ESA:erna direkta tillsynsrättigheter inklusive informationsförfrågningar, inspektioner på plats och tillsynsrekommendationer.
- Plattformsteknik är leveransen. Paved roads på Kubernetes (EKS / AKS / GKE / OpenShift), Backstage-liknande utvecklarportal, GitOps (ArgoCD eller Flux), Open Policy Agent vid admission, OpenTelemetry end-to-end. Fem namngivna primitiver; allt som saknas är ett fynd.
- Suverän moln är teknik, inte varumärke. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud — var och en adresserar en specifik dimension av Schrems II + DORA artikel 28; ingen är ett nyckelfärdigt svar.
- Testat exit-bevis krävs. EBA/GL/2019/02 paragraf 81 och 113-117. Kvartalsvis tabletop är otillräckligt; tillsynsmyndigheter förväntar sig årlig end-to-end exit-genomförandetestning för varje kritisk eller viktig funktion.
- RTO / RPO från CIF-inventering. Tier 1: 2 h / 15 min. Tier 2: 4 h / 1 h. Tier 3: 24 h / 4 h. Härledd från konsekvensanalys (BIA), inte från plattformsteamets kapacitet.
Varför DORA-molnresiliensen befinner sig i revisionsfas #
Tre skäl till att inramningen "förberedelse" är fel 2026.
Först, tidslinjen. DORA publicerades i december 2022. Den 24 månader långa tillämpningsperioden stängdes 17 januari 2025. ESA:ernas slutliga RTS och ITS — inklusive ITS om informationsregistret som används för CTPP-utpekande — publicerades under 2024. Den första vågen av tillsynsrevisioner pågick under 2025; fynd om fullständighet i ramverket för IKT-riskhantering enligt artikel 6 och avstämning av registret enligt artikel 8 landade Q4 2025 hos flera tier-1-institutioner.
För det andra, CTPP-utpekanderegimen. Artikel 31 fastställer kriterierna för utpekande som kritisk tredjepartsleverantör: systemisk påverkan vid fel, kritikalitet i de tjänster som tillhandahålls, skala och komplexitet i tjänsterna, substituerbarhet. ESA:erna upprätthåller registret och publicerar utpekandebeslut. AWS, Microsoft (Azure), Google (GCP) och Salesforce ligger inom eller nära utpekandeperimetern, beroende på marknadsandel inom finansiella tjänster per medlemsstat. Utpekande ger den ledande tillsynsmyndigheten (en av ESA:erna, fördelad per leverantör) direkt tillsynsbefogenhet: informationsförfrågningar enligt artikel 37, inspektioner på plats enligt artikel 38, rekommendationer enligt artikel 35 och regimen för offentlig redovisning enligt artikel 41. Bankerna som tillsyns över dessa CTPP:er omfattas av motsvarande tillsynsförväntningar på hur de hanterar det utpekade beroendet.
För det tredje, ECB:s tillsynsprioriteringar 2026-28. Prioriteringsdokumentet namnger två uttryckliga program som direkt påverkar molnnativ bankverksamhet: beredskap för större molntjänststörningar (modellerade tillsynsscenarier testar institutionens förmåga att absorbera ett ihållande avbrott hos en utpekad CTPP) och TIBER-EU-anpassad TLPT (varje TIBER-EU-övning omfattar institutionens kritiska och viktiga funktioner, vilket nu inkluderar tjänster i publika molnet). Revisionsvågen 2026 kommer att producera fynd inom båda.
Inramningen för 2026 är inte "DORA kommer"; det är "DORA-revisionsfynd anländer till din institutions brevlåda, och de plattformsteknikbeslut ni fattade under 2024-2025 är vad tillsynsmyndigheten granskar i dessa fynd."
Indexarkitekturen för 2026 #
| Indexlager | Vad "redo" ser ut som | Mognadsmått | Felläge |
|---|---|---|---|
| Plattformsmognad | >80 % av arbetsbelastningarna på en paved-road Kubernetes-plattform (EKS / AKS / GKE / OpenShift) med policy-as-code admission, GitOps-distribution, automatiserad DR-testning | % av CIF:er på paved-road-plattform; antal skuggdistributioner; medeltid för att introducera en ny tjänst på plattformen | Skuggplattformar med inkonsekventa kontroller; CIF:er som körs på opaverad infrastruktur osynliga för avstämningen av registret enligt artikel 8 |
| Integritet i registret enligt artikel 8 | Informationsregistret stäms automatiskt av mot plattformens tredjeparts-API-konsumtion + cloud-bill-of-materials; kritikalitetsklassificering konsekvent med institutionens CIF-inventering | % registerposter avstämda mot plattformstelemetri; antal föräldralösa poster; integritetskontroll av CTPP-perimetern | ESA:erna identifierar ett utpekat CTPP-beroende som institutionen underlåtit att redovisa enligt artikel 8; individuellt fynd och konsekvens för CTPP-perimetern |
| Molnkoncentration | Kritiska funktioner kartlagda till molnleverantörer OCH delregioner OCH tjänster OCH substituerbarhetsbedömning; korrelerad exponering över CIF:er kvantifierad | Koncentrationspoäng per CIF; korrelerad exponering över CIF:er som delar utpekad CTPP-region | Ett enda AWS us-east-1 IAM-avbrott slår ut fyra CIF:er som institutionen trodde var oberoende försörjda |
| Testad exit-förmåga | Årligt end-to-end exit-genomförandetest för varje CIF som är beroende av en utpekad CTPP; dokumenterad RTO / RPO uppfyller BIA-härledda mål; dataportabilitetsväg testad | Andel godkända test per CIF; medeltid för exit-genomförande mot RTO-mål; latens i dataportabilitetsvägen | Exit-plan som finns enbart som PDF; tabletop säger 4 h RTO, faktiskt test visar 48 h vid första försöket |
| Observerbarhet + incidentrapportering | OpenTelemetry-spår end-to-end över tjänster; automatiserad hjälp för 4-timmarsklassificering enligt artikel 18 kopplad till incidenthanteringsplattformen | % CIF-trafik täckt av OTel-spår; medeltid från incidentdetektion till klassificeringsbeslut enligt artikel 18 | Stor incident klassificerad utanför 4-timmarsfönstret eftersom kritikalitetsbedömningen krävde ett triagemöte; fynd enligt artikel 18 |
| TLPT-integration | TLPT-omfattning härledd från CIF-inventeringen och löpande uppdaterad; fynd matas tillbaka till plattformens policy-as-code; stängda fynd producerar tillsynsklara bevispaket | TLPT-fyndens stängningstakt; cykeltid från fynd till policyuppdatering | TLPT upptäcker en sårbarhet som institutionens plattformsteknikteam inte kan åtgärda på mindre än två release-cykler |
Aktuella signaler att följa #
| Signal | Vad det betyder för banker | Källa |
|---|---|---|
| DORA i aktiv tillämpning sedan 17 jan 2025 | Tillsynsfynd från första vågen landade Q4 2025; andra vågens fynd väntas under H2 2026 | EUR-Lex ⧉ |
| CTPP-utpekande öppnas under 2025-2026 | AWS, Microsoft, Google, Salesforce inom eller nära perimetern; utpekande ger ESA:erna direkta tillsynsrättigheter | EBA ⧉ |
| ECB:s tillsynsprioriteringar 2026-28 namnger molnstörningar uttryckligen | Modellerade tillsynsscenarier testar förmågan att absorbera ihållande avbrott hos utpekad CTPP | ECB Banking Supervision ⧉ |
| TIBER-EU anpassad till DORA artikel 26 | TLPT-omfattning täcker kritiska / viktiga funktioner inklusive molntjänster | ECB TIBER-EU ⧉ |
| EBA:s outsourcing-riktlinjer (EBA/GL/2019/02) griper i DORA artikel 28 | Substantiell närvaro (¶64), substituerbarhetsbedömning (¶81), exit-strategi (¶113-117) — paragraferna tillsynsmyndigheter faktiskt testar | EBA ⧉ |
| EU:s certifieringsschema för molntjänster (EUCS) i utveckling | Framtida certifieringsschema för suverän moln under EU:s cybersäkerhetsakt; ENISA-publicerat utkast | ENISA EUCS ⧉ |
Plattformsteknik: de fem namngivna primitiverna #
Molnnativ mognad 2026 reduceras till fem tekniska primitiver som griper in i varandra och producerar tillsynsbevis i distributionspipelinens tempo. Att sakna någon av dem är ett fynd som väntar på att hända.
1. Paved roads baserade på Kubernetes #
Varje CIF körs på en hanterad Kubernetes-plattform — EKS, AKS, GKE eller OpenShift på en utpekad CTPP, eller ett leverantörshanterat alternativ. Plattformsteamet driver ett enda golden cluster-mönster med kontrollerad avvikelse: noder från en dokumenterad basbild; namespace-per-team-isolering; pod-security-standards-restricted-profil; nätverkspolicyer; service-mesh-injektion (Istio eller Linkerd) för autentisering och observerbarhet mellan tjänster. Nya tjänster ansluter till paved road genom ett mallat onboarding-flöde som producerar posten i registret enligt artikel 8 som en distributionsartefakt.
2. Backstage-liknande utvecklarportal #
En central utvecklarportal — Spotifys öppna Backstage ⧉ är referensimplementationen, med olika enterprise-alternativ — fungerar som system of record för vad som körs var. Katalogen listar varje tjänst, ägare, beroende, kritikalitetsklassificering, runbook och on-call-rotation. Portalen griper in i registret enligt artikel 8: varje katalogpost mappar till en registerpost; poster utan registerreferenser utlöser CI-fel; registerposter utan katalognärvaro utlöser tillsynsföregripande larm.
3. GitOps-distribution via ArgoCD eller Flux #
Produktionsdistribution körs genom en GitOps-controller — ArgoCD eller Flux är produktionsstandard 2026 — som stämmer av ett Git-versionshanterat deklarativt tillstånd mot det körande klustret. Manuell kubectl apply är inaktiverad; den enda vägen till produktion är en sammanslagen pull request. Git-repositoriet är revisionsloggen; tillsynsmyndigheter som frågar "visa mig konfigurationen av tjänst X på datum Y" får en Git-tagg, inte en skärmdump.
4. Open Policy Agent vid admission #
Open Policy Agent (OPA) sitter i klustrets admission-kedja och tillämpar plattformspolicy: efterlevnad av pod-security-profil, image-proveniens, resursgränser, närvaro av nätverkspolicy, replikering anpassad till kritikalitetsnivå, placering i delregion under begränsningar för suverän moln. Policyer är Git-versionerade och förändringshanterade vid sidan av tjänstekonfigurationer. Avvisade distributioner producerar granskningsbara motiveringar som matas in i bevispaketet för förändringshantering.
5. OpenTelemetry end-to-end #
Varje tjänst sänder ut OpenTelemetry-spår, mått och loggar. Plattformsteamet driver en centraliserad observerbarhetspipeline — typiskt Tempo eller Jaeger för spår, Prometheus för mått, Loki eller OpenSearch för loggar — som exponerar end-to-end CIF-hälsa, beroendekartläggning och indata för incidentklassificering. 4-timmarsfönstret för klassificering enligt artikel 18 börjar vid detektion; OTel-pipelinen kortar vägen från detektion till klassificering till en sökbar uppslagning, inte ett triagemöte.
Suverän moln som teknik, inte varumärke #
Suverän molnstrategi 2026 måste besvara fyra specifika frågor inom Schrems II + DORA + EBA-outsourcing:
- Var bearbetas och lagras data? Plats inom EU-medlemsstat; delregion för flöden med hög kritikalitet; skriftliga åtaganden om dataresidens.
- Vem har laglig tillgång till data? Drift med enbart lokalt anställda; förfrågningar om utländsk myndighetsåtkomst underkastade lokal domstolsprocess; testad respons på begäran om laglig åtkomst.
- Vad är substituerbarhetsprofilen? Substituerbarhetsbedömning enligt EBA/GL/2019/02 ¶81; testat exit-genomförande; alternativ leverantör identifierad och kontrakterad (eller dokumenterat varför det inte är genomförbart).
- Vad är modellen för teknisk suveränitet? Kundkontrollerade nycklar; kryptografisk separation; suveränt management-plane; granskningsbar leveranskedja.
Leverantörsalternativen för 2026 som adresserar dessa frågor:
- AWS European Sovereign Cloud (tillkännagiven 2023, GA förväntad H2 2026): fysisk region driven av EU-baserat AWS-dotterbolag; EU-baserad drift och support; kundkontrollerade nycklar via KMS-XKS-mönster. Avvaktar anpassning av avtalsinnehåll enligt DORA artikel 28 under 2026.
- Microsoft EU Data Boundary (GA 2024) + Bleu (Capgemini + Orange + Microsoft, endast Frankrike): Data Boundary håller EU-kundens data inom EU-regioner; Bleu är den SecNumCloud-anpassade franska suveräna molnen som kör Microsoft Azure-stacken under fransk operativ kontroll.
- Google Clouds suveräna partnerskap: Thales / S3NS i Frankrike (Bleu-motsvarighet); T-Systems i Tyskland.
- Oracle EU Sovereign Cloud (GA 2023): tvåregionsmönster (Frankfurt + Madrid) med EU-baserad drift; tydligt Schrems II-kompatibel.
- Gaia-X-anpassade leverantörer (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS): inhemska EU-leverantörer med Gaia-X-märkning; mindre skala och ekosystem än hyperscalers men ingen exponering mot Foreign Intelligence Surveillance Act.
Det strategiska beslutet är sällan binärt. Tier-1-banker driver typiskt en hyperscaler-med-Data-Boundary-konfiguration för huvuddelen av arbetsbelastningarna, ett suveränt molnalternativ för utpekade flöden med hög känslighet (t.ex. ärendehanteringssystem för penningtvätt / sanktioner som hanterar personuppgifter för EU-bosatta), och en beredskapssubstituerbarhetsväg som testas årligen enligt DORA artikel 28.
Testat exit-genomförande #
EBA/GL/2019/02 ⧉ paragraf 113-117 är bestämmelserna om exit-strategi. Texten är uttrycklig om vad som krävs: "Institutioner och betalningsinstitut bör säkerställa att de kan avsluta outsourcingarrangemang utan otillbörlig störning av sin affärsverksamhet… Exit-strategierna bör också dokumenteras och testas som en del av de regelbundna översynerna av outsourcingarrangemangen."
Tillsynsförväntningen 2026 är årlig end-to-end exit-genomförandetestning för varje CIF som är beroende av en utpekad CTPP. Tabletop-övningar och dokumentgranskningar är otillräckliga. Testet måste producera:
- Time-to-restore-mätning: faktisk förfluten tid från deklaration av exit till att arbetsbelastningen återställts hos den alternativa leverantören, mot det BIA-härledda RTO-målet.
- Dataportabilitetsbevis: testad dataexport från primärleverantören, validerad mot destinationsleverantörens importväg, med avstämningsbevis.
- Funktionell ekvivalens: testad arbetsbelastning som körs hos den alternativa leverantören med likvärdiga SLO:er.
- Kostnadsbevis: dokumenterad kostnad för exit-genomförande mot kostnadsantagandet för återställning i institutionens kontinuitetsplanering.
Det första försöket till end-to-end exit-testning för en CIF avslöjar typiskt ett 5-10× gap mellan dokumenterad RTO och faktisk RTO. Att stänga det gapet är tekniskt arbete som tar månader. Banker som upptäcker det under en tillsynsinspektion snarare än under sin egen årliga testcykel står inför en Q3-fyndcykel de hade kunnat undvika.
RTO- / RPO-mål från CIF-inventering #
Varje kritisk eller viktig funktion mappas till en nivåklassificering härledd från institutionens konsekvensanalys (BIA). Nivån styr de RTO- och RPO-mål som plattformsteknikteamet förbinder sig att leverera.
| Nivå | Exempel | RTO | RPO |
|---|---|---|---|
| Tier 1 (uppdragskritisk) | RTGS-konnektivitet (CHAPS / T2 / Fedwire), auktorisering av detaljhandelsbetalningar, kundautentisering för digitala kanaler | 2 timmar | 15 minuter |
| Tier 2 (kritisk) | Penningtvätts-/sanktionsscreening, bedrägeridetekteringsflöden, ATM-auktorisering, batchbetalningsbehandling | 4 timmar | 1 timme |
| Tier 3 (viktig) | Rapportering och regulatorisk inlämning, kundvända kunskapsbaser, interna samarbetsplattformar | 24 timmar | 4 timmar |
| Tier 4 (icke-kritisk) | Interna HR-system, marknadsföringsverktyg, icke-kundvänd rapportering | 72 timmar | 24 timmar |
Dessa siffror är illustrativa — institutionens BIA producerar sina egna. Plattformsteknikens leverans är en regressionstestad förmåga att uppfylla de BIA-härledda målen, bevisad genom automatiserad DR-testning per tjänst och validerad genom det årliga exit-genomförandetestet för CTPP-beroende CIF:er.
Vad detta betyder per banktyp #
Globalt systemviktiga banker #
Det svåra problemet är skala över affärsområden: tusentals tjänster, hundratals CIF:er, flera utpekade CTPP-exponeringar över produkter, jurisdiktioner och resiliensprofiler. Investeringen är den centrala plattformstekniska förmågan — paved roads på Kubernetes, Backstage-portal, GitOps, OPA, OTel — som producerar avstämningen av registret enligt artikel 8, CTPP-koncentrationskartan och CIF-för-CIF exit-genomförandeförmågan utan skräddarsydd konstruktion per affärsområde.
Universella och medelstora banker #
Plattformsteknikinvesteringen är motiverad på denna nivå men omfattningen är begränsad: välj de två eller tre CIF:er med högst kritikalitet, bygg paved-road-mönstret runt dem, acceptera att legacy-arvet fortsätter med befintliga kontroller på medellång sikt. Den tillsynsmässiga positioneringen är viktigare än plattformsbredden — att kunna styrka integriteten i registret enligt DORA artikel 8 och testat exit för de tre främsta CIF:erna täcker tillsynsmyndighetens primära bekymmer.
Regionala och mindre banker #
Leverantörsval framför internt bygge. Välj en bankplattformsleverantör vars Kubernetes-nativa arkitektur är dokumenterad, vars integration med registret enligt artikel 8 är inbyggd och vars åtaganden om avtalsinnehåll enligt DORA artikel 28 är tydliga. Den interna tekniska förmågan handlar om konfiguration, övervakning och incidentrespons — inte plattformskonstruktion.
Fintechs, betaltjänstleverantörer och SaaS-leverantörer som tjänar banker #
Produktfrågan för leverantörer som säljer till EU-banker 2026 är om plattformen producerar de registerposter enligt artikel 8 och det avtalsinnehåll enligt DORA artikel 28 som bankens compliance-funktion behöver. Leverantörer med strukturerade utdata vinner enterprise-affärer; leverantörer med PDF-mallar förlorar till konkurrenter med strukturerad JSON.
Slutsats #
DORA-molnresiliensen befinner sig i revisionsfas. Plattformsteknikbesluten från 2024-2025 är vad 2026 års tillsynscykel granskar. De institutioner som ser trovärdiga ut för ECB och EBA under 2026-2028 är de som kör paved roads på Kubernetes med Backstage-liknande portaler och GitOps-distribution under Open Policy Agent-admission med OpenTelemetry end-to-end — som producerar bevis för registret enligt artikel 8 som en distributionsartefakt och testat exit-genomförandebevis som en årlig cykel, inte ett svar på tillsynsförfrågan.
De institutioner som inte gjorde dessa investeringar kommer att upptäcka om deras andra linjens compliance-team kan absorbera den första rundan av tillsynsfynd innan den andra rundan anländer.
Mät plattformen som du mäter vilket operativt program som helst: paved-road-täckning, registeravstämningstakt, CTPP-koncentrationspoäng, testad exit-tid mot RTO-mål, medeltid för klassificering enligt artikel 18, TLPT-stängningstakt. Bevis i pipelinens tempo; dokumentationspaket endast när tillsynsmyndigheten ber om ett.
Vanliga frågor #
Befinner sig DORA-molnresiliensen fortfarande i förberedelsefas 2026?
Nej. DORA har varit i aktiv tillämpning sedan 17 januari 2025. CTPP-utpekanderegimen enligt artiklarna 28-44 öppnas under 2025-2026. ECB:s revisionsfynd om IKT-riskhantering enligt artikel 6 och integritet i registret enligt artikel 8 landade hos flera tier-1-institutioner Q4 2025. Tillsynsfrågan 2026 är institutionsspecifikt revisionsbevis, inte regulatorisk beredskap.
Vilka molnleverantörer utpekas som CTPP:er?
ESA:erna publicerar utpekandebeslut på sina webbplatser. Institutionerna inom eller nära perimetern 2026 inkluderar AWS, Microsoft (Azure), Google (GCP), Salesforce och ett mindre antal andra beroende på marknadsandel inom finansiella tjänster per medlemsstat. Banker som tillsyns över dessa leverantörer möter motsvarande tillsynsförväntningar på hur de hanterar det beroendet.
Eliminerar suverän moln behovet av avtalsinnehåll enligt DORA artikel 28?
Nej. Suverän moln adresserar Schrems II- och dataresidensdimensionen; avtalsinnehåll enligt DORA artikel 28 är en separat skyldighet som gäller oavsett var data ligger. Den suveräna molnleverantörens avtal måste fortfarande täcka datatillgänglighet, säkerhet, residens, granskningsrättigheter, exit-strategier och kontinuitet enligt artikel 28.
Vad är den tekniska leveransen som visar DORA-molnresiliens?
Fem plattformstekniska primitiver som griper i varandra: paved roads på Kubernetes (hanterat kluster med policykontrollerad avvikelse), Backstage-liknande utvecklarportal (katalog som stäms av mot registret enligt artikel 8), GitOps-distribution (ArgoCD eller Flux), Open Policy Agent vid admission, OpenTelemetry end-to-end. Bevis i pipelinens tempo snarare än vid revisionstillfället.
Hur ofta måste exit-genomförandet testas?
Årlig end-to-end exit-genomförandetestning per CIF som är beroende av en utpekad CTPP. Tabletop-övningar och dokumentgranskningar är otillräckliga. Testet måste producera time-to-restore, dataportabilitetsbevis, funktionell ekvivalens och kostnadsbevis — mätt mot de BIA-härledda RTO- och RPO-målen.
Referenser #
- Europeiska unionen, (2022). Förordning (EU) 2022/2554 — Digital Operational Resilience Act (DORA) ⧉.
- Europeiska bankmyndigheten, (2019). EBA/GL/2019/02 — Riktlinjer för outsourcingarrangemang ⧉.
- Europeiska bankmyndigheten, (2026). Digital Operational Resilience Act ⧉.
- Europeiska tillsynsmyndigheterna, (2024). Slutrapport om ITS för informationsregistret enligt DORA ⧉.
- ECB Banking Supervision, (2025). Tillsynsprioriteringar 2026-28 ⧉.
- Europeiska centralbanken, (2024). TIBER-EU-ramverket ⧉.
- ENISA, (2024). EU:s cybersäkerhetsschema för molntjänster (EUCS) ⧉.
- Spotify, (2020-2024). Backstage utvecklarportal ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
- Cloud Native Computing Foundation, (2019). OpenTelemetry ⧉.
Senast granskad .
Senast granskad .