Comprensione del problema quando le cose si rompono nella produzione

24

Scenario:

Spingi alla produzione
La spinta ha rotto più cose
Quella stessa build non ha rotto qa o dev
Come sviluppatore, non hai accesso prod.
C'è molta pressione dall'alto per far funzionare le cose agian.

specifiche:

Applicazione PHP / MVC basata su API in Zend.
Distribuito su alcuni server.

La mia domanda:

Durante le indagini, diciamo che ho la sensazione che qualcosa non vada. Ma non lo so per certo. E, naturalmente, non posso testare le cose in produzione. Se ho una soluzione suggerita basata su quell'intuizione, sarebbe saggio provare ad applicarla e vedere se funziona, prima di capire qual è il problema?

bug production

— bitcycle
fonte

24

Se non ha interrotto DEV o QA, ma ha interrotto la produzione, di solito è un problema di configurazione.

— Mike L.

4

Anche se potresti non avere personalmente accesso alla produzione, dovresti avere un membro del team operativo che può essere i tuoi occhi e le tue mani per risolvere i problemi.

— shufler,

3

Hai escluso problemi di configurazione, ad esempio l'accesso al database o le autorizzazioni di rete che possono essere utilizzati nella nuova versione?

— JB King,

7

@MikeL. O dati corrotti che non esistono in sviluppo o QA.

— maple_shaft

3

@shufler - Negli Stati Uniti, Sarbanes – Oxley Act (aka SOX) richiede che gli sviluppatori non abbiano accesso alla produzione in società quotate in borsa. Alcune aziende hanno le proprie politiche interne che limitano l'accesso. Questi di solito entrano in vigore dopo che uno sviluppatore fa crollare l'intero sistema in base a un sospetto.

— jfrankcarr,

33

Raccogliere quante più informazioni possibili sul problema (file di registro, ecc.), Quindi ripristinare i server di produzione su uno stato funzionante. Questo è un dolore dal punto di vista dello sviluppatore ovviamente, ma molto probabilmente è un dato di fatto.

Quindi, prova a vedere se riesci a riprodurre il problema in un ambiente di sviluppo. Se puoi, correggilo e prova a rilasciare di nuovo.

Se non riesci a riprodurlo, verifica se è possibile aggiungere più diagnostica e rilasciarla a un server per un breve periodo per ottenere ulteriori informazioni sul problema.

Se ciò non è possibile, osserva più da vicino le differenze tra la produzione e gli ambienti dev / qa e cerca di avvicinare l'ambiente di sviluppo alla produzione.

— Chris Card
fonte

4

Quanto bene capisci il problema? Qual è il rischio che il tuo sospetto peggiori le cose? È possibile tornare indietro e riprodurre il problema nelle regioni DEV / QA? Cosa puoi fare per sincronizzare la tua regione DEV / QA per avvicinarla a PROD? Forse devi modificare alcune impostazioni ambientali o del database, forse devi importare i dati PROD su DEV, forse devi cambiare alcune impostazioni di debug.

In generale, non consiglierei di inviare la tua idea di una soluzione a PROD a meno che tu non possa confermare che è effettivamente corretta in un'altra regione. Comprendo il tipo di problemi che si presentano quando si verifica un bug in PROD e non possono essere riprodotti altrove. Questo è quando si tratta di vedere cos'altro differisce tra DEV / QA e PROD e concentrarsi su quelli. Nella mia esperienza, di solito è un'impostazione ambientale o una configurazione diversa, in particolare per PROD. E so che probabilmente c'è molta pressione dall'alto per risolvere questo problema, quindi è possibile tornare allo stato di lavoro precedente e quindi provare a riprodurre il problema in DEV, trovare una correzione in DEV e quindi provare di nuovo in PROD? Questo è quello che suggerirei.

— FrustratedWithFormsDesigner
fonte

5

Sicuramente non vuoi applicare una correzione a un pugno rotto che non sai per certo che la risolverà; questo probabilmente lo spezzerà di più! Meglio tornare a uno stato stabile e lavorare nel controllo qualità dove c'è meno pressione per farlo bene la prima e unica volta.

