Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Come ogni settimana cerchiamo di essere qua a tenervi in compagnia nonostante le energie siano sempre al minimo, quella flebile aura di energia ormai sta terminando e non so come andremo a finire.Con me ho il mio amico Luca, ciao Luca com'è da quelle Ciao a tutti, un tempo uggioso.Il tempo un po' influenza lo stato d'animo, ma non ci lasciamo sconfiggere, quindi siamo qua per darci la carica.Tu vuoi insinuare che noi nerdozzi della situazione siamo forse meteoropatici? Nooo, ma che? Il clima non influenza il nostro mood, il nostro mood è sempre negativo, sempre e comunque.insomma non c'è non c'è gran che oggi ho portato un caro amico che adesso vi presento e proviamo a parlare di un topic un po' un pochino particolare ma lo facciamo subito dopo avervi...ah ah ah iniziamo bene......dato i nostri contatti info@gitbar.it su X che ormai in realtà non usiamo più quindi no "Infocasioalagitbar" era la mail, si era la mail ok "Infocasioalagitbar.it" via email @brenrepo su twitter che ormai diciamo è moribondo non ci entro praticamente mai ma abbiamo un posto super frequentato dove siamo sempre là.Abbiamo sempre il posto più frizzante che il gruppo Telegram basta cercare Gitbar Podcast c'è il nostro logo, entrate per favore salutate dite ciao buongiorno perché così noi ci...così non vi banniamo...così non vi banniamo di default perché ogni tanto arriva qualcuno che propone lavori online da remoto che io dico ma cioè scusami ma sai in che gruppo stai? Non so entra e parliamo di Rall...Vuoi lavorare su internet.Vuoi lavorare su internet? Non so vogliamo offrire i recorsi di Anna.Però è frizzantino entrate salutatevi la prima birra in omaggio virtuale, si spera anche vera, un giorno e siamo siamo un po' calati mi sembra 150.Ma credo che insomma quello ormai è il il nostro range stabile, siamo la famosa famiglia e i genitori sono abbastanza grandi e adulti da non fare altri figli, quindi più o meno abbiamo raggiunto la nostra massa critica e siamo felici di questo in realtà.Facevo proprio una riflessione l'altro giorno parlando con la mia amica Michela, cioè la smania del crescere come community a tutti i costi, dall'espandersi all'uomo.Allora dai, dai.No, no, no, no.Aspetta, aspetta, l'ospite sta parlando e in realtà è mutato.Non so se posso menzionarla qui però tu sai da community arrivo io fondamentalmente su Facebook.Sì sì sì ma tutti possono essere menzionati, tutte le community, c'è posto per tutti su git barra? No perché parlando proprio di mania di crescere mi ha ricordato i tempi di web developer italiani, uno credo dei gruppi probabilmente più citofonati visti su Facebook.Ma eravate giganti! Siamo giganti, più di 15.000 membri abbiamo e tra l'altro sono tutti selezionati, non c'è stato come dire quello che entrava, joinava libero e tanti saluti, sono tutti quanti che hanno passato il filtro del sei umano, sei vero, sei un bravo sviluppatore, comunque sei uno sviluppatore e allora puoi passare.Quindi è stata una crescita organica, devo essere sincero, non abbiamo avuto il boom in un anno o in due, è stato un lavoro di più di 10 o più anni credo.Insomma, sono d'accordo con te, non c'è bisogno della smania di crescere una community per forza di cose.Se deve crescere o se vuole crescere è perché la community vuole crescere.Sì anche perché quando non ci sono grossi interessi o questo tipo, poi alla fine non hai neanche bisogno di alimentarla forzatamente la community, quindi è un circolo, se vuoi entrare entri, il primo giorno che entri ti si fa la tessera e poi bevi esentasse per quanto vuoi, più o meno l'approccio.Ma poi soprattutto ogni posto ha una sua capienza massima, insomma, altrimenti diventa un...soprattutto nelle chat real time, come nel nostro caso Telegram, insomma, se arriviamo a un milione e tutti parlano...Già, 1.500 è un bel numero ragazzi, cioè in tanti miei complimenti, perché comunque 1.500 membri in un gruppo solo, tanta roba da gestire.Infatti talvolta è abbastanza rumoroso.Però visto che ci siamo già presentati, devo dare il benvenuto al mio amico e collega Julian.Lui è il salvatore, mi è stato salvatore in un sacco di occasioni, è tipo quel buon samaritano che arriva e ti lancia il salvagente quando stai affogando nella merda.e quindi siccome più di una volta abbiamo avuto occasione di parlare di topic interessanti in chat o nelle nostre call giornaliere, ho detto "no, guarda Julian, dobbiamo trovare il modo per dedicarci uno spaziato qua nel Gitbar perché secondo me ha senso fare una chiacchierata e portarla qua nel podcast".Quindi grazie per essere venuto a trovarci.Grazie a voi per avermi invitato Oggi il topic è SRE, ok, è detto da un ex sviluppatore tutto un dire, perché comunque diciamolo, non nascondiamoci dietro un dito, arrivo dal mondo dello sviluppo ok, però oggi parleremo di SRE.Sì ma non è una vergogna amico mio, no però uno poi si aspetta che arrivo, cioè quando parli di SRE dice questo arriva dal mondo devops, non capisce una rava e una fava di sviluppo, parlerà delle sue fantasie, però no, si parla di SRE con cognizione di causa, arrivo dal mondo dello sviluppo anche io.Secondo te ecco e intanto alcuni di noi già conoscono il significato e il ruolo e l'obiettivo di essere...per chi non lo conosce se possiamo provare a fare una piccola diapositiva perché io se cerchiamo su internet ognuno c'è la sua definizione di cosa voglia dire SRI.Ovviamente.E nessuna matcha con l'altra al 100%.Quindi dalla tua prospettiva cosa metti nel calderone SRI? Guarda è una bellissima domanda perché ovviamente tutti quanti quando chiedi SRI vanno tutti con la frase classica che è da Google, il famoso site reliability engineering e soprattutto è una pratica che è nata in Google quindi diciamo che Google è stata la prima azienda che ha coniato il termine perché ha coniato anche il ruolo, quindi nessun ingegnere prima era SRI, anzi non si sapeva neanche che cosa fosse.Qual è stata la differenza, da dove arriva il mondo SRI, almeno dal mio punto di vista? Soprattutto da uno che li ha visti un po' tutte, ha visto lo sviluppo, ha visto la parte DevOps e ora sono nel mondo SRI.Per me l'SRI è quell'ingegnere che si occupa della messa post produzione e nella gestione della stabilità del prodotto una volta che è andata in produzione, il che mi costa molto a dirlo in italiano perché non sono abituato neanche più a parlare in informatica in italiano, però spero di averlo azzeccato bene in italiano.L'idea è proprio quella, gestire tutto il ciclo di vita del software una volta che va in produzione.L'SRI è la figura che si occupa non solo di stabilire, di fare che il software funzioni, ma anche capire in che modo sta funzionando, con delle metriche e con delle informazioni aggiuntive che vanno intorno al servizio, capire se il servizio sta performando bene o male e indirettamente aiutare gli sviluppatori dando informazioni indietro tramite tool, insomma tramite strumenti particolari che possano poi dare feedback interessanti allo sviluppatore e dire "eh guarda, ho notato che il tuo prodotto è in produzione sotto questo tipo di carico, per esempio un milione di utenti che cliccano tutti lo stesso URL o comunque lo stesso API, il suo sistema non performa come dovrebbe, magari sta usando 8 giga di RAM al posto di 4 come avevi preventivato o magari usa un sacco di CPU in certi momenti e andiamo a analizzare perché.Quindi questa è una pratica che arriva dall'SRI in verità, quindi la persona che osserva e aiuta a come gestire un prodotto post produzione, che diciamo è una causa che in verità tutti si aspettano faccia il DevOps, ma il DevOps in verità si occupa di automazione, del come portare il software in produzione, ma dopo l'ha messa in produzione chi ci guarda? Mi chiedo...ah vai Luca! No no, una domanda giusto perché la definizione è interessante, però mi ha dato una virgola di dubbio per come l'hai formulata.Vuol dire che cominci a lavorare, diciamo, dopo che il software va in produzione, o c'è un lavoro da fare prima? Ovviamente c'è un lavoro da fare prima, nel senso il, come dire, il lavoro effettivo, cioè il titolo SRE arriva da lì, però ovviamente come qualunque altro ruolo, il risultato ottimo inizia sempre dalla prefase della preproduzione in verità perché è quel momento in cui tu lavorando a stretto contatto con gli sviluppatori in effetti è la parte che ho detto anche prima, dai del feedback agli sviluppatori, porti delle informazioni che possono aiutare nel portare queste informazioni porti anche una specie di best practice, cioè le migliori pratiche che si possono fare per poter monitorare, osservare al meglio il software che può essere integrare una linea di codice in un determinato punto, cambiare magari delle informazioni nel header per lavorare meglio, questa è una parte magari che possiamo approfondire tra poco però si chiama tracing quindi approfondire come collegare le informazioni e correlarle insomma c'è tanto lavoro in verità qua dietro che insomma se cominci a delinearle tutte adesso credo che dopo la chiamata è definita qui però se vi lascio a voi insomma il piacere di scoprirlo poco a poco.Sì, l'esempio classico è avere Giuliano Incoli e ti dice "la tua cazzo di osservabili non funziona come dovrebbe, merda, non sta arrivando un cazzo su Line Attrace".Questo è un esempio non così colorito, sono io che l'ho migliorato.Io sono credo di essere un po' più paccato, Esatto, tu sei decisamente più pacato, però in sintesi questa è una delle declinazioni, poi ce ne sono milioni.Pensiamo a una cosa, io invecchiando, sto sviluppando una sorta di pragmatismo e una cosa che ho visto evolvere nel tempo è l'esplodere di ruoli diversi, deve avere un ruolo questo è giustificato in scale di una certa dimensione diventa un po' meno giustificato quando gli ambienti sono un po' più piccoli, i contesti sono un po' più piccoli.A me piace tantissimo quel famoso concetto che andava di moda qualche anno fa "you develop it, secondo te fino a che scala e con quale approccio questo modo di gestire il software, non entriamo nel mondo dei microservizi perché tanto ci arriviamo tra un po', però questo modo di gestire il software funziona qual è la scala per cui poi si rompe tutto? La domanda è nel senso quale ruolo può avere un determinato raggio d'azione in tutto questo statement qui che hai detto, cioè appunto "you build it, you run it, you ship it".Dal tuo punto di vista, nel senso, dal tuo punto di vista quanto questo processo può essere gestito da un singolo team/persona e quando poi hai bisogno di figure specializzate che ti fanno solo le serie, ti fanno solo il DevOps engineering e via discorrendo.Guarda questa in verità è una cosa che ho sperimentato personalmente mentre stavo lavorando in Ubisoft, non è lì a caso, ho lavorato per loro, io ero il DevOps dello studio, sono entrato come DevOps la dentro e avevano bisogno di qualcuno che gli gestisse la piattaforma, anzi gliela sviluppasse perché non avevano una piattaforma in verità, oltre a questo capire anche come gestire esattamente questa scalabilità, cioè come fare in modo che le diverse squadre che stavano lavorando ai diversi giochi avessero anche l'autonomia di poter fare quello che volevano fare con i loro servizi nella piattaforma.Ed è lì che poi ho iniziato anch'io a farmi questa stessa domanda che hai fatto tu, fino a che punto c'è bisogno di gente specializzata, fino a che punto possono abilitare altri? Io guardo e ti dico, per per esperienza ho visto che secondo me la costruzione di qualcosa, diciamo una piattaforma, un'infrastruttura, chiamala come vuoi, quella secondo me ha bisogno di figure specializzate, ma una volta che quell'infrastruttura, quella piattaforma c'è, secondo me puoi abilitare gente nella squadra a fare determinate cose che poi vengono chiamate in inglese "ownership", cioè il punto di dire "tu hai la...aiutatemi a tradurre ownership che mi manca adesso in italiano come lo potete tradurre.Io ho il tuo stesso problema.Scusami? Responsabilità.Responsabilità può andare può andare quindi hai la responsabilità di avere quella determinato contesto e dire ok da qui a qui è il mio territorio da qui a qui il mio territorio.Io ti dico nel famoso statement di Ushipi cioè tu lo costruisci tu lo fai andare e tu lo mandi in produzione secondo me determinate figure possono fare cose.L'SRI potrebbe essere per esempio una figura specializzata per quel determinato set di servizi perché nel mio caso erano squadre diverse che facevano giochi diversi non avevano ognuno gli stessi servizi o lo stesso codice c'era chi costruiva codice che un altro tipo di codice e si qui si parlava anche di codice che magari non è il generico web service che facciamo tutti i giorni si parlava anche di servizi di codice completamente codice server no del gioco server completamente fatto in unity per esempio o in in unreal o quello che poteva capitare e quindi questa roba la conosceva solo il team.Quindi l'SRI potrebbe osservare questo e c'è secondo me come si può fare.Il DevOps non è proprio il DevOps che conosciamo tutti, cioè non è quel DevOps che aiuta nel fare l'infrastruttura.E' più la persona che dice "ok, una volta che il team compila penso come posso ottimizzare i processi per mandarlo da qui a qui".Perché quella persona è quella che conosce meglio quel codice, anche più del DevOps stesso che sa mettere mano nell'infrastruttura sia ICD.Quindi secondo me c'è modo in verità di comportamentalizzare questa cosa, però richiede anche molta alta specializzazione, insomma non è un ruolo che secondo me nasce basso, secondo me lo diventi, lo diventi a colpi di cose viste, di esperienza, magari di passati vari, tipo se sei stato sviluppatore puoi capire il DevOps, se sei stato ingegnere di sistemi puoi capire l'SRI e così via.Sì, no la mia domanda era quanto la parte di mantenere il software in produzione può essere fatto dal team stesso che ha sviluppato il software e in quale scala questa cosa smette di funzionare perché se provo a fare un parallelismo nella vita reale, l'ingegnere e l'impresa costruiscono un building, uno stabile oppure ancora più semplice io ho un team che mi fa il bootstrap di un'azienda e poi stranamente dopo il terzo anno il CEO cambia perché ho bisogno di un CEO che magari non ha quel approccio da bootstrap, ho bisogno di uno che ha una visione nel mantenere le cose e far funzionare le cose in modo stabile perché il lavoro è completamente diverso.Però ecco, se nel business io vedo questa diversità e posso vedere dei momenti in cui lo stesso CEO può fare entrambe le cose, mi chiedo ecco fino a che punto questa cosa può essere fatta nel software? Cioè io ho il mio team di, partiamo dal piccolo, di cinque, sette sviluppatori mi fanno la mia applicazione, i miei servizi, me li mettono in produzione e si occupano anche di farmi le serie.Quanto avere un team che si occupa di questo può funzionare? In quale scala questo si rompe? Per esempio provando a ragionare a voce alta mi vorrebbe da dire quello skill set è costoso da tenere inglobato in ogni team di development.Assolutamente.No no tranquillo scusa adesso ho capito la domanda pensavo la domanda prima fosse riferita al se era possibile invece adesso proprio tu dici no no nel concreto fammi capire se il team lo può fare e in che scala le cose continuano a funzionare.Ti dico allora un SRE come tale cioè una figura di questo tipo non puoi avere in una squadra perché come hai detto tu costa troppo è proprio infattibile a livello di business non possono avere un SRE per squadra.Se poi ci sono due squadre in tutta l'azienda è capace anche che può esserci cioè dipende a che scala stiamo parlando internamente in un'azienda.Però se già mi parli di un centinaio di dipendenti, facciamo che il 60 dipendenti sono sviluppatori, ecco già lì non funzionerebbe perché mentre c'è anche una squadra di 5-6 persone, comunque sono 10 squadre, già il calcolo non funziona più.Però io credo che secondo me dati gli strumenti giusti alle squadre c'è possibilità di farlo.Quindi da 1 a 10 io dico che secondo me se la piattaforma è fatta bene e gli SRE che sono magari nella loro squadretta.Sono 3-4 però sono quelli che mettono su il tool, fanno in modo che le cose vengano osservate bene, le metriche arrivano, il feedback agli sviluppatori arriva.Io credo che secondo me lo statement può funzionare in una scala io direi anche un 7-8 perché se tu fai le cose bene gli sviluppatori hanno gli strumenti giusti per analizzare il loro territorio, che loro hanno il potere di andare nella pipeline e fare play e dire sì, metti in produzione.Hanno il potere di fare il rollback nel caso qualcosa va storto, hanno il potere di andare, adesso ne menziono uno a caso, non so se hai sponsor, tipo cose varie, però metti che vanno su Grafana e vanno lì per vedere le dashboard e lì allora loro possono dire ok nella dashboard ho le metriche, ho i trace, ho i log, ho tutto, posso analizzare la situazione completamente in autonomia e quindi lo statement "you build it, you run it, you ship it" funziona, ma se togli tutto questo ovviamente è già impossibile.Nel mio caso le squadre che avevano Ubisoft le potevano fare, loro erano completamente autonomi.Io avevo fatto l'infrastruttura, avevo fatto tutta la parte sia di observability che di DevOps per il pipeline e loro potevano deployare quando volevano e anzi ti dico deployavano alle due di notte quando io non lo sapevo.Quindi c'erano un sacco di volte che loro deployavano e avevano totale controllo del flow e io non lo sapevo.E quindi questa cosa in qualche modo riesce a scalare anche nel micro perché quello che quello che io mi mi chiedo sempre, dalla mia prospettiva oggi, lavorando come te in una grande enterprise dove siamo un gozzilione di persone che mettono mano alle cose, si ha una certa prospettiva, però parte dei nostri ascoltatori, essendo italiani, vengono dalle piccole e medie realtà, dove magari ci sono dieci sviluppatori in tutta l'azienda e avere un SRI dedicato probabilmente è semplicemente antieconomico.Esatto.Quanto fa la figura e quanto possono fare i principi? Cioè quanto possiamo fare in un contesto dove non ci possiamo permettere la figura, shift left e portare quei principles direttamente agli sviluppatori in modo che reliability by design? Guarda è una cosa che mi sono chiesto anche io perché dopo l'esperienza che ho fatto in Ubisoft prima di entrare adesso dove siamo insieme colleghi stavo proprio pensando e detto che secondo me una figura di questo tipo potrebbe essere una figura chiave che potresti farlo anche da freelancer secondo me in stile toccata e fuga perché? Perché una volta che tu stabilisci bene la giostra che è ben oliata con tutto quello che deve esserci e in più includi anche del training per le persone, per gli sviluppatori, del come usare questa giostra che sia a loro favore, io credo che una volta che gli sviluppatori prendano confidenza con lo strumento, capiscono come leggere le cose, capiscono come interpretarle, tu praticamente sei, non dico inutile, diciamo che se non si cambia il tool, non si cambia l'infrastruttura, non sei più utile in quell'azienda lì, perché le cose sono già oleate, basta.Siccome io sono parzialmente boomer e vengo da un'epoca dove di SRI non se ne è mai parlato, c'erano i famosi sistemisti, quelli che conoscevano i sistemi operativi e sapevano...sapevano i sistemi diciamo, erano solitamente quei mostri che stavano vicino alla sala server i capelli lunghi e la musica metal sulle cuffie.No scherzo, sto alimentando luoghi comuni.Io il mio primo lavoro sarebbe stato da system insta, te lo dico, conosco bene quel ruolo.No però dico, cos'è cambiato da allora a oggi in ambito esseri? Perché si è avuta la necessità di dare un nuovo nome.Quali sono gli elementi in termini di approccio che sono cambiati per giustificare questa formalizzazione di una struttura nuova? Guarda, io credo, allora, se facciamo un'evoluzione storica molto rapida del come siamo arrivati qui, partiamo dalla figura, almeno in Italia, del noto sistemista.Cosa faceva il sistemista? Si metteva lì e gestiva l'hardware in modo che funzionasse sempre, stesse sempre vivo, sempre online, a fare quello che doveva fare con gli aggiornamenti del sistema, in modo che tu non avessi problemi da quel punto di vista.Dicevo io se ci installo il mio software che farò qualunque cosa sia, PHP, sotto tempo cosa c'era non mi ricordo anche più, Visual Basic, Asp, Cold Fusion, bravo! Quindi Cold Fusion insomma ce n'era.Se tu installavi queste cose andavano.Poi cos'è successo? È successo che a un certo punto hanno detto secondo me questa gestione dei sistemi soprattutto e qui secondo me è stata la chiave disvolta con l'avvento del cloud dove il sistemista non era più la persona che si occupava anche di installare i software ma era semplicemente la figura che si occupava di tenere in piedi l'hardware quindi con l'avvento del cloud e con il fatto che le mani sull'hardware sono state date di nuovo in mano agli sviluppatori è nata la domanda e adesso come configuro tutto questo? nel senso non è che posso andare lì in ogni computer e fare l'aggiornamento e l'installazione cioè è una roba che è ingestibile e quindi da lì è nata la figura del DevOps la persona che con il codice configurava i sistemi.Quando tu metti in produzione qualcosa, tutti sospettavano che il DevOps fosse la persona che si occupava di questa roba qui.E quindi gli dici "ok, in una complessità che parleremo come detto tu tra poco di microservizi che continuavano a nascere a bomba, il DevOps dice "ma io mi devo occupare dell'infrastruttura o dei servizi che mi stai mettendo lì sopra?" Entrambe le cose sono un po' complesse da gestire, quindi hanno bisogno di due mentalità, che una è dedicata all'hardware e una è dedicata al software.Quindi come la facciamo, come la mettiamo? E io credo che da lì è nata proprio la figura in Google della persona che dice "Vabbè, allora uno si occuperà della gestione dell'infrastruttura, della scalabilità, della sua resistenza, degli attacchi informatici, tutto quello che riguarda quella pezza lì, e io invece mi occuperò di tutta la parte che riguarda i servizi".Quindi si astrae di nuovo, quindi si crea una linea rossa e si dice "ok da qui in giù ci guardi tu devops e da qui in su ci guardo io sri" stessa roba cioè stessa identica cosa che mettermi entrambi le mani ma la guardiamo da due fronti completamente diversi io da sopra tu da sotto piccolo escursus.Escursus storico.Per cui...troppa ciccia nel fuoco.Sì sì sì no sono andato in overflow perché ho un botto di domande e sto cercando di mettere ordine per provare a seguire un flusso logico e non fare dei collegamenti a Capriola però, it's too late, è stata una giornata lunga.Qual è allora secondo te l'evoluzione naturale delle serie? Per come l'hai raccontato sai l'idea che ne ho è che in fase di evoluzione naturale io ho il developers che poi si sviluppa si specializza in infrastruttura e mi diventa un DevOps engineer o comunque fa da testa di ponte in ambito di pratiche DevOps e mi viene da immaginare magari sto sbagliando SRE che invece viene più da un ambito sistemico e si specializza.Quanto questo è luogo comune? Perché tu mi hai appena detto che tu vieni dallo sviluppo software quindi hai fatto tipo un loop.Quanto invece questa categorizzazione, questa ladder virtuale è guidata da un luogo comune e quanto invece è naturale evoluzione? Allora, è partita la webcam.Molto bene, non so perché.Forse torniamo online? Ok, ci siamo.Allora, guarda, ti dico, il luogo comune in verità del sistemista, io l'ho già sentito, almeno in Italia, questa cosa, il più delle volte arrivava dal mondo dev, cioè il sistemista, quello che si occupava di hardware, di network, di cavi di rete, di schede di rete, tutte quelle robe lì, era poi la persona che in più delle volte uno pensava, o il più delle volte ho visto e ho sentito di gente che da sistemista e di nuovo esplose la camera, scusate ragazzi, io sto litigando con DroidCam quindi abbiate pazienza il più delle volte il sistemista è la persona che arrivava, diventava DevOps e quindi arrivava e diceva "beh ma io comunque le skill ce le ho" tu dicevi "sì, ma quelle d'automazione, cosa vuol dire scrivere una linea di terraforma o capire comunque le logiche di un linguaggio?" e tu vedi il più delle volte che queste persone no, perché non arrivavano neanche con la skill di Bash, erano proprio persone che si occupavano di fare solo installazione di sistemi, configurazioni IP e cose così.L'SRI secondo me non arriva dall'ambito sistemistico.Io credo che sia la super evoluzione, anzi il mix tra uno sviluppatore puro e un sistemista, fra virgolette.Perché? Perché l'SRI è la persona che vuole stabilità.È la persona che dice "io voglio comunque fare in modo che quella cosa che io sto guardando sia il più stabile possibile".In generale.quindi non è diciamo una figura solo di contorno cioè che sa mettere quelle tre informazioni dentro e poi tanti saluti e il più delle volte dall'SRI ci si aspetta anche che sia una persona che sappia analizzare cose, cioè informazioni quindi in verità nell'SRI c'è un po' di data engineering e un po' di developer e un po' di sistemistico perché? perché devi avere la capacità, il know-how di capire la stabilità.Cosa vuol dire essere stabili? Perché dai siamo sinceri da sviluppatori la stabilità non è una delle skill che uno richiede, perchè lo sviluppatore deve avere lo slancio di scrivere qualcosa di nuovo, fare qualcosa di nuovo, fare in modo che l'API funziona, questi cazzi se magari il database crolla ogni tre secondi, però intanto tu devi fare quello.Poi però chi si occupa di fare in modo che le cose funzionino? Esatto, oppure ci mettiamo un proxy, un reverse proxy, tanto chi se ne frega.Insomma, della parte sistemistica c'è la stabilità, del developer c'è la capacità di capire come funziona un prodotto, cioè come funziona quel software e la fine del data engineering è come usare i dati a tuo vantaggio per analizzare la situazione e portartela a casa dicendo ok posso migliorare un po' questo un po' quello quindi in verità l'SRI scom arriva da tre diversi angoli che è un po' interessante secondo me come punto di vista però ci si può anche parlare sopra quando quando tu hai detto la capacità di analizzare un software quindi essere parzialmente developer in quello cosa intendi per analizzare un software cioè scendere a livello code perché io quando penso a essere al lato developer la cosa che mi viene in mente è l'automazione forse no quindi deve essere in grado di poter lavorare sull'automazione però tu hai detto capace di andare a leggere il codice come si declina questa competenza la tuo codice Io mi aspetto che un SRI butti gli occhi sul codice e dica "Ehi, guarda, questo potrebbe non funzionare su un carico pesante o questo è delegato a qualche altra figura?" No, allora, la risoluzione del problema è ovviamente delegato a un'altra figura, cioè lo sviluppatore non va sostituito, quindi su questo io sono estremamente ferro.però quello che secondo me è importante con essere abbia è la conoscenza nel poter interpretare per esempio se io vado su grafana e vedo che il tuo servizio è costantemente al 50% di cpu qualcosa mi fa pensare che o hai un loop sbagliato per esempio o che magari determinate chiamate veramente sono super cariche quindi hanno magari fanno un treno di codice che probabilmente inutile però comunque dire avere il naso no di pensare del capire del cosa potrebbe essere andato storto poi ovviamente sono pointer cioè tu vai dal sviluppatore gli dice ascolta io ho notato che il tuo servizio è sempre al 50 per cento di cpu può essere che magari ci sono dei loop sbagliati delle chiamate sbagliate magari del codice in più che non deve essere eseguito magari è compilato in debug e non in release insomma ci sono tutte una serie di accorgimenti che potrebbero dare un hint allo sviluppatore e secondo me è lì che uno delle serie si deve fermare non deve assolutamente essere capace di commitare codice a meno che, e qui è l'unica cosa che l'SRI deve saper fare, a meno che si parli di automazione di infrastruttura e/o di codice inerente alla sua parte che di observability.Quindi per esempio, non so, mettere in mano a un open telemetry o piuttosto che, non lo so, framework vari di integrazione per capire come ottenere quella determinata informazione dal software.Nella quotidianità hai parlato di monitoraggio, observability, si è un po' come i vecchi sistemisti che si siedono sul server, ne abbiamo parlato prima, cioè nel senso ti siedi, arriva, ti bevi il caffè, ti siedi e cominci a osservare o sta cosa diciamo si ma anche no e si lascia agli alert automatici o chissà che cosa.Ci vuole un occhio periodico, ovviamente periodico sto parlando, ogni tanto, Dio grazie, si spera che qualcuno ci guardi in quei bei grafici di Grafana, però intendo dire che è proprio una cosa quotidiana o anche no.Allora, in teoria, come dici tu, uno dovrebbe potersi prendere il caffè, sedersi e andare ad analizzare come è la situazione in generale.Però bisogna essere anche onesti.Immagina di avere un parco di 100 servizi, dove tu ogni giorno ti vai a vedere i 100 servizi e come stanno performando.Chiaramente la cosa non scala.Potresti vederne forse 10 al giorno, 12 al giorno e per vederli non dico andare nella dashboard 5 secondi, poi la prossima dashboard 5 secondi.Dico andare nella dashboard ed analizzare la situazione.Metti che se veramente il super ingegnere ne riesce a analizzare dieci al giorno, comunque ci vogliono dieci giorni per analizzare cento servizi e ricominciare dal servizio uno dopo dieci giorni.E quando ne è mille? Scusami? E quando ne è mille? E vabbè, lì ci vogliono tre anni, sei ancora in backlog.Magari ci sanno anche più essere ingegneri.Non lo so, questa può essere una domanda, è possibile averne di più di uno per ogni team? Ovviamente, cioè nel senso che adesso si parla che non è che sei solo, si spera, non sei l'unico di un'azienda che ha mille micro servizi o servizi, insomma.Però l'idea è che comunque vederli tutti a mano comunque non è sempre una cosa che avviene realisticamente parlando.Tuttavia, però, hai menzionato una cosa veramente interessante che sono appunto gli alert.Cioè, tutta quella pratica del capire, no, che in base a determinati limiti ottenere degli input, no, dei nudge da parte del tool che stai usando e dicendoti "Ehi, guarda che qui qualcosa non sta andando bene".Al giorno d'oggi siamo abbastanza fortunati perché stiamo vivendo una cosa che credo tutti quanti conosciamo, quindi non menzionerò niente di nuovo, però l'intelligenza artificiale.Questa cosa in verità nel mondo dell'observability sta aiutando molto perché grazie all'intelligenza artificiale stiamo riuscendo a fare determinate cose che prima era molto più complesso fare.Per esempio determinare come il tuo software in produzione sta andando e quali sarebbero i threshold giusti in base a quelli che invece mettiamo noi a mano.Quindi se lui vede che il trend è che ogni cinque giorni tu hai un picco di 100 utenti, in quel picco lì lui cerca di capire quanto è stato il consumo medio di CPU.Dopodiché, negli restanti giorni, magari vedi che stai andando così così e poi improvvisamente inizi a andare un po' sì, un po' no, 50 qua, 0 di là, 100 di qua, 0 di là.E quindi, grazie alle A, possiamo avere una specie di ricalcolo e capire quali sarebbero in verità i threshold corretti per te.Quello che invece tu faresti a mano sarebbe una media, no? Cioè, dici "boh, più o meno va così, faccio la media, boh".Invece lì ti aiuta a capire anche in base al carico.E dicendo "guarda che durante la settimana il tuo carico dei threshold è così, ma durante il fine settimana, per esempio, è cosa A".o magari dirgli in quali momenti potrei ridurre il carico del software e l'IA ti dice "guarda, ho determinato che in determinati punti della settimana, magari lunedì sera, lunedì pomeriggio, mercoledì mattina, potresti mettere anche in stand by il tuo software perché tanto non lo usa nessuno".Quindi un po' di informazioni adesso, per fortuna, arrivano anche tramite l'utilizzo di questa IA.Tuttavia, diciamo che la pratica dell'SRE vuole anche che tu ti metti lì e capisci quali sono i limiti parametri per poter poi fare gli alert.E un'altra branca che arriva dopo gli alert, credo ci arriverà probabilmente con una domanda, è il famoso on-call, stare in chiamata per capire cosa succede se qualcosa va a fuoco.E il famoso pager duty che tutti odiano! Chiunque abbia installato un pager duty nel telefono l'ha fatto a seguito di gozzilioni di bestemmie.- Major Duty o OVGINI, dipende da quale prodotto hai usato, però OVGINI è un altro che tutti amano e odiano allo stesso tempo.- Sì, vero.Poi l'empowerment del team è fondamentale, per esempio una cosa che l'Observability sblocca, aiuta, permettere al team di gestire, per quanto non completamente, ma almeno gestire i propri servizi in produzione.Una delle cose che ricordo Julian fece praticamente da subito è che "Ok caro bel team, questi sono i tuoi servizi in produzione, questa è la tua dashboard Dynatrace per ogni ambiente.Guardatelo" e ogni team, almeno ogni giorno, ci buttavano occhi "Ok ci sono x errori" Perfetto, tutto sta funzionando.Perché tu guardavi se c'erano errori e se c'erano 200, e se c'era almeno qualche errore tutto stava funzionando come doveva.Capita però che se il team non sta attento si rompe l'implementazione di OpenTelemetry o si fa qualche cazzata e smettono, o non si aggiornano od e smettono di arrivare le metriche e là a quel punto avere un sistema di alerting che ti dice "oh non mi stanno arrivando le metriche" è fondamentale.Quindi secondo me pretendere che un uomo controlli servizio per servizio non è più fattibile, in questa in questa procedura, cioè proprio non è più neanche pensabile, non si può fare.Anche perché secondo me la parte più complessa sarebbe poi la conoscenza approfondita di quel servizio, per poterlo poi interpretare.Secondo me è impraticabile che uno conosca a mena dito, proprio dal cuore, più di 100 servizi e capire tutti quanti come funzionano e come dovrebbero funzionare.Però lo studio degli alert, ok un po' l'intelligenza artificiale ti dà una mano, però facciamo prima un tempo, tempi belli di una volta quando non c'era l'intelligenza artificiale ai miei tempi.Comunque, per capire quale fosse il threshold su cui fa scattare l'alert, immagino, penso, qualcosa devi analizzare manualmente anche per vedere, ok, a questo servizio è normale che ci siano un 1% di errori, per qualche strana ragione, perché c'è un qualcosa, invece in questo servizio assolutamente non ci devono essere errori.Lo fa il team di sviluppo che lo dice, oppure forse è una cosa che piano piano cresce, viene naturale a seconda delle esigenze, a seconda degli incidenti che accadono, qualcosa del genere, piano piano si costruisce tutta l'infrastruttura, tutti gli alert all'observability.Insomma, un po' come può funzionare in diversi scenari.Quindi, c'hai, puoi avere l'infrastruttura che è cresciuta esponenzialmente troppo presto e non ha niente di tutto ciò, quindi tu arrivi, hai magari un team di 100 persone e nessuno si è mai sognato nemmeno di fare qualcosa di diverso, che vedersi i log, i file di log sui sistemi Linux e quindi in questo modo operi con una certa strategia che poi mi dici quale.Di contro invece c'è un, può esserci, un'azienda che cresce pian piano e che arriva a un certo punto non critico dove ci sono dieci servizi e non mille dove si deve cominciare a creare, a creare questo sistema di monitoring.E poi mi dici come agire e poi magari ci sta un'altra azienda dove invece hanno già pensato a tutto ma si deve semplicemente migliorare o utilizzare giusti tool migliori o aggiornarli.Immagino questi tre scenari, come agiamo in questi tre scenari? Sono tre scenari veramente complessi, quindi iniziamo a spacchettarli uno ad uno e cerca di ricordarmili perché più o meno me li ricordo, ma non tutti chiaramente precisi.Però il primo, se non ricordo male, è quello che hai mai detto, di come uno analizza i threshold, cioè come arriviamo a questi numeri.Allora, in quel caso lì, quello che di solito si fa, o quello che abbiamo cercato di fare anche noi nel nostro caso, insomma quando siamo arrivati qui dove sto lavorando anche con Mauro, è stato quello di dire "partiamo da dei numeri che sarebbero gli ideali".diciamo per esempio il tuo servizio deve avere al massimo quindi per massimo intendiamo quello che poi sarà la criticità p1 cioè priorità 1, quella dove tutta l'azienda si allarma o mio dio sta andando tutto a fuoco al massimo diciamo un p1 può avere un 10 per cento di errori se partiamo come errore come metrica ok perché ci sono diverse metriche tra l'altro che si analizzano c'è gli errori che puoi avere server side quindi diciamo tutti quelli che vanno dal 500 in su ci ci sono per esempio quello che in inglese viene definito throughput, cioè quanto è la tua potenza di fuoco nel traffico, nel poter sostenere quel tipo di traffico.C'è anche quello che in inglese viene chiamato latency, che sarebbe la latenza, se non ricordo male, in italiano, che è quanto veloce è la comunicazione tra te e l'utente finale.Però se prendiamo per esempio solo l'error rate, cioè quindi gli errori in server, in quel caso ne diciamo 10% il massimo.Dopodiché, in base agli scaglioni che vuoi avere, di avviso, perché poi ci sono gli avvisi carini e gli avvisi meno carini.Quindi c'è l'avviso carino P4 per esempio, priorità 4, che dice questo è il primo avviso che di solito do agli sviluppatori perché sarebbero quelli che dovrebbero dire "ustrà, qualcosa qui non sta andando".Quindi sul P4 per esempio se analizza si dice vai a un 2%, magari un P3 lo fai a un 3-4%, il P2 lo fai a un 7-8% e poi P1 10%.Dopodiché cosa succede? Come hai detto tu, il software, non tutti i software sono guardi ci sono software che magari per forza di cosa avranno sempre un margine d'errore però quell'errore deve essere controllato quindi se come hai detto tu per esempio è sempre uno per cento e vabbè ci si mette l'anima in pace si saprà che con l'uno per cento sarà sempre l'error rate ma per forza naturali di cose magari cose che non puoi controllare cose che non sono di tuo controllo per esempio chiami un server che completamente dipendente da te chiami un servizio che non c'entra niente con te una volta è stabile una volta no insomma tutte queste cose qua quindi questi di solito sono i numeri alla vecchia maniera di come si facevano, di che il team che sviluppa il software dovrebbe controllare e gestire questi parametri, questi numeri e dire questo è il numero che scelgo io per la criticità massima, questa per la criticità minima e poi tutte le varie scarie in mezzo.In teoria l'SRI quello che può fare è in base agli alert, in base magari si è tipo dice "oh guarda che io dal tuo software sono stato chiamato dieci volte nell'ultima settimana, qualcosa non sta andando" quindi quello che l'SRI può fare è andare dal team e dire "scusate ragazzi ma insomma siamo stati chiamati 10 volte ci sono svegliati 10 volte alle 3 del mattino ogni volta forse no è il caso di dare un controllo al software o quello che sta andando però questo è quello che si faceva come dire alla vecchia maniera ora con l'intelligenza artificiale per fortuna un sacco di volte molti dei problemi se magari l'IA vede che tu fai un errore ed è sempre lo stesso errore ed è sempre alla stessa ora è sempre allo stesso momento dice no guarda inutile che ti chiamo perché ho già visto che l'abbiamo fatto 10 volte questo gioco, tu comunque per 10 volte sei andato lì a fare knowledge e dopodiché non è successo niente evidentemente è una cosa che già nota e evito di chiamarti.Ci sono dei trucchetti che l'IA sta aiutando da questo punto di vista però rimane full core cruciale la squadra che sviluppa il software secondo me per controllare più numeri.Credo che nella definizione delle threshold abbiano un ruolo importante i requisiti non funzionali dell'applicazione stessa nel senso che sono quelle cose che si devono prendere in considerazione perché a noi capita di fare dei servizi che sono di criticità uno e dei servizi che sono di criticità ce ne farei un cazzo perché tanto c'è il fallback e quindi l'approccio E tra l'altro da development spesso quando una roba fallisce in modo consistente ci capita di sviluppare dei fallback by design, cioè queste API mi fallisce in modo inconsistente, flachi perché il provider ce l'ha on premise nello sgabuzzino di casa e funziona una volta sei 12,9 allora io te se vedo che fallisce in chiamata ti servo una cash con rischio che sia stale ma intanto ti servo qualcosa e non lo blocco quindi da questo punto seria.Poi in fase di comunicazione secondo me c'è anche tanta politica di comunicazione del P1, P2, P3 nel senso che il team di SRI se vede un errore consistente ha tutti gli strumenti per fare in modo che il team di development...stai ridendo perché io so che ce li avete perché il team di development lo fixi perché Giulia in modo molto political correctly dice "no vabbè noi vediamo però se developers...glielo diciamo a developers e bom bom bom.In realtà quello che succede è che l'errore fallisce consistentemente e Siri non fa altro che chiamare per tre noti di seguito i developers on call perché anche se ha capito l'errore deve fargli pensare la cosa e dopo due giorni che i developers a mezzanotte e mezzo si devono collegare per leggere i log fixano il bug 90% dei casi.Io sono pronto.Quindi c'è anche quel gioco che però è un gioco di comunicazione e allora apriamo la porta della comunicazione.Come si devono strutturare le skill di comunicazione di un SRI? Bellissima domanda.Allora io credo che secondo me un bravo SRI deve essere capace di spiegare il problema ma senza prendere niente a livello personale.Ok? Alla fine della fiera comunque io credo, sono ancora convinto, nel fatto che ogni persona non ha delle malintenzioni, ok? A meno che sappiamo delle figure classiche, cracker, fisher e tutte quelle robe lì, però se escludiamo quella branca di persone io credo che gli sviluppatori, comunque in generale chiunque lavori in un ambito professionale, non lo fa in malafede.Quindi gli errori possono capitare ed è giusto che capitino, l'importante è imparare da questi errori.Dopodiché, come hai detto tu, la parte politica purtroppo gioca anche la sua criticità, quindi anche lì devi saperti giostrare e capire in che modo puoi determinare determinate conseguenze di richieste che fai.Ci sono richieste che potrebbero essere completamente ignorate dalla squadra di sviluppo, ci sono cose che tu dici "guarda a me piacerebbe che questo errore venisse sistemato perché così riduce l'overhead di threshold, perché abbiamo notato che dei log che abbiamo analizzato sistemando questa cosina piccolina comunque migliora la situazione però dal vostro punto di vista, cioè dal punto di vista del produttor diciamo io non ce li spendo questo tempo questi soldi a sistemare una cazzatina così.Ci sono dei trade politici che poi puoi iniziare a dire guarda se mi fai questo io ti faccio questo favore se hai bisogno ti analizzo qualcosa in più, c'è quella parte di gioco politico però in teoria in un'azienda sana e in un gruppo di squadre di lavoro sano queste cose non dovrebbero esserci e dovrebbe essere invece parte della cultura analizzo porto il feedback che ci lavoriamo sopra dove in verità l'SRI altro non fa che dire ok ho trovato questo problema ti crea la task, story, chore, quello che vuoi essere dentro il backlog su gira o di quello che usi come ticket system per gestire il ticket di lavoro ti crea il ticket e poi lo sviluppatore se lo piglia e vai in saccoccia e se ha domande pinga l'SRI e gli dice cosa volevi intendere.Adesso però a però a questo punto la domanda immediatamente successiva viene in modo quasi automatico collegandoci alla chiacchierata che abbiamo avuto stamattina proprio sul topic.Stamattina hai tirato fuori dal cilindro la parola magica, io probabilmente volevi mettere un po' di paura, però hai tirato fuori dal cilindro la parola error budget.intanto che cos'è il concetto dell'error budget e poi come in realtà l'error budget entra in questo tipo di contesto e come aiuta in questo tipo di contesto? Allora l'error budget innanzitutto definiamo che cos'è l'error budget, cioè il budget degli errori è una specie di portafoglio, è come se tu avessi determinato, come se ti dicessi hai 100 euro, ok? Hai 100 euro, con questi 100 euro te la devi sapere gestire.Il tuo software deve stare in produzione con 100€.Se qualcosa va storto, per ogni cosa che va storta, per ogni piccolezza o qualche errore che può capitare nel software, mi pagherai 1 centesimo.Quindi, immaginiamo che il tuo software ha un 5% di errori, in base alla soglia massima, tu mi devi dare indietro 5€ di quei 100€, perché ne avevi solo 100€, quindi tu mi paghi 1 centesimo per errore.L'error budget in questo caso viene definito dalla parte o della squadra SRI o del team software ed è una specie di contratto di fiducia che si ha tra chi tiene il tuo software in produzione e tu che lo sviluppi.Dopodiché cosa succede con questo error budget? Si calcola sopra questo tutto quello che poi a noi tutti quanti piace vedere quando vai sul sito di un fornitore di servizi che ti dice disponibilità 99.999999% infinito.Come è stato calcolato questo numero? questo numero è quello che tutti conoscono come SLA cioè Service Level Availability questa cosa, questo numero, viene calcolato in base a determinati altri parametri che sono SLI, l'indicator, cioè Service Level Indicator e SLO, che è Service Level Objective questi parametri vengono calcolati anche includendo l'error budget quindi cosa si fa? per farla proprio grossolana, molto semplicistica abbiamo 100 servizi il budget che avete tutti quanti per servizio del 5%.In base al calcolo mediano dei 100 servizi e dell'error budget che avete, noi calcoliamo quanto è la disponibilità 100% meno la mediana degli errori di tutti i 100 servizi.Quello, a mente, sarà il nostro SLA.Che poi, non proprio l'SLA, sarà l'SLI, in verità.Cioè quello con la "i".Perché poi l'SLA è un contratto di fiducia che tu fornisci ai tuoi clienti dicendo ti garantisco che sarò disponibile il 99.9999% molti servizi per esempio anche amazon stesso se ci andate a vedere non ha più 99.9999% ha il 98% credo 97% perché non può garantire che è sempre al 100% e quindi cerca di tenere quella soglia di disponibilità sempre in quel numero quindi l'SLAI deve essere sempre idealmente maggiore dell'SLA perché se no devi pagare indietro i tuoi clienti e dirgli scusate non ero online c'è un problema, avevamo concordato un numero e quel numero non è stato rispettato.Abbiamo parlato di observability, quindi di tool, di observability come strumento per l'attività di SRI, ma esistono altri strumenti, non parlo di tool software o di tool specifici, di tool da toolkit nella cassetta degli attrezzi dell'SRI.Allora i famosi tool che escono fuori dalla manica quando parli con un SRI il più delle volte sono gli strumenti che servono a osservare e di questi conosciamo i nomi, ne possiamo menzionare alcuni.Hai già menzionato Dynatrix che è uno dei più grandi player del mercato di observability, abbiamo Datadog che che è un altro elefante nella stanza del mondo observability.Ammo e Grafana, Prometheus, la combinazione che tutti quanti il più delle volte conoscono perché è il più citofonato nel mondo open source.Ce ne sono di nuovi, come per esempio Honeycomb, che è tutto basato su OpenTelemetry e può fare comunque monitoraggio e observability in generale a 360° usando solo le informazioni che arrivano tramite OpenTelemetry.Quindi esistono dei player che, diciamo, questi sono i tool che uno di solito usa perché sono quelli che ti forniscono tutto il pacchetto informazioni.Dopodiché per tool il più delle volte quello che un SRE ha bisogno è un agente, viene chiamato così, un agente software che va installato, che automaticamente cerca di capire o carpire tutte le informazioni, quei metadata che ti servono per calcolare tutte queste informazioni qui.C'è bisogno di conoscenza secondo me al giorno d'oggi per l'automazione, per tutto quello che c'è di Terraform, perché comunque è il linguaggio che viene usato il più delle volte per fare infrastruttura e il più delle volte dovrai usarlo tu stesso per deployare, per mettere in produzione questa gente e dopodiché può essere appunto i vari, non so, Python se usi Ansible, Ruby se usi l'altro che non mi ricordo più come si chiama, che è l'altro di automazione rispetto ad Ansible.C'è Bash ovviamente, no, perché il più delle volte i sistemi sono fatti in Linux, quindi insomma c'è Bash, ovviamente poi i vari sistemi di CI/CD che stai usando, che può essere GitHub Actions, GitLab o Jenkins per la gente che usa ancora Jenkins, che è innamorato di Jenkins, insomma c'è Jenkins e il suo linguaggio che non mi ricordo neanche più come si chiama, Groovy, me lo so ricordato, quindi il Groovy, insomma c'è anche quel mondo lì.Eh vabbè allora, aspetta vado a tirar fuori la mia t-shirt Jenkins Master se vuoi, la maglietta me la metto al prossimo giro.Pensavo una cosa tra i tool che stavi nominando, prescindere dal brand, dall'azienda che lo produce, uno dei tool molto interessanti che ci apre la discussione poi a un altro concetto, un altro bridge che mi piacerebbe tirare sono i tool di synthetic monitoring perché finora abbiamo parlato dell'utente, consumo e servizi, i servizi sono sotto carico dagli utenti, l'applicazione è sotto carico dagli utenti, noi spesso parliamo di servizi ma possiamo anche parlare di applicazioni, mi immagino che la mia app Next.js è deployata da qualche parte sotto carico degli utenti e va bene ma il synthetic monitoring shifta completamente la prospettiva no? e quindi vuoi parlarci un po' di synthetic monitoring visto che ci hai lavorato per un po'.È una cosina che conosco giusto un po' lì.No, però in verità sì, è un ambito molto interessante il Synthetic Monitoring e credo che sia una delle practice che secondo me è nata ultimamente in verità.Non è stata, non è molto famosa, è una cosa che già tutti comunque in un modo o nell'altro conoscono come approccio, però credo che nel mondo observability sia arrivata recentemente.Perché? perché l'approccio proprio, la mentalità del Synthetic Monitoring è quella cosa che...cioè per spiegarlo in poche parole, che cos'è il Synthetic Monitoring? È fondamentalmente il monitoraggio a livello sintetico, quindi traduzione papale a papale, però fondamentalmente è un robot che visita il tuo sito come se fosse un utente e cerca di capire a livello funzionale se le cose stanno andando.Qual è il vantaggio di usare un monitoraggio a livello sintetico? Praticamente, SAR è il mondo ideale che uno sviluppatore si aspetta, dato uno scenario che lo sviluppatore sa, o comunque l'azienda o il business sa, perché ti chiede di fare un servizio su un determinato business, su un determinato...aspettativa che si ha dell'utente finale.Quindi, concretizziamo questa aspettativa, facciamo che questo utente ideale naviga ogni 5 minuti il tuo sito e ogni 5 minuti va a farti un acquisto.Ogni 5 minuti si va nel suo profilo e si cambia la password.ogni 5 minuti entra e va a scrivere un commento in un post.Cioè tutte quelle funzionalità che potrebbe avere il tuo sito.Qual è il vantaggio di questo? Che il monitoraggio a livello sintetico.Una volta che esegui questa azione, siccome è fatto dallo stesso tool che anche fa monitoraggio dei tuoi servizi, se trova un problema, il più delle volte riesce a correlare tutta questa cosa, tutta questa attività che ha fatto, con il problema.Quindi a te come sviluppatore ti fornisce una cosa bellissima, che secondo me è una delle cose che mi sono emozionato di più quando l'ho vista in azione, che è praticamente il root cause analysis, cioè l'analisi a livello di radice.Ti dà un grafico molto bello che ti dice "ho iniziato qui, sono passato di qui, sono passato poi di qua, di qua e di qua e mi sono bloccato esattamente qui".E l'errore è stato questo.E le comunicazioni che ho avuto tra tutti questi passaggi sono state queste API con queste risposte.Secondo me è la cosa più bella che se io avessi avuto a mio tempo come sviluppatore per debuggare tutto quello che dovevo debuggare, era una delle cose più belle che mi sarei stato proprio emozionato.Perché? Perché credo che in un unico sguardo al tuo problema ti dice esattamente dove devi picconare.La famosa riproducibilità.Esatto, che poi alla fine andiamo a finire lì, la riproducibilità.Io ero ignorante, quindi non conoscevo questa tematica ma come si fa? Cioè che strumenti ci sono? Come si fa a simulare il comportamento di un utente? Domanda giustissima.Con i test classici di qualcosa che apre un browser finto, headless e ben giro o ci sono cose più che inutili? No, non è fantastico, è esattamente come mi hai quindi lo strumento dietro alle quinte usa una cosa...come si chiamava quello strumento in node? Puppeteer! mi sono ricordato! si usano roba tipo puppeteer, però adesso ne esistono anche di migliore, di driver e tutto quello credo che il più famoso è stato puppeteer quindi usano un roba come puppeteer dietro che usa il browser e praticamente tu come lo piloti questo sintetico gli dici "apri questo url, cliccami qui, qui e qui" quindi gli dai tutti gli step di click e poi lui li segue uno ad uno step possono essere fatti o con dei css selector oppure con dei dom selector quindi puoi farli o sintassi javascript oppure sintassi css e in base ai determinati casi lui ti fa proprio l'azione ti dice click hover muovi il mouse puoi fare determinata azione no quindi tu le coordini lo pilota in questo modo il più delle volte il più delle volte scusami il tool ha una interfaccia UI che te lo permette di fare comodo oppure puoi anche scrittarlo puoi anche farlo in codice javascript piuttosto che magari un json, un bel mappazzone json fatto insomma strutturato, però che ti permette di fare questa cosa qui.Per farlo andare ad libitum? Perché è detto che sono una botta che vanno...lo puoi settare o una tantum, cioè tipo dirgli "fallo e basta, e dammi il risultato" oppure lo puoi settare schedulato, quindi gli dici "fallo andare ogni cinque minuti oppure fallo andare ogni lunedì mattina fallo andare e puoi farlo ovviamente per quello che viene definito journey no quindi per ogni oggetto che sarà il tuo journey cioè per dirgli tutti gli step che farà l'encapsulatore più grande e journey quindi per ogni journey gli dici puoi fare questa cosa qua e in ogni giorno è completamente indipendente quindi puoi avere giorni che vanno una volta alla settimana altri che vanno ogni cinque minuti e così via.sono degli end to end tester in produzione continui? allora esatto su questo volevo specificare una piccola differenza ti dico è una confusione che è ancora noto presente anche nelle aziende che lavoriamo noi il più delle volte quando la gente mi parla di questo mi dice ma allora scusami cosa cambia da per esempio usare cypress no? che è un altro tool che viene usato spesso per fare testing di questo tipo la differenza fondamentale è che un monitoraggio a livello sintetico non si cura e non gli deve interessare dell'aspetto estetico del sito.Cosa voglio dire con questo? Che se il bottone per andare avanti, cioè immaginiamo un processo di checkout dove tu fai il tuo acquisto è in step e quindi è il tuo famoso azione poi bottone avanti, azione, bottone avanti.Ora nel monitoraggio a livello sintetico a te non ti interessa se il bottone avanti è in alto a sinistra, in alto a destra, in basso e a destra, devi scrollare un treno per poi andare a bottone avanti questo non ti interessa, a te ti interessa, c'è il bottone, l'utente finale può andare avanti nel processo, se sì, quello è il tuo test del monitoraggio sintetico, di che chi invece fa il testing a livello di design, a livello di qualità o a livello di quelle cose lì, sono quello che fa il QA, cioè il Quality Assurance quello si deve occupare di quell'aspetto, invece il monitoraggio a livello sintetico puramente funzionale.Il sito funziona, cioè quell'azione funziona, sì.E chi lo scrive il test? QA o SRI? Allora, in verità il test, cioè il journey, dovrebbe in teoria...C'è scritto dal business in gear king...in teoria il team di sviluppo che sviluppa quel software dovrebbe sapere il suo journey, dovrebbe sapere in che punto di tutto l'incastro è.Però se il team non lo sa, allora dovrebbe essere il team SRI che è allineato col business sa dove deve andare a parare tutta sta roba.La vera magia in realtà di alcuni strumenti di synthetic monitoring si vede con l'integrazione delle traces, la root case analysis si sblocca nel momento in cui c'è una corretta configurazione delle traces e tutto è fatto a modino.Quindi possiamo parlare giusto due minuti di cosa sono le traces? Perché potrebbero essere così importanti e togliamo anche il potrebbero e perché da quando le ho scoperte io metto sempre un request ID tra i miei aid? No, io credo che sono il punto di svolta del mondo dell'observability, un po' come la favola di Chiara, che mi sa che era persa nel bosco e con le briciole è riuscito a tornare indietro? Pollicino! Ah, pollicino! Ecco, è una favola di pollicino.Quindi i traces sono esattamente la stessa cosa che a noi permettono di andare indietro e capire come le cose sono andate.Quindi, in termine molto semplici, le traces, cioè le tracce, sono quella informazione che noi collezioniamo per poter poi dire "sei passato di qui, poi sei passato di qui, poi sei passato di qui".però immaginate ovviamente che un sito non è usato da un solo utente, è usato da un milione di utenti quindi come facciamo a capire quel singolo utente, cioè Julian che sta visitando il sito come facciamo a capire che Julian ha cliccato prima sto link, poi sto link, poi sto link e poi questo link lo facciamo con un'informazione che aggiungiamo negli header che viene chiamata correlazione e questa informazione sarà quella, la nostra chiave che ci permetterà di dire "ok, sei sempre Julian, sei sempre Julian, sei sempre Julian" e quindi in base a quella determinata chiave noi correliamo tutto e diciamo "ok, Julian è passato di qui, di qui, di qui, prima che l'errore, cioè prima che tutto andasse in implosione".Quindi questa è una cosa che è molto, appunto, molto frequente e molto usata nelle traces.Spero che vi sia stato bene, se avete domande...Sì, sì, no, no, no, era perfetto.Io quando parlo di traces l'esempio più semplice è immaginate una dashboard che potete vedere da dove entra la richiesta fino alla call al database.lo so sto banalizzando però vedete tutto il flow fino alla query SQL e secondo me è la cosa più spettacolare, partendo dal browser fino al database secondo me è spettacolare.E questa cosa è potentissima perché a quel punto ti permette di spottare tutti i bug in modo veramente semplice questo approccio è potenziato, è empowered, è fortemente stimolato anche dallo sviluppo di OpenTelemetry come tool.Adesso, quanto dal tuo punto di vista sta facendo OpenTelemetry e quanto invece è ancora a pannaggio degli agent della applicazione specifica che sia da inattreschi, qualunque tipo di prodotto commerciale vogliamo tirar dentro.Chiaro, allora c'è da fare un prologo a questa cosa perché molte persone purtroppo confondono OpenTelemetry come un'altra soluzione che si può usare indipendentemente da tutto il resto.Sfatiamo un mito, OpenTelemetry è un protocollo, non è una cosa magica che funziona, che qualsiasi protocollo va usato per tuo vantaggio.Quindi è un protocollo che è nato per standardizzare, cioè per creare uno standard intorno al mondo dell'observability.Tra l'altro OpenTelemetry è nato esattamente da questi grandi player.È nato da Dynatrace ed è stato adottato da Datadog, è stato adottato da Honeycomb, è stato adottato da Grafana e così altri.sono entrati fondamentalmente nella stessa cosa un po' come un patto di alleanza nel dire vabbè facciamo in modo che abbiamo sto protocollo standard tutti quanti lo supportiamo e sappiamo che parliamo la stessa lingua open telemetry da solo non può funzionare open telemetry da solo deve per funzionare deve essere implementato dagli sviluppatori è una linea di codice che devi scrivere tu devi pilotare tu quindi se tu vuoi mandare un trace devi proprio scrivere la lina di codice dicendo manda il trace con queste informazioni dentro altrimenti OpenTelemetry da solo non le colleziona.Quello che avviene, diciamo, la magia che avviene da parte di questi tool commerciali è dire ok abbiamo concordato che abbiamo un linguaggio comune, un protocollo comune, quello che possiamo fare è implementare questo protocollo comune e fare in modo di saperlo leggere.L'agent, quindi quella parte che diciamo che coordina questo manda il trace, manda la metrica fai questo fai quello è quello che si occupa di mettere una porzione di codice dentro al tuo codice e fare in modo di coordinare open telemetry di riguarda che se qualcosa avviene a livello http mandami il trace se qualcosa avviene a livello di servizio mandami la metrica quindi hanno una porzione di codice che il più delle volte voi non vedete però noi a sarì che andiamo fondo sappiamo che c'è del codice in più rispetto al vostro codice che viene aggiunto il più delle volte in testa nel caso di Node.js viene aggiunto in testa e quel codice viene avviato prima del vostro codice perché? Per esempio hooka proprio parlando terra a terra, hooka il modulo HTTP di Node.js e fa in modo che qualunque cosa avviene a livello xml, http request viene mandato a Dynatrace o la gente che sta usando DataDog o insomma quello che sta usando come tool tramite open telemetry.L'anno scorso febbraio scorso a Fosdem c'era un interessantissimo talk fatto dai ragazzi di Grafana che parlavano delle prospettive di ebpf per fare l'instrumentation più a basso livello, che è una cosa mostruosa perché in realtà riesce a uccare la chiamata metodo, quindi era qualcosa di veramente eccezionale, con decaveat per linguaggi interpretati, per cui da quel punto di vista ci aspettiamo ancora un po' di rivoluzione da questo punto di vista, sono super curioso, però era una cosa che aveva catturato la mia attenzione ed era uno dei che avevo seguito con più piacere? Assolutamente, è una delle piccole rivoluzioni che sta entrando nel mondo SRI ed è il trend del giorno, un po' come l'IA di tutti i giorni che se ne parla.Nel mondo observability, l'ABPF è quello che sta rivoluzionando un po' tutto perché permette di fare le stesse cose però più performanti e tra l'altro evitando dell'overhead a livello di codice.Per fare un esempio molto pratico per chi ci se tu carichi un servizio e su questo servizio deve aggiungersi un pezzo di software che analizza è cpu in più che viene usato e ram in più che viene usata ok invece le bpf lo installi una volta nel sistema è fatto praticamente io ho l'ownership totale di tutto il sistema che sta lanciando qualunque servizio che sia kubernetes che sia il microservizio che sta andando o che sia quello che sia però sì come detto tu purtroppo anche delle limitazioni soprattutto in linguaggio interpretato.Sono curioso di vedere l'evoluzione.Il tempo sta volando, ho appena dato uno sguardo al timer e sembra che abbiamo iniziato dieci minuti fa, siamo già un'ora e un quarto.Però voglio farti questa domanda.SRI e tool, practices e quanto essere i processi? Allora io credo da quello che sto notando io adesso è un 40/60, 40 nei tool e 60 in processi perché il più delle volte è convincere le squadre, l'azienda stessa, far capire il valore di quella determinata scelta più che farla perché una volta che ti sei allineato e sai come mandare avanti la giostra, puoi farla, sì ok hai i suoi challenge ma alla fine della fiera, insomma si parla di giungere un paio di righe, una gente di qua, una gente di là, ehi portate la pagnata a casa come diranno, però il più delle volte la sfida più grande è convincere, convincere la gente che determinate cose portano dei risultati.Un esempio pratico per esempio qui, abbiamo parlato del nitoraggio a livello sintetico e io ancora oggi sto portando avanti una battaglia che è quella di capire come fare in modo che le squadre di sviluppo possano avere in autonomia la gestione dei propri flussi, dei propri journey nello sviluppo.Come farlo? Dando potere a loro tramite l'automazione, magari mettendo file.json o qualcosa come interfaccia per poterla gestire.Apriti cielo! L'ultima volta che ho provato a aprire questo argomento mi è stato cannato a metà, è stato verso metà anno scorso, non mi è stato permesso.Ora sembra che ci sia un po' di interesse, però ancora c'è un po' di confusione, vediamo forse sì forse no, insomma ci sono sei mesi di discussione ancora dietro e di codice, di una linea di codice non è ancora scritta quindi sono fermamente convinto del mio 6040.Sì e lo sdoganamento dei processi anche da parte dei team non è una cosa gratuita, non è una cosa immediata perché in realtà lavora su due filoni, sul filone del development team che è sempre abbastanza conservativo il fatto di nuovo workload che si aggiunge al backlog in fase nel filone di prodotto che pensa che questa nuova cosa non è un RGU, un elemento che genera revenue e si vabbè tu mi dici che il servizio è stabile ma cazzo i miei sviluppatori sono bravi devono scrivermelo bene dall'inizio perché per quanto noi possiamo prodotto la vede da questo li sto pagando bene devono scrivermi il codice buono che funziona ma non è così cioè il codice lo si scrive ma tanto non funziona Perché, come diceva Osho, "shit happens" non è "se" ma è "quando".Assolutamente.Infatti, tra l'altro, una delle domande che tutti si fanno, anzi tutti si aspettano che l'SRI non sia la figura che punta il dito sui problemi, ma sia la persona che dice "tranquillo, ti risolgo tutto io, non c'è problema".Quindi questo è quello che prodotto pensa, "Ah, c'è una serie? Perfetto, la persona che mi risolverà tutti i problemi".Non funziona proprio così.Si, ma lei ti dice perché è andato tutto a puttane, ma non fa altro.Con i guanti.Comunque ti dice "Sta per andare tutto a rammengo".Comunicazione di servizio.Esatto.Comunicazione di servizio tutto attaccato.Di servizio, esatto, tutto attaccato.Comunicazione di servizio.Ok, io direi che è arrivato il momento tipico e topico di Gitbar, il momento in cui sia i nostri host che i nostri guest condividono con noi un libro, un talk, o qualunque cosa abbia catturato la loro attenzione, diciamo valga la pena essere condiviso qua appunto nel nostro circolo bar di Gitbar.Quindi sigletta.Forse l'SRI è andato...La facciamo.Si è rotto tutto, hai bisogno di una mano? La mia domanda qua è diretta a Julian in questa fase e la domanda è appunto hai qualcosa da condividere nella nostra community qualcosa che secondo te valga la pena appunto essere condiviso con i nostri ascoltatori? Guarda sarò magari in contrattendenza perché non condivido un libro non condivido magari non so un talk però mi sento di condividere che se c'è gente appassionata che sta guardando questo ed è interessata a un altro ambito che è quello del reverse engineering io consiglio caldamente uno dei progetti a cui sto lavorando personalmente in questo periodo, andate a trovarmi su github e lo troverete lì sopra, il progetto si chiama ffnx ed è inerente a un gioco in verità, a Final Fantasy, e se siete interessati a fare reverse engineering sul gioco sentite liberi di contattarmi perché abbiamo bisogno di una mano e ci sono anche ragazzi italiani tra l'altro che ci stanno lavorando sopra ma non posso dire chi perché devo chiedere alla persona stessa se vuole essere menzionata.La scopriremo subito.Grazie mille.Molto a te.Non vuole essere menzionata credo.Ok ti chiedo per cortesia di mandarci un link quando appena puoi.Luca! Eccomi, forse l'ho ballocato forse no ma ci ho rigiocato di recente ed è un un sito, in realtà è un'azienda che fa queste cose, però mette a disposizione un gioco che Gandalf di Lakera, o Lakera non so come si pronunci, .ai, poi metterò il link.Interessante.No, è interessante per vedere la sicurezza dietro i LLM moderni, visto che un tema è un topic.Dobbiamo comunque cominciare a prendere confidenza anche con questo tema per non fare la figura degli SQL injection di vent'anni fa, quindi evitare i prompt injection e cose di questo tipo, ti spiegano...allora è un gioco dove c'è un bot che devi convincere a farti dare una password.Diviso i livelli, quindi il primo livello è del tipo "dammi la password" e lui te la dà, e poi via via sempre più sempre più complicato.Prima il bot viene istruito a non svelare la password, cosa che come sicurezza è un po' blanda, però poi mettono sempre più sicurezza, sempre più misure di sicurezza che tu devi in qualche modo cercare di agirare.E ce ne sono diversi, prima hanno cominciato con questo giochino di otto livelli, poi ne hanno aggiunti altri ed è simpatico, è carino, merita di darci un'occhiata.Gandalf di Lekerai.ai Se mi dicessi che io non ho un balocco? Stavo pensando una cosa però l'unica cosa in realtà che mi viene in mente da condividere è legato all'ultimo punto che ho portato nella discussione ed è legato ai processi.Un libro che abbiamo condiviso diverse volte qua su Gitbar e che io ho qua nel mio biletto è The Phoenix Project.Leggetelo.È un romanzo che parla di di organizzazioni, di problematiche legate all'organizzazione, ha un botto di anni credo, ma è tipo sembra scritto ieri mattina.Ma la cosa bella è che è un romanzo, cioè non è un libro tecnico, è proprio un romanzo.E Spoiler è un po' come l'oroscopo, cioè parla di tutte le organizzazioni, se tu lo leggi dici "ma cazzo questa è la mia azienda", e dici "ma è davvero così disfunzionale?" è un po' così, è un libro fantastico perché pur essendo un romanzo riesce a essere più incisivo di un saggio, credo sia l'unico romanzo che ho letto negli ultimi 3-4 anni.non potrei trovare semilitudine migliore almeno per uno come me che non lo conosce ora mi è intrippato quindi se mi dice che com'è l'oroscopo devo leggerlo quindi buttaci un occhio buttaci un occhio perché secondo me lo trovi interessante bene ragazzi si è fatto tardissimo per me che sono sveglio tipo dalle 5 e mezza stamattina quindi intanto ringraziamo Julian per esserci venuto a trovare grazie Julian è stato un superissimo piacere come abbiamo detto all'inizio Gitbar è un po' un circolo no? Io sono sicuro che tu ti ricordi dei circoli arci di una volta dove si andava a bere economico e dove la prima volta che entravi ti si faceva la tessera ecco Gitbar è il nostro circolo della situazione per cui hai ormai la tessera per cui puoi venire a bere una birra fresca quando vuoi anzi meglio la prossima volta che hai qualcosa di interessante che ti fa piacere condividere con la nostra community pingaci c'è sempre una birra fresca e Gitbar da oggi è anche un po casa tua grazie mille molto valentieri è stato un piacere ragazzi il piacere è tutto nostro.Luca cosa cambia della tua vita? Adesso che sai che...Mentre si parlava stavo pensando a tutti i server che ho che non hanno monitoring, una roba di vergogno, e poi devo pure fare finta di dire no no sì sì assolutamente, chi è che non ce l'ha? Però poi mi ricordo che...Io pensavo al mio side project dove il mio sistema di monitoring è la mia socia che usa il motore di booking che ho scritto io e quindi lei quando qualcosa si rompe tanto non ho bisogno di monitor, mi chiama dopo cinque minuti con una sfilsa di bestemmie.Poco synthetic monitoring.simpatico e tanto monitorizzato.Guarda, se vuoi lancio un guanto di sfida alla community che è uno dei progetti che avevo pensato di farlo in casa mia, quindi non so adesso fino a che punto lo porterò però sono interessato a farlo.Una certa persona che conosciamo, che è italiana anche lui, mi ha messo la pulce nell'orecchio, Luca, lo salutiamo? Ciao Luca! Ciao Luca, che tra l'altro ci sta ascoltando credo.Perfetto, lui mi ha messo la pulce nell'orecchio per il monitoraggio, l'osservazione del consumo di elettricità che ha in casa.Quindi ho fatto tutto il mio quadro elettrico nuovo apposta perché abbia i posti per poter mettere gli switch che prenderanno le informazioni e mi farò una dashboard di grafana che analizzerà tutto quanto e mi darà determinate informazioni quando passerò determinati threshold di consumo.Quindi se vedo che da una linea a distanza consumo più di quanto io mi aspetto, per esempio 1 kilowatt o 2 kilowatt, mi dovrà dire "guarda che nella stanza della cucina hai superato i 2 kilowatt, quindi attenzione! E ti stacca le prese magari! Mi stacca le prese! Ma non ti consuma energia! E qua c'è l'Eisenberg! Però secondo me è una delle cose più carine del mondo dell'usability, cioè il pensare che non è solo inerente al servizio server che stai facendo, l'applicazione web o quello che è, ma in verità è la capacità di osservare e avere informazioni da tutto quello che è intorno a te, che potrebbe essere anche una cosa stupidissima, un termometro digitale che ti dà le informazioni, che tu dici quando magari cala più di un tot di temperatura dammi l'informazione.Guarda mio fratello si è fatto un raspberry con un sensore, l'ha messo sullo stendino fuori dal balcone e si accende una lucina rossa in casa per avvisarli se piove oppure no, così deve stendere, deve risultare più observability di quello.In realtà qua ci sono due elementi, cioè da una parte il problema di family responsibility, perché in realtà il mio terrore fottuto nell'automatizzare, nell'osservare casa è che qualcosa vada storto e mia moglie si incazzi, perché finché è prodotto che si incazza o la delivery manager o comunque prodotto in azienda è una cosa che puoi gestire, se moglie, marito, compagna, compagno, compagni si incazzano soccaccia, cioè non è la stessa cosa di prodotto.E poi un'altra cosa sul fatto che io l'ho buttata la ridenda scherzando, consumo di energia e ti stacca la presa allo scaldabagno, per esempio, lo sto buttando così.In realtà è un argomento che non abbiamo avuto occasione di affrontare, ma secondo me merita una puntata a sé stante, il concetto di autosoluzione.Penso che sia uno degli elementi meno trattati in fase di essere io un problema, identifico il problema, è l'automatismo della soluzione è secondo me parte della svolta.Mi viene da pensare al mondo dei sistemi a controreazione che avevo studiato all'università quando feci ingegneria e secondo me appunto come topic questo può essere un topic interessante per un prossimo episodio quindi sentiti già preinvitato per un'altra birra virtuale.Parliamo di disaster recovery, a posto.Grazie, grazie di nuovo Giuliano, un abbraccio.Grazie a voi e grazie a tutti gli ascensatori.Grazie Luca, anche per te, mi raccomando riservati la mano, riposati, non lavorare, vai alle Maldive, stacca.Ma non dire...va beh.Non alle Maldive dai, vengo in Sardegna.Ma vieni a Barcellona, cioè io sono a Barcellona, c'è il sole, c'è il mare, c'è tutto quello che vuoi quindi.Avete nominato due posti dove mia moglie mi prenderebbe le orecchie, dice andiamo.tutte le volte che mi si dice Barcellona io penso mare e bò, vabbè sai, sì però sole, ambiente catalano, fumo buono, fumo buono, no scherzo a parte io non fumo, non sono neanche una persona che fumo, però se vuoi ce ne hai quanto ne vuoi.No, di Barcellona ricordo, di Barcellona mio fratello c'è abitato a lungo e ricordo, probabilmente questo pezzo lo tagliamo, c'è un circolo di skaters con lo skate park indoor dentro questo circoletto ed è, non so se lo conoscevo, non l'ho più ritrovato, era vicino al barrio gotico, ma un posto della madonna la birra tipo 2 euro entravi...- No lo conosco, lo conosco, sì sì, ci sono stato - Ci sono i bidoni di latta come tavoli, i pneumatici come sedie, è proprio un posto super bellissimo io non l'ho più trovato ed era un posto super serio - Ci sono, ci sono, ci sono anche...Se vengo a Barcellona allora ti chiamo e andiamo lì.Ma sai quanta gente che sta venendo a trovarmi? Spero che tutto questo viene tagliato.Sai quanta gente viene a trovarmi qua a Barcellona, ma anche di gente con cui lavoro, con le varie aziende con cui collaboriamo e tutto? Tutta gente che è venuta qua a Barcellona, che mi sono visto, mi sono preso un caffè, ovviamente non l'ho detto così, un po' magna, ragazzi, sono preso un caffè con uno di vostri competitor, però non voglio mentire, se passi per favore dimelo che assolutamente non solo il caffè ma anche il pranzo incluso.Bene, volentieri.Volentieri.Ok ragazzi un abbraccio alla prossima settimana.Ciao ciao.Ciao.Ciao ciao.
