Ovenbird Iniciar sesión Empieza gratis

historias · operaciones

Cuatro fallos de proceso famosos y lo único que tienen en común

Los 440 millones de dólares de Knight Capital, una caída de AWS por una errata, el accidente que inventó la lista de verificación y la lista de verificación que redujo las muertes quirúrgicas. Distintos sectores, la misma lección sobre los procedimientos documentados.

· 8 min de lectura · Equipo de Ovenbird

Los fallos de proceso llegan a las noticias cuando la cifra es lo bastante grande. Detrás de la cifra casi siempre hay un paso que estaba escrito y no se dio, o se dio en la rama equivocada. Cuatro casos públicos, contados brevemente y a partir del registro público, y el hilo que los une.

Knight Capital, 2012: un servidor de ocho

Knight Capital era un creador de mercado que gestionaba una gran parte de la negociación de renta variable en EE. UU. En agosto de 2012 desplegó un nuevo software de trading en sus servidores antes de un cambio en el mercado. El procedimiento de despliegue cubría ocho servidores. En uno de ellos no se instaló el nuevo código, y una rutina antigua, inactiva desde hacía mucho, se reactivó por un indicador reutilizado.

Cuando abrió el mercado, ese servidor empezó a enviar órdenes que nadie pretendía. En unos 45 minutos la firma acumuló posiciones que le costaron unos 440 millones de dólares y, en cuestión de días, su independencia. La resolución posterior de la SEC describió la ausencia de controles adecuados en torno al despliegue.

El paso existía. El procedimiento decía ocho servidores. El fallo fue que nada comprobó, en el momento de actuar, que el paso se hubiera completado, y nadie pudo ver a tiempo que no era así.

Amazon S3, febrero de 2017: un comando con mayor radio de impacto del previsto

El propio resumen posterior al incidente de Amazon es inusualmente sincero. Un ingeniero del equipo de S3 seguía un playbook establecido para retirar un pequeño número de servidores de un subsistema de facturación. Una de las entradas del comando se introdujo de forma incorrecta y se retiró un conjunto de servidores mucho mayor, incluidos algunos que daban soporte a subsistemas de índice críticos. S3 en la región US-East-1 estuvo prácticamente no disponible durante horas, y buena parte de internet que dependía de él cayó también.

La solución de Amazon no fue "ser más cuidadosos". Cambiaron la herramienta para que retirara capacidad más despacio y se negara a bajar un subsistema por debajo de su mínimo, y dividieron los subsistemas en celdas más pequeñas. En otras palabras: se siguió el proceso; el propio proceso carecía de una protección en el paso en el que una persona teclea un número.

Boeing, 1935: el accidente que produjo la lista de verificación

La historia está muy bien contada en The Checklist Manifesto, de Atul Gawande. En octubre de 1935 el Army Air Corps evaluó el Modelo 299 de Boeing, la aeronave que se convertiría en el B-17. En su vuelo de prueba ascendió, entró en pérdida y se estrelló, y murieron dos de los cinco tripulantes, entre ellos el piloto, uno de los más experimentados del Ejército. La causa fue un mando del timón de profundidad bloqueado que nadie había liberado antes del despegue.

No se juzgó que la aeronave fuera demasiado peligrosa para volar; se juzgó demasiado compleja para que una sola persona la tuviera en la cabeza. Un grupo de pilotos elaboró una lista de verificación breve, paso a paso, para el despegue, el vuelo, el aterrizaje y el rodaje. El B-17 llegó a volar un enorme número de horas sin un accidente grave atribuible a un error de piloto de ese tipo, y la lista de verificación pasó a formar parte de la aviación.

El paso —liberar el bloqueo del timón de profundidad— lo conocía todo piloto. Lo omitió uno de los mejores. La experiencia no protege contra el paso que es fácil olvidar; un aviso visible, en el momento, sí.

La lista de verificación de seguridad quirúrgica de la WHO, 2008: el caso de éxito

El propio experimento de Gawande. Una lista de 19 puntos, usada en tres momentos de una operación (antes de la anestesia, antes de la incisión, antes de que el paciente salga del quirófano), probada en ocho hospitales de países ricos y pobres. El resultado publicado: las complicaciones graves bajaron alrededor de un tercio y las muertes casi a la mitad en el conjunto de los centros. Nada de lo que figuraba en la lista era desconocido para los equipos quirúrgicos. Confirmar la identidad del paciente, comprobar que se administró el antibiótico, contar las gasas: todo documentado, todo "obvio", todo omitido con la frecuencia suficiente como para matar gente.

Lo que lo hizo funcionar no fue la lista. Fue que la lista se leía en voz alta, en el momento, por una persona designada, y que se esperaba que todos los miembros del equipo dijeran algo si veían un fallo. El cumplimiento se volvió visible dentro del quirófano.

Lo que tienen en común

Los equipos de soporte e ingeniería no estrellan aviones, pero ejecutan a diario la misma forma de proceso: documentado, con ramas, dependiente de datos sobre el elemento e invisible cuando se omite. Las soluciones también tienen la misma forma: llevar el paso al trabajo, pedir el dato antes de actuar y hacer visible el cumplimiento para que el documento pueda mejorar. Eso es lo que significa guía de procesos en la práctica.

Fuentes: orden de la SEC contra Knight Capital Americas LLC (2013); "Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region", de Amazon (2017); Atul Gawande, The Checklist Manifesto (2009); Haynes et al., "A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population", NEJM (2009).

Empieza gratis · 14 días, sin tarjetaReserva una demo

← Todos los artículos