Thực tế của một kỹ sư mạng (với mì và... muối?)
Gần đây, khi thảo luận về nhiều sự cố khác nhau với các kỹ sư, tôi nhận thấy một mô hình thú vị.
Trong các cuộc thảo luận này, câu hỏi về “nguyên nhân gốc rễ” luôn được đặt ra. Những độc giả trung thành có lẽ biết rằng tôi có trên . Ở nhiều tổ chức, việc phân tích sự cố hoàn toàn dựa trên khái niệm này. Họ sử dụng các kỹ thuật khác nhau để xác định mối quan hệ nhân quả, chẳng hạn như . Những phương pháp này thừa nhận cái gọi là “tính tuyến tính của các sự kiện” như một giáo điều không thể chối cãi.
Khi bạn thách thức ý tưởng này và chỉ ra rằng tính tuyến tính chắc chắn là có tính lừa dối trong các hệ thống phức tạp, một cuộc thảo luận hấp dẫn sẽ ra đời. Những người tranh chấp nhấn mạnh rằng chỉ có kiến thức về “nguyên nhân gốc rễ” mới giúp chúng ta hiểu được điều gì đang xảy ra.
Tôi nhận thấy một mô hình thú vị: các nhà phát triển và nhà phát triển phản ứng khác nhau với ý tưởng này. Theo kinh nghiệm của tôi, các nhà phát triển có nhiều khả năng lập luận rằng nguyên nhân cốt lõi là quan trọng và mối quan hệ nhân quả luôn có thể được thiết lập trong các sự kiện. Mặt khác, DevOps thường đồng ý rằng một thế giới phức tạp không phải lúc nào cũng tuân theo tính tuyến tính.
Tôi luôn tự hỏi tại sao lại như vậy? Cái gì làm cho lập trình viên lại chỉ trích quan điểm “nguyên nhân sâu xa là chuyện hoang đường” như vậy? Giống như một hệ thống miễn dịch nhận biết tác nhân lạ. Tại sao họ lại phản ứng theo cách này, trong khi những người sùng đạo khá nghiêng xem xét ý tưởng này?
Tôi không hoàn toàn chắc chắn, nhưng tôi có một số suy nghĩ về điều này. Nó liên quan đến các bối cảnh khác nhau trong đó các chuyên gia này thực hiện công việc hàng ngày của họ.
Các nhà phát triển thường làm việc với các công cụ xác định. Tất nhiên, trình biên dịch, trình liên kết, hệ điều hành - tất cả đều là những hệ thống phức tạp, nhưng chúng ta đã quen với việc chúng đưa ra kết quả xác định và chúng ta tưởng tượng chúng là xác định: nếu chúng ta cung cấp cùng một dữ liệu đầu vào thì chúng ta thường mong đợi kết quả cùng một đầu ra từ các hệ thống này. Và nếu có vấn đề với đầu ra (“lỗi”) thì nhà phát triển sẽ giải quyết nó bằng cách phân tích dữ liệu đầu vào (từ người dùng hoặc từ một bộ công cụ trong quá trình phát triển). Họ tìm kiếm "lỗi" rồi thay đổi dữ liệu đầu vào. Điều này sửa chữa "lỗi".
Giả định cơ bản về phát triển phần mềm: cùng một dữ liệu đầu vào đáng tin cậy và chắc chắn sẽ tạo ra cùng một đầu ra.
Trên thực tế, bản thân một kết quả không xác định được coi là một lỗi: nếu kết quả đầu ra không mong muốn hoặc có lỗi không được sao chép thì các nhà phát triển có xu hướng mở rộng điều tra sang các phần khác của ngăn xếp (hệ điều hành, mạng, v.v.), phần này cũng hoạt động tương tự. ít nhiều mang tính xác định, tạo ra cùng một kết quả với cùng một dữ liệu đầu vào... và nếu đó không phải là trường hợp, thì đây vẫn được coi là một lỗi. Bây giờ chỉ là lỗi hệ điều hành hoặc mạng.
Trong mọi trường hợp, thuyết tất định là một giả định cơ bản, gần như được coi là đương nhiên đối với hầu hết các lập trình viên công việc.
Nhưng đối với bất kỳ anh chàng tín đồ nào đã dành cả ngày để thu thập phần cứng hoặc tìm ra API đám mây, ý tưởng về một thế giới hoàn toàn xác định (miễn là thậm chí có thể ánh xạ tất cả các đầu vào!) chỉ là một khái niệm thoáng qua. Ngay cả khi bạn đặt nó sang một bên , những kỹ sư giàu kinh nghiệm đã từng chứng kiến những điều kỳ lạ nhất trên thế giới này. Họ biết điều đó , chưa kể hàng triệu yếu tố khác trong môi trường.
Vì vậy, các kỹ sư giàu kinh nghiệm sẽ dễ dàng nghi ngờ rằng tất cả các sự cố đều có một nguyên nhân cốt lõi duy nhất và các kỹ thuật như “Năm lý do” sẽ dẫn đến nguyên nhân gốc rễ đó một cách chính xác (và có thể lặp lại!) Trên thực tế, điều này mâu thuẫn với kinh nghiệm của chính họ, khi các mảnh ghép không khớp chặt chẽ trong thực tế. Vì vậy, họ chấp nhận ý tưởng này dễ dàng hơn.
Tất nhiên, tôi không nói rằng các nhà phát triển ngây thơ, ngu ngốc hoặc không thể hiểu được tuyến tính có thể lừa dối như thế nào.
Nhưng đối với tôi, có vẻ như phản ứng chung của các nhà phát triển trong các cuộc tranh luận này thường liên quan đến thực tế là khái niệm thuyết tất định nhìn chung phục vụ họ tốt trong công việc hàng ngày. Họ không gặp phải thuyết bất định thường xuyên như các kỹ sư phải bắt những con mèo của Schrödinger trên cơ sở hạ tầng của họ.
Điều này có thể không giải thích đầy đủ các phản ứng được quan sát của nhà phát triển nhưng là một lời nhắc nhở mạnh mẽ rằng phản ứng của chúng tôi là sự kết hợp phức tạp của nhiều yếu tố.
Điều quan trọng cần nhớ là sự phức tạp này, cho dù chúng ta đang xử lý một sự cố đơn lẻ, đang cộng tác trên một quy trình phân phối phần mềm hay đang cố gắng hiểu thế giới rộng lớn hơn.
Nguồn: www.habr.com