Ricerca in FOLBlog

SdSM

Le avventure e le peripezie di un SysAdmin

[SdSM] Curare e’ sempre meglio che prevenire

 Scritto da alle 06:27 del 07/04/2013  1 Risposta »
Apr 072013
 

Siamo a parlare di architettura. No, non il tipo di architettura che specifica come costruire un palazzo in modo che vinca premi su premi anche se sembra vomitato dagli alieni e nessuno vuole viverci anche solo vicino, si tratta di architettura di sistema ovviamente.

Taaaaaaanto tempo fa quando ero giovane, imbecille e con tanti capelli (adesso sono solo imbecille), la regola aurea insegnata e ripetuta era: sedetevi con una penna ed un foglio di carta e fate funzionare il cervello: cercate di immaginarvi cosa puo’ andare male e scegliete una architettura che a) risolva i vostri problemi e b) eviti di schiantarsi miserandamente quando una o piu’ di quelle cose brutte e cattive succedono. Questo tipo di modus operandi ha portato a cose come il protocollo TCP/IP, SCSI et similia. Poi e’ successo qualche cosa, credo che la “vecchia” generazione di ingegnieri, quelli che si ingegniavano, sia andata in pensione ed una nuova generazione, ammaliata dalla tecnologia, l’abbia sostituita. Questi ultimi hanno probabilmente pensato: “fuckoff pensare e’ difficile ed e’ noioso, le penne e la carta sono superate, la nostra tecnologia e’ invincibile, se ci sono problemi basta buttarci piu’ risorse per risolverli”. Il risultato di questo metodo di pensiero sono cose come il sistema ferroviario/autostradale (sempre prossimi al collasso e perennemente in fase di ristrutturazione).

Ovviamente io non mi occupo dell’architettura in grande stile, al massimo posso addocchiare l’architettura della nostra di rete e di solito l’effetto che mi fa e’ di farmi produrre un suono tipo “Mehoooowwwwwww….” con facepalm incorporato. Per esempio, per qualche strano motivo tutte le macchine sono dotate di un IP pubblico (anche quelle che non hanno nessun motivo di averlo perche’ non dovrebbero MAI essere disponibili su interdet, tipo database server). Per qualche altro strano motivo tuttavia, tutte le macchine hanno come unico gateway UN firewall. Uno solo. Ok, e’ ridondato (nel senso che c’e’ una seconda macchina che sarebbe li’ pronta a sostituirla nel caso di un patatrac) me e’ un solo firewall, non c’e’ load balancer. Il che significa anche che, avendo certi servizi unici, lo scambio da ‘attivo’ a ‘passivo’ e’ solo manuale (no, non cominciate a commentare, e’ cosi’ e basta. Non l’ho fatto io il sistema). Ovviamente, grazie al principio del “basta buttare risorse al problema”, nessuno ha mai pensato di fare una mini-analisi di quanto e’ il carico massimo che e’ possibile attaccare a questo famoso e solitario firewall prima che se ne vada in coma profondo, l’ipotesi era (probabilmente) che “quando ci arriveremo butteremo li’ un firewall piu’ grosso”. Bhe’, quel giorno e’ oggi.

Sono le 2 del mattino di domenica, quando il famosissimo e famigerato pager si mette a suonare segnalandomi che 280 servers sono improvvisamente in coma. Io balzo fuori dal letto accendo il lapdog e cerco di capire che accidenti sta succedendo. Un rapido controllo mi dice che il firewall non accetta piu’ connessioni. Subdorando problemi di capacita’ mi collego al secondario, balzo sullo switch e faccio un rapido controllo. Yep! Il foxxuto backup e’ in pieno svolgimento e questo semplicemente sta sovraccaricando la capacita’ del firewall.

Un altro rapido controllo mi dice anche che se lo lascio cosi’ ci sono ben poche possibilita’ che il backup vada a termine prima delle 8 del mattino. Quindi rapida decisione: ammazzo il backup. Dopo un giro di kill che neanche un’assassino professionista se lo sogna il firewall ripiglia un pelo di energia e le cose cominciano a rimettersi in sesto. I problemi adesso sono che 1) diversi servers avranno cominciato a notificare i vari SL/UL che sono stati ‘down’ per un certo periodo di tempo (quale migliore sistema di notificare il proprio proprietario che si e’ morti se non mandare una mail? No, non rispondete), 2) alcuni di questi cosi hanno dischi in condivisione su altri sistemi e con molta probabilita quei dischi sono adesso off-line 3) la settimana prossima succedera’ esattamente la stessa identica cosa. Il che ci lascia due scelte: “buttare altre risorse” al problema o cambiare drasticamente la struttura dell’intero sistema.

