Storie dalla Sala Macchine |
Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Imposta lingua:en it | Login/Register
Forse non ve ne sarete accorti (se cosi':buon per voi) ma siamo sempre in piena crisi economica. Il che significa che un sacco di societa' e dittarelle varie stanno cercando di risparmiare soldi in ogni modo possibile immaginabile e qualche volta pure impossibile ed inimmaginabile. E parecchie di tali 'dittarelle' sono anche nostre clienti.
Un po' di tempo fa arrivo' fresca fresca $noiguardiamolavostrarobba, che proponeva un servizio di monitoring di... qualche cosa. Puo' essere che abbia gia' parlato di sta gente. Comunque sia all'inizio l'SL della situazione si era lanciato ed aveva richiesto due server, uno dedicato come Database server ed uno come application server. Entrambi con Windows Server. Una sorta di applicazione era stata sviluppata dal programmatroto di turno e la ditta aveva cominciato a raccattare clienti.
Poi avevano scoperto che superato un certo numero di clienti due pezzi della suddetta applicazione entravano in conflitto tra di loro provocando un bel crash dell'intero sistema. La ditta che questa gente aveva contattato per sviluppare l'applicazione in questione, non avendo la piu' pallida idea di come risolvere il problema aveva suggerito di aggiungere un altro server e 'spezzare' l'applicazione sui due. Il che significa un incremento dei costi del 33% secco. Poi hanno cominciato ad avere problemi con la quantita' (per non parlare della qualita') dei dati che venivano scaricati sul database.
Ora, dire che MS SQL Server sia un database 'pesante' e' dire poco, quando poi il programmatroto di turno non si prova nemmeno a fare un minimo di analisi e decidere se la struttura dati sia ottimale o meno non ne parliamo. Se poi si cerca di scaricare dati in quasi-real-time al ritmo di ennemila transazioni al secondo si va cercare dei guai con una lente d'ingrandimento gigante. Il risultato e' stato che il sistema ha subito diversi tracolli abbastanza preoccupanti.
Per qualsiasi ditta che prentende di fornire servizi con "99% di uptime" il che non e' molto bello. Il programmatroto di turno non sapendo che pesci pigliare lamenta che sul sistema di test funziona tutto perfettamente. Qualche cosa mi fa pensare che il sistema di test ha un decimo dei dati ed un centesimo delle richieste, rendendolo praticamente inutile come sistema di test. Qualche altra cosa mi fa pensare che la 'ditta di sviluppo' e' composta dal programmatroto e dal di lui cane (il quale pero' non scrive codice purtroppo).
Dopo una serie di vari casini, l'SL della situazione ha lasciato il campo a qualcun altro (non so se la dipartita e' stata volontaria o meno). Ed un nuovo e brillante SL ha deciso che la cosa migliore era rifare il tutto daccapo. Per il rifacimento e' stata scelta una piattaforma basata su 6 server Linux con Postgre come database e JBoss come application server (??). Il software, riscritto da un programmatroto 'interno' invece che essere fatto all'esterno (non che vi sia una grande differenza in sostanza ma per qualche motivo il 'fatto fuori' sembra meglio del 'fatto dentro').
Il rifacimento viene rifacito ed i due ambienti (vecchio e nuovo) sono in funzione in parallelo. Il nuovo ambiente si rivela purtroppo stabile quanto il vecchio se non meno. Il DB server (che per qualche motivo si ritrova a fare anche da sftp server) risulta incriccato con un load average di circa 8. Dopo un po' di tira e molla SL consente all'aggiunta di una extra CPU alla macchina. Poi ci sono un po' di casini con uno degli elementi che pare crashare con regolarita' inquietante sempre alle 3 del mattino, con grande felicita' del pinguino in 'standby' che viene svegliato regolarmente. Per risolvere la situazione viene decisa l'installazione di una seconda istanza di JBoss sulla stessa macchina perche' pare che quell'applicazione non possa funzionare nella stessa istanza con un'altra applicazione (???). Poi ci sono problemi con un'altra applicazione (su un'altra macchina) che per riavviarla richiede un reboot dell'intero server (?!??).
Al tutto si aggiunge una ennesima applicazione che gira su TomCat (per la serie "non abbiamo abbastanza problemi"), ed una ridda di rewrite e redirect che per mantenerle ci vuole la pazienza di Giobbe.
Nel frattempo le release e sottorelease si susseguono ed ovviamente ogni volta e' un casino perche' si tratta di fare rilasci su 'n' sistemi in parallelo ognuno con le sue idiosincrasie (non puoi avviare l'applicazione A sul server 1 in concorrenza con l'applicazione B sul server 2 altrimenti tirano giu' il database che manda in coma l'applicazione C sul server 3...) ed operazioni "speciali" (prima di fermare l'applicazione A sul server 3 bisogna mettere la pagina di manutenzione sul server 4...) ovviamente ogni rilascio richiede un'ora e passa ed e' un miracolo se non si verifica nessun problema (il programmatroto tende a dimenticarsi i pezzi nelle query SQL per l'aggiornamento del database).
Poi veniamo informati che SL ed UL (che apparentemente sono l'intero IT) vogliono assumere un ruolo piu' "attivo" nella gestione della cosa per cui vogliono i diritti di eseguire rilasci e modifiche. Ovviamente questo fa' scattare una immediata uscita dei server incriminati dal monitoraggio 24x7 il che ha provocato non poche discussioni ovviamente.
Adesso siamo arrivati alla fase di 'transizione' tra il sistema vecchio e quello nuovo, non c'e' bisogno di dire che non appena il carico di lavoro ha cominciato a passare sul server Postgre, il load average a superato la soglia di guardia. Finalmente, dopo uno straziante tira-e-molla, SL ha acconsentito all'aggiunta di UNA cpu extra sul server (3 CPU... ma quando mai?) il che ha riportato il carico sui livelli di guardia ma non eccessivi. Poi oggi e' arrivata la novella che i server Windows verranno dismessi a fine settimana e tutto il carico passera' sui nuovi server. Dato che oramai quella roba e' solo in locazione (noi facciamo a malapena i normali updates dell'OS) non e' che la cosa mi preoccupi molto. Comunque per pura formalita' vado ad informarmi della cosa.
IO - ...quindi mi chiedevo come gestirsi il supporto dei server.
DB - Mah, l'unico supporto che forniamo adesso e' quello base dell'hardware
e dell'OS.
IO - Appunto. Non facciamo nemmeno piu' i backup perche' se ci proviamo il database diventa talmente lento che l'intera cosa si siede per terra.
DB - Si appunto... ma tanto il contratto e' stato modificato.
IO - E se ci sono problemi?
DB - Sono problemi loro. D'altra parte non mi aspetto che rimangano in funzione per molto.
IO - (drizzando le orecchie) Come?
DB - Mah sai... prima hanno cominciato a perdere clienti, poi hanno cominciato a perdere dipendenti che non sono stati sostituiti... adesso stanno cercando di tagliare i costi...
IO - Piu' tagliati di cosi'...
DB - Appunto. Quindi non mi aspetto che rimangano in vita molto a lungo.
Per la serie "avevano tante ambizioni". Ma la cosa che mi lascia un pelo perplesso e': se fossero partiti con una analisi coerente fin dall'inizio, sarebbe andata diversamente?
Davide
23/04/2012 08:00
I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.
Di Guido postato il 23/04/2012 08:12
Classico esempio di problem solving alla microsoft. Non si riscrive l'applicazione in maniera migliore, si mette hardware più potente...
se pretendi di avereil 99% di uptime forse sarebbe il caso di badare anche alla QUALITA'... ma oggi non usa più...
-- salva un albero: mangia un castoro!
Di WM postato il 23/04/2012 08:37
>>Per la serie "avevano tante ambizioni". Ma la cosa che mi lascia un pelo perplesso e': se fossero partiti con una analisi coerente fin dall'inizio, sarebbe andata diversamente?
NO!
sono pessimista? forse. forse non avro' capito il problema, ma l' aria fritta prima o poi "finisce"
WM
-- WM
Di Anonymous coward postato il 23/04/2012 09:20
"vogliono assumere un ruolo piu' "attivo" nella gestione della cosa per cui vogliono i diritti di eseguire rilasci e modifiche"
che e' come dire che voglio operrmi da solo di appendicectomia o decidere al posto dell'architetto quali debbano essere i muri portanti di casa mia. Le ovvie conclusioni sono morte per setticemia nel primo caso e per crollo nel secondo.
E' bello vedere come vanno a gambe all'aria, visto che sono incapaci totali... e se anche il servizio fosse andato bene, dopo un po' se ne sarebbero venuti fuori con un altra ideona tipo alimentare i server tramite energia elettrica data dalle ruote di 100mila criceti delocalizzati in Cina.
Di questa gente qui non ne sentirete la mancanza, mi raccomando di farsi pagare le fatture in anticipo e la prima volta che non pagano tagliare via tutto, perche e' una perdita sicura in energia elettica ed ingombri.
-- Anonymous coward
Di Kurgan postato il 23/04/2012 11:35
Se avessero speso di piu` per il lavoro di programmazione (analisi e programmazione) magari adesso avrebbero un sistema che funziona, spendendo di meno in hardware. Ma immagino che abbiano scelto il fornitore del software semplicemente scegliendo l'offerta piu` bassa.
-- Il massimo danno con il minimo sforzo
Di Luca postato il 23/04/2012 11:42
Beh, siamo pronti a leggerci una storia con effetto 'sliding doors'
-- Luca
Di Anony-mous postato il 23/04/2012 11:52
> dire che MS SQL Server sia un database 'pesante' e' dire poco
in realtà Oracle è ben più pesante... il "problema" è che in Oracle ci mettono le mani in pochi e si presume che sia gente che ci sappia fare con i database, mentre con MS-SQL riescono a metterci le mani in molti, anche chi non sa bene cosa fare, il che non può che creare pesanti e mostruosi accrocchi. Il peggio però l'ho visto quando gente che ci capiva poco pretendeva di mettere in piedi qualcosa con Oracle.
Purtroppo MySQL manca di determinati strumenti
-- Anony-mous
@ Anony-mous Di Davide Bianchi postato il 24/04/2012 11:54
in realtà Oracle è ben più pesante.
Dissento, ho visto oracle funzionare decentemente con 512Mb di ram, ho visto SQL Server far sedere servers con 4Gb di ram
Purtroppo MySQL manca di determinati strumenti
Putrtroppo MySQL e' e rimane un giocattolo. Bello, ma sempre giocattolo.
-- Davide Bianchi
Di Erik postato il 23/04/2012 11:57
"Poi hanno cominciato ad avere problemi con la quantita' (per non parlare della qualita')"
"Qualche altra cosa mi fa pensare che la 'ditta di sviluppo' e' composta dal programmatroto e dal di lui cane (il quale pero' non scrive codice purtroppo)."
FANTASTICHE!!!!
Sto ancora ridendo
-- Erik
Di spacexplorer postato il 23/04/2012 13:05
Hum... Tagliare costi e Windows mi pare un ossimoro...
A parte questo; ma hai trovato da qualche parte una soluzione software custom,
che sia un gestionale, un porcale di qualche genere, quel che ti pare che non
sia fatto coi piedi di un gatto ubriaco deambulante su una tastiera?
Comincio a sentirmi un po' solo...
-- spacexplorer
Di Messer Franz postato il 23/04/2012 13:14
Adesso spiego cosa succede di solito; si parte con un'analisi coerente.
Analisi coerente :
punto 1)abbiamo dei soldi da far fruttare
punto 2)TIENTELI E FATTI UN VIAGGIO ALLE MALDIVE INVECE DI FARE DITTE DEL C...avolo!
Questa soluzione spesso viene però scartata.
Analisi un po' meno coerente :
punto 1)abbiamo dei soldi da far fruttare
punto 2)usiamoli anzitutto per aggiungerci una CPU funzionante nella scatola cranica prima di fare qualsiasi altra cosa
E anche questa analisi viene scartata.
Analisi vagamente coerente :
punto 1)abbiamo dei soldi da far fruttare
punto 2)assumiamo gente capace che sappia fare cio' che noi evidentemente non sappiamo fare nemmeno di striscio
Domanda : se non sai farlo , come puoi giudicare chi assumi?E anche questa analisi va nel cestino della spazzatura
Analisi per niente coerente:
punto 1)abbiamo dei soldi da far fruttare
punto 2)Allegria! Indotto! Gioia-eterna-che-mai-finira'! Che puo' mai andar male?Non sappiamo niente , non capiamo niente (appunto) ma tutto andra' bene! Scegliamo i dipendenti piu' esperti in buzzword ( che di certo vuole dire "i piu' esperti in assoluto in tutto " ) e diamogli carta bianca e carta moneta!
punto 3)morte e disperazione
punto 4) The (usual) end
E questo e' quanto.
-- Messer Franz
Di marco panino postato il 23/04/2012 13:55
"...altrimenti tirano giu' il database che manda in coma l'applicazione C..."
Quanto si vede che non sei Guybrush Threepwood!
-- marco panino
@ marco panino Di Davide Bianchi postato il 24/04/2012 11:51
Quanto si vede che non sei Guybrush Threepwood!
A dispetto di quello che pensa un sacco di gente io sono un essere umano vero, non il personaggio di un cartone animato (o di un videogame).
-- Davide Bianchi
Di Lazy-LuKe postato il 23/04/2012 16:09
"Qualche altra cosa mi fa pensare che la 'ditta di sviluppo' e' composta dal programmatroto e dal di lui cane (il quale pero' non scrive codice purtroppo)."
HAHAHAHA - questa frase la rubero' per descrivere molte ditte Ns. clienti :)
-- Lazy-LuKe
Di Anonymous coward postato il 23/04/2012 17:16
Cavolo, se tagliano li' qui che dovrebbe accadere? Che tristita'
-- Anonymous coward
Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.
Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.
Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".