Robot không biết nói, nên kỹ sư hiện trường ở Monumental phải nói thay

Thử hình dung: bảy giờ sáng, giữa công trường. Một con robot dừng hẳn ở hàng gạch thứ năm, và người đốc công đang đi về phía bạn. Laptop còn chưa mở xong đã có người hỏi: “Nó hỏng à?”

Monumental là công ty đưa những đội robot xây gạch cỡ nhỏ, chạy điện, tự di chuyển tới công trường để xây tường. Tin tuyển dụng vị trí Forward Deployed Robotics Engineer (FDRE) của họ ghi rõ rằng debug những lỗi xảy ra tại công trường là một phần của công việc.

Tin này cũng nói thẳng: robot không biết nói, nên hễ thấy bạn đứng cạnh robot là người ta sẽ tới hỏi chuyện.

Có thể bạn sẽ chẳng bao giờ làm việc với gạch và vữa. Nhưng nếu việc của bạn là deploy phần mềm vào môi trường thật của khách hàng, bạn sẽ gặp đúng hai việc này cùng lúc: tìm ra lỗi khi đang bị áp lực, và giúp người đang đứng chờ hiểu chuyện gì đang xảy ra. Phần dưới đây hướng dẫn cách làm cả hai.

Vì sao debug ở hiện trường khó hơn debug trên máy mình?

Ở văn phòng, khi hệ thống hỏng, bạn thường có log đầy đủ, có thời gian và có thể chạy lại bao nhiêu lần cũng được. Ra công trường, những thứ đó eo hẹp hơn hẳn: người ta đang đứng chờ, và mỗi lần chạy lại là một lần bức tường đứng yên. Monumental mô tả FDRE là người lo trọn phần kỹ thuật của deployment, từ đầu đến cuối.

Lo trọn không có nghĩa là không được nhờ ai. Nhưng khi robot dừng ngay trước mặt, người dẫn dắt việc tìm lỗi tại chỗ là bạn.

Mô hình kinh doanh khiến áp lực còn lớn hơn. Theo ioplus.nl, Monumental không bán robot mà bán những bức tường đã xây xong, và mỗi công trường do một đội nhỏ gồm ba robot đảm nhận.

Các robot phối hợp với nhau để chở gạch và vữa. Khách hàng trả tiền cho bức tường, nên trong mắt họ, một con robot đứng im nghĩa là bức tường đang chậm tiến độ.

Thêm nữa, một sự cố trên công trường có thể nằm ở mặt đất, ở vật liệu, ở cảm biến, chứ không chỉ ở phần mềm. Cái bẫy nằm ở chỗ đội kỹ sư của Monumental, theo lời CEO công ty, nghiêng hẳn về phần mềm, khoảng ba người phần mềm cho một người phần cứng.

Người quen viết code thường nghi code trước, và đó chính là lỗi thứ tư trong danh sách ở cuối bài. Có lẽ vì vậy mà tin tuyển dụng đòi hỏi bạn phải rất giỏi debug và chia nhỏ vấn đề.

Giữ manh mối trước, chia sự cố thành ba lớp sau

Nguyên tắc cốt lõi rất đơn giản: đừng vội kết luận là lỗi code, và đừng động vào máy khi chưa giữ lại manh mối. Bước đầu tiên là mô tả triệu chứng bằng những gì nhìn thấy được ngoài đời.

Với con robot dừng ở hàng gạch thứ năm, một bản ghi triệu chứng tốt sẽ trông thế này: “Robot B dừng khi đang đặt viên thứ 12 của hàng 5, bức tường phía bắc; hai robot còn lại vẫn chạy; mười phút trước đó có một xe đẩy vật liệu đỗ cạnh ray”.

Bước thứ hai là lưu bằng chứng. Phản xạ hay gặp nhất là bấm khởi động lại cho máy chạy tiếp, và đôi khi đó đúng là cách gỡ tạm cần làm. Nhưng trước khi bấm, hãy chụp ảnh khu vực, lưu log và trạng thái cảm biến, ghi lại thời điểm.

Một lỗi không tái hiện được sau khi restart thường sẽ quay lại đúng vào hôm bạn không có mặt ở công trường. Chỉ khi đã giữ được manh mối, bạn mới bắt đầu tách sự cố thành ba lớp.

Lớp môi trường gồm mặt bằng, thời tiết, vật liệu và những thứ con người đặt vào khu vực làm việc. Lớp phần cứng gồm cảm biến, cơ cấu chấp hành và nguồn điện. Lớp phần mềm gồm định vị, lập kế hoạch và phối hợp giữa các robot.

Chỉ riêng câu mô tả triệu chứng ở trên đã gợi ra ba giả thuyết thuộc ba lớp khác nhau, và mỗi giả thuyết cần một phép thử riêng. Việc hai robot kia vẫn chạy là manh mối quan trọng.