Dopo aver risolto il punto 2) sopra (dato che non posso fare un tubo riguardo 1) e 3) ) ed aver scritto il rapportino di “incidente” e marcato le mie ore extra me ne torno a letto. Al lunedi’ ovviamente siamo tutto a consulto con il grande capo. Il guaio e’ che non pare voler capire che il problema non e’ a “one time freaky thing” ma e’ strutturale.

DB – Quindi il problema e’ risolto.
IO – Ma risolto un ca$$o! Il problema e’ che il firewall ha raggiunto la sua capacita’ di carico massima e basta un minimo di sollecitazione per portarlo al collasso. Come avevo detto quando mi venne presentata la situazione piu’ di un anno fa. E’ solo questione di tempo.
DB – Ma adesso funziona tutto no?
IO – E continuera’ a funzionare se non succede niente fino a domenica, quando si inchiodera’ di nuovo tutto nel momento in cui il backup inizia a girare.
DB – (guardando P) Non possiamo far girare il backup in un’orario diverso?
P – Hummm… si credo sia possibile magari anticipandolo di mezz’ora…
IO – Cosi’ anticipi o posticipi solo il momento in cui il firewall entra in crisi. Il punto e’ che abbiamo troppi sistemi attaccati dietro a quel firewall che non dovrebbe nemmeno essere li’ per prima cosa.
P – Ma ci serve un firewall!
IO – E su questo siamo anche d’accordo. Ma il 90% delle macchine dietro a quel firewall sono Linux ed hanno gia’ un indirizzo IP pubblico: mettiamo un firewall sulla singola macchina ed evitiamo di far passare tutte le connessioni da un unico collo di bottiglia. In questo modo riduciamo il carico del firewall del 90% in un botto solo. Lasciamo le macchine Windows sul firewall (dato che non mi fido di quel coso di windows manco un po’). E magari si potrebbe pensare a come implementare un Out-of-band network per il backup e la manutenzione.
(P e DB si guardano stralunati come a dire “ma che sta a di’ questo?”) P – No guarda, tu non hai idea di come e’ strutturata la rete…
IO – Il che e’ possibilissimo dato che qui si attua una decisa separazione delle competenze, ma da quello che posso vedere spostare l’ora di esecuzione del backup non risolvera’ il problema. Il problema non e’ il backup o la capacita’ del firewall, il problema e’ che la rete e’ strutturata con troppi colli di bottiglia e troppi single-point-of-failure. C’e’ un firewall dietro al quale c’e’ uno switch dietro al quale ci sono ‘n’ servers. Il che significa che abbiamo due colli di bottiglia e due single-point-of-failure. I server virtuali girano su un host, altro collo di bottiglia e single-point-of-failure, ed i loro dischi sono volumi logici su un SAN che e’ collegato tramite un altro switch. Se uno di questi elementi ha un problema, come e’ gia’ capitato con quel disco sifulo sul SAN, l’intero sistema ne risente.
P – Ma il sistema e’ stato progettato in modo da richiedere il minimo di manutenzione!
IO – E allora spiegami come mai sto accumulando ore extra di recupero per allarmi ad orari assurdi. O forse per te “minimo di manutenzione” significa che puoi impostare una cosa in 2 minuti e poi perdere 40 ore alla settimana, tutte le settimane, per tenerla in piedi? Io preferisco metterci 40 ore per impostare qualche cosa e poi dimenticarmela perche’ sta in piedi da sola.
DB – Vabbe’, questi sono punti di vista (me pensa: e gia’…) in ogni caso non possiamo di certo metterci adesso a rifare tutto l’architettura (me pensa: senno dovresti ammettere che quello precedente era una chiavica?), quindi dobbiamo trovare una soluzione al problema. Io direi di sostituire il firewall. Mettiamone uno piu’ potente e prestante con una maggiore capacita’ e finita li’ (me pensa: che t’avevo detto io?).
IO – Guarda che se aumenti semplicemente la capacita’ finisci per ritrovarti con lo stesso identico problema ma aumentato del fatto che hai molte piu’ macchine/collo di bottiglia che vengono affette quando il sistema crolla.
DB – E piantiamola li’.

E cosi’ comincia l’odissea di ‘sostituire il firewall’ che regge l’intera baracca.

