Ahora mismo estamos en medio del proceso de búsqueda de un/a nuevo/a sysadmin para el equipo técnico y como estos procesos son bidireccionales, recibimos bastantes preguntas por parte de algunas de las personas que aplican al puesto.

Esta semana nos han preguntado nuevamente sobre cómo organizamos el trabajo del equipo técnico en STR Sistemas y me ha parecido interesante compartirlo de manera pública, tal y como haríamos en las conversaciones de pasillo de algún evento, o en una sesión del SOSZ, mi evento favorito.

Es importante destacar que ante todo priorizamos siempre el servicio de nuestros clientes y por tanto hay dos cosas que deben tener siempre a alguien dedicado a ello:

• La atención de los sistemas de monitorización/alertas y cualquier incidencia que estos puedan reportar, desde la alerta hasta la resolución pasando por el análisis necesario
• La gestión del canal de comunicación, principalmente email, habilitado para comunicarnos con los equipos y empresas con los que colaboramos día a día (usamos Help Scout para ello desde hace bastantes años)

Roles del equipo técnico

Cada persona del equipo trabaja semanalmente con un rol y para el caso anterior disponemos del rol de soporte. Éste se asigna de manera rotativa a una o varias personas, asegurando que en todo momento nuestro soporte técnico esté cubierto, es decir, vamos a enterarnos de cualquier incidencia que nuestros monitores alerten y se va a responder a los clientes en tiempos adecuados en función de la gravedad reportada.

Dado que está muy clara la prioridad del rol de soporte, las personas con dicho papel no tienen asignación de tareas con alguna de estas condiciones:

• Su ejecución sea crítica desde el punto de vista de seguridad o de servicio
• Tengan un plazo concreto de ejecución
• Requieran una concentración y dedicación de tiempo considerable como ocurre por ejemplo con las tareas que conllevan más desarrollo

Al rol de soporte también le asignamos tareas recurrentes sencillas o sin prioridad, que pueden ejecutarse con menor concentración e interrupciones.

No estamos siempre apagando fuegos, hacemos muchas más cosas como desarrollar roles de ansible, módulos de terraform o scripts, implantar nuevas plataformas, realizar upgrades, preparar migraciones, etc. Todas estas tareas las realizan los componentes del equipo con otro rol, que en un alarde de ingenio, llamamos proyectos.

Existe un tercer pseudo-rol que llamamos i+D, al que le intentamos dedicar al mes un mínimo del 50% del tiempo de una persona para probar nuevas tecnologías y desarrollar nuevos componentes de automatización o integración. A veces esto es necesidad de un proyecto y entonces es parte de las tareas del rol de proyectos, pero otras veces (aquí es donde aplica este papel realmente) es simplemente por explorar nuevas opciones con las que trabajar en el futuro. De aquí han surgido muchas de las cosas que usan nuestros clientes a diario como por ejemplo el software de despliegue de aplicaciones.

Los roles afectan directamente a los horarios de nuestro equipo. Con el rol de soporte, el horario es estricto para garantizar el servicio a los clientes. El rol de proyectos disfruta de horarios flexibles, aunque en general intentamos tener horas de coincidencia con todo el equipo durante la mañana.

Organización y planificación del trabajo

Todo los jueves realizamos una reunión semanal del equipo técnico en la que tratamos:

• Cualquier tema relevante de la semana que acaba como incidencias que se deban tener en cuenta, nuevos retos de alguna plataforma que requieran debate técnico o comentarios de un nuevo componente que hayamos desarrollado
• Estudiamos los nuevos proyectos si hay, comenzando por conocer el negocio y luego la solución técnica que vamos a implantar, gestionar y mantener
• Las tareas que queremos y acordamos planificar para ejecutar la siguiente semana

Todas estas tareas se definen en nuestro kanban (usamos JIRA de una manera muy sencilla) y el responsable de gestionar dicho kanban, asigna las tareas teniendo para ello en cuenta las siguientes condiciones:

• Asignación de roles para la semana siguiente
• Match de conocimientos vs tareas: asignar el trabajo a quién más controla del tema si es algo crítico o hay demasiada urgencia o asignarlo a alguien que no conoce mucho la tecnología en cuestión para que mejore su conocimiento y experiencia con dicha materia
• Criticidad de la tarea y compromisos de fechas sobre la misma
• Todo lo que se haya comentado sobre prioridades, preferencias, situaciones personales, viabilidad, dependencias, etc.

Desde que una tarea es asignada a alguien, esa persona es totalmente responsable de la misma. Esta responsabilidad conlleva analizar el trabajo a realizar y ejecutarlo, pero también saber cuándo pedir ayuda en el equipo, comunicarse con el cliente o incluso, parar el trabajo e informar al equipo si por alguna razón no se puede llevar a cabo tal y como estaba planteado originalmente.

El día a día de nuestros sysadmin

Con todo lo anterior, intentamos trabajar de manera planificada, pero a veces por la naturaleza de nuestro servicio, todo se va al traste y aparecen imprevistos como agujeros críticos de seguridad, ataques, incrementos no esperados de tráfico, etc. que requieren de máxima prioridad. Son situaciones que asumimos y que tratamos con los equipos de los clientes con normalidad y transparencia, ya que afecta a nuestras programaciones.

Trabajamos en remoto pero conectados a través de slack y meet cuando es necesario, usando otras herramientas asíncronas el resto del tiempo.

Además, ante incidencias o actuaciones reseñables hacemos retrospectivas (internas o conjuntamente con clientes) para analizar lo que hemos hecho bien para potenciarlo y lo que no ha tenido el resultado deseado para ver cómo podemos mejorar.

Quizás pueda parecer poco glamuroso y trivial, pero hemos tardado años en pulir esta manera de trabajar para que funcione de forma productiva. Siempre hay nuevas aportaciones del equipo a todo el modelo organizativo, así que tengo claro que dentro de unos años o quizás meses al menos parte será diferente.