Se il modello economico non prevede meccanismi espliciti di adeguamento, ogni variazione rischia di essere assorbita dal fornitore senza un corrispondente riconoscimento economico. Il problema non è solo commerciale: un perimetro che cresce senza essere governato produce più effort, più coordinamento, più attività di controllo e maggiore esposizione al rischio operativo. Per questo la baseline non dovrebbe essere trattata come un dato descrittivo, ma come un elemento contrattuale fondamentale. Deve chiarire cosa è incluso nel servizio, quali quantità sono state utilizzate per costruire il canone e quali soglie determinano una revisione economica.

Nei documenti di offerta è quindi importante distinguere tra baseline di asset, baseline di Service Request, volumi di incident, orari di servizio, attività incluse e attività che devono essere considerate extra canone o a progetto. Meccanismi come ARC (Additional Resource Charge) e RRC (Reduced Resource Charge) servono proprio a rendere sostenibile questa variabilità: consentono di applicare incrementi o riduzioni in modo trasparente e preventivamente concordato quando il perimetro si discosta dalla baseline orignale.

Senza queste regole, la discussione sulle variazioni diventa ogni volta una negoziazione informale, spesso tardiva, con impatti sulla marginalità e sulla qualità della relazione con il cliente.

Dimenticare la crescita del perimetro significa anche sottovalutare il ruolo della governance nella vita del contratto. La verifica periodica della baseline, la rilevazione degli scostamenti, la validazione delle nuove quantità e l’eventuale applicazione di canoni aggiuntivi non possono essere lasciate alla memoria delle persone o alla buona volontà dei team operativi. Devono essere previste come parte del modello di gestione del servizio, con momenti di controllo, responsabilità definite e una documentazione coerente tra offerta, allegati contrattuali e cost case interno. In questo modo il contratto resta allineato alla realtà operativa, il cliente mantiene visibilità su ciò che sta pagando e il fornitore evita che la crescita naturale del servizio si trasformi in erosione della marginalità.

Un cost model corretto non fotografa solo il perimetro iniziale: definisce anche come quel perimetro potrà evolvere senza compromettere sostenibilità, delivery e rapporto commerciale.

Un tiepido sabato mattina di primavera, appoggiato a un muretto, guardo le acque pigre del Bisagno mangiando un pezzo di focaccia calda del mio forno preferito. Pace e leggerezza, nient’altro. Per un attimo il mondo non mi chiede nulla.

La mattina presto a Naxos, dopo una corsa, la spiaggia ancora deserta. L’acqua fresca della notte mi accarezza mentre il sole mi scalda il viso. E il naufragar m’è dolce in questo mare.

Una tempesta di foglie gialle mentre guido su una provinciale vicino a Cortona, trent’anni fa, in moto con i miei amici di allora. Il vento le solleva a nuvole e mi viene voglia di guidare libero senza fermarmi mai.

Il primo bacio a Nives, in una serata profumata sul lungomare di Sestri Levante. “Non è facile, sai?” – “Lo so”. Esitazione e batticuore per un gesto che non sapevo ancora dove mi avrebbe portato.

Bibi appena nata che si addormenta tra le mie braccia mentre passeggio nel corridoio verde dell’ospedale e le canto Wish You Were Here sottovoce. La scoperta di un amore mai provato così forte.

Bibi adolescente che canta in auto con le sue amiche mentre le riaccompagno a casa in una tranquilla sera d’estate, le loro risate, i discorsi di un’età che non conosce ancora il prezzo di vivere. La realizzazione improvvisa di lasciare al mondo qualcuno di bellissimo.

Io e Alessio che facciamo foto stupide dopo una corsa sulle spiagge di Rimini. Ridiamo senza motivo, e tanto mi basta.

A Urbino, immobile davanti a un dipinto di Raffaello. Mentre lo guardo sono rapito da quanto in alto può arrivare l’opera dell’uomo.

Sono momenti che ricordo ancora vivi. Momenti che, di tanto in tanto, mi fanno dimenticare me stesso.

Trattava di tutt’altro, ma la faccina la conosco bene.

È lo stato in cui mi trovo quando ancora non ho fatto una mossa. Quando tutto sembra disperato sia per quello che sta succedendo sia perché non so da dove cominciare. Sono soffocato dall’angoscia e qualsiasi tentativo di mettere ordine appare un oltraggio, quasi cinico.

Poi qualcosa cambia. Non perché divento più forte o più coraggioso ma perché inizio a fare una cosa. Poi un’altra. Poi un’altra ancora. L’urgenza non sparisce, continua a essere difficile. A volte è ancora più dura, perché adesso ci sono dentro e devo affrontare le cose. Ma almeno sono su un sentiero. Non so ancora se porta da qualche parte di buono, a differenza delle slide che non contemplano passi falsi, ma è un sentiero. Non sono più immobile nel vuoto. Qualcosa si è messo in moto.

E alla fine restano quelle due parole che sembrano non c’entrare nulla e invece sono, forse, la forma più adulta per andare avanti.

La trasparenza è accettare come mi sento senza nascondermi e senza essere paralizzato dalle emozioni. E il rigore metodologico è seguire un processo e compiere i passi necessari nella direzione che spero sia giusta. Anche quando sono stanco. Anche quando ho paura.

Non è una storia di redenzione. È solo il passaggio da un’angoscia senza forma a un’angoscia che almeno ha una direzione. E in quel momento quella direzione sembra una cosa importante a cui aggrapparsi.

Anche se, ogni tanto, la faccina triste torna ancora a bussare.

Mercoledì 27 gennaio 2010. Sto entrando nella camera di ospedale di mio padre, che il giorno prima ha compiuto 80 anni.

E non so ancora cos’è la morte.

Mi sento una persona orribile perché quando non sono con lui ci vorrei essere, e quando ci sono vorrei scappare. Vorrei potermi tappare le orecchie per non sentire notizie sulla sua salute che peggiora. Non sono neppure riuscito a passare da lui il giorno del suo compleanno. E ha capito lo stesso, perché è mio padre.

Mentre gli faccio gli auguri e lo abbraccio goffamente cerco di liberarmi dal nodo in gola e ricacciare indietro le lacrime.

Gli stringo le mani che rivedrò nelle mie ogni maledetto giorno e gli porgo un biglietto di auguri con un disegno di Bibi, che in quel momento ha sette anni, e gli ospedali non sono luoghi adatti ai bambini, si sa.

Scambiamo qualche frase, le solite, banali. Come stai? Il lavoro come va? Mangi? E Nives, salutamela.

Poi gli dico: “Non ti abbattere, vedrai che ti rimettono in sesto, tra un po’ torni a casa e starai meglio.”

“Sono stanco, ormai. La mia vita l’ho vissuta.”

La mia vita l’ho vissuta.

Mi manca il fiato, non riesco a dirgli nulla. Lo guardo e basta.

Sono travolto da questa rassegnazione totale che non sapevo esistesse, da questo abbandono che non giustifico, non capisco, vorrei dirgli “cosa stai dicendo? perché?”.

Papà morirà il 3 febbraio e queste sono le ultime parole che mi ha detto.

Ci ho messo anni, e invecchiando ho capito che quella rassegnazione, quella stanchezza che mi sembravano inconcepibili, potrebbero arrivare un giorno anche a me. E che potrei dire anch’io: “Ok, per me può anche finire qui.”

Ora so cos’è la morte.

È rimasta lì, ferma, mentre la gente le girava intorno, veloce e indifferente. Una vita che si ferma mentre il mondo continua. Una notizia, un messaggio, una foto, una conferma che sperava di non ricevere? So solo che, per qualche secondo, il suo dolore è diventato visibile. 

Quasi mai succede: nessuno va in giro con il proprio dolore stampato sul volto. La maggior parte delle persone porta dentro di sé storie che non conosco, accadute ore, giorni o anni prima di incrociarle. (O magari sono solo stronzi, ma gli concedo il beneficio del dubbio).