Ovviamente la mia idea di installare il nuovo firewall come secondario di quello esitente e poi fare un fallback in modo che il nuovo diventi primario e poter (eventualmente) ritornare a quello vecchio se qualche cosa non funziona e’ stata cassata immediatamente da P che preferisce “soluzioni pratiche”, aka: sostituire di botto entrambi i firewall in un colpo solo.

Il che si e’ tramutato in una all-night alla colo per sincronizzare il duo. Il giorno dopo P ha scoperto sulla sua pelle che la nuova versione di SSH installata su questo firewall manda in coma il firmware dello switch primario dietro al firewall stesso. Che gioia.

Davide

legenda personaggi

  • Facebook
  • Twitter
  • Delicious
  • StumbleUpon
  • Wikio
  • Reddit
  • Technorati
  • Segnalo
  • Live
  • Add to favorites
  • Email
  • RSS

[SdSM] TecnicaMENTE

 Scritto da alle 06:27 del 28/02/2013  2 Risposte »
Feb 282013
 

cervello

Ci sono persone che riescono a parlare di roba che non capiscono in maniera tale che sembrano degli esperti, almeno ai non-esperti. Ci sono anche persone che riescono a parlare di roba che capiscono e conoscono in maniera tale che sembrano dei completi interdetti, agli esperti ed ai non esperti. E ci sono poi persone che non capiscono e non conoscono un argomento ma si intestardiscono a riempirsi la testa di articoli e nozioni e cercano poi di riversare le loro idee su persone che capiscono e conoscono l’argomento. Il risultato e’ prevedibile.

Il grosso problema e’ che se non si conosce o capisce un argomento e’ molto difficile distinguere tra un articolo che e’ una pila di cazzate ed un articolo serio. Soprattutto quando chi legge si e’ gia’ fatto una idea di cosa dovrebbe esserci scritto ed invece di leggere quello che c’e’ scritto lo interpreta liberamente. Di solito (non so bene perche’) quelli che cascano in questa categoria sono UL ed SL vari.

Ok, fine del preambolo. Ritorniamo a parlare di $noiguardiamolavostrarobba di cui ho gia’ detto precedentemente. L’SL superstite (nel senso che e’ l’unico rimasto in forze) e’ impegnato a cercare di rimanere a galla e cacciare via i piranha che si aggirano. Per fare cio’ sta cercando di spremere tutta la potenza che puo’ dalla webapplicascion che costituisce l’unica sua fonte di guadagno. Il che e’ cosa buona e giusta se non fosse che l’applicascion e’ stata scritta da un programmatroto che non ha mai letto nessun manuale di programmazione. Una delle prime cose che io mi ricordo dei miei studi di programmazione di rete sono le seguenti regolette:

  1. La rete e’ fallibile – fallira’ quando meno te lo aspetti o piu’ ti serve. Regolati di conseguenza
  2. Le risorse (memoria, processore, disco) non sono infinite, usale con parsimonia e rilasciale quando non ti servono
  3. La rete e’ lenta. Non provare a fare cose in ‘real time’ perche’ non funziona.

Che, lette cosi’, sembrano estremamente logiche. Ma andate a dirlo ad un moderno programmatroto ‘agile’, ‘flexible’ e robe cosi’ o al di lui capo e vi guardera’ come un marziano.

Il risultato e’ che l’applicascion assume che a) ogni connessione vada a termine in 0 nanosecondi b) si puo’ allocare un infinita quantita’ di memoria, disco e connessioni di rete e c) non c’e’ bisogno di fare nessun controllo che le connessioni siano terminate correttamente. Il che assicura una marea di problemi. Come il fatto che una certa parte dell’applicascion deve essere riavviata giornalmente o crasha miserabilmente (di solito tra le 2 e le 3 del mattino) per out of memory.

Il rifacimento dell’intera webapplicascion dovrebbe anche risolvere certi “problemi di allocazione delle risorse”. Ed in effetti una parte dei problemi vengono ridotti. Solo che SL comincia a prendere un’interesse quasi morboso nella “ottimizzazione” delle risorse. In particolare si mette a guardare cose di cui non capisce un tubo. Per esempio, dato che il suo sistema e’ basato su un ‘server’ che riceve connessioni ed inserisce i dati in un database, diventa quasi nevrastenico al pensiero che il database “rimanga indietro”.

