29 Apr 21
The importance of proper system monitoring
Monitoring is the basic pillar of IT departments. Knowledge is power, and power is the capability of deciding what, how, […]
Un día ágil en tu departamento de IT
18 Feb 21
Seguro que si eres aficionado a las metodologías Agile o al mundo Lean habrás leído en más de una ocasión cómo su buen uso te puede ayudar en un proyecto de software.
Pues bien, querido amigo del lado oscuro, incomprendido de la informática al que solo se nombra cuando algo se rompe. Sí, me estoy refiriendo a ti y a todos esos chicos del departamento de sistemas que nadie tiene en cuenta para el arranque de los proyectos, que se encuentran muchas veces toda la arquitectura de la nueva plataforma definida, que tienen que escuchar frases como la de “en mi máquina funciona”. Para ti y para todos ellos hay luz al final del túnel: esa luz son este tipo de metodologías.
Todo equipo de sistemas tiene que enfrentarse en mayor o menor medida a una serie de tareas:
Históricamente, estas tareas se han venido realizando, la verdad, sin mucho control, sobre todo en plataformas que no son de gran tamaño (en empresas grandes te puedes encontrar con la implementación de ITIL y cosas por el estilo, pero no es frecuente).
Metodologías como Lean o Scrum nos pueden ayudar en cada uno de los escenarios o etapas anteriormente listados.
Este tipo de metodologías está especialmente pensado para vivir en entornos flexibles, de cambios constantes. Muchos administradores de sistemas de la vieja escuela se echarán las manos a la cabeza cuando ven aquello de “cambios constantes”. ¿No se supone que una plataforma de sistemas debe de ser estable? Cuantos menos cambios, más estable, ¿no? Sí y no; aquí no estamos hablando de diseñar una plataforma poco estable: estamos hablando de que las necesidades del negocio (y en el momento en el que vivimos más aún) son muy cambiantes y hay que estar en constante evolución, ofreciendo nuevos productos y funcionalidades, lo que muchas veces nos lleva a cambios en la plataforma.
Por esta razón es por la que debemos diseñar nuestra plataforma pensando en el crecimiento a futuro de la misma, pero en un crecimiento sostenido, un crecimiento que venga de la mano del negocio. Nada de despilfarros. Sé realista, tu plataforma tiene que aguantar tu carga de trabajo actual, pero teniendo en mente que tienes que dejar una puerta abierta a un crecimiento fácil en caso de necesitarlo.
En esta fase es muy importante intentar que alguien del equipo de sistemas (con voz fuera de él) esté en todas las reuniones relevantes en las que se tomen decisiones sobre la infraestructura y el proyecto en general.
Hay algoritmos brillantes y modelos de negocio increíblemente rentables que han muerto de gloria por un mal diseño de la arquitectura de sistemas, incapaz de absorber toda la carga de trabajo que los usuarios demandaban.
Es posiblemente el escenario más estresante de todos. Sentirás el aliento de tus compañeros de otras áreas sobre tu nuca, esperando que des al botón y todo empiece a funcionar como por arte de magia (“informagia”).
Es importante definir junto con el equipo de desarrollo unos buenos procedimientos de puesta en producción.
Esto es solo un ejemplo y, además, bastante manual. Puedes usar herramientas de integración continua como Jenkins o herramientas de plataformado como Puppet o Ansible para automatizar todos estos procesos.
Ten en cuenta que es importante tener bien definido el procedimiento de marcha atrás en caso de que algo falle en producción y haya que volver a la última versión estable.
En este stage nos encontramos con dos grandes subáreas, que son la gestión de incidencias y la estabilización de la plataforma.
La gestión de incidencias es una de las piezas clave dentro de cualquier departamento de tecnología, ya sea para el equipo de desarrollo, el de sistemas, seguridad o microinformática.
En Transparent Edge Services abogamos por el uso de dos herramientas básicas para nosotros.
La primera es un gestor de incidencias como pueden ser Redmine, OTRS o similares. Una buena configuración de estas herramientas nos va a permitir llevar un tracking de todas las incidencias reportadas y el estado en el que se encuentran. Con un poco de trabajo adicional y unas cuantas querys sobre la base de datos, puedes conseguir ver cosas como tiempos medio de resolución de incidencias, cuántas de estas se resuelven al mes, quién es el miembro del equipo más resolutivo, etc. En definitiva, nos va a permitir medir para optimizar los procesos.
La segunda herramienta que recomendamos es usar un Kanban junto con Scrum para una correcta gestión de tareas.
Kanban te ayudará de una manera muy visual a organizar tu equipo y las tareas que está realizando cada uno de sus integrantes en ese momento, así como el estado y criticidad de las mismas.
Haz una pequeña reunión (5 minutos) todas las mañanas con todos los miembros de tu equipo para hacer un pequeño seguimiento de las tareas. No te centres aquí en resolver problemas. Si hay problemas, abórdalos en otra reunión monográfica si es necesario. Esto es lo que se conoce en el mundo scrum como la daily meeting.
Como ves en este modelo, trabajamos en sprint de una semana (aunque puedes ajustarlo a tus necesidades). También recomendamos hacer una pequeña reunión al final de cada sprint, por ejemplo, a principios de la semana siguiente (a poder ser los lunes antes de meterse en faena) con el objetivo de repasar todas las tareas realizadas la semana anterior.
Mensualmente es interesante hacer una reunión de departamento en la que se revisen los procesos internos con el afán de ir mejorándolos. En Scrum, esta reunión es conocida como retrospectiva.
Con Scrum, al igual que con todas las metodologías, somos partidarios de no aplicar todo al pie de la letra, sino de hacer uso de las herramientas en la medida que sean útiles para ayudarte en tus tareas.
Este pequeño paradigma basado en el Crear – Medir – Aprender de Lean Startup nos aproxima bastante a lo que deberíamos hacer para llevar a cabo una estabilización consistente de nuestra plataforma. Para ello vamos a poner foco en la monitorización.
Nuestra herramienta de monitorización es la base de nuestra plataforma. Sin ella estamos ciegos. Si no sabemos qué ocurre, no podremos anticiparnos a posibles problemas que puedan estar por venir. Por eso, todos los procesos relevantes de tu plataforma han de estar monitorizados y, a ser posible, graficados.
Para llevar a la práctica este paradigma, como es lógico, lo primero que haremos será configurar nuestro servicio. Después recogeremos el impacto de nuestros cambios mediante nuestra herramienta de monitorización favorita y, por último, analizaremos estos cambios para saber si es necesario volver a iterar dentro del bucle.
Compartir:
