La cultura della “pezza”..ovvero come rimandare i problemi…

… già perchè quando di domenica ti alzi la mattina (anche se era pomeriggio), ed in sequenza fulmini le lampadine dell’antibagno prima e del bagno dopo, rendendoti conto di esserti giocato le uniche due lampadine della casa che sono dentro un lucernario, capisci che il bastardo fato ha in serbo per te simpatiche sorprese…

Come dite?? Vedo solo il peggio delle cose? Solo il bicchiere mezzo vuoto? Sarà…ma a me l’esperienza insegna…

Stamani infatti era il gran giorno, lo switch ufficiale di tutto il sito di $cliente dalla singola macchina al cluster di 4 macchine OCFS.

Entro in ufficio rilassato e garrulo (povero stolto) e cinque minuto dopo essermi seduto arriva pure il capo, senza nemmeno togliersi zaino e sistemarsi inizia:

Boss: Oggi c’è lo switch di $cliente, Ale puoi occupartene tu?
IO: Se proprio devo…
Boss: E si mi sembri la persona più adatta a farlo

(Davvero? e io che pensavo che copiare qualche file non richiedesse chi sa quali competenze)

Avendo vinto il concorso mi rassegno e capisco che il fato di cui sopra mi riservava proprio questa sorpresa, si perchè dovete sapere che ogni volta che c’è da fare qualcosa per $cliente, questa non va mai liscia. Io sono convinto che sia colpa degli sviluppatori, ma non lo sapremo mai.

Chiedo quindi conferma che tutti si siano staccati dalle macchine perchè non voglio dover riallinearle dopo aver finito la procedura, il boss mi assicura di si, quindi si inizia, mi connetto a tutte le macchine che mi servono..

Ma visto che ci sono facciamo un bel backup va…

Il mio amico rsync mi da una grossa mano e quindi in pochi minuti le 4 macchine sono uguali all’attuale macchina che ha erogato fino a ieri.

IO: Ok fatto le ho allineate, quando mi danno l’ok ricarico i bilanciatori cosi giriamo
il traffico.
Boss: Ah hai finito, ok spe che chiamo

Dopo nemmeno 3 secondi di telefonata Boss mi guarda con una faccia tra il disperato e un condannato a morte, io ad essere sincero avevo già capito tutto…

Boss: Ale per caso hai fatto il backup delle macchine prima di riallinearle??

Toh eccolo li, minchia come riesco a vedere nel futuro in queste cose, magari avessi le stesse capacità col superenalotto…

IO: Naturalmente si, me l’aspettavo una roba del genere perchè?
Boss: Perchè M dice che il war dell’applicazione deve essere quello che era prima in collaudo.
IO: EH??!! Cioè loro hanno rilasciato nelle macchine di collaudo anzichè in produzione??
Boss: Si M dice che c’era scritto anche nel ticket tutto quello che si doveva fare…
IO: Quale minchia di ticket??
Boss: Spe che vengo li vai su kronos

Ed effettivamente c’era un ticket aperto:

Lunedì mattina ore 9:00 switch del sito $cliente alla configurazione 4 macchine

mmm e chi l’aveva visto, apriamolo va…

Ciao,
lunedì mattina appena arrivati dobbiamo eseguire le operazioni di switch del sito $cliente
sulla nuova configruazione a 4 macchine.
Gli step da seguire saranno:
1) allargamento del volume della document library
2) allineamento della document library con quella di produzione attuale
3) allineamento del data base con quello di produzione attuale
4) a questo punto ci avviserete e noi rifaremo un giro di test sul sito,
se funziona tutto vi daremo l’ok per girare il bilanciatore sulla nuova configurazione.
Per qualsiasi cosa chiamatemi.

Grazie
M

IO: Ok punto uno fatto ieri, punto due
appena fatto, punto tre…non l’ho capito, perchè li dobbiamo
riallineare non possiamo semplicemente far puntare le macchine
al db di produzione?
E poi dove sta scritta sta cosa del war, tu la vedi? perchè se no ho problemi.

