Một lần tập vẽ (case study)

Thỉnh thoảng hoặc thường xuyên, một BrSE không chỉ cần đối ứng các công việc dự án mà còn phải đóng nhiều vai trò khác như Giải thích lại Spec cho user, tiến hành các loại Rà soát kỹ thuật/ phi kỹ thuật theo yêu cầu quản lý hay Tư vấn kỹ thuật cho khách hàng … Câu chuyện tôi chia sẻ lần này bắt đầu từ một tình huống có thật như thế.

I. Tình huống

Một lần, bên phía VN nhận được yêu cầu từ một bạn Dev. ở công ty khách hàng bên Nhật, nhờ phía VN tư vấn giúp về việc quản lý thông tin credential như thế nào cho chuẩn chỉnh. Khách hàng không có chuyên môn về IT và bạn Dev. này cũng không có nhiều kinh nghiệm. Vụ tư vấn này chẳng liên quan gì đến công việc hay hợp đồng hiện tại nào, tuy nhiên tiện có mối quan hệ thì phía Nhật cứ hỏi thôi 🙂.

Đại loại bối cảnh và yêu cầu tư vấn được gửi qua phía VN như sau:

Hiện tại bên Nhật đang hard code các thông tin credential (id và secret) trong file config. py. File này được đặt trên Gitlab repository và được phân quyền access.

Phía Nhật muốn có phương án quản lý credential tốt hơn, đảm bảo

• Engineer không cần biết credential vẫn có thể code và vận hành được
• Nhân viên hợp đồng không được biết credential
• Khi thay đổi credential thì chỉ phải sửa code ít nhất có thể
• Code sẽ lấy giá trị credential từ biến môi trường (env. variable) lúc runtime

II. Trao đổi tư vấn cụ thể

Sau khi nhận được yêu cầu tư vấn nói trên, BrSE phụ trách đã hỏi ý kiến bộ phận Infra và được gợi ý đề xuất phương án mà phía VN đã tiến hành triển khai thực tế có hiệu quả cho bản thân mình với 2 điểm chủ yếu sau:

a. Áp dụng mô hình CICD dùng Gitlab runner, trên cơ sở đó

b. Quản lý credential với Gitlab variable hoặc Vault

Vì tài liệu cho b. đã được Infra tạo sẵn nên BrSE chuyển ngữ và giới thiệu nội dung đó cho bạn Dev. bên Nhật.

Tuy nhiên, mặc dù được share tài liệu nhưng khoảng 2 tuần sau bạn Dev. bên Nhật lại hỏi tiếp những thao tác khá cơ bản như cách tạo gitlab variable, cách lấy giá trị từ gitlab variable bằng code, tuần tiếp sau lại hỏi code với Vault thế nào…. Phía VN lại phải tạo code sample trên gitlab và share để bạn tham khảo.

Đã cung cấp nhiều thông tin, cung cấp cả code tham khảo như vậy nhưng rốt cục gần 1 tháng sau bạn Dev. trên vẫn loay hoay và xin họp online để được hướng dẫn trực tiếp. Lúc đầu là bạn xin tư vấn về một vấn đề cụ thể nhưng thực chất cuối cùng có vẻ bạn cần hướng dẫn tổng thể mọi thứ, bao gồm chia directory trong repo Gitlab thế nào, code file gitlab-ci.yml ra sao, tạo Docker image, config connection, thiết lập giá trị cho biến môi trường của production server bằng script ra sao …… Sau một hai lần họp hướng dẫn trực tiếp online nữa cho bạn thì vụ việc mới có thể kết thúc.

Nhìn lại, xuất phát từ một yêu cầu tư vấn nghe có vẻ đơn giản ban đầu, thực tế đã phát sinh tổng cộng hơn 50 trao đổi nội bộ phía VN cùng một lượng đáng kể trao đổi với bên Nhật, trải qua gần 1 tháng. Trừ hai buổi họp online thì các trao đổi này chủ yếu bằng text.

