Khởi đầu một năm mới, vấn đề mà dễ gặp hơn bao giờ hết và gần như chúng ta sẽ đều gặp phải đó là trong bất kỳ team kỹ thuật nào, tôi thấy thường có những mẹo nhỏ nhưng cực kỳ quan trọng, ví dụ như: từ việc deploy ở đâu, xin quyền thế nào, cho đến cách nhìn log khi pipeline báo lỗi,… Những thứ này đa phần chỉ nằm trong đầu một vài anh em làm lâu năm trong dự án.

Việc anh em hỏi cho nhanh là điều hết sức hợp lý và bản thân tôi trước đây khi chưa quản lý team cũng vậy, lúc gấp cứ hỏi người biết rõ nhất cho xong việc.

Nhưng nếu cùng một câu hỏi cứ quay lại đều đặn, tôi nghĩ đó là lúc mình nên dừng lại một chút. Không phải để trách móc ai, mà để tìm cách sao cho lần sau gặp lại, anh em có thể tự xử lý được mà không cần phải tìm đúng một người duy nhất.

Tôi nghĩ là việc nào cứ phải đợi đúng một người mới làm được, thì sớm muộn gì chính chúng ta cũng đang tự làm khó mình.

Sự phụ thuộc không đáng có

Tôi không thấy việc hỏi là vấn đề, nhưng sẽ là vấn đề nếu cùng một câu hỏi quay lại lần thứ hai, thứ ba mà cách xử lý vẫn y như cũ. Lúc đó, team bắt đầu hình thành thói quen phụ thuộc.

Các lỗi liên quan đến pipeline là ví dụ điển hình. Chúng thường lặp lại theo chu kỳ và cách xử lý cũng lặp lại y chang. Tôi nhớ có lần gần giờ release, pipeline bỗng nhiên báo lỗi. Không phải lỗi code, mà do không kéo được image từ registry. Giữa đống log dài dằng dặc, anh em mới nhìn vào rất dễ hoa mắt.

Lúc đó, một bạn ping người hay xử lý CI. Người đó mất vài phút để chốt lỗi: token registry hết hạn. Sau khi rotate token và cập nhật secret, mọi thứ hoạt động trở lại. Nếu mọi chuyện chỉ dừng ở đó, vài tuần sau token lại hết hạn, pipeline lại đỏ và anh em lại phải đi tìm đúng người đó để nhờ vả. Trong khi thứ thực sự cần chia sẻ chỉ là một mẩu ghi chú ngắn:

• Dấu hiệu trong log thường thấy khi token hết hạn (unauthorized hoặc denied).
• Chỗ để rotate token.
• Tên secret cần cập nhật và môi trường tương ứng để tránh nhầm lẫn.
• Job cần rerun và dấu hiệu để biết mọi thứ đã ổn.

Chỉ cần 5~10 dòng ghi chú thực tế như vậy là đủ để lần sau bất kỳ ai trong team cũng có thể tự giải quyết.

Chia sẻ để nhàn hơn chứ không phải viết tài liệu cho có

Chắc là không mấy ai thích việc ngồi viết tài liệu dài dằng dặc theo đúng quy trình, vì thực tế ai cũng bận và tài liệu dài thì lúc gấp chẳng ai muốn đọc. Cách tôi hay làm là để lại những ghi chú ngắn đủ dùng. Đúng theo quy tắc 80/20 mà anh em vẫn biết.

Chỉ cần anh em chú ý những câu hỏi bị lặp lại đến lần thứ 2-3, tôi sẽ ghi lại ngay:

• Dấu hiệu thường nằm ở đâu.
• Bước đầu tiên cần kiểm tra là gì.
• Nếu đúng bệnh thì xử lý ở đâu.
• Xong thì kiểm tra lại bằng cách nào.

Tôi không cố viết từ A đến Z, mà chỉ tập trung vào đúng những đoạn anh em hay vấp. Ví dụ như ai cũng biết chạy lệnh rerun, nhưng hay không biết rerun job nào là đúng, ai cũng biết cập nhật secret nhưng hay nhầm namespace. Ghi đúng những điểm kẹt đó là đủ.

Hãy để anh em cùng làm

Ghi chú dù tốt đến đâu nhưng nếu tôi vẫn trực tiếp nhảy vào làm cho nhanh thì kiến thức vẫn nằm lại trong đầu tôi. Anh em sẽ vẫn quen hỏi, còn tôi thì mãi bận rộn với những việc lặp lại. Cách tôi thấy hiệu quả nhất là thay đổi vai trò:

• Lần đầu tôi làm, nhưng vừa làm vừa giải thích rõ chỗ nào dễ sai và lý do tại sao làm vậy.
• Lần sau để anh em làm, tôi ngồi cạnh quan sát và chỉ nhắc đúng chỗ dễ vấp, tuyệt đối không giành chuột.
• Lần thứ ba để anh em tự làm hoàn toàn và tôi chỉ kiểm tra kết quả cuối.

Khi thực hiện như vậy, team tự nhiên có thêm người gánh vác được việc, và đó mới là lúc sự phụ thuộc thực sự giảm bớt.

Nâng cấp lên những buổi chia sẻ ngắn

Với những ca khó về tư duy hay luồng hệ thống lằng nhằng, nhiều khi viết note vẫn chưa tải hết được vấn đề. Những lúc đó, tôi thường rủ anh em họp nhanh tầm 15 phút. Thay vì tốn sức làm slide, tôi cứ share màn hình rồi code hoặc debug trực tiếp để anh em dễ ngấm mạch xử lý hơn.

Tôi luôn giữ thói quen quay màn hình lại để làm tư liệu. Sau này có người mới vào hoặc ai lỡ quên, tôi chỉ cần coi video là xong, khỏi tốn công giải thích lại từ đầu. Với tôi, đây là cách đóng gói kinh nghiệm hiệu quả nhất để mình không còn bị kẹt vào những câu hỏi lặp đi lặp lại.

Chia sẻ có làm mất giá trị?

Đôi khi anh em cũng hay có tư duy tuyến tính và thấy lo ngại rằng nếu chia sẻ bí kíp, mình sẽ không còn quan trọng hoặc dễ bị thay thế. Nhưng trải nghiệm thực tế cho tôi thấy điều ngược lại.

Khi giải phóng bản thân khỏi những việc vụn vặt và lặp lại, tôi mới có thời gian để tập trung vào những bài toán khó hơn, nghiên cứu những công nghệ mới hơn, nâng cấp cải thiện hạ tầng và quản trị tốt hơn. Giá trị của mình không nằm ở việc nhớ một vài việc lặp đi lặp lại, mà nằm ở khả năng xây dựng hệ thống và dẫn dắt anh em cùng phát triển. Khi mình giúp cả team mạnh lên, vị thế của mình thực tế còn được nâng cao hơn nhiều so với việc chỉ là một người đi sửa lỗi vặt.

Kết

Giữ bí kíp trong đầu không phải xấu. Ai cũng vậy thôi. Nhưng nếu cái gì cũng giữ trong đầu, team sẽ quen dựa vào một người, công việc chậm đi, và người bị dựa thì sẽ rất mệt. Nếu anh em muốn thay đổi ngay, tôi gợi ý một câu hỏi rất đơn giản: Trong team mình, thứ gì đang bị hỏi lại nhiều nhất?

Mong bài chia sẻ sẽ giúp cho anh em sắp, đã và đang quản lý team hiệu quả hơn để tự giúp chính mình. Và mong rằng sẽ ngày càng có nhiều bạn thích chia sẻ kinh nghiệm tới cộng đồng để chúng ta cùng trao đổi phát triển và giúp đỡ các thế hệ đi trước…