Usuario:Dgavidia

De ConssaWiki

Revisión de 14:06 16 ago 2012

tl;dr significa too long, didn't read. Este gato trató de leer un texto muy largo y, como podemos ver, fracasó.
Advertencia: El texto en este artículo es largo. ¿Está usted preparado?

Blog... ¿Blog? ¡Las ideas no pueden ser arrestadas!

Este es un compendio de ideas, pensamientos y opiniones que considero deberían contar para algo. Considero que deberían estar en alguna parte. Algunas ideas funcionan, otras no. Algunas valen la pena analizar... otras no vale la pena ni mencionar. Lea bajo su propio riesgo.

Ideas en el aire

El efecto DTS explicado

14/08/2012

Funcionamiento de un DTS

Primero, una explicación necesaria sobre el funcionamiento de un DTS.

• La función primaria de los DTS es copiar datos de una base de datos a otra.
• Existen dos casos: la inserción y la actualización.
• El DTS hace una consulta SQL para determinar cuales son los registros que debe copiar.
• Cada registro tiene dos campos que se usan en esta consulta: CDATEADD (fecha en la que el registro se insertó), y CDATEUPD (fecha en que se actualizó el registro).

Para determinar cuales son los datos que se van a copiar se consultan los registros que fueron insertados o actualizados el día de hoy, es decir, algo así:

SELECT CAMPO1, CAMPO2 CAMPO3 from TABLA WHERE cdateadd = GETDATE() and cdateupd = GETDATE()

Efecto DTS

Chévere... ¿y cual es el problema entonces? El problema viene a media noche, cuando la oscuridad se apodera de los servidores, y los registros quedan con fecha de 'ayer' en vez de fecha 'de hoy'.

Como la ejecución del DTS tiene un retraso (pues, se ejecuta una vez cada cierta cantidad horas) al llegar la medianoche los registros que no fueron copiados 'ayer' no son copiados nunca.

Supongamos que un DTS se ejecuta cada 2 horas.

• 9pm -> Se copian todos los registros actualizados hasta las 9pm
• 11pm -> Se copian todos los registros actualizados hasta las Desde las 9pm hasta las 11pm
• 1am -> Se copian todos los registros actualizados hasta las 12am hasta la 1am

¡Quiere decir que los registros actualizados entre las 11pm y 11:59pm nunca se copiaron!

Y así se origina el Efecto DTS.

El efecto se agudiza o se reduce, dependiendo del caso. Los siguientes factores influyen:

• Frecuencia de ejecución del DTS
• Fecha/hora de la ultima ejecución del DTS
• Fallas en la ejecución del DTS
  • Error en datos (no completa la ejecucion)
  • Intermitencia/caidas en conexión (se ejecuta pero no completa)
  • Servidor apagado (nunca se ejecuta)

Los problemas de conexión y fallas eléctricas han sido las causas más frecuentes en el último año.

Servidores apagados

Hago mención especial a este caso, pues es un caso especial. En ciertas ocasiones, como fallas eléctricas graves, vacaciones, y otros, los servidores se apagan. Particularmente durante el racionamiento eléctrico, los servidores solían apagarse durante el fin de semana. Cuando un servidor está apagado más de un día, se origina un efecto DTS agudo.

Generalmente, los servidores se apagan de manera controlada. Quiere decir que de manera controlada estamos generando un efecto DTS.

Solución (?)

Para reducir el efecto, los DTS están configurados para copiar los registros actualizados 'ayer y hoy'. Así se soluciona el problema cuando el funcionamiento del sistema es normal, es decir, sin errores en la ejecución del DTS.

Sin embargo, el problema se soluciona a un costo considerablemente alto. Ahora los DTS no pasan registros actualizados durante un día, sino los registros actualizados durante dos días. Es decir, que el tráfico ha sido duplicado.

Con todo y eso, es una solución parcial, pues cuando hay fallas de conexión prolongadas o el servidor se apaga durante días, el efecto persiste.

La solución podría estar en suministrarle al DTS, de alguna forma, una fecha exacta a partir de la cual deben seleccionar los registros.

Si sabemos que el último día en que el servidor estuvo funcionando fue a 7 días, entonces esa fecha debe ser suministrada.

Se me ocurren dos manera de hacer esto:

1. Se consulta en la tabla 'receptora' cual es la fecha máxima de actualizacion o insercion de los registros. Esa fecha servirá como fecha inicial para la próxima consulta.
2. Se mantiene actualizada una tabla que sirva de control. Cada vez que un DTS se completa exitosamente, entonces se actualiza un registro. La siguiente ejecución del DTS debe sacar la fecha de esa tabla.

