Ticket on Melabit

Cronaca di un disastro: come sopravvivere alla pagina bianca di WordPress

Wed, 22 Jan 2020 06:00:00 +0000

Questo non è un post adatto per chi si spaventa facilmente. Se siete ansiosi o deboli di cuore fatevi un favore e non continuate a leggere.

Premessa

Quando si verifica un disastro in ambito informatico (e non solo) la cosa più importante è non perdere mai la calma. E poi non bisogna avere fretta di rimettere le cose a posto, meglio riflettere prima di agire. Naturalmente avere un backup aggiornato a disposizione aiuta sempre moltissimo.

Tutte le volte che ho dovuto affrontare un disastro di tipo informatico – e fra casi personali, amici e conoscenti succede relativamente spesso – queste linee guida sono sempre state utilissime per risolvere il problema. L’ultima volta, però, una installazione di WordPress andata completamente in tilt ha messo a durissima prova la mia pazienza, oltre che le mie conoscenze tecniche. Ecco il racconto di quello che è successo.

Una giornata particolare

Oltre a questo blog, amministro da anni Il nostro CNR, un sito finalizzato alla discussione di tematiche relative al mondo del CNR e della ricerca in generale. Come melabit, anche Il nostro CNR è basato su WordPress. Il sito è piuttosto popolare, ha un discreto numero di visualizzazioni giornaliere, purtroppo sono sempre troppo pochi quelli che hanno la voglia e la pazienza di intervenire sul forum. Ma questo è un male tipico degli italiani, bravissimi a discutere animatamente al bar (verba volant…), ma molto meno propensi a mettere per iscritto quello che pensano, magari per paura di ritorsioni (…scripta manent ).

Poco prima di Natale Corrado Zunino, un giornalista di Repubblica sempre molto attento ai problemi della ricerca, pubblica un articolo in cui rivela che la procedura di elezione del rappresentante del personale nel CdA del CNR, conclusa un mese prima, potrebbe essere stata viziata da brogli. Il rappresentante eletto alla tornata precedente era stato una vera e propria spina nel fianco per la dirigenza del CNR e, non pago di quattro anni di fatiche e sacrifici anche personali, aveva deciso di ripresentarsi per un secondo mandato, con ottime possibilità di successo. Toglierlo di mezzo e sostituirlo con qualcuno meno rigido e competente era quasi una necessità.

Subito dopo aver letto l’articolo su Repubblica decido di diffonderlo tramite Il nostro CNR. Del resto, dopo la trasmissione di Report del marzo 2017 che ha rivelato la lunga serie di ruberie avvenute in un istituto del CNR (di certo non l’unico) e ancora di più dopo l’arresto dell’ex-direttore del CNR e dei suoi sodali, nel nostro ente l’interesse per queste vicende ripugnanti è altissimo.

– Fonte: Il Mattino, 20 novembre 2019.

Aggiornamenti inattesi

Entro quindi in quello che è un po’ il retrobottega del sito, la cosiddetta dashboard, l’interfaccia di gestione dei contenuti e delle funzionalità di WordPress, per scrivere un post sulla notizia di Repubblica e come al solito trovo alcuni plugin da aggiornare (i plugin sono dei pezzetti di codice che estendono le funzioni del sito). Succede praticamente ogni volta che accedo alla dashboard, e senza pensarci più di tanto clicco sul pulsante di aggiornamento. È una procedura assolutamente sicura e comunque, anche se uno dei plugin non dovesse più funzionare bloccando il resto del sistema, mi basterebbe modificare i nomi di qualche file per disattivarlo e recuperare la piena operatività del sito.

Questa volta invece, per qualche motivo incomprensibile, insieme all’aggiornamento dei plugin parte anche l’aggiornamento dell’intero codice di WordPress dalla versione 4.x all’ultima versione disponibile, la 5.qualcosa. Aggiornamento che per tanti motivi non volevo ancora fare, e soprattutto che non avrei mai fatto senza prima eseguire un backup affidabile di tutto il sito.

Non riesco ancora a capacitarmi di cosa possa essere successo, ma sono sicuro al 100% di non averlo fatto io stesso per errore. I pulsanti per aggiornare i plugin o il codice di WordPress sono ben distinti e non possono essere premuti contemporaneamente (lo vedete qui sotto), e poi ricordo benissimo di aver letto i messaggi che elencavano i plugin in corso di aggiornamento. Ma, quando alla fine del processo ho cliccato per tornare alla pagina principale, ho visto partire anche l’aggiornamento del codice di WordPress, e a quel punto non potevo più far niente per interromperlo.

