Innovación con sistemas críticos para la vida

Cada empresa tiene una infraestructura "crítica". En general, esto significa que si el sistema se desconecta, partes (o la totalidad) del negocio se detendrán hasta que los técnicos puedan volver a ponerlo en funcionamiento. Esto suele ocurrir cuando se requieren grandes actualizaciones de software, hardware o red: los sistemas recién implementados contienen errores inesperados que provocan una falla del sistema, o los usuarios cometen errores con el nuevo sistema porque no están familiarizados con él, y la productividad se detiene hasta que los técnicos pueden solucionar los errores de implementación o capacitar a los usuarios. En su mayor parte, un período de tiempo de inactividad o reducción de la productividad es un riesgo aceptable a cambio de la promesa de un mejor rendimiento y eficiencia de la nueva tecnología, pero eso no es universal. La mayoría de las empresas pueden permitirse una cierta cantidad de tiempo de inactividad sin arriesgar muchos ingresos o antagonizar a sus clientes.

Pero, ¿qué sucede cuando los sistemas que necesita modificar son sistemas críticos para la vida, donde la seguridad de la vida depende de poder usar el sistema de manera confiable?

Este artículo se aleja del desarrollo de software más tradicional en el que pasamos la mayor parte de nuestro tiempo y, en cambio, analiza el elemento humano en los sistemas críticos para la vida. Mis pensamientos sobre este tema provienen de mi experiencia como Director de Tecnología de la Información para un servicio de ambulancia 911, como especialista en tecnología para una organización internacional de respuesta humanitaria a desastres y con mi Ph.D. en Integración de Sistemas Humanos completado en el Instituto de Tecnología de Massachusetts.

Antes de comenzar, me gustaría explicar por qué esto puede ser relevante para usted. Si bien puede no ser obvio que su proyecto en realidad involucra un sistema crítico para la vida, es mucho más probable de lo que piensa. Todo lo siguiente califica, así como innumerables temas más:

• Automotor. ¿Está trabajando en un proyecto con un fabricante de vehículos o alguno de sus proveedores? ¿Reclutado fuera de la universidad por una startup de autos sin conductor? Frenado automático, control de crucero, control de carril, visión por computadora, reconocimiento de obstáculos, módulos de control electrónico del motor, etc. Cada uno de estos es un sistema crítico para la vida, donde una falla puede ser fatal.
• Aviación. Cuando estás a 30 000 pies en el aire, casi cualquier falla del sistema puede ser crítica para tu vida. Teniendo en cuenta los eventos recientes con el Boeing 737 MAX, existen los sistemas obvios y críticos para la vida del piloto automático y el control de vuelo computarizado, pero también hay muchas cosas en las que quizás no pienses. En casa, si el ventilador de su sistema HVAC falla y produce un poco de humo, abre la ventana o sale a tomar aire fresco. ¿Alguna vez ha intentado abrir la ventana y salir durante un vuelo transatlántico? Incluso los sistemas más básicos, desde los tomacorrientes en la cocina hasta los frenos en las ruedas del carrito de bebidas, pueden ser críticos para la vida en los aviones.
• Comunicaciones. La mayoría de los desarrolladores o ingenieros, en algún momento de sus carreras, trabajarán en un proyecto de sistema de comunicaciones en una capacidad u otra. Para muchas personas, las telecomunicaciones inicialmente no parecen críticas para la vida; después de todo, a la civilización le fue bien antes de los teléfonos e Internet. Como alguien que se ha desplazado a zonas de desastre donde la infraestructura de telecomunicaciones ha sido destruida, déjame decirte lo que realmente sucede: las personas se enferman o lesionan gravemente y no pueden llamar al 911; los residentes mayores no pueden llamar a sus hijos para pedirles que recojan sus recetas en la farmacia; los servicios de emergencia no pueden comunicarse con sus despachadores ni entre ellos; y las personas que no pueden contactar a sus familiares se preocupan y se ponen en situaciones extremadamente peligrosas para tratar de encontrarlos. Los sistemas de comunicaciones son absolutamente críticos para la vida.

En el mundo actual de gran dependencia de la tecnología, los proyectos que nunca consideró ni siquiera semiimportantes podrían terminar siendo un componente vital de un sistema crítico para la vida.

Pero si no está roto, no lo arregles

