2 điểm bởi GN⁺ 2023-12-15 | 1 bình luận | Chia sẻ qua WhatsApp

Phỏng vấn mẹ tôi, một lập trình viên COBOL trên mainframe

  • Mẹ tôi đã làm việc tại một trong những ngân hàng lớn nhất trong EU từ trước cả khi tôi sinh ra.
  • Thế giới lập trình ngân hàng hoàn toàn khác với những gì đa số mọi người quen thuộc.
  • Nếu mẹ tôi và nhóm của bà ngừng làm việc, ngân hàng sẽ sụp đổ chỉ trong vài tuần.

Năm 1991

  • Mẹ tôi bắt đầu chương trình đào tạo nội bộ tại Nordbanken (nay là Nordea).
  • Bà trải qua nhiều bài kiểm tra khác nhau và vượt qua kiểm tra IQ, đánh giá tâm lý và kiểm tra đa nhiệm.
  • Bà bắt đầu với vai trò lập trình viên COBOL trên mainframe IBM và 25 năm sau vẫn làm đúng công việc đó tại cùng ngân hàng.

COBOL

  • COBOL không phải là một ngôn ngữ lập trình hào nhoáng như Haskell thuần hàm hay Golang về đồng thời.
  • COBOL là một ngôn ngữ mệnh lệnh, thủ tục, và từ năm 2002 đã có tính hướng đối tượng.
  • Trong bối cảnh lập trình mainframe, hầu như không có ai biết COBOL.

Cơ sở dữ liệu

  • Cơ sở dữ liệu chính được gọi là IMS, một cơ sở dữ liệu phân cấp do IBM tạo ra cho chương trình Apollo.
  • Họ đang cố gắng di chuyển sang DB2, nhưng đây là công việc sẽ mất nhiều năm.
  • Cơ sở dữ liệu DB2 hiện đang lưu trữ khoảng 10TB dữ liệu.

Batch

  • Khoảng 80% hệ thống được cấu thành từ các tác vụ batch.
  • Các tác vụ batch chạy vào những thời điểm hoặc khoảng thời gian nhất định, xử lý dữ liệu hoặc truyền dữ liệu sang các ngân hàng/tổ chức khác.

Những vấn đề ngân hàng đang đối mặt

  • Các ngân hàng sử dụng mainframe có rất nhiều vấn đề phải xử lý.
  • Các lập trình viên đang ngày càng lớn tuổi, và nhân viên mới mất 2-3 năm mới có thể làm việc độc lập.
  • Có những chương trình đã tồn tại hàng chục năm mà không ai biết chúng thực sự làm gì.

Lời cuối

  • Rất thú vị khi nghĩ xem Nordea và các ngân hàng khác sẽ áp dụng công nghệ mới nào trong vài năm tới.

Hỏi & Đáp

  • Tại sao lại chọn lập trình COBOL trên mainframe IBM? Vì bà muốn làm việc với máy tính.
  • Điều tệ nhất trong một ngày làm việc là gì? Một đồng nghiệp quên dấu chấm trong mô-đun hệ thống quan trọng khiến ngân hàng bị sập suốt 16 giờ.
  • Tương lai của ngân hàng sẽ ra sao? Họ nhận ra rằng cần thay thế mainframe bằng thứ gì đó hiện đại hơn.
  • Là một nữ lập trình viên trong thập niên 90, bà gặp những thách thức gì? Không có vấn đề gì.
  • Làm việc với cùng một codebase suốt hơn 20 năm có trở nên nhàm chán không? Việc xây dựng các hệ thống mới luôn thú vị.
  • Viết code cho ngân hàng có đáng sợ không? Rất đáng sợ, nhưng môi trường kiểm thử rất vững chắc nên phần lớn đều diễn ra suôn sẻ.
  • Bà đã từng mắc sai lầm lớn nào với hệ thống ngân hàng chưa? Năm 1997, bà đã mắc lỗi khiến người ta có thể rút tiền trái phép từ tài khoản tiết kiệm hưu trí.
  • Môi trường làm việc như thế nào? Họ đã chuyển từ bàn làm việc cá nhân sang không gian mở, và bà rất ghét điều đó.

Ý kiến của GN⁺

  • Mainframe và ngôn ngữ COBOL vẫn giữ vai trò quan trọng trong ngành tài chính, và chuyên môn về công nghệ này rất có giá trị.
  • Độ phức tạp của hệ thống ngân hàng và sự phụ thuộc vào công nghệ cũ khiến việc chuyển đổi sang hệ thống mới trở nên khó khăn, và đây là một thách thức lớn.
  • Bài phỏng vấn này cho thấy rằng so với tốc độ phát triển nhanh của công nghệ, một số ngành vẫn đang sử dụng công nghệ cũ, tạo nên một sự tương phản thú vị.

