Una cosa che puoi fare ora è verificare quali misure di sicurezza sono in atto. Questo mostra l'assunzione di responsabilità. La tua azienda dispone di backup recenti nel caso qualcosa vada storto? Puoi tu eseguire backup ad-hoc prima di modificare le parti critiche? Stai lavorando su sistemi di test e disponi di una buona procedura per implementare le modifiche nei sistemi live? Ecc.

Se mancano queste misure di sicurezza, richiedi di averle a disposizione.

A proposito, sono sorpreso che tu dica che stai lavorando con dati non recuperabili . Se è davvero così, è una bandiera rossa per l'azienda nel suo insieme. Niente (beh, il meno possibile) dovrebbe essere "irrecuperabile".

Non dovresti mai e poi mai modificare i dati di produzione irrecuperabili.

Non lo sottolineerò mai abbastanza. Dovresti essere disposto a prendere una posizione su questo. Se fossi in me, farei due richieste.

1. Che ci sono backup frequenti (idealmente, più di un set) eseguiti automaticamente. La frequenza dipende dalla sensibilità dei dati, ma direi almeno una volta al giorno. Il cliente sarà disposto ad accettare una settimana di dati persi se qualcosa va storto?

2. Che non sei tu a farlo. Questo è in realtà più importante, ma il primo dovrebbe essere ancora il caso. Tu, uno sviluppatore di software, non dovresti scherzare con i dati in tempo reale. Non conosco le dimensioni della tua azienda, ma lavoro in un'azienda di cinquanta e gli sviluppatori vengono rimproverati se interagiscono con il sistema live. Se hai un reparto di supporto, questo è il loro lavoro e dovresti, anche con i backup, sentirti a disagio nel toccare i dati in tempo reale. Il lavoro di sviluppo dovrebbe essere svolto solo su un sistema di sviluppo. Se è necessario fare qualcosa al sistema live, convincili a farlo, anche a costo dell'efficienza. Se necessario, fornire uno script ben collaudato. In genere, tuttavia, qualsiasi modifica dovrebbe avvenire solo quando tutti sono consapevoli che il sistema potrebbe non funzionare, quindi i clienti devono essere consapevoli di questa possibilità. Se è necessario che tu tocchi i dati in tempo reale come sviluppatore, non farlo senza backup, nemmeno qualcosa di piccolo.

Queste cose sono piuttosto semplici. Dovresti sempre considerare i potenziali effetti degli errori e fare tutto il possibile per ridurre al minimo tali rischi. Potrebbero sembrare eccessivamente cauti, ma se non prendi precauzioni, le conseguenze personali saranno molto maggiori se qualcosa va storto.

Prima di eseguire qualsiasi operazione che potrebbe causare la perdita di dati, è necessario assicurarsi di disporre di un piano di ripristino. Questo di solito significa eseguire un backup manuale del database prima di eseguire qualsiasi script SQL che modifica i dati. Ciò fa parte della tua responsabilità in quanto persona che esegue il lavoro.

La prossima volta che ti viene chiesto di svolgere tale lavoro, fai sapere al tuo manager di linea che farai un backup immediatamente prima di eseguire il modifica.

Nota a margine: è sempre utile racchiudere i tuoi script sql in BEGIN TRANSACTION .. ROLLBACK TRANSACTION per la prima volta che li esegui sui dati di produzione. Questo esegue lo script e mostra l'output, senza applicare effettivamente le modifiche. Questo fornisce una buona indicazione su quanti record verranno modificati e se ci saranno errori.

Rischio organizzativo e due diligence individuale

Se ho cancellato per errore alcuni dati importanti, cosa dovrei fare? Io sposto manualmente (utilizzando script SQL) le cose nel database qua e là.

La questione se l'azienda sta facendo la cosa giusta ™ apportando modifiche ai dati di produzione che non ha backup è davvero una decisione aziendale che è al di sopra del tuo paygrade. Sebbene tu possa certamente raccomandare di non farlo a causa dei rischi, sarei molto sorpreso se non fossero già consapevoli dei rischi e li considerassero rischi accettabili per l'azienda rispetto ai costi di fare qualcosa di sistemico al riguardo .

Da parte tua, dovresti eseguire i tuoi backup completi o parziali prima di apportare modifiche. Anche se potrebbe essere poco pratico eseguire il backup dell'intero sistema, puoi sicuramente eseguire il dump dei record che intendi modificare o dei file di configurazione che intendi modificare in modo da poterli ripristinare in caso di errore.

