Tương lai của kỹ nghệ phần mềm là SRE

• Ngay cả trong thời đại agentic coding, nhu cầu đối với kỹ sư phần mềm được dự báo vẫn sẽ tăng lên; điểm cốt lõi nằm ở năng lực vận hành dịch vụ chứ không phải viết mã
• Viết mã vốn dĩ luôn là phần dễ hơn, còn điều thực sự khó là vận hành hệ thống ổn định trong thời gian dài
• Giống như các trường hợp no-code và bảng tính, ngay cả người không chuyên cũng có thể tạo ra công cụ, nhưng gánh nặng bảo trì và vận hành cuối cùng vẫn đòi hỏi kỹ nghệ chuyên nghiệp
• Người dùng không mua phần mềm mà mua dịch vụ; phần mềm tốt phải hoạt động trơn tru đến mức gần như vô hình
• Sự xuất sắc trong vận hành (operational excellence) như uptime, tỷ lệ lỗi, tốc độ phục hồi, cập nhật bảo mật... là năng lực cạnh tranh cốt lõi trong tương lai
• Vai trò đáp ứng được toàn bộ những yêu cầu này là SRE, đang dịch chuyển vào vị trí trung tâm của kỹ nghệ phần mềm

---

SRE được dự báo sẽ trở thành vị trí được tuyển dụng nhiều nhất

• Khi code trở nên rẻ hơn, mô hình chiến thắng sẽ là sự xuất sắc trong vận hành
• Ai cũng có thể làm ra một bản demo greenfield, nhưng để vận hành dịch vụ ổn định thì cần năng lực kỹ thuật thực sự
• "Ai cũng muốn viết demo greenfield, nhưng không ai muốn vận hành dịch vụ"
• Kỹ nghệ phần mềm không chỉ là lập trình, mà là quản lý những hệ thống thay đổi theo thời gian

Bài học từ thời đại no-code và bảng tính

• Joe, một nhân viên kế toán, đã dùng công cụ no-code và macro bảng tính để rút ngắn một công việc lặp lại từ 10 giờ mỗi tuần xuống còn 1 giờ
• Ban đầu hiệu quả rất rõ rệt, nhưng theo thời gian độ phức tạp tăng nhanh
  • Môi trường kinh doanh thay đổi, quy tắc kế toán thay đổi, các vấn đề về múi giờ và giờ tiết kiệm ánh sáng ban ngày chồng chất
  • Mỗi tuần lại lộ ra các edge case mới, đòi hỏi liên tục chỉnh sửa và vá lỗi
• Cuối cùng Joe chuyển sang trạng thái bị trói buộc vào chính hệ thống mình tạo ra
  • Ngay cả khi đi nghỉ cũng phải để tâm đến hệ thống, và rất khó bàn giao việc vận hành cho người khác
  • Bản thân việc chạy code và kiểm tra kết quả đã trở thành nguồn gây lo âu và căng thẳng

Căn bệnh máy tính (The Computer Disease)

• Đây là khái niệm do Feynman đặt tên, chỉ việc vấn đề của máy tính là chúng khiến con người không ngừng muốn nghịch và chỉnh sửa
• Bản thân tự động hóa rất thú vị, nhưng có một cái bẫy là mở rộng tự động hóa sang cả những lĩnh vực không cần thiết, làm độ phức tạp tăng lên
• Gánh nặng thực sự nằm ở vận hành dịch vụ
  • Giữ cho nó hoạt động ổn định
  • Mở rộng ở quy mô lớn mà không phát sinh sự cố
  • Quản lý liên tục trong suốt nhiều năm
• Cung cấp dịch vụ đặt trọng tâm vào tính ổn định, độ tin cậy và tính liên tục

Vì sao sự xuất sắc trong vận hành là tương lai

• Con người không mua phần mềm, mà là thuê một dịch vụ giải quyết vấn đề cho họ
• Họ không quan tâm iCloud vận hành nội bộ ra sao, mà kỳ vọng ảnh sẽ luôn tự động đồng bộ giữa các thiết bị
• Word, Notion hay gDocs được xây dựng như thế nào không quan trọng; điều cốt lõi là trải nghiệm viết và chia sẻ suy nghĩ
• So với cấu trúc mạng thanh toán, kết quả là ly matcha latte 7 đô được thanh toán trơn tru mới quan trọng hơn
• Phần mềm tốt là thứ gần như vô hình (hoạt động tự nhiên, không gây cảm giác hiện diện)

Những bài toán kỹ thuật thực sự khó

• 90% đầu tiên để làm ra một bản demo chạy được là phần dễ, còn 190% còn lại mới thực sự quan trọng
• Những câu hỏi cần trả lời từ góc độ vận hành:
  • Uptime là bao nhiêu
  • Tỷ lệ phát sinh lỗi ở mức nào
  • Khi xảy ra sự cố, mất bao lâu để phục hồi
  • Có phát hiện vấn đề trước khi người dùng nhận ra hay không
  • Có quản lý được các phụ thuộc upstream hay không
  • Khi nhà cung cấp gặp sự cố, có phát hiện trước khi người dùng phàn nàn hay không
  • Mất bao lâu để phản ánh các ý tưởng do người dùng đề xuất
  • Có ngăn được việc các kỹ sư làm hỏng hệ thống của nhau hay không
  • Có hệ thống nào giúp kỹ sư tiếp tục tiến lên mà không biến ứng dụng thành một mớ hỗn độn khó hiểu hay không
  • Có thể xử lý phần mềm ở quy mô vượt quá khả năng chứa trong đầu của một người hay không
  • Nếu sự cố lớn xảy ra khi kỹ sư đang ngủ ở một múi giờ lệch 12 tiếng, có sửa xong trước khi người dùng bỏ cuộc hay không
  • Có khả năng phục hồi sau sự cố nội bộ và sự cố upstream không, hay dữ liệu quan trọng sẽ bị mất
  • Có đều đặn áp dụng các bản cập nhật bảo mật hay không
  • Dữ liệu người dùng có bị rò rỉ hay không
  • Có đáng tin cậy hay không
  • Có thể dựa vào hay không
  • Có bằng chứng nào chống lưng cho sự tin cậy đó hay không
  • Có thể ký vào một cam kết ràng buộc pháp lý bảo đảm phần mềm sẽ hoạt động khi cần hay không
• Đây mới là những bài toán kỹ thuật thực sự khó, còn viết mã là phần dễ hơn

[bsh998]

Kết quả AI đọc được: bíp bíp bíp... 95% khả năng đây là blog do AI viết.

[alfenmage]

kkk 90 190 kkk

[roxie]

kkkkkkkkkk

[sudosudo]

Nói gì vậy trời

[skageektp]

Sẽ tốt hơn nếu có kèm theo phần giải thích SRE là gì.