Câu chuyện của Bộ Phân Tích Vi Phân
Quy tắc đầu tiên về kỹ thuật hệ thống của Hamming: Nếu bạn tối ưu hóa các thành phần, bạn sẽ có thể làm hỏng hiệu suất hệ thống.
Ông minh họa điều này bằng một câu chuyện từ công việc của chính mình. Ông vận hành một bộ phân tích vi phân: một máy tính tương tự giải các phương trình vi phân bằng tích phân cơ học. Nhu cầu tăng lên, vì vậy một đơn vị thứ hai được đặt hàng, để kết nối với đơn vị đầu tiên để cả hai có thể vận hành độc lập hoặc cùng nhau.
Những người xây dựng, tự hào về kỹ năng của họ, đã cải thiện các bộ khuếch đại trong đơn vị mới. Hamming khăng khăng rằng bất kỳ cải tiến nào cũng không được can thiệp vào hoạt động của hệ thống tổng thể. Vào ngày chấp nhận, ông chạy bài kiểm tra cổ điển: giải y'' + y = 0, vẽ biểu đồ y so với y', mong đợi một vòng tròn hoàn hảo. Nó thất bại ngay lập tức.
Nguyên nhân: các bộ khuếch đại được cải thiện rút nhiều dòng điện qua mạch tiếp đất. Mạch tiếp đất không đủ, vốn đã hoạt động tốt với các bộ khuếch đại ban đầu, giờ đây cho phép các dòng rò chảy ghép nối giữa các hệ thống con. Sự cải thiện của một thành phần (các bộ khuếch đại) làm hỏng giao diện (tiếp đất), và hệ thống thất bại.
Cách sửa chữa rất đơn giản: tiếp đất dây đồng nặng hơn, nhưng nguyên tắc rõ ràng: một cải tiến thành phần thay đổi hành vi giao diện của nó. Phần còn lại của hệ thống được thiết kế xung quanh giao diện cũ. Cải thiện thành phần, phá vỡ giao diện, làm hỏng hệ thống.
Nhận biết Tối ưu hóa Thành phần
Hamming nói rằng quy tắc 'có vẻ rất hợp lý nếu bạn làm cho một thành phần bị cô lập tốt hơn thì toàn bộ hệ thống sẽ tốt hơn' — nhưng nó lại sai. Sự thất bại là do giao diện: sự cải thiện thành phần thay đổi tín hiệu mà giao diện nhận.
Giao diện Hơn Thành phần
Kết luận thực tế của Hamming: các kỹ sư hệ thống phải thiết kế và xác minh giao diện trước tiên, thành phần thứ hai. Một thành phần hoàn hảo với giao diện bị hỏng là vô dụng. Một thành phần trung bình với giao diện được xác định rõ có thể được cải thiện sau.
Quy tắc 2: các điều kiện biên (ràng buộc) của một hệ thống thường quan trọng hơn các giá trị tối ưu bên trong những ràng buộc đó. Một hệ thống được thiết kế để tối đa hóa hiệu suất tại điểm vận hành dự kiến thường dễ vỡ: những sự lệch nhỏ bên ngoài phạm vi dự kiến gây ra các sự cố. Một hệ thống được thiết kế để hoạt động an toàn trên một phạm vi rộng, với các ràng buộc được xác định rõ, là mạnh mẽ.
Ví dụ: một hệ thống thông tin được thiết kế cho chính xác 100 Mbps lưu lượng ở 25°C sẽ thất bại nếu lưu lượng tăng đến 110 Mbps hoặc nhiệt độ tăng lên 40°C. Một hệ thống được thiết kế với ràng buộc 'không được vượt quá 90% sử dụng ở bất kỳ nhiệt độ nào dưới 60°C' có ích hơn, ngay cả khi hiệu suất đỉnh của nó thấp hơn một chút.
Công việc của kỹ sư hệ thống: không phải để tối ưu hóa A hoặc B riêng lẻ, mà là để tối ưu hóa A+B+C... như một toàn thể, chịu ràng buộc.
Hệ thống Giáo dục: Kỹ thuật Hệ thống Thất bại
Hamming áp dụng nguyên tắc của chính mình cho giáo dục. Trong nhiều thập kỷ, các trường đại học đã tối ưu hóa các khóa học toán học riêng lẻ: Giải tích đã được tước sạch đến những điều cơ bản, Đại số Tuyến tính đã được làm sạch và siết chặt. Mỗi khóa học, được đánh giá riêng lẻ, trông tốt hơn.
Nhưng được xem như một hệ thống, những khoảng trống lớn xuất hiện:
- Cảm ứng toán học: hiếm khi được đề cập sau trung học.
- Số phức: được giới thiệu ngắn gọn trong đại số, sau đó tránh cho đến cuối Đại số Tuyến tính khi các giá trị riêng phức xuất hiện. Học sinh đối mặt với hai ý tưởng khó mới cùng lúc mà không có chuẩn bị trước.
- Hệ số không xác định: được đề cập ngắn gọn.
- Chứng minh tính không thể: hầu như hoàn toàn vắng mặt.
- Toán học rời rạc: phần lớn bị bỏ qua.
Sự tối ưu hóa của mỗi thành phần (mỗi khóa học) tạo ra những khoảng cách giao diện: những cây cầu khái niệm bị thiếu giữa các khóa học. Đầu ra của hệ thống: các kỹ sư và nhà khoa học được giáo dục, bị ảnh hưởng, ngay cả khi số liệu đầu ra của mỗi khóa học cải thiện.
Chống lại Mong muốn Tự nhiên để Sửa chữa Phần Bị hỏng
Nhận xét của Hamming: dễ dàng để nói những lời đúng về kỹ thuật hệ thống. Rất ít người có thể thực sự làm điều đó khi lúc đến.
Phản ứng tự nhiên khi một hệ thống thất bại: xác định thành phần bị hỏng rõ ràng nhất và sửa chữa nó. Đây là tư duy thành phần. Hệ thống thất bại vì một lý do liên quan đến sự tương tác của các thành phần, giao diện, và ràng buộc, nhưng sự thất bại nhìn thấy rõ nhất thường ở một thành phần duy nhất.
Kỷ luật của kỹ sư hệ thống: trước khi sửa chữa sự thất bại nhìn thấy, hãy hỏi: tại sao hệ thống tạo ra sự thất bại này ở thành phần này? Thành phần có thực sự hoạt động kém hơn, hoặc nó được yêu cầu hoạt động bên ngoài bao bì thiết kế của nó bởi phần còn lại của hệ thống? Sửa chữa triệu chứng thành phần để lại sự thất bại hệ thống nguyên vẹn.
Nút cổ chai liên lạc trong các tổ chức lớn theo mô hình này: một bộ phận liên lạc kém (sự thất bại rõ ràng). Sửa chữa thành phần: thuê các nhà liên lạc tốt hơn. Sửa chữa hệ thống: thiết kế lại kiến trúc luồng thông tin để yêu cầu ít liên lạc hơn để đạt được sự phối hợp tương tự.
Chẩn đoán Hệ thống
Sự phân biệt: một sửa chữa thành phần coi một triệu chứng. Một sửa chữa hệ thống coi nguyên nhân. Nguyên nhân thường liên quan đến cấu trúc của hệ thống: những thành phần nào tồn tại, những giao diện nào kết nối chúng, những ràng buộc nào giới hạn hoạt động của chúng.