Nếu phần mềm điều phối bị lỗi chung, nhiều khả năng cả đội sẽ cùng bị ảnh hưởng. Khi chỉ một con dừng, hãy xem trước điều gì khác biệt quanh nó: chiếc xe đẩy, cảm biến của riêng nó, hay vị trí nó đang đứng trên bức tường.

Nói chuyện với đốc công: trả lời về bức tường, không về con robot

Trong lúc bạn kiểm tra giả thuyết, người đốc công vẫn đứng đó. Monumental coi FDRE là gương mặt và đại sứ của công ty tại công trường. Đốc công không cần biết planner hay cảm biến nào lỗi. Họ cần biết ba điều: bức tường có kịp không, có an toàn không, và họ có phải làm gì không.

Dưới đây là một đoạn hội thoại mẫu để bạn tự luyện:

Đốc công: Nó hỏng à? Hôm nay có xong bức tường phía bắc không?

FDE: Một con dừng, hai con kia vẫn đang xây. Em đang kiểm tra xem có phải do chiếc xe đẩy đỗ sát quá không. Anh cho người dời xe ra khoảng hai mét giúp em. Mười lăm phút nữa em báo anh là chạy lại được hay phải chuyển phần việc sang con khác.

Câu trả lời đó nói về bức tường trước, về robot sau. Nó nhờ người ta một việc cụ thể và hẹn một mốc báo lại mà bạn giữ được. Nó cũng không hứa “xong ngay”, vì bạn chưa biết nguyên nhân.

Từ một robot sang cả đội: vòng lặp tính bằng giờ

Tìm ra nguyên nhân mới xong một nửa. Theo mô tả của Monumental, bản sửa được deploy và thử trên một robot trước, sau đó mới đưa ra toàn bộ đội robot, theo những vòng lặp tính bằng giờ và ngày chứ không phải tuần.

Vì vậy, ngay tại công trường, bạn phải phân biệt được hai thứ: cách gỡ tạm để bức tường hôm nay vẫn được xây, và bản sửa thật sẽ chạy trên mọi robot.

Trong ví dụ này, cách gỡ tạm là dời xe đẩy rồi chạy tiếp. Bản sửa thật có thể là giúp robot nhận biết vật cản tốt hơn, hoặc thêm một bước kiểm tra khu vực vào quy trình mỗi sáng. Phương án nào cũng phải được thử trên một con trước.

Làm như vậy, những gì bạn học được ở công trường này sẽ trở thành mặc định cho công trường sau. Đó cũng là mục tiêu mà một FDRE viết trên Substack của công ty: bảo đảm năng lực kỹ thuật đã sẵn sàng trước các đợt deployment sắp tới.

Những lỗi người mới hay mắc

Lỗi đầu tiên là cắm mặt vào laptop và im lặng. Robot không tự giải thích được, nên nếu bạn cũng im, người xung quanh sẽ tự đoán, và thường đoán theo hướng xấu nhất. Lỗi thứ hai là hứa một mốc thời gian khi chưa khoanh được vùng lỗi.

Lỗi thứ ba là sửa cho riêng công trường này rồi thôi, không đưa bài học vào bản dùng chung cho cả đội. Lỗi thứ tư là mặc định nguyên nhân nằm ở phần mềm chỉ vì đó là lớp bạn quen nhất.

Cũng đừng coi nhẹ phần hậu cần: tin tuyển dụng nói trước rằng bạn sẽ thường xuyên phải dậy sớm lái xe tới công trường cho kịp giờ, và phải thật sự thích làm việc trong môi trường đó.

Đưa kỹ năng này vào hồ sơ của bạn

Khi đọc mô tả công việc, hãy để ý những cụm như “debugging failures on-site”, “face of the company” hay “decomposing problems”. Chúng cho thấy vị trí đó cần cả năng lực kỹ thuật lẫn khả năng làm việc với người ở hiện trường.

Trong CV, đừng chỉ ghi chung chung “debug hệ thống production”. Hãy viết theo trình tự: triệu chứng nhìn thấy được, lớp chứa nguyên nhân, cách gỡ tạm, và bản sửa đã được rollout tới đâu.

Chưa từng ra công trường, bạn vẫn có thể luyện kỹ năng này. Lần tới khi có sự cố production, hãy viết bản cập nhật cho người phía business trước khi viết post-mortem kỹ thuật, gồm đúng ba dòng:

Ảnh hưởng: việc của anh/chị đang chậm hay dừng ở đâu.

Cần anh/chị làm: một việc cụ thể, hoặc “chưa cần làm gì”.

Báo lại lúc: một mốc giờ bạn chắc chắn giữ được.

Máy không tự giải thích được, nên người đứng cạnh nó phải làm thay.