Breve corso di management

Andate a lavorare per un Application Service Provider. Dato che, per la natura del business, un ASP avrà un gran numero di clienti, assicuratevi che per ogni cliente si costruisca una nuova applicazione da zero, non curandovi del fatto che il tipo di applicazione è sempre lo stesso. Il riutilizzo del codice è per i pigri.

In particolare, visto che la piattaforma è costituita da un front-end Windows e un back-end Linux, non assumete specialisti Linux: fate il massimo sforzo possibile per uniformare e standardizzare la parte Windows e mettete insieme la roba Linux un po' come viene e quando serve. A questo stadio è essenziale non avere più di due o tre server con la stessa versione della stessa distribuzione Linux.

Abbiate cura, in questa fase, di non limitarvi a creare una diversa applicazione per ogni cliente: preoccupatevi di usare diverse metodologie per risolvere gli stessi problemi. Per alcune applicazioni, recuperate i dati dal sito o da un feed del cliente; per le altre, ignorate l'esistenza di un analogo sito e costringete il cliente a inviare i dati via FTP una volta al giorno, e costruite una complessa architettura tutta basata su cron script, avendo cura che fallisca miseramente e in maniera assolutamente silenziosa se il cliente invia i dati alle 9:05 invece che alle 9. I cron job, poi, dovranno essere a volte in una directory dedicata inclusa nell'applicazione, a volte in una directory dedicata sotto /root, a volte nella home directory dello sviluppatore (esportata all'uopo via NFS dai server di sviluppo a quelli di produzione), a volte su un diverso server messo su alla bisogna; ed eseguiti ora dall'utente root, ora da un utente standard comune a tutte le macchine, ora dall'ID dello sviluppatore che li ha creati. Altre volte ancora, scrivete un daemon che interroghi ogni 48 secondi un server FTP del cliente e prelevi i dati trasferendoli poi su uno share da cui cron script che girano su un'altra macchina ancora li prelevino e li sottopongano all'applicazione. Non usate mai un solo server per un'applicazione quando potete distribuirla su un numero casuale di macchine in diversi hosting centre. Non usate mai un database quando potete salvare decine di migliaia di file su un fileserver, indicizzati esclusivamente per data di creazione. Non usate mai un singolo logfile quando potete salvare centinaia di migliaia di file di testo, uno per ogni singola transazione, su un fileserver, assicurandovi che l'ID della transazione non venga mai salvato all'interno del file ma solo nel suo nome, per semplificare l'aggregazione dei dati.

In uno sforzo verso la standardizzazione delle applicazioni web, imponete che tutte le opzioni di configurazione vengano impostate in un singolo file, sempre lo stesso per ogni applicazione. Accertatevi che metà delle funzionalità vengano attivate settando il parametro corrispondente a 1, l'altra metà settandolo a 0. Non fate documentare nulla: che bisogno ce n'è, quando lo sviluppatore sa già quali sono i valori giusti?

Spalmate tutta l'infrastruttura, back-end e front-end (distribuita su quattro diverse locazioni), su un'unica rete classe B senza segmenti. Mostrate sorpresa quando gli hub esplodono e/o fondono o il traffico si strozza a 1 byte per secondo. Mostrate ulteriore sorpresa alla scoperta del concetto di latenza.

Una volta arrivati al magico numero di 200 macchine per il back-end, assumete un sistemista Linux. A partire dal terzo giorno, dategli la colpa di tutto quello che va storto. Quando, dopo sei mesi, si dimette, accusatelo di scarsa professionalità e annunciate che in ogni caso fra un mese o due sarebbe stato licenziato per manifesta incompetenza.

Assumete un nuovo sistemista Linux. Dategli l'incarico di standardizzare l'infrastruttura. Quando annuncia che è impossibile farlo nei tempi desiderati (settimane) senza causare falle nei servizi, licenziatelo. Scoprite di non avere avuto una giusta causa. Pagategli un cospicuo indennizzo.

Assumete un nuovo sistemista Linux. Dategli dello stronzo senza ragione ogni mattina. Dategli nuovamente dello stronzo per la ragione che dopo tre giorni non si è più presentato al lavoro.

Assumete un nuovo sistemista Linux. Licenziatelo il giorno prima che entri effettivamente in servizio perchè avete dovuto pagare una multa colossale per violazione di alcune regolamentazioni sulle telecomunicazioni. Mostrate sorpresa quando scoprite che invece di tagliare i costi, con quest'astuta mossa gli avete dovuto pagare una penale che levati, e siete ancora senza sistemista.

Assumete un nuovo sistemista Linux. Dategli la colpa di tutto dal giorno prima di assumerlo. Dategli il compito di portare ogni singolo server allo stesso standard, e contemporaneamente vietategli di standardizzare i server perchè la loro configurazione deve rispecchiare i compiti specifici che devono svolgere. Accusatelo di insufficiente elasticità per non aver capito quello che volevate dire con la frase precedente. Incaricatelo di segmentare la rete. Vietategli di segmentare la rete. Incaricatelo di creare un accesso VPN per permettervi di lavorare da casa. Mandategli una lettera con minaccia di licenziamento per aver creato un buco di sicurezza gravissimo con un accesso VPN che è stato violato quasi immediatamente, a causa del keylogger/bot che gli alieni avevano teletrasportato sul vostro laptop personale con cui pretendevate di collegarvi da casa. Chiedetegli di trasferire tutti i cron job di ogni singolo server su una macchina centrale di servizio da cui dovrebbero poi accedere al server desiderato ed eseguire le azioni necessarie. Dopo due giorni, lamentatevi perchè "ancora non sei riuscito a mettere insieme quella che dopotutto è una semplice crontab".

Assumete un junior sysadmin. Mostrate sorpresa quando vi fa notare che al colloquio nessuno aveva parlato di "portare quotidianamente il caffè ai manager in riunione" come uno dei suoi compiti.

Continuate a sfornare applicazioni ognuna diversa dalle altre e accusate i sistemisti di scarsa professionalità se non riescono a tener dietro a tutte le dipendenze, minuzie e idiosincrasie rigorosamente non documentate di ognuna.

In nome di una maggiore standardizzazione, adottate due diversi database come standard e lasciate assoluta libertà agli sviluppatori di utilizzare l'uno, l'altro o entrambi. Fate girare tutte le istanze di uno sotto Linux, alcune istanze dell'altro sotto una diversa distribuzione di Linux e altre sotto Windows (2000, XP e 2007 Server). Se tutte le applicazioni devono salvare certi dati critici per il business in un database comune, create lo stesso database su ognuna delle tre piattaforme e offrite agli sviluppatori assoluta libertà di scelta, creando poi una complessa architettura al solo scopo di replicare i dati di quel database attraverso tre piattaforme.

Quando un tecnico del supporto vi chiede di mandarlo a fare un corso su Linux, accettate. Addebitategli il costo del corso sullo stipendio, ostentando sorpresa quando lui lo scopre e s'incazza.

Mandate un'altra nota disciplinare/minaccia di licenziamento al senior sysadmin quando una delle vostre applicazioni web viene penetrata. Rifiutatevi di ritirarla quando lui vi fa notare che l'applicazione era stata messa in linea da uno sviluppatore, su vostra autorizzazione, e a sua insaputa perchè utilizzava una piattaforma con vulnerabilità note e ampiamente sfruttate di cui lui aveva espressamente vietato l'installazione. Controbattete che comunque lui è alla fine responsabile di quei sistemi.

Accusatelo di scarsa professionalità quando si dimette.

Restate sei mesi senza senior sysadmin. Accusate il junior sysadmin di generica incompetenza e restringete il più possibile le sue mansioni all'ordinaria manutenzione. Vietate esplicitamente al tecnico di supporto che ha fatto il corso per la certificazione Linux anche solo di toccare una macchina Linux. Fate curare l'installazione e il setup di nuove applicazioni e di nuovi server Linux agli sviluppatori che ne hanno voglia, quando ne hanno voglia.

Assumete un nuovo sistemista Linux. Durante il colloquio, rispondete di sì a tutte le sue domande, soprattutto a quelle relative all'esistenza di un ambiente di test, alla pianificazione dei rollout, alle procedure formali di hand-off delle applicazioni, al sistema di ticketing per il supporto. Non importa che non abbiate idea di cosa stia parlando: è essenziale rispondere di sì a tutto.

Dategli come primo compito quello di riordinare i cron job e gli script che fanno variamente funzionare (o no) ognuna delle applicazioni. Dategli come secondo compito quello di portare tutti i server allo stesso standard per sistema operativo, software installato e versione delle librerie. Per facilitargli la vita, dopo il primo mese licenziate il junior sysadmin e il tecnico di supporto con la certificazione Linux, con la doppia giustificazione (resa pubblica) che comunque Linux è stabile e non ha bisogno di supporto continuo, e che i soldi per lo stipendio del senior sysadmin da qualche parte devono pur uscire.

Quando il sistemista crea una procedura automatica che permette di sfornare un numero arbitrario di server perfettamente standard in un'ora, passate due giorni a farvi spiegare ogni riga dello script kickstart, il funzionamento di DHCP e TFTP, fraintendete tutto il fraintendibile, lamentate che un'ora è troppo, lamentate che non è PCI-compliant, mostrate sorpresa quando scoprite che lo è, fatevi rispiegare cosa significa PCI-compliant, pretendete che ogni singola riga vi venga spiegata nuovamente alla luce di quel che avete appena imparato, mettendoci altri due giorni, e alla fine mandate un'email di fuoco al sysadmin (in copia al resto del management e alle risorse umane) perchè ha finalizzato la procedura una settimana fa, millantandone la velocità, e in una settimana non è riuscito a mettere in linea neanche un server.

Per ogni server portato allo standard, lamentate rumorosamente e pubblicamente sia il troppo tempo speso, sia il tempo insufficiente dedicato al testing. Durante il processo di aggiornamento, rifiutatevi di fornire qualsivoglia informazione sul testing. Chiarite subito che il tempo degli sviluppatori è troppo prezioso e il testing di ogni aspetto (non documentato) delle applicazioni deve essere eseguito dal sysadmin.

Siate apertamente e pubblicamente sospettosi della lealtà del sysadmin per aver avuto precedenti rapporti di lavoro con un cliente molto importante. Quando il sysadmin risolve (ripetutamente) casini che avevano messo a rischio il contratto con quel cliente, accusatelo pubblicamente di essere più leale al cliente che alla compagnia per cui lavora, portando come prova una mail del cliente che ringrazia tutti "e in particolare il sysadmin" per il magnifico lavoro svolto. Mettete il sysadmin a completa disposizione di quel cliente. Fatelo sbattere ripetutamente in giro per l'Europa a risolvere casini accessori del cliente. Accusatelo al suo ritorno di trascurare il lavoro.

Accusate il sysadmin (e gli altri tecnici senior) di scarsa professionalità ed incompetenza, pubblicamente, se possibile sulla lista di distribuzione interna della compagnia, per ogni svista o omissione, anche e soprattutto se priva di conseguenze (e.g. aver usato "reply" invece che "reply all" in uno scambio di email), dilungandovi su tutti i motivi per cui queste sviste denotano che non sono affidabili, mancano di competenza e probabilmente molestano i bambini.

Pretendete di avere l'ultima parola su ogni dettaglio di ogni decisione tecnica. Indite meeting di quattro ore per discutere il fatto che un default gateway abbia indirizzo .1 piuttosto che .254.

Pretendete di continuare ad usare nastri DLT da 20 Gigabyte per il backup di una SAN da 16 Terabyte, perchè "il backup funzionava benissimo prima che comprassimo la SAN". Imponete al sysadmin di chiamare il supporto del produttore della SAN e protestare perchè "la SAN ha rotto il sistema di backup".

Stupitevi della perplessità del sysadmin davanti ad un cron job che riavvia un certo daemon (in produzione) ogni minuto, giustificato con "yes, the daemon is a bit flaky, you know". Informatelo che lo sviluppatore ha cose più importanti da fare che trovare qualche stupido bug di un daemon che comunque se viene riavviato regolarmente non causa quasi nessun problema.

Se è un giorno lavorativo dove vi trovate voi, aspettatevi che la gente sia al lavoro anche se nel loro Paese è un giorno di festa. Se siete a Londra, fate una sfuriata agli sviluppatori francesi (sul telefono di casa di ognuno di loro, in teleconferenza) perchè non sono al lavoro il 14 luglio o a Ferragosto. Se siete in Francia, fate una sfuriata agli inglesi che non sono al lavoro ogni Bank Holiday Monday.

Non sforzatevi troppo a cercare di imparare a parlare inglese. Quando non capite qualcosa, potete sempre fare una sfuriata a chi vi sta di fronte e parla un inglese "inutilmente complicato" - ma solo dopo che eventuali malintesi hanno causato danni irreparabili. Non siete mica Shakespeare, come si può pretendere che sappiate che "indeed" significa "esatto, proprio così"?

Il giorno in cui il governo dichiara che chi si prende l'influenza suina deve restare a casa per due settimane, annunciate che i giorni di malattia pagati sono ridotti da quindici a dieci all'anno. Accusate chi viene al lavoro con la febbre di essere distratto e taciturno perchè non ha voglia di lavorare. Quando alla fine uno dei tecnici del supporto finisce in ospedale con la polmonite, abbiate cura di telefonargli per chiarire che i giorni pagati sono comunque dieci indipendentemente dalla gravità della malattia. Visto che ci siete, accusate il sysadmin, che vi fa notare la mancanza di tatto, di aver fomentato una cultura del relax e del dolce far niente fra i membri del suo team.

Licenziate poco meno di metà del personale tecnico della compagnia in un mese, al ritmo di uno al giorno o quasi. Mostratevi scandalizzati ed offesi quando scoprite che qualcuno degli ultimi aveva mandato in giro il proprio CV prima di essere licenziato. Accusateli di scarsa lealtà. Ringraziate pubblicamente i superstiti per la loro lealtà e dedizione. Licenziatene due il giorno dopo. Rimpiazzate tutti i licenziati con diciannovenni americani (inviati dalla nuova proprietà) e francesi (figli di vecchi compagni di scuola) e date la colpa ai "vecchi" per ogni sopravvenuta inefficienza.

Celebrate il fatto che siete riusciti a perdere personale più rapidamente di quanto abbiate perso clienti, realizzando così un profitto col taglio dei costi nonostante il crollo del fatturato. Proclamate che questo prova l'oculatezza della vostra strategia ed un segnale positivo per il futuro.

Mostratevi esterrefatti e feriti negli affetti quando metà dei "vecchi" superstiti si dimettono.

Prendete ogni lamentela dei clienti riguardo alle sopravvenute inefficienze come un attacco personale condito di insinuazioni sulla verginità delle vostre figlie. Per ripicca, cancellate contratti su contratti con i clienti. Fate una sfuriata a chi vi fa notare che rifiutare i soldi di un cliente non è una ripicca efficace.

Riprendete il sysadmin per aver usato la pausa pranzo per pranzare invece di lavorare.

Quando il sysadmin si dimette, accusatelo di scarsa lealtà e competenza, e annunciate che comunque il suo stipendio non era affatto giustificato e sarebbe stato licenziato presto, perchè di un sysadmin Linux non ce n'è veramente bisogno.

Assumete un sistemista Linux... (ad libitum, o fino al fallimento)