Arriva pertanto una prima mail che domanda come si puo’ “ottimizzare” il database. La mia risposta e’ che non sapendo un tubo di come il database sia utilizzato dall’applicazione e’ impossibile dare indicazioni precise. Ma dato che ho capito che questi pisquani cercano di infilare i dati il piu’ in fretta possibile, a parer mio l’uso di un database -server- SQL sia una boiata e sarebbe molto meglio usare un database file-based o nessun database e poi riprocessare i dati off-line per poter analizzare le informazioni con comodo. Devo supporre che questo suggerimento sia entrato da un orecchio ed uscito dall’altro senza minimamente disturbare una delle migliaia di cellule cerebrali all’interno del cranio perche’ un paio di ore dopo mi e’ arrivata una seconda mail (quotando in toto la mia precedente) con un paio di link ad articoli di ‘ottimizzazione’ dei database scritti dai soliti noti di interdet e riportanti suggerimenti tanto innoqui quanto inutili. Okkido’ mister, NMP!

Ovviamente le ‘ottimizzazioni’ non hanno alcun risultato ma se non altro SL e’ contento ed ha esaurito le sue ore di assistenza gratuita per questo mese quindi mi rilasso fino al mese prossimo. E dato che hanno deciso che i rilasci li vogliono fare da soli non mi preoccupo nemmeno piu’ di quando le loro applicascion si incartano.

Poi arriva il momento in cui l’SL vede il grafico del ‘load average’ del suo server e si spaventa a vedere un L.A. tra 4 e 5. Ora, premetto che un L.A. di 5 con una macchina biprocessore potrebbe anche essere considerato ‘alto’, ma io ho visto macchine monoprocessore con un load average di 20 andare avanti tranquille per dei mesi, quindi non e’ che mi preoccupo moltissimo. Soprattutto dato che sto coso va’ a “raffiche”, ogni tanto si becca la raffica di connessioni e fa qualche cosa ma per il resto del tempo sta li’ a girarsi i pollici. Ma spiegarlo all’SL della situazione e’ praticamente impossibile.

Comunque sia, soppesando il costo di aggiungere una cpu al sistema (50 euro) ed il costo di continuare a fare il pieno al Volvo StascionUagon per un altro paio di giorni decide di rischiare e mettere la CPU. Mi ritrovo cosi’ a vedere un server con 3 cpu (!). Vabbe’…

Tuttavia il capitale investimento non ha gli effetti che l’SL sperava. In particolare il load average rimane piu’ o meno lo stesso. Percui mi becco l’odierna telefonata.

SL – Ma io mi chiedevo, le CPU che abbiamo aggiunto sono dualcore?
IO – E’ una macchina virtuale quindi LA cpu che abbiamo aggiunto e’ UNA cpu e basta, non essitono dual core.
SL – Ma se io guardo la descrizione della cpu in cosiliproc…
IO – Quello e’ come la cpu si presenta al sistema ed il sistema riporta quello che vede e basta, ma e’ UNA cpu e basta.
SL – Ma se e’ dual core allora…
IO – E’ una macchina virtuale, l’hardware virtuale puo’ avere qualsiasi nome e non significa nulla. La Cpu e’ UNA cpu e basta.
SL – Perche’ se io guardo il load average allora devo dividerlo per 6 o per 12?
IO – ??? Che ? Il load average che c’entra adesso?
SL – Perche’ io stavo leggendo questo articolo che…

Mi faccio mandare link del famoso articolo che risulta essere una roba che sembra messa insieme da un laureando in storia dell’architettura che ha incespicato su una rivista di informatica mentre broccolava studentesse nei pressi dell’aula magna, l’unica cosa giusta che dice e’ una descrizione di che cosa il load average indica (cosa che puo’ essere estratta da qualunque ‘howto’ o ‘readme’ sulla rete) ma a parte questo nada. Soprattutto fornisce indicazioni sul ‘quanto’ dovrebbe essere il load average che non hanno alcun senso. Dopo aver madonnato contro chi scrive articoli del genere e chi li legge senza capirli mi preparo a spiegare le cose all’SL.

