Qué debería entregar una evaluación de infraestructura de dos semanas

Lo que dos semanas pueden y no pueden hacer

Dos semanas son unos diez días laborables. Es suficiente para entender a fondo una parte acordada de un entorno: una plataforma, un conjunto de aplicaciones, un candidato a migración o un pipeline de entrega. No es suficiente para evaluar todo lo que usted ejecuta, y un evaluador que promete eso está prometiendo un informe superficial.

Por eso el documento más importante se escribe antes de empezar: el alcance. Debe nombrar los sistemas y entornos incluidos, las preguntas que la evaluación debe responder, lo que queda fuera y quién está disponible por su parte. Un reparto habitual dedica aproximadamente la mitad del tiempo al descubrimiento y las entrevistas, y la otra mitad al análisis y la redacción. Una evaluación tampoco es una implementación. Si los cambios empiezan durante la evaluación, los hallazgos dejan de describir el entorno que realmente tiene.

Lo que debería preparar

La mayoría de las evaluaciones pierden sus primeros días esperando accesos. Organice un acceso de solo lectura a los sistemas incluidos antes del primer día y reúna lo que ya existe: diagramas de arquitectura, aunque estén desactualizados, exportaciones del inventario o de la CMDB, paneles de monitorización, los últimos seis a doce meses de incidentes y cambios, y las fechas de renovación y de fin de soporte de las licencias y contratos implicados.

Reserve tiempo con las personas que saben cómo funcionan realmente las cosas: los ingenieros que operan la plataforma, quienes despliegan en ella y el responsable que la paga. Unas pocas horas de entrevista con cada uno suelen bastar. Los documentos describen el sistema previsto; las personas describen el real.

Cómo suelen transcurrir las dos semanas

Una evaluación bien llevada tiene un ritmo visible. Los primeros dos o tres días se dedican al arranque, los accesos y las entrevistas, confirmando que el alcance y las preguntas siguen siendo válidos una vez que el evaluador ha visto el entorno. La mitad de la primera semana y el inicio de la segunda se dedican al descubrimiento práctico: leer configuraciones, trazar dependencias, comprobar qué hacen realmente la monitorización y las copias de seguridad, y recorrer el pipeline de entrega con quienes lo usan.

Los últimos días se dedican al análisis y la redacción. Pida una breve reunión de seguimiento al final de cada semana. La primera detecta una suposición errónea cuando aún hay tiempo para corregirla; la segunda anticipa los hallazgos principales para que la presentación no sorprenda a los más afectados. Si no sabe nada durante diez días y después recibe un informe terminado, el evaluador ha trabajado a su alrededor, no con usted.

Una imagen de lo que existe

El primer entregable es una descripción precisa del estado actual. Para la infraestructura significa la topología: sistemas, dependencias, flujos de datos, versiones y estado de soporte, incluido todo lo que ya haya superado su fin de soporte. Para la entrega significa el pipeline: cómo llega un cambio a producción, quién lo aprueba, qué se prueba por el camino y cómo se revierte una versión defectuosa.

Una buena evaluación separa lo verificado de lo declarado. "La copia de seguridad se ejecuta cada noche" significa una cosa cuando alguien lo dice y otra cuando el evaluador ha visto una restauración correcta. Usted debería poder distinguir una de otra.

Hallazgos ordenados por riesgo, con evidencias

Cada hallazgo debe incluir su evidencia, su impacto, la probabilidad de que el problema se materialice y, aproximadamente, lo que cuesta corregirlo. Después, los hallazgos deben ordenarse. Una lista de 200 puntos con el mismo peso es una transferencia de trabajo, no un resultado. Usted quiere saber qué cinco cosas importan este trimestre.

Separe los riesgos urgentes de las mejoras. Las versiones sin soporte, los puntos únicos de fallo y las copias de seguridad que nunca se han restaurado van arriba. Unas convenciones de nombres más ordenadas, no. Una perspectiva coherente ayuda: revise cada sistema en cuanto a fiabilidad, seguridad, coste, operabilidad y rendimiento, y use referencias reconocidas e independientes de cualquier proveedor para el detalle, como el NIST Cybersecurity Framework para la seguridad, organizado en seis funciones: gobernar, identificar, proteger, detectar, responder y recuperar. Use un marco como lista de comprobación de cobertura, no como el entregable en sí.

Una arquitectura objetivo que pueda defender

La arquitectura objetivo debe ser un documento escrito, no solo un diagrama. Debe decir cómo debería ser el entorno, por qué, qué alternativas se consideraron y por qué se descartaron, y qué restricciones determinaron la elección: presupuesto, habilidades, contratos, regulación o plazos.

También debe decir qué se queda como está. Un objetivo que lo sustituye todo rara vez es creíble, y conocer las partes que están bien también es útil.

Una secuencia con vuelta atrás

Un objetivo sin ruta es un deseo. La evaluación debe proponer un orden de movimientos basado en dependencias y riesgo, con un plan de vuelta atrás para cada movimiento y puntos de decisión claros en los que pueda detenerse, cambiar de rumbo o continuar.

También debe indicar el coste de no hacer nada: renovaciones de licencias que le atarán otro periodo, versiones que se quedan sin soporte en fechas conocidas y riesgos que crecen mientras nada cambia. A menudo eso es lo que justifica actuar, o esperar deliberadamente.

Una presentación para quienes deciden

El último entregable es una presentación para la dirección: las decisiones necesarias, las opciones para cada una, sus riesgos y el esfuerzo aproximado. Debería poder actuarse sobre ella sin el evaluador en la sala. Los documentos detallados se quedan con sus ingenieros.

La implementación debe presupuestarse por separado y nunca ser una condición de la evaluación. Los hallazgos solo son fiables si serían los mismos tanto si contrata al evaluador para corregirlos como si no.

Después de la presentación

Una evaluación solo vale lo que cuesta si después pasa algo. Convierta los hallazgos ordenados en un backlog que su equipo posea, con un responsable y una fecha objetivo para los puntos principales. Algunos riesgos, como una versión sin soporte en producción o una copia de seguridad que nunca se ha restaurado, deberían corregirse en semanas, decida lo que decida sobre lo demás.

Después, use la arquitectura objetivo y la secuencia para decidir cómo ejecutar: con su propio equipo, con el evaluador, con otro proveedor o con una combinación. Como los documentos son suyos, esa elección sigue abierta. Revise los hallazgos al cabo de un trimestre; una evaluación que sigue siendo precisa seis meses después, y cuyos riesgos principales se han cerrado, cumplió su función.

Señales de alerta

Desconfíe de hallazgos sin evidencias, de listas genéricas de buenas prácticas que podrían describir a cualquier empresa y de recomendaciones que solo el producto del propio evaluador puede satisfacer. Desconfíe de una lista sin ordenar, de una arquitectura objetivo sin ruta de migración, de una ruta de migración sin vuelta atrás y de un alcance que creció en silencio hasta "todo" sin que creciera el tiempo.

Por último, compruebe a quién pertenece el resultado. Debería recibir todos los documentos en un formato editable y poder compartirlos con quien quiera, incluido otro proveedor.

Cómo encaja nuestro Sprint de evaluación

Nuestro Sprint de evaluación se construye en torno a estos entregables: una revisión de dos semanas del entorno acordado, una auditoría de la topología y del pipeline de entrega, una arquitectura objetivo por escrito, una secuencia de migración con planes de vuelta atrás y una presentación para la dirección. Tiene una tarifa fija, el alcance se acuerda por escrito antes del pago y cualquier implementación se presupuesta por separado.