È possibile che l’aggiornamento del codice sia partito da solo per qualche baco di Wordpress o di un plugin, del resto i bachi del software sono inevitabili. Una cosa seccante, ma ancora niente di preoccupante.

Un backup è per sempre?

Una volta concluso l’aggiornamento non voluto di WordPress, apro una nuova scheda del browser per controllare cos’è successo al sito. Compare solo una pagina completamente bianca. Il sito in effetti funziona ancora, ma non carica correttamente le pagine, e anche la dashboard appare completamente vuota. Per fortuna i file che costituiscono il sito ci sono ancora tutti, e anche il database usato da WordPress per memorizzare i dati variabili del sito è ancora al suo posto.

Un sito web dinamico come WordPress è costituito in genere da due componenti ben distinte: la prima comprende tutti file che costituiscono il sito web vero e proprio e che vengono modificati di rado, in particolare il codice WordPress e le personalizzazioni dell'utente, i plugin, i temi grafici, le immagini e tutti i documenti collegati alle pagine del sito (questa componente sarà denominata da ora in poi "file del sito" o semplicemente "sito"). La seconda componente è costituita da un database nel quale vengono memorizzati i dati variabili del sito, fra cui i testi degli articoli e degli interventi sul forum, le informazioni relative agli utenti registrati, i dati di accesso e moltissimo altro.

Quando succedono queste cose nel 99% dei casi la colpa è di qualche plugin che funziona male o non funziona affatto. Non c’era del resto da stupirsi, uno dei motivi per decidere di non aggiornare alla versione più recente di WordPress era legato proprio al fatto che almeno due plugin piuttosto importanti non erano ancora stati aggiornati per funzionare con le nuove versioni di WordPress e di PHP, il linguaggio di programmazione per il web con il quale è sviluppato WordPress.

Per correggere il problema della pagina bianca ci sono sostanzialmente due metodi: il primo richiede di disattivare i plugin uno ad uno, fino a scoprire quello che non funziona. Richiede ore ed ore di lavoro certosino e non avrebbe comunque risolto il problema dell’aggiornamento indesiderato del sito. Nonostante tutto, ho provato a disattivare i due, tre plugin più critici ma non cambiava niente.

Il secondo metodo prevede di ripristinare il sito da un backup recente e, in questo caso specifico, ha l’enorme vantaggio di poter tornare alla versione precedente di WordPress. E dato che il provider scelto per ospitare il sito fa un backup ogni ora, mi sembrava più che naturale scegliere la seconda soluzione.

Ed è qui che sono cominciati i guai.

Apro un ticket, cioè una richiesta di supporto tecnico, presso il provider e chiedo come ripristinare il sito da un backup eseguito intorno alle 9 del mattino, ora alla quale ero sicuro di non aver fatto ancora niente. Purtroppo non posso fare da solo, l’assistenza tecnica mi avvisa che la procedura di ripristino del database di WordPress deve essere effettuata dal provider, altrimenti dà errore.

Ovviamente li lascio fare, indicando il backup da ripristinare, il #687 eseguito alle 8:53, e ribadendo che volevo un ripristino totale, pulito, sia del sito che del database su cui si appoggia (la conversazione qui sotto, così come tutte le conversazioni successive, vanno lette dal basso verso l’alto).

Non funziona, anzi è peggio, i file del sito sembrano a posto, ma il database viene ripristinato solo in parte e quindi in pratica non serve a niente.

Intanto mi sono fatto dare l’intero backup del sito e del database delle ore 8:53 in formato standard e in questo backup il database sembra completo. Però ogni volta che l’assistenza tecnica prova a ripristinarlo la procedura fallisce. Secondo loro perché il database è corrotto, secondo me perché la loro procedura di ripristino non funziona bene.

Provo allora a chiedere il ripristino da un backup di un paio di giorni prima, ma non cambia niente. È già passato un giorno, il sito è ancora giù e io faccio una pessima figura con i colleghi che lo frequentano.

Andare sul cloud

A questo punto decido di lasciar perdere l’assistenza tecnica e di fare da solo, usando il backup del sito e del database che mi sono fatto dare per ricostruire il sito da zero. Potrei usare come al solito una macchina virtuale, dove installare una versione server di Linux con tutto quello che serve per far funzionare WordPress, ma questa volta preferisco di andare sul cloud in modo da poter lavorare, se serve (e servirà molto spesso!), anche da casa.

Scelgo AWS Cloud9 di Amazon, funziona bene, costa poco e mi sembra più affidabile di altri servizi che ho usato in passato, come Codeanywhere, Koding o Pilvia, che cambiano continuamente modello di business. Accedo al mio account e creo una nuova istanza di AWS Cloud9, dove installo la versione 18.04/Bionic LTS di Ubuntu Linux.¹

