DISPONIBILIDAD DEL​ SERVICIO Y SEGURIDAD DRIVER360

DISPONIBILIDAD DEL​ SERVICIO Y SEGURIDAD DRIVER360

Disponibilidad del servicio

DRIVER360 está di​sponible 24x7x365.

DRIVER360 está alojada en infraestructura propia en un centro de datos Tier III+ de Sewan, lo que nos permite desplegar servicios en la nube altamente escalables y fiables con una disponibilidad del 99,978% y sin periodos de inactividad planificados.

Asimismo contamos con una copia de seguridad activa y en tiempo real en Google Cloud Platform con un Acuerdo de nivel de servicio (SLA) del 99,95%.

Con el fin de minimizar las interrupciones en el servicio ocasionadas por fallos del hardware, desastres naturales u otros incidentes, DigitalizaT ya planificado una infraestructura de centros de datos altamente redundante.

Nivel de servicio


Digitalizat Solutions, S.L. proporciona asistencia técnica las 24 horas del día, los 7 días de la semana, con tiempos de respuesta y resolución rápidos en función de la gravedad.

ALTA

Respuesta: 3 horas

Resolución: entre 4 y 24 horas

ME​DIA

Respuesta: 5 horas

Resolución: entre 120 y 240 horas

BAJA

Respuesta: 8 horas

Resolución: entre 300 y 500 horas

CRÍTICA

Respuesta: 1 hora

Resolución: entre 3 y 6 horas

  1. La cobertura de gravedad Crítica se presta las 24 horas del día, los 7 días de la semana.
  2. Para los tiempos de respuesta objetivo de los niveles de gravedad Alta, Media y Baja se considera solo el horario de atención comercial local, sin incluir fines de semana ni festivos.
  3. El tiempo de resolución comenzará a computarse a partir del momento en que el cliente facilita toda la información requerida para el análisis y resolución del mismo.

Definición de gravedad

Deberá calificarse en este nivel cuando ningún cliente pueda trabajar con la aplicación.

Ejemplo:

Indisponibilidad total de la aplicación (caída de plataforma, infraestructuras)

Deberá calificarse en este nivel aquellos bug’s que impidan al usuario en ese momento ejecutar una acción imprescindible.

Ejemplo:

No se pueden emitir facturas de OR’s

Deberá calificarse en este nivel aquellos bug’s que impedirán al usuario en un momento futuro, comprendido entre los siguiente 3 y 10 días, ejecutar una acción imprescindible en dicho momento.


Estos Bugs se pasarán automáticamente a prioridad “Alta” en el momento en que falten menos de 3 días para la fecha tope de resolución definida en el ticket. La fecha tope se definirá en seleccionando en el campo “Estado” la opción “Pospuesto” lo que permitirá señalar la fecha tope de resolución.


Ejemplo:

Existe un bug en el Modelo 347 de la AEAT.
Al ser exigible este modelo en Febrero de cada ejercicio, se calificará como nivel medio hasta que la fecha se aproxime a dicho mes, momento en el que pasará a configurarse en el nivel superior.

Deberá calificarse en este nivel aquellos bug’s que:

  • Impidan al usuario en ese momento ejecutar una acción definida, imprescindible o no, pero exista una solución funcional para poder realizar dicha acción.
  • Impedirán al usuario en un momento futuro, más allá de los 10 días siguientes, ejecutar una acción imprescindible en dicho momento. Estos Bugs se pasarán automáticamente a prioridad “Media” en el momento en que falten menos de 10 días para la fecha tope de resolución definida en el ticket. La fecha tope se definirá en seleccionando en el campo “Estado” la opción “Pospuesto” lo que permitirá señalar la fecha tope de resolución.


Ejemplo:

El Módulo de VO no permite introducir una compra a una persona física autónoma, que emite una factura con el IVA aplicable al 50% de la Base imponible, al tener afectado solamente el 50% del vehículo a su actividad profesional.
Existe la posibilidad de registrar una factura de compra por Factura Libre e indicar en el expediente de VO que la factura ya existe e introducir los importes de la misma.

Infraestructura del sistema


DRIVER360 cuenta con una infraestructura de 3 niveles:

  • Sistema de desarrollo (DEV).
  • Sistema de preproducción o aseguramiento de calidad (QAS).
  • Sistema de producción (PRD).


