El lanzamiento es el inicio de la parte cara.
Un producto en producción necesita actualizaciones de dependencias, parches de seguridad, monitoreo que alguien lea, y un camino para el defecto que un cliente encontró un domingo.
El problema
Esto es lo que los clientes compran con más frecuencia. El software no se queda quieto. Las dependencias se descontinúan, los certificados expiran, una versión del sistema operativo rompe un supuesto, y el volumen crece más allá de lo que podía cargar una decisión temprana.
Si se deja solo, eso se acumula en silencio por dos años y después se presenta como una crisis sin causa evidente. Si se maneja de forma continua, es un consumo pequeño y predecible de capacidad.
Mientras un Pod está corriendo, el mantenimiento sale de la misma capacidad de puntos que el trabajo de funcionalidades, así que puedes ver el intercambio que estás haciendo. Cuando un mes se va en buena parte a mantenimiento, eso se ve en el reporte de capacidad, y se vuelve una conversación en vez de una sorpresa.
Cuando termina una construcción, esto se vuelve algo propio. Una garantía de 30 días calendario cubre sin costo los defectos que califican en nuestro código, contados desde tu aceptación escrita del lanzamiento a producción. Más allá de eso, el soporte es un plan mensual aparte dimensionado en puntos, desde mantenimiento liviano sobre un producto estable hasta atención prioritaria en uno que todavía se está moviendo.
- Una garantía de 30 días sobre el software entregado, y después un plan mensual opcional
- Mantenimiento de dependencias y de seguridad con calendario, no con un incidente
- Monitoreo configurado para que las alertas signifiquen algo y se lean
- Cuatro severidades con objetivos de respuesta, acordados antes del lanzamiento
Qué cubre esto
Mantenimiento de seguridad
Parches, auditorías de dependencias y respuesta a vulnerabilidades divulgadas.
Monitoreo que se lee
Alertas afinadas al hecho de negocio, revisadas como parte del ciclo.
Desviación de desempeño
Atrapar la degradación lenta antes de que los usuarios digan que el producto está lento.
Cuidado de la infraestructura
Costo, capacidad y configuración revisados en vez de dejados crecer.
Camino para incidentes en producción
Severidades y expectativas de respuesta acordadas y escritas.
Continuidad
Documentación y accesos que sobreviven a que la gente cambie de trabajo.
Si no está probado, no existe
El monitoreo es la cosa que todo aliado afirma y que casi nadie comprueba. Un rastreador de errores sin su DSN configurado, una línea de log que nadie envía a ningún lugar donde se pueda buscar, una alerta enrutada a un canal que se silenció el trimestre pasado: todas esas se ven como observabilidad en una diapositiva y ninguna te va a decir cuándo se rompió tu producto.
Así que lo tratamos como una funcionalidad con sus propios criterios de aceptación. Si la captura de errores no se verifica provocando un error a propósito y confirmando que llegó con el contexto correcto, es una aspiración. Lo mismo aplica para las líneas de log estructurado que emite un proceso en segundo plano y para la alerta que supuestamente despierta a alguien.
Hay una razón específica por la que esto importa más en la entrega AI-First. Las fallas que llegan a producción desde código generado rara vez son caídas. Son interpretaciones plausibles de un requisito ambiguo que producen resultados silenciosamente equivocados, contratos que se desviaron después de que se escribió la integración, y consultas a la base de datos que son correctas pero generan una llamada por fila. Ninguna de esas se anuncia. Todas son visibles en las trazas de desempeño y en el contexto de los errores si el cableado es real.
- Rastreo de errores en frontend, backend y procesos en segundo plano, con contexto de versión y de usuario
- Trazas de desempeño con una línea base p95 por endpoint, para que una regresión sea un número y no una sensación
- Detección de explosión de consultas, que es el olor de desempeño más común en código generado
- Logs estructurados con un identificador de correlación, para poder reconstruir una acción de usuario de punta a punta
- Verificaciones de salud que prueban dependencias reales, no solo que el proceso está vivo
- Alertas enrutadas a un responsable con nombre por área, según la severidad
Cuatro severidades, acordadas antes de necesitarlas
Los objetivos de respuesta son en horario laboral, sobre defectos reproducibles en código que escribimos, mientras un plan de soporte esté activo. Publicados aquí en vez de negociados durante un incidente.
| Dimension | Respuesta inicial | Contención | Resolución objetivo |
|---|---|---|---|
| P1. Crítica: un flujo central está caído y no hay alternativa | Dentro de 2 horas hábiles | Dentro de 1 día hábil donde sea viable | Dentro de 2 días hábiles para defectos en nuestro código |
| P2. Alta: degradación mayor, existe una alternativa parcial | Dentro de 4 horas hábiles | Dentro de 2 días hábiles donde sea viable | Dentro de 5 días hábiles para defectos en nuestro código |
| P3. Media: mal funcionamiento parcial, impacto limitado al negocio | Dentro de 1 día hábil | Según priorización mutua | En el siguiente ciclo disponible |
| P4. Baja: cosmética o usabilidad menor | Dentro de 2 días hábiles | No aplica | Priorizada dentro del backlog |
Estos no son una garantía de disponibilidad y no incluyen monitoreo 24/7 ni disponibilidad fuera de horario, salvo que se contrate aparte. Cuando un tercero controla la corrección, investigamos y contenemos, pero no podemos comprometer una ventana de resolución que no nos corresponde.
Dónde se detiene un plan de soporte
Un plan de mantenimiento es en horario laboral, de lunes a viernes. No es una garantía de disponibilidad y no es un equipo de operaciones. El monitoreo permanente, un turno de disponibilidad, y las operaciones de infraestructura como aprovisionamiento, escalamiento y recuperación ante desastres son todos trabajo real, y todos se dimensionan aparte en vez de asumirse en silencio dentro de una tarifa mensual.
Vale la pena decir en voz alta otros dos límites. Una actualización mayor de framework o de entorno de ejecución que necesita una migración coordinada es un proyecto, no mantenimiento. Y las pruebas de penetración y las auditorías formales de seguridad pertenecen a nuestra práctica de gobierno, con un fijo mensual o una tarifa fija, porque una opinión de auditoría no es un story point.
La capacidad no usada en un plan de soporte no se arrastra al mes siguiente, que es lo contrario de cómo funcionan los puntos acumulados en un Pod. Preferimos que lo sepas antes de escoger un nivel y no después.
- Soporte en horario laboral, de lunes a viernes, excluyendo los festivos de la compañía
- Monitoreo 24/7, disponibilidad por turnos y operaciones de infraestructura se dimensionan aparte
- Las migraciones de versión mayor se manejan como proyecto, no como mantenimiento
- Todo lo que exceda la capacidad del plan se estima y se acuerda antes de empezar
Qué mueve la estimación
Los planes de soporte se dimensionan en capacidad mensual de puntos, así que escoger un nivel es en realidad un pronóstico de cuánto cambio va a absorber el producto. Dos productos con funcionalidades idénticas pueden necesitar planes muy distintos.
El factor dominante es la superficie de dependencias. Un producto apoyado en seis servicios de terceros hereda los calendarios de liberación, las descontinuaciones y las caídas de seis otras compañías, y alguien tiene que absorber eso, lo hayas planeado o no.
- De cuántos servicios de terceros dependes, y qué tan agresivamente descontinúa cada uno
- Si el producto todavía está cambiando o de verdad está estable
- Datos regulados dentro del alcance, que vuelven los parches una obligación de cumplimiento en vez de una preferencia
- Móvil dentro de la mezcla, porque las versiones del sistema operativo llegan en el calendario de Apple y de Google, no en el tuyo
- El crecimiento del tráfico, que convierte la decisión razonable de ayer en el cuello de botella de hoy
Preguntas que vale la pena hacer
¿Pueden mantener un producto que construyó otro aliado?
¿La capacidad no usada del plan se arrastra?
¿Qué cubre la garantía y qué cubre un plan?
¿De verdad necesitamos un plan?
¿Y si necesitamos algo fuera del plan?
Soporte medido en años
El mantenimiento es la razón por la que varios de los proyectos que ves en nuestra página de trabajo llevan años y no meses.
Tráenos el backlog.
En 30 minutos te mostramos qué entregaría primero un Pod y cómo lo cotizaríamos.