Boss: No non la vedo, e che ca$$o mi va dicendo allora M..
IO: Te l’ho detto che quelli non sanno nemmeno quello che stanno facendo..
Boss: Va beh per favore ripristinalo se no perdiamo tempo inutile
IO: Ok

Riprendo in mano il backup, ripristino, allineo le macchine e riavvio le applicazioni…

IO: Ok fatto adesso giro i bilanciatori…
Boss: NO SPETTA!! devono prima provare loro!!
IO: E mi spieghi come minchia fanno a provare se il bilanciatore non li manda
sulle 4 macchine?
Boss: perchè adesso come le raggiungono?
IO: Adesso NON le raggiungono perchè il bilanciatore reindirizza per $urldicollaudo
mentre adesso puntano al db che ha $urldiproduzione

E qui è doverosa la spiegazioncina, Liferay, vale a dire la merdavigliosa applicazione che mi ritrovo a dover gestire, non tiene il parametro che dice a quale url deve rispondere su un cristo di file di testo come tutti i CMS in circolazione, NO! lui lo vuole su DB, quindi se per caso devi cambiare il db come in questo caso, devi andare ad aggiornare la stringa su DB altrimenti il sito fa puff…ma questa riga al momento non potevo cambiarla perchè se l’avessi fatto avrei oscurato il sito che attualmente girava su una sola macchina, un bordello insomma come sicuramente avrete (non) capito.

Dopo smadonnamenti vari ed un numero imprecisato di seghe mentali si decide di cambiare l’impostazione dei bilanciatori, girare tutto il traffico e come va va…controllo che le applicazioni puntino al db corretto, le avvio, e procedo coi bilanciatori…

Boss: Ale hai fatto per caso?
IO: Si appena finito perchè?
Boss: Perchè non funziona una sega si vede "It Works"
IO: Errrr e come ca$$o e possibile…

Effettivamente digitando l’url mi compariva quella famosa pagina bianca con la scritta enorme "It Works", che spunta appena installato apache…

Eh it works un paio di balle, qui non "it works" veramente una sega…

fortunatamente avevo già lanciato tcpdump sulle macchine, e vedevo le chiamate arrivare, tali chiamate restituivano codice 200, il che sembrerebbe normale, se non fosse che con applicazioni java, ed usando quindi jkmount, deve prima restituire un 200, e poi un bel codice 301 di redirect permanente, questo perchè apache gira le chiamate al tomcat dell’applicazione java. Ed io di questo straca$$o di codice 301 non ne vedevo nemmeno il disegnino.

Ecco il problema, mi sono dimenticato di cambiare i virtual host di apache che testa di £$%& che sono.

Aggiustati i vari apache il sito ha ripreso a farsi vedere, missione compiuta…

Ho giusto il tempo di aprire una pagina web che il collega F mi chiama su jabber:

F: Ale stai lavorando tu su $db di $cliente?
IO: No non più, perchè?
F: Perchè nagios si incazza guarda gli allarmi…

** PROBLEM alert 1 – [fw-$cliente] scalesia/CHECK MYSQL-LOGIN is CRITICAL **

WTF??!! Ma se ci sono dentro….

Guardando l’allarme il mistero è svelato, l’errore che nagios riceve è "too many connections"…

O_O ma è impossibile….forse si è incartato…

Provo a riavviarlo e la shell inizia a ridermi in faccia.."Too many connections"..

IO: Non me lo fa riavviare giustamente
F: come non te lo fa riavviare
IO: eh si per farlo mysqladmin deve entrare per chiudere le tabelle e se non c’è posto…
F: Ma £$%&@# ma come ca$$o si fa a lavorare cosi…
F: quindi avevo ragione io
F: Quel ca$$o di parametro fa si che
F: se un povero £$%&@# si connette al sito apre una sessione su db di 7 ore!!
IO: Eggià si sapeva
F: Setta il max connections su 350 abbondiamo va…
IO: Si ma devo riavviarlo per farglielo prendere
F: No puoi darlo da shell (fortunatamente non avevo chiuso la shell che avevo aperto prima)
F: guarda devi fare questo..quello..quell’altro…e questo ancora..
IO: Ok fatto prova un pò
F: Allarme rientrato meno male, ricordati di allineare la replica..
IO: lol è una replica..è sempre allineata
F: Azz c’hai ragione