indicador de sincronizacion

15/05/2012

• Se calcula una "Duración estimada del ciclo", que incluye replicación + DTS + algun factor macabro.
• Color verde: El tiempo estimado está transcurriendo.
• Color amarillo: El tiempo estimado terminó. Debería estar sincronizando en este momento.. o tal vez no. Si pasa 4 horas o más en amarillo, envia un correo a desarrollo pidiendo auxilio (¡la replicación se trancó!).
• Color rojo:
  • Se cayó el internet total en la sucursal
  • Se cayó el metro en CONSSA
  • Se cayó la VPN
• Se puede agregar un label explicando los estados:
  • Verde: "El estos momentos el ciclo de sincronización está transcurriendo normalmente. "
  • Amarillo: "En estos momentos el sistema está esperando por una sincronización."
  • Rojo: "En estos momentos el sistema no puede sincronizar la información debido a problemas de conexión."
• Se puede agregar un label con información como esta:
  • ¿Qué documentos se ven afectados por la sincronización?
    • Pedidos aprobados
    • Cobranzas aprobadas
    • etc

rescate de T3Web

04/05/2012

T3Web es lento. Hasta ahora no tenemos un indicador fiable que nos muestre la causa, pero tengo la corazonada de que buena parte del problema está en el diseño de las tablas de la base de datos. Diseño que resolvió los problemas al momento, pero que ocasionó este problema a la larga. Durante el curso de SQL server que realizamos recientemente, un procedimiento para rescatar T3Web del abismo computacional en el que anda me fue confiado por las musas de la informática:

1. Activar auditoria un par de horas, durante horas pico.
2. Identificar las operaciones (Top 10) más lentas.
3. Identificar las TABLAS y CAMPOS (where) que son consultados en dichas operaciones.
4. Identificar en cuales tablas hacen falta indices, e implantarlos donde corresponda. Los índices puede ser creados no sólo por campos individuales, sino también por la combinación de campos.
5. Diseñar particionamiento horizontal.
6. Realizar pruebas de comprobación de mejora de rendimiento (en desarrollo).
7. Implantar
8. Comprobar mejora de rendimiento en producción.

doble ingreso de números de control de facturas

04/05/2012

Problema: Los vendedores en determinados casos no pueden ingresar cobranzas, pues el sistema indica que el numero de control de la factura es incorrecto.

Causa: A pesar de las validaciones existentes, los usuarios de almacén ingresan los números de control con errores. Los números de control ingresados no son verificados en ningún momento.

Solución propuesta: Asumir la filosofía que se usa para los conteos de inventario, y solicitar el numero de control una segunda vez, y por un segundo usuario, de modo de que exista verificación de estos números.

El proceso podría ser así:

1. AALMACEN imprime la factura, ingresa el número de control.
2. La factura pasa al dpto de cobranzas
3. ACREDITO ingresa una vez más el número de control.
4. Si no hay diferencias, entonces no pasa nada.
5. Si hay diferencias, entonces ACREDITO recibe una notificación o advertencia, y le aparecen dos cajas de texto con los numeros ingresados tanto por AALMACEN, como por si mismo.
6. ACREDITO verifica con el papel en la mano si el error fue de AALMACEN o de si mismo y hace la corrección necesaria en la caja de texto. Ambos números deben coincidir para que sea válido el cambio.

O podría ser así:

1. AALMACEN ingresa el número de control.
2. ACREDITO ingresa una vez más el número de control.
3. Si no hay diferencias, entonces no pasa nada.
4. Si hay diferencias, entonces el JCREDITO corrige el número.

mantenimiento en T3Web

04/05/2012

Problema: Durante treinta minutos al día los vendedores no pueden ingresar pedidos al sistema. Calculando a ojo un promedio de 75 usuarios al día, el grupo de empresas pierde 37.5 horas diarias, 262.5 horas a la semana, 1050 horas al mes, en las que se pudieran estar cargando pedidos. Para efectos de mantenimiento, en un mes hay unas 15 horas de mantenimiento, pero en realidad se usan 2 o 3... lo que quiere decir que 80% del tiempo de mantenimiento es tiempo no productivo desperdiciado.

Causa: El tiempo de mantenimiento es habilitado diariamente, a pesar de que no se necesita diariamente.