SL – Quindi devo dividere il load per 6?
IO – Il load puoi dividerlo per quanto ti pare ma ci sono sempre e solo 3 cpu in quel coso. Ed il load non significa niente da solo. Il load e’ solamente una indicazione di quanti processi concorrenti vengono eseguiti, non ti dice cosa quei processi stanno facendo. Non puoi fare ottimizzazione di un sistema guardando solo un elemento del sistema.
SL – Perche’ io vedo che il database non resta indietro…
IO – E perche’ dovrebbe restare indietro?
SL – Perche’ il server e’ troppo carico…
IO – Un load di 5 su un server, anche se avesse un solo processore non significa niente. Soprattutto dato che quello e’ l’average di 5 minuti. Come ho gia’ detto, non si possono fare ottimizzazioni guardando un solo parametro.
SL – Ma quell’articolo…
IO – Oltre a leggere l’articolo sarebbe bene anche leggere i commenti, soprattutto gli ultimi che lo tagliano a fettine con ottimi argomenti tecnici.
SL – Ma io non sono un tecnico
E questo lo avevamo capito tutti
SL – Ed e’ per questo che domando a voi.
IO – Ed io ho risposto: il load average non significa nulla se non viene guardato insieme ad altri parametri. In questo caso quella macchina non si puo’ considerare ‘carica’.
SL – Quindi voi non consigliate di aggiungere processori?
IO – Al momento no. Ovviamente solo voi sapete cosa volete farci con questa macchina, se sia il caso di aggiungere processori adesso o aspettare.

Dopo un lungo tira-e-molla con SL che mi recita parti dell’articolo ed io che gli ri-spiego daccapo la faccenda, SL si convince che puo’ aspettare ancora un po’ e si rimette tranquillo. Ora, io lo so gia’ che la settimana prossima ricomincera’ a farsi venire le paturnie quando comincera’ a pensare allo spazio libero sui dischi. Lasciamo perdere che lo spazio libero e’ lo stesso dall’inizio dell’anno. Certa gente proprio non dovrebbe occuparsi di problemi tecnici. Manco un po’.

Davide

legenda personaggi

  • Facebook
  • Twitter
  • Delicious
  • StumbleUpon
  • Wikio
  • Reddit
  • Technorati
  • Segnalo
  • Live
  • Add to favorites
  • Email
  • RSS

[SdSM] Money for (almost) Nothing

 Scritto da alle 06:27 del 03/02/2013  1 Risposta »
Feb 032013
 

Moneydownthedrain

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 24×7 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

legenda personaggi

  • Facebook
  • Twitter
  • Delicious
  • StumbleUpon
  • Wikio
  • Reddit
  • Technorati
  • Segnalo
  • Live
  • Add to favorites
  • Email
  • RSS

[SdSM] NON E’ come magia!

 Scritto da alle 06:27 del 23/01/2013  Nessuna risposta »
Gen 232013
 

possible

Avevo gia’ spiegato come per molta gente gran parte dell’informatica e’ come magia. E c’e’ gente che ‘ci crede’ a questa cosa al punto che pensa che qualsiasi cosa possa essere ottenuta semplicemente usando il giusto incantesimo. Che in genere consiste nel tirare su il telefono e dire al SysAdmin di turno “voglio questo”. In alcuni (rari) casi e’ anche necessario mandare una mail, soprattutto quando il sysadmin in questione e’ nel mezzo di un qualche casino e non ha il tempo di risolvere il problema all’istante.

Solo che, a dispetto di cio’ che questa gente pensa… l’informatica NON E’ come magia! Ok, loro non lo capiscono come funziona e non gliene frega niente di capirlo e questo posso anche accettarlo, non scusarlo ma accettarlo si. Ma qualche volta gradirei che capissero che “non si puo’ fare” non significa “sara’ fatto istantaneamente se lo domandi al mio capo”.

Ok, ritorniamo a bomba. Abbiamo gia’ parlato a sufficienza credo di $noicifacciamogliaffarivostri. Adesso questo branco di rimba ha deciso di buttarsi sull’ultimissimissima fad internettiana: il sito mobile. Che in genere non vuole dire altro che una versione ridotta e rimpicciolita del sito normale. Solo che, per qualche strano motivo (digestione difficile probabilmente), il SEO del momento ha deciso che la cosa migliore sarebbe che se l’utonto visita il sito con un dispositivo ‘mobile’ (aka: telefono o tablet) dovrebbe essere automaticamente spedito alla versione ‘mobile’ del sito stesso. Il che potrebbe anche non essere troppo sbagliato.

Ora, io ho fatto subito presente che la cosa e’ fattibile ma potrebbe avere delle conseguenze inattese, prima tra tutte che occorre fare una bella lista di tutti gli ‘user agents’ usati dai vari cellofoni e softwerofoni vari e mantenere la foxxuta lista in modo che ogni volta che esce una nuova versione di questo o quel cellofonino (aka ogni 2 giorni) la lista sia aggiornata. Avevo anche fatto presente che, data la struttura del loro sito, una volta che la redirezione e’ implementata non c’e’ modo di tornare indietro. Cioe’ l’utente ‘mobile’ si becchera’ sempre e solo la versione ‘mobile’ (no, non cominciate a commentare. E’ cosi’ e basta).