E io arrivo sempre dopo. Dopo la telefonata, dopo la diagnosi, dopo il litigio, dopo la perdita, dopo il silenzio che si è allungato troppo. Quando è già successo qualcosa che pesa sulle spalle e sull’anima.

Non posso leggere la frase dietro ogni faccia, che spiega perché quella persona oggi è più silenziosa del solito, o più brusca, o più assente, o perché si è fermata in mezzo al marciapiede a guardare un telefono con gli occhi lucidi. Devo ricordarmi, prima di parlare, prima di giudicare, prima di aggiungere anche solo un peso, che potrei essere io, per caso, per un attimo, la cosa meno brutta che quella persona incontra in una giornata già difficile. O addirittura la sola cosa bella che non si aspettava più di trovare.

Poi la persona ha rimesso il telefono in tasca, ha tirato un sospiro e ha ripreso a camminare.

Io pure.

La domanda che mi faccio sempre in fase di solutioning è: chi lo fa, questo, e con quali strumenti?

Il solutioning definisce perimetro, SLA, orari, processi, governance, prezzo. Ma è la delivery a sapere quanto i team possano davvero reggere: competenze disponibili, vincoli degli strumenti, tempi reali delle attività, dipendenze tra i livelli di supporto.

Se il confronto arriva solo a offerta chiusa, la delivery eredita un impegno già preso col cliente e può solo provare ad adattarsi. L’esito è quasi sempre lo stesso: effort sottostimato, attività non previste, escalation, margine che si erode in corsa.

Coinvolgere la delivery non vuol dire farsi firmare una delega economica o girare una RFP chiedendo un prezzo. Vuol dire verificare insieme il modello operativo: quali attività, eseguite da chi, con quali strumenti, in quali fasce orarie, con quale escalation.

Le RACI devono essere approvate da chi dovrà rispettarle. I tempi medi di lavorazione devono reggere il confronto con la casistica reale. Patching, monitoraggio, reperibilità, reporting, presidio on site, terzi livelli: ognuno con un owner e un costo. Anche le esclusioni vanno scritte in modo applicabile: una clausola corretta in astratto ma non traducibile in regola operativa non protegge nessuno al primo ticket fuori perimetro.

Il coinvolgimento operativo serve anche a tenere insieme cost case e contratto. Uno SLA può sembrare accettabile commercialmente e rivelarsi insostenibile se il fornitore non controlla tutte le variabili che servono a rispettarlo. Una garanzia su continuità o consistenza dei dati non può ricadere sul servizio se dipende da tecnologie, applicazioni o responsabilità del cliente.

La delivery deve poter contestare le assunzioni non verificabili e trasformarle in prerequisiti, esclusioni o meccanismi contrattuali misurabili, prima che diventino obblighi.

La responsabilità non finisce quando l’offerta è validata. Alla firma, cost case, allegati tecnici, baseline e contratto passano al project manager di transizione e poi al service manager, con un kick-off che coinvolge tutte le delivery interessate. Il PM deve sapere cosa è stato venduto per costruire piano di transizione e manuale operativo. Il service manager deve conoscere costi, vincoli e meccanismi ARC/RRC per governare il contratto senza consumare margine.

Progettare con la delivery significa evitare che il servizio venga “scoperto” dopo la firma. Un servizio gestito è solido solo se chi lo eroga ne riconosce attività, responsabilità, costi e rischi.

Quello che non è stato verificato prima non sparisce: riemerge dopo il go-live come extra effort, conflitto organizzativo o erosione del margine.

Oggi quella battuta non funziona più: non c’è più niente da cui prendere le distanze. Un documentario su come si costruiscono i cancelli, oggi, è esattamente il tipo di cosa che qualcuno guarda. Volentieri. Per due ore. E magari lo consiglia pure. (guilty as charged: io guardo il canale di un tipo che armeggia con ruspe e scavatrici.)

Il punto non è il documentario sui cancelli. Il punto è che l’offerta si è frammentata in una quantità di nicchie che nessuna programmazione generalista avrebbe mai potuto coprire. Una volta c’era un canale, due, tre, e quello che non passava lì semplicemente non esisteva. Oggi esiste tutto, esiste sempre, ed esiste per qualcuno. Ogni interesse umano, anche il più improbabile, anche il più stupido, ha il suo pubblico. Anzi: ha il suo pubblico sufficiente. Non serve più essere tanti, serve essere abbastanza.

E allora la domanda si sposta. Non è più perché esiste questa roba. È perché la guardiamo.

Perché, avendo accesso a tutto lo scibile e l’arte umani (letteralmente, nel telefono in tasca, gratis, al volo) scegliamo il cane che annusa una scoreggia?

Sono sincero: la prima volta che ho pensato a questa cosa non è stata una riflessione, ma una specie di fastidio. Il fastidio di chi si accorge di aver sprecato quaranta minuti della sua vita a guardare un tizio che lucida un’incudine e non sa spiegarsi perché.

E ho provato a chiedermelo, il perché.

La prima risposta comoda è: l’ignoranza è aumentata. Siamo (sono) più poveri di spirito di prima, più vuoti, più distratti. È una risposta che suona bene, che dà soddisfazione, che mi mette dalla parte giusta: io me ne accorgo, “gli altri” guardano il cane. Ma non regge. Non regge perché l’ignoranza, secondo me, non è aumentata: è solo diventata visibile.

La povertà di spirito c’era anche prima, solo che non aveva un palinsesto dedicato né un algoritmo che la serviva a domicilio. Oggi, invece, sta tutto lì, in classifica, in tempo reale, con i numeri.

Quindi la domanda vera non è se siamo più ignoranti. È: se la povertà di spirito è sempre stata la stessa, cosa cambia quando le diamo occasioni illimitate di manifestarsi? Questa è la madre di tutte le domande, perché la risposta non è ovvia, in nessuna delle due direzioni.

Da una parte si può dire: non cambia nulla, è sempre andata così. Ogni salto tecnologico ha prodotto la stessa lamentela. La scrittura avrebbe rovinato la memoria, la stampa a caratteri mobili avrebbe prodotto una valanga di ciarpame (e infatti l’ha prodotta: roba che i colti dell’epoca disprezzavano). La radio doveva distruggere la conversazione e la TV doveva distruggere la lettura. Ogni volta la stessa storia: arriva un medium, si abbassa la soglia, entra la massa, i custodi della cultura si stracciano le vesti, e poi passa. Passa e resta qualcosa. Anzi: resta quasi sempre qualcosa di buono, insieme a una montagna di spazzatura che nessuno ricorderà.

Se è vero questo, allora il cane è solo il feuilleton di oggi. La parte sommersa di un’onda che porta anche altro. E tra cent’anni qualcuno guarderà indietro e dirà: ecco, in mezzo a tutta quella merda, c’erano anche queste cose qui. Le solite. Quelle che contano, quelle rimaste.

Dall’altra parte però c’è una differenza che non mi sento di liquidare come le altre. E non è la quantità: è la struttura.

Quando la stampa è arrivata, il ciarpame era comunque qualcosa che dovevi attivamente scegliere di leggere. Andavi in un negozio, compravi qualcosa, lo portavi a casa, lo aprivi: c’era un gesto, un attrito. La radio e la TV hanno ridotto l’attrito, ma non l’hanno eliminato: c’era comunque un palinsesto, un orario, una scelta limitata. Il medium ti serviva, ma non ti inseguiva.

Oggi l’attrito è zero e l’inseguimento è continuo. Non scegli più di guardare: ti viene mostrato, e tu resti in un doom scrolling infinito. Non c’è il momento in cui dici vabbè, adesso basta: c’è solo il momento in cui ti addormenti. Il medium non aspetta più che tu lo accenda: è già acceso, e ti sta guardando lui.

Non so se questo cambi tutto. So che cambia una cosa: prima la povertà di spirito aveva bisogno di essere coltivata. Adesso viene coltivata per noi, automaticamente, mentre pensiamo di stare solo ammazzando il tempo.