Solución propuesta: Cambiar el tiempo de mantenimiento de manera tal que se habilite sólo cuando se necesite.

El proceso podría quedar así:

1. El día que se requiere mantenimiento, se activa una bandera (campo en T3TCONFIGCONSSA, o alguna tabla similar).
2. Durante todo el tiempo que la bandera este activa, se coloca un mensaje no-intrusivo en la parte superior de la pantalla para todos los usuarios, indicando "Estimado usuario, el día de hoy a las 11am el sistema estará en mantenimiento. Por favor tome las previsiones necesarias.".
3. A la hora anunciada, el sistema entra en horario de mantenimiento.
4. Un DTS deshabilita la bandera cuando haya pasado el periodo de mantenimiento.

notificadores para Choroní

30/03/2012

La idea es utilizar una lista de opciones cerrada y pre-programada para las entidades/tablas que puede consultar un notificador. Un algoritmo debe ser creado para hacer que las diferentes combinaciones sean válidas.

quiero olvidarme de las OC

Problema: Con cierta frecuencia, las OC son creadas y no bajan.

Causa: Las OC requieren aprobación del Proveedor, o en su defecto, debe crearse una "excepción de aprobación", de manera tal que pasen pre-aprobadas. Sin embargo, T3 permite crear OC sin que exista un usuario proveedor aprobador, y a la vez, sin que exista la excepcion, por lo que las OC quedan en el limbo informático. Sucede sobretodo para proveedores nuevos.

Solución propuesta:

• Agregar una validación que le impida al usuario crear OC que quedarán en el limbo. Esto le obligaria a comunicarse con el responsable de crear las excepciones, o sino:
• Crear las excepciones automáticamente, o consultando al usuario, cuando se asigna el proveedor a la compañía.

depuración asistida de errores de calculo de incentivos de venta

09/05/2012

Los incentivos de venta, como proceso administrativo, se realizan de diferente manera en las diferentes sucursales. Esto no debería ser, pero es. Como en muchas ocasiones, el sistema tiene entonces una tarea cuesta arriba, y no es una tarea técnica. Es la tarea de estandarizar el proceso administrativo. Eso significa que el sistema debe crear dudas en los usuarios sobre el proceso administrativo. Estas dudas deben ser disipadas entre ellos, y finalmente, cuando los criterios se hayan unificado, las correcciones deben llegar al sistema. Mientras eso pasa el sistema tendrá fallas a los ojos de todos los usuarios, y siempre arrojará diferencia con los cálculos.

Mi propuesta es un cambio de mentalidad en el departamento de desarrollo. Asumir que las diferencias estarán allí durante un periodo prolongado, y programar consecuentemente.

El proceso quedaría más o menos así:

1. El usuario configura los incentivos y se generan los calculos automáticos. Estos resultados son guardados en una tabla, identificados con el periodo y la sucursal / empresa.
2. Antes de que estos cálculos vayan a nómina, el usuario los verifica. En los casos que haya diferencias, el usuario ingresa una corrección manual. Estas correcciones son guardadas en otra tabla.
3. El sistema genera entonces los cálculos con las modificaciones manuales, y los pasa a nómina.
4. Las correcciones manuales son analizadas y discutidas a posteriori. Ya sea por personal administrativo, o por los desarrolladores, o ambos.
5. Se modifica el sistema según las conclusiones obtenidas en esa discusión, y se repite el ciclo, hasta que ya no hayan errores ni diferencias de criterio.

Otra ideas:

• Las corrección manuales de los cálculos podrían ser monitoreadas, o requerir aprobación, por parte de la dirección.
• Al ingresar una corrección manual, se puede solicitar una explicación detallada. Esto agilizaría el proceso de desarrollo y análisis posterior.

bitacora de uso / monitoreo de rendimiento

10/05/2012

Andamos a ciegas con respecto al rendimiento de T3. No existe ningún indicador fiable y objetivo, que nos permita saber si el sistema tiene problemas de velocidad, o si alguna determinada característica se está usando o no. Si ya sabemos que los usuarios tienen quejas sobre la velocidad... ¿por qué no construimos algunos indicadores?

Propuesta:

• Crear un PA que realice algunas consultas 'clave' del sistema, y ejecutarlas con regularidad (digamos, dos o tres veces al día), midiendo el tiempo que tardan. Estos resultados deberían guardarse en una tabla, o en algún tipo de bitácora. Si una consulta generalmente tarda 5ms, y de pronto se dispara a 30s, entonces sabremos que hay lentitud. Pero además sabremos... ¿este problema sucede todos los días? ¿a todas horas?