Come atteso, l’UL della situazione ha ignorato completamente i miei commenti ed ha cominciato a blaterale di “user experience” e “forward-thinking” e “customers oriented” e tante altre cagate che sospetto che non abbia la piu’ pallida idea di cosa significano ma fanno tanto “new-management”.

Detto fatto, aggiungo le quattro righe di codice per fare il controllo e redirigere il tutto, poi chiudo gli occhi, mi infilo le dita nelle orecchie ed aspetto il botto… che non si fa attendere troppo. Il mattino dopo mi arriva la prima mail che cita “problemi”. QUale problema? Che nella versione ‘mobile’ del sito apparentemente questi azzoppati hanno un bellissimo link che dice “vai alla versione normale del sito”. Ma ovviamente, dato che la redirezione ignora gli URL e guarda solo l’user-agent, una volta che sei nella versione ‘mobile’ non ne esci piu’ (come avevo fatto notare all’inizio). Ovviamente la cosa non e’ gradita e non e’ sufficiente che io “lo avessi detto”.

Ed ovviamente non e’ che possono accettare la mia spiegazione, apparentemente questa gente pensa veramente che l’informatica sia praticamente magia (anzi peggio: stregoneria) percui loro vorrebbero che il sistema “telepaticamente” capisse cosa vuole l’utente ed andasse sul sito giusto.

Dopo una lunga e complicata spiegazione (mi e’ venuto per un po’ l’impulso di attribuire l’impossibilita’ a fare quello che questi rintronati vogliono a forze soprannaturali o goblins…) i rintronati decidono di ‘rimuovere’ tutto e ritornare al funzionamento ‘normale’. Almeno per un po’.

Due ore dopo mi arriva una ennesima mail dal solito UL che domanda -a me- come possono replicare il funzionamento di $notositodinews in cui, apparentemente tutto funziona come loro vorrebbero. Un rapido giro sul sito dei tizi mi dice che (1) la versione di sito mobile/immobile e’ controllata da un parametro dell’applicazione, il che significa che io posso avere la versione ‘mobile’ su qualunque dispositivo, non solo su un dispotivo mobile e (2) apparentemente non usano un proxy o probabilmente non come lo usiamo noi, il che lascia l’applicazione libera di smandrupparsi lo User-Agent come meglio crede.

E adesso aspetto che arrivi il prossimo capitolo del tormentone quando chiederanno perche’ noi non possiamo fare nello stesso modo. Ritengo che “e’ stato un mago” non sara’ una risposta accettata pero’.

Davide

legenda personaggi

  • Facebook
  • Twitter
  • Delicious
  • StumbleUpon
  • Wikio
  • Reddit
  • Technorati
  • Segnalo
  • Live
  • Add to favorites
  • Email
  • RSS

[SdSM] La Regola Numero Uno

 Scritto da alle 06:27 del 05/01/2013  1 Risposta »
Gen 052013
 

number_1

La Regola Numero Uno dice che “Un problema intermittente e la cui causa e’ non specificata e’ impossibile da risolvere”. E questo in genere capita sempre su sistemi del cappero il di cui proprietario in genere non vuole spendere un centesimo piu’ del necessario ed e’ uso tenere aperto un browser 24 ore su 24 sul sito e schissare ‘refresh’ ogni 30 secondi per assicurarsi che il sito sia sempre ben visibile. Il che significa che quando il sito ha un hiccup lui e’ al telefono prima ancora che il nostro monitor di sistema si sia reso conto che c’e’ qualche cosa che non va. Lasciamo perdere che 9 volte su 10 il sito funziona benissimo.

La Regola Numero Uno dice che “I programmatori non hanno mai toccato niente, il sito non e’ stato mai modificato e nessuno sa nulla”. Ovviamente. Perche’ senno’ sarebbe troppo facile.

La Regola Numero Uno dice che “Le applicazioncine del ca$$o che hanno sempre funzionato cominceranno a non funzionare piu’ quando il cliente invia una mail a 30.000 destinatari per promuovere i suoi nuovi servizi”. Ovviamente senza informarci prima del fatto e senza tenere conto che la sua applicazioncina del ca$$o e’ ospitata su un sito che il Commodore 64 al confronto era un supercomputer.

