Cómo escribir software para ser resuelto por un equipo de soporte técnico que no tiene acceso al código

Esto es lo que puedes hacer:

• Tenga una pantalla que muestre la versión exacta y la compilación de la aplicación. Proporcione un apodo también. (Un código que consta de 4 a 6 letras y está vinculado al lanzamiento)
• Tener un botón en esa pantalla que permita tener información sobre el entorno. SO, variables de entorno (filtradas si es posible), cantidad de RAM y espacio en disco. Tanta información sin tener problemas legales. (¡Por ejemplo, no la lista de software abierto o entradas MRU!)
• Tenga una forma de agrupar y enviar registros a sus servidores. Esto debería generar un mensaje para el usuario que debe tener la posibilidad de ver lo que se enviará.
• Tener una entrada de asistencia rápida en el menú de ayuda. Para activarlo, se requiere un código y el soporte lo proporciona. (Incorporación de un control remoto que debe iniciar el usuario)
• La posibilidad de iniciar la aplicación en modo “seguimiento”. Y que se envíe el rastro a soporte. (Con conformaciones habituales del usuario)

En el lado de soporte, un lugar centralizado para registrar síntomas comunes y problemas relacionados con sus soluciones.

Un conjunto de programas escritos por el equipo de desarrollo y que leen los diversos registros y rastreos y pueden orientar el soporte para encontrar una solución.

En el lado del desarrollador: registro extenso con capacidad de filtrar el registro. (¡La mayoría de los madereros lo hacen perfectamente bien!)

Para algunos programas, también debería estar disponible un “solucionador de problemas” alternativo.

Todo depende de si puedes incrustar el solucionador de problemas en tu aplicación principal o no.

Además, la aplicación en sí misma debe contener un manual interactivo para evitar errores ID-10T y CTKI. Una guía de solución de problemas para el usuario.

Se necesita mucho trabajo y la mayoría de las tiendas prefieren ampliar su equipo de soporte.

Algunas buenas respuestas ya. Algunas cosas que puede hacer dependen de la naturaleza del software. ¿Es una aplicación web? ¿Es una aplicación de escritorio? ¿Es una aplicación móvil?

Si se trata de una aplicación de escritorio o móvil, cuando muestre el error, proporcione un enlace donde se brinden las posibles soluciones. Idealmente, cada error tendría un enlace único (una wiki tal vez), y los usuarios podrían agregar sus comentarios.

Además, junto con el mensaje de error, puede proporcionar un botón que dice “contacto con el soporte”, que completará un ticket y completará automáticamente la información sobre el software, como la versión, el mensaje de error, el seguimiento de la pila de excepción, las estadísticas de memoria, el último pocas entradas en el registro, fecha y hora de error, etc.

Si es una aplicación web, considere una herramienta APM como newrelic. Si los usuarios informan que la aplicación es lenta, una herramienta APM será realmente útil para descubrir por qué.

Si se trata de una aplicación de escritorio o móvil, considere agregar análisis y seguimiento de errores en un servicio centralizado.

Tenga una página de “comprobación de estado” que verifique el estado de todos sus recursos e indicadores clave de rendimiento, como las conexiones de la base de datos, la integridad del sistema de archivos, el estado de la memoria, las profundidades de la cola y el tiempo de respuesta. Esta sería la primera página que su equipo de soporte verificará cuando llegue un ticket. Vincúlelo a holgura para que el equipo pueda comunicarse cuando ocurra un problema.

Configure alertas cuando el sistema salga de los parámetros aceptables. Si los sistemas de archivos están demasiado llenos, o las colas son demasiado profundas, o el tiempo de respuesta es más de unos pocos segundos, se debe generar una alerta en holgura, que su equipo de soporte debe monitorear.

No creo que se pueda hacer de manera efectiva.

Encontrar errores, sí. Reduciendo el problema a un área específica de funcionalidad, sí.

Sin embargo, la resolución de problemas implica que se puede demostrar que la causa raíz específica, identificable como una parte específica del código fuente, causa el error, además de ser capaz de explicar por qué es así. Para poder hacer esto correctamente, se requiere acceso al código fuente.

El desarrollador puede colocar trampas de error con códigos de error específicos adjuntos, pero esto solo permite que un equipo de soporte identifique un punto en el código donde se detectó un mal comportamiento , que no es lo mismo que solucionar el problema.

La verificación de que la resolución de un problema se ha producido correctamente solo se puede hacer alterando el código fuente y luego probando el código resultante para asegurarse de que la solución funciona, y esto en sí mismo es parte del proceso de resolución de problemas.