Questo non proteggerà da errori catastrofici (ad esempio, l'eliminazione dell'intero database, ad esempio), ma sicuramente assicurerebbe che se apporti modifiche al record 12345 puoi ripristinare quel record dopo aver apportato le modifiche se risultano le tue modifiche erano errati.

Ricorda solo che, sebbene tu abbia una responsabilità professionale di portare i rischi all'attenzione della tua direzione e di mitigarli così come sei in grado di lavoro, il team di gestione della tua organizzazione possiede effettivamente il 100% del rischio aziendale. Se hai svolto la dovuta diligenza al meglio delle tue capacità, qualsiasi rischio residuo ricade sull'organizzazione piuttosto che su di te.

In caso di incidente ...

Nel caso in cui qualcosa fa vada storto, la tua responsabilità professionale è informare immediatamente qualcuno che ha autorità. Dovresti far loro sapere cosa è successo, quali dati sono stati persi, cosa (se non altro) sei in grado di recuperare e offriti di aiutarti con eventuali sforzi di recupero aggiuntivi che potrebbero essere necessari.

Questi tipi di errori non dovrebbe essere coperto. Tuttavia, mentre dovresti essere responsabile di eventuali errori o errori che hai commesso, ricorda che la responsabilità di avere un sistema senza adeguate protezioni è un rischio che appartiene all'organizzazione, non a te. Assumiti la responsabilità della tua parte nell'incidente, ma non assumerti la colpa del fallimento di un sistema senza adeguate garanzie.

C'è una grande differenza tra assumersi la responsabilità e assumersi la colpa. Assicurati di accettare solo il primo e non il secondo, a meno che tu non abbia fatto veramente qualcosa di negligente.

In realtà ci sono due domande in una:

• chi dovrebbe essere responsabile delle modifiche nei dati di produzione?
• qual è il modo migliore per eseguire tali modifiche?

Consentitemi di affrontarli separatamente.

Chi dovrebbe essere responsabile delle modifiche ai dati di produzione?

Nessuna singola persona.

Qual è il modo in cui stai eseguendo il cambiamento; un cambiamento nella produzione (o in qualsiasi sistema sensibile) dovrebbe essere esaminato da almeno un'altra persona (esperta) e approvato da qualche manager.

Questo è lavoro di squadra e obbedisce alla catena di responsabilità. Quindi a questo punto, non importa se fai un errore:

1. Verrà applicato solo se qualcun altro lo ha esaminato (e non ha notato il problema)
2. Verrà applicato solo se un manager l'ha approvato (e se ne è assunto la responsabilità)

Se nessun manager è disposto ad assumersi la responsabilità del cambiamento, non eseguirlo.

Se le persone discutono sulla sensibilità temporale del cambiamento, dì loro che non si dovrebbe mai confondere essere veloci per correre . In realtà, vorrei sostenere la extra cura in caso di urgenza (un altro revisore, ad esempio), in particolare perché la pressione aumenta la possibilità di errori. È molto più veloce avere ragione la prima volta, piuttosto che fare confusione, ripulire il casino e infine eseguire la modifica.

Qual è il modo migliore per eseguire queste modifiche?

Idealmente :

• è disponibile un backup e c'è una procedura di ripristino
• la modifica viene eseguita tramite uno script, che è accompagnato da uno script di fallback controllato (*)

Ora, sfortunatamente, le condizioni non sono sempre ideali.

I backup sono buoni, ma in un ambiente live in cui i dati cambiano ogni secondo non è possibile mantenerli esattamente aggiornati; i backup possono essere utilizzati solo in caso di errori massicci e accettando che le ultime modifiche andranno perse. Questo è il motivo per cui non posso insistere abbastanza sullo scripting delle modifiche e sul controllo che lo script di fallback funzioni come previsto.

Alcune modifiche non possono essere annullate. Ad esempio, quando si rimuove una colonna, i dati in questa colonna non possono essere ripristinati in caso di problemi. Tali modifiche dovrebbero essere eseguite in due passaggi:

• in un primo passaggio, disabilitare l'accesso alla parte di dati che verrà eliminata, senza eliminarla effettivamente; nel caso della colonna, rinominala ad esempio. Questo passaggio può essere annullato.
• quindi, quando è stato accertato che la modifica era valida (diversi giorni o settimane sono trascorsi senza problemi), esegui la modifica non di riserva in uno script monouso

