Bỏ qua đến nội dung chính

Failure Patterns

Chương này là lõi của trang web này.

Nó mô tả dưới dạng Failure Patterns
các "cách hỏng" được quan sát lặp đi lặp lại
trong software và các tổ chức.

Các Patterns được đề cập ở đây
không phải là các phân tích nguyên nhân gốc rễ hoặc các danh sách kiểm tra.
Chúng là các cấu trúc giải quyết
cách các giả định như decisions, measurement, responsibility, và boundaries
sụp đổ và trở nên cố định.

Pattern as Structure​

Failure Patterns
không phát sinh từ một lỗi hoặc đánh giá sai duy nhất.

Khi nhiều Forces như
sự không chắc chắn, responsibility phân tán, absence of measurement, và các ràng buộc thời gian
tiếp tục tác động đồng thời,
một hành vi nhất định ổn định như một "cấu trúc."

Các Patterns được đề cập trong chương này
mô tả các cấu trúc thất bại xuất hiện
như kết quả của các Forces như vậy đạt đến trạng thái cân bằng mà không được giải quyết.

Mỗi Pattern được cấu thành từ các khía cạnh sau:

  • Context
  • Forces
  • Failure Mode
  • Consequences
  • Countermeasures
  • Resulting Context

Đây không phải là các bước,
mà là các khía cạnh của cùng một tình huống được cắt từ các góc nhìn khác nhau.

Core and Derived Patterns​

Trang web này tổ chức Failure Patterns
như hai lớp với các vai trò khác nhau.

Core Failure Patterns​

Một nhóm Patterns giải quyết
các cấu trúc cơ bản về cách mọi thứ hỏng,
như decisions, measurement, responsibility, và boundaries.

Chúng tồn tại như các giả định trong nhiều tình huống
và hình thành nền tảng mà các Failure Patterns khác được thành lập.

Derived Failure Patterns​

Một nhóm Patterns giải quyết
các dạng hỏng được suy ra thường được quan sát trong thực tế
trong các môi trường mà Core Failure Patterns được thiết lập.

Chúng gần với các ngữ cảnh cụ thể như công nghệ, tổ chức, và vận hành,
và dễ dàng được sử dụng trực tiếp như các thuật ngữ chẩn đoán trong thực địa.

Relationships Between Patterns​

Derived Failure Patterns
có xu hướng được quan sát dễ dàng hơn
trong các tình huống mà các Core Failure Patterns cụ thể tồn tại như các giả định.

Ví dụ,

Đây không chỉ ra các mối quan hệ nhân quả.
Chúng là các ví dụ về các chuỗi cấu trúc
được quan sát lặp đi lặp lại trong các tình huống với các sắp xếp tương tự của Forces.

Intended Readers and Use Cases​

Các Failure Patterns được đề cập trong chương này
không giả định một vai trò hoặc nghề nghiệp cụ thể.

Người dùng chính dự kiến là những người
muốn tổ chức một cách cấu trúc
"điều gì đang xảy ra" và "tại sao các quyết định không thể được thực hiện"
trong các tình huống mà các thay đổi, cải tiến, hoặc quyết định
phải được thực hiện đối với software đang vận hành.

Ví dụ,

  • Được yêu cầu thực hiện các thay đổi mà không biết các specifications hoặc giả định cho các quyết định
  • Thực hiện các hoạt động cải tiến nhưng không thể giải thích hiệu quả của chúng
  • Đã đồng ý được cho là, nhưng các quyết định bị lật lại sau đó
  • Các tests và staging pass, nhưng lo lắng vẫn còn
  • Distribution và external integration tăng, và phạm vi tác động không thể giải thích

Trong các tình huống như vậy,
các Patterns trong chương này có thể được sử dụng như các thuật ngữ chẩn đoán.

Patterns không thay thế cho các quyết định.
Chúng là các đường hướng dẫn để diễn đạt
các giả định, động lực, và cấu trúc
để thực hiện các quyết định.

Hints for Use​

  • Khi không thể tổ chức điều gì đang xảy ra, tham khảo Context
  • Khi suy nghĩ về lý do tại sao nó không dừng lại, tham khảo Forces
  • Khi muốn thay đổi không phải cách sửa mà là các giả định cho các quyết định, tham khảo Countermeasures

Patterns không phải là phương thuốc chữa bách bệnh.
Sử dụng chúng như các điểm tham chiếu để khôi phục khả năng ra quyết định
trong các tình huống mà nhiều Forces đang căng thẳng.

Cập nhật lần cuối vào bởi Hiroshi Kurabayashi