Potrei scegliere anche Amazon Linux, una versione di Linux specifica per Amazon AWS e basata su RedHat e CentOS, ma preferisco andare sul sicuro, in fondo Ubuntu deriva sempre da Debian, e nel mondo Linux non c’è niente di meglio di Debian.

Tralascio i dettagli dell’installazione di tutto quanto serve per far funzionare WordPress su Linux (ma se richiesto potrebbe essere argomento di un prossimo articolo). Il server web Apache, il linguaggio di programmazione PHP e il sistema di database relazionale MariaDB,² sono già installati di default in Ubuntu LTS, si tratta solo di configurare opportunamente tutto per girare su AWS Cloud9 e di creare il database per WordPress. Già che ci sono, installo anche phpMyAdmin, un programma comodissimo che permette di gestire un database MySQL (e quindi anche MariaDB) tramite una interfaccia web.

A questo punto basta scaricare il codice di WordPress ed effettuare la famosa installazione in 5 minuti per essere a posto.

Beh, magari fosse così semplice! Tutto quello che ho in questo momento è un sito funzionante ma vuoto, invece a me serve ripristinare tutto il contenuto de Il nostro CNR.

Per farlo, sostituisco i file del sito e il database di WordPress con quelli contenuti nel backup fornito dal provider. Sembra difficile, ma avendo pieno accesso al terminale di Linux ed essendo l’amministratore onnipotente del sistema su cui gira WordPress diventa un gioco da ragazzi. Riavvio MariaDB ed Apache per fargli rileggere i nuovi dati su cui operare, ma non funziona.

Naturale, il database contiene l’indirizzo web (URL) del sito originale, https://ilnostrcnr.it, ma ora sono su Amazon AWS e l’URL del sito che ho creato è completamente diverso, è qualcosa tipo https://b0ef0914612e145f8fad9237c0dabd8a.vfs.cloud9.us-east-2.amazonaws.com. Non ho intenzione di combattere con i DNS o il file hosts, per cui entro nel database con phpMyAdmin, seleziono la tabella wp_options e sostituisco l’URL originale contenuto nei record siteurl e home con quelli forniti da Amazon AWS.

Riavvio di nuovo MariaDB ed Apache e finalmente il sito torna a vivere. Con phpMyAdmin controllo se il database ha degli errori, e in effetti ci sono, ma niente di così grave che possa impedirne il ripristino (e del resto a me funziona tutto perfettamente).

A questo punto è quasi routine, ed è anche l’occasione per dare una bella rinfrescata alle funzionalità del sito. Entro nella dashboard e rimuovo il plugin All-in-One WP Migration, che usavo per fare i backup personali del sito ma che che non è compatibile con le ultime versioni di PHP 7.x, e cancello dal terminale la directory relativa. Rimuovo anche il plugin Count per Day, ottimo per analizzare le statistiche di accesso al sito ma che non è aggiornato da un anno e non è stato testato con le versioni più recenti di WordPress. E dato che ha violato le linee guida di WordPress è stato pure rimosso dall’archivio (repository) ufficiale dei plugin di WordPress.

Controllo di nuovo il database usando sia una funzione seminascosta di WordPress³ che il solito phpMyAdmin ed ora è tutto a posto, dopo la rimozione dei due plugin problematici anche gli errori del database sono scomparsi.

Ritorno al provider

A questo punto mi rimane solo da fare un backup del sito e del database, che il provider potrà usare (o meglio “dovrà usare”, visto che finora non ha fatto niente di significativo) per ripristinare il sito originale.

Ma la cosa si rivela più difficile del previsto e l’interazione fra il supporto tecnico e me sembra un dialogo fra sordi,

che sfocia rapidamente nella incomunicabilità totale. Il sito è giù da ben 11 giorni ma al servizio tecnico importa pochissimo. Inutile provare ancora a ricevere un supporto degno di questo nome.

Prima di tagliare i ponti con il servizio tecnico ho preparato un Piano B. Ore di ricerche sul web mi hanno fatto trovare Duplicator, un plugin che sembra perfetto per le mie esigenze. In apparenza è uno dei soliti plugin di backup/ripristino di una installazione di WordPress, che alla fine richiedono sempre l’acquisto della versione Pro per essere davvero utili. Duplicator invece è diverso, la versione Pro aggiunge delle funzioni molto interessanti per chi gestisce dei siti web per professione, ma la versione base gratuita fa tutto quello che mi serve, è solo leggermente più complicata da utilizzare.