• Incluir mediciones de tiempo via C#/ASP, que midan en sí cuanto tarda un usario en realizar un determinado proceso. Ejemplo, cuanto tarda en loguearse, o cuanto tarda desde el momento en que cliquea en el boton CONSULTAR de un reporte, hasta que logra ver la información.

• ¿Qué pantallas se usan del sistema, y que pantallas no se usan del sistema? ¿Qué tal crear una bitácora de uso?

puntos de esfuerzo para t3bugs

Actualmente la prioridad de los casos controla dos cosas: - Importancia: Orden en que debemos atenderlo - Tiempo máximo de atención / solución

Realmente, estos dos criterios no se deben mezclar. Tanto es posible que un caso muy importante, represente el mínimo esfuerzo, como que un caso de mínima importancia represente un gran esfuerzo. Y toda la gama de posibilidades en medio...

Propuesta:

Agregar un campo para cada caso, que contenga los puntos de esfuerzo que correspondan al caso.

De esta manera, los casos serían algo asi:

• Prioridad alta (4 horas de cola)
• Prioridad media (12 horas de cola)
• Prioridad baja (24 horas de cola)

• Esfuerzo bajo : 2 ptos ( 2 horas de solucion)
• Esfuerzo medio: 8 ptos ( 8 horas de solucion)
• Esfuerzo alto : 40 ptos ( 40 horas de solucion)

1. Ordenar reporte TAL de manera descendiente: Prioridad Baja, Esfuerzo Bajo , tiempo estimado: 24 + 2 = 26 horas
2. Agregar campo a reporte TAL, y hacerlo ya, porque sino, no se puede despachar mercancia: Prioridad Alta, Esfuerzo Bajo, tiempo estimado: 4 + 2 = 6 horas
3. Modificar interfaz con sistema X, agregar 6 campos nuevos: Prioridad media, Esfuerzo alto, tiempo estimado 12 + 40 = 52 horas

Con esta flexibilidad se abre la posibilidad de un cálculo de velocidad por analista.

Se presenta un factor nuevo que hay que considerar: ¿Quién asigna los puntos de esfuerzo?

Se me ocurren tres opciones, con nivel de exquisitez ascendente :

• Opción 1, nivel de exquisitez bajo: El admin asigna los puntos de esfuerzo, según crea conveniente... con derecho a réplica. El admin podria modificar este dato a solicitud del analista.
• Opción 2, nivel de exquisitez medio: El admin asigna los PE que considere. T3Bugs le da la potestad al analista de aceptar o rechazar el valor elegido, y de elegir un valor nuevo. El admin entonces debe aprobar o recharzar la propuesta del analista. Todo mediante la interfaz del software.
• Opción 3, nivel de exquisitez alto: El admin asigna solo la prioridad. El sistema entonces consulta con todos los analistas, y solicita un voto/estimación por cada caso. Cada analista, desde su maquina, eligue los P.E. que considere, y si hay consenso, entonces se establece el valor final. Si no, el admin debe ponerse de acuerdo con el equipo, y elegir.

¿cual es tu nombre?

16/05/2012

Problema: Los nombres de los usuarios guardados en la base de datos no coinciden con los nombres reales de las personas.

Causa: En la mayoría de los casos los nombres se escribieron al implantar el sistema, y nunca se actualizaron. Es común encontrarse con usuarios llamados VACANTE durante meses o años, y con usuarios que tienen nombres de personas que hace mucho tiempo no laboran en la empresa.

Solución propuesta: Crear un formulario que muestre y solicite una confirmación de datos personales del usuario. Nombre, correo electrónico, teléfono de contacto. Este formulario debe aparecerle a los usuarios cada cierto tiempo, por ejemplo, una vez cada tres meses.

inhabilitacion automática de usuarios inactivos

Ideas que funcionaron

SVN

automatizacion de lanzamiento de nuevas versiones de t3win

robocopy

Multifiltro

Reportes2

Calendario de cierre

Sub-sistema 'nadie usa mi clave'

16/05/2012

cpausacambio

estacion de cambios

cambiosBD

EjecutarEnTodasLasSucursales

Imprevistos y Holgura para SCRUM

Ideas que no funcionaron, o que funcionaron sólo un tiempo

T3Wiki y ConssaWiki

Noticias via Twitter

Resumen de cambios

Reseteo de claves

Estadísticas de uso de reportes en t3web

programar por pasión