Gestión y escalado

Operar y seguir desarrollando soluciones digitales: OTOKO® le apoya en el mantenimiento, la gestión técnica y el escalado de sus sistemas.

Las actualizaciones de seguridad, los nuevos requisitos y las incidencias no terminan con la aceptación.

Traspaso con análisis de código, inventario de dependencias, documentación y transferencia de conocimiento Monitorización con Prometheus, Grafana y OpenTelemetry, con alertas según gravedad Gestión de incidencias y problemas según ITIL mediante Jira Service Management Actualizaciones de seguridad y mantenimiento de dependencias con Renovate, con verificación frente a vulnerabilidades conocidas Informes periódicos sobre disponibilidad, incidentes y riesgos abiertos

Catálogo de servicios con procedimientos de respuesta y responsabilidades Monitorización con alertas y dashboards Informes de operación con incidentes y riesgos

Repositorio, licencias y accesos técnicos Documentación, incidentes conocidos y proveedores de servicios actuales Horarios de servicio esperados y criticidad funcional

Una aplicación de negocio desarrollada internamente debe traspasarse a un equipo externo. Tras el análisis de código y la obtención de un build reproducible, primero se comprueban la monitorización y la recuperación. A continuación, comienza el mantenimiento con los horarios de servicio acordados y una lista priorizada de problemas heredados.

Jira Service Management Grafana Prometheus OpenTelemetry Renovate

Antes de asumir la responsabilidad, comprobamos el acceso al código, los derechos de uso, las dependencias y la posibilidad de compilar nosotros mismos una versión. Junto con usted, registramos los problemas conocidos, el conocimiento operativo y los procesos críticos. Que la aplicación arranque correctamente no es suficiente. También deben estar aclaradas la copia de seguridad, la recuperación y la responsabilidad sobre los servicios externos. Del traspaso resulta un alcance de servicio con riesgos abiertos y medidas priorizadas. Los problemas heredados que no se pueden controlar no se incluyen tácitamente en un compromiso genérico. Si antes es necesaria una estabilización, se describe como un paquete de trabajo independiente.

Que un servidor esté en funcionamiento dice poco sobre si los usuarios pueden realizar su trabajo. Por eso orientamos también la monitorización hacia las operaciones y las interfaces relevantes de la aplicación. Las notificaciones se clasifican según su impacto. Cada alerta necesita un destinatario y un primer paso de actuación razonable. Los horarios de soporte, los objetivos de respuesta y las vías de escalado se fijan en el contrato. Un tiempo de respuesta no equivale a un tiempo de solución garantizado. Para las incidencias graves, aclaramos la comunicación, las competencias de decisión y la colaboración con su proveedor de infraestructura o de software.

Las actualizaciones se evalúan según el riesgo, la urgencia y la compatibilidad. Mantenemos las dependencias visibles, comprobamos los cambios en un entorno adecuado y planificamos la entrega con un plan de vuelta atrás. Las incidencias recurrentes se analizan en busca de sus causas, para que la operación no consista de forma permanente en las mismas reparaciones. Los informes periódicos relacionan los incidentes, los riesgos técnicos y las decisiones pendientes. Las mejoras pequeñas pueden incluirse dentro del marco acordado; las ampliaciones funcionales de mayor envergadura se priorizan por separado. Para una eventual devolución del servicio a su equipo, documentamos de forma continua el conocimiento y los accesos.

Una aplicación puede estar accesible y, aun así, no procesar pedidos. Por eso elegimos puntos de medición para los procesos de usuario relevantes y distinguimos entre accesibilidad, procesamiento correcto y tiempo de respuesta. Un objetivo de servicio necesita un periodo de medición, una fuente de datos y reglas para tratar las mediciones ausentes. Solo así se puede valorar con criterios verificables si se ha alcanzado el estado acordado. La desviación restante respecto al objetivo puede utilizarse como presupuesto de errores para equilibrar la estabilización y la evolución. Qué consecuencias tiene un incumplimiento se define de forma conjunta. Esto no sustituye ni los acuerdos contractuales de servicio ni la evaluación de un incidente grave concreto. Los dashboards y las alertas deben apoyar la toma de decisiones: quién reacciona, qué diagnóstico sigue y cuándo hay que informar a los responsables de negocio.

Que una copia de seguridad se complete correctamente no demuestra todavía que se pueda restaurar. Aclaramos qué pérdida de datos sería como máximo aceptable y cuánto puede durar una interrupción. De ahí se derivan los requisitos para los intervalos de copia, la conservación y el restablecimiento. Además de la base de datos, la aplicación suele incluir archivos, configuración, claves y servicios externos; si falta una parte, una copia técnicamente legible puede resultar inservible. Los ejercicios de recuperación verifican el procedimiento acordado en un entorno adecuado. Durante estos ejercicios se documentan la duración, los accesos necesarios, los pasos manuales y las comprobaciones de negocio de los datos. Un único inquilino o un registro eliminado por error pueden requerir procedimientos de recuperación distintos a los de un fallo total. Los resultados se traducen en mejoras concretas. Las carencias detectadas se comunican de forma explícita, en lugar de presentar un valor objetivo no verificado como una capacidad garantizada.

Un aviso sobre una biblioteca vulnerable se evalúa en el contexto de la aplicación: qué versión está integrada, si la función afectada es accesible y qué medidas de protección existen. La urgencia y el riesgo técnico del cambio se analizan de forma conjunta. Para las actualizaciones que no son posibles de inmediato, se necesitan medidas provisionales documentadas y una fecha para una nueva evaluación. Las nuevas versiones pasan por las pruebas adecuadas y una implementación acordada. Tras incidencias recurrentes o graves, investigamos la causa, la detección y la reacción. De ahí surgen medidas priorizadas con responsables asignados, no solo un ticket cerrado. La documentación, los runbooks y los resúmenes de accesos se mantienen de forma continua. También se prepara el posterior traspaso a su equipo o a otro proveedor de servicios: con repositorio, instrucciones de build, riesgos abiertos y una transferencia de accesos ordenada. Un servicio es sostenible a largo plazo cuando el conocimiento está documentado de forma comprensible.

Panorama de aplicaciones, requisitos, riesgos Área de negocio, TI, seguridad de la información, arquitecto de software de OTOKO® Proyectos evaluados, inventario, requisitos de seguridad y de operación

Arquitectura, tecnología, modelo de operación Área de negocio, arquitectura, protección de datos, seguridad de la información Arquitectura objetivo, modelo de amenazas, estrategia de pruebas, modelo de operación, hitos