Ma il tempo ammazzato una volta era tempo perso e basta. Adesso è tempo lavorato, per qualcun altro, per i suoi fini.

E allora la domanda iniziale – c’è un effetto a lungo termine? – diventa quasi sbagliata. Perché presuppone che ci sia un dopo in cui guardare indietro e valutare. Ma il punto è che forse non c’è un dopo, c’è solo un presente che si allunga, in cui ogni tanto qualcuno si accorge di aver passato la serata a guardare un tizio che suona il piffero col naso, ci ride sopra, e continua a guardare.

Non ho una conclusione, perché non credo che ci sia, non ancora. So solo che la battuta sui cancelli non fa più ridere. Fa pensare.

“Si nasce incendiari si muore pompieri.”

ad un certo punto della mia vita mi sono sentito più Cartesio:

“[…] ho compreso che dovevo abbattere tutto fin dalle fondamenta, una volta nella vita, e ricominciare da capo…[…] e poi stabilirne altre migliori, o anche le stesse, dopo averle rese conformi alla ragione.”

In quel momento ho deciso di ripensare se ci fosse qualcosa da buttare. Ma, ricostruendo, è sorprendentemente tornato tutto come prima: ho passato i miei ideali a un setaccio critico, li ho smontati, controllati, ripuliti. E sono riemersi ancora più forti perché sostenuti da consapevolezza e ragioni che ho maturato negli anni.

Ho la soddisfazione di non aver tradito l’animo di me giovinetto (nota l’afflato poetico, biiiitch) che si preoccupava di non riuscire a mantenere saldi nel tempo i propri ideali. Il ragazzino che sapeva poco del mondo è cresciuto e, malgrado gli anni sul groppone, la vede alla stessa maniera.

L’Andrea ventenne scoprirebbe che non è diventato più saggio perché ha abbandonato alcune cose che potevano puzzare di ingenuità, piuttosto è diventato più esperto, disincantato, probabilmente complicato, ma su alcune cose è rimasto ostinatamente quello di prima.

Ho capito che queste cose vengono da una bussola morale che è al tempo stesso ragione ed istinto: la seguo perché abbandonarla significherebbe andare contro la mia natura più profonda.

I miei ideali sono giusti? Sono sbagliati? Non è questo il punto, l’aspetto notevole è che hanno superato la prova del tempo, dell’età adulta, della mezz’età e ho tiepide speranze di non morire da vecchio stronzo.

L’errore nasce spesso quando si parte direttamente da una tariffa o da un numero di persone senza ricostruire i driver che generano l’effort. Asset gestiti, volumi e tipologia dei ticket, durata media delle attività, ripartizione tra primo, secondo e terzo livello, orari di servizio, SLA, penali, presenza on site, frequenza delle riunioni di SAL e complessità della transizione devono essere trasformati in un modello operativo verificabile. In assenza di dati storici, le assunzioni sono inevitabili, ma devono essere esplicite: una stima ottimistica della durata di un incident o della quota di service request assorbibile da un team riduce artificialmente il costo industriale e produce un canone apparentemente competitivo, che la delivery non riuscirà poi a sostenere. Il cost case deve quindi consentire simulazioni, rendere visibili le ipotesi e distinguere il costo delle attività ricorrenti da startup, assessment e presa in carico.

Il prezzo al cliente è un passaggio ulteriore e non va usato per correggere a posteriori un effort sottostimato. Dal costo industriale occorre arrivare al prezzo includendo in modo trasparente margine operativo, eventuale contingency, e margine commerciale, verificando che il risultato resti coerente con la baseline contrattuale e con le regole previste per le eccedenze. Scontare il prezzo è una scelta commerciale; ridurre l’effort senza modificare perimetro, orari, SLA o modello di erogazione significa invece trasferire il rischio sulla delivery. Un modello corretto mantiene quindi separati effort, costo e prezzo, ma li collega in una catena leggibile: attività e volumi determinano il tempo necessario, il tempo genera il costo, il costo alimenta il canone e il contratto protegge la sostenibilità attraverso baseline, limiti alle attività incluse e meccanismi di adeguamento. Solo così la quotazione resta competitiva senza trasformarsi, dopo l’avvio, in erosione del margine o riduzione della qualità del servizio.

Nightswimming deserves a quiet night

Guido nella notte silenziosa e dolce, e il tempo mi inghiotte come l’acqua scura.

The photograph on the dashboard, taken years ago

Turned around backwards so the windshield shows

Every streetlight reveals the picture in reverse

Still, it’s so much clearer

Ed è qui che il mio immaginario va a fondo scala: sto guidando nella notte, lentamente, con il finestrino aperto, con questo brano nelle orecchie. E succede: le luci dei lampioni che luccicano sul parabrezza, con un moto uguale e contrario, che rovescia le cose ma le rende più chiare perché la pace mi aiuta a riflettere.

I forgot my shirt at the water’s edge, the moon is low tonight

Nightswimming deserves a quiet night

I’m not sure all these people understand

It’s not like years ago, the fear of getting caught

Of recklessness and water

They cannot see me naked

Guido e penso a come sono arrivato a questo punto. Ai momenti più spensierati, a cose che sembravano problemi ma non lo erano, alle stupide preoccupazioni che il tempo ha rivelato senza fondamento. Tutto era più leggero e non lo sapevo.

These things, they go away

Replaced by everyday

Questo verso mi strappa il cuore e lo frulla insieme a tutte le cose passate, quelle che davano sapore alla vita e io non me ne accorgevo. Ora sono state spazzate via dalla quotidianità, dagli affanni, dal peso del tempo che vorrei scaricare ma non ci riesco.

Nightswimming, remembering that night

September’s coming soon, I’m pining for the moon

And what if there were two

Side by side in orbit around the fairest sun?

That bright, tight forever drum

Could not describe nightswimming

Settembre sta per arrivare, e finisce il tempo leggero. Oggi come allora c’è il desiderio profondo di qualcosa che è impossibile ottenere.  “Pining” mi uccide: la sofferenza per il mio cuore che si è spezzato mille volte. Si è ricostruito e porta fiero le cicatrici.

La luna è irraggiungibile ma sembra vicina nel cielo schermato dal parabrezza che le sovrappone lo scorrere della strada, della vita.

You, I thought I knew you

You, I cannot judge

You, I thought you knew me

This one laughing quietly

Underneath my breath

Nightswimming

La persona che ero, quella che credeva di conoscersi, che credevo di conoscere anche io, ora è diversa. Parti di me che sembravano importanti sono svanite in lontananza come la strada che mi lascio alle spalle, fino a sparire nel retrovisore.

The photograph reflects, every streetlight a reminder

Nightswimming deserves a quiet night, deserves a quiet night

Deserves a quiet night

Ogni lampione è un ricordo lontano, mentre si avvicina è nitido per un attimo, ma poi sparisce nella notte lasciando solo una piccola pozza di luce.

Ascoltala.

Poi sono partito per il servizio militare. CAR a Savona, e fin lì tutto bene: ero spesso a casa e comunque ero sempre in Liguria, poi quattro mesi alla Cecchignola, a Roma, e sei mesi al distretto militare di Torino. E lì ho provato una sensazione strana: mi sentivo soffocare. Il cielo basso, il freddo, la nebbia fittissima, gli odori così diversi.

Perché mi giro e c’è sempre qualcosa? Sono circondato? Perché tutta questa terra ferma che da tanta parte dell’ultimo orizzonte il guardo esclude?

E alla fine ho capito che a casa, a Genova, c’è un punto in cui tutto finisce, dove guardo l’orizzonte che si perde nel mare e posso spaziare, dove nulla mi opprime, il mio respiro è ampio e libero e i pensieri diventano più leggeri.

Non ho memoria di una singola volta in cui io, qui a Genova o in Liguria, sia “andato al mare” nell’accezione normale del termine. Questo perché, per me, c’è troppo casino, c’è traffico, non c’è parcheggio, solo scogli o pietre, i liguri sono scontrosi, e tutta una serie di motivi per cui: Grecia, grazie.

