Category Archives: Gestión del cambio

El Partido

El día D, el día de la puesta en producción.

La primera regla que hay que tener en cuenta es que siempre hay imprevistos.
Aplicar las previsiones vistas anteriormente minimizan riesgos y dan la confianza necesaria para esperar imprevistos no bloqueantes. Hay que tener muy claro que esto no garantiza que la aplicacion/servicio funcione.

Pueden existir procesos de calidad, pruebas de rendimiento, todo tipo de pruebas y documentación y el dia D, la nueva web se caiga con 5 peticiones porque la “home” hace conexiones sincronas recursivamente.

A veces, es simplemente que no todos los condicionantes estan planificados. Marketing contrata una empresa que le de hits (pj un proveedor de banners que te capture no solo el html de la home sino todo el site completo: html, imagenes,estilos,links…) cada vez que se vea un banner en una pagina de terceros (una razón mas para usar un Adblock) . Marketing y/o SEO han decidido inflar los números (hits y visitas), ingeniería junto a negocio han hecho una estimación realista de uso:  servidores, ancho de banda, pruebas de rendimiento… la suma es un DoS.

Por supuesto siguen estando los sospechosos usuales, elementos de producción no replicables en otros entornos que no se comportan como se esperaba o simplemente no se han tenido en cuenta, dimensionamientos insuficientes (las pruebas de rendimiento son un mundo y un arte). Leyes de Murphy, perversidad de la naturaleza, etc. lo esperable.

Lo importante es tener un buen plan de ruta, no estar perdido y tener claro los procesos de continuar o marcha atras. Todo ello debe estar ya planificado con antelación, incidencias siempre van a suceder.

La Previa, 2

Un cambio en producción puede ser algo relativamente sencillo: añadir un nodo a un cluster, actualizar un datasource o algo mas complejo como migrar un servicio, reemplazar la infraestructura o montar algo nuevo.
Aqui la diferencia es: ¿tienes un entorno de preproducción idéntico o usando la misma infraestructura que producción o una aproximación? Si es una aproximación deberás ser mucho más conservador en las estimaciones y preveer que saldrán mas incidencias no contempladas.

Como regla general y buenas practicas, simpre planificar un paralelo o una subida a producción previa a la subida a producción real.

  1. Paralelo: Tienes un servicio que reemplazas, reutilizas parte de la infraestructura para montar el nuevo servicio y realizar las pruebas internamente en un entorno real. El dia D se borran los datos de las pruebas y se abre al público. Si no hay marcha atras se procede a migrar el resto de la infraestructura.
  2. Nueva:  Si es un servicio nuevo, piensa en al menos 1 semana de pruebas en el entorno final de producción. El objetivo es minimizar los problemas generados por las diferencias entre los elementos de producción y los entornos de test.

Ningun piloto de rally se mete a hacer una carrera sin haber dado unas cuentas vueltas antes por el circuito, aunque ya lo conozca de otros años, aunque haya practicado en simulador o con el coche en otros circuitos similares en ese terreno. El bache de este año que hace saltar el coche y estrellarte contra un arbol es el bucle infinito entre dos redireccionares que solo existen en real.

La Previa

Ya sean mantenimientos o nuevos desarrollos el paso a producción es un caso delicado.

Siempre sale alguna incidencia, de primeras,la arquitectura no es 100% identica en todos los entornos. Incluso intentandolo siempre habrá algo que por algún matiz (por ejemplo precio) no se puede replicar de la misma manera y sin contar que los parámetros cambian, los errores tipográficos existen, las políticas de seguridad pueden ser mas estrictas, etc.

Con una buena gestión de cambios se puede estar relativamente optimista pero como se dice, el demonio esta en los detalles. Debes estar preparado para limarlos y que no aparezcan al usuario. Esto es muy importante, es como ser portero de fútbol, no importa que seas un buen portero y pares todo, si te marcan un gol no han servido de nada y si ademas es cantada te persigue, como el runrun en los campos.

El método es tener planificado el antes, durante y despues de la intervención.

Antes de la intervención:

  • Identificar ventana horaria y lugar de intervención (fuera de horas? remoto?)
  • Identificar personas y recursos que van a realizar la intervención.
    • Esas personas tienen permisos para realizar su trabajo?. Si es fuera de horas y en local tienen forma de entrar, si es en remoto tienen acceso a los servicios involucrados?
  • Identificar el conjunto de pruebas que debe pasar la solución. Si es distribuida en multiples sedes en todas ellas, idem si se accede de diferentes metodos: directamente, via proxy, desde internet, en local, por vpn, por citrix,…
    • Asegurarse que el conjunto de pruebas se pasa previamente tanto en la oficina como en el lugar/hora de intervencion. Si remotamente no es posible validar que la aplicación funciona piensa en hacerlo presencial o buscar formas de poder hacerlo remotamente (pj con dameware si terminal service no cumple).
  • Identificar y reservar conjunto de personas clave: grupo 1) responsables de la aplicación, grupo 2) usuarios clave de la aplicación (pj uno por sede)
    • Grupo1: Anunciar con tiempo, solicitar permisos necesarios y recibir vistos buenos
    • Grupo2: Reservarlos para pruebas de funcionamiento (antes, durante y despues). Si el proyecto es importante los tendras durante pero lo normal es que solo esten disponibles despues e incluso ya en horario solo produccion.
  • Documentar el plan de pruebas en modo checklist y que sea validado por el Grupo 1. Esto es importante, es tu contrato con negocio. Si falta algo siempre podrás venir a este documento y decir que no entraba en las especificaciones (es un escudo no una carta de “libre de cárcel”). En un mundo ideal el plan de pruebas te lo pasaría desarrollo o el dueño de la aplicacion, y es cierto en parte pero por diferencias lingüísticas (nota mental: diferencias conceptuales entre desarrollo y sistemas) lo normal es obtener pruebas funcionales pero no pruebas completas.
  • Documentar plan de contingencia y marcha atras. Especial atencion a cuando se activa (fecha limite para decidir continuar o dar marcha atras. Aqui se debe tener en cuenta el tiempo necesario para poder dejar la situacion original) y que personas lo deciden y bajo que condiciones.

A veces el proyecto es mas complejo, involucra múltiples equipos, aplicaciones y dependencias. Es complicado llegar a ellos sin haber hecho previamente más simples. Mismos pasos pero de forma recursiva. Ata cada componente y añade la complejidad de interelación entre ellos que tambien deberás controlar y validar.