In previsione del piano B ho già provato a fondo Duplicator, usandolo per fare un backup completo del sito e per ripristinarlo in una nuova istanza di AWS Cloud9, e funziona in modo spettacolare. Mi piace soprattutto il fatto che lavori a bassissimo livello, sembra quasi di usare il terminale, che è poi quello che farei io stesso se il provider mi concedesse un accesso pieno e senza limitazioni via ssh al mio sito e soprattutto al database associato.

Entro quindi nel pannello di controllo del mio sito web e di tutti i tool collegati, il notissimo cPanel, cancello tutti i file del sito e anche il database che ha creato tanti problemi, e già che ci sono aggiorno PHP alla versione 7.2, la stessa versione disponibile in AWS Cloud9. Mi tremano un po’ i polsi, da ora in poi se sbaglio non posso più tornare indietro, ma ho delle alternative migliori?

A differenza degli altri plugin di backup/ripristino che conosco, Duplicator non ha bisogno di una installazione preesistente di WordPress per funzionare, ma insieme al backup del sito genera un programma in PHP che effettua da solo il processo di ripristino del sito e del database associato. Anche l’URL che ho modificato a mano diretatmente nel database vengono aggiornati correttamente. Bastano pochi minuti e il sito torna a vivere.

È il 2 gennaio, sono passati ben 14 giorni dal disastro.

Conclusioni

Quando dicevo all’inizio che la lettura di questo articolo non è adatta a chi si spaventa facilmente o è ansioso, stavo scherzando, ma non troppo. Questa esperienza ha davvero messo a dura prova le mie capacità tecniche, nonché la mia pazienza nell’interagire con chi dovrebbe fornire un supporto tecnico decente.

Ma dopo un paio di giorni era diventata una sfida personale, una specie di esame fuori tempo massimo, sei capace di risolvere questo problema difficile? E poi, naturalmente, c’era la necessità di non fare brutta figura con tanti colleghi…

Ovvio che alla scadenza del contratto bisognerà cambiare provider, tutto sommato questo finora non è stato male, ma finché va tutto bene sono buoni tutti, le differenze si vedono solo quando il gioco si fa duro. Avevo già pensato di farlo per altri motivi, ma il dover traslocare il sito su un’altro spazio web mi preoccupava un po’. Ora, con l’esperienza che mi sono fatta, sarà uno scherzetto.

A differenza delle versioni normali di Ubuntu Linux, che vengono rilasciate ogni sei mesi, le versioni LTS, Long Term Support, vengono rilasciate solo nella primavera degli anni pari e sono particolarmente indicate per un sistema server. ↩︎
MariaDB è un derivato (fork) del notissimo database MySQL, prodotto dagli sviluppatori originali di MySQL e compatibile praticamente al 100% con la versione corrispondente di MySQL. L’origine del fork sta nell’introduzione da parte di Oracle, che nel 2010 ha acquisito la ormai decaduta Sun Microsystems con tutto il suo parco software fra cui Java e proprio MySQL, di estensioni proprietarie disponibili solo per la versione a pagamento di MySQL. ↩︎
Bisogna aggiungere nel file wp-config.php la riga define('WP_ALLOW_REPAIR', true);, andare all’URL di amministrazione YOURSITE.com/wp-admin/maint/repair.php (dove YOURSITE.com deve essere sostituito con l’indirizzo web del sito) e seguire le istruzioni. ↩︎

Qui! Consip, ovvero altro che quattro punti spuntati

Mon, 30 Jul 2018 06:00:00 +0000

Non mi sarei mai aspettato di vedere immediatamente confermato, e nel modo peggiore, quello che scrivevo solo pochi giorni fa sulla Consip, il carrozzone che gestisce gli appalti della pubblica amministrazione.

Riassumo brevemente i fatti.

Una azienda, la Qui! di Genova (difficile trovare un nome più insulso), vince due lotti di un appalto Consip da 1 miliardo di euro (avete letto bene, 1 miliardo di euro) relativo alla distribuzione dei buoni pasto agli uffici pubblici.

L’azienda però è indebitata fino al collo e smette di pagare gli esercenti che ritirano i suoi ticket e che, in cambio della “fortuna”, le devono pure versare una certa commissione. I negozianti a loro volta smettono di ritirare i buoni pasto della Qui!

La situazione precipita rapidamente e alla fine la Consip, quasi in contemporanea alla pubblicazione del mio articolo, decide pilatescamente di risolvere la convenzione con Qui! ma di lasciare alle singole amministrazioni il compito di decidere cosa fare delle loro forniture. L’effetto finale è che circa 100.000 dipendenti pubblici del Lazio e delle regioni del Nord-Ovest si ritrovano in tasca decine di buoni pasto che non possono utilizzare e che forse non saranno mai rimborsati o sostituiti.

