Friday, October 10, 2014

Los números que todos deberíamos conocer

Nada resume mejor la filosofía para diseñar sistemas dentro de Google que los números que todo ingeniero de software debe conocer. Ahí tenemos los tiempos de respuesta de la mayoría de operaciones fundamentales que podemos realizar en un ordenador.

Con esos números podemos diseñar una página web rápida. Si algo va lento entendemos el por qué y en la mayoría de los casos lo podemos solucionar.

Menos conocido es otro documento donde se publican el tiempo de vida de todos los componentes de un centro de datos. Cuanto tarda de media un disco duro en romperse, cuanto tarda una tarjeta de red, cuantos segundos de caída al año son debidos a un problema con un router, cuantos de forma prevista y cuantos de forma imprevista, cuantos son debidos a un problema de suministro eléctrico, etc.

Con esos números en mano, podemos diseñar sistemas robustos. Si estamos sirviendo imágenes sabemos que no podemos guardarlas todas en un solo disco duro, porque si tienes muchos discos duros esas probabilidades de error teóricas se convierten en perdida de fotos de forma rutinaria. Necesitas guardar una copia en otro disco. Si tu disco principal se rompe, necesitas hacer una copia del secundario en otro disco y tirar el original. Pero mientras haces la copia, ¿qué disco sirve las fotos que se estén viendo en ese momento? Desgraciadamente necesitas tener preparadas dos copias distintas de cada foto para no perder fotos y no dejar de servirlas en caso de problema con un disco duro.

Cuando diseñas un sistema tienes que tener en cuenta que tu disco duro se puede romper, que tu ordenador se puede romper, que tu router se puede romper, que pueden configurar mal el enrutado a tu servidor, que se puede cortar la electricidad, que tu rack se puede incendiar, etc.

Desde el punto de vista del sysops / devops / SRE (o ingeniero de sistemas) eso significa que tienes que estar listo para que en cualquier momento tengas que cambiar de servidor o incluso de centro de datos, y eso con un tiempo de caída nulo, o el mínimo aceptable por tus usuarios.

¿Por qué no se hacen esos sistemas más robustos?

El primer motivo es porque esas capas extra de seguridad que se añaden para que un sistema aguante cuando hay un problema en una de las capas no son independientes entre sí.

Por ejemplo, recuerdo que un día un centro de datos se quedó sin electricidad. Todos los centros de datos contaban con un suministro de electricidad secundario usando motores diesel. ¿Cómo podía haber fallado la electricidad general y el suministro de emergencia al mismo tiempo? La electricidad había fallado porque era invierno y había una gran demanda, acrecentada por el alto precio de la gasolina aquel invierno. Cuando encendieron los motores diesel se apagaron a los pocos segundos, sencillamente porque no había gasolina en los tanques. La habían robado. El alto precio de la gasolina había provocado un error en dos sistemas que se habían considerado teóricamente independientes.

En ese caso la solución era sencilla, se introdujo dentro del protocolo de mantenimiento de los centros de datos una revisión y puesta en marcha rutinaria de los motores diesel.

Otra vez perdimos completamente la conectividad a un centro de datos entero. Era algo raro, porque el centro estaba conectado con dos cables de fibra óptica distintos, para que si se producía un problema en uno de ellos el otro aguantase todo el tráfico. El motivo fue que en primavera los cazadores de la zona se distraían disparándole a los cables, y claro, a los pocos minutos de acertar con el primero acertaron con el segundo.

Aquí la solución fue intentar que uno de los cables fuese soterrado, pero tenía un alto sobrecoste.

Como os podéis imaginar es necesaria mucha experiencia práctica para conocer los tipos de errores que se suelen producir, y una vez se conocen esos errores hay que tener cuidado para diseñar un sistema que resista a esos errores.

Tenemos otro ejemplo dramático estos días con el contagio de ébola de una enfermera del Hospital Carlos III. El que diseñó el protocolo para tratar a los pacientes de ébola tienen que preveer que los que tratan a un enfermo de ébola no deben de tocar su piel ni sus fluidos, si lo hacen la probabilidad de contagio es de cerca del 100%. Si les ponen un traje que impida el contacto directo, tienen que preveer que el traje no va a transpirar, va a dar calor y que hay una alta probabilidad de que alguien se toque al quitárselo. Si se desinfecta el traje en una sala intermedia antes de salir baja aún más esa probabilidad. Si se ponen desinfectantes en la sala donde está el paciente para que los auxiliares puedan limpiar todas las zonas del traje en contacto con el paciente mientras le atienden, aún baja más esa probabilidad. Si al salir un compañero va desinfectando todas las partes del traje que te quitas antes de que te las quites aún mejor. Puede ser que hayas tocado algo sin darte cuenta y no lo limpiases inmediatamente en la habitación, lo que es normal con un traje voluminoso, y que tampoco se haya limpiado correctamente en la habitación intermedia por ejemplo porque quedó en algún pliegue que no había sido bien rociado. Para terminar, que otra persona te vaya ordenando que te quites el traje parte a parte siguiendo un orden establecido. La cara debería ser la última en quedar al descubierto ya que es la parte del cuerpo más crítica (por donde puede entrar el virus). Las manos debería ser la penúltima, ya que nos las llevamos muy a menudo a la cara. Antes de liberar la cabeza volver a desinfectar las manos.

Con un protocolo así un error humano no sería equivalente a una infección. El protocolo no es infalible, todo el mundo debe seguirlo rigurosamente para que sirva de algo, y cuando alguien lleva meses haciendo algo sin ninguna consecuencia negativa acaba relajando las medidas de seguridad. Hay que ir rotando al personal para que tengan destreza pero sin perderle el respeto a la enfermedad.

Todos los que critican el error humano que ha llevado a esta infección no son capaces ni de diseñar ni de criticar un protocolo.

7 comments:

SQIAR LTD said...

Hello, I love reading through your blog, I wanted to leave a little comment to support you and wish you a good continuation. Wish you best of luck for all your best efforts.
Tableau Guru
http://www.sqiar.com/services/tableau-software-consultants/

Michael SMITH said...

It’s a new kind of time tracking tool that allows you to look back into time.
http://www.massmail4u.com/

John James said...

And while we’re at it, why not talk about a free (as in free beer, but also as in freedom) entire operating system: GNU/Linux?
http://www.mindtechworld.com/

John James said...

For email marketing, if you’re computer-savvy, or know someone who is, I’d recommend PHPList. It’s an online application, installed in your server, really powerful for managing email marketing campaigns.
http://www.mindtechworld.com/

Ethan MOORE said...

For time tracking you can also use Premember Light .
http://www.bulkmailservers.net/

dedicated hosting said...


Thanks for all of these amazing resources! 

Daniel Joseph said...


For time tracking you can also use Premember Light .