DevOps

Tôi vào nghề với một niềm tin giản dị: code tốt là đủ. Viết clean code, close ticket đúng deadline, không để bug lên production — vậy là một dev giỏi. Hơn năm năm đi làm, tôi dần trở thành người được giao task khó nhất team. Rồi đến lúc tôi nhảy vào một dự án Fintech.Tuần đầu tiên tưởng bình thường. CRUD vẫn là CRUD. API vẫn là API. Nhưng rồi có một buổi chiều, PM hỏi: "Nếu hệ thống xử lý sai số tiền của người dùng, chuyện gì xảy ra?"Tôi định trả lời theo kiểu dev: "Thì mình log lỗi rồi rollback." Nhưng nhìn khuôn mặt mọi người trong phòng — tôi hiểu câu hỏi đó không phải về technical.Trong Fintech, bug không phải là lỗi phần mềm. Bug là ai đó mất tiền thật.Từ "viết code chạy được" đến "viết code đáng tin"Dev 5 năm dạy tôi nhiều thứ: clean architecture, performance, CI/CD pipeline. Nhưng có một thứ tôi chưa từng nghĩ tới — chi phí của sự sai lầm.Trong các project trước, nếu UI hiển thị sai giá sản phẩm, user reload lại là xong. Còn khi số dư tài khoản hiển thị sai vì một race condition không ai kiểm tra — không có chuyện "reload lại là xong".Tôi bắt đầu đọc lại codebase không phải để hiểu logic làm gì, mà để hỏi: cái này sai được không? Nếu sai, sai đến đâu?Ba câu hỏi tôi học được cách đặt ra mỗi ngày:Nếu request này chạy 2 lần cùng lúc thì sao? — Idempotency không còn là khái niệm học thuật, đó là thứ phải code mỗi ngày.Khi nào transaction thực sự "xong"? — Eventual consistency đẹp trên giấy. Trong Fintech, bạn phải biết chính xác moment nào tiền "an toàn".Ai có thể xem dữ liệu này? — Authorization không chỉ là middleware. Đó là kiến trúc, là audit log, là compliance.Cái tôi tưởng là thừa, hoá ra là thiếu5 năm làm full-stack, tôi quen move fast. Nhưng Fintech dạy tôi một bài học kỳ lạ: đôi khi đi chậm mới là tạo ra value thật.Có lần tôi propose một feature tưởng là "quick win" — cho phép user xem lịch sử giao dịch real-time. Tôi tự tin lắm: websocket, 2 ngày là xong.Nhưng senior trong team hỏi: Audit log ở đâu? Nếu user dispute giao dịch, mình chứng minh bằng gì? Hệ thống fraud detection có nhận được event này không?Tôi ngồi im. Hai ngày của tôi hóa thành hai tuần — và feature đó tốt hơn rất nhiều."Làm nhiều hơn task" không phải là code thêm tính năng. Đó là hiểu tại sao task đó tồn tại — rồi làm cho mục đích đó được phục vụ thật sự.Khi dev học nói chuyện với người không biết codeMột trong những thay đổi lớn nhất không liên quan đến keyboard. Đó là học cách giải thích.Trong Fintech, quyết định kỹ thuật ảnh hưởng đến compliance, đến risk, đến tiền thật. Bạn không thể chỉ nói "tôi dùng optimistic locking để handle concurrent write" rồi kết thúc. Bạn phải nói được: "Nếu không có cơ chế này, hai người có thể rút cùng một số tiền lúc 3 giờ sáng và cả hai đều thành công."Kỹ năng dịch technical sang business impact — không ai dạy trong trường. Tôi học được từ những buổi họp awkward, từ những lần bị hỏi ngược mà không trả lời được.Công thức tôi đang tập dùng: [Quyết định kỹ thuật] giúp/ngăn chặn [điều gì xảy ra với người dùng], điều mà nếu không có sẽ gây ra [hậu quả cụ thể].Dấu ấn không nằm ở số dòng codeLần đầu tiên tôi cảm thấy mình thật sự tạo ra giá trị — không phải khi ship một feature phức tạp. Mà là lúc tôi ngồi cùng đội fraud analyst, lắng nghe họ mô tả workflow thủ công làm mỗi buổi sáng, rồi nói: "Mình có thể tự động hoá bước này."Feature đó chỉ tốn 3 ngày code. Nhưng để biết cần làm gì, tôi mất 2 tuần ngồi hiểu bài toán. Đó là thứ 5 năm trước tôi sẽ không làm — vì "đó không phải task của tôi".Fintech không cần thêm người viết code. Fintech cần người hiểu rằng code là phương tiện, không phải đích đến.Hành trình từ "dev hoàn thành task" đến "người tạo ra dấu ấn" bắt đầu bằng một câu hỏi rất đơn giản: Tại sao cái này quan trọng?Khi bạn có câu trả lời cho câu hỏi đó — mọi dòng code bạn viết ra đều có trọng lượng hơn.