La Regola Numero Uno dice che “Il cliente di cui sopra comincera’ a tempestare di telefonate il supporto tennico ancora prima che tale supporto tennico abbia avuto il tempo di domandarsi che accidenti e’ questo server e di chi e’“. Perche’ ovviamente noi dovremmo conoscere a memoria ogni singola applicazioncina del ca$$o che gira su questo coso.

La Regola Numero Uno dice che “Dopo aver avviato il tcpdump, tracing, controllo statistico etc. per cercare di diagnosticare il problema sul sito, tale problema non si verifichera’ piu’ per le successive 19 ore”. Per poi ritornare puntualmente non appena pensi che “forse era un qualche accrocchio sul routing” e morderti le chiappe a tradimento.

La Regola Numero Uno dice che “Quando, dopo ore ed ore di verifiche, becchi un IP che apre 230 SYN senza mandare piu’ un pacchetto che e’ uno al server e riempie completamente la tabella delle connessioni di Apache scoprirai che quell’IP appartiene al Cliente che sta facendo delle prove di funzionamento del sito”. E guarda caso ha cominciato a fare le prove di funzionamento il giorno stesso che ha mandato il mailing per “verificare il carico del server”.

La Regola Numero Uno dice che “Se il SysAdmin cerca di spiegare le intricazioni del tcp/ip al cliente quello liquidera’ l’intera faccenda sostenendo che il sysadmin sta cercando scappatoie per non dimostrare la propria incompetenza nel risolvere il problema” e non che sta semplicemente cercando di spiegare al cliente che lo stesso cliente sta eseguendo un DDOS sul suo stesso server.

La Regola Numero Uno dice che “Applicare caching, proxy, ridurre timeout, aumentare il numero di thread etc. sulla suddetta applicazione servira’ solo a rendere il client piu’ fiducioso sul numero di ‘test’ contemporanei che puo’ eseguire”. Il che significa anche che aumenteranno il numero di casini che si verificano, soprattutto tra le 20.30 e le 4 del mattino, quando il SysAdmin vorrebbe dormire o comunque non pensare ai casini del suddetto cliente.

La Regola Numero Uno dice che “Dopo aver accettato (mugugnando) di disattivare il famoso test per un intero week-end, e non aver sofferto piu’ nemmeno un problema per tutto il tempo, il Cliente di cui sopra insistera’ comunque in un ulteriore test da condurre nottetempo (per evitare problemi con i suoi clienti ovviamente), il tutto senza informare il sysadmin della cosa”. Provocando una feroce incazzatura nel suddetto sysadmin che avrebbe voluto dormirsela della grossa.

La Regola Numero Uno dice che “Non si puo’ dire al cliente di andare a fan…”.

La Regola Numero Uno dice che “E’ sempre colpa del sysadmin”.

Davide

legenda personaggi

  • Facebook
  • Twitter
  • Delicious
  • StumbleUpon
  • Wikio
  • Reddit
  • Technorati
  • Segnalo
  • Live
  • Add to favorites
  • Email
  • RSS

[SdSM] Perche’ siamo scemi…

 Scritto da alle 06:27 del 29/12/2012  Nessuna risposta »
Dic 292012
 

allarme

Era una notte buia e tempestosa… No, in effetti era una notte chiara, stellata e tranquilla! Ed all’improvviso non risuono’ uno sparo (come nella migliore tradizione narrativa) ma risuono’ un cellofono! In questo caso, il cellofono riservato alle ‘emergenze’.

Ebbene si’. E’ la fottuta settimana di “Stand by” ed io sono il pinguino di turno. Il fottuto arnese comincia a suonare, io lo acchiappo, lo fermo ed accendo la luce per vedere che cazzo vuole, e li’ sullo schermino mi compare la scrittina “DNS server XXXX unreachable” e subito sotto l’ora: 02.32. Bello. Ok, che accidenti e’ il server XXX?

Uscito dal letto sveglio il lapdog dal suo standby e mi metto a cercare cosa e’ il server in questione. Risulta essere uno dei server di una qualche ditta per la quale facciamo servizio di hosting. Il che significa che il server e’ nel nostro rack ed attaccato alla nostra rete ma li’ ci si ferma. Un rapido controllo mi dice che la porta dello switch e’ on, i pacchetti vanno dentro e fuori ma apparentemente non c’e’ risposta dal servizio DNS. Nella mia documentazione non compare nessuna informazione utile, non ho una password per accedere al server ed apparentemente non accetta ne’ RDP ne’ SSH.

