Series gồm 3 phần:

• Phần 1: Làm Junior developer tại FPT Software và Aswig Solution
• Phần 2: Làm Full-stack developer tại Lancaster ISS (UK)
• Phần 3: Làm Senior Front-end Engineer tại Algomerchant Singapore

 

Ở 2 phần trước, các bạn đã nghe mình chia sẻ về những sai lầm mình mắc phải khi mới ra trường, làm việc ở Fsoft và Aswig; khi qua UK, làm việc cho phòng IT của ĐH Lancaster.

Ở phần cuối cùng trong series, mình sẽ kể về những sai lầm của mình ở vị trí hiện tại – Senior Front-end Engineer tại Algomerchant nha.

Phần này sẽ có vài đoạn bi đát và lâm ly gay cấn hơn 2 phần đầu nhiều nhe!

Senior Front-end Engineer tại Algomerchant – Trách nhiệm to, sai lầm bự

Đây là giai đoạn mình được giao nhiều trách nhiệm nhất, cũng là giai đoạn mình … phạm nhiều sai lầm to bự nhất. Đơn giản là do mình làm công ty startup về fintenh:

• Làm Startup đồng nghĩa với việc sản phẩm và công nghệ thay đổi nhanh chóng, trọng trách mà mình phải gánh vác nhiều hơn, dễ sai lầm hơn.
• Làm về fintech, về tiền bạc và stock đồng nghĩa với việc lỗi lầm của bạn sẽ gây ra thiệt hại nặng nề hơn cho công ty, cho người dùng.

 

Về dự án

Do công ty ít người, mỗi thành viên phải ôm luôn 1 dự án/sản phẩm (hoặc luân phiên 2,3 dự án).

Hệ thống mình làm mang tên Auto Invest, gồm một Trading Engine và một ứng dụng desktop làm bằng Electron + AngularJS, có thể thực hiện mua bán stock hoàn toàn tự động để … kiến tiền cho người dùng.

Ở startup nên các bạn làm ăn nhanh gọn rẹt rẹt! Mình vào công ty vào cuối tháng 8. Đến giữa tháng 9 thằng CTO bảo: Mày làm prototype thử cái ứng dụng trading xem?

Sau 2 tháng, vừa làm vừa sửa đổi requirement, vừa test, vừa lấy feedback từ người dùng, phiên bản đầu tiên cũng … tạm xong. Team sales liền lập tức làm event sản phẩm cho người dùng, thu phí tận 50$/tháng.

Đợt đấy, mình còn hỏi anh CTO: Ê prototype mới làm 2 tháng mà cũng đem đi bán hả, thu tiền mắc vl nữa??

Ảnh nhún vai trả lời: Ờ, startup nó vậy đó!

À quên, kể tiếp về các sai lầm … chết người mà mình gây ra nha!!

1. Bom xịt hôm đầu tiên

Ngay sau hôm dụ dỗ bán cho người dùng, hệ thống bắt đầu được đưa vào hoạt động. Hôm đầu tiên, hơn 60% khách hàng nhận tín hiệu nhưng hệ thống không mua không bán gì sất!

Trong khi team customer support nháo nhào lên, mình bình tĩnh bắt đầu tìm lỗi. Cũng may hệ thống có logging đầy đủ, mình tra ra được nguyên nhân.

Hóa ra là do khách hàng chưa bật permission để mua bán stock US. (Permisison này thuộc về account do stock broker cung cấp, không nằm trong hệ thống tụi mình)

Bấy lây nay, cả công ty khi test test chỉ dùng account công ty, đã có permisison này bật sẵn. Khi khách hàng đăng kí account mới, họ phải chọn thì permission này mới bật!

Team customer support nhanh chóng liên hệ để hướng dẫn khách hàng. Ngay chiều hôm đó, hệ thống lại hoạt động bình thường!

 

2. Bán ngược cổ phiếu

