ほとんどのソフトウェア バグは知識不足によるものではない

若い頃、ロック クライミングや登山の遠征に何度か参加しました。私は、山での安全を非常に真剣に考えているインストラクターや開業医にさらされました。そのうちの 1 人は、クライミングの事故に関する The American Alpine Club の本を持っていました。事故は、単一の悪い選択の原因ではありませんでした。それらは、時間の経過とともに下された一連の決定によって引き起こされ、それらが組み合わさって事故の条件を作り出しました。

物語の舞台になりそうな岩肌のそばに座っていた私の記憶に残っているのは、場合によっては同じ選択をするかもしれないということでした。時間帯や天候、クライミング パートナーが異なると、同じ選択でもリスクのレベルが異なる可能性があります。それらの物語を読んで議論することで、私はより意識の高い冒険家になり、より安全な登山家になりました.

一連の決定と事故につながった出来事の公開分析と議論は、初心者が経験を積み、専門家が知恵を育て、安全の文化を育むのに役立ちます。他の業界やサブカルチャーには、事故から学ぶ独自の方法があります。たとえば、米軍には事後審査があり、医療には事故審査委員会があり、航空には NTSB 事故審査があります。

ハイパースカラー クラウド ホスティング プロバイダーでの障害の根本原因分析レポートを読みました。多くの場合、彼らは長い間死んでいた動物の石膏の足跡のように読み、法務部門とマーケティング部門は生活のあらゆる要素を消毒してこすり洗いしたり、それらから学んだりしています。それらは、事故調査と報告のカーゴカルトです。実体のないすべての動きと愛情。

エラーに対するソフトウェアの一般的な文化は、「もしそうなら」のようです。エラーが知識不足のせいにされるところ。オペレーターが構成変更の影響を「ちょうど」知っていた場合、開発者がコード変更の相互作用を「ちょうど」理解していた場合。それは専門知識の文化です。これは、バグは知識不足または注意不足からのみ存在するという未検証の信念に基づいています。または、愚かさと怠惰という攻撃的な極端に取り込まれます。

ソフトウェア業界では、ほとんどの場合、バグや機能停止が負傷や死亡につながることはありません。しかし、社会がソフトウェア システムにますます依存するようになるにつれて、問題の深刻さと影響は増大する一方です。ソフトウェア システムの複雑さが増し、ソフトウェアを作成して解決する問題の範囲が拡大するにつれて、私たちは社会として、この文化を変えることに取り組まなければなりません。

この文化を変える道の一歩として、私は自分が見たり参加したりした失敗について話しています。私の目標は、他の人がどこで失敗したかを簡単に共有できるようにすることです.これにより、より速く学習できるフィードバックループが作成されます。

失敗談を共有しに参加してください。失敗についての話と、私と Cyclic チームからのいくつかの関連記事があります。

1. サーバーレスで失敗する方法: サーバーレスはステートレスです (ブログ投稿)
2. 常に晴れた us-east-1: ギャングは事業継続性を維持 (ブログ投稿)
3. AWS S3: 10 万ドルのボタンを押す必要がある理由 (ブログ投稿)

皆様のお話をお待ちしております。

何か書いてください。

公に投稿します。

我々に教えてください。

私たちはあなたの背中を持っています:)

ここにも掲載されています。上記の注目の画像は、HackerNoon Stable Diffusion によって生成されました。