Uno potrebbe chiedersi come sia possibile che una azienda come Qui! possa vincere un appalto di questa entità senza che il carrozzone Consip effettui i dovuti controlli, che sono una delle ragioni alla base della sua stessa esistenza, e quali trame e quali compiacenze ci siano dietro tutto ciò.

Ma queste considerazioni non mi interessano, le lascio volentieri a giornalisti e commentatori, oltre che alla solita magistratura chiamata sempre a spiegare e a risolvere a posteriori i tanti fatti mefitici della nostra vita pubblica.

Quello che mi interessa è l’intrico di burocrazia asfissiante e di gattopardismo che pretende di controllare persino le minuzie in modo che non si riesca a controllare un bel niente, che c’è dietro tutta questa storia.

Non so più da quando ho iniziato a ricevere i buoni pasto (o più confidenzialmente ticket), sarà più o meno dalla metà degli anni ‘90.¹ Prima per mangiare durante la pausa pranzo avevo due possibilità: andare alla mensa ospitata nell’area del mio istituto, dove il pasto era gratuito (bevande escluse) anche se la qualità spesso decadeva con l’avvicinarsi del termine della convenzione, oppure scegliere uno dei bar o delle tavole calde della zona per il classico panino o l’insalatona pseudo-salutista. Se decidevo di andare “fuori” ero penalizzato, sia perché pagavo di tasca mia sia perché l’ente pagava anche per me la convenzione con la mensa senza che ne usufruissi. Però tutto sommato ero libero di scegliere e andava bene così. Inoltre se mangiavo fuori potevo cedere il mio buono giornaliero per la mensa a un tesista, borsista, o precario di altro genere che non essendo un dipendente “ufficiale” avrebbe dovuto pagarsi il pranzo, per cui niente o quasi andava sprecato.

Poi arrivarono i ticket, blocchetti di una ventina di foglietti strappabili da usare per pagare i pasti (che a me hanno sempre ricordato i miniassegni usati negli anni ‘70 al posto degli spiccioli). Il mio istituto appaltava la fornitura dei ticket ad una delle società emettitrici, dopo uno o due anni il contratto scadeva e l’istituto decideva se rinnovare l’appalto o se cambiare fornitore (basandosi, si spera sul feedback degli utenti).

Come dipendente avevo il diritto di ricevere un ticket per ogni giorno lavorativo e lo potevo usare sia nella mensa interna che in un qualsiasi bar, tavola calda o supermercato convenzionato con quel particolare tipo di buono pasto. Sembrava l’uovo di Colombo, e tutti o quasi ne traevano dei vantaggi (a parte i precari che perdevano la possibilità di mangiare gratis).

Sembra incredibile ma dalla faccenda dei ticket ci guadagnano più o meno tutti, mettendo a dura prova il primo principio della termodinamica. Ci guadagna l’ente pubblico che paga i ticket meno del loro valore nominale (stiamo parlando di un euro o anche un euro e mezzo in meno), ci guadagnano gli esercenti convenzionati che aumentano spesso di parecchio clienti e vendite.

Ma ci guadagna anche e soprattutto la società emettitrice dei buoni pasto, nonostante li venda a meno del loro valore. Come? Prima di tutto giocando sui tempi: l’ente pubblico paga la fornitura tutta insieme o in grosse tranche periodiche e (relativamente) veloci mentre i dipendenti spendono solo uno o due ticket al giorno. Quindi in media ciascun ticket viene pagato alla società emettitrice parecchi giorni (ma più spesso mesi) prima del momento in cui questa rimborsa l’esercente che l’ha ritirato. Moltiplicando per decine o centinaia di migliaia di ticket ogni mese, significa che la società ha in mano per lunghi periodi di tempo un bel po’ di soldi freschi che può far fruttare sul mercato finanziario, trasparente o opaco che sia (come forse è successo con Qui!).

Se si aggiunge che gli esercenti sono obbligati, se vogliono mantenere la convenzione, ad accettare quasi sempre condizioni capestro, pagando ad esempio commissioni piuttosto elevate alla società emettitrice e venendo rimborsati solo dopo parecchi mesi (la commissione in teoria è proibita ma può essere camuffata in molti modi diversi, per tanti esercenti rifiutarsi di pagarla può significare perdere anche centinaia di clienti), e che tante volte i dipendenti perdono o dimenticano in un cassetto una parte dei loro ticket oppure non riescono a utilizzarli entro la data di scadenza,² ci si rende facilmente conto di come i buoni pasto possano essere un affare eccellente per chi li emette.