Có một lầm tưởng trong ngành IT: Nếu bạn không có một công ty để check-in mỗi sáng, không có một danh hiệu trên LinkedIn để khoác lên mình, thì bạn đang "thất nghiệp".Tôi cũng từng trải qua cảm giác đó khi quyết định rời khỏi vị trí DevOps & System Engineer tại một Core Team chuyên nghiệp. Nhưng nhìn lại, đó là giai đoạn tôi làm việc năng suất nhất, không phải cho một ông chủ nào, mà là cho chính mình và những khách hàng tin tưởng tìm đến tôi.1. Từ "người vận hành" đến "người giải quyết vấn đề"Khi còn làm System Admin hay DevOps tại TEL4VN, thế giới của tôi là đảm bảo hệ thống của công ty luôn Up. Nhưng khi bước ra ngoài, đối mặt với các dự án Outsourcing, tôi nhận ra khách hàng không cần một người chỉ biết gõ lệnh. Họ cần một giải pháp.Giai đoạn mà mọi người gọi là "thất nghiệp" thực chất là lúc tôi bắt đầu build những dự án CNTT từ con số 0 cho khách hàng.Thay vì chỉ quản lý một phần hệ thống, tôi phải tự tay thiết kế toàn bộ kiến trúc (Architecture).Thay vì đợi task đổ về, tôi phải tự đi tìm "bug" trong mô hình kinh doanh của khách và dùng công nghệ để sửa nó.Đó không phải là thất nghiệp. Đó là "Freelance with a CEO mindset".2. Tư duy DevOps trong mọi ngóc ngách sự nghiệpDù sau này tôi có giữ vị trí Managing Director hay làm Advisory Board cho các dự án tài chính, cái gốc của tôi vẫn là một người làm kỹ thuật. Tôi mang tư duy của một DevOps vào việc quản trị dự án:CI/CD cho cuộc sống: Tôi không đợi đến khi hoàn hảo mới bắt đầu. Tôi "release" bản thân vào những thử thách mới, nhận feedback từ thị trường, và cải tiến (optimize) mỗi ngày.Automation: Tôi luôn tìm cách hệ thống hóa quy trình, từ việc quản lý dự án cho đến việc kết nối với các "tần số" cùng đam mê.Khi bạn tự mình build dự án cho khách, bạn không còn là một "thợ code" hay một "người trực server". Bạn trở thành một người kiến tạo. Bạn học được cách quản trị rủi ro, cách tối ưu chi phí và cách giao tiếp để khách hàng hiểu được giá trị của những dòng code khô khan.3. Đừng sợ khoảng trống, hãy sợ "lỗi hệ thống" trong tư duyGửi những bạn đang loay hoay với hai chữ "thất nghiệp" trong mùa layoff này:Hệ thống không sập, nó chỉ đang bảo trì: Khoảng thời gian không đi làm công ty là cơ hội tốt nhất để bạn tự build một sản phẩm của riêng mình, hoặc nhận những dự án Outsourcing để thử sức với những Stack công nghệ mới mà ở công ty cũ bạn không có cơ hội chạm vào.Nói chuyện bằng sản phẩm, không phải bằng chức danh: Khách hàng và đối tác tìm đến tôi vì tôi giải quyết được bài toán của họ, chứ không phải vì cái danh thiếp tôi đang mang.Tôi là Thảo – một GenZ trầm tính nhưng luôn sẵn sàng "nói nhiều" bằng những dự án thực tế. Tôi đã từng bước ra khỏi vùng an toàn của một nhân viên chính thức để tự mình "vận hành" sự nghiệp. Và tin tôi đi, khi bạn làm chủ được kỹ thuật và tư duy hệ thống, bạn sẽ không bao giờ thất nghiệp. Bạn chỉ đang bận chuẩn bị cho một đợt "Big Release" của cuộc đời mình thôi.