1 bình luận

 
GN⁺ 2023-12-15
Ý kiến trên Hacker News
  • Bài gửi HN gốc năm 2016 là https://news.ycombinator.com/item?id=12096250
    Nếu muốn đọc thêm về chủ đề “thế giới lập trình ngân hàng hoàn toàn khác với những gì phần lớn chúng ta quen thuộc”, thì An oral history of Bank Python cũng rất hay: https://calpaterson.com/bank-python.html
    Trước đây cũng từng được đăng lên HN: https://news.ycombinator.com/item?id=29104047

    • Thật khó tin là đã 7 năm rồi. Tôi từng định phỏng vấn mẹ mình về chuyện bà lập trình mainframe bằng Michigan Algorithm Decoder, nhưng cuối cùng đã không làm được
      https://news.ycombinator.com/item?id=12097032
  • Người ta thường nghĩ rằng “nếu là lập trình viên mainframe 20 tuổi thì tuổi tác sẽ là một giá trị cực lớn nên sẽ nhận lương rất cao”, nhưng thực tế thường chỉ ở mức trung bình, thậm chí dưới trung bình, nên mới nảy sinh vấn đề đường ống nhân lực
    Giá trị thực sự không nằm ở kỹ năng như “biết COBOL”, mà là tri thức tổ chức về khối logic nghiệp vụ khổng lồ đã tích tụ trong COBOL. Một lập trình viên bình thường cũng có thể học COBOL, nhưng việc một lập trình viên COBOL đã nghỉ hưu quay lại với hợp đồng 500.000 USD một năm không phải vì COBOL, mà vì tri thức thể chế đã tích lũy
    Nếu các ngân hàng và tổ chức thực sự trả lương rất cao cho các lập trình viên mainframe trẻ, thì vấn đề nhân khẩu học hiện nay đã bớt nghiêm trọng hơn

    • Tôi từng gặp một người ở tình huống như vậy khi học cao học. Ông ấy làm ở ngân hàng rồi bị sa thải trong khủng hoảng tài chính, và ngân hàng định chuyển hệ thống cũ sang thứ như Java
      Họ báo cáo rằng dự án gần hoàn tất, và cho rằng đội viết lại đã đủ quen với COBOL nên có thể tự làm phần còn lại mà không cần ông ấy, nhưng trên thực tế, dù hiểu COBOL thì họ vẫn rất cần tri thức tổ chức của ông. Cuối cùng ông quay lại làm bán thời gian với mức phí tư vấn cao ngất cho đến khi quá trình chuyển đổi kết thúc, đồng thời học cao học để nâng cao năng lực
    • Tôi từng làm với hệ thống lõi COBOL ở một công ty bảo hiểm lớn và hoàn toàn đồng ý. Thứ công ty trả tiền không phải là kiến thức COBOL tự thân, mà là những người biết các điểm kỳ quặc và cạm bẫy không được tài liệu hóa trong mã
      Một lập trình viên khá vẫn có thể đọc và lần theo chương trình COBOL. Nhưng họ sẽ không biết vì sao tác vụ export quan trọng lại chết trong lúc trích xuất dữ liệu cho báo cáo 10-K. Lý do là vì ai đó từng cho rằng số bản ghi nhất định sẽ không vượt quá 3000, nên đã hardcode để cứ vượt ngưỡng đó là báo lỗi
    • Khi mới đi làm tôi từng làm nghiệp vụ mainframe cho ngân hàng/bảo hiểm, và môi trường làm việc khá tệ, từ những chuyện nhỏ như quy định trang phục cho tới những thứ khó chịu hơn như codebase legacy cổ lỗ sĩ khủng khiếp
      Nếu lương cao thì tôi còn chịu được, nhưng thực tế cũng không phải vậy. Trên thực tế tôi còn nhận ít hơn nhiều so với công việc trước đó là lắp đặt hạ tầng cáp vật lý, tức lắp cáp quang và Ethernet đồng, và lý do tôi chọn việc này chủ yếu chỉ vì văn phòng có điều hòa. Đây không phải kiểu công việc mà tôi muốn xây dựng sự nghiệp
      Khi làm quản trị viên hệ thống Windows cấp trung, hỗ trợ qua điện thoại cho khách hàng tại một nhà cung cấp cloud, tôi kiếm được nhiều hơn gần 30% so với thời làm nhân sự mainframe junior cho ngân hàng/bảo hiểm. Dù là kỹ năng hiếm và thuộc ngành giá trị cao, công việc mainframe lại được trả thấp hơn rất nhiều, và ở công ty đó, lập trình viên mainframe là nhóm được trả thấp nhất trong các vị trí phát triển ở mọi cấp độ kinh nghiệm. Những người thực sự được trả đúng giá chỉ là các nhà thầu độc lập đã làm 30 năm trước khi nghỉ hưu
    • Tôi có kinh nghiệm COBOL, cũng đã làm trên mainframe và sẵn sàng làm lại. Xét theo chuẩn lập trình viên COBOL thì tôi vẫn còn trẻ, nên ai đó vẫn có thể tận dụng tôi thêm 20 năm nữa
      Nhưng lương cho những vai trò như thế thảm hại so với mức đãi ngộ có thể nhận được ở các công nghệ khác, trong khi cuộc sống hiện đại gây áp lực rất lớn buộc người ta phải theo đuổi mức lương cao hơn
    • Thực sự có những trường hợp như vậy. Tôi từng làm ở một ngân hàng đa quốc gia có trụ sở tại Mỹ, nơi đội ở trụ sở chính đã tạo ra một chương trình hào nhoáng để thu hút sinh viên mới tốt nghiệp khoa học máy tính
      Chương trình này đưa ra mức giá thị trường “công bằng” cho vị trí đầu vào trong ngành, và cho họ trải nghiệm 2~3 đội hoặc phòng ban trong năm đầu tiên. Khi kết thúc, nếu vẫn thích công ty, ứng viên có thể chọn đội để vào chính thức, nhưng không có tăng lương, và tới lúc đó thì những người không thể hiện đủ nhanh đã bị sàng lọc từ trước
      Xét từ góc nhìn công ty, kết quả rất tuyệt. Họ có thể sử dụng các lập trình viên trẻ giỏi COBOL hơn cả những đồng nghiệp mới của tôi với mức 60.000~70.000 USD một năm, trong khi các đồng nghiệp senior hoặc thâm niên lâu năm thì tùy trường hợp nhận 200.000~400.000 USD
  • Bà tôi từng lập trình bằng thẻ đục lỗ, nhưng tôi không biết đó là phần cứng gì, và giờ thì đã quá muộn để hỏi. Bố tôi từng làm rất nhiều Fortran và COBOL trên mainframe Liên Xô, rồi sau đó cũng làm nhiều việc liên quan đến Y2K ở Mỹ
    Trong số đó, món đồ thú vị nhất là bản in chương trình Fortran mà bố tôi từng xé thành ba mảnh để bọc quanh cuộn phim lớn 64mm chụp ảnh núi từ ngày xưa. Có lẽ nó được in từ Minsk-32 mainframe, tên chương trình là MATR1, dùng để thao tác ma trận, và phần chú thích có nhắc tới địa hình. Giờ tôi đã đóng khung và treo nó lên tường gần bàn làm việc
    Tôi cũng đã viết code bằng nhiều ngôn ngữ suốt cả đời, và giờ con tôi đang ở tuổi teen, học Java và Python ở trung học và bắt đầu hứng thú với việc lập trình. Hướng tới thế hệ lập trình viên thứ tư

    • Nghe như ý tưởng cho một bộ phim nơi cùng một codebase được truyền qua nhiều thế hệ. Legacy Code sẽ là một cái tên hợp lý
  • Nếu đúng là đó là vị trí quan trọng nhất trong một ngân hàng xét về mặt kỹ thuật, thì với thị phần của Nordea tại Thụy Điển và Bắc Âu, nếu đội đó biến mất, kinh tế Thụy Điển, thậm chí cả kinh tế Bắc Âu, có thể bị chao đảo. Khi đó có lẽ EU cũng sẽ bị ảnh hưởng khá nhiều
    Từ sau khi đọc bài này, tôi cứ băn khoăn liệu những lập trình viên COBOL giữ cho các ngân hàng như vậy vận hành có phải là một bus factor cực kỳ bị đánh giá thấp trong nhiều nền kinh tế trên thế giới hay không. Tôi cũng tò mò kế hoạch dự phòng cho tình huống đó là gì
    [0] https://en.wikipedia.org/wiki/Nordea

    • Cũng khiến tôi tự hỏi liệu các lập trình viên APL có ở trong hoàn cảnh tương tự không. Tôi biết khá nhiều tập đoàn lớn dùng APL
    • Kế hoạch dự phòng cho tình huống đó, theo tiếng xấu thì có thể là ngừng hoạt động vài tuần: https://en.wikipedia.org/wiki/TSB_Bank_(United_Kingdom)#Migration_to_the_Sabadell_Proteo_banking_platform
      Tôi cho rằng sự thất thoát tri thức tổ chức là một yếu tố lớn trong thảm họa đó
    • Với tư cách là một lập trình viên từng bị xe buýt tông, lại còn là đúng chuyến xe buýt đi suốt 5 tiếng đến bến cuối ở miền tây Hy Lạp, tôi xin nói rằng nguy cơ bị ô tô tông chết còn cao hơn nhiều
      Cộng thêm việc doanh số SUV tăng lên, vốn nguy hiểm hơn cho người đi bộ và người đi xe đạp, thì điều đáng ngạc nhiên có lẽ là ngân hàng không sụp đổ vì các lập trình viên đã chết mà lại sụp đổ vì kế toán tồi và gian lận
  • Đoạn “Tôi từng có bàn làm việc riêng, còn giờ thì bị chuyển sang không gian mở nơi ngồi đâu cũng được, và tôi cực kỳ ghét điều đó” gây đồng cảm kỳ lạ một cách mạnh mẽ, dù tôi chưa từng làm việc với mainframe

    • Tôi cũng thích bàn làm việc riêng hơn nhiều. Việc con người tự thiết lập môi trường theo gu và sở thích của mình là rất tự nhiên, nên tôi không hiểu vì sao một số người thiết kế văn phòng lại không tính đến điều đó
    • Không biết có phải đa số văn phòng như chỗ chúng tôi cũng gọi là “chỗ ngồi linh hoạt” nhưng thực tế ai cũng có chỗ của mình, đi làm là luôn ngồi đúng cái bàn đó, và nhìn chung mọi người đều tôn trọng điều ấy không
      Ghế, vị trí và độ sáng màn hình, chiều cao bàn... đều đã được chỉnh cho hợp với bản thân, nên bản thân khái niệm hot desking trở nên nực cười. Tôi thà họ chính thức từ bỏ nó còn hơn
  • Khi làm tư vấn tích hợp hệ thống trong lĩnh vực dịch vụ tài chính, tôi đã phải tích hợp với các hệ thống core banking kiểu này rất nhiều
    Thông thường, nếu đàm phán một giao diện hoàn toàn mới thì ma sát về kỹ thuật, kinh doanh và tuân thủ quy định sẽ rất lớn, nên dự án rất dễ bị lùi hơn 1-2 năm; vì vậy chúng tôi thường cố tái sử dụng các điểm tích hợp sẵn có từ những dự án trước
    Việc tích hợp thường là chuyển giao các tài liệu có cấu trúc trước một thời điểm nhất định vào buổi tối để phục vụ xử lý batch qua đêm. Các tài liệu dữ liệu dựa trên offset theo thiết kế sẽ có những vùng chưa được gán để dành cho cập nhật và sử dụng trong tương lai, và khi cần thêm thông tin mới thì sẽ thương lượng xem có thể dùng những byte nào trong số đó
    Ở phía trích xuất dữ liệu, đôi khi cũng có thể tìm được các API “hiện đại” hơn, nhưng đừng kỳ vọng quá nhiều vào thứ gì quá chi tiết kiểu REST. Chúng tôi thường xuyên phải họp với bộ phận pháp chế và tuân thủ để tìm cách tránh những phần phát triển mới quá tốn kém
    Nói thêm thì, nhân sự phụ trách tuân thủ thường thực tế và định hướng giải pháp hơn nhiều so với IT. Thuyết phục nhóm của tôi rằng câu chữ trong quy định không nhất thiết phải bị diễn giải một cách sát chữ theo hướng hạn chế nhất, nhiều khi còn khó hơn là đạt được đồng thuận với phía tuân thủ
    Nếu tưởng tượng tầng tích hợp này đã chồng chất qua hàng trăm dự án trong suốt nhiều thập kỷ, bạn sẽ lần đầu cảm được vì sao thay thế hệ thống lõi lại khó đến vậy

  • Mẹ vợ tôi đã làm cả đời ở bộ phận IT của một công ty bảo hiểm. Bà không lập trình nhiều, nhưng theo thời gian đã trở thành nguồn kiến thức miền nghiệp vụ
    Có rất nhiều câu chuyện thời xưa. Trước khi có các hệ thống máy tính đúng nghĩa, dĩ nhiên mọi thứ đều được lưu bằng tài liệu giấy, và dự án đầu tiên của bà sau khi tốt nghiệp đại học là đi khắp các văn phòng vệ tinh để sắp xếp lại hệ thống hồ sơ tại chi nhánh theo chiến lược mới mà trụ sở chính đề ra
    Trong lúc nhóm của bà đúng nghĩa là lấy mọi tài liệu ra, dán nhãn lại rồi cất vào lại, hoạt động của chi nhánh đó phải dừng lại, và toàn bộ dự án kéo dài hơn một năm. Điều đó đã phần nào thay đổi góc nhìn của tôi về công việc của mình

    • Nghĩ đến việc các ngân hàng thời đó đã đẩy giới hạn của giấy tờ xa đến mức nào, thật khó tưởng tượng được độ phức tạp của ngân hàng hiện đại. Tôi không hiểu đủ về tài chính để biết phải bắt đầu hình dung từ đâu
  • Tôi ước gì đã trò chuyện với bà nhiều hơn trước khi bà mắc chứng mất trí. Tôi biết bà là nhà toán học và lập trình viên, nhưng trong một lần nói chuyện ngắn vài năm trước, bà kể rằng mình từng làm công việc tính toán quỹ đạo vệ tinh ở Liên Xô
    Ít nhất thì tôi hy vọng là vệ tinh

    • Tôi cũng ở hoàn cảnh tương tự. Mẹ tôi từng làm phần mềm mô phỏng cho hệ thống AEGIS. Với một phụ nữ da đen trong thập niên 1980, đó không phải chuyện thường thấy
      Bà lấy bằng toán trong 3 năm khi mới 20 tuổi, và đã lập trình máy tính bằng thẻ đục lỗ vào những năm 1970.
      Giờ thì bà thậm chí không còn buộc dây giày ổn định được nữa. Mong mọi người hãy ghi lại những thành tựu và câu chuyện cuộc đời của người thân yêu trước khi quá muộn
    • Nếu bạn từng nghĩ đến việc làm điều này, tôi thực sự khuyên bạn nên làm. Nếu đang băn khoăn bắt đầu thế nào, tôi gợi ý ứng dụng StoryCorps
      Nó dễ dùng, có rất nhiều câu hỏi soạn sẵn và bạn cũng có thể tự tạo câu hỏi. Bạn có thể ghi âm trực tiếp trên điện thoại, và nếu muốn thì còn có thể tải cuộc phỏng vấn lên Thư viện Quốc hội Mỹ
      https://storycorps.org/participate/storycorps-app/
    • Cũng có thể là cả hai: https://en.wikipedia.org/wiki/Fractional_Orbital_Bombardment_System#Development_history_and_deployment
  • Bà tôi năm nay đã 95 tuổi. Bà vẫn đi làm mỗi ngày tại một viện nghiên cứu ở khối hậu Xô Viết và viết mô phỏng số bằng Fortran và Maple
    Đồng nghiệp của bà vẫn chưa muốn bà nghỉ hưu, và bà cũng cứ hoãn nghỉ hưu hết năm này sang năm khác. Tôi thật sự rất tự hào về kiến thức giải tích số và toán học xuất sắc của bà

  • Công việc lập trình đầu tiên của bà là ở một công ty vận tải, nơi có nhiều lập trình viên đã làm việc hơn 15~20 năm, và một phần đáng kể trong số đó chủ yếu bảo trì COBOL đang vận hành doanh nghiệp
    Trong số các lập trình viên kỳ cựu đó có rất nhiều phụ nữ, và cảm giác là ở nhóm senior thì con số này vượt quá 50%. Điều đáng buồn là dù trong số các lập trình viên trẻ vẫn có khá nhiều phụ nữ, nhưng nhìn chung đa số vẫn là nam giới
    Vì công ty đó chủ yếu tuyển dụng từ các trường kỹ thuật địa phương, đây có vẻ như là một ví dụ thú vị cho thấy theo thời gian số lượng phụ nữ theo học chuyên ngành kỹ thuật phần mềm đã giảm đi như thế nào

    • Tôi nhớ từng nghe rằng ngày xưa lập trình máy tính được xem là giống công việc đánh máy hay thư ký, nên ban đầu chủ yếu thu hút phụ nữ