June 2026 DevOps Meetup

Parla 1
**Titolo: La piattaforma sono le persone: SLA, DORA e fiducia in miliardi di richieste al mese**
Autore: Harry Bouras
Ruolo / LinkedIn: leader di AI & Cloud Engineering, in precedenza a capo dell'organizzazione API di un'azienda leader, estremamente globale e multiculturale. LinkedIn: https://www.linkedin.com/in/harry-bouras/

Estratto:
La maggior parte dei discorsi sulla "piattaforma" riguardano gli strumenti. Questo no. Dirigere l'organizzazione API di un'azienda leader, estremamente globale e multiculturale, interconnettendo decenni di sistemi legacy e servendo miliardi di richieste al mese e scalando sia Azure che Google Cloud, mi ha insegnato una lezione controcorrente nel modo più duro: a quel volume, le piattaforme non falliscono in termini di tecnologia e i costi del cloud non esplodono a causa di Terraform scadente. Falliscono, o hanno successo, su come l’organizzazione è impostata per possedere, fornire e far crescere l’attività. L’organigramma è la vera architettura.

Camminerò attraverso le leve che hanno effettivamente mosso l'ago, ciascuna ancorata a momenti reali da quella scala. In che modo gli SLA, intesi come chiarezza piuttosto che come punizione, modificano il comportamento degli ingegneri più di qualsiasi dashboard. Perché estendere la fiducia e il tempo a un team in anticipo: la cosa più scomoda che un leader può fare, è proprio ciò che aumenta la qualità costruttiva e riduce le rielaborazioni che non puoi permetterti su miliardi di richieste. Cosa è veramente cambiato quando abbiamo trascinato un'organizzazione a forma di cascata verso una consegna iterativa basata su Scrum, e perché si trattava di abbreviare i cicli di feedback, non di aggiungere cerimonie. E come le metriche DORA sono diventate la nostra risposta obiettiva a una domanda su cui ogni team discute: cosa rende effettivamente un Senior Software Engineer di successo e cosa un ingegnere DevOps?

Poi il nucleo umano, raccontato onestamente, cioè raccontato come commedia. Ciò che rende un buon manager in questo mondo, raccontato attraverso le cose di cui ero certo e su cui mi sbagliavo completamente. La battuta ricorrente è anche il vero punto: quasi ogni istinto che mi ha reso un buon ingegnere mi ha reso un manager mediocre finché non l'ho disimparato.

Infine, uno sguardo a ciò che stiamo per sbagliare tutti insieme: l'intelligenza artificiale sta costringendo DevOps a crescere in DevSecOps e i team che lo gestiranno bene saranno quelli che già hanno la proprietà, la fiducia e la cultura della crescita di cui parla veramente questo discorso.

Discorso 2
**Cultura post-mortem: trasformare i fallimenti in apprendimento, non in colpa**
Autore: Dani Yelovitch
La maggior parte dei team di ingegneri tratta gli incidenti come motivi di imbarazzo da seppellire: una soluzione rapida, un messaggio vago su Slack e tutti vanno avanti. Questo discorso sostiene un approccio diverso: trattare ogni fallimento come un dono.
L'idea centrale è l'autopsia irreprensibile, una pratica sperimentata da Google e Netflix in cui l'obiettivo non è trovare un capro espiatorio, ma capire in primo luogo come il sistema (persone, strumenti, processi) ha permesso che si verificasse un fallimento. Se un essere umano ha commesso un errore, la vera domanda è: perché il sistema ha reso quell’errore facile da commettere?
Il discorso riguarderebbe:
Come si presenta una buona autopsia (e i modi comuni in cui va storta)
Come eseguire una revisione irreprensibile senza che diventi una sessione di colpa da parte del comitato
Trasformare gli elementi di azione in un cambiamento reale, non in un documento sul cimitero che nessuno legge
Costruire sicurezza psicologica in modo che gli ingegneri segnalino tempestivamente i problemi invece di nasconderli
Il punto fondamentale è che i team che imparano dai fallimenti più velocemente dei loro concorrenti forniscono software migliore con meno incidenti catastrofici, non perché hanno ingegneri migliori, ma perché hanno creato circuiti di feedback migliori.

**Discussione 3:**
Titolo: Dall'organizzazione dei servizi al self-service: ingegneria della piattaforma in azione
Di Pavel Bureš di Sky

Le moderne organizzazioni ingegneristiche accumulano silos di piattaforme più velocemente di quanto riescano a ripagarli: ogni team sceglie il proprio modo di fornire carichi di lavoro, database, code e cache, ciascuno con profili di sicurezza, osservabilità e costi leggermente diversi. In questo discorso condividiamo il modo in cui stiamo affrontando questo problema su larga scala attraverso una pratica di Platform Engineering costruita sul principio di un'interfaccia unificata e astratta per una configurazione incentrata sull'applicazione, un approccio che sposta i team della piattaforma da un "impianto idraulico basato sui biglietti" a una mentalità di prodotto: contratti stabili, percorsi d'oro e self-service per impostazione predefinita.

Nella seconda metà ci concentreremo su PEaaS (Persistence Engineering as a Service), la nostra implementazione concreta di questi principi per carichi di lavoro con stato. Esamineremo l'architettura (funzioni di composizione Crossplane 2.0 su EKS, attestazioni Kubernetes (XR) incentrate sull'applicazione e un modello di onboarding del tenant che automatizza IAM, endpoint VPC, provisioning OIDC e S3 - e come astrae backend eterogenei (Keyspaces, Aurora DSQL, Redis Cloud e Kafka su EKS) dietro un'unica interfaccia coerente.

I partecipanti partiranno con: Un modello pratico per progettare piattaforme di ingegneria nelle proprie organizzazioni.
Un'architettura di riferimento per la persistenza come servizio su Crossplane.
Lezioni oneste su standardizzazione, onboarding dei tenant e adozione della piattaforma.