In fondo quello che ci guadagna di meno è proprio il dipendente, che ancora oggi riceve buoni pasto del valore di soli 7 euro, appena sufficienti ad acquistare un panino e una bottiglietta di acqua, altro che pasto completo! Senza dimenticare i gestori delle mense aziendali, che diminuiscono ogni giorno di più, perché “tanto ci sono i ticket!”.

Gli enti pubblici sono obbligati ad offrire un servizio mensa ai loro dipendenti (ma credo che la stessa cosa succeda anche nelle aziende, o almeno in quelle più grandi). Fino a pochi anni fa, la mensa era spesso interna, ospitata nei locali dell’ufficio e il servizio era appaltato ad un servizio esterno per uno o più anni, dopo i quali l’ente poteva decidere se rinnovare l’appalto o cambiare gestore. In alternativa l’ente poteva stabilire apposite convenzioni con bar, tavole calde o simili dei dintorni, che agivano in tutto e per tutto da sostituti del servizio mensa interno.

Una mensa interna è un bel fastidio. Bisogna avere i locali adatti, gestire l’appalto, controllare la qualità e il rispetto delle norme di sicurezza, avere a che fare con i fumi puzzolenti, i rumori, il via vai dei dipendenti che vanno e vengono dalla mensa, tutte cose che disturbano e non poco chi ha la sfortuna di lavorare nelle vicinanze della mensa. Naturale che tante amministrazioni pubbliche abbiano deciso velocemente di saltare sul carro dei ticket, chiudendo il servizio mensa interno e passando a distribuire i soli ticket.

Si chiama “esternalizzazione”, è successo anche per il servizio di pulizia, di portierato, di manutenzione generale degli uffici. In teoria è un vantaggio, il privato fornisce il servizio in cui è specializzato e l’ente pubblico risparmia gli stipendi dei dipendenti che prima svolgevano internamente quel determinato servizio. In pratica è una porcheria, il privato per vincere la gara d’appalto al ribasso deve risparmiare su tutto, in particolare sugli stipendi dei suoi dipendenti, sfruttati senza pietà e che si limitano a fare solo lo stretto indispensabile (quando lo fanno), e sulla qualità e quantità delle forniture. Venite a vedere come fanno le pulizie nel mio istituto per credere.³

Che problema c’è? Dopo una serie di disservizi documentati si può annullare l’appalto e cercare qualcuno che svolga un servizio migliore. Sbagliato! E qui torniamo alla Consip, che avevamo lasciato molte righe fa.

Da anni tutti gli appalti degli Enti Pubblici sono centralizzati e gestiti dalla Consip,⁴ la società del Ministero dell’Economia e delle Finanze che dovrebbe “rendere più efficiente e trasparente l’utilizzo delle risorse pubbliche, fornendo alle amministrazioni strumenti e competenze per gestire i propri acquisti e stimolando le imprese al confronto competitivo con il sistema pubblico” (lo so che l’ho già scritto, ma in certi casi è meglio ripetersi).

Lo vogliono certe norme europee e lo vuole anche il buonsenso, se un appalto viene gestito da professionisti che conoscono il loro mestiere, come dovrebbero essere i burocrati della Consip, si possono ottenere economie di scala che consentono di risparmiare, e allo stesso tempo si stimola la concorrenza e si evitano imbrogli e corruzione.

Le sole eccezioni a questa norma sono gli acquisti “specializzati”, come ad esempio quelli che riguardano la strumentazione scientifica (ma anche in questo caso ormai le cose sono diventate paurosamente complicate, con grave danno per chi fa questo tipo di acquisti che richiedono flessibilità e tempi rapidi).

Che con la Consip o costi (e la corruzione) si siano ridotti mi pare opinabile, basta guardare questi dati relativi all’acquisto di beni sanitari nelle diverse regioni italiane per rendersi conto delle enormi discrepanze che esistono ancora oggi fra le varie arre del paese. Come è possibile ad esempio che i servizi di medicina di base possano costare circa 90–95 euro a residente in Liguria, Piemonte, Lombardia e Friuli, così come in Toscana e Umbria, ma che arrivino a ben 130–150 euro a residente nelle regioni del Sud, mentre le regioni autonome di Valle D’Aosta e Trentino Alto Adige sono più vicine alle regioni del Sud che a quelle più virtuose del Nord? Oppure che i servizi specialistici ambulatoriali costino cifre tutto sommato contenute e poco variabili al Sud ma quasi il doppio in Lombardia, o che presentino delle variazioni spaventose nel Lazio o nel Nord-Est?