III. Tổng hợp

Cũng trong thời gian diễn ra vụ tư vấn trên, tôi có ý định tập hợp các tình huống trao đổi thực tế với khách hàng để làm tài liệu case study tham khảo cho nhóm BrSE, nhất là các tình huống hàm chứa nhiêu nội dung kỹ thuật. Nhận thấy tính phù hợp, tôi quyết định lựa chọn tình huống này. Tuy nhiên, để đưa tình huống thành case study, tiếp theo tôi cần tạo thêm tài liệu tóm tắt cho tình huống.

Với mục đích đó, tôi đã dành vài tiếng tự mình review toàn bộ hơn 50 trao đổi nội bộ của tình huống sau đó tạo bản tóm tắt lại các điểm chính của phương án mà phía VN đã đề xuất như sau:

. Store credential vào Gitlab variable

. Source code vẫn sẽ lưu ở Gitlab repository

. Source code (được deploy lên Production) sẽ lấy giá trị credential từ biến môi trường (env. variable) lúc runtime

. Sau khi deploy, Gitlab runner sẽ chạy script để lấy giá trị credential từ Gitlab variable và set vào biến môi trường của môi trường Production

. Khi phát triển trên local, Dev. có thể lấy giá trị credential từ Gitlab variable qua API để sử dụng

So với hơn 50 trao đổi nội bộ ban đầu thì bản tóm tắt gồm 5 ý trên cũng đã khá cô đọng rồi. Tuy nhiên dù vậy bản tóm tắt “toàn chữ” trên cũng vẫn sẽ là một thử thách với các bạn BrSE xuất thân nonIT, vì thế, tôi đầu tư thêm một bước để có thể truyền đạt dễ hiểu hơn nữa tới các bạn.

IV. Sơ đồ hoá

Nhiệm vụ đặt ra ở đây là cần có một sơ đồ mà nhìn vào người ta có thể hình dung được dễ dàng đoạn tóm tắt 5 ý ở trên. Để vẽ sơ đồ này, ta sẽ phải quyết định ta có các khối hình nào và liên hệ giữa chúng ra sao.

Việc quyết định các khối hình là quan trọng nhất vì sau khi đã quyết định được rồi ta có thể dựa vào bản tóm tắt ta đã có để thể hiện các thông tin được lưu chuyển giữa chúng.

Để làm việc này, ta có thể bắt đầu từ việc phân tích văn bản. Đơn giản nhất là đầu tiên ta bôi đậm các danh từ quan trọng trong từng ý của bản tóm tắt:

. Store credential vào Gitlab variable

. Source code vẫn sẽ lưu ở Gitlab repository

. Source code (được deploy lên Production env.) sẽ lấy giá trị credential từ biến môi trường (env. variable) lúc runtime

. Sau khi deploy, Gitlab runner sẽ chạy script để lấy giá trị credential từ Gitlab variable và set vào biến môi trường của môi trường Production

. Khi phát triển trên local, Dev. có thể lấy giá trị credential từ Gitlab variable qua API để sử dụng

Sau đó, chỉ cần loại bỏ các từ trùng lặp là ta còn lại một tập hợp gồm 5 thứ:

. Gitlab variable

. Gitlab repository

. Production env.

. Gitlab runner

. local

Cứ đưa 5 thứ trên thành 5 khối hình và vẽ thử, nếu thấy chưa ưng ta có thể thêm hoặc bớt các khối hình sau đó. Sửa xong rồi ta có thể đem sơ đồ ta đang có đi xác nhận lại với những người thực sự tham gia vào tình huống: BrSE phụ trách tình huống, Infra team đã tư vấn/ tạo sample code cho tình huống, xin nhận xét và hoàn thiện tiếp..….

Và đây là kết quả thu được sau một quá trình như vậy:

Và thế là giờ ta đã có một case study với:

. Một sơ đồ mô tả trực quan

. Một bản tóm tắt những điểm quan trọng