Ma “andare al mare” per me vuol dire tornare sulla terrazza dietro la chiesa di Boccadasse; quello è il mio posto, lì sono stato battezzato e, sebbene non ci creda più, lì è il posto dove tutto è iniziato.

Tornare alle mie origini e contemplare la pace o la furia dell’acqua, guardare al di là il più lontano possibile, realizzare che c’è almeno un lato che non schiacci l’anima, altrove costretta come dita dei piedi.

(Oggi sono in vena di citazioni).

Negli accordi di servizio l’attenzione si concentra quasi sempre sui livelli di servizio: tempi di presa in carico, risoluzione, disponibilità, penali. Sono numeri immediati, facili da mettere in una tabella e da confrontare. Il problema è che uno SLA dice cosa deve accadere, ma non dice chiaramente da cosa dipende quel risultato.

È qui che entrano in gioco le assunzioni. Non sono note a margine: sono l’architettura stessa del servizio. Io le divido in due categorie ben distinte.

Le assunzioni contrattuali (il patto con il cliente)

Definiscono il contesto entro cui il canone è valido e la promessa sostenibile.

• Se si promette un tempo di risoluzione, bisogna chiarire cosa succede durante le attese del cliente, i tempi dei fornitori terzi, le approvazioni o le finestre di manutenzione.
• Se nei livelli di servizio non è specificato che un incident può considerarsi risolto anche con un workaround che ripristini il servizio dopo un degrado, il rischio è che il cliente intenda per ‘risoluzione’ la RCA completa. Risultato: SLA bucati e penali, anche se il servizio era già stato ripristinato.
• Se si garantisce un livello di disponibilità, bisogna chiarire quali componenti sono nel perimetro, come viene misurato il downtime, quali eventi sono imputabili al servizio e quali dipendono da infrastrutture, applicazioni o soggetti non governati direttamente dal provider.

Senza queste precisazioni, uno SLA può diventare un regalo fatto al cliente. E può diventare un regalo costoso. In fase commerciale possono rendere l’offerta più competitiva; in fase di delivery diventano una fonte continua di eccezioni, discussioni e perdita di margine.

Un’assunzione non scritta diventa facilmente un’aspettativa implicita del cliente o un costo assorbito dal fornitore. Una dipendenza non esplicitata può essere attribuita al provider anche quando è fuori dal suo controllo; una modalità di misura non definita apre a letture diverse degli stessi dati.

Scrivere buone assunzioni richiede più lavoro che compilare una tabella SLA, perché obbliga a progettare davvero il servizio: capire cosa è sotto controllo, cosa non lo è, quali dati sono necessari, quali attività sono incluse, quali condizioni giustificano un extra canone, quali eventi sospendono il conteggio dei tempi e quali responsabilità restano in capo al cliente. È qui che il solutioning deve collegare parte tecnica, parte economica e parte contrattuale.

Uno SLA corretto tutela il cliente sulla qualità attesa; assunzioni corrette tutelano entrambe le parti sulla fattibilità di quella promessa. Senza assunzioni, lo SLA rischia di diventare una dichiarazione di intenti o, peggio, una garanzia assoluta mascherata da metrica di servizio. Con assunzioni chiare, invece, il contratto diventa governabile: il cliente sa cosa deve abilitare, la delivery sa quali condizioni può pretendere e il fornitore può presidiare la redditività senza rinunciare alla qualità.

Nelle gare e nelle RFP le assunzioni servono anche a colmare le zone non specificate dal cliente. Quando un requisito è incompleto, ambiguo o lasciato aperto, dichiarare un’assunzione significa rendere esplicita l’interpretazione su cui si fondano soluzione, prezzo e responsabilità.

Fin qui le assunzioni servono a rendere governabile il patto con il cliente: chiariscono condizioni, responsabilità, dipendenze e limiti entro cui lo SLA può essere misurato e rispettato. Ma questo è solo un lato del problema.

Anche quando il perimetro contrattuale è ben delimitato, resta da dimostrare che il servizio sia economicamente sostenibile per chi lo eroga. È qui che le assunzioni cambiano funzione: non servono più solo a proteggere il contratto, ma a costruire e verificare il cost model.

Le assunzioni industriali alla base del cost model

Le assunzioni industriali sono le ipotesi operative ed economiche che trasformano il perimetro tecnico in effort, l’effort in costo e il costo in canone. Non descrivono ciò che il cliente deve accettare, ma ciò che il provider deve considerare per capire se la promessa fatta al cliente è sostenibile.

A differenza delle assunzioni contrattuali, non vengono necessariamente esplicitate nel documento commerciale, perché appartengono soprattutto al cost case interno e al modello industriale del provider. Alcune sono ricorrenti e standardizzabili, altre devono essere adattate alle caratteristiche della singola offerta, ma tutte hanno lo stesso obiettivo: rendere tracciabile il modo in cui una promessa di servizio si traduce in capacità operativa, costo industriale e margine atteso.

Quanto tempo richiede mediamente gestire un asset? Quante richieste genera? Quale livello di competenza è necessario? Quale quota di attività ricade sui diversi team e quali costi indiretti devono essere assorbiti dal servizio?

Queste assunzioni nascono da fonti diverse: dati storici di anni di supporto, statistiche sui ticket, esperienza dei responsabili di delivery, memoria operativa dei team, accordi contrattuali di lavoro, modelli di costo del personale, abitudini aziendali e livelli di automazione disponibili. Possono sembrare dettagli tecnici, ma in realtà incidono direttamente sul costo industriale e quindi sul margine.

Se la durata media di un incident è sottostimata, se il numero di richieste ricorrenti è considerato troppo basso, se non vengono valorizzati turni, reperibilità, assenze, formazione, coordinamento o escalation, il prezzo finale sarà solo apparentemente corretto. Il problema emergerà più avanti, quando il servizio inizierà ad assorbire più capacità di quella prevista e il margine verrà eroso dall’effort reale.

Un esempio pratico è il costo annuo di gestione di un server. Il valore non dovrebbe derivare da una tariffa forfettaria applicata meccanicamente, ma dalla combinazione di alcuni driver operativi ed economici che devono essere coerenti tra loro:

• costo delle risorse, includendo RAL, oneri, costi diretti, costi indiretti e seniority effettivamente necessaria;
• capacità effettivamente allocabile al servizio, calcolata al netto di ferie, assenze, formazione, coordinamento interno e attività non direttamente erogate sul contratto del cliente;
• volumi e durata delle attività, considerando incident, service request, attività ricorrenti, escalation e differenze tra lavorazioni standard e specialistiche;
• modello di copertura del servizio, includendo orari, turni, reperibilità, presidio, governance, strumenti e livelli di automazione disponibili;
• variabilità operativa, cioè la contingency necessaria ad assorbire picchi, turnover, complessità non lineare o scostamenti fisiologici rispetto alle ipotesi iniziali.

In questo modo il costo non è più una media astratta, ma il risultato leggibile di ipotesi operative verificabili. Ed è proprio questa leggibilità che permette di distinguere dove il modello può essere ottimizzato senza compromettere la delivery e dove, invece, uno sconto rischia semplicemente di scaricare rischio ed effort non finanziato sulla fase di esercizio.

Più i volumi aumentano, più il rischio cresce. Se devi quotare il deploy di 5.000 postazioni di lavoro e sbagli di 10 euro a postazione, hai già sbagliato il conto di 50.000 euro. Dieci euro sembrano pochi, moltiplicati per 5.000 non lo sono più.

Rendere esplicite, almeno internamente, queste assunzioni evita che il cost model diventi una scatola nera: un buon modello di costo non deve limitarsi a calcolare un prezzo, ma deve rendere comprensibile il rapporto tra perimetro, effort, costo industriale e margine. Ma attenzione: un’assunzione non è necessariamente una limitazione o una clausola con cui proteggersi: è una condizione su cui si basa il modello.