Ci saranno norme europee dietro tutto questo, ma non è che “lo vuole l’Europa!” è diventato una giustificazione analoga al “Dio lo vuole!” dei tempi delle crociate, dietro il quale si celavano le peggiori nefandezze? Lo vorrà pure l’Europa, ma lo vuole proprio così o ci sono modi diversi e più efficienti per venire incontro alle giuste richieste dell’Unione?

E poi, come è possibile che dopo tutti le specifiche, le documentazioni richieste, i chiarimenti, le commissioni, i controlli, che gli appalti gestiti da Consip dovrebbero garantire, possano verificarsi casi come quello di Qui!? Come è possibile che possa essere affidata una grossa fornitura pubblica ad una azienda che una semplice verifica fiscale di routine ha trovato sommersa di decreti ingiuntivi da parte di commercianti non pagati?

E come è possibile che, quando si verifica il patatrac, la Consip se ne lavi le mani, risolva il contratto a parole, ma lasci ai singoli enti che usufruiscono dell’appalto il compito di decidere cosa fare con le loro forniture, anche se il problema non dipende dalle loro decisioni e se i singoli enti possono fare abbastanza poco per tamponare velocemente il problema?

E come è possibile che in questa storia nessuno pensi ai dipendenti dei vari enti pubblici coinvolti, bistrattati spesso a ragione ma che in questo caso sono solo vittime, che si ritrovano con dei buoni pasto che non potranno mai utilizzare e non sanno se e quando saranno mai rimborsati?

Non è facile correggere un errore su un appalto che in totale vale l’astronomica cifra di 1 miliardo di euro? Non lo metto in dubbio, ma siamo sicuri che non sia proprio questa elefantiasi alla base del problema? Qui non stiamo parlando di grandi infrastrutture, stiamo parlando di banali buoni pasto. Appalti di questo tipo non sarebbe meglio gestirli a un livello più basso, come succedeva in passato, in modo che sia più facile prendere le opportune contromisure nel caso in cui qualcosa vada male?

In Italia la corruzione e il malaffare sono un male endemico, combatterla è buono e giusto oltre che necessario, però come dicevo nella scorsa puntata, non sarebbe meglio combatterla responsabilizzando le singole amministrazioni e facendo fuori i funzionari e i loro capi presi con le mani nella marmellata, invece di creare mostri burocratici come la Consip che controllano e gestiscono tutto, ma che alla fine non sembra siano tanto efficaci nel fare al meglio il loro lavoro?

Anche perché come sempre ogni norma rigida ha i suoi punti deboli. La Consip non interviene per gli appalti sotto una certa soglia (naturale, in tanti casi bisogna per forza agire rapidamente, non si possono aspettare le lungaggini delle gare di appalto) e infatti i (pochi) dati disponibili mostrano un forte aumento di questi ultimi dopo l’ultimo aggiornamento del codice degli appalti, nell’aprile del 2016.⁴ L’aumento del numero di appalti appena sotto la soglia vale di sicuro per gli appalti di lavori, per i quali la soglia è fissata a 150.000 euro, ma è probabile che valga anche per contratti e forniture (dove la soglia è di soli 40.000 euro), di cui però si sa poco perché sotto questa cifra l’ANAC, chissà perché, non registra i dati nel suo Portale della Trasparenza.

Secondo gli autori dello studio citato,⁴ “L’introduzione della soglia, lo spacchettamento degli appalti in contratti di importo inferiore alla soglia di € 150.000 ha comportato una serie di potenziali sprechi dovuti all’aumento artificioso delle procedure di gara, e dei costi connessi.” Inoltre “ciò implica inoltre probabili inefficienze nella realizzazione delle opere dovute alle difficoltà di coordinare un maggior numero di soggetti che, a causa della frammentazione dell’opera originaria in una serie di sottocontratti, si trova a dover interagire su lavorazioni legate tra loro.” Per poi concludere che, “questi problemi evidenziano quindi dei forti limiti a quello che era l’obiettivo principale della riforma, ovvero quello di accorpare in soggetti altamente qualificati [cioè la Consip, ndr] le procedure di aggiudicazione.”

Ma non c’è solo la Consip a complicare la vita. Persino la consegna dei singoli buoni pasto ai dipendenti che ne hanno il diritto è diventata negli ultimi anni una cosa assurdamente complicata. Potrei sbagliare, però mi sembra di ricordare che all’inizio mi spettava un ticket per ogni giorno lavorativo, quindi ricevevo un blocchetto standard di 22 ticket ogni mese, con delle eccezioni per quando ero in ferie o in missione.