(*) Per controllare uno script di fallback, devi eseguire lo script su una copia del database reale, quindi applicare lo script di fallback e controllare che i dati siano tornati alla normalità.

(*) Ho visto il suggerimento di fare la modifica in una transazione; questo è insufficiente (cosa succede se ti rendi conto del tuo errore dopo il commit?), soggetto a contese (stai bloccando tutte le righe modificate finché non effettui il commit) e non sempre possibile (set di modifiche troppo grande / rischi di deadlock). Tuttavia, se possibile, utilizza le transazioni all'interno dello script poiché le modifiche eseguite a metà sono più difficili da ripiegare.

Se sei bloccato con questo sistema (e lo respingerei seriamente perché è estremamente rischioso e una cattiva pratica), questo è quello che farei.

Per prima cosa crea una tabella di backup per il dati che influenzerai (abbiamo un database zero per cose che possono essere utilizzate solo una volta). A seconda della dimensione dei dati, potresti voler creare un indice su questo)

Una volta che hai la tabella di backup, metti tutto in una transazione. Quindi, quando esegui la query per influenzare il join dei dati nella tabella di backup che hai creato.

Quando esegui, esegui un passaggio alla volta e prendi nota di quanti record ci sono nella tabella di staging, se i dati sono interessati nella query di azione non corrisponde al numero di record nella tabella, ti consigliamo di eseguire il rollback e poi capire perché.

Questo approccio ti offre anche la massima flessibilità per ripristinare se la modifica è stata negativa in quanto è più facile e generalmente più veloce aggiornare una tabella ai vecchi valori piuttosto che ripristinare l'intero database. E se solo pochi record sono stati modificati per errore, hai la possibilità di riportare solo quelli ai vecchi valori.

Un'alternativa a tutto questo è avere tabelle di audit che registrano tutte le modifiche. Tuttavia, è improbabile che tu abbia quelli se gli sviluppatori eseguono le cose direttamente in produzione. Personalmente non prenderò mai in considerazione la possibilità di avere un database senza l'audit perché è ottimo per correggere gli errori provenienti dall'interfaccia utente, nonché le importazioni di dati e gli script di azioni ad hoc che vengono eseguiti sul database, incluso il punto in cui i dati vengono modificati in modo dannoso. ma lavoro in un ambiente normativo in cui è un requisito.

Aggiunto in seguito Mi sono dimenticato di menzionare, chiedi a qualcun altro di rivedere il codice cosa stai facendo prima di farlo.

Sono abbastanza sicuro che tu ne sia consapevole, ma sottolineerò comunque l'ovvio: prova, prova e fai altri test. Ci sono così tante cose che possono andare storte se non si eseguono test adeguati, uno dei tanti è la rimozione accidentale dei dati. Imitando l'ambiente di produzione con dati effettivi, puoi eseguire test in un ambiente realistico e ridurre al minimo errori e bug.

Tieni presente che, anche dopo ore di test approfonditi, gli errori e accadrà . In tal caso, riferisci al tuo supervisore / manager e spiega. Se con qualsiasi mezzo il tuo codice interrompe una connessione al database, milioni di record che avrebbero dovuto essere inseriti andranno persi (solo un esempio, però). Se trovi un errore o sospetti un errore: fallo sapere alle persone .

Se devi fare QUALSIASI COSA in un sistema di produzione, fallo in una transazione. (Oppure lascia che sia un amministratore di database a farlo se ne hai uno)

Alcuni anni fa ho visto l'aspetto di orrore del mio capo mentre eseguiva un "semplice" aggiornamento su un database di produzione, senza un WHERE clausola.

Se avesse utilizzato una transazione, avrebbe potuto emettere un ROLLBACK e salvarsi una notte di panico nel recupero dei dati da un backup a un sistema di produzione ancora in esecuzione. (Il rollback avrebbe richiesto due secondi, non quattro ore ...)

(Sembra un cartone animato di Scott Adams, ma sì, l'ho visto accadere ...)

Un altro modo semplice per prevenire errori catastrofici è prendere l'abitudine di aggiungere un'istruzione limite (ad es. limite 1; se stai cambiando solo un record).

Quindi, se stai modificando qualcosa come una tabella utente, anche se hai dimenticato una clausola WHERE come ha fatto il capo di @ tim, sbaglieresti solo un record utente e non ogni singolo record utente.