# Mantenimiento y Soporte > Mantenimiento continuo, monitoreo, y cuidado de dependencias y seguridad para productos en producción. Una garantía de 30 días, y después cuatro severidades con objetivos de respuesta publicados. Fuente: https://www.koombea.com/es/capabilities/maintenance-and-support/ --- 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. | | 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? Sí, y arranca con un descubrimiento para saber a qué nos estamos comprometiendo. Comprometer objetivos de respuesta sobre un código que no hemos leído sería una promesa que no podríamos cumplir. El trabajo de documentación que está bajo modernización de plataformas a menudo es el primer paso correcto. ### ¿La capacidad no usada del plan se arrastra? No. Los puntos acumulados en un AI Pod se arrastran por 90 días. La capacidad no usada en un plan de soporte no se arrastra, salvo que el acuerdo diga otra cosa. No asumas que el comportamiento del Pod aplica aquí. ### ¿Qué cubre la garantía y qué cubre un plan? La garantía de 30 días cubre sin costo los defectos que califican en código que escribimos, desde tu aceptación escrita del lanzamiento. No cubre funcionalidades nuevas, cambios que despliegues tú o un tercero, ni fallas de terceros. Cuando expira, un plan de soporte es la forma en que ese mismo trabajo sigue pasando. ### ¿De verdad necesitamos un plan? No necesariamente. Un producto genuinamente estable con pocas dependencias puede aguantar mucho tiempo sin nada, y te vamos a decir cuándo esa es tu situación en vez de venderte un fijo mensual. Los productos que sí necesitan uno son los que siguen cambiando o los que cargan obligaciones regulatorias. ### ¿Y si necesitamos algo fuera del plan? Se estima en puntos y se acuerda por escrito antes de empezar, a la misma tarifa que cualquier otro trabajo. No hay penalidad ni sobreprecio por estar 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.