Trong hệ thống có 1 logic đặc biệt là: Nếu cuối ngày còn stock ABC này thì phải bán hết, không được để lại qua hôm sau. Ví dụ bạn giữ 20 stock (LONG) thì tới buổi chiều, hệ thống phải bán sạch (liquidate) 20 stock đó.

Mình sử dụng 1 thư viện hẹn giờ của NodeJS tên node-schedule. Sau khi test thử thấy chạy ok, mình update hệ thống, thêm logic đó cho người dùng.

Thế nhưng, thư viện này bị bug ngầm là … lâu lâu nó sẽ chạy một hàm 2 lần vào lúc được hẹn. Thế là thay vì bán 20 cổ phiếu 1 lần, hệ thống bán 20 cổ phiếu 2 lần, tức là người dùng … mượn 20 cổ phiếu (người ta gọi là SHORT stock).

Đến cuối ngày, cả team ngồi monitor hệ thống thì giật mình vì phát hiện có 1 khách hàng đang … mượn 20 cổ phiếu. Mình lại ngồi check đống logging thần thánh, phát hiện được bug của thư viện đó.

May mắn là bug này xuất hiện ngẫu nhiên, không xuất hiện lúc test, các khách hàng còn lại không bị ảnh hưởng. Team tụi mình phải phát tín hiệu để hệ thống mua lại 20 cổ phiếu đó, sau đó liên hệ giải thích và xin lỗi khách hàng.

Bài học rút ra: Đừng quá tin tưởng những thư viện trên mạng, hãy chịu khó xem các bug của nó. Với các hệ thống quan trọng, cần bỏ thêm thời gian để test thử.

 

3. Nâng cấp version làm mất sạch dữ liệu local

Một lần nọ, mình cần thêm chức năng vào hệ thống, tích hợp API của stocke broker khác. API của các bạn này hơi sida, không thể dùng http request của Chromium trong Electron được vì sai header, mà phải dùng http request của NodeJS.

Sau khi code xong, chạy được 5 phút thì chương trình … crash. Google lỗi một hồi thì hóa ra http request của NodeJS trong phiên bản Electron đang dùng bị lỗi.

Sửa cũng khá đơn giản, chỉ việc downgrade bản Electron xuống là xong. (Do lúc đó dự án đang dùng bản mới nhất nên không upgrade lên được).

 

Sau khi chạy thử và test kĩ, mình bắt đầu release dần đến máy khách hàng. Mình vừa xách đít đi về, ăn tối gần đó thì chợt nhận được một cú điện thoại động trời từ phía CTO, dữ liệu local của toàn bộ người dùng mất sạch.

Mình vội vàng quay lại công ty, kiểm tra lại thì thấy … dữ liệu người dùng mất sạch thật!! Nguyên nhân là do khi downgrade, bản Chromium cũ không đọc được dữ liệu trong localstorage của Chromium mới, nên clear sạch toàn bộ localstorage luôn.

May mắn thay, do phải monitor người dùng nên app của mình lưu trữ dữ liệu người dùng ở local lẫn Firebase (để team tiện monitor). Mình cắm mặt vào viết code để migrate dữ liệu từ Firebase về máy người dùng.

Mọi việc hoàn tất vào lúc 8h30, 1 tiếng trước khi sàn chứng khoán Mĩ mở cửa. Mình và anh CTO thở phào nhẹ nhõm. Mình vác cặp ra khỏi công ty, bắt taxi về nhà (Về trễ được claim lại tiền taxi).

Bài học rút ra: Khi thay đổi bất kì thư viện, framework cũng nên … rất rất cẩn trọng. Những dữ liệu quan trọng nên được sao lưu, backup ở nhiều chỗ để tiện khôi phục lại.

 

4. Một dòng code xóa sạch server trên staging

Sai lầm cuối cùng trong series là một sai lầm … thật như đùa, khiến mình dở khóc dở cười, nhưng cũng làm mình và anh CTO mất nguyên buổi chiều để khắc phục.

