All posts by gGainza

Separación de poderes (Parte 2)

Suponiendo un proceso automático y razonable de gestión del cambio ya implantado (nota mental: como montar uno) , hay pocos motivos buenos para intentar saltárselo y muchas excusas para tapar problemas o colar cosas (similar a violar una cadena de custodia. Toda linea de codigo en produccion debe ser auditable durante todo el proceso de cambio: desde quien la desarrolló, por los entornos que ha pasado, quien la ha promocionado, cuando, etc.).

Sin embargo es normal que haya presiones para saltárselo, casi siempre con la excusa de la “flexibilidad“. Y es difícil negarse si dirección permite vulnerar las normas y seguridad mira para otro lado. Es un camino que lleva al caos y la anarquía así que si se da la situación hay que entender la causa y minimizar daños.

Modificaciones en el entorno de produccion

La causa más común es que no han probado la aplicación previamente, se sube a produccion y el usuario se da cuenta que hay tipos o palabras mal escritas. Otra veces son funcionalidades que no han probado y cuando entran producen un fallo. Suelen necesitar soluciones tontas, modificar un texto, subir una clase, no son cambios masivos y juegan con “¿por esta tonteria hay que rehacer todo el proceso?) .

El problema es que el proceso existe para que todo quede registrado, si se modifica directamente no queda registro. A veces estos cambios no exigen reiniciar y son un fix rapido. No hay muchas alternativas, el compromiso es que sea una petición oficial de negocio con copia a jefes de IT (para evitar ir de tapadillo) y un cambio de emergencia siguiendo el proceso normal para la siguiente ventana de instalación. En estos casos el fix no registrado dura el menor tiempo posible online.

Modificaciones en el entorno de integración o pruebas de usuario

Con gente de la casa no suele existir el problema pero esto es facil que suceda si subcontratas proyectos a consultoras externas. Se sienten encorsetados y empiezan a poner pegas de si no van a llegar en fechas (un clásico).

Si esto sucede, la causa principal es falta de calidad del equipo de desarrollo. No saben trabajar en local e integrar cambios y necesitan acceder directamente a una maquina para tener algo funcionando a base de prueba y error. Esto es como ver un lemming, ya sabes que va acabar despeñado.  Contención de daño, si dirección no hace nada al respecto tu objetivo es que no te arrastren (a ti y al resto de aplicaciones).

Monta una estructura paralela de entornos, crea entornos de desarrollo y que trabajen con ellos. Estos equipos no duran mucho más que la creación de la aplicación y el marrón del mantenimiento se lo comen otros, lucha para que el mantenimiento este integrado en el proceso oficial de cambio (no es dificil, ya que la excusa es la flexibilidad para sacar el nuevo proyecto y una vez fuera ya esta cubierta, los actores se han ido o apunto de irse, y las medallas colgadas en el hombro de algun jefe, funcione… o no.)

Para ello hay que asegurarse que la aplicacion se integra con el proceso de cambio, construye e instala en todos los entornos. Y la construcción se atiene a unas normas de la compañía.

A veces, la causa es puramente ego de un jefe de proyecto, querer estar por encima de las normas. Normalmente nadie le para lo pies e incluso esta muy bien valorado por dirección. Dale cuerda, pero recuerda esta gente nunca se ahorca siempre encuentran a alguien que ocupa su sitio en el nudo. No seas tu.

 

Separación de poderes (Parte 1)

En 1748, Montesquieu en “El espíritu de las leyes” establecía la separación de poderes en el estado (legislativo, ejecutivo y judicial) como método de control del desgobierno.

En la gestion de cambios, el proceso de desarrollo o mantenimiento de uno o múltiples productos en el tiempo, este concepto es básico y a partir de él, definiremos la estrategia.

Los actores son 3 ( 4 si el proceso de auditoría lo lleva otro dpto.):

  • Desarrollo
  • Infraestructuras
  • Operación

Desarrollo controla el código fuente de las aplicaciones y los entornos de desarrollo. No tiene acceso físico a los entornos de test ni producción (dejare para otro día que separa unos de otros) .

Infraestructuras (o Sistemas o Arquitectura o …) tiene control de los entornos de test y producción. Su función es mantener el chiringuito funcionando llueva o nieve. CYA, desarrollo puede hacerte la vida muy difícil, jugar todos con las mismas reglas escritas e inmutables es tu primera linea de defensa.

Operación gestiona los pasos o promociones entre entornos, son los encargados de instalar las aplicaciones u operar sobre ellas. No tienen acceso ni al codigo fuente ni a las maquinas fisicas. Trabajan con aplicaciones (ya hablaremos de ellas otro dia) como Quickbuild o Jenkins montadas por sistemas y son la unica forma legal de instalar una aplicacion en un entorno.

En general operación no tiene mucha libertad (y tampoco se busca) se trabaja con manuales o procedimientos y no se salen de ellos. Si un manual no existe tampoco existe la posibilidad de que lo hagan. A veces pueden controlar el acceso de Sistemas a las propias maquinas mediante herramientas de asignación de usuarios temporales y ventanas de tiempo con permisos.

Este blog tiene el punto de vista del área de sistemas, otras áreas tendrán su perspectiva que seguramente no sea la misma pero tampoco muchas veces están sujetos a las mismas responsabilidades: si una aplicación cae sistemas es quien se da cuenta (o debería, enterarse por el usuario es un no-no, primera y principal causa de mal rollo entre negocio e IT). Quizá haya empresas en las que desarrollo (quien siempre tiene acceso a los logs) se hace responsable (es su aplicación, la conoce, la ha programado) analiza la causa y pone remedio… mi experiencia es que los logs ni se miran, a desarrollo hay que perseguirlo porque “no es crítico para negocio”, la prueba de demostrar esa criticidad corre por parte de sistemas, hay que mantener un SLA pero hay cambios en producción cada 3 dias, etc.

No hay balas de plata o soluciones técnicas  a problemas no técnicos, técnicamente un marco estable de trabajo es el minimo para trabajar, la parte 2 tratará de porque hace falta esta separación y a que peligros se enfrenta y porque. El siguiente tema sera la inmutabilidad del código fuente de una aplicación.