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.

 

Patrones de comportamiento

El análisis de la historia, su dinámica, la percepcion de que la historia se repite son indicadores de la existencia de patrones de comportamiento. No es muy distinto a lo que intenta hacer la rama de Bussines Inteligence o el pronóstico meteorológico. Esos patrones de comportamiento permean en todos los ámbitos y las relaciones (personales y grupales).

Los cambios históricos en general vienen marcados por un componente bélico. Las innovaciones técnicas son importantes, la agricultura en el eufrates/tigris y en el nilo permitirón el nacimiento de las primeras civilizaciones hace 6 mil años, el caballo permitio la creación del primer sevicio de mensajeria y el mantenimiento del primer imperio asirio (conquistado a sangre y fuego). Sin embargo cuando organizamos la historia la hacemos en civilizaciones o dinastias y su nacimiento/explendor esta marcado por su potencia militar: el caballo,  el hierro, la falange, la legión, el tercio español, la armada naval inglesa o el nuevo mapa político provocado por la bomba atómica.

El ámbito empresarial no es ajeno a estas dinámicas, los ejemplos más claros son terminos comúnmente aceptados como guerra comercial, guerra de precios, guerra de patentes, absorciones, etc. pero también se puede considerar una empresa como un estado, un sector como una zona territorial, nuevas áreas de negocio como exploración o colonización y podríamos seguir buscando analogías ad eternun.

Mi intención en esta categoria de Filosofia e Historia, es reflexionar sobre estas analogías y su aplicación moderna en el ámbito del trabajo. Inaugurare el apartado con el fantástico mundo del outsourcing y la subcontración o lo que toda la vida se ha conocido como mercenarios.

 

A mi me funciona

Los expedientes-X existen, fallos que no tienen explicación o razón de ser pero pasan. A veces encuentras la causa,  a veces se arreglan como vienen y otras veces acabas dando un rodeo para solucionarlo. Cuanto más niquelado tengas la plataforma bajan en cantidad y suben en calidad.

Pero lo normal es encontrarse errores típicos y en el caso de errores en aplicaciones necesitas la complicidad de desarrollo y estar seguro de poder descartar hipótesis. Para hacerlo, lo primero es poner orden y establecer unas reglas que simplifiquen a plataforma.

  • Un repositorio central de código fuente versionado y auditable.
  • Entornos de desarrollo, test, preproducción y producción homogeneos e identicos: mismas aplicaciones, mismas versiones, mismos conectores, drivers (incluso versión), misma estructura/plataforma (pj en cluster, con proxys intermedios,bbdd independientes por entorno, usuarios por entorno,etc…). Los entornos de test y los de desarrollo deben ser lo mas parecidos a producción posibles (no siempre es asi, si en produccion tienes 2 balanceadores por valor de 90k euros es complicado tenerlos en test).
  • Un unico proceso de construcción por aplicación. Construcción identica tanto para los entornos de desarrollo, test como producción.
  • Código fuente identico para una aplicación en los diferentes entornos, solo cambia la parametrización del entorno. Aseguras que la aplicación con etiqueta X es la misma aplicación X que probo el usuario, que se subió a preproducción y que generó desarrollo. No hay comportamientos distintos de la aplicación porque el código fuente sea distinto, si se comporta de forma distinta es por la casuistica del entorno (acotas hipótesis).
  • Procesos de construcción automáticos sin intervención manual (o intervención minima al declarar etiqueta X). Te aseguras que nadie mete la pata sin querer y que lo que construye hoy lo construye como ayer y antes de ayer. Y si instala, en los mismos sitios y de la misma forma.
  • Pruebas de integración continua, calidad del software, pruebas de regresión. Todo automático por supuesto, ya tienes las herramientas básicas en los pasos anteriores. Dependes de los programadores para hacer pruebas unitarias y chequeos pero es la forma de detectar errores de regresión (errores ya corregidos que vuelven aparecer en versiones posteriores) .
Seguro que me dejo más, aunque es lo básico y suficiente para tener algo decente. Esto no evita que existan problemas, evita que existan muchos problemas en un entorno en caos.