Esto significa que:

  • Los cambios se realizan en el sistema de desarrollo (DEV).
  • Cuando se liberan las solicitudes de cambio correspondientes, se pasan al Sistema de preproducción o aseguramiento de calidad (QAS). En el Sistema de preproducción o aseguramiento de calidad (QAS) se testean los cambios realizados.
  • Si la prueba tiene éxito, las solicitudes de cambio se transportan al sistema de producción (PRD). El sistema de producción (PRD) está completamente separado de los demás sistemas en lo que respecta a los datos entre clientes.

Permisos


Para la definición de permisos en DRIVER360 se parte del tipo de usuario, siendo estos:


Administrador

Centralita

Asesor de servicio

Comercial

Dirección

Jefe de taller

Director comercial

Jefe de ventas

Operador

Recambista

La configuración de los permisos se estructura por módulos.

Pulsando cada una de las pestañas indicadas con el nombre de cada módulo, se desplegarán los permisos disponibles. Marque o desmarque las casillas correspondientes para el Tipo de usuario seleccionado, dependiendo de si quiere dar o quitar los permisos, respectivamente.

Estrategia copias de seguridad



¿Cuándo se crean copias de seguridad? 

Tenemos programadas la realización de copias de seguridad cada 4 horas. En el caso de que los datos no hayan cambiado desde la última copia de seguridad, no se realizará ninguna copia de seguridad.


Copia de seguridad de las instancias de segunda generación. 

Las copias de seguridad de las instancias de segunda generación son incrementales. Sólo contienen datos que han cambiado desde que se realizó la copia de seguridad anterior. Esto significa que la copia de seguridad más antigua tiene un tamaño similar al de la base de datos, pero los tamaños de las copias de seguridad posteriores dependen de la velocidad de cambio de los datos. Cuando se elimina la copia de seguridad más antigua, el tamaño de la próxima copia de seguridad más antigua aumenta, de manera que todavía existe una copia de seguridad completa.

Seguridad

DRIVER360 utiliza tecnología SSL de 128 bits. Los Certificados SSL de 128 bits funcionan con Server Gated Cryptography (SGC), tecnología aplicada al cifrado de información con la capacidad más alta que alcanza 256 bits. Además, los Certificados SSL de 128 bits garantizan compatibilidad con el 99 por ciento de los navegadores y la mayoría de los dispositivos móviles. Por estas características, ofrecen los mejores niveles de protección en operaciones electrónicas para Organizaciones, sitios web y casi todos los clientes o usuarios. 

Mantenimiento transparente. Gracias a los innovadores centros de datos y a la tecnología de migración en vivo, es posible realizar un mantenimiento proactivo de la infraestructura y mejorar la fiabilidad y la seguridad. Las máquinas virtuales activas se trasladan automáticamente a los hosts cercanos (incluso si estas tienen una carga extrema) mientras se realiza el mantenimiento de las máquinas de host subyacentes. No necesitamos reiniciar las máquinas virtuales después de actualizar el software del host ni cuando se produzcan ciertos errores de hardware detectables.

  • Fiabilidad y seguridad. Disponemos de tres servidores de BBDD multi-CPD replicados en tiempo real, esta configuración nos permite ejecutar un plan de emergencia desde el CPD de respaldo en menos de una hora.
  • Acceso SQL. Acceso limitado por VPN.

Fiabilidad


Con el fin de minimizar las interrupciones en el servicio ocasionadas por fallos del hardware, desastres naturales u otros incidentes, Digitalizat ha planificado una infraestructura de centros de datos altamente redundante.

La arquitectura de red y de aplicaciones de DigitalizaT está diseñada para ofrecer la máxima fiabilidad y operatividad. Los datos se distribuyen entre los servidores y los centros de datos de Sewan y Google. Si falla un servidor (o incluso el centro de datos completo), los datos seguirán estando accesibles.

Contamos con un plan de continuidad de la empresa para sus centros de datos y operaciones de producción. En este plan se recogen los desastres naturales más graves, como terremotos y crisis sanitarias, y se asume que las personas y los servicios podrían no estar disponibles durante 30 días. Este plan se ha diseñado para poder seguir ofreciendo los servicios a los clientes de forma ininterrumpida.

Modo Offline

No disponible Offline


DRIVER360 solo está disponible para su uso de manera online.

Fiabilidad del 99,97%


DRIVER360 está alojada en la infraestructura de Digitalizat con backup en Google, lo que nos permite desplegar servicios en la nube altamente escalables y sin periodos de inactividad planificados.

2 líneas independientes


