Che tipo di garanzie si usa per evitare accidentalmente apportare modifiche indesiderate al vostro ambiente di produzione?

Question

Perché non abbiamo un buon ambiente di staging spesso siamo costretti a problemi di debug sui nostri sistemi di produzione. Abbiamo web, applicazioni e server di database.

Che tipo di garanzie si usa per evitare accidentalmente apportare modifiche indesiderate nell'ambiente di produzione quando si fa questo?

---

EDIT:

L'applicazione è molto complessa B2B di applicazioni web in verticale. Ci sono un sacco di dati coinvolti. Alcune tabelle hanno quasi 100 milioni di dischi.

---

EDIT:

L'ambiente di staging che abbiamo in atto non ha la capacità di rispecchiare produzione. Ci sono anche centinaia di gigabyte di file di dati coinvolti oltre ai dati database effettivo.

---

EDIT:

Facciamo utilizzare controllo del codice sorgente per il codice, ma non per le stored procedure. Ci sono alcuni vecchi stored procedure in controllo del codice sorgente, ma nessuno tiene più così aggiornato.

Le preoccupazioni principali sono la base di dati e di dati nel file system.

A proposito, io sono un consulente di questa azienda, non è un dipendente vero e proprio.

Answer 1

La risposta più diretta è: "Non farlo".

Answer 2

controllo del codice sorgente. niente come un rollback quando le cose per irreparabilmente sbagliato. Inoltre, un diff può aiutare a replicare le modifiche ad altri sistemi di produzione.

Answer 3

Le nuove versioni di produzione vanno via i nostri sistemi di ragazzi, i programmatori e gli sviluppatori possono richiedere solo per rendere il loro nuovo sistema di andare a vivere, è necessaria l'approvazione pure, e ci mostrano che ogni cambiamento che è stato fatto è stato testato (includendo un un'istantanea di tutto ciò che è stato testato in questa versione nella richiesta di produzione).

Manteniamo le precedenti release di produzione per ripiego in caso di problemi.

Se le cose si rompono (che non dovrebbero fare spesso con una corretta procedura di test e rilascia gestiti) allora possiamo neanche ripristinare o hotfix. Spesso, quando le cose sono rotti nel vivo e la correzione è piccolo, siamo in grado di hotfix, quindi spostare la correzione di testare per fare un test vero e proprio.

In ogni caso, a volte le cose si fanno da ...

Answer 4

consentono solo determinati account accesso in scrittura, in modo da effettuare il log in modo diverso per fare un cambiamento

sul server web, hanno due strutture di directory, che rispecchiano l'un l'altro, quella in cui un solo ID può scrivere, l'altro dir messa in scena, tutti possono scrivere.

sul server di database, hanno un db di produzione, dove solo un ID può scrivere, avere un db messa in scena in cui tutti possono scrivere. DB messa in scena può avere backup notturno restaurato ad esso.

Tuttavia, se si dispone di un cattivo query o qualche risorsa porco nelle vostre risorse di sistema di gestione temporanea sarà tirato dalla produzione, e la macchina potrebbe bloccarsi.

Answer 5

per i server Web e di applicazioni, vorrei provare a copiare l'ambiente in una nuova posizione (ma lo stesso ambiente) e hanno le persone colpite riprodurre il problema sulla copia. Questo almeno vi darà un livello di separazione da accidentalmente avvitamento con il 100% dei vostri clienti.

Per i server di database, vorrei configurare gli account utente sul sistema di produzione per dare loro leggere solo diritti.

Answer 6

account di sola lettura / Guest. Sul serio. E 'la stessa ragione per cui non sempre login come root o amministratore.

Answer 7

Questa è una cosa difficile, e va con il territorio di "no ambiente di staging".

Per molte ragioni, è meglio avere una dedicata (duplicato) di CODICE è possibile utilizzare per stage distribuisce in ... ed eseguire il debug, ma so che a volte quando stai partendo che non funziona fuori il più rapidamente o accuratamente come noi vorremmo.

Una cosa che ho visto di lavoro è l'uso di macchine virtuali: a parte l'ambiente di debug, è possibile creare un mini-PROD in una macchina virtuale e l'uso che per eseguire il debug. Questo può non essere pratico dato il tipo di applicazione che si sta sviluppando, in modo particolare ulteriore in quella zona sarebbe utile.

Per quanto riguarda evitare modifiche CODICE durante il debug: c'è una ragione avresti bisogno di cambiare nulla per facilitare il debug? Se è così, che potrebbe essere la pena di guardare nel risolvere un altro modo.

Answer 8

Il controllo delle versioni è immensamente utile per controllare le modifiche agli ambienti di produzione - solo rendere il vostro ambiente di produzione di una copia di lavoro della directory o le directory appropriata dal repository. Quando si tira fuori un aggiornamento, il sistema di controllo di origine assicura che tutti i file modificati vengono copiati. Quando un aggiornamento rompe qualcosa, si può rotolare la produzione copia di lavoro di nuovo all'ultima revisione che non era rotto. Inoltre, è possibile controllare la vostra produzione WC fuori da un tag invece che dal tronco; in questo modo si può decidere quali revisioni repository da applicare nell'ambiente di produzione, regolando il tag.

Se non hai familiarità con i concetti di sistemi di controllo versione, vi consiglio di fare qualche ricerca. Sono concettualmente complessa ma incredibilmente utile e potente. L'articolo di Wikipedia è un buon punto di partenza: http://en.wikipedia.org/wiki/Revision_control

Answer 9

Mi dispiace, è necessario disporre di un ambiente di staging. Non c'è niente da fare intorno a questo. Se significa che devi abbattere le dimensioni dei set di dati, quindi questo è quello che devi fare. Utilizzare VMware e VMware Converter per importare i sistemi di produzione durante il down-periodi, se li avete (questo è un processo molte ore al giorno, quindi forse non è pratico).

Ci sono una certa classe di problemi non si possono risolvere senza avere pieno accesso alla produzione DB (o una copia), la prestazione è uno di questi. Ma si dovrebbe costruire un ambiente di staging, anche se è sulla macchina desktop di qualcuno con un insieme di dati ridotta.

A parte questo, ho dovuto vivere la mia vita con alcuni di questi in passato, e in realtà, non c'è niente che tu possa fare se non un sacco di backup. Ogni modifica apportata deve essere preceduto da backup incrementali. In questo modo se si fubar'd qualcosa, l'importo che hai perso, non è sostanziale. SQL server può prendere backup differenziali che limitano quantità di spazio su disco utilizzato per i backup. Oracle può pure.

Answer 10

Nel caso in cui davvero non hanno altra scelta, ed è probabile che sia una situazione cronica ... considerare l'aggiunta di qualche modo per i dati delle applicazioni (file, o database) per segnalare una serie di dati come 'per favore Dio non fare effettivamente cambiare attivamente stato di produzione con questi dati', combinata con i dati dump in posizioni critiche in un processo quando viene attivato questo flag, si può essere in grado di esercitare maggior parte della logica produzione senza dati effettivamente venire impegnata.