Al momento ho il compito di fare da baby-sitter a un sistema ETL batch business critical, interrogare il database di questo sistema ogni mattina per incongruenze e rieseguire i lavori che hanno fallito.
Non sono il progettista originale del sistema o del database, ma ho apportato diverse modifiche ad entrambi e sono ragionevolmente a mio agio con il codice base e il modello dati.
Il sistema ha una reputazione per essere inaffidabile. Sono stati apportati miglioramenti, ma siamo ancora lontani dal raggiungere gli obiettivi da raggiungere. Ciò ha portato a problemi di fiducia sia per il sistema che per il team coinvolto. Quindi, ora il sistema ha una baby-sitter che si assicura che si comportino bene ogni mattina mentre lavoriamo per indurirlo.
Con questo in mente, mi sono imbattuto in un dilemma sul quale la mia squadra è divisa. Ogni volta che il sistema mostra incongruenze o esecuzioni fallite, con quale rapidità e severità dovremmo suonare l'allarme?
Ecco i fattori che sono entrati nella discussione finora:
- Se non sappiamo che cosa sta causando un sintomo, ma il sintomo sembra grave, non smetteremo di suonare l'allarme, o suoneremo l'allarme con una gravità minore finché non ne conosciamo la causa e scopriamo che è davvero così grave?
- Diciamo di conoscere la causa di qualcosa che causa un sintomo e il sintomo è grave. Abbiamo una strategia per mitigare quel sintomo, ma la soluzione ha la possibilità di uno o più fallimenti prima di un successo, e richiederà tuttavia del tempo per implementarla. Continuiamo a suonare l'allarme grave finché non completiamo i passaggi di attenuazione e continuiamo a vedere i dati andare lateralmente?
- Diciamo di conoscere la causa di qualcosa che causa un sintomo, ma la causa è fuori dal nostro controllo e non saremo in grado di mitigare il sintomo finché la causa non verrà corretta da una terza parte. Questo merita la stessa severità di allarme come se la perdita di dati fosse responsabilità del nostro codice.
- Se suoniamo troppo spesso i falsi allarmi, corriamo il rischio di perdere ancora più fiducia, perché ora sembriamo incompetenti riguardo alle modalità di errore del nostro sistema. Vale la pena ritardare gli allarmi, o moderare la loro gravità, per evitare di perdere la fiducia nella nostra capacità di sapere quando e come il nostro sistema si sta rompendo? Seguire gli allarmi di gravità elevata per ridurre il livello di gravità a sufficienza, o il danno è già stato fatto quando si è spento l'allarme grave?
Il motivo per cui lo chiedo è perché stamattina ho sentito che si trattava di un falso allarme, a causa di alcuni dati che inizialmente sembravano essere ben lontani da quello che mi aspettavo. Ulteriori ricerche hanno dimostrato che si trattava solo di una corsa contro dati insoliti, e quindi l'incoerenza che vedevo era prevedibile. Insieme a questo, ho dovuto tornare indietro e rieseguire alcune cose che non sono andate a buon fine, e ho dovuto aspettare che queste finissero prima che i miei controlli di coerenza dei dati significassero qualcosa.
Un altro membro del mio team mi ha chiamato su questo, e ha fatto il punto che non avrei dovuto suonare l'allarme, e avrei dovuto o non aver detto nulla fino a quando non ero sicuro, o aver riportato uno stato meno grave finché non ero sicuro che i dati erano in uno stato gravemente compromesso e che era nostra responsabilità che fosse così. In tal modo, non mi sto aiutando a ripristinare la fiducia.
Pertanto, con questo in mente, vorrei porre le seguenti domande: quando suoneresti gli allarmi e con quale gravità , per problemi di lavoro in batch come quello che descrivo sopra, sapendo che ha una storia di problemi? Inoltre, ci concentriamo sulle cose sbagliate nel ricostruire la fiducia cercando di assicurare che mandiamo gli allarmi il meno possibile ?