Oggi bisogna risparmiare su tutto,⁵ per cui ora mi danno un ticket per ogni giorno lavorato. Di conseguenza niente ticket se sono in ferie e niente ticket se usufruisco di un riposo compensativo (cioè sto a casa recuperando le ore di servizio fatte in più che da contratto non vengono pagate, io ne ho oltre 2000!). Ma anche niente ticket se sono in missione per più di tot ore (non mi chiedete quante, però) o se la missione prevede il rimborso del pranzo. E niente ticket se in un giorno faccio meno di tot ore (dove è possibile che questo tot sia diverso da quello di prima). E poi niente ticket se…, io stesso non ricordo tutte le eccezioni possibili.

Sta di fatto però che, per una sede di istituto dove ci sono una quarantina di persone (e forse anche meno) che usufruiscono dei ticket, ci vuole un collega dell’amministrazione che ogni giorno si occupa di gestire tutti questi casi particolari (che poi tanto particolari non sono, è nella stessa natura del nostro lavoro svolgere una parte più o meno consistente dell’attività fuori dalle mura dell’istituto), contando il numero di ticket maturati dal singolo dipendente e distribuendo a ciascuno di noi un nuovo blocchetto da 20 solo nel momento in cui ha maturato i benedetti 20 giorni di lavoro effettivo. Il collega ci perde una bella fetta della mattina per fare tutte queste cose, senza considerare che si deve anche occupare di ordinare le nuove forniture di blocchetti, di contarli e di verificare che sia tutto a posto, e mille altre piccole incombenze analoghe.

Insomma, almeno nel mio microcosmo, la pubblica amministrazione paga lo stipendio ad una persona che per almeno un quarto del suo tempo è occupato a risparmiare qualche ticket ogni giorno. Diciamo che il collega guadagna 1.500 euro netti al mese, quindi a occhio almeno 4.000 euro comprese tasse e contributi, circa 200 euro lordi al giorno. Il suo lavoro di gestione analitica dei ticket viene quindi a costare allo Stato almeno 50 euro al giorno, praticamente lo stesso (se non di più) del risparmio che si riesce ad ottenere controllando in modo così granulare e fiscale quello che fanno i dipendenti (in effetti costa molto di più perché a Roma ci sono ulteriori controlli che impiegano altro personale).

Altro che (finto) risparmio, a me sembra invece solo uno spreco di tempo e di risorse, camuffato sotto la forma di una gestione oculata dei fondi. Un po’ come quando qualche agenzia statale (e a volte anche non statale) chiede al cittadino un rimborso di pochi spiccioli, la cui gestione viene a costare dieci o venti volte di più.

I risparmi hanno senso quando sono veramente tali, non quando si risparmia da una parte per buttare via i soldi dall’altra. Molto meglio a questo punto abolire i ticket tout court e aggiungere l’importo equivalente alla busta paga di ciascun dipendente (come reddito non tassato, perché i ticket entro certi limiti non sono tassati). Per le meno si risparmierebbero le spese e la gestione di questi appalti miliardari, il contenzioso, i trucchetti, le furbate e gli scandali come quello di Qui!.

Ma figuriamoci, in Italia tutte le semplificazioni si risolvono in nuove e incredibili complicazioni, tutti i proclami inneggianti al risparmio si risolvono nel controllo stringente delle più piccole minuzie, perché questo è il mezzo più efficace per rendere impossibile un controllo vero ed efficace dei grossi sprechi.

Ma ne riparliamo presto con un esempio personale.

Ci sarà una relazione con l’uscita di Windows 95? Perché no, di certo non è meno probabile della fantasiosa relazione fra vaccini e autismo). ↩︎
Perché i ticket, sembra incredibile, scadono quasi più rapidamente del latte o dello yogurt. ↩︎
Dopo aver visto pulire le scrivanie con lo stesso straccio usato per il water, ho iniziato a coprire la mia ogni sera con articoli e fogli vari per impedire che le signore delle pulizie ci si avvicinassero. ↩︎
L. Castellani, F. Decarolis e G. Rovigatti, “Il Processo di Centralizzazione degli Acquisti Pubblici: Tra Evoluzione Normativa e Evidenza Empirica”, Mercato Concorrenza Regole, Il Mulino (2017). Il file pdf dell’articolo è liberamente disponibile qui. ↩︎ ↩︎ ↩︎
A parole e quasi solo sugli stipendi, gli sprechi su tutto il resto non sono stati minimamente scalfiti. ↩︎