Ok, e’ il momento di cominciare la procedura di “escalation”. Il che significa che sfodero il cellofono e schisso il tasto “chiama il capo”. Ovviamente becco la segreteria telefonica, gli lascio un messaggio e mentre aspetto controllo lo storico del server. A quanto pare e’ stato installato un paio di mesi fa e non ha dato nessun problema fino ad ora. Noi non abbiamo mai avuto un account su quel coso che e’ interamente gestito da $ditta (della quale mi pare di ricordare che il loro sysadmin e’ uno che ci sa fare). Mi viene il vago dubbio del perche’ quel coso sia nel nostro monitor e soprattutto perche’ in 24×7.

Dopo un (bel) po’ il cellofono risuona ed e’ il capo, che suona un po’ come un orso addormentato.

DB – Che succede?
IO – Ho un allarme dal server XXX per il servizio DNS, ma non ho nessuna login su quel server per verificare. Il server sembra up ma il servizio non risponde.
DB – Huh? Non puoi riavviarlo?
IO – Potrei staccargli e riattacargli la corrente ma dubito che funzioni.
DB – Heeee.. ma di chi e’ quel server? Nostro?
IO – No, e’ di $ditta.
DB – Haaaa.. aspetta, adesso mi ricordo. Lo abbiamo messo li’ temporaneamente mentre loro sistemavano la loro colo… pero’ non mi ricordo che cosa c’era che andava su quel coso.
IO – Bhe, se P ha inserito un controllo sul servizio DNS suppongo che un DNS ci fosse su questo arnese. Solo che adesso o non risponde o non risponde a noi.
DB – Ah be… mandagli una mail ed informali.
IO – Questo coso e’ in supporto 24×7. Non hanno un numero di emergenza?
DB – Non credo.
IO – E allora perche’ e’ in 24×7?
DB – Perche’ ci pagano.
IO – …ci pagano per mandargli una mail?
DB – Mmmm… non ricordo i dettagli della cosa, magari la vediamo domani in ufficio.
IO – Fammi capire: io sono stato tirato giu’ dal letto alle 2 e mezza del mattino per mandare una mail?
DB – Bhe’ il contratto…
IO – Un servizio sul quale non abbiamo nessun controllo non dovrebbe essere in 24×7! Che stracazzo devo fare io adesso con questo allarme?
DB – Disattivalo. E comunque tu hai tirato anche me giu’ dal letto.
IO – Mal comune mezzo gaudio. Il contratto lo hai proposto tu a sta gente vero? E dato che sei tu che hai insistito sull’importanza della “escalation” dei problemi mi pareva giusto metterti a conoscenza della cosa.
DB – Vabbe’, al momento disattiva quell’allarme. Domani vedremo che ci dicono.

Dopo aver disattivato l’allarme, aggiunto nella lista degli “incidenti” il problema, riportato mezz’ora di “recupero” nell’apposita tabella e rimesso il pc in stand-by me ne ritorno a letto. Tanto lo so gia’ che domani mattina qualcuno si incazzera’ perche’ noi (aka: io) non abbiamo risolto il problema subito e verranno citati danni per mancato rispetto del contratto eccetera eccetera.

Il giorno dopo, verso le 10 mi arriva una telefonata da $ditta nella persona di BOB.

BOB – Hallo, chiamo per il nostro server XXX che e’ nella vostra co-lo…
IO – Ah! Allora avete capito che cosa era il problema?
BOB – …problema? che problema?
IO – Che stanotte ha smesso di rispondere tirandomi giu’ dal letto per esempio?
BOB – Hu… Stanotte ho spento il servizio, si’. Perche’ domani vendiamo a prendercelo per metterlo nella nostra co-lo, volevo infatti prendere un appuntamento per ritirarlo. In che senso “tirato giu’ dal letto”?
IO – Nel senso che il nostro monitor ha cominciato a suonare.
BOB – Monitor? Ma voi monitorate quel coso?
IO – Purtroppo si. Non dovremmo?
BOB – Hmmm… No. Dato che non dovreste avere nessun account sul server quindi anche se fosse non potreste fare nulla, e noi lo controlliamo gia’ per conto nostro. Perche’ lo monitorate anche voi?
IO – Qualche cosa mi dice che l’unica risposta che posso dare alla domanda e’ “perche’ siamo scemi”.

Eh si’. Qualche volta si’.

Davide

legenda personaggi

  • Facebook
  • Twitter
  • Delicious
  • StumbleUpon
  • Wikio
  • Reddit
  • Technorati
  • Segnalo
  • Live
  • Add to favorites
  • Email
  • RSS