Risolta l’emergenza parte il debug, e la causa delle connessioni sono proprio le 4 macchine appena attivate, aprivano 103 connessioni (mysql di default ne accetta massimo 101) verso il db e le lasciavano li in stato "sleep"…tutto questo grazie al fantastico bugfix, che M e la sua cricca avevano partorito dopo intensi meeting sul problema.

Durante i momenti di panico, in cui non sapevamo se killare il processo di mysql, sapendo che avremmo spaccato qualche tabella, Boss ha avuto uno scambio di mail con M, infatti dopo 2 minuti mi vedo recapitare un forward nella Inbox: (non vi quoto tutta la mail perchè lunga, e perchè non ve ne frega una fava di tutta la discussione, sostanzialmente Boss segnalava il problema dicendo che ci sono una marea di connessioni in stato "sleep" sul db, e questo è male, vi quoto direttamente la risposta di M forwardata a noi)

Subject: [Fwd: Re: connesisoni DB x $cliente]
From: Boss
To: F, IO

——- Messaggio inoltrato ——-
Da: M
A: Boss
Oggetto: Re: connesisoni DB x $cliente

Io mi chiedo perché su due macchine non avevamo problemi e su quattro
sì. Noi eravamo già stati in cluster, giusto?
Stiamo guardando dei parametri da mettere nei file di configurazione,
speriamo risolvano il problema, adesso se due utenti accedono alla
stessa pagina vedono cose diverse.

A questo punto, complice la bassa simpatia che nutro nei confronti di M (e non sono l’unico), esplodo e rispondo con una mail-terrorista:

From: IO
To: Boss
CC: F
Subject: Re: [Fwd: Re: connesisoni DB x $cliente]

Perchè quando usavamo due macchine

1. Il numero degli accessi era molto minore
2. Liferay aveva molte meno modifiche
3. Se non ricordo male non c’era nemmeno il cms ancora
4. Non c’era il _fantastico_ bugfix che allungava a 7 ore la
connessine di hibernate
5. altro sicuramente che mi sto dimenticando…

qualcuno dovrebbe insegnargli che mantenere 7 ORE di connessione al db
non è di certo un bugfix efficace, quanto piuttosto un workaround di
dubbia utilità.
A questo punto anche io mi chiedo come mai col riavvio dell’applicazione
programmato non abbiamo mai avuto problemi, e guardacaso il db si è
piantato 5 minuti dopo aver switchato tutto il traffico sul nuovo cluster,
e col loro fantastico bugfix installato..

Dopo un pò di minuti ecco arrivare un nuovo ticket:

[Op #540] Modifica config Cluster $cliente

Boss: Ale ti ho aperto un ticket su $cliente, nuovo bugfix per il DB
IO: Si visto, ma perchè adesso dobbiamo anche aprigli i ticket, loro non lo fanno più?
Boss: si lo so gliel’ho detto e scritto..
IO: Come sempre parole al vento.
Boss: Ma tanto io non mi arrendo
IO: Ed intanto noi siamo qui ad aprire ticket per loro al posto loro…

Questo bugfix, contiene due stringhe da inserire nella configurazione dei Liferay, e non sembra essere un workaround degno del primo bugfix, questa volta è un pò più serio, confortato dalla cosa procedo e dopo polverizzo il ticket. Effettuando una verifica le connessioni da 94 scesero a 45, un buon risultato..

Minchia era ora che imparassero a fare una ricerchina con goorgle, a quest’ora un sacco di tempo e di bile sarebbero stati risparmiati..

Dopo questo bel travaso di bile, la giornata scorre normalmente, finchè non vedo (Durante la giornata lavorativa sto sempre con gli auricolari a palla perchè non voglio sentire) S la simpatica collega della storia di ieri, che si avvicina al nuovo assunto (G) guardandomi, al che capisco che c’è roba per me e mi tolgo un auricolare..

S: ..cosi e cosi..se no se hai difficoltà chiedi pure ad Ale che l’ha fatto
milioni di volte, e l’ha sbagliato puntualmente tutte le volte…
IO: O_o
G: Ok
IO: Scusa se l’ho sempre sbagliata cosa ca$$o lo mandi a fare da me

G non riusciva a fare funzionare delle stored procedure (SP) su DB, gli dico di venire da me che l’avremmo guardato insieme, controllando si accorge subito dell’errore, aveva sbagliato a dare le grants per l’utente sulle SP, riparato al volo anche questo guardo l’ora, 18:10 è il momento di rincasare…

Update:

La stesura di questo articolo (grazie alle voste gufate), stasera si estende perchè non appena mi siedo al pc mi contatta M:

M: Tu sei in ufficio?

guardo l’ora, 19:00, ma che sei scema per caso??!!

IO: no
M: Sei reperibile?

Lo odio quel ca$$o di sorrisino, ogni volta che mi chiami sono solo casini..

IO: Si sono io perchè?
M: no perché forse quando abbiamo finito l’allineamento dovremo riavviare le macchine
M: ma non adesso, tra dieci minuti
IO: scusa quale allineamento?
M: eh è una cosa lunga da spiegare
M: abbiamo ricreato le pagine del vecchio sito con una nuova struttura

WTF??!! Dopo tutti sti casini per rilasciare il nuovo sito, mi vieni a dire che hai ricostruito il vecchio??!! Ma che minchia gli prende al mondo, ma è possibile che sono solo io che vedo pazzie in queste cose??

IO: e necessariamente alle 19 bisogna fare il rilascio non si può fare domani?
IO: tanto non è bloccante
M: Veramente adesso è tutto giù
IO: O_o
M: Si
IO: Momento

firefox $urlsitocliente

Error: rimani di stucco, è un barbatrucco

ma come ca$$o hanno fatto a romperlo in un pomeriggio??!!

IO: E che è successo?
M: si tengono la cache del db
M: se tu potessi riavviarle adesso?

Si tengono la cache del db??! CHI si tiene sta ca$$o di cache e soprattutto PERCHE’

IO: spe sto stoppando i liferay
IO: ma come mai si è rotto? per curiosità
M: non si è rotto

Ah no??!! non mi pare che una pagina biancaa d’errore sia la home page del sito, questo significa una sola cosa R-O-T-T-O

M: è che da una delle macchina abbiamo cambiato il contenuto del db
M: e le altre si sono tenute la cache
M: almeno questo supponiamo
IO: ma dipende da quei parametri che mi avete fatto impostare pomeriggio?
M: no, dipende dai contenuti del db, cache del db; stai riavviando?
IO: Ma quale ca$$o di cache del db, il db mette in cache solo le query,
di modo che se tu ne rilanci una uguale dopo poco tempo non deve ricalcolarsela.
Cmq si sto riavviando.
M: no con hibernate non è così

E allora non dipende dalla cache del DB furba!!!! è la tua straca$$o di applicazione che fa cagare…

IO: Vai riavviato, io vedo index_old
M: riprova dovremmo avere sistemato
IO: Sempre index_old
M: pulisci cache e chiudi browser

Ciccia te l’ho insegnato io sto trucchetto non venire a farlo con me…

IO: Sempre index_old
M: Ma £$%&@#
M: spe
IO: Qua sono
M: in pratica hibernate per velocizzare le chiamate si cacha le tabelle
M: per spiegare la cosa di prima

Come volevasi dimostrare…è la tua applicazione di merda…

IO: e quindi se vuoi uploadate un contenuto
IO: la tabella non viene ricaricata
IO: furba come cosa
IO: vi conviene toglierlo
M: prova un pò
IO: ok vedo index e basta
M: andata, ok
IO: a posto quindi?
M: si grazie
IO: prego ciao.

Sarò prevenuto, ma nei parametri che oggi pomeriggio mi ha fatto impostare c’è:

net.sf.ehcache.configurationResourceName=/ehcache/hibernate-clustered.xml

siamo ancora sicuri che la causa non sia quest'altro merdaviglioso bugfix?? Bah, io intanto inizio a prendere dei caffè perchè mi sa che stanotte mi richiameranno...