Quand j'étais plus jeune, j'ai participé à plusieurs expéditions d'escalade et d'alpinisme. J'ai été exposé à des instructeurs et à des pratiquants qui prenaient très au sérieux la sécurité en montagne. L'un d'eux portait un livre de l'American Alpine Club sur les accidents d'escalade. Les accidents n'ont jamais été la cause d'un seul mauvais choix. Ils ont été causés par une série de décisions, prises au fil du temps, qui se sont conjuguées pour créer les conditions de l'accident. Ce qui m'est resté en mémoire, assis à côté de parois rocheuses qui pouvaient très bien être le théâtre d'une des histoires, c'est que dans certains cas on pouvait faire un des mêmes choix. Qu'étant donné une heure différente de la journée, ou une météo différente, ou différents partenaires d'escalade, le même choix pourrait avoir différents niveaux de risque. Lire et discuter de ces histoires a fait de moi un aventurier plus conscient et un grimpeur plus sûr. L'analyse et la discussion publiques de la chaîne de décisions et d'événements qui ont conduit à des accidents aident les débutants à acquérir de l'expérience, les experts à acquérir de la sagesse et à favoriser une culture de la sécurité. D'autres industries et sous-cultures ont leurs propres façons d'apprendre des accidents. Par exemple : l'armée américaine a des examens après action, la médecine a des comités d'examen des accidents et l'aviation a des examens des accidents par le NTSB. J'ai lu des rapports d'analyse des causes profondes de pannes chez des fournisseurs d'hébergement cloud hyper scalaires. Souvent, ils se lisent comme les empreintes de pas en plâtre d'un animal mort depuis longtemps, les services juridiques et marketing désinfectant et nettoyant tout élément de la vie ou apprenant d'eux. Ils sont la cargaison culte des enquêtes et des rapports sur les accidents. Tous les mouvements et l'affectation sans aucune substance. La culture qui prévaut dans les logiciels aux erreurs semble être "si vous venez". Où les erreurs sont imputées au manque de connaissances. Si l'opérateur avait "juste" connu l'impact d'un changement de configuration, si le développeur avait "juste" compris l'interaction de son changement de code. C'est une culture de la connaissance experte. Il est basé sur la croyance non vérifiée que les bugs n'existent que par manque de connaissances ou de soins. Ou poussés à leurs extrêmes offensifs : stupidité et paresse. Dans l'industrie du logiciel, les bogues ou les pannes n'entraînent généralement pas de blessures ou de décès. Cependant, à mesure que la société devient plus dépendante des systèmes logiciels que nous construisons, la gravité et l'impact des problèmes ne font qu'augmenter. Alors que nos systèmes logiciels continuent de croître en complexité et en portée des problèmes pour lesquels nous écrivons des logiciels à résoudre, nous, en tant que société, devons nous attaquer à changer cette culture. En tant qu'étape sur ce chemin de changement de cette culture, je parle des échecs que j'ai vus ou auxquels j'ai participé. Mon objectif est de permettre aux autres de partager plus facilement où ils ont échoué. Cela créera une boucle de rétroaction qui nous permettra d'apprendre plus rapidement. Joignez-vous à moi pour partager des histoires d'échec. Voici une discussion sur l'échec et quelques messages connexes de moi-même et de l'équipe Cyclic : https://www.youtube.com/watch?v=kRVUEYPua4A&t=7870s?embedable=true Comment échouer sans serveur : sans serveur, c'est sans état (article de blog) C'est toujours ensoleillé en us-east-1 : Le gang assure la continuité des activités (article de blog) AWS S3 : pourquoi parfois vous devriez appuyer sur le bouton 100 000 $ (article de blog) Nous aimerions entendre vos histoires. Écrivez quelque chose. . Publiez-le publiquement Faites le nous savoir. Nous vous soutenons :) Également publié . ici Image sélectionnée ci-dessus générée par HackerNoon Stable Diffusion.
