¿Qué tipo de garantías que utiliza para evitar que accidentalmente haciendo cambios no deseados en su entorno de producción?

Question

Debido a que no tenemos un buen entorno de ensayo a menudo tenemos que depurar problemas en nuestros sistemas de producción. Tenemos web, aplicaciones y servidores de bases de datos.

¿Qué tipo de garantías que utiliza para evitar que accidentalmente cambios no deseados en su entorno de producción cuando se hace esto?

---

EDIT:

La aplicación es una aplicación web B2B verticales muy complejo. Hay una gran cantidad de datos involucrados. Algunas mesas tienen cerca de 100 millones de discos.

---

EDIT:

El entorno de ensayo que tenemos en lugar no tiene la capacidad de reflejar la producción. También hay cientos de gigabytes de archivos de datos que participan, además de los datos de base de datos real.

---

EDIT:

Hacemos uso de control de código fuente para el código, pero no para los procedimientos almacenados. Hay algunos viejos procedimientos almacenados en control de código fuente, pero nadie que mantiene actualizado más.

Las principales preocupaciones son la base de datos y los datos del sistema de archivos.

Por cierto, soy un consultor en esta empresa, no un empleado real.

Answer 1

La respuesta más directa es: "No hagas eso."

Answer 2

control de origen. nada como una reversión cuando las cosas a irreparablemente mal. Además, un diff puede ayudar a replicar los cambios en otros sistemas de producción.

Answer 3

Las nuevas versiones de producción pasan a través de nuestros sistemas de chicos, los programadores y desarrolladores sólo se puede solicitar para que su nuevo sistema de ir a vivir, se necesita la aprobación, así, y nos muestran que cada cambio que se ha hecho ha sido probado (incluyendo una instantánea de todo lo que se puso a prueba en este comunicado en la solicitud de producción).

Nos mantenemos las notas de producción anteriores de repliegue en caso de problemas.

Si las cosas se rompen (que no deben hacer a menudo con un procedimiento de prueba adecuado y las versiones administradas) entonces podemos tampoco hacer retroceder o revisión. A menudo, cuando las cosas se rompen en vivo y la solución es pequeña, podemos revisión, a continuación, mover el punto de referencia para poner a prueba a hacer una prueba adecuada.

En cualquier caso, a veces las cosas se ponen por ...

Answer 4

sólo permiten ciertas cuentas de acceso de escritura, por lo que tiene que entrar de forma diferente para hacer un cambio

en el servidor web, tiene dos estructuras de directorios, que se reflejan mutuamente, uno donde sólo uno puede escribir ID, el otro dir puesta en escena, todo el mundo puede escribir.

en el servidor de base de datos, tener uno db producción, donde sólo un ID puede escribir, tener una base de datos puesta en escena donde todo el mundo puede escribir. la puesta en escena DB puede tener copia de seguridad nocturna restaurado a la misma.

Sin embargo, si desea realizar una consulta o alguna mala consumidor de recursos en los recursos del sistema de estadificación será arrancada de la producción, y la máquina podría colgar.

Answer 5

Para los servidores Web y de aplicaciones, me gustaría tratar de copiar el medio ambiente a una nueva ubicación (pero en el mismo entorno) y tienen las personas afectadas reproducen el comportamiento en la copia. Esto por lo menos le dará un nivel de separación accidental de atornillar con el 100% de sus clientes.

Para los servidores de bases de datos, me gustaría configurar cuentas de usuario en el sistema de producción para darles leen sólo derechos.

Answer 6

de sólo lectura / cuentas de clientes. Seriamente. Es la misma razón por la que no siempre está registrado como root o administrador.

Answer 7

Esto es una cosa difícil, y se va con el territorio de "ningún entorno de ensayo."

Por muchas razones, es mejor tener un dedicado (por duplicado) de PROD puede utilizar para la etapa despliega a ... y depurar, pero sé que a veces, cuando estás empezando que no funciona a cabo tan rápidamente o bien como nos gustaría.

Una cosa que he visto el trabajo es el uso de máquinas virtuales: aparte del entorno de depuración, puede crear un mini-PROD en una máquina virtual y el uso que de depurar. Esto puede no ser práctico dado el tipo de aplicación que está en desarrollo, por lo que el detalle adicional en esa área sería de gran ayuda.

En cuanto a evitar los cambios a PROD durante la depuración: ¿hay alguna razón que había necesidad de cambiar nada para facilitar la depuración? Si es así, que podría ser digno de mirar en la solución de otra manera.

Answer 8

El control de versiones es inmensamente útil para controlar los cambios en los entornos de producción - simplemente hacer que su entorno de producción de una copia de trabajo del directorio o directorios apropiados desde el repositorio. Cuando sacas a cabo una actualización, el sistema de control de código fuente se asegura de que todos los ficheros modificados se copian. Cuando una actualización rompe algo, se puede rodar la producción copia de trabajo posterior a la última revisión que no estaba roto. Además, se puede comprobar su producción de WC a partir de una etiqueta en lugar de desde el tronco; de esa manera usted puede decidir qué revisiones del repositorio para aplicar al entorno de producción mediante el ajuste de la etiqueta.

Si no está familiarizado con los conceptos de sistemas de control de versiones, te aconsejo que hacer algunas investigaciones. Son conceptualmente compleja, pero increíblemente útil y potente. El artículo de Wikipedia es un buen punto de partida: http://en.wikipedia.org/wiki/Revision_control

Answer 9

Lo siento, usted tiene que tener un entorno de ensayo. No hay manera de evitar esto. Si significa que tienes que sacrificar el tamaño de los conjuntos de datos, entonces eso es lo que tiene que hacer. Utilizar VMware y VMware Converter para importar los sistemas de producción durante períodos de bajada, si los tiene (este es un proceso de muchas horas, así que tal vez no es práctico).

Hay una cierta clase de problemas que no puede resolver sin tener acceso completo a la producción DB (o una copia), el rendimiento es uno de ellos. Pero que realmente debe construir un entorno de ensayo, aunque sea en la máquina de escritorio de alguien con un conjunto de datos simplificada.

Aparte de eso, he tenido que vivir mi vida con unos pocos de estos en el pasado, y en realidad, no hay nada que puedas hacer excepto un montón de copias de seguridad. Cada cambio que haga debe ir precedida de copias de seguridad incrementales. De esta forma si usted fubar'd algo, la cantidad que ha perdido no es sustancial. servidor SQL puede realizar copias de seguridad diferenciales que limitan la cantidad de espacio en disco utilizado para copias de seguridad. Oracle también pueden hacerlo.

Answer 10

En caso de que realmente no tienen otra opción, y es probable que sea una situación crónica ... considerar la adición de alguna manera a los datos de la aplicación (archivos o base de datos) para marcar un conjunto de datos como 'por favor dios no lo hacen de hecho cambiar de forma activa el estado de producción con estos datos', combinado con los datos volcados en posiciones críticas en un proceso cuando se activa este indicador, es posible que pueda ejercer la mayor parte de la lógica de la producción sin los datos realmente están poniendo en práctica.