Capire il problema quando le cose si rompono in produzione

Raccogli tutte le informazioni sul problema che puoi (file di log, ecc.) e quindi ripristina i server di produzione in uno stato funzionante. Questo è un problema dal punto di vista dello sviluppatore, ovviamente, ma è probabilmente un dato di fatto.

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

Se non riesci a riprodurlo, controlla se è possibile aggiungere più diagnostica e release su un server per un breve periodo di tempo per ottenere ulteriori informazioni sul problema.

Se ciò non è possibile, guarda più da vicino le differenze tra la produzione e gli ambienti dev / qa e prova a rendere un ambiente di sviluppo più vicino alla produzione.

Come bene capisci il problema? Qual è il rischio che la tua impressione possa peggiorare le cose? È possibile tornare indietro e riprodurre il problema nelle regioni DEV / QA? Cosa puoi fare per sincronizzare la tua regione DEV / QA per avvicinarti a PROD? Forse devi modificare alcune impostazioni ambientali o di database, forse devi importare i dati PROD in DEV, forse devi modificare alcune impostazioni di debug.

In generale, vorrei non consigliare di inviare la tua intuizione di una soluzione a PROD a meno che tu non possa confermare che è effettivamente corretto in un'altra regione. Capisco il tipo di problemi che si presentano quando un bug si verifica in PROD e non può essere riprodotto da nessun'altra parte. Questo è quando si tratta di vedere cosa altro differisce tra DEV / QA e PROD e si concentra 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 da sopra per sistemare questo, quindi è possibile tornare al precedente stato di lavoro e quindi provare a riprodurre il problema in DEV, trovare un correggere in DEV, e quindi riprovare in PROD? Questo è quello che suggerirei.

Dipende dal tipo di correzione. Nella maggior parte dei casi, problemi di produzione che non compaiono in dev sono legati alla contesa nel database. Quindi, applicare un bug che modifica il contenuto del database senza essere sicuro di cosa sia esattamente "là fuori" potrebbe essere un primo passo in un grande disastro. Se puoi facilmente riprenderti, potresti provare in giro. 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 privilegi giusti 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 proibiscono tale configurazione)

È davvero difficile, dal momento che ci sono molte possibilità come impostazioni, librerie e versioni di software differenti.

Forse puoi scrivere prima una parte di codice che valuta con qualche output di debug se la tua ipotesi sull'origine del bug era corretta e solo allora applica la correzione effettiva.

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 lo stato di avanzamento della tua applicazione, può farlo essere nel DB, i file, ecc. Ha senso o no? È quello che tu aspettarci?

Una volta capito cosa sta succedendo, è necessario riportare la produzione a uno stato operativo e lavorare per risolvere il problema in un ambiente più basso, fino a quando non viene risolto e ri-distribuito alla produzione.

Mentre il tuo ambiente è PHP, ho fatto una presentazione su come pensarci per Java: link

I problemi principali sono gli stessi: capire i possibili punti di strozzatura per risolvere la situazione: rete, accesso al file system, file di registro, deadlock, ecc. Inoltre, sapere come porre le domande giuste: "Sistema inattivo" - "Cosa in particolare intendi: la pagina web è lenta, c'è un messaggio di errore specifico, c'è un timeout ", ecc.

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

Per quanto riguarda l'accesso alla produzione, il gruppo operativo deve sapere come utilizzare questi strumenti / tecniche o se ha un business case per loro (insieme a te) per imparare come usarli. Dopodiché, hanno bisogno di un set specifico di protocolli di risoluzione dei problemi da eseguire quando si verifica un problema, quindi puoi eseguire l'analisi offline.

Risposta breve: non se hai una scelta.

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

1. Potresti rompere qualcos'altro, che potrebbe anche essere meno riproducibile.
2. Potresti semplicemente mascherare il problema, rendendo più difficile notarlo e riprodurlo (il che lo rende peggiore)
3. Stai buttando via la potenziale esperienza domestica - esperienza che potrebbe renderti un programmatore migliore e allo stesso tempo più prezioso per la tua azienda (vale a dire un potenziale aumento futuro).

D'altra parte, non vedo alcun danno nel verificare prima se la tua soluzione ipotizzata funziona, e se lo fa - allora scavare più a fondo e scoprire la vera ragione o altri modi forse migliori per risolvere il problema problema.