Con el fin de eliminar posibles problemas de conexión del lado del cliente, se recomienda la contratación de 2 líneas independientes de datos, por ejemplo una ADSL o fibra y otra móvil 3G o 4G.

Estrategia de actualizaciones

Las actualizaciones programadas se realizan en las fechas planificadas, previa superación de los test pertinentes en el sistema de preproducción o aseguramiento de calidad (QAS). Estas actualizaciones pueden ser:

  • Nuevas funcionalidades en general (Planificación general. Se actualiza trimestralmente)
  • Nuevas funcionalidades por encargo de un cliente (Planificación específica. Se actualiza según contrato)

Las nuevas funcionalidades siempre se engloban dentro de las actualizaciones programadas, debido a que:

  • Requieren de una revisión y verificación exhaustiva del entorno actual ya que pueden afectar a la arquitectura, especificaciones del sistema, requisitos de dimensionamiento de hardware, etc.
  • Es muy posible que se requiera la formación en las nuevas funcionalidades de los usuarios afectados, siendo necesaria la planificación y realización de la misma.

Las actualizaciones no programadas se realizan una vez superados los test pertinentes en el sistema de preproducción o aseguramiento de calidad (QAS). Estas actualizaciones pueden ser:

  • Corrección de errores.
  • Parches de seguridad.
  • Actualizaciones de desempeño.

Para llevar a cabo la gestión de las actualizaciones, DIGITALIZAT utiliza GitHub como sistema de control de versiones basado en ramas.

Con GitHub es posible compartir proyectos con otros usuarios e invitarlos a contribuir directamente.

GitHub permite crear proyectos internos, lo que permite almacenar los repositorios de código en servidores privados. Un proyecto interno permite a cualquier usuario logueado tener acceso para explorarlo. Algo conocido como inner sourcing.



  • Desarrollo (DEV)
  • Preproducción o test (QAS)
  • Producción (PRD)


  • Implementación de una nueva funcionalidad:
    • Se recuperan los datos de la rama de producción y se crea una nueva rama de desarrollo.
    • Se trabaja sobre la rama para desarrollar la nueva funcionalidad.
    • Una vez finalizado el desarrollo se envía a la rama de preproducción (o test).
    • Si se valida se fusionará (merge) con la rama de producción. En caso contrario, si se detectase algún fallo, se volvería a desarrollo para corregir los problemas.
  • Si se recibe un aviso de un problema crítico que tiene que ser resuelto, se realizan los siguientes pasos:
    • Se guarda la rama en local sobre la que se estaba trabajando.
    • Se recupera la rama de producción original.
    • Se crea una nueva rama para el problema crítico y se resuelve sobre esta nueva rama.
    • Tras las pertinentes pruebas (envío preproducción), se fusiona (merge) la nueva rama con (push) la rama de producción.
    • Al final se vuelve a la rama inicial sobre la que estaba trabajado antes del aviso del problema.


  • Actualizaciones no programadas:
    • Corrección de errores: Descubrimiento de errores (interna o externamente) que afectan directamente al software en producción. Han de ser subsanados lo antes posible.
    • Parches de seguridad: Son errores que suelen aparecer por las versiones de software utilizadas en el desarrollo (java, mysql, protocolos de comunicación, ...). Estos errores son los más críticos y es necesario solucionarlos lo antes posible.
    • Actualizaciones de desempeño: No son errores como tal, son mejoras, tanto a nivel interfaz, como a nivel programación interna del software. Este tipo de actualizaciones son las menos importantes puesto que no impiden el desarrollo normal de los trabajos.​
  • Actualizaciones programadas:
    • Nuevas funcionalidades en general: Se planifican y liberan trimestralmente.
    • Nuevas funcionalidades por encargo de un cliente: Se planifican y liberan según contrato.


Actualizaciones


DRIVER360 presenta una arquitectura multi-tenant, es decir que todos los clientes y sus usuarios utilizan el servicio desde la misma aplicación.

Es por ello que, al contrario que en las aplicaciones tradicionales, las actualizaciones y mantenimiento de DRIVER360 se producen de manera inmediata y transparente para todos los usuarios, eliminando de esta manera el control de versiones en producción.

En el caso de las apps móviles, se utiliza el sistema de actualización propio del sistema operativo para el cual está desarrollada la aplicación (Google Play Store, Apple Store, ...).

Las actualizaciones pueden derivar de:

  • Corrección de errores.
  • Parches de seguridad.
  • Actualizaciones de desempeño.
  • Nuevas funcionalidades.