Supongamos que su equipo escribe un sistema de software que funciona bien.
Un día, uno de los ingenieros ejecuta erróneamente algunas consultas SQL que cambian algunos de los datos de la base de datos, y luego se olvida de ello.
Después de un tiempo, descubre los datos corruptos / erróneos y todos se preguntan qué parte del código causó esto y por qué, sin éxito. Mientras tanto, el gerente del proyecto insiste en que encontremos la parte del código que lo causó.
¿Cómo lidias con esto?
Es obvio que ningún gerente de proyecto invertirá una cantidad infinita de tiempo en este problema. Lo que quieren es evitar que vuelva a pasar la misma situación.
Para lograr este objetivo, incluso si uno no puede encontrar la causa raíz de tal falla, a menudo es posible tomar algunas medidas para
Por ejemplo, un registro más detallado, un manejo más detallado del error o una señalización de error inmediata podrían ayudar a prevenir el mismo error de nuevo, o encontrar la causa raíz. Si su sistema permite agregar desencadenantes de la base de datos, tal vez sea posible agregar un desencadenante que prohíba la introducción de inconsistencias en primer lugar.
Piense en cuál sería el tipo de acción adecuado en su situación y sugiéralo al equipo; Estoy seguro de que su gerente de proyecto estará satisfecho.
Un día, uno de los ingenieros ejecuta erróneamente algunas consultas SQL que cambian algunos de los datos de la base de datos, y luego se olvida de ello.
Como lo mencionaron otros, también es una buena idea prohibir tal procedimiento (si tiene influencia sobre cómo se opera el sistema). A nadie se le debe permitir ejecutar consultas ad hoc sin documentar que cambian el contenido de la base de datos. Si es necesario realizar una consulta de este tipo, asegúrese de que exista una política para almacenar la consulta junto con su fecha de ejecución, el nombre de la persona que la ejecutó y la razón por la que se usó, en un lugar documentado.
Esto no es un error
Al menos no en tu código. Es un error en su proceso . Su administrador de proyectos debería estar mucho más preocupado por su proceso que por su código.
¿Cómo lidias con esto?
Sencillamente, al no permitir que los ingenieros cambien las bases de datos de producción o de desarrollo compartido .
Suponiendo que esta es una base de datos de desarrollo compartida:
Idealmente, si es posible, evita tener una base de datos compartida en primer lugar . En su lugar, tener bases de datos por desarrollador que son de corta duración. Esto debería automatizarse con scripts, de lo contrario, el costo de la prueba se vuelve demasiado grande y hay un incentivo para no probar las cosas. Puede tener estas bases de datos en la estación de trabajo del desarrollador o en un servidor central.
Si, por alguna razón, DEBES tener una base de datos compartida, debes usar fixtures - esencialmente, algo que establece la base de datos en un estado de bien conocido cada vez que necesita usarla. Esto evita que los desarrolladores sean mordidos por los cambios de otras personas.
Si necesita aplicar cambios permanentes a la base de datos, debe confirmarlos a su control de fuente . Configure su base de datos de modo que los desarrolladores no tengan permiso para escribir en ella directamente, y tengan un programa que extraiga los cambios del control de origen y los aplique.
Finalmente, según su descripción de cómo está depurando las cosas, parece que no está utilizando CI . Utiliza CI . Es un poco difícil de configurar, pero ahorrará mucho tiempo a largo plazo, por no mencionar que evitará que se preocupe por errores de base de datos que no se pueden reproducir. Solo tendrás que preocuparte por los heisenbugs ahora!
Suponiendo que esta es una base de datos de producción:
Si sus desarrolladores están cambiando las bases de datos de producción, muchas cosas han salido terriblemente mal, incluso si los cambios son absolutamente correctos.
Los desarrolladores nunca deben acceder a las bases de datos de producción . No hay absolutamente ninguna razón para hacerlo, y hay tantas cosas que pueden salir muy mal muy .
Si necesita arreglar algo en una base de datos de producción, primero realice una copia de seguridad, restaure esa copia de seguridad en una instancia de diferente (desarrollo) y luego jugar alrededor de esa base de datos de desarrollo. Una vez que cree que tiene una solución lista (en el control de código fuente), vuelve a realizar la restauración, aplica la solución y ve el resultado. Luego, después de hacer una copia de seguridad de las cosas nuevamente (e idealmente evitar las actualizaciones concurrentes), arregla la instancia de producción, idealmente a través de un parche de software.
Si necesita probar algo en una base de datos de producción ... no, no lo hace. Independientemente de las pruebas que necesite realizar, debe realizarlas en una instancia de desarrollo. Si necesita algunos datos para realizar las pruebas, puede obtener esos datos allí.
Una base de datos de producción debe tener un registro de acceso completo y controles de acceso basados en roles. Por lo tanto, debe tener pruebas sólidas de quién hizo QUÉ CUANDO HACIA LA Base de datos, de modo que la atención del código a una seguridad operacional deficiente.
En este caso, al final resolviste la causa, pero suponiendo que no lo hiciste ...
Primero, analiza lo que cambió. Si el sistema se estaba ejecutando bien antes, un análisis cuidadoso de todo lo que se ha hecho recientemente podría revelar el cambio que causó el error. Revise sistemáticamente su control de versiones, sistemas de despliegue / CI y control de configuración para ver si algo cambió. Ejecute git bisect o un mecanismo equivalente para realizar una búsqueda binaria. Revisar los registros. Busca alrededor de troncos que no sabías que tenías. Hable con todos los que tengan acceso al sistema para ver si han hecho algo recientemente. Para su problema, si es lo suficientemente exhaustivo en este proceso, esto debería revelar las consultas de SQL olvidadas.
Segundo, instrumentación. Si no puede encontrar directamente la causa de un error, agregue la instrumentación a su alrededor para recopilar datos sobre el problema. Pregúntese "si pudiera reproducir este error en el comando, ¿qué querría ver en el depurador" y luego registrarlo? Repita según sea necesario hasta que tenga una mejor comprensión del problema. Como sugiere Doc Brown, agregue el registro para los estados relevantes al error. Añade aserciones que detectan datos corruptos. Por ejemplo, si su error es un error de aplicación, agregue un mecanismo de registro de errores. Si ya tiene uno, genial, agregue anotaciones a los registros de bloqueo para registrar el estado potencialmente relevante para el bloqueo. Considere si los problemas de concurrencia pueden estar involucrados y para ejercer la seguridad de subprocesos .
Tercero, resiliencia. Los errores son inevitables, así que pregúntese cómo puede mejorar sus sistemas para que sean más resistentes, de modo que la recuperación del error sea más fácil. ¿Podrían tus copias de seguridad ser mejoradas (o existentes)? ¿Mejor monitoreo, failover, y alerta? ¿Más redundancia? ¿Mejor manejo de errores? ¿Desacoplar los servicios dependientes unos de otros? ¿Puede mejorar sus procesos en torno al acceso a bases de datos y consultas manuales? En el mejor de los casos, estas cosas harán que las consecuencias de su error sean menos graves y, en el peor, probablemente sean cosas buenas para hacer de todos modos.
También puede considerar si debería agregar un proceso adicional para reducir la posibilidad de que el acceso manual a la base de datos cause este tipo de problema en el futuro.
Según mi experiencia, lo que su jefe quiere es cierta seguridad de que esto no volverá a ocurrir. Si es el caso, la causa es que ningún código fue la causa, ya que las pruebas unitarias lo garantizan, por lo que, suponiendo que ya tenga una cobertura de prueba en su base de código, la solución debería agregar "pruebas" a su base de datos. Citaré a Don Gilman, porque él clavado allí:
Una base de datos de producción debe tener un registro de acceso completo y controles de acceso basados en roles. Por lo tanto, debe tener pruebas sólidas de quién hizo QUÉ CUANDO HACIA LA Base de datos, de modo que la atención del código a una seguridad operacional deficiente.
Pero también, debe tener un procedimiento operativo estándar para cambiar los datos en producción. Por ejemplo, ningún DBA debe cambiar los datos, ningún desarrollador debe ejecutar el cambio por sí mismo y deben, según se define en el SOP, solicitarse mutuamente el cambio por correo o boleto.
Debe haber una cita como esta en alguna parte, si no puede citarme en ella:
Hay una buena razón para que los chefs no sean los responsables de limpiar los inodoros.
Estaba trabajando en el equipo de desarrollo para un producto de base de datos de mainframe cuando un cliente informó que tenía una base de datos dañada. Una corrupción en el sentido de que el estado interno de los bits en el disco significaba que la base de datos no se podía leer a través del software de la base de datos. En el mundo del mainframe, los clientes le pagan $ millones y usted necesita tomarse esto en serio. Esto es lo que hicimos:
Paso 0: ayude al cliente a ponerse en marcha nuevamente al reparar la base de datos.
Paso 1: al examinar el archivo en el disco a nivel hexadecimal, determinamos que la corrupción era sistemática: hubo muchos casos de la misma corrupción. Así que definitivamente fue causado en el nivel del software de base de datos. De hecho, fue lo suficientemente sistemático como para sentir que podíamos descartar problemas de subprocesos múltiples.
Después de eliminar muchas otras teorías, aprovechamos una utilidad que podría usarse para la reorganización física de la base de datos. Parecía ser el único código que tenía acceso a los datos en el nivel correcto. Luego descubrimos una forma de ejecutar esta utilidad, con opciones cuidadosamente seleccionadas, que reproducían el problema. El cliente no pudo confirmar o negar que esto es lo que habían hecho, pero como era la única explicación que podíamos encontrar, decidimos que era la causa probable, y no tenían más remedio que aceptar nuestro diagnóstico. .
Paso 2: Luego hicimos dos cambios en el software: (a) hizo más difícil causar este efecto accidentalmente a través de una interfaz de usuario "sí sé lo que estoy haciendo", y (b) introduciendo un nuevo archivo de registro de modo que si volviera a suceder, tendríamos un registro de las acciones del usuario.
Entonces, básicamente (a) repare el daño y restaure la ejecución en vivo, (b) encuentre la causa raíz, (c) haga lo que sea necesario para evitar que vuelva a suceder, o para permitir un diagnóstico fácil si vuelve a suceder.
Hay varias cosas que se deben hacer con errores no reproducibles.
Crea un ticket y registra todo lo que puedas imaginar en el ticket. También verifique si este "error" se ha registrado antes y vincule los tickets. Eventualmente, puede obtener suficientes tickets para establecer un patrón sobre cómo reproducir el error. Esto incluye el trabajo alrededor utilizado para tratar de evitarlo. Incluso si esta es la única instancia, si hay una primera vez, eventualmente habrá una segunda vez. Cuando encuentre la causa, cierre el ticket con una explicación de cuál fue la causa para que tenga una idea clara de lo que sucedió si vuelve a suceder (reparar la pérdida en la fusión incorrecta)
Observe el sistema, qué falló y cómo falló. Trate de encontrar el área del código que pueda actualizarse para hacer menos probable la falla. Algunos ejemplos ...
execute(<query>) con executeMyStoredProcedure(<params>)
Es posible que esto no solucione el error, pero incluso si no lo hace, el sistema ahora es más estable / seguro, por lo que aún vale la pena.
Es una parte de 2, pero sucedió algo, y necesitas saber cuándo vuelve a suceder. Debe crear algunos programas / scripts de comprobación de estado para monitorear el sistema, de modo que se pueda alertar a los administradores dentro de las 24 horas de la reaparición del error (cuanto menor sea la demora, mejor, dentro de la razón). Esto hará que la limpieza sea mucho más fácil. (Tenga en cuenta que además de los registros de las bases de datos, el sistema operativo también debe registrar quién se registra y las acciones de no lectura que realizan. Como mínimo, debe haber registros de tráfico de la red hacia esa máquina)
Su problema no fue causado por una falla en su software, sino por alguien que está jugando con la base de datos. Si consideras que las cosas van mal como un "error", entonces tu error se puede reproducir fácilmente: las cosas siempre van a salir mal cuando alguien hace estupideces en la base de datos. Y hay formas de evitar este "error", al no permitir que la base de datos se modifique manualmente o utilizar software no probado, y al controlar estrictamente quién puede modificar la base de datos.
Si solo llama a las fallas en su base de datos un "error", entonces no tiene un error irreproducible, no tiene ningún error. Es posible que tenga un informe de error, pero también tiene evidencia de que el problema no fue causado por un error. Así que puedes cerrar el informe de error, no como "irreproducible", sino como algo así como "base de datos dañada". No es raro tener informes de errores en los que la investigación muestre que no hay ningún error, pero un usuario utilizó el software incorrectamente, las expectativas del usuario eran incorrectas, etc.
En ese caso, todavía sabes que hubo un problema que no quieres que se repita, así que tomas la misma acción que en el primer caso.
Lea otras preguntas en las etiquetas project-management