Ghi chú. bản dịch.: Tác giả của tài liệu này là Cindy Sridharan, một kỹ sư tại imgix, người chuyên phát triển API và đặc biệt là thử nghiệm microservice. Trong tài liệu này, cô chia sẻ tầm nhìn chi tiết của mình về các vấn đề hiện tại trong lĩnh vực truy tìm phân tán, trong đó, theo quan điểm của cô, đang thiếu các công cụ thực sự hiệu quả để giải quyết các vấn đề cấp bách.
[Hình minh họa lấy từ về việc theo dõi phân tán.]
Người ta tin rằng khó thực hiện và lợi nhuận thu được từ nó . Có nhiều lý do khiến việc theo dõi gặp khó khăn, thường trích dẫn công sức liên quan đến việc định cấu hình từng thành phần hệ thống để truyền các tiêu đề thích hợp với mỗi yêu cầu. Mặc dù vấn đề này tồn tại nhưng không có nghĩa là không thể khắc phục được. Nhân tiện, nó không giải thích được tại sao các nhà phát triển không thực sự thích truy tìm (ngay cả khi nó đã hoạt động).
Thách thức chính với việc theo dõi phân tán không phải là thu thập dữ liệu, chuẩn hóa các định dạng để phân phối và trình bày kết quả hay xác định thời điểm, địa điểm và cách lấy mẫu. Tôi không cố tưởng tượng không đáng kể trên thực tế, những "vấn đề dễ hiểu" này khá quan trọng về mặt kỹ thuật và (nếu chúng ta đang xem xét Nguồn mở thực sự) ) những thách thức chính trị cần phải vượt qua để những vấn đề này được xem xét giải quyết.
Tuy nhiên, nếu chúng ta tưởng tượng rằng tất cả những vấn đề này đã được giải quyết thì có khả năng cao là sẽ không có gì thay đổi đáng kể về mặt trải nghiệm người dùng cuối. Việc theo dõi có thể vẫn không được sử dụng thực tế trong các tình huống gỡ lỗi phổ biến nhất—ngay cả sau khi nó đã được triển khai.
Một dấu vết khác biệt như vậy
Truy tìm phân tán bao gồm một số thành phần khác nhau:
- trang bị các công cụ điều khiển cho ứng dụng và middleware;
- chuyển ngữ cảnh phân tán;
- thu thập dấu vết;
- lưu trữ dấu vết;
- trích xuất và trực quan hóa của họ.
Rất nhiều cuộc thảo luận về việc theo dõi phân tán có xu hướng coi nó như một loại hoạt động đơn nhất với mục đích duy nhất là giúp chẩn đoán đầy đủ hệ thống. Điều này phần lớn là do các ý tưởng về truy tìm phân tán đã được hình thành trong lịch sử như thế nào. TRONG , được thực hiện khi các nguồn Zipkin được mở ra, người ta đã đề cập rằng nó [Zipkin] làm cho Twitter nhanh hơn. Các dịch vụ thương mại đầu tiên để truy tìm cũng được quảng bá là .
Ghi chú. bản dịch.: Để làm cho văn bản dễ hiểu hơn, chúng ta hãy định nghĩa hai thuật ngữ cơ bản theo :
- nhịp cầu - yếu tố cơ bản của truy tìm phân tán. Đó là mô tả về một quy trình công việc nhất định (ví dụ: truy vấn cơ sở dữ liệu) với tên, thời gian bắt đầu và kết thúc, thẻ, nhật ký và ngữ cảnh.
- Các nhịp thường chứa các liên kết đến các nhịp khác, cho phép kết hợp nhiều nhịp thành Dấu vết — trực quan hóa vòng đời của một yêu cầu khi nó di chuyển qua hệ thống phân tán.
Dấu vết chứa dữ liệu cực kỳ có giá trị có thể trợ giúp thực hiện các nhiệm vụ như thử nghiệm sản xuất, thử nghiệm khắc phục thảm họa, thử nghiệm tiêm lỗi, v.v. Trên thực tế, một số công ty đã sử dụng phương pháp truy tìm cho các mục đích tương tự. Hãy bắt đầu với có những cách sử dụng khác ngoài việc đơn giản là di chuyển các nhịp sang hệ thống lưu trữ:
- Ví dụ: Uber truy tìm kết quả để phân biệt giữa lưu lượng truy cập thử nghiệm và lưu lượng truy cập sản xuất.
- Facebook dữ liệu theo dõi để phân tích đường dẫn quan trọng và chuyển đổi lưu lượng trong quá trình kiểm tra khắc phục thảm họa thường xuyên.
- Ngoài ra mạng xã hội Sổ ghi chép Jupyter cho phép nhà phát triển chạy truy vấn tùy ý trên kết quả theo dõi.
- Chất kết dính (Tiêm lỗi do dòng truyền thừa) dấu vết được phân phối để kiểm tra bằng cách chèn lỗi.
Không có tùy chọn nào được liệt kê ở trên áp dụng hoàn toàn cho kịch bản gỡ lỗi, trong đó kỹ sư cố gắng giải quyết vấn đề bằng cách xem xét dấu vết.
Khi nó đến chưa đến tập lệnh gỡ lỗi, giao diện chính vẫn là sơ đồ theo dõi (mặc dù một số người còn gọi nó là "Biểu đồ Gantt" hoặc "sơ đồ thác nước"). Dưới theo dõi я tất cả các khoảng và siêu dữ liệu đi kèm cùng nhau tạo nên dấu vết. Mọi hệ thống truy tìm nguồn mở, cũng như mọi giải pháp truy tìm thương mại, đều cung cấp một theo dõi giao diện người dùng để hiển thị, chi tiết và lọc dấu vết.
Vấn đề với tất cả các hệ thống truy tìm mà tôi đã thấy cho đến nay là kết quả trực quan hóa (theo dõi) gần như phản ánh đầy đủ các đặc điểm của quá trình tạo dấu vết. Ngay cả khi các hình ảnh trực quan thay thế được đề xuất: bản đồ nhiệt, cấu trúc liên kết dịch vụ, biểu đồ độ trễ, cuối cùng chúng vẫn đi đến kết quả là theo dõi.
Trước đây tôi rằng hầu hết "sự đổi mới" trong việc theo dõi UI/UX dường như chỉ giới hạn ở siêu dữ liệu bổ sung trong dấu vết, đầu tư vào chúng thông tin có lượng số cao (số lượng cao) hoặc cung cấp khả năng đi sâu vào các khoảng cụ thể hoặc chạy truy vấn giữa và trong dấu vết... Trong đó theo dõi vẫn là công cụ trực quan chính. Chừng nào tình trạng này còn tiếp diễn, thì tính năng theo dõi phân tán (tốt nhất) sẽ chiếm vị trí thứ 4 như một công cụ gỡ lỗi, sau các số liệu, nhật ký và dấu vết ngăn xếp, và tệ nhất là nó sẽ trở thành một sự lãng phí tiền bạc và thời gian.
Sự cố với traceview
Mục đích theo dõi - cung cấp một bức tranh hoàn chỉnh về chuyển động của một yêu cầu duy nhất trên tất cả các thành phần của hệ thống phân tán mà nó có liên quan. Một số hệ thống theo dõi nâng cao hơn cho phép bạn đi sâu vào từng khoảng thời gian riêng lẻ và xem bảng phân tích theo thời gian bên trong một quá trình (khi các nhịp có ranh giới chức năng).
Tiền đề cơ bản của kiến trúc microservice là ý tưởng rằng cơ cấu tổ chức phát triển theo nhu cầu của công ty. Những người ủng hộ dịch vụ vi mô cho rằng việc phân phối các nhiệm vụ kinh doanh khác nhau thành các dịch vụ riêng lẻ cho phép các nhóm phát triển nhỏ, tự chủ kiểm soát toàn bộ vòng đời của các dịch vụ đó, giúp họ có khả năng xây dựng, thử nghiệm và triển khai các dịch vụ đó một cách độc lập. Tuy nhiên, nhược điểm của cách phân phối này là mất thông tin về cách mỗi dịch vụ tương tác với những dịch vụ khác. Trong những điều kiện như vậy, việc theo dõi phân tán được coi là một công cụ không thể thiếu cho gỡ lỗi tương tác phức tạp giữa các dịch vụ.
Nếu bạn thực sự , thì không một ai có thể giữ được nó trong đầu hoàn thành hình ảnh. Trên thực tế, việc phát triển một công cụ dựa trên giả định rằng nó thậm chí có thể xảy ra là một điều gì đó mang tính phản khuôn mẫu (một cách tiếp cận không hiệu quả và không hiệu quả). Lý tưởng nhất là việc gỡ lỗi cần có một công cụ giúp thu hẹp khu vực tìm kiếm của bạn, để các kỹ sư có thể tập trung vào một tập hợp con các thứ nguyên (dịch vụ/người dùng/máy chủ, v.v.) liên quan đến tình huống sự cố đang được xem xét. Khi xác định nguyên nhân lỗi, các kỹ sư không cần phải hiểu điều gì đã xảy ra trong quá trình thực hiện. tất cả các dịch vụ cùng một lúc, vì yêu cầu như vậy sẽ mâu thuẫn với chính ý tưởng về kiến trúc microservice.
Tuy nhiên, traceview là cụ thể là Cái này. Có, một số hệ thống theo dõi cung cấp chế độ xem theo dõi được nén khi số lượng nhịp trong dấu vết quá lớn đến mức chúng không thể hiển thị trong một lần trực quan hóa. Tuy nhiên, do lượng thông tin chứa trong một hình ảnh đơn giản như vậy nên các kỹ sư vẫn ép buộc “sàng lọc” nó, thu hẹp lựa chọn theo cách thủ công thành một tập hợp các dịch vụ là nguồn gốc của vấn đề. Thật không may, trong lĩnh vực này, máy móc nhanh hơn con người rất nhiều, ít mắc lỗi hơn và kết quả của chúng có thể lặp lại nhiều hơn.
Một lý do khác khiến tôi cho rằng traceview sai là vì nó không tốt cho việc gỡ lỗi dựa trên giả thuyết. Về cốt lõi, việc gỡ lỗi là lặp đi lặp lại một quá trình bắt đầu bằng một giả thuyết, sau đó là xác minh các quan sát và sự kiện khác nhau thu được từ hệ thống theo các vectơ khác nhau, kết luận/khái quát hóa và đánh giá sâu hơn về tính đúng đắn của giả thuyết.
Cơ hội nhanh và rẻ kiểm tra các giả thuyết và cải thiện mô hình tinh thần cho phù hợp là hòn đá tảng gỡ lỗi Bất kỳ công cụ gỡ lỗi nào cũng phải tương tác và thu hẹp không gian tìm kiếm hoặc trong trường hợp dẫn sai, cho phép người dùng quay lại và tập trung vào một khu vực khác của hệ thống. Công cụ hoàn hảo sẽ làm được điều này chủ động, ngay lập tức thu hút sự chú ý của người dùng đến các khu vực có vấn đề tiềm ẩn.
Chao ôi, theo dõi không thể gọi là công cụ có giao diện tương tác. Điều tốt nhất bạn có thể hy vọng khi sử dụng nó là tìm ra một số nguồn có độ trễ tăng lên và xem xét tất cả các thẻ cũng như nhật ký có thể có được liên kết với nó. Điều này không giúp kỹ sư xác định được hoa văn trong giao thông, chẳng hạn như chi tiết cụ thể về phân bổ độ trễ hoặc phát hiện mối tương quan giữa các phép đo khác nhau. có thể giúp giải quyết một số vấn đề này. Thật sự, phân tích thành công bằng cách sử dụng máy học để xác định các khoảng thời gian bất thường và xác định một tập hợp con các thẻ có thể liên quan đến hành vi bất thường. Tuy nhiên, tôi vẫn chưa thấy hình ảnh trực quan hấp dẫn về kết quả học máy hoặc khai thác dữ liệu được áp dụng cho các khoảng khác biệt đáng kể so với chế độ xem theo dõi hoặc DAG (biểu đồ chu kỳ có hướng).
Các nhịp ở mức quá thấp
Vấn đề cơ bản với traceview là nhịp là những nguyên hàm ở mức độ quá thấp cho cả phân tích độ trễ và phân tích nguyên nhân gốc rễ. Nó giống như phân tích cú pháp các lệnh của bộ xử lý riêng lẻ để cố gắng giải quyết một ngoại lệ, biết rằng có nhiều công cụ cấp cao hơn như backtrace thuận tiện hơn nhiều khi làm việc.
Hơn nữa, tôi sẽ tự do khẳng định điều sau: lý tưởng nhất là chúng ta không cần bức tranh toàn cảnh xảy ra trong vòng đời yêu cầu, được thể hiện bằng các công cụ theo dõi hiện đại. Thay vào đó, cần có một số dạng trừu tượng ở cấp độ cao hơn chứa thông tin về những gì đã đi sai (tương tự như backtrace), cùng với một số ngữ cảnh. Thay vì xem toàn bộ dấu vết, tôi thích xem nó hơn часть, nơi có điều gì đó thú vị hoặc bất thường xảy ra. Hiện tại, việc tìm kiếm được thực hiện thủ công: kỹ sư nhận được dấu vết và phân tích độc lập các nhịp để tìm kiếm điều gì đó thú vị. Cách tiếp cận của những người nhìn chằm chằm vào các khoảng trong dấu vết riêng lẻ với hy vọng phát hiện hoạt động đáng ngờ hoàn toàn không có quy mô (đặc biệt là khi họ phải hiểu tất cả siêu dữ liệu được mã hóa trong các khoảng khác nhau, chẳng hạn như ID khoảng, tên phương thức RPC, khoảng thời gian 'a, nhật ký, thẻ, v.v.).
Các lựa chọn thay thế cho traceview
Kết quả theo dõi hữu ích nhất khi chúng có thể được hiển thị theo cách cung cấp cái nhìn sâu sắc không hề tầm thường về những gì đang xảy ra trong các bộ phận được kết nối với nhau của hệ thống. Cho đến khi điều này xảy ra, quá trình gỡ lỗi phần lớn vẫn còn trơ và phụ thuộc vào khả năng của người dùng trong việc nhận thấy các mối tương quan phù hợp, kiểm tra các phần phù hợp của hệ thống hoặc ghép các mảnh ghép lại với nhau - trái ngược với công cụ, giúp người dùng hình thành các giả thuyết này.
Tôi không phải là nhà thiết kế hình ảnh hay chuyên gia UX, nhưng trong phần tiếp theo, tôi muốn chia sẻ một số ý tưởng về những hình ảnh trực quan này trông như thế nào.
Tập trung vào các dịch vụ cụ thể
Vào thời điểm ngành đang củng cố các ý tưởng , có vẻ hợp lý khi các nhóm riêng lẻ nên ưu tiên đảm bảo dịch vụ của họ phù hợp với các mục tiêu này. Nó theo sau đó định hướng dịch vụ trực quan hóa là phù hợp nhất cho các nhóm như vậy.
Dấu vết, đặc biệt là không lấy mẫu, là một kho tàng thông tin về từng thành phần của hệ thống phân tán. Thông tin này có thể được cung cấp cho một bộ xử lý thông minh sẽ cung cấp cho người dùng định hướng dịch vụ Chúng có thể được xác định trước - ngay cả trước khi người dùng nhìn vào dấu vết:
- Sơ đồ phân bổ độ trễ chỉ dành cho các yêu cầu có mức độ nổi bật cao (yêu cầu ngoại lệ);
- Sơ đồ phân bổ độ trễ cho các trường hợp không đạt được mục tiêu SLO dịch vụ;
- Các thẻ “phổ biến”, “thú vị” và “kỳ lạ” nhất trong các truy vấn thường xuyên nhất được lặp đi lặp lại;
- Phân tích độ trễ cho các trường hợp phụ thuộc dịch vụ không đạt được mục tiêu SLO của chúng;
- Phân tích độ trễ cho các dịch vụ hạ nguồn khác nhau.
Một số câu hỏi này đơn giản là không được giải đáp bằng các số liệu tích hợp sẵn, buộc người dùng phải xem xét kỹ lưỡng các khoảng thời gian. Kết quả là chúng tôi có một cơ chế cực kỳ thù địch với người dùng.
Điều này đặt ra câu hỏi: còn những tương tác phức tạp giữa các dịch vụ đa dạng do các nhóm khác nhau kiểm soát thì sao? Phải không theo dõi không được coi là công cụ thích hợp nhất để làm nổi bật tình huống đó?
Các nhà phát triển di động, chủ sở hữu dịch vụ không trạng thái, chủ sở hữu dịch vụ trạng thái được quản lý (như cơ sở dữ liệu) và chủ sở hữu nền tảng có thể quan tâm đến thứ khác bài thuyết trình hệ thống phân phối; theo dõi là một giải pháp quá chung chung cho những nhu cầu cơ bản khác nhau này. Ngay cả trong kiến trúc vi dịch vụ rất phức tạp, chủ sở hữu dịch vụ cũng không cần kiến thức sâu về nhiều hơn hai hoặc ba dịch vụ thượng nguồn và hạ nguồn. Về cơ bản, trong hầu hết các tình huống, người dùng chỉ cần trả lời các câu hỏi liên quan đến bộ dịch vụ hạn chế.
Nó giống như việc xem xét một tập hợp nhỏ các dịch vụ qua kính lúp để xem xét kỹ lưỡng. Điều này sẽ cho phép người dùng đặt những câu hỏi cấp bách hơn liên quan đến sự tương tác phức tạp giữa các dịch vụ này và các dịch vụ phụ thuộc trực tiếp của chúng. Điều này tương tự như việc truy vết ngược trong thế giới dịch vụ, nơi kỹ sư biết mà sai và cũng có một số hiểu biết về những gì đang xảy ra ở các dịch vụ xung quanh để hiểu tại sao.
Cách tiếp cận mà tôi đang quảng bá hoàn toàn trái ngược với cách tiếp cận dựa trên lượt xem theo dõi từ trên xuống, trong đó việc phân tích bắt đầu với toàn bộ dấu vết và sau đó dần dần đi xuống từng khoảng riêng lẻ. Ngược lại, cách tiếp cận từ dưới lên bắt đầu bằng cách phân tích một khu vực nhỏ gần nguyên nhân tiềm ẩn của sự cố, sau đó mở rộng không gian tìm kiếm khi cần thiết (với khả năng huy động các nhóm khác để phân tích phạm vi dịch vụ rộng hơn). Cách tiếp cận thứ hai phù hợp hơn để kiểm tra nhanh các giả thuyết ban đầu. Sau khi thu được kết quả cụ thể, có thể chuyển sang phân tích chi tiết và có mục tiêu hơn.
Xây dựng cấu trúc liên kết
Chế độ xem dành riêng cho dịch vụ có thể cực kỳ hữu ích nếu người dùng biết cái gì một dịch vụ hoặc nhóm dịch vụ chịu trách nhiệm làm tăng độ trễ hoặc gây ra lỗi. Tuy nhiên, trong một hệ thống phức tạp, việc xác định dịch vụ vi phạm có thể là một nhiệm vụ không hề đơn giản khi xảy ra lỗi, đặc biệt nếu không có thông báo lỗi nào được báo cáo từ dịch vụ.
Việc xây dựng cấu trúc liên kết dịch vụ có thể giúp ích rất nhiều trong việc tìm ra dịch vụ nào đang có tỷ lệ lỗi tăng đột biến hoặc độ trễ tăng lên khiến dịch vụ xuống cấp đáng kể. Khi tôi nói về việc xây dựng một cấu trúc liên kết, tôi không có ý nói bản đồ dịch vụ, hiển thị mọi dịch vụ có sẵn trong hệ thống và được biết đến với . Chế độ xem này không tốt hơn chế độ xem theo dõi dựa trên biểu đồ chu kỳ có hướng. Thay vào đó tôi muốn xem cấu trúc liên kết dịch vụ được tạo động, dựa trên các thuộc tính nhất định như tỷ lệ lỗi, thời gian phản hồi hoặc bất kỳ tham số nào do người dùng xác định giúp làm rõ tình huống với các dịch vụ đáng ngờ cụ thể.
Hãy lấy một ví dụ. Hãy tưởng tượng một trang web tin tức giả định. Dịch vụ trang chủ (trang đầu) trao đổi dữ liệu với Redis, với dịch vụ đề xuất, với dịch vụ quảng cáo và dịch vụ video. Dịch vụ video lấy video từ S3 và siêu dữ liệu từ DynamoDB. Dịch vụ đề xuất nhận siêu dữ liệu từ DynamoDB, tải dữ liệu từ Redis và MySQL, đồng thời ghi thông báo tới Kafka. Dịch vụ quảng cáo nhận dữ liệu từ MySQL và viết tin nhắn tới Kafka.
Dưới đây là sơ đồ trình bày cấu trúc liên kết này (nhiều chương trình định tuyến thương mại xây dựng cấu trúc liên kết). Nó có thể hữu ích nếu bạn cần hiểu sự phụ thuộc của dịch vụ. Tuy nhiên, trong thời gian gỡ lỗi, khi một dịch vụ nhất định (chẳng hạn như dịch vụ video) có thời gian phản hồi tăng lên thì cấu trúc liên kết như vậy không hữu ích lắm.
Sơ đồ dịch vụ của một trang tin tức giả định
Sơ đồ dưới đây sẽ phù hợp hơn. Có vấn đề với dịch vụ (Video) được vẽ ngay ở trung tâm. Người dùng nhận thấy nó ngay lập tức. Từ hình ảnh này, có thể thấy rõ dịch vụ video đang hoạt động bất thường do thời gian phản hồi của S3 tăng lên, điều này ảnh hưởng đến tốc độ tải một phần của trang chính.
Cấu trúc liên kết động chỉ hiển thị các dịch vụ “thú vị”
Cấu trúc liên kết được tạo động có thể hiệu quả hơn bản đồ dịch vụ tĩnh, đặc biệt là trong cơ sở hạ tầng linh hoạt, tự động mở rộng quy mô. Khả năng so sánh và đối chiếu các cấu trúc liên kết dịch vụ cho phép người dùng đặt các câu hỏi phù hợp hơn. Những câu hỏi chính xác hơn về hệ thống có nhiều khả năng dẫn đến sự hiểu biết tốt hơn về cách thức hoạt động của hệ thống.
Hiển thị so sánh
Một hình ảnh trực quan hữu ích khác sẽ là một màn hình so sánh. Hiện tại các dấu vết không phù hợp lắm cho việc so sánh song song, vì vậy việc so sánh thường được thực hiện nhịp. Và ý tưởng chính của bài viết này chính xác là các nhịp ở mức quá thấp để có thể trích xuất thông tin có giá trị nhất từ kết quả theo dõi.
So sánh hai dấu vết về cơ bản không yêu cầu hình dung mới. Trên thực tế, một cái gì đó giống như biểu đồ thể hiện cùng một thông tin như lượt xem theo dõi là đủ. Đáng ngạc nhiên là ngay cả phương pháp đơn giản này cũng có thể mang lại nhiều kết quả hơn là chỉ nghiên cứu hai dấu vết riêng biệt. Thậm chí còn mạnh mẽ hơn nữa là khả năng hình dung so sánh dấu vết Tổng cộng. Sẽ cực kỳ hữu ích khi xem thay đổi cấu hình cơ sở dữ liệu được triển khai gần đây để kích hoạt GC (thu gom rác) ảnh hưởng như thế nào đến thời gian phản hồi của dịch vụ hạ nguồn trong phạm vi vài giờ. Nếu những gì tôi đang mô tả ở đây nghe giống như một bản phân tích A/B về tác động của những thay đổi về cơ sở hạ tầng trong nhiều dịch vụ sử dụng kết quả theo dõi thì bạn không đi quá xa sự thật.
Kết luận
Tôi không đặt câu hỏi về tính hữu ích của việc theo dõi. Tôi chân thành tin rằng không có phương pháp nào khác để thu thập dữ liệu phong phú, nhân quả và theo ngữ cảnh như phương pháp có trong dấu vết. Tuy nhiên, tôi cũng tin rằng tất cả các giải pháp truy tìm đều sử dụng dữ liệu này cực kỳ kém hiệu quả. Chừng nào các công cụ theo dõi vẫn còn bị kẹt trên biểu diễn traceview, chúng sẽ bị hạn chế về khả năng tận dụng tối đa thông tin có giá trị có thể được trích xuất từ dữ liệu có trong dấu vết. Ngoài ra, còn có nguy cơ phát triển thêm một giao diện trực quan hoàn toàn không thân thiện và không trực quan, điều này sẽ hạn chế nghiêm trọng khả năng khắc phục lỗi trong ứng dụng của người dùng.
Việc gỡ lỗi các hệ thống phức tạp, ngay cả với các công cụ mới nhất, là vô cùng khó khăn. Các công cụ sẽ giúp nhà phát triển hình thành và kiểm tra giả thuyết, tích cực cung cấp thông tin liên quan, xác định các ngoại lệ và lưu ý các đặc điểm trong việc phân bổ độ trễ. Để truy tìm trở thành công cụ được các nhà phát triển lựa chọn khi khắc phục lỗi sản xuất hoặc giải quyết các sự cố trải rộng trên nhiều dịch vụ, cần có giao diện người dùng ban đầu và hình ảnh trực quan phù hợp hơn với mô hình tinh thần của các nhà phát triển tạo và vận hành các dịch vụ đó.
Sẽ cần nỗ lực tinh thần đáng kể để thiết kế một hệ thống thể hiện các tín hiệu khác nhau có sẵn trong kết quả theo dõi theo cách được tối ưu hóa để dễ phân tích và suy luận. Bạn cần suy nghĩ về cách trừu tượng hóa cấu trúc liên kết hệ thống trong quá trình gỡ lỗi theo cách giúp người dùng vượt qua các điểm mù mà không cần nhìn vào từng dấu vết hoặc nhịp riêng lẻ.
Chúng ta cần khả năng phân lớp và trừu tượng hóa tốt (đặc biệt là trong giao diện người dùng). Những thứ phù hợp với quy trình gỡ lỗi dựa trên giả thuyết, nơi bạn có thể lặp đi lặp lại việc đặt câu hỏi và kiểm tra các giả thuyết. Chúng sẽ không tự động giải quyết tất cả các vấn đề về khả năng quan sát, nhưng chúng sẽ giúp người dùng mài giũa trực giác và đặt ra các câu hỏi thông minh hơn. Tôi kêu gọi một cách tiếp cận sáng tạo và chu đáo hơn để hình dung. Có một triển vọng thực sự ở đây để mở rộng tầm nhìn.
Tái bút từ người dịch
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «'.
Nguồn: www.habr.com