— Michael K,

2

Dipende dal tipo di correzione. Il più delle volte, i problemi di produzione che non compaiono in sviluppo sono correlati a contendersi nel database. Quindi applicare un bug che modifica il contenuto del database senza essere sicuri di cosa sia esattamente "là fuori" potrebbe essere il primo passo in un grande disastro. Se riesci facilmente a riprendere la modifica, potresti essere in grado di provare. Ma in generale, se non si ha accesso diretto, dovrebbe esserci almeno una copia del database o dell'intero server per i test. Le persone con i giusti privilegi dovrebbero comunque eseguire il nuovo codice, ma almeno senza il rischio di perdita di dati. (Ma a volte le dimensioni del database o la complessità dell'infrastruttura vietano tale configurazione)

È davvero difficile, poiché ci sono molte possibilità come impostazioni diverse, librerie e versioni di software.

Forse puoi prima scrivere un pezzo di codice che valuti con qualche output di debug se la tua ipotesi per l'origine del bug era corretta e solo allora applichi il corretto bugfix.

— Thorsten Müller
fonte

1

Di solito si tratta di problemi di configurazione o di dati, supponendo che il codice e il DB siano identici tra Prod, QA e dev.

Vorrei prima esaminare quanto segue:

Tutti i dati di registrazione del tuo codice.
Controlla il visualizzatore eventi per le eccezioni non gestite.
Controlla i dati che rappresentano l'avanzamento della tua applicazione, possono trovarsi nel DB, nei file, ecc. Ha senso o no? È quello che ti aspetti?

Una volta capito cosa sta succedendo, è necessario ripristinare la produzione a uno stato funzionante e lavorare per risolvere il problema in un ambiente inferiore, fino a quando non viene risolto e reimplementato nella produzione.

— La vita è più di questo
fonte

0

Mentre il tuo ambiente è PHP, ho fatto una presentazione su come pensarci per Java: http://www.infoq.com/presentations/maintain-production-java-apps

I problemi principali sono gli stessi: capire i possibili punti di strozzamento per risolvere la situazione: rete, accesso al filesystem, file di registro, deadlock, ecc. Inoltre, sapere come porre le domande giuste: "Sistema spento" - "Cosa specificatamente fai significa: la pagina web è lenta, c'è un messaggio di errore specifico, c'è un timeout ", ecc.

Inoltre ci sono alcuni strumenti per facilitare la risoluzione dei problemi: Wireshark per la risoluzione dei problemi di rete è il migliore in assoluto e vale la pena imparare. Altri dipendono dall'O / S che usi. Per Windows, qualsiasi cosa da SysInternal (ora parte di Microsoft) è geniale. Per Unix / Linux, guarda truss / strace.

All'accesso alla produzione, il gruppo operativo dovrebbe sapere come usare quegli strumenti / tecniche o hai un business case per loro (insieme a te) per imparare come usarli. Successivamente, hanno bisogno di un set specifico di protocolli di risoluzione dei problemi da eseguire quando si verifica un problema, in modo da poter eseguire l'analisi offline.

— Alexandre Rafalovitch
fonte

0

Risposta breve: non se hai una scelta.

Risposta lunga: se non capisci il problema, ci sono diversi rischi coinvolti in una tale patch:

Potresti rompere qualcos'altro, che potrebbe anche essere meno riproducibile.
Potresti semplicemente mascherare il problema, rendendo più difficile notare e riprodurre (il che peggiora)
Stai gettando via la potenziale esperienza domestica - esperienza che potrebbe renderti un programmatore migliore e allo stesso tempo più prezioso per la tua azienda (ovvero un potenziale aumento futuro).

D'altra parte, non vedo alcun danno nel controllare prima se la tua ipotetica correzione funziona e se funziona, quindi scava più a fondo e scopri il vero motivo o altri modi forse migliori per risolvere il problema.

— Yam Marcovic
fonte