Chuyện là, trước giờ mình có dùng Azure Fluent API để quản lý các service, tạo thêm máy ảo (virtual machine) trên Azure. Trước giờ hệ thống chạy khá ổn.

Thế nhưng, khi mình migrate một số code (do mình viết hồi xưa) từ service này qua service kia, mình có sửa một dòng code trong Deployment Mode của Azure (để chạy thử) từ Incremental Mode sang Complete Mode.

• Incremental Mode (default) sẽ thêm một máy áo một khi chạy code
• Complete Mode sẽ clear sạch toàn bộ máy ảo, chỉ để lại một máy ảo mình thiết lập trong code

Khổ nỗi, mình lại không chịu đọc document trước khi sửa code. Thường thì mình chạy code, chờ khoảng 15 phút thì Azure sẽ tạo xong Virtual Machine. Lần này, chờ 30 phút mà code vẫn chưa chạy xong.

Mình vội dừng code, lên Azure kiểm tra thì… ôi thôi, toàn bộ server và VM trên môi trường Staging (để test) đã bay sạch.

Hoảng hồn, mình vội hú anh CTO để restore lại hệ thống. Nhưng dữ liệu back-up cũng bị … xóa sạch luôn. Gọi điện cho Azure nhờ họ restore lại cũng không cứu giúp được gì!! Mình và anh CTO đành phải tạo lại service và VM trên Staging, sau đó cài đặt lại.

Cũng may là sai lầm này chỉ xảy ra trên môi trường Staging, không ảnh hưởng tới người dùng. Trước đó 1 tháng, anh COO còn chạy nhầm script xóa sạch file trên reverse proxy của production, làm người dùng không vào được web luôn cơ!

Bài học rút ra: Đôi khi có những thay đổi rất nhỏ, nhưng lại gây ra những hậu qua cực kỳ thảm khốc. Bài học tương tự như trên, nên backup dữ liệu thường xuyên hơn.

Văn hóa mắc lỗi

Trái ngược với team mình ở FPT Software, khi có vấn đề, mọi người sẽ lùng sục tìm bằng được thủ phạm để … đổ lỗi, bắt chịu trách nhiệm! Ở công ty của mình, khi ai phạm phải sai lầm gì đó, team không hề trách móc hay truy lùng thủ phạm.

Khi có vấn đề hay có lỗi, điều quan trọng là tìm hiểu nguyên nhân gây ra vấn đề, sau đó sửa chữa hệ thống đó, đặt ra qui trình để tránh gặp phải vấn đề tương tự trong tương lại. Do đó, mình cảm thấy khá thoải mái khi làm việc cũng như khi mắc lỗi.

Nhân vô thập toàn, ai cũng có lúc mắc lỗi. Chúng ta nên tập trung vào vấn đề, chứ đừng nên tập trung vào con người nhé!

Vài lời cuối

Nghĩ đi nghĩ lại, từ lúc đi làm tới giờ mình cũng mắc phải một đống sai lầm đấy chứ nhỉ? Viết tới tận 3 bài viết mới hết là các bạn thấy rồi!

Sai lầm thì đương nhiên là … không có gì đáng để tự hào. Tuy vậy, mình rất trân trọng những sai lầm này, vì sau mỗi sai lầm mình đều học được cái gì đó, trở nên giỏi hơn, giúp mình trưởng thành.

Do vậy, nếu trong quá trình làm việc, các bạn có … lỡ mắc phải sai lầm to hay nhỏ gì thì cũng đừng lo nhé! Hãy coi đó là một cột mốc cho sự trưởng thành của mình thôi.

Hãy kiếm một môi trường nơi bạn có thể mắc lỗi mà không sợ bị chỉ trích. Bạn sẽ học được nhiều hơn, nhanh trưởng thành hơn.

 

Còn bạn thì sao? Đừng ngại ngần gì hết, cứ chia sẻ những lỗi lầm mình từng gặp khi đi làm nhé 😀