Hầu hết các lỗi phần mềm không phải do thiếu kiến thức

Khi tôi còn trẻ, tôi đã tham gia một số cuộc thám hiểm leo núi và leo núi. Tôi đã được tiếp xúc với một số người hướng dẫn và học viên rất coi trọng việc giữ an toàn trên núi. Một trong số họ mang theo một cuốn sách của Câu lạc bộ Alpine của Mỹ về tai nạn leo núi. Tai nạn không bao giờ là nguyên nhân của một lựa chọn tồi. Chúng được gây ra bởi một loạt các quyết định, được thực hiện theo thời gian, kết hợp lại để tạo ra các điều kiện cho vụ tai nạn.

Điều đọng lại trong trí nhớ của tôi, khi ngồi bên những khuôn mặt đá rất có thể là bối cảnh cho một trong những câu chuyện, là trong một số trường hợp nhất định, chúng tôi có thể đưa ra một trong những lựa chọn giống nhau. Với một thời điểm khác nhau trong ngày, thời tiết khác nhau, hoặc các đối tác leo núi khác nhau, cùng một lựa chọn có thể có các mức độ rủi ro khác nhau. Đọc và thảo luận về những câu chuyện đó khiến tôi trở thành một nhà thám hiểm có ý thức hơn và một người leo núi an toàn hơn.

Việc phân tích và thảo luận công khai về chuỗi các quyết định và sự kiện dẫn đến tai nạn giúp người mới bắt đầu xây dựng kinh nghiệm, các chuyên gia phát triển trí tuệ và nuôi dưỡng văn hóa an toàn. Các ngành công nghiệp và tiểu nền văn hóa khác, có những cách riêng để học hỏi từ những tai nạn. Ví dụ: quân đội Hoa Kỳ có các cuộc đánh giá hành động sau khi hành động, y học có các hội đồng xem xét tai nạn và hàng không có các cuộc đánh giá tai nạn NTSB.

Tôi đã đọc các báo cáo phân tích nguyên nhân gốc rễ từ sự cố ngừng hoạt động tại các nhà cung cấp dịch vụ lưu trữ đám mây siêu vô hướng. Thường thì họ đọc giống như những dấu chân thạch cao của một con vật chết lâu ngày, các bộ phận pháp lý và tiếp thị làm vệ sinh và tẩy rửa bất kỳ yếu tố nào của cuộc sống hoặc học hỏi từ chúng. Họ là người vận chuyển hàng hóa trong quá trình điều tra và báo cáo tai nạn. Tất cả các chuyển động và ảnh hưởng mà không có chất nào.

Văn hóa phổ biến trong phần mềm đối với các lỗi dường như là "nếu bạn chỉ cần". Lỗi ở đâu do thiếu hiểu biết. Nếu nhà điều hành đã "chỉ" biết tác động của việc thay đổi cấu hình, nếu nhà phát triển "chỉ" hiểu sự tương tác của việc thay đổi mã của họ. Đó là một nền văn hóa của kiến thức chuyên gia. Nó dựa trên niềm tin chưa được khám phá rằng bọ chỉ tồn tại do thiếu kiến thức hoặc thiếu chăm sóc. Hoặc bị coi là thái cực khó chịu của họ: ngu ngốc và lười biếng.

Trong ngành công nghiệp phần mềm, lỗi hoặc sự cố thường không dẫn đến thương tích hoặc tử vong. Tuy nhiên, khi xã hội ngày càng phụ thuộc nhiều hơn vào các hệ thống phần mềm mà chúng ta đang xây dựng, mức độ nghiêm trọng và tác động của các vấn đề chỉ tăng lên. Khi các hệ thống phần mềm của chúng ta tiếp tục phát triển với mức độ phức tạp và phạm vi của các vấn đề mà chúng ta viết phần mềm để giải quyết, chúng ta với tư cách là một xã hội phải vật lộn với việc thay đổi văn hóa này.

Là một bước trên con đường thay đổi văn hóa này, tôi đang nói về những thất bại mà tôi đã thấy hoặc đã tham gia. Mục tiêu của tôi là giúp những người khác dễ dàng chia sẻ nơi họ đã thất bại. Điều này sẽ tạo ra một vòng phản hồi cho phép chúng tôi tìm hiểu nhanh hơn.

Hãy cùng tôi chia sẻ những câu chuyện thất bại. Đây là một cuộc nói chuyện về thất bại và một vài bài đăng liên quan từ bản thân tôi và nhóm Cyclic:

1. Làm thế nào để thất bại ở Serverless: Serverless là không trạng thái (bài đăng trên blog)
2. It Always Sunny in us-East-1: Băng đảng làm ăn liên tục (bài đăng trên blog)
3. AWS S3: Tại sao đôi khi bạn nên nhấn nút $ 100k (bài đăng trên blog)

Chúng tôi rất thích nghe những câu chuyện của bạn.

Viết một cái gì đó lên.

Đăng nó một cách công khai .

Hãy cho chúng tôi biết.

Chúng tôi đã hỗ trợ bạn :)

Cũng được xuất bản ở đây . Hình ảnh nổi bật ở trên được tạo bởi HackerNoon Stable Diffusion.