¿Alguna vez ha escuchado o utilizado la palabra “patrimonio” en relación con un sistema tecnológico? Es una palabra fuerte, que invoca pensamientos de antiguas tradiciones, linaje y tiempos difíciles de antaño. En el mundo de la ingeniería, se usa para denotar diseños que han existido durante mucho tiempo y se ha demostrado que funcionan de manera confiable y, a menudo, se considera un rasgo deseable para reducir el riesgo. En realidad, es un eufemismo para la tecnología arcaica que nunca se actualizó debido a la aversión al riesgo, y es omnipresente en las industrias donde las fallas del sistema pueden tener consecuencias nefastas.

Hay una buena razón detrás de esta afinidad con el software y el hardware heredados. Se sabe que funciona, es poco probable que surjan errores desconocidos y sus costos son estables y predecibles. Un excelente ejemplo es la industria de los vuelos espaciales: la nave espacial rusa Soyuz ha estado lanzando astronautas al espacio durante más de 50 años con solo revisiones menores durante ese tiempo, y continúa usándose porque es confiable y segura. Desafortunadamente, esto significa que también es extremadamente ineficiente en comparación con los diseños modernos: mientras que Soyuz le cuesta a la NASA $ 81 millones de dólares por asiento para llevar a los astronautas a la estación espacial utilizando su hardware heredado, se espera que SpaceX y Boeing ofrezcan asientos por $ 58 millones de dólares cada uno. utilizando sus modernos diseños de cohetes.

Es comprensible que pocas personas quieran actualizar los sistemas antiguos que aún funcionan; los ejecutivos no quieren correr riesgos, los técnicos no quieren lidiar con el servidor misterioso en el armario con un tiempo de actividad de 12 años y los clientes no quieren tener que aprender nuevos diseños. Desafortunadamente, hay un punto de inflexión entre la minimización de riesgos y el ahorro de costos: eventualmente, los diseños heredados deberán actualizarse, incluso en entornos de alto riesgo .

El resto de este artículo cubre algunos de los pasos más importantes en el proceso de hacerlo cuando sus sistemas son vitales, como los que utilizan los socorristas, las unidades militares o las aeronaves.

Convenciendo al latón

Según mi experiencia, posiblemente el paso más difícil del proceso es convencer a los responsables de la toma de decisiones y a las partes interesadas de que se necesitan actualizaciones. Los sistemas que operan en entornos críticos para la vida a menudo se rigen por una amplia regulación legal y una política de organización, lo que significa que debe convencerlos de que no solo deben correr el riesgo y gastar el dinero, sino que también deben participar en lo que fácilmente podrían ser varios. años de corte de cinta burocrático. La oposición más fuerte a la que se enfrentará probablemente será la del equipo legal, que expondrá con gran detalle la responsabilidad potencial a la que se expondrá la organización al introducir nueva tecnología. Tienen razón: la responsabilidad es un problema importante , y si algo se rompe y alguien resulta herido o muere, podría ser una enorme carga ética, reputacional y financiera.

Independientemente de si está trabajando con una corporación Fortune 500 o con su departamento local de bomberos voluntarios, siempre se trata de lo mismo: dinero. Las corporaciones no quieren perderlo y, en primer lugar, las organizaciones sin fines de lucro no tienen mucho con lo que trabajar. La única forma confiable que he encontrado para convencer al liderazgo de una organización de que se arriesgue a cambiar un sistema crítico para la vida es demostrar que, de manera probabilística, es más probable que ganen/ahorren dinero que lo pierdan, o que pueden reducir su responsabilidad mediante la modernización de su tecnología y la mejora de la seguridad.

Lo que eso significa es que necesitas hacer los cálculos. ¿Cuál es la probabilidad de que haya un tiempo de inactividad prolongado o fallas futuras debido a errores (según implementaciones anteriores en su organización o datos de otras organizaciones)? ¿Cuál es el impacto esperado si falla y cuánto costaría? Por el contrario, ¿cuáles son las ganancias esperadas de rendimiento o confiabilidad, y cuánto valdrían? Si puede demostrar que hay una alta probabilidad de salir adelante, es muy probable que obtenga luz verde.

No es sobre ti

