Cuando era más joven participé en varias expediciones de escalada y montañismo. Estuve expuesto a algunos instructores y practicantes que se tomaron muy en serio la seguridad en las montañas. Uno de ellos llevaba un libro del American Alpine Club sobre accidentes de escalada. Los accidentes nunca fueron la causa de una sola mala elección. Fueron causados por una serie de decisiones, tomadas a lo largo del tiempo, que se combinaron para crear las condiciones para el accidente. Lo que quedó grabado en mi memoria, sentado junto a las paredes rocosas que muy bien podrían ser el escenario de una de las historias, fue que en ciertos casos podríamos tomar una de las mismas decisiones. Que dada una hora diferente del día, un clima diferente o diferentes compañeros de escalada, la misma elección podría tener diferentes niveles de riesgo. Leer y discutir esas historias me hizo un aventurero más consciente y un escalador más seguro. El análisis público y la discusión de la cadena de decisiones y eventos que llevaron a los accidentes ayuda a los principiantes a adquirir experiencia, a los expertos a adquirir sabiduría y fomenta una cultura de seguridad. Otras industrias y subculturas tienen sus propias formas de aprender de los accidentes. Por ejemplo: el ejército de EE. UU. tiene revisiones posteriores a la acción, la medicina tiene juntas de revisión de accidentes y la aviación tiene revisiones de accidentes de la NTSB. He leído informes de análisis de causa raíz de interrupciones en proveedores de alojamiento en la nube hiperescalares. A menudo se leen como las huellas de yeso de un animal muerto hace mucho tiempo, los departamentos legal y de marketing desinfectan y restriegan cualquier elemento de la vida o aprenden de ellos. Son el objeto de culto de la investigación y notificación de accidentes. Todos los movimientos y afectaciones sin nada de sustancia. La cultura predominante en el software de errores parece ser "si sólo". Donde los errores se atribuyen a la falta de conocimiento. Si el operador "simplemente" supiera el impacto del cambio de configuración, si el desarrollador "simplemente" entendiera la interacción de su cambio de código. Es una cultura de conocimiento experto. Se basa en la creencia no examinada de que los errores solo existen por falta de conocimiento o falta de cuidado. O llevados a sus extremos ofensivos: la estupidez y la pereza. En la industria del software, los errores o interrupciones generalmente no resultan en lesiones o muerte. Sin embargo, a medida que la sociedad se vuelve más dependiente de los sistemas de software que estamos construyendo, la gravedad y el impacto de los problemas solo aumentan. A medida que nuestros sistemas de software continúan creciendo en complejidad y el alcance de los problemas para los que escribimos software para resolver, nosotros, como sociedad, debemos lidiar con el cambio de esta cultura. Como un paso en este camino de cambiar esta cultura, estoy hablando de los fracasos que he visto o en los que he participado. Mi objetivo es facilitar que otros compartan dónde han fallado. Esto creará un circuito de retroalimentación que nos permitirá aprender más rápido. Únase a mí para compartir historias de fracaso. Aquí hay una charla sobre el fracaso y un par de publicaciones relacionadas mías y del equipo de Cyclic: https://www.youtube.com/watch?v=kRVUEYPua4A&t=7870s?embedable=true Cómo fallar en Serverless: Serverless es Stateless (entrada de blog) Siempre soleado en us-east-1: The gang hace negocios continuos (publicación de blog) AWS S3: por qué a veces debería presionar el botón de $ 100k (publicación de blog) Nos encantaría escuchar sus historias. Escribe algo. . Publicarlo públicamente Haznos saber. Te respaldamos :) También publicado . aquí Imagen destacada arriba generada por HackerNoon Stable Diffusion.
