Soporte y mantenimiento gestionado de aplicaciones
Mantener en funcionamiento el software que ya está en producción, dentro de su SLA y de su cola de tickets: clasificación, correcciones en la causa, versiones de parches, actualizaciones de dependencias y de plataformas, respuesta a incidentes de seguridad y gestión de incidentes. Segundo y tercer nivel, a cargo de ingenieros que también desarrollan, de modo que un fallo recurrente se corrija y no se limite a reiniciarse.
Por qué esto es un problema de los socios
El soporte es la parte de un servicio gestionado que es fácil de vender y difícil de dotar de personal. Llega de forma irregular, necesita personas capaces de leer código desconocido bajo presión de tiempo, y en cuanto pone a sus mejores ingenieros en ello dejan de estar disponibles para el trabajo mejor pagado. La respuesta habitual es un nivel aparte y más barato que cierra tickets sin arreglar nunca nada, y el cliente lo nota en un trimestre.
Nuestra respuesta es que las personas de soporte son ingenieros. Pueden cambiar el sistema, no solo describirlo, que es la única manera de que un incidente recurrente deje de repetirse.
Lo que asumimos
Clasificación y diagnóstico
Recoger lo que el primer nivel no sabe responder, reproducirlo y decir qué falla en realidad en lugar de cerrarlo como no reproducible.
Correcciones que se sostienen
Defectos corregidos en su causa, con una prueba de regresión escrita contra toda la clase de error y no contra un solo ticket, para que el mismo incidente no vuelva el próximo trimestre.
Versiones y parches
Versiones de parches publicadas a través de su pipeline y de su proceso de cambios, con las dependencias, las versiones de frameworks y los runtimes de plataforma al día, en lugar de deslizarse hacia una crisis de actualización.
Respuesta de seguridad
Un aviso de seguridad publicado sobre algo de lo que usted depende es un motivo incondicional para actualizar, no un elemento del backlog. Lo seguimos, lo parcheamos y le decimos cuál fue la exposición.
Monitorización e incidentes
Vigilar las alertas que ya existen, añadir las que deberían existir y gestionar los incidentes con un informe escrito posterior sobre lo que ocurrió y lo que evita que se repita.
Cambios pequeños
El flujo constante de pequeñas mejoras que mantiene satisfecho a un cliente y nunca justifica un proyecto: se atiende dentro de la misma capacidad y en las mismas condiciones.
Su SLA, evaluado con honestidad
No publicamos objetivos de respuesta y resolución, porque una cifra inventada antes de que nadie haya visto su sistema no vale nada para usted ni para su cliente. En su lugar leemos el SLA que usted ya debe, le decimos qué partes podemos asumir de verdad y qué cobertura exige, y después nos comprometemos a ello por escrito.
Lo mismo vale para la cobertura fuera de horario. Cuando un proyecto la necesita y lo hemos acordado de antemano, la cubren personas reclutadas o asignadas para esas horas y no alguien al que se despierta confiando en la suerte. Ya trabajamos en horario europeo, australiano y del Pacífico de EE. UU. en otros proyectos, así que la pregunta es qué franja necesita usted, no si es posible.
Asumir un sistema que no construimos
Que es el caso normal. Nueve relevos hasta ahora, el más antiguo escrito en 2008.
Primero, una revisión de solo lectura
Obtenemos acceso al código, la infraestructura y el historial de tickets antes de ser responsables de nada de ello, y observamos en lugar de cambiar.
Una lista escrita de riesgos
Qué es frágil, qué está sin parchear, qué no está documentado y qué despertará a alguien por la noche, ordenado por impacto en producción. Es suyo, sigamos adelante o no.
La conversación sobre la cobertura
Leemos el SLA que usted debe a su cliente y le decimos con honestidad qué partes podemos asumir, qué horario exige y cuánto cuesta, antes de que ninguna de las partes firme nada.
Traspaso y después en producción
Un periodo definido de acompañamiento (shadowing) con quien tiene ahora el conocimiento, y después asumimos la cola. Si ya nadie conserva el conocimiento, empezamos en cambio por la revisión de riesgos.
Bajo su nombre, si ese es el acuerdo
El soporte suele ser la parte más visible de un servicio gestionado, por lo que es también donde más importa el white-label. Nuestros ingenieros pueden trabajar desde los buzones y las cuentas que usted emita, responder en su sistema de tickets y redactar informes de incidentes que usted reenvía sin cambios; su cliente trata con usted en todo momento. El desarrollo white-label explica cómo se organiza, y se aplica al soporte exactamente igual.
Cómo se fija el precio del soporte
Por persona y por mes, de modo que su propio coste sea predecible y usted pueda fijar el precio de un contrato de soporte a su cliente a partir de él. Todos registran sus horas en nuestro propio portal, usted ve las horas durante todo el mes y las mismas cifras generan la factura, de modo que hay un único registro con el que ambas partes concilian.
Cuando el soporte convive con el desarrollo nuevo, ambos suelen formar un único pod de entrega y no dos contratos, de modo que las semanas tranquilas de un lado compensan las semanas de mucha carga del otro.
Preguntas sobre los acuerdos de soporte
¿Qué cubre el soporte gestionado de aplicaciones?
Mantener en funcionamiento el software que ya está en producción: clasificar lo que entra en la cola, reproducir y corregir defectos, responder las dudas técnicas que el primer nivel no puede resolver, publicar versiones de parche, mantener actualizadas las dependencias y las versiones de la plataforma, vigilar las alertas y gestionar incidentes cuando algo falla. Es trabajo de segundo y tercer nivel; su primer nivel sigue donde está.
¿Trabajan según nuestro SLA?
Sí. No publicamos objetivos de respuesta y resolución, porque una cifra inventada antes de conocer su sistema no vale nada. Leemos el SLA que usted ya debe a su cliente, le decimos con honestidad qué partes podemos asumir y qué cobertura haría falta, y después nos comprometemos por escrito.
¿Pueden ofrecer cobertura fuera de horario o guardias?
Sí. La cobertura fuera de horario y las guardias se acuerdan de antemano, se incluyen por escrito en las condiciones del soporte y las atienden personas cuyo horario laboral coincide con ellas, de modo que un incidente nocturno llega a alguien que está de turno y no a alguien a quien se despierta.
¿Pueden dar soporte a un sistema que no han desarrollado ustedes?
Es lo habitual. Hasta ahora nos han llegado nueve sistemas de otros equipos, el más antiguo escrito en 2008. El soporte de un sistema heredado empieza con una revisión de solo lectura y una lista escrita de riesgos ordenados por su impacto en producción, de modo que las primeras semanas se dedican a entender de qué es usted realmente responsable, y no a adivinar bajo presión.
¿Las mismas personas que dan soporte al sistema también lo modifican?
Sí, y esa es la clave. Los ingenieros de soporte son ingenieros, no un nivel aparte que cierra tickets, así que un incidente recurrente puede corregirse en su causa en lugar de reiniciarse cada lunes. Cuando usted tiene con nosotros un flujo de desarrollo y otro de soporte, ambos comparten las revisiones de código y las decisiones de arquitectura.
¿Cómo se cobra el soporte?
Por persona y por mes, de modo que su propio coste es predecible y usted puede fijar el precio de un contrato de soporte a su cliente sobre esa base. Las horas se registran en nuestro portal y usted puede verlas durante todo el mes, y las mismas cifras generan la factura, así que hay una única fuente para ambas partes.
¿Tiene sistemas que mantener en funcionamiento?
Cuéntenos cuáles son los sistemas, qué promete su SLA y dónde le duele hoy el soporte. Lo leeremos y le diremos qué partes podemos asumir, incluidas las que no podemos.