Es posible que esté familiarizado con la frase "por ingenieros, para ingenieros", un modismo que sugiere que los ingenieros construyeron algo para que lo usaran personas con calificaciones similares a las suyas. Es un hecho extremadamente común y fue uno de los principales factores desencadenantes del auge de los estudios de usabilidad informática a principios de la década de 1990. Como ingenieros, a menudo tenemos diferentes modelos mentales de cómo funcionan los sistemas tecnológicos que el usuario final promedio, lo que lleva a una tendencia a diseñar sistemas con la suposición de que el usuario final ya sabe cómo funciona. En los sistemas convencionales, esto conduce a errores y clientes insatisfechos; en sistemas críticos para la vida, puede conducir a la muerte.

Considere el caso del vuelo 447 de Air France. El 1 de junio de 2009, el Airbus A330 estaba sobre el Océano Atlántico en ruta de Río de Janeiro a París. Los cristales de hielo obstruyeron los tubos de Pitot, provocando inconsistencias en las mediciones de la velocidad del aire. La computadora de vuelo desconectó el piloto automático, reconociendo que no podía volar el avión de manera confiable con datos de velocidad del aire incorrectos. Luego se colocó en un modo de "sobre de vuelo extendido" , lo que permitió a los pilotos realizar maniobras que la computadora normalmente no permitiría. Puede imaginarse a los ingenieros que construyeron el sistema pensando “si el piloto automático se desactiva, probablemente se deba a que hay una situación en la que los pilotos pueden necesitar control adicional. ”

Este es el tren de pensamiento natural para los ingenieros, que entienden qué tipo de cosas pueden hacer que el piloto automático se desconecte. Para los pilotos, no fue el caso. Obligaron a la aeronave a emprender un ascenso empinado, ignorando las advertencias de "BLOQUEO", hasta que perdió toda la velocidad aerodinámica y cayó en picado al océano. Los 228 pasajeros y la tripulación murieron. Si bien existen múltiples ideas en cuanto a la motivación exacta de sus acciones, la teoría predominante es que los pilotos asumieron que la computadora de vuelo evitaría las entradas de control que provocarían la entrada en pérdida de la aeronave (lo cual es cierto para la envolvente de vuelo normal), y no se dieron cuenta de que había cambiado al modo de sobre extendido porque no compartían el modelo mental de los ingenieros de la lógica que impulsaba las decisiones de la computadora.

Si bien es una ruta un poco tortuosa, esto nos lleva a mi punto principal: las acciones que desea que los usuarios realicen en condiciones específicas deben ser acciones que se sientan naturales para el usuario .

Se puede instruir a los usuarios para que sigan procedimientos específicos, pero simplemente no siempre recordarán lo que deben hacer o comprenderán lo que sucede en condiciones de alto estrés. Es su responsabilidad diseñar software, controles e interfaces de una manera intuitiva que haga que los usuarios quieran hacer las cosas que se supone que deben hacer.

Lo que esto significa es que es absolutamente crítico que los usuarios finales participen en cada etapa del proceso de diseño y desarrollo. No se pueden hacer suposiciones sobre lo que probablemente harán los usuarios; todo debe estar basado en evidencia. Cuando diseñe interfaces, debe realizar estudios para determinar los patrones de pensamiento que inducen en los usuarios y ajustarlos según sea necesario. Cuando pruebe sus nuevos sistemas, debe probarlos con usuarios reales en entornos reales bajo condiciones realistas. Y desafortunadamente, cuando modifica sus diseños, debe realizar estos pasos nuevamente.

Aunque cada sistema complejo es único, me gustaría mencionar tres consideraciones de diseño, en particular, que deberían aplicarse universalmente:

• Los controles deben ser representativos de las acciones que invocan. Afortunadamente, este es bastante común, generalmente visto en la forma de seleccionar íconos relevantes para botones GUI o formas relevantes para controles físicos. Los botones de "Nuevo archivo" usan un icono de hoja de papel en blanco, y las palancas del tren de aterrizaje en los aviones tienen una perilla en forma de rueda. Sin embargo, es fácil volverse complaciente. ¿Por qué todavía vemos iconos de disquetes de 3,5" para los botones "Guardar"? ¿Alguien menor de 25 años sabe lo que es un disquete? Continuamos usándolo porque creemos que es representativo, pero en realidad ya no lo es. Requiere un esfuerzo constante para garantizar que las representaciones de los controles sean significativas para los usuarios, pero también es necesario y difícil equilibrar eso con la continuidad.
• Si un sistema de alerta se rompe, debe ser detectable. A menudo usamos luces de advertencia que se activan cuando hay un problema, como un indicador rojo intermitente. Es excelente para llamar la atención del usuario, pero ¿qué sucede si la luz se funde? La nave espacial utilizada en las misiones lunares Apolo tenía decenas de luces de advertencia para todo tipo de sistemas, pero no funcionaban de manera convencional. En vez de encenderse cuando había algún problema, permanecían encendidos cuando todo iba bien y se apagaban cuando había algún problema. Esto aseguró que una luz de advertencia quemada no haría que los astronautas no perdieran un error del sistema potencialmente fatal. No estoy diciendo que deba usar este diseño, ya que las bombillas de luz han avanzado mucho en confiabilidad desde la década de 1960, pero da una idea de cuán profunda debe ser parte de su planificación. ¿Cuántas veces se ha bloqueado un sistema sin que usted lo supiera porque el registro o las notificaciones no funcionaban correctamente?
• Las transiciones de modo deben ser obvias para el usuario. ¿Qué sucede si un Airbus A330 pasa del modo de control normal al modo de control avanzado sin que el usuario se dé cuenta y, de repente, la aeronave hace cosas que el usuario no creía que pudiera hacer? ¿Qué sucede si un automóvil autónomo desactiva su piloto automático, dejando al usuario inesperadamente con el control total? ¿Qué sucede cuando hay una transición importante en el modo o la funcionalidad que requiere un cambio inmediato en las acciones del usuario, pero el usuario tarda uno o dos minutos en darse cuenta de lo que acaba de suceder? Si bien una variedad de modos operativos pueden ser necesarios en un sistema complejo, los modos no pueden cambiar sin un aviso, explicación e interacción adecuados con el usuario al hacerlo.

Sacar del taller los sistemas críticos para la vida

De acuerdo con las mejores prácticas de la industria, una fase beta es crucial para las implementaciones de nuevos sistemas críticos para la vida. Las pruebas de su nueva tecnología pueden haberlo ayudado a corregir la mayoría de los errores y problemas de usabilidad, pero pueden surgir peligros ocultos cuando tiene que usarse junto con otros sistemas en entornos del mundo real. En la disciplina de ingeniería de sistemas, esto se conoce como "emergencia". Las propiedades emergentes son "comportamientos inesperados que surgen de la interacción entre los componentes de una aplicación y su entorno" y, por su propia naturaleza, son esencialmente imposibles de detectar en un entorno de laboratorio. Al invitar a un grupo representativo de usuarios finales a probar su nuevo sistema bajo una cuidadosa supervisión, muchas de estas propiedades pueden detectarse y evaluarse en busca de consecuencias negativas que pueden aparecer en una implementación a gran escala.

Otro tema que surge a menudo en las discusiones de arquitectura con mis clientes es el de una implementación por etapas. Esta es la elección entre reemplazar gradualmente elementos de un sistema preexistente con elementos de uno nuevo hasta que finalmente se reemplace todo o cambiar todo a la vez. Hay ventajas y desventajas para cada uno: una implementación por etapas permite la aclimatación gradual de los usuarios al nuevo diseño, lo que garantiza que los cambios se produzcan en cantidades manejables y que los usuarios no se sientan abrumados; por otro lado, puede prolongar el proceso durante períodos prolongados y dar como resultado un estado de transición constante. Los lanzamientos inmediatos son beneficiosos porque "arrancan la curita" y aceleran las cosas, pero los cambios repentinos y drásticos pueden abrumar a los usuarios.

Para los sistemas críticos para la vida, descubrí que las implementaciones por etapas son generalmente más seguras, ya que permiten la evaluación incremental de componentes individuales en un entorno de producción y permiten reversiones más pequeñas si es necesario revertir algo. Sin embargo, esto es algo que debe evaluarse caso por caso.

Normalización de la Desviación

De acuerdo, sus pruebas de usuario lo ayudaron a diseñar un sistema intuitivo, su fase beta identificó problemas emergentes, su implementación por etapas permitió que los usuarios se sintieran cómodos con el diseño y todo funciona sin problemas. Ya terminaste, ¿verdad? Lamentablemente no.

Inevitablemente surgirán problemas con su sistema, no hay forma de evitarlo. Cuando los usuarios se encuentran con estos problemas, a menudo desarrollan soluciones alternativas en lugar de informar el problema al equipo técnico. Las soluciones alternativas se convertirán en una práctica estándar, compartida como "consejos" de veteranos a novatos. La socióloga Diane Vaughan acuñó una frase para describir este fenómeno: “normalización de la desviación”. Los usuarios se acostumbran tanto al comportamiento desviado que no recuerdan que, de hecho, es desviado.

El ejemplo clásico es el transbordador espacial Challenger: se observó regularmente que un componente de los propulsores de cohetes sólidos se erosionaba durante el lanzamiento y, aunque todos sabían que la erosión de los componentes de los cohetes era algo malo, sucedía con tanta frecuencia que se emitían exenciones con regularidad y se consideraba normal. El 28 de enero de 1986, el problema que todos sabían originalmente que no se debía permitir, pero que se habían normalizado, resultó en la explosión del Challenger y la muerte de siete astronautas.

Como administrador de un sistema crítico para la vida, depende de usted evitar que sucedan tales sucesos. Estudia cómo interactúan tus usuarios con el sistema. Obsérvelos durante un par de días y vea si están usando soluciones inesperadas. Envíe periódicamente encuestas para solicitar cambios y mejoras sugeridas. Dedique tiempo y esfuerzo a mejorar su sistema antes de que sus usuarios encuentren formas de solucionar los problemas sin usted.

Entrenamiento para el desempeño bajo presión

A menudo ocurre que fallas en los sistemas críticos para la vida ocurren cuando los usuarios sufren estrés, oleadas de adrenalina y visión de túnel. Les sucedió a los pilotos de Air France 447, les sucedió a los paramédicos que no pueden recordar cómo operar su monitor cardíaco en su primer paciente con paro cardíaco, y les sucedió a los soldados que no pueden operar sus radios correctamente mientras están bajo fuego.

Parte de este riesgo se reduce mediante el uso de diseños intuitivos, como se mencionó anteriormente, pero eso por sí solo es insuficiente. Particularmente en entornos donde ocurren escenarios de alto estrés pero ocurren con poca frecuencia, es esencial capacitar a sus usuarios no solo sobre cómo operar su sistema, sino también sobre cómo pensar con claridad en tales condiciones. Si los usuarios memorizan acciones relacionadas con el funcionamiento del equipo, no pueden lidiar con fallas inesperadas porque las acciones que aprendieron ya no son apropiadas; si se entrenan para pensar de manera lógica y clara bajo estrés, pueden responder a las circunstancias cambiantes y ayudar a que su sistema se mantenga vivo cuando algo se rompe.

Conclusión

Obviamente, desarrollar, implementar y mantener software crítico para la vida es mucho más complejo de lo que se puede detallar en un solo artículo. Sin embargo, estas áreas de consideración pueden ayudarlo a tener una mejor idea de qué esperar cuando esté pensando en trabajar en un proyecto de este tipo. En resumen:

• La innovación es necesaria, incluso cuando todo funciona sin problemas
• Es difícil convencer a los ejecutivos de que el riesgo vale la pena, pero los números no mienten
• Los usuarios finales deben participar en cada paso del proceso
• Pruebe y vuelva a probar con usuarios reales en entornos reales en condiciones realistas
• No asuma que lo hizo bien la primera vez; a pesar de que funciona, es posible que haya problemas no detectados de los que los usuarios no le estén informando.
• Capacite a sus usuarios no solo sobre cómo usar el sistema, sino también sobre cómo pensar con claridad y adaptarse bajo estrés.

Para terminar, me gustaría señalar que en los sistemas críticos de seguridad complejos, las cosas saldrán mal en algún momento sin importar cuánta planificación, prueba y mantenimiento haga. Cuando esos sistemas son críticos para la vida, es muy posible que una falla provoque la pérdida de la vida o de una extremidad.

En el caso de que ocurra una tragedia de este tipo con algo de lo que eres responsable, será un peso aplastante sobre tu conciencia y probablemente pensarás que podrías haberlo evitado si hubieras prestado más atención o trabajado más duro. Tal vez eso sea cierto, tal vez no lo sea, pero es imposible prever cada posible ocurrencia.

Trabaja meticulosamente, no seas arrogante y estarás haciendo del mundo un lugar mejor.