Sorteo en el departamento de IT

Con la escusa de que habíamos acumulado algo de merchandising de los distintos eventos en los que hemos participado, decidimos hacer un pequeño sorteo dentro del departamento de IT para ver quién se quedaba cada cosa. Cómo no, el sorteo no podía ser por los medios tradicionales, lease papelitos o piedra-papel-tijera, así que me aventuré a tirar unas líneas de python que resolvieran el problema de forma sencilla, aunque como veréis luego decidimos complicarlo un pelín más. El sorteo lo proyectamos en la tele que tenemos para la monitorización justo al lado del departamento:

La primera versión del código era realmente sencilla y muestra lo fácil que es hacer algo con python, simplemente declara un array de personas y otro de regalos, recorre los regalos y va eligiendo una persona de forma aleatoria como ganador de cada regalo y eliminando esa persona del array de personas:

sorteo-simple.py (Pincha sobre el enlace para ver o descargar el código)

Pero así quedaba un poco simplón por lo que añadí alguna opción más para hacerlo más interesante. La idea es que había gente que sólo estaba interesada en algunos regalos y tenía su orden de preferencia, así que modifiqué el código para que las tuviera en cuenta en caso de que te tocara un regalo a modo de Wish List:

sorteo-wish-list.py (Pincha sobre el enlace para ver o descargar el código)

Y por supuesto el código fue enviado a todos los participantes para que lo auditaran antes de su ejecución con el consiguiente debate de cómo se podría hacer mejor… además en el correo me colé y puse para vuestra audición y alguno quería ponerlo con el festival. Y claro, así no hay forma de hacer trampa, con lo que finalmente no me tocó ningún regalo cómo podéis ver si pincháis sobre la imagen de la tele, pero al menos me queda esta entrada del blog cómo recuerdo.

Charla: Gestionando nuestros servidores con Puppet

Otro semestre más vuelven los cursos del Gul de la Universidad Carlos III de Madrid que durante la semana próxima, del 08 al 14 de Noviembre, tratarán de temas tan interesantes cómo Git, tunning de Mysql, Android o ITIL. Yo me apunto de nuevo a dar una charla y esta vez será sobre Puppet y cómo puede cambiar radicalmente la concepción de la gestión de nuestros servidores ofreciendonos grandes ventajas en la automatización, gestión de configuración y la reutilización.

Mi charla será el Martes 09 de Noviembre a las 18:00 en el aula 4.0.E02 en el Campus de Leganés de la Carlos III, así que si os interesa el tema nos vemos por allí.

ACTUALIZACIÓN: Ya tenéis un resumen y las transparencias de la charla disponibles en el blog.

Recuperación de desastres, algunas notas entre las llamas

¿Cuál es la probabilidad de que algo que es realmente muy improbable pase? No importa, porque por la ley del gafe terminará pasándote, así que aparte de intentar reducir la posibilidad de que esto pase el otro punto importante es estar preparado para cuando eso pase. Aquí va la historia:

Las dos semanas pasadas en el curro nos ha tocado a todo el equipo de IT ponernos el mono de bombero y apagar el incendio que provoca esa pequeña chispa tan realmente improbable. ¿Qué fue esta vez? Un fallo en los discos de la cabina central de almacenamiento, dónde tenemos la mayor parte de máquinas virtuales que son, cada día más, el centro de las operaciones de la compañía, decidieron romperse de forma coordinada. Los discos están en RAID 5 y disponemos de 3 discos de spare, discos listos para sustituir de forma automática a otro en caso de rotura, pero ¿qué pasa si cuando un disco ha fallado y está entrando uno de los de reserva y otro decide pasar también a mejor vida? El RAID ya no se puede reconstruir y en nuestro caso hay que tirar de backup. Lo siguiente ya os lo podéis imaginar, muchas horas sin dormir, carreras por los pasillos, gente preguntando cuando estará todo listo de nuevo y desesperación. Chicos, estamos en DEFCON 1.

Y aquí es dónde se debería sacar el libro «rojo» del armario, el famoso plan de recuperación ante desastres, y todo debería ser coser y cantar. Pero ante la inexistencia de ese libro con el plan maestro, aquí van algunos consejos que me doy a mi mismo para la próxima vez que tenga que afrontar un fuego:

Mantén la calma, hay que pensar con la cabeza fría y no actuar atropelladamente, ya que podemos agravar el problema por no pensar bien en las alternativas.

Gestiona eficientemente la comunicación, especialmente la que Lili califica cómo comunicación en crisis como es esta, y las distintas fases en las que te encontrarás durante la recuperación: la sorpresa inicial, el fastidio de que todo no esté para ya, la sombra de las dudas y demás reacciones a favor y en contra. Yo en esta parte soy partidario de la transparencia y de intentar mantener al día a todos los implicados de cuál es la evolución de nuestro paciente, pero también hay que saber soportar el chaparrón de la mejor manera.

Prioriza la recuperación, planificar la restauración del servicio y los datos estableciendo un sistema de prioridades hará más efectiva la recuperación, ¿qué servicios son más críticos para el negocio?

Toma notas para el futuro, soy un gran defensor de la mejora continua, y cuando hemos llegado a una situación de desastre es un gran momento para analizar que ha podido fallar y cómo podríamos evitarlo en futuras ocasiones. Además tienes viento a favor por parte de dirección para acometer cambios y mejoras, así que hay que aprovechar la ocasión. En resumidas cuentas, como mínimo, ¿habrá libro rojo la próxima vez?

Hay mucho por hacer de ahora en adelante, pero ahora mismo sólo querría destacar el gran trabajo de todo mi equipo, ha sido increíble luchar con las llamas con vosotros y os doy las gracias porque sin vosotros y vuestra dedicación todo habría sido mucho más complicado. También gracias a todos los afectados por el problema, porque habéis sido muy comprensivos. Ahora a planificar el futuro.

Madrid devops

El tema de los devops es uno de los que más me han llamado la atención últimamente, me ahorro la definición formal ya que la de la wikipedia es bastante buena y sobre todo los enlaces que propone son un punto muy bueno para empezar. Creo que sin darme cuenta una gran parte de mi trabajo en Andago en los pasados años ha ido en esa dirección y eso que siempre había tratado de mantenerme un tanto a parte de las fases más puras del desarrollo. Esto fundamentalmente se debe a que comparto muchos de los intereses que caracterizan al movimiento de los devops: uso de metodologías ágiles, integración y entrega continua, búsqueda de la automatización en los procesos de configuración y despliegue de servicios, virtualización e IaaS, etc… Por mi parte no comparto la opinión del compañero @nubeblog de que el nacimiento del devop sea la muerte del administrador tradicional, pero sí una posición a tener en cuenta en los esquemas de operaciones de las compañías.

Y ¿qué tiene todo esto que ver con Madrid?, os preguntaréis, bueno pues el otro día tuve el gran placer recibir la invitación vía twitter del compañero @therobot, al que conocí en el FOSDEM y con el que estuve charlando sobre Chef, que estaba organizando un grupo de devops en Madrid. Por ahora nos estamos coordinando a través del grupo de Google Madrid devops, al que invito a unirse a todo el mundo que esté interesado. Además hemos planificado la primera reunión/quedada, por ahora no habrá charlas ni nada, sólo cervecitas y conocernos, el Miercoles 13 de Octubre a las 20:00 en el bar casa Camuñas. ¿Alguien se apunta?