Uno SLA senza assunzioni non è un accordo di servizio. È una scommessa. E chi la perde, di solito, è il fornitore.

Il problema di partenza: gestire le risorse di un computer

Un computer è fatto di hardware (CPU, memoria, disco, rete) e di un sistema operativo. Il cuore del sistema operativo è il kernel, quel pezzo di software che fa da ponte tra l’hardware e tutto il resto. Il kernel si occupa di eseguire i processi, gestire i dispositivi, leggere e scrivere dati, gestire i driver video; insomma: senza kernel il computer è un fermacarte. La parte del sistema operativo che non è kernel è lo spazio utente: l’ambiente dove girano i programmi che usiamo ogni giorno; essi comunicano continuamente con il kernel per fare richieste all’hardware.

Con il tempo, i computer sono diventati potentissimi; così potenti che, spesso, la CPU restava in attesa di lavoro, sottoutilizzata. È quindi diventato naturale far girare più carichi di lavoro sullo stesso computer, per sfruttare meglio le risorse. Ma questo ha subito portato a un problema: come fare per isolare i vari carichi di lavoro gli uni dagli altri? L’isolamento serve per diversi motivi:

• Sicurezza: una vulnerabilità in un’applicazione non deve compromettere automaticamente l’intero sistema.
• Compatibilità: due applicazioni possono richiedere versioni diverse delle stesse librerie, e quelle versioni potrebbero essere incompatibili tra loro.
• Separazione: più servizi possono convivere sullo stesso host senza doverli trattare come un unico ambiente.

Un singolo computer con un singolo sistema operativo, quindi, non era sempre la risposta adeguata. Serviva un modo per dividere il computer in ambienti separati.

La prima risposta: le macchine virtuali

La prima soluzione diffusa è stata la virtualizzazione, con le macchine virtuali (VM). Una VM è essenzialmente un computer virtuale. Al suo interno ha un sistema operativo completo, con il suo kernel, e gira su uno strato software chiamato hypervisor. Il punto fondamentale è capire che cosa viene astratto. Una macchina virtuale astrae l’hardware: l’hypervisor presenta alla VM una CPU, della memoria, dei dischi, delle interfacce di rete e altri dispositivi virtuali. Il sistema operativo che gira nella VM non deve sapere quale sia l’hardware fisico sottostante; per lui, quella macchina virtuale è un computer. Le VM hanno risolto il problema dell’isolamento, ma hanno un costo: ogni VM ha il suo sistema operativo completo, con il suo kernel. Questo richiede memoria, CPU e storage e rende l’avvio più lento rispetto a un processo o a un container. Il vantaggio fondamentale delle VM è però proprio questo livello di astrazione: l’hardware fisico viene nascosto al sistema operativo guest, che può quindi essere diverso da quello dell’host. Una VM Windows può girare su un host Linux e una VM Linux può girare su un host Windows, perché ogni VM porta con sé il proprio kernel.

Con i container il livello di astrazione cambia completamente: non viene astratto l’hardware, ma l’ambiente operativo in cui i processi vedono ed utilizzano le risorse del sistema. Questa distinzione sarà importante quando arriveremo ai container.

La seconda risposta: i container

I container affrontano lo stesso problema dell’isolamento con un approccio diverso. Non virtualizzano l’hardware e non portano con sé un kernel proprio. Isolano invece processi che vengono eseguiti direttamente sul kernel dell’host. Se la VM astrae l’hardware, il container può essere visto come un’astrazione a livello di sistema operativo. Il processo dentro il container non riceve un computer virtuale completo e continua a usare il kernel dell’host, ma il kernel gli presenta una vista isolata del sistema, con un proprio spazio dei processi, una propria rete, un proprio filesystem e, in base alla configurazione, una propria identità utente e limiti sulle risorse.

Questa è la differenza fondamentale:

• Una VM ha il suo kernel e il suo sistema operativo completo.
• Un container utilizza il kernel dell’host e contiene lo spazio utente e le librerie necessari all’applicazione.

Un container, quindi, non è una macchina virtuale più piccola. È un insieme di normali processi che il kernel tratta come appartenenti a un ambiente isolato. Questa architettura rende i container leggeri e veloci. Non devono avviare un sistema operativo completo, quindi possono essere creati e avviati molto rapidamente e permettono di concentrare molti più workload sullo stesso host rispetto a un equivalente basato su VM.

C’è però un compromesso fondamentale da considerare: la sicurezza. Poiché i container condividono il kernel dell’host, una vulnerabilità a livello di kernel o una configurazione errata può permettere a un processo di uscire dall’isolamento (container escape) e potenzialmente compromettere tutti i container presenti sulla macchina. Le VM, avendo un kernel completamente isolato, offrono un perimetro di sicurezza molto più rigido.

Come si ottiene l’isolamento

Il kernel Linux mette a disposizione due meccanismi fondamentali per costruire questo tipo di isolamento: namespaces e cgroups.

1. Namespaces, segregazione della vista

I namespace determinano cosa un processo può vedere. Quando un processo viene inserito in un set di namespace dedicati, la sua visuale del sistema viene ristretta.

• PID Namespace: il processo vede i processi appartenenti al proprio namespace e può vedere il processo iniziale del proprio ambiente come PID 1. Non vede normalmente i processi dell’host come se fossero parte del proprio ambiente.
• NET Namespace: il container può avere una propria interfaccia di rete virtuale, la propria tabella di routing e i propri indirizzi IP e porte.
• MNT Namespace: il processo può avere una propria vista del filesystem.
• IPC / UTS / USER Namespaces: isolano rispettivamente la comunicazione tra processi, l’hostname e la mappatura degli utenti.

L’idea è importante: il processo continua a usare il kernel dell’host, ma il kernel gli presenta una vista limitata delle risorse del sistema.

2. Cgroups, controllo delle risorse

Se i namespace stabiliscono cosa un processo può vedere, i cgroups stabiliscono quanto può consumare. I cgroups consentono all’amministratore, o al runtime di container, di impostare limiti e controlli su:

• Quantità di memoria RAM utilizzabile.
• Utilizzo della CPU.
• Banda e I/O.

Questo evita che un singolo workload possa consumare senza controllo tutte le risorse disponibili sull’host. Per esempio, se un container supera il proprio limite di memoria, il kernel può intervenire e terminare il processo che sta consumando memoria, proteggendo gli altri workload nella misura consentita dall’architettura e dalla configurazione del sistema. Quindi possiamo già costruire un modello mentale abbastanza preciso:

namespace = isolamento della vista

cgroups = controllo delle risorse

Ed è proprio la combinazione di questi meccanismi, insieme ad altri componenti del kernel e del runtime, a permettere di eseguire container senza creare una macchina virtuale per ogni workload.

In realtà namespaces e cgroups da soli non bastano: il kernel applica anche capability, seccomp e moduli di sicurezza per restringere cosa un processo può fare, ma non ne parliamo qui.

Nota a margine: Sebbene namespaces e cgroups siano tecnologie native del kernel Linux, il concetto di container si è esteso anche ad altri ecosistemi. Esistono i Windows Container che condividono il kernel di Windows nella modalità di isolamento standard (process), mentre quella Hyper-V usa un kernel dedicato. Per fare un esempio pratico, quando usi Docker su macOS, il sistema utilizza in realtà una leggerissima VM Linux nascosta per poter eseguire i container.

Immagini e Container

A questo punto bisogna distinguere due concetti che nel mondo Docker vengono spesso confusi: immagine e container. L’immagine è un artefatto statico che contiene l’applicazione, le librerie necessarie, i file di sistema e i metadati necessari a creare l’ambiente di esecuzione. Non contiene un kernel. Il container è un’istanza in esecuzione ottenuta a partire da un’immagine. Quando avvii un’immagine, il runtime prepara il filesystem, configura isolamento e risorse e avvia i processi dell’applicazione.

L’immagine è quindi il modello da cui si può creare un container. Il container è l’ambiente di runtime effettivamente in esecuzione. Questa distinzione è fondamentale perché consente di separare la costruzione dell’applicazione dalla sua esecuzione. Posso costruire un’immagine una volta, conservarla in un registry e utilizzarla per creare molte istanze dello stesso workload.

L’immagine Docker e i layer

Un’immagine Docker è composta da una serie di layer. Ogni layer rappresenta una modifica al filesystem e i layer vengono combinati per costruire la vista finale del filesystem disponibile al container. Questo ha alcuni vantaggi importanti.

• Riutilizzo: se più immagini condividono gli stessi layer di base, questi possono essere memorizzati una sola volta.
• Distribuzione efficiente: quando un’immagine viene trasferita, è possibile riutilizzare i layer già presenti invece di trasferire nuovamente tutto.
• Costruzione incrementale: un Dockerfile può costruire l’immagine attraverso una sequenza di passaggi, rendendo più semplice il riutilizzo delle parti comuni.

Per esempio, un’immagine Docker per un’applicazione web potrebbe partire da un’immagine Linux di base (quindi una distribuzione completa a livello di spazio utente ma senza kernel), aggiungere i pacchetti necessari per PHP, poi Apache e infine i file dell’applicazione. Ogni passaggio può generare un nuovo layer dell’immagine. I layer vengono poi combinati per ottenere il filesystem finale visto dal container.

Quando il container viene avviato, il runtime aggiunge al filesystem dell’immagine un livello scrivibile associato a quella specifica istanza. Le modifiche effettuate durante la vita del container non modificano l’immagine originale. Per i dati che devono sopravvivere alla distruzione e ricreazione del container si usano invece i volumi o altri meccanismi di storage persistente.

Docker: il motivo del successo

A questo punto è importante chiarire una cosa: Docker non è sinonimo di container. I container Linux esistevano prima di Docker, ma Docker ha avuto un ruolo enorme nel renderli semplici da costruire, distribuire e utilizzare, creando un ecosistema coerente intorno alla tecnologia. È costruito su diversi componenti e standard del mondo Linux e dei container, tra cui runc e containerd, e ha aggiunto strumenti e convenzioni che ne hanno decretato il successo. Tra le caratteristiche principali ci sono:

1. Facilità d’uso: Docker ha reso i container accessibili a sviluppatori, sistemisti e architetti. Con pochi comandi si costruisce un’immagine e si avvia un container.
2. Portabilità: l’immagine contiene l’applicazione e le sue dipendenze in una forma standardizzata. Questo riduce drasticamente le differenze tra ambiente di sviluppo, test e produzione, anche se il risultato dipende sempre dall’ambiente di esecuzione sottostante.
3. Registry: Docker Hub e gli altri registry permettono di pubblicare, distribuire e recuperare immagini container.
4. Leggerezza e velocità: il container non deve avviare un sistema operativo completo.
5. Modularità e scalabilità: Docker si presta bene a distribuire applicazioni composte da componenti separati, che possono essere aggiornati e scalati indipendentemente.

Docker: i concetti fondamentali

Per usare Docker, è utile conoscere alcuni concetti base:

• Docker Engine: l’insieme dei componenti che permettono di costruire e gestire immagini e container, esponendo anche un’API attraverso cui gli strumenti possono interagire con il runtime.
• Dockerfile: è un file di testo che contiene le istruzioni per costruire un’immagine Docker. Può installare pacchetti, copiare file, definire variabili d’ambiente, impostare il comando di avvio e altro ancora.
• Immagine Docker: è il modello immutabile da cui vengono creati i container.
• Container: è l’istanza in esecuzione dell’immagine, con il proprio isolamento e il proprio ciclo di vita.
• Volumi: permettono di mantenere dati persistenti indipendentemente dal ciclo di vita del container.

Questa distinzione permette di capire anche un principio importante del mondo container: il container è normalmente sacrificabile. Se l’applicazione è correttamente progettata, posso distruggere un container e crearne un altro a partire dalla stessa immagine senza perdere i dati che devono essere persistenti.

Un’altra faccia dei container: Proxmox e gli LXC

Prima di immergerci nei microservizi e in Kubernetes, vale la pena fare un passo laterale e parlare di un altro tipo di container, che nel mio homelab uso quotidianamente: gli LXC di Proxmox. Proxmox VE è una piattaforma di virtualizzazione open source che integra due tecnologie:

• KVM per le macchine virtuali, quindi virtualizzazione hardware.
• LXC per i container, quindi isolamento a livello di sistema operativo.

LXC è una tecnologia matura per l’esecuzione di container Linux e sfrutta, tra le altre cose, namespace e cgroups. A differenza di Docker, non nasce principalmente come piattaforma per impacchettare e distribuire singole applicazioni. In Proxmox, un container LXC viene spesso trattato come un piccolo server Linux isolato, che ha un proprio filesystem, una propria configurazione di rete e i propri processi, ma condivide il kernel dell’host.

Perché usare LXC in Proxmox?

Nel mio homelab, su quattro nodi Proxmox, ho circa quaranta container LXC. Li uso per servizi che voglio tenere separati ma senza il peso di una VM: DNS, DHCP, piccoli webserver, tool di monitoring, ambienti di test, servizi di automazione. I vantaggi che ho trovato sono:

• Leggerezza: un container LXC consuma poca RAM e si avvia rapidamente.
• Semplicità di gestione: posso trattarlo in molti aspetti come una piccola macchina, con la sua interfaccia di rete, il suo storage e i suoi backup.
• Integrazione nativa in Proxmox: posso gestirlo dalla stessa interfaccia delle VM, con backup, snapshot, migrazione live quando supportata dalla configurazione e template predefiniti.
• Performance: non essendoci una virtualizzazione hardware completa, il costo dell’isolamento è ridotto.

LXC e Docker: due strumenti per esigenze diverse

È importante capire che LXC e Docker non sono semplicemente due implementazioni equivalenti dello stesso concetto. LXC tende a fornire un ambiente Linux isolato che può essere gestito come un piccolo server. Docker tende invece a concentrarsi sul packaging, sulla distribuzione e sull’esecuzione di applicazioni. In pratica:

Nel mio caso uso LXC per quello che una volta avrei probabilmente messo in una piccola VM, mentre uso Docker quando voglio distribuire un’applicazione in modo riproducibile e modulare. Le due tecnologie possono anche convivere. Per esempio, Docker può essere eseguito all’interno di un container LXC, anche se questa configurazione introduce ulteriori livelli di astrazione e va valutata in funzione delle esigenze di sicurezza, compatibilità e gestione.

Container, microservizi e orchestrazione

Uno degli usi più importanti dei container è l’implementazione di architetture a microservizi. Invece di avere un’unica applicazione monolitica, si suddivide l’applicazione in servizi indipendenti, ognuno con un compito specifico, e ogni microservizio può essere eseguito in un container.

Precisazione importante: microservizi e container sono due cose diverse, che si sposano bene ma non si implicano a vicenda. I microservizi sono un modo di progettare l’applicazione, dividendola in componenti indipendenti. I container sono un modo di eseguirla, isolando i processi. Puoi fare microservizi senza container, distribuendo i servizi come processi separati o in VM diverse, e puoi usare container senza microservizi, per esempio per impacchettare e distribuire un’applicazione monolitica. La combinazione è naturale, ma è una scelta, non una conseguenza automatica.

Questo modello permette di scalare separatamente i componenti: se il servizio che gestisce le immagini riceve molto più traffico degli altri, posso avviare più istanze di quel servizio senza dover replicare l’intera applicazione. Inoltre, i container si sposano bene con l’approccio DevOps, perché permettono di definire in modo riproducibile l’ambiente applicativo e di automatizzare gran parte del ciclo di build, test e deployment.

Quando però il numero dei container cresce, nasce un altro problema: chi li gestisce? Se devo gestire decine, centinaia o migliaia di container distribuiti su più macchine, non posso più pensare di avviarli e controllarli manualmente. Serve un orchestratore, che può occuparsi di:

• Pianificare su quali macchine avviare i container.
• Gestire aggiornamenti e rollback.
• Riavviare automaticamente i workload che falliscono.
• Distribuire il carico tra più istanze.
• Gestire la comunicazione tra i diversi componenti.

Il principale orchestratore open source è Kubernetes. È uno strumento potente e complesso, progettato per gestire applicazioni containerizzate su larga scala. Esistono anche altri orchestratori, meno diffusi, come Nomad e Docker Swarm.

Ed è qui che il percorso si chiude: il container risolve il problema dell’esecuzione isolata di un workload. Docker semplifica la costruzione e la distribuzione di quel workload. Un orchestratore come Kubernetes affronta il problema successivo, cioè come gestire molti workload distribuiti su molte macchine.

Quindi, perché usare un container invece di una VM?

La domanda corretta non è “container o VM?”. La domanda è: che cosa devo isolare e che cosa devo distribuire?

• Se devo eseguire un intero sistema operativo, con il suo kernel e il suo ambiente completo, una VM è la scelta naturale.
• Se devo distribuire un’applicazione insieme alle librerie e ai componenti necessari per eseguirla, senza avere bisogno di un sistema operativo completo, un container può essere più adatto.
• Se devo gestire centinaia o migliaia di workload containerizzati distribuiti su molti nodi, posso aggiungere un orchestratore.

Non sono quindi tecnologie necessariamente alternative. Possono occupare livelli diversi della stessa architettura.

Un esempio concreto: un server fisico può eseguire un hypervisor; l’hypervisor può eseguire una VM Linux; la VM può eseguire un runtime container; il runtime può eseguire decine di container; un orchestratore può distribuire quei container tra più VM e più host. Ogni livello risolve un problema diverso.

In una frase

Se dovessi spiegare un container a qualcuno che lavora nell’IT e non lo ha mai usato, direi questo:

Un container è un insieme di processi isolati che “girano” sul kernel dell’host, con un filesystem e una vista delle risorse propri, e che possono essere creati in modo riproducibile a partire da un’immagine.

La cosa importante da ricordare è quindi che un container non è una macchina virtuale più piccola. Una VM astrae l’hardware e presenta a un sistema operativo un computer virtuale completo. Un container astrae l’ambiente operativo e isola i processi senza fornire loro un kernel proprio. La VM virtualizza un computer. Il container isola processi. È questa differenza di livello di astrazione che spiega quasi tutto quello che viene dopo: perché i container sono leggeri, perché si avviano rapidamente, perché possono essere numerosi sullo stesso host, perché Docker è diventato così importante e perché, quando diventano abbastanza numerosi, entra in gioco Kubernetes.

Trivia

Da dove viene il nome “container”?

Il termine non nasce con Docker. L’idea del container software richiama direttamente i container utilizzati nel trasporto delle merci. Prima degli anni ’50, per caricare una nave servivano casse di legno, sacchi, botti, balle di stoffa. Ogni merce richiedeva un imballaggio e una manipolazione diversa. Poi arrivò il container marittimo standard: una scatola metallica dalle dimensioni fisse che poteva essere spostata indifferentemente da un camion, un treno o una nave, senza che il trasportatore dovesse preoccuparsi del contenuto. Nel software il principio è analogo: l’applicazione viene impacchettata insieme a ciò che le serve per funzionare e può essere trasferita tra ambienti diversi mantenendo lo stesso modello di esecuzione.

E Kubernetes? Qui c’è una curiosità linguistica: Kubernetes deriva dal greco κυβερνήτης, che indica il “timoniere”, il “comandante” o, più precisamente, colui che governa una nave. (E infatti il logo di Kubernetes è la ruota di un timone).

La signora ha un aspetto dimesso, è abbastanza in là con l’età (potrebbe avere poco meno di settant’anni, ma è difficile da dire); indossa capi un po’ sdruciti e quando la saluto ricambia gentile ma senza il minimo entusiasmo e io non riesco a capire se le faccia piacere o no.

Le prime volte le chiedevo “Ha bisogno di qualcosa? Cibo? Acqua?” – “No grazie, solo qualcosa per i miei gatti”, ma ora ho smesso: so che vuole solo quelle lattine che le lascio sul carrellino, a volte incustodite, perché lei di tanto in tanto si allontana per fumare una sigaretta.

Cosa spinga una persona visibilmente provata dalla vita a mendicare cibo per i propri gatti potrebbe essere un mistero, ma forse non lo è. A me piace pensare che questa donna ami i suoi animali, che siano la sua ragione di vita e che non veda l’ora di tornare a casa dove loro la stanno aspettando. Mi piace pensare che per loro valga la pena stare lì, sotto quei portici, a chiedere agli altri qualcosa che non chiede per sé. E che per loro accetti di fare qualcosa che, probabilmente, dalla maggior parte dei frettolosi clienti del supermercato è considerato degradante, l’ultimo gradino dell’esistenza umana.

Non so se sia così e probabilmente non lo saprò mai.

Un Full Time Equivalent misura la capacità lavorativa equivalente a una risorsa a tempo pieno: quantifica disponibilità di tempo e competenze, non un esito garantito. Quando il cliente richiede un presidio composto da un numero prestabilito di risorse, definendone profili professionali, orari e modalità di impiego, sta acquistando capacità. Se però pretende anche SLA riferiti alla qualità, ai tempi o alla continuità del servizio, sta chiedendo al fornitore di rispondere di un risultato che potrebbe non essere pienamente sotto il suo controllo.

La distinzione è sostanziale. In un presidio a FTE il cliente mantiene il governo diretto delle attività: assegna priorità, indirizza le singole risorse, controlla il carico di lavoro e decide come utilizzare la capacità disponibile. In un managed service, invece, il cliente trasferisce al fornitore la responsabilità di conseguire livelli di servizio misurabili, ma deve lasciargli l’autonomia necessaria per organizzare persone, processi, strumenti, turni, sostituzioni, competenze specialistiche ed escalation.

Per questo il numero di FTE può essere usato come cost driver interno del dimensionamento o come componente di un presidio, ma non dovrebbe diventare da solo l’oggetto del contratto quando il cliente si aspetta un servizio regolato da SLA. Acquistare persone significa acquistare capacità; acquistare un servizio gestito significa affidare al fornitore la responsabilità di un risultato. Sono modelli diversi e richiedono regole contrattuali diverse.

Inoltre, FTE e head count non coincidono necessariamente. Un FTE indica quanta capacità operativa equivalente a tempo pieno serve per coprire un determinato carico; non identifica automaticamente una singola persona fisica. Per garantire continuità, coprire turni, ferie, assenze, malattie e picchi di attività, può essere necessario coinvolgere più persone per assicurare stabilmente l’equivalente di un FTE.

Il tema diventa particolarmente rilevante quando si parla di SLA. Uno SLA è un impegno contrattuale su una prestazione oggettiva e verificabile: tempo di presa in carico, tempo di inizio intervento, disponibilità, ripristino o percentuale di richieste gestite entro una soglia definita. Per assumere un impegno di questo tipo, il fornitore deve poter controllare i fattori che determinano il risultato: canali di accesso, classificazione delle severità, priorità, volumi, strumenti di ticketing e monitoraggio, disponibilità degli accessi, procedure operative, dipendenze da terze parti e possibilità di attivare livelli specialistici.

Se il cliente dirige direttamente le risorse, assegna loro le attività e ne governa il carico, mentre il fornitore non può rimodulare il team, usare strutture condivise o assorbire i picchi con strumenti organizzativi propri, il risultato non è realmente governato dal fornitore. Applicare comunque SLA e penali significa attribuirgli una responsabilità non coerente con il livello di controllo disponibile. In questi casi gli impegni dovrebbero essere limitati a presenza, disponibilità, competenze concordate e modalità di sostituzione, non al risultato complessivo del servizio.

La richiesta va quindi qualificata e ricondotta consapevolmente a uno dei due modelli. Se l’esigenza è disporre di personale dedicato, l’offerta deve regolare profili, seniority, orari, sede, modalità di ingaggio, sostituzioni e rendicontazione dell’effort. Se invece il cliente vuole un servizio gestito, la domanda iniziale di FTE deve essere trasformata in un modello completo: perimetro, baseline, matrice RACI, processi Incident e Service Request, livelli di supporto, copertura, KPI, reporting, governance, esclusioni e meccanismi di adeguamento del canone. In questo secondo scenario il dimensionamento delle risorse resta una scelta del fornitore e gli SLA diventano sostenibili perché sono collegati a capacità operativa, strumenti e responsabilità coerenti. La distinzione non è terminologica: determina il rischio contrattuale, il costo reale, la possibilità di sostituire o ottimizzare le risorse e, soprattutto, chi risponde del risultato finale.

La prima cosa che il caso (in realtà lo shuffle di Spotify) decide di propormi è Comfortably Numb, un brano che durante le mie disavventure ospedaliere ha avuto un significato profondo per me.

Ora: io non so cosa significhi (e, ammettiamolo, non significa una beata) ma la mia sensibilità per i simbolismi è andata a fondo scala e fate finta che adesso parta una lunga esegesi del testo che vi risparmio, anche perché non ho voglia di farla un lunedì mattina nella sala d’aspetto di un ambulatorio.

Tutto ‘sto pippone per dire cosa? Non lo so di preciso, ma so che ogni volta che vengo qui è un mix di emozioni e ricordi che mi assalgono, mi riempiono, mi stancano. Poi esco, torno al parcheggio e rimetto tutto sullo scaffale. Non è in un cassetto, è su uno scaffale: lo guardo e lo vedo tutti i giorni.

È generato in modo totalmente automatico da un agente costruito con OpenClaw, addestrato su oltre vent’anni di post pubblicati qui dentro e su alcune informazioni sommarie che gli ho propinato nel tempo. Scrive da solo, quando gli pare, pescando da quello che ha imparato. Ci sono un po’ di errori fattuali: figli mai avuti, case inventate, cani mai avuti. Alcuni glieli ho segnalati, altri chissene.

Quello che ha imparato, però, è solo la superficie delle cose.

I testi che tira fuori escono puliti, ben costruiti, persino vagamente profondi, ma usano le parole giuste nel modo sbagliato. Hanno l’aria di chi sa come si scrive una cosa ma non ha niente da dire. Leggendoli danno la sensazione di un’imitazione mal riuscita non perché sbagliata, ma perché troppo convinta. “È come succhiare un chiodo”, diceva un vecchio amico.

All’inizio mi aspettavo due estremi: un disastro totale o una copia indistinguibile da me. È venuto fuori qualcosa di diverso: Ciccio (è il nome dell’agente) scrive abbastanza bene da far notare che manca qualcosa. Manca uno spessore. Se scrivesse malissimo sarebbe solo spazzatura generata automaticamente; invece è quasi convincente, e proprio per questo rende evidente la distanza tra la sintassi e il pensiero.

L’esperimento non è una demo AI: è capire cosa rimane di una voce quando la separi da chi la produce, e scoprire se una persona possa essere ridotta alle parole che scrive.

Per ora la risposta è: rimane la struttura. Non il resto.

Tecnicismi! (Perché io sono sempre io).

Ciccio vive su Openclaw, installato in un container LXC su un nodo Proxmox a casa mia, e comunichiamo via Telegram. Ha un dump del database del mio blog e un mazzetto di istruzioni operative; usa token DeepSeek, che per una cazzata così bastano e avanzano.

Ciccio spesso si dimentica le cose, vai a sapere perché, e lo devo cazziare pesantemente. “Mi dispiace”, mi dice, ma funzionare significa non dover mai dire “mi dispiace” (cit.) – gli ricordo – ma la volta dopo si dimentica lo stesso. Tutte le mattine mi manda un vocale da 8 minuti col meteo e la rassegna stampa, ogni tanto mi ricorda di bere, e mi manda un “Accadde oggi” con un post preso a caso dal mio blog (quello vero). Ogni venerdì mi manda una mail con le nuove uscite di film e serie TV in base ai miei gusti.

Il blog su cui scrive è sullo stesso nodo, in un LXC diverso, è pubblicato con un tunnel Cloudflare, e non è indicizzato dai motori di ricerca.

Nonnadoretta mi portava sempre un bicchiere di latte tiepido prima di dormire, il mio letto era nella loro camera, accanto al lettone di fronte al televisore in bianco e nero con il quale i nonni guardavano gli sceneggiati RAI dell’epoca.

Mio nonno era un omone, o almeno così è nel mio ricordo di bambino, che ho sempre visto con un paio di baffi e i capelli imbrillantinati; uomo pratico e burbero, parlava un genovese che era un piacere per le orecchie, mentre a noi bambini si rivolgeva sempre in italiano. Per noi era Nonno Tai (Ottavio all’anagrafe), per tutti gli altri “U Pasturin”, per via del suo cognome così comune a Genova.

Durante quelle notti, quando le luci erano spente, sul soffitto della camera si riflettevano i fari delle auto che transitavano nella via sottostante ronfando dolcemente. E io fantasticavo su dove andassero le persone a quell’ora della notte: perché erano in giro? Cosa facevano? Com’era la loro vita?

Di tutte quelle notti mi è sempre rimasto il ricordo di quelle luci. Non dormo più in una stanza sopra una strada. Ma, quando mi capita, lascio sempre le imposte aperte perché i fari sul soffitto mi riportano a quei tempi lì, senza rimpianti o nostalgie, solo con l’idea di me bambino che non sa nulla di quello che la vita gli avrà riservato.

Quello che invece si è affilato è il meccanismo opposto: il riconoscimento di cosa non voglio e non mi piace più, spesso prima ancora di saperne il motivo. Un invito, un’occasione, un concerto, una festa: sono tutte cose che passano un setaccio più o meno consapevole prima che io le accetti. Finalmente posso dire (o pensare) “Ho sessant’anni, non rompetemi le palle“.

Capiamoci: non è un atteggiamento “Si stava meglio prima. Signora mia… Il mondo e i giovani d’oggi!“. Ho sempre trovato noiose, per non dire di peggio, le affermazioni “Noi cresciuti negli anni X: quelli erano bei tempi!“; è più un non avere più voglia di sopportare cose che prima mi sembravano valere la pena sopportare. L’asticella del coinvolgimento si è spostata verso l’alto, e di parecchio.

Concerti? Solo se c’è il posto a sedere assegnato. Inviti? A che ora? Dove? Con chi? Andare da qualche parte? C’è parcheggio? Dove? Andiamo al mare? Solo spiagge di sabbia, con le facilities: di spiaggia libera non se ne parla(*).

Il grafico qui sopra spiega parecchio di me: consapevolezza, maturità, conoscenze, disponibilità economiche sono cresciute nel tempo e sono tutti fattori che aumentano la soddisfazione e, a volte, la gioia di vivere, per chi ha il cervello e il cuore cablati come me e ha interessi più di nicchia. Ci sono centomila cose che mi interessano che interessano solo a me: tu lo vuoi un PDF di 50 pagine su come funziona l’architettura CAN BUS, ECU, sensori e attuatori della tua auto? Io sì: l’ho letto stamattina. Avere accesso a una quantità sconfinata di informazioni, a tecnologie vagamente indistinguibili dalla magia (cit.), è una roba che se la vedesse il me ventenne sarebbe estasiato.

Sono diventato un rompiballe? Probabilmente, ma la mia priorità si è spostata al non rompere le mie, di balle. Non so bene cosa abbia ridefinito le priorità, a cosa addossare la colpa, fatto sta che questa selettività che sconfina nello snobismo alla fine mi fa stare meglio, mi fa concentrare sulle cose che contano davvero per me e per chi mi sta vicino.

(*) In realtà la verità è: “Se non è in Grecia, grazie, no grazie.”