Bài viết đến từ anh Vũ Tuấn Nghĩa – Quản lý cao cấp hoạch định dữ liệu Data Engineering team @Techcombank

Data orchestration là một khối xây dựng cốt lõi của các hệ thống ETL dữ liệu, và là một công cụ đã có từ lâu đời và được áp dụng trong nhiều hệ thống khác nhau. Khi xây dựng Data Lake tại Techcombank, chúng mình có cơ hội thiết kế nhiều component/system từ đầu, từ hệ thống Data sourcing đến Datalake, đến hệ thống data ETL pipeline trên các zones của Data Lake. Để đáp ứng các nhu cầu và thách thức thực tế, ta cần có một hệ thống Data orchestration để giải quyết các bài toán:

1. Cơ chế trigger các downstream job một cách linh hoạt mà không gây khó khăn trong quá trình vận hành
2. Rút ngắn thời gian phát triển, xây dựng và kiểm thử
3. Hạn chế sự phụ thuộc lẫn nhau gây ra chain failure

Hôm nay chúng ta sẽ tìm hiểu về Data orchestration và cách giải quyết bài toán ở Techcombank.

Data Orchestration là gì?

Data orchestration là nền tảng platform có nhiệm vụ quản lý và tự động hoá flow của data xuyên suốt giữa các hệ thống, application và các hệ thống lưu trữ.

Có thể hiểu đơn giản như như hình dưới như sau:

1. Khi có 1 lệnh trigger
2. Job 1 được execute
3. Khi Job 1 done, Job 2 và Job 3 được execute
4. Khi Job 2 và Job 3 cùng done, Job 4 được execute

Nhu cầu cần một Data Orchestration xuất hiện khi có dependency giữa các hệ thống. Khi có một job phụ thuộc vào job khác, thì sẽ cần 1 hệ thống ở giữa để không chỉ trigger mà còn đảm bảo với từng Job riêng biệt, chỉ được bắt đầu sau khi tất cả các phần phụ thuộc đã hoàn tất (ví dụ: Job 4).

Sự phát triển của Data Orchestration patterns

First Gen – Flight schedule

Phiên bản đầu tiên cũng như cổ điển nhất của Orchestration, được dùng khá phổ biến ở nhiều IT system (ví dụ: hệ thống giờ bay của máy bay).

Job được trigger dựa theo fixed time hoặc interval time và không phụ thuộc vào các job upstream có hoàn tất hay không. Để phòng trừ trường hợp các Job chạy tốn thời gian hơn kế hoạch, thường sẽ thêm các buffer giữa các job.

Điểm hạn chế của design này là cũng chính là task delay – buffer time

Lúc này Job 2 sẽ nhận stale input data khiến data output của Job 2 cũng sai, dẫn đến cả pipeline đang xử lý data bị sai lệch.

Current Gen – Train schedule

Phiên bản orchestration được sử dụng rộng rãi trong các software hiện đại ngày nay, nổi bật có Airflow, Dagster, Prefect, và dbt. Core concept sử dụng Directed Acyclic Graph (DAG) để định nghĩa sự phụ thuộc giữa các job và stateful application để quản lý trigger và start job.

Điểm hạn chế của design này là

1. Mono-DAG

Việc sử dụng DAG để liên kết phụ thuộc giữa các job với nhau, dẫn đến trong quá trình phát triển

a. việc liên tục thêm những job vào dẫn đến “mạng nhện” DAG, khiến chi phí maintain bao gồm: compile, test càng ngày càng tăng cao khiến development cycle chậm dần theo thời gian.

b.

c. việc xác định owner of DAG cũng là vấn đề nhức đầu, nhất là khi có issue, việc ảnh hưởng đến nhiều job (nhiều team) khiến chi phí phối hợp rất tốn nhiều thời gian.

2. DAG of DAG
Một hướng giải quyết khác là thay vì sử dụng một mono-DAG, chúng ta sẽ tạo DAG of DAG. Tuy nhiên ta lại gặp phải vấn đề lớn là do giờ đây tầng phụ thuộc là DAG, sẽ giảm sự linh hoạt trong định nghĩa sự phụ thuộc của các job, nhất là trong trường hợp các data flow quan trọng, với SLA thấp.

Bài toán ở Techcombank

Hệ thống Datalake của Techcombank được chia làm 2 part:

1. ETL Sourcing dữ liệu từ tất cả các hệ thống Data sources, tập kết data ở Raw zone, do đặc thù đơn giản về mặt nghiệp vụ, không có transformation, không dependency → Data orchestration sử dụng Airflow – out of the box solution.
2. Với các ETL giữa các zone trên On-cloud Datalake, các ETL về mặt nghiệp vụ yêu cầu các dependency phức tạp, việc sử dụng các stateful Orchestration(current Gen) như Airflow hay AWS StepFunction gặp phải nhiều khó khăn trong quá tình development or operation (mono-DAG và DAG of DAG) → dẫn đến không đáp ứng được nhu cầu sử dụng của các team development.

Từ đó team mình có phát triển framework Orchestration để giải quyết bài toán gặp phải.

Event-driven Orchestration

Thay vì build 1 hệ thống centralized stateful orchestration thì team mình tiếp cận theo một mindset khác:

1. Condition-based over state
2. Events within queue over hardly dependency
3. Configuration as code over code-first approach

Condition-based over state

Việc sử dụng Conditions để xác định xem khi nào job được trigger thay vì đơn giản dùng state của upstream job khiến việc config trigger rất linh hoạt trong quá trình sử dụng. Sau đây là một số ví dụ trong quá trình sử dụng:

Condition để trigger job khi cả 2 job_1, job_2 succeeded

{
  "trigger_events":[
     "job_1", "job_2"
  ],
  "conditions": [
    {
      "name": "all_jobs_succeeded",
      "params": {
        "job_ids": [
          "job_1",
          "job_2"
        ],
        "within": 86400
      }
    }
  ]
}

Condition để trigger job khi đến ngày 5 or 18 của tháng và lần chạy của job cuối cùng success

{
  "trigger_events": [
    {
      "schedule_expression": "cron(45 01 * * ? *)"
    }
  ],
  "conditions": [
    {
      "name": "is_date_of_month",
      "params": {
        "days": [
          5,
          18
        ]
      }
    },
    {
      "name": "last_run_succeeded"
    }
  ]
}

Những functions như “last_run_succeeded“, “all_jobs_succeeded” đều là những custom function, do đó khi có nhu cầu trigger theo một logic nào đó, các bạn engineer hoàn toàn có thể contribute vào core Orchestration framework.

Events within queue over hardly dependency

Thay vì dùng DAG để định nghĩa dependency giữa các Job một cách chặt chẽ, chúng ta sẽ dùng queue system(ở đây bọn mình dùng AWS SQS) để decoupling giữa producer và consumer từ đó giải quyết:

1. Không còn Mono-DAG – mỗi Job được định nghĩa độc lập ở small unit DAG, mỗi khi job hoàn thành, sẽ bắn ra event với naming đã được định nghĩa trong config
   {"finish_events": [ { "name": "job_1_completed" } ] }
2. Tăng tốc độ build và testing time – do mỗi DAG được định nghĩa độc lập và ở small unit nhất do đó tăng thời gian development và testing

Configuration as code over code-first approach

Hệ thống Datalake theo đuổi mindset “Configuration as Code“

để tách biệt Operation khỏi development từ đó tăng tốc khả năng release của các system, hầu hết các system của Datalake ở Techcombank đều có 2 repo:

1. Repository chứa core code logic
2. Repository chứa configuration

Sau đây là ví dụ một ví dụ 1 config:

Kết luận

Dù đã đáp ứng được hầu hết các nhu cầu sử dụng đồng thời khá hiệu quả trong quá trình development và operation, nhưng Data orchestration framework ở Techcombank vẫn còn nhiều điểm đang phát triển thêm:

• Resource manager
• Retry mechanism: back-off retry and dead letter queue

Thuộc dự án “Inside GemTechnology” do Techcombank x TopDev triển khai, chuỗi nội dung thuần Tech “độc quyền” được chia sẻ bởi đội ngũ Tech Leader đến từ Silicon Valley tại Techcombank sẽ được cập nhật liên tục tại chuyên mục Tech Blog Techcombank x TopDev. Cùng theo dõi & gặp gỡ các chuyên gia bạn nhé!

Các cơ hội việc làm tại Techcombank

Senior Data Engineer

Quận Cầu Giấy, Hà Nội - Quận 1, Hồ Chí Minh

Ngân Hàng

Đăng nhập để xem mức lương

JavaPythonScalaData Engineer

Ứng tuyển

Expert, Software Engineering (Data Operations)

Quận Cầu Giấy, Hà Nội - Quận 1, Hồ Chí Minh

Ngân Hàng

Đăng nhập để xem mức lương

PythonAWSCI/CDSoftware EngineerETLData Operation

Ứng tuyển

TECH & DATA MANAGEMENT ASSOCIATE ( 18-MONTH FAST TRACK)

Quận Hoàn Kiếm, Hà Nội - Quận 1, Hồ Chí Minh

Ngân Hàng

Đăng nhập để xem mức lương

JavaPython.NETBig DataQA/QCDatabase AdministratorNetworkIT SecurityData Architecture

Ứng tuyển

Bài viết liên quan

Data Lake - Nền tảng lý trí cho mọi quyết định tài chính

Anh Nguyễn Quang Huy từng có kinh nghiệm nhiều năm về Khoa học dữ liệu cũng như phát triển và quản lý Hệ thống Dữ liệu lớn (Big Data) khi công tác tại các tập đoàn đa quốc gia tại tại Sing và Mỹ. Được truyền cảm hứng từ những bài toán lớn trên hành trình số hóa mà Techcombank đang giải quyết cho thị trường ngân hàng, Anh Nguyễn Quang Huy đã quyết định quay trở về Việt Nam để đồng hành với đội ngũ Techcombank trong giai đoạn chuyển đổi số mạnh mẽ nhất từ trước đến nay. Ở thời điểm hiện tại, anh đang giữ vị trí Director, Data Engineer tại Techcombank. Công việc chính của anh là phụ trách xây dựng các hoạt động, dự án liên quan đến Data Lake (Hồ dữ liệu) tại Techcombank. Hãy cùng nghe câu chuyện về Data Lake sẽ giải quyết những bài toán lớn nào cho hàng triệu khách hàng của Techcombank. Theo anh đâu là tầm quan trọ [...]

Chia sẻ từ Techcombank

Chi tiết

Data Modeling with DynamoDB: Single table design (Xây dựng mô hình dữ liệu với DynamoDB: Thiết kế bảng đơn lẻ)

Bài viết đến từ anh Vũ Tuấn Nghĩa - Quản lý cao cấp hoạch định dữ liệu Data Engineering team @Techcombank DynamoDB là một dịch vụ cơ sở dữ liệu NoSQL cung cấp hiệu năng nhanh và nhất quán - có khả năng mở rộng và linh hoạt trong cách sử dụng. Khác với cơ sở dữ liệu quan hệ (RDMS), DynamoDB không sử dụng joins và các cấu trúc quan hệ khác để lưu trữ và truy vấn dữ liệu. Thay vào đó, bạn sẽ thiết kế table của mình theo Single design table - 1 table duy nhất phục vụ toàn bộ application hay service, việc này giúp hiệu suất đọc và ghi nhanh hơn ở scale lớn và giảm chi phí cloud. Trong bài viết này, chúng mình sẽ khám phá các lợi ích và thách thức của việc sử dụng Single design table trong DynamoDB, cũng như cách Datalake ở Techcombank sử dụng để đáp ứng và tối ưu như cầu sử dụng. Single table design Trong tài liệu trang chủ AWS có đề cập: You should maintain as few tables as [...]

Chia sẻ từ TechcombankLập Trình

Chi tiết

Khoa học dữ liệu là một trong những chiếc chìa khóa giúp nhiều doanh nghiệp cũng như các tổ chức tài chính lớn như ngân hàng đột phá trong kỷ nguyên 4.0. Càng ngày việc thu thập và hiểu dữ liệu dần trở thành một kim chỉ nam giúp các doanh nghiệp tạo ra tính đột phá trong tương lai. 

Anh Nguyễn Hoàng Huy hiện đang là Giám đốc khoa học dữ liệu, và đã được trao bằng tiến sĩ ngành Khoa học máy tính của Đại học tổng hợp Greifswald. Năm 2012, anh được giải thưởng bài báo xuất sắc nhất của Hội khoa học dữ liệu CHLB Đức. Sau đó anh trở về Việt Nam tham gia nhiều công ty được đầu tư bài bản vào dữ liệu lớn.

Ứng dụng Data Science: dữ liệu là nguồn nhiên liệu cho trí tuệ nhân tạo

Theo anh, dữ liệu quan trọng như thế nào với tương lai của Digital Banking?

“Thực ra dữ liệu quan trọng trong mọi lĩnh vực nói chung, khi chúng ta phải ra quyết định chứ không chỉ với Digital Banking “

Để đơn giản chúng ta hình dung thế này: trong sinh tồn, một con khỉ tinh mắt thấy được vài nải chuối đang treo trên cây nhưng cũng thấy một con sư tử đang gần đó. Khi đó con khỉ phải tính toán các xác suất chết đói nếu không ăn chuối so với xác suất bị sư tử vồ dựa trên rất nhiều dữ liệu ví dụ như: mình cách nải chuối bao xa? cách con sư tử bao xa? bản thân có thể chạy nhanh đến đâu? sư tử có thể chạy nhanh như nào? con sư tử thức hay ngủ, có vẻ đói hay no? nải chuối đó có bao nhiêu quả, quả lớn hay nhỏ, xanh hay chín? rồi thông tin về điều kiện bên trong cơ thể, bản thân đang đói không? có cần liều lĩnh ăn những quả chuối không?. Trong tất cả các lĩnh vực, đặc biệt trong các giao dịch kinh tế, tài chính, bên sở hữu nhiều kiến thức, thông tin, dữ liệu thực tế đều có nhiều lợi thế hơn so với bên còn lại.

Như chúng ta biết, hoạt động ngân hàng diễn ra mọi lúc mọi nơi trong cuộc sống hàng ngày của khách hàng, ví dụ như giao dịch mua bán, chuyển tiền, thanh toán dịch vụ v.v, những hoạt động này được thực hiện theo thời gian thực trong nhiều bối cảnh khác nhau, thông qua nhiều dịch vụ công nghệ khác nhau. Vì vậy nếu chúng ta có những dữ liệu giàu bối cảnh đó, AI có thể hỗ trợ chúng ta để gỡ bỏ những rào cản trong gắn kết, tiếp cận khách hàng, gợi ý sản phẩm phù hợp với bối cảnh cá nhân, chuyển các quy trình thẩm định cũng như phân phối sản phẩm lên môi trường số, theo thời gian thực, khi đó việc đi đầu và mở rộng thị trường không nằm ngoài tầm tay.

“Phiên bản ngân hàng số (digital banking) 4.0, mục tiêu mà tất cả các ngân hàng ở những nước tiên tiến hiện đang hướng đến, Việt Nam cũng không nằm ngoài câu chuyện này”

Phiên bản ngân hàng tương lai chủ yếu vận hành đa kênh số, không có yêu cầu về việc phân phối sản phẩm/dịch vụ qua kênh vật lý, hướng đến trải nghiệm khách hàng trong từng bối cảnh, cá nhân hóa trải nghiệm, loại bỏ ma sát ra khỏi trải nghiệm khách hàng. Ngân hàng này sẽ vận hành dựa trên nhiên liệu là dữ liệu, nhưng không chỉ loại dữ liệu giao dịch, hay dữ liệu tham chiếu tín dụng mà các ngân hàng đang sở hữu hiện nay mà phải xoay quanh các dữ liệu cung cấp theo bối cảnh. Từ đó, ngân hàng có thể cung cấp sản phẩm/dịch vụ dựa trên bối cảnh “Ở đâu, khi nào, vì sao và như thế nào?”, theo thời gian thực.

Cụ thể, dữ liệu và AI sẽ là phần cốt lõi trong sự dịch chuyển mô hình hoạt động tư vấn tài chính của ngân hàng. Lời tư vấn có khả năng biến thành trải nghiệm theo thời gian thực được thực hiện bằng AI thông qua hiểu rõ về hành vi, khẩu vị rủi ro của khách hàng, cũng như tìm ra được công cụ, sản phẩm tốt nhất giải quyết vấn đề của khách hàng. Công nghệ giọng nói sẽ dần dần giúp khách hàng tin tưởng vào trợ lý AI của mình trong việc đưa ra những gợi ý về giải pháp tài chính hàng ngày cho họ, thay vì họ phải tự đi tìm kiếm giải pháp. Ví dụ trợ lý AI có thể đưa ra tư vấn như: Bạn đang thanh toán qua thẻ tín dụng quá nhiều rồi đấy, tôi có những phương án khác giúp bạn có tiền mua sắm tiết kiệm được 1,2 triệu đồng mỗi tháng bằng cách tự động liên kết với ví Apple Pay của bạn, bạn muốn xem không?. Thậm chí ngân hàng Emirates NBD đề xuất sản phẩm tiết kiệm với lãi suất dựa trên số bước chân mà khách hàng đi hoặc chạy bộ mỗi ngày, để khích lệ họ tiếp tục lối sống lành mạnh hơn cả về thể chất lẫn tài chính. Bạn thậm chí không cần phải làm hồ sơ mở tài khoản tiết kiệm thì mới bắt đầu tiết kiệm được mà chỉ cần xin quyền truy cập vào ứng dụng của ngân hàng số như Moven.

Với nhiều ứng dụng ngân hàng số đột phá, tất yếu trong tương lai, nếu không có chiến lược dữ liệu áp dụng xuyên suốt toàn bộ tổ chức, bạn sẽ chỉ có 1 ốc đảo dữ liệu riêng rẽ và không biết khách hàng của mình là ai, nhu cầu, hoàn cảnh của họ để đưa ra những dịch vụ tốt nhất. Như chúng ta đã thấy gần đây, hiện tượng tư vấn up-sale, cross-sale các sản phẩm bảo hiểm, đầu tư một cách cứng nhắc, chạy theo KPI, gây một số điều tiếng tại các ngân hàng thương mại trong nước gần đây là do chúng ta thiếu dữ liệu bối cảnh, hành vi theo thời gian thực của khách hàng để đề xuất đúng sản phẩm theo kịp thời gian, nhu cầu của khách hàng dẫn đến giảm sự gắn kết, lòng trung thành của khách hàng.

Như trên chúng ta đã thấy xu hướng ngân hàng số, nhúng toàn diện, ngân hàng mở là tất yếu. Trong cuộc dịch chuyển về ngân hàng số trở nên hoàn thiện, thì những ngân hàng hàng đầu không phải là những ngân hàng sở hữu mạng lưới phân phối lớn, mà là những ngân hàng có năng lực dữ liệu quy mô lớn, mang lại những lợi thế cung cấp bối cảnh cho hoạt động ngân hàng hàng ngày.

Vì vậy, các ngân hàng phải có nền tảng công nghệ mở, xây dựng mối quan hệ hợp tác với đối tác bên ngoài lĩnh vực ngân hàng, đi đôi với khả năng tiếp cận, sở hữu và tận dụng dữ liệu có được. Từ đó mang đến sự khác biệt thực sự trong việc gợi ý sản phẩm/dịch vụ ngân hàng theo thời gian thực dựa trên dự đoán hành vi khách hàng. Ví dụ ngân hàng Emirates NBD hợp tác với mạng xã hội Twitter xây dựng ngân hàng xã hội, cải thiện trải nghiệm dịch vụ ngân hàng dựa trên phân tích nhu cầu khách hàng kịp thời từ dữ liệu mạng xã hội.

Ngày nay nếu muốn thu hút khách hàng sử dụng dịch vụ ngân hàng của mình, bạn phải tiếp cận họ xung quanh một giao dịch hoặc sự tương tác nào đó, khi họ cần tín dụng để hoàn tất một cuộc mua bán nào đó chẳng hạn. Ngoài ra, một khi người tiêu dùng đã sử dụng dịch vụ ngân hàng nhúng trong một nền tảng khác, các ngân hàng sẽ không còn biết khách hàng đang làm gì, cần gì, do ngân hàng hoàn toàn không có dữ liệu của khách hàng trên nền tảng đó. Ngân hàng sẽ hoàn toàn mất dấu, bối cảnh khách hàng, do đó ngân hàng cần chiến lược hợp tác tích hợp các sản phẩm, dữ liệu của các công ty Fintech, hoặc các công ty công nghệ nền tảng. 

Những thử thách của người làm dữ liệu “thực địa”

Có rất nhiều thách thức ở “thực địa” đối với các nhà khoa học dữ liệu. Đầu tiên là vấn đề chất lượng dữ liệu cho xây dựng các mô hình học máy, dự báo, sản phẩm trí tuệ nhân tạo. Đối với các tổ chức có lịch sử phát triển lâu dài, các quy trình nghiệp vụ phải tuân thủ các quy trình chặt chẽ, phức tạp, đặc biệt như các ngân hàng, dữ liệu thường silos. Dữ liệu quá khứ có thể đến từ nhiều nguồn, hệ thống cũ, bộ phận khác nhau không liên thông với nhau, mô hình dữ liệu không nhất quán, meta data thiếu hoặc không được định nghĩa đầy đủ. Điều này dẫn đến sự mất kết nối giữa nguồn dữ liệu với cách sử dụng dữ liệu sao cho đúng, mất manh mối với bối cảnh kinh doanh. Thậm chí mã chương trình, tài liệu của các luồng xử lý dữ liệu không đầy đủ, không được cập nhật. Những điều này gây ra rất nhiều những khó khăn cho việc tiền xử lý, khảo sát dữ liệu từ quá khứ, lên ý tưởng, xây dựng các đầu vào cho các mô hình dự báo. Tất nhiên còn nhiều khó khăn khác như phải xử lý, xây dựng các mô hình dự báo trên dữ liệu lớn, luôn cập nhật. Tuy nhiên với nền tảng công nghệ của mình, Techcombank đã giảm thiểu một cách tối đa những khó khăn này cho các nhà khoa học dữ liệu.

Thử thách lớn thứ hai là phải rút ngắn thời gian phát triển một vòng đời của một mô hình dự báo, đặc biệt rút ngắn thời gian xây dựng mô hình từ khi xác định được các yêu cầu, mục tiêu của bộ phận kinh doanh. Để làm được điều này, chúng ta phải có một nền tảng tính toán xử lý, lưu trữ các thuộc tính, đặc điểm (biến đầu vào của các mô hình dự báo) cơ bản, đầy đủ, toàn diện của khách hàng, cũng như các kỹ thuật xây dựng mô hình dự báo tương đối phổ quát cho đa dạng các sản phẩm, yêu cầu nhanh của các bên kinh doanh. Tất nhiên không thể có mô hình, hệ thống thuộc tính luôn tốt nhất, thậm chí phù hợp cho mọi bài toán, yêu cầu kinh doanh. Hơn nữa những kỹ thuật xây mô hình này còn phải đảm bảo tính khái quát hoá, giữ được hiệu năng trong sự thay đổi của dữ liệu thực tế, trong điều kiện chất lượng dữ liệu không cao, dữ liệu không được xử lý đồng bộ. Suy cho cùng, hiệu năng thực sự của mô hình dự báo chỉ được đánh giá trong tương lai. Nhưng có lẽ thách thức hơn cả, có những bài toán, yêu cầu khoa học dữ liệu thực tế của bên kinh doanh hóc búa ngay cả trong điều kiện lý tưởng, lý thuyết và rất khó đưa ra giải pháp thích hợp trong điều kiện thực tế.

Xuất phát nhu cầu am hiểu khách hàng, cung cấp sản phẩm/dịch vụ, cải thiện trải nghiệm khách hàng trong bối cảnh, vòng đời khách hàng, Techcombank tiên phong phát triển một nền tảng dữ liệu khách hàng tổng thể trên Cloud. Và để giảm thiểu khó khăn như trao đổi ở trên, cũng như đảm bảo sự tuân thủ, bảo mật khi khai thác dữ liệu, một bộ khung về quản trị dữ liệu với Collibra đã được tiên phong triển khai đồng bộ ở ngân hàng. Khi đó chất lượng, độ tin cậy, xác thực của dữ liệu được quản lý, tạo thuận lợi cho triển khai các dự án về khoa học dữ liệu. Đặc biệt một nền tảng về học máy trên Cloud với SageMaker đang được ngân hàng đầu tư và triển khai. Rồi sự chuẩn bị nền tảng dữ liệu mở, dữ liệu bối cảnh từ các đối tác, hệ sinh thái mới được bổ xung. Tất cả những điều này giúp ươm mầm những dự án khoa học dữ liệu lớn hơn, tạo nhiều ảnh hưởng tích cực đến ngân hàng, khách hàng.

Techcombank là một trong những ngân hàng đầu tiên trong nước đầu tư mạnh mẽ các tài năng dữ liệu nói chung hay khoa học dữ liệu nói riêng. Có lẽ Techcombank là một trong những ngân hàng có khối dữ liệu riêng đầu tiên với đông đảo hơn 200 nhân sự, chuyên gia tài năng nhiều kinh nghiệm. Khối có cấu trúc với năm phòng: 

• Sản phẩm dữ liệu
• Hoạch định dữ liệu
• Phân tích và am hiểu dữ liệu kinh doanh
• Phân tích nâng cao và sáng tạo (AAI)
• Quản trị dữ liệu như những ngân hàng tiên tiến trên thế giới. 

Phòng phân tích nâng cao và sáng tạo với trách nhiệm xây dựng các công cụ, năng lực, mô hình phân tích nâng cao, dự báo, học máy, có nhiều chuyên gia quốc tế, như từ Google DeepMind đến làm việc. Quan trọng hơn cả Techcombank đang phát triển văn hoá dữ liệu từ tất cả các khối, phòng ngoài dữ liệu, từ đó có thể thúc đẩy nhiều hơn nữa những dự án khoa học dữ liệu sáng tạo, có sức ảnh hưởng lớn.   

Theo anh, đâu là những kỹ năng và kiến thức cần có dành cho những bạn muốn trở thành một Data Scientist trong tương lai?

Techcombank có nhiều bạn Intern, sinh viên mới ra trường đang theo đuổi trở thành nhà khoa học dữ liệu. Cũng như mọi ngành nghề khác chúng ta đều cần tư duy giải quyết vấn đề sáng tạo, tư duy thiết kế, phản biện. Đầu tiên nhà khoa học dữ liệu luôn phải thiết kế, chuyển đổi các yêu cầu, mục tiêu của các bài toán kinh doanh thành các bài toán học máy, trí tuệ nhân tạo. Cụ thể chúng ta cần một số kiến thức, kỹ năng như:

• Kiến thức về Khoa học dữ liệu, Học máy, Tính toán, Thống kê
• Kiến thức, kỹ năng về lập trình, tính toán phân tán cho dữ liệu lớn
• Kiến thức, kỹ năng về cấu trúc, kiến trúc dữ liệu, tiền xử lý, trực quan hoá dữ liệu 
• Kỹ năng nghiên cứu, thích khám phá, thử nghiệm, tập trung, tỉ mỉ
• Kỹ năng giao tiếp, trình bày, do trong vòng đời phát triển mô hình học máy chúng ta luôn phải kết hợp, đánh giá hiệu quả mô hình, nhận phản hồi với/từ các đơn vị kinh doanh 
• Kiến thức đại cương về các nguyên lý cơ bản trong kinh tế, tài chính, các sản phẩm trong ngân hàng

Cảm ơn anh về những chia sẻ rất bổ ích giúp đem lại nhiều góc nhìn tích cực cho những ai đang muốn tham gia vào lĩnh vực Khoa học dữ liệu tại ngân hàng, hy vọng team AAI của Techcombank sẽ gặt hái được nhiều thành công trong tương lai. 

Thuộc dự án “Inside GemTechnology“ do TopDev hợp tác cùng Techcombank triển khai, chuỗi nội dung thuần “Tech” độc quyền được chia sẻ bởi đội ngũ chuyên gia Công nghệ & Dữ liệu tại Techcombank sẽ được cập nhật liên tục tại chuyên mục Tech Blog | Techcombank Careers x TopDev. Cùng theo dõi & gặp gỡ các chuyên gia bạn nhé!

Các cơ hội việc làm tại Techcombank

Senior Data Engineer

Quận Cầu Giấy, Hà Nội - Quận 1, Hồ Chí Minh

Ngân Hàng

Đăng nhập để xem mức lương

JavaPythonScalaData Engineer

Ứng tuyển

Expert, Software Engineering (Data Operations)

Quận Cầu Giấy, Hà Nội - Quận 1, Hồ Chí Minh

Ngân Hàng

Đăng nhập để xem mức lương

PythonAWSCI/CDSoftware EngineerETLData Operation

Ứng tuyển

TECH & DATA MANAGEMENT ASSOCIATE ( 18-MONTH FAST TRACK)

Quận Hoàn Kiếm, Hà Nội - Quận 1, Hồ Chí Minh

Ngân Hàng

Đăng nhập để xem mức lương

JavaPython.NETBig DataQA/QCDatabase AdministratorNetworkIT SecurityData Architecture

Ứng tuyển

Bài viết liên quan

Hơn cả một phương pháp, DevSecOps chính là “triết lý bảo mật” tại Techcombank

Là một thành viên mới tại Techcombank, anh Bùi Nguyễn Tuấn Minh hiện đang là Giám đốc DevSecOps, đây cũng là công việc đầu tiên của anh sau những năm tháng làm việc tại Singapore. Anh cũng là một trong những người góp phần mang lại những góc nhìn mới trong các phương pháp phát triển phần mềm của Techcombank. Được biết, Techcombank là một trong những đơn vị tiên phong ứng dụng phương pháp DevSecOps trong việc phát triển sản phẩm. Đây cũng được xem là một trong những định hướng giúp các ngân hàng số hóa và phát triển mạnh mẽ trong tương lai. Sau đây là những chia sẻ của anh Bùi Nguyễn Tuấn Minh về công việc DevSecOps tại Techcombank. Anh có thể chia sẻ một chút về môi trường làm việc tại Techcombank? Khi chuyển công tác từ Singapore về Việt Nam, mình nhận thấy môi trường và cách thức làm việc [...]

Chia sẻ từ TechcombankLập Trình

Chi tiết

DevSecOps Philosophy (Triết lý DevSecOps)

Bài viết đến từ Ngô Doãn Thông - DevSecOps Engineer    DevSecOps team @Techcombank Giới thiệu Trong 20 năm qua, DevOps đã cùng với Agile, thay thế cho mô hình phát triển Waterfall. Microservices được coi là công nghệ tiên tiến nhất để triển khai kiến trúc dịch vụ. Thời gian phát triển sản phẩm đã được giảm đi, triển khai tự động được thực hiện hàng tuần hoặc hàng ngày và cloud thì cung cấp khả năng tính toán, cơ sở hạ tầng, lưu trữ và mạng rất mạnh mẽ. Triết lý DevOps thường được tóm tắt bằng khẩu hiệu "move fast and break things", điều này có nghĩa là triển khai mọi thứ nhanh hơn, mạnh dạn hơn và sẵn sàng, phá bỏ các cấu trúc silo, rào cản, chấp nhận rủi ro và khắc phục nhanh từ những rủi ro đó. Tuy nhiên, có một yếu tố quan trọng chưa được đề cập tới. Các tổ chức áp dụng DevOps vẫn cần đáp ứng tiêu chuẩn an [...]

Lập TrìnhChia sẻ từ Techcombank

Chi tiết

Bài viết đến từ Ngô Doãn Thông – DevSecOps Engineer

   DevSecOps team @Techcombank

Giới thiệu

Trong 20 năm qua, DevOps đã cùng với Agile, thay thế cho mô hình phát triển Waterfall. Microservices được coi là công nghệ tiên tiến nhất để triển khai kiến trúc dịch vụ. Thời gian phát triển sản phẩm đã được giảm đi, triển khai tự động được thực hiện hàng tuần hoặc hàng ngày và cloud thì cung cấp khả năng tính toán, cơ sở hạ tầng, lưu trữ và mạng rất mạnh mẽ.

Triết lý DevOps thường được tóm tắt bằng khẩu hiệu “move fast and break things”, điều này có nghĩa là triển khai mọi thứ nhanh hơn, mạnh dạn hơn và sẵn sàng, phá bỏ các cấu trúc silo, rào cản, chấp nhận rủi ro và khắc phục nhanh từ những rủi ro đó.

Tuy nhiên, có một yếu tố quan trọng chưa được đề cập tới. Các tổ chức áp dụng DevOps vẫn cần đáp ứng tiêu chuẩn an ninh thông tin và tuân thủ quy định. Sự linh hoạt, đa dạng và tính mở của chuỗi cung ứng phần mềm (software supply chain), đặc biệt là các phần mềm mã nguồn mở, buộc chúng ta phải đánh giá đến yếu tố security này.

Đó là giá trị cốt lõi của DevSecOps: Tưởng tượng ra các giải pháp an ninh mới để bảo vệ phần mềm cũng như quy trình phát triển phần mềm.

Tuy nhiên, đó là một con đường không hề dễ dàng. Cần có một sự hợp tác giữa các nhóm phát triển sản phẩm, đội an ninh thông tin và vận hành để làm cho “security” trở thành quá trình thông suốt. Software supply chain và các CI/CD pipeline là những thành phần vô cùng quan trọng cần được bảo vệ khi áp dụng DevSecOps.

Security: Bảo vệ thông tin cũng như tốc độ phát triển sản phẩm

Có một sự thật là việc áp dụng các tiêu chuẩn an ninh thông tin vào có thể là rào cản làm chậm quá trình phát triển phần mềm. Khi mà time-to-market là quan trọng, thì việc áp dụng tiêu chuẩn an ninh thông tin vào có thể trở thành “bottleneck”. Một số rào cản, vấn đề có thể đưa ra như sau:

• Thiếu chuyên môn về security hoặc khả năng viết code an toàn trong suốt vòng đời phát triển sản phẩm. Developer thường được chấp nhận để triển khai nhanh hơn và khắc phục sau.
• Security ownership: Ai chịu trách nhiệm về mặt security này? Nhà cung cấp dịch vụ cloud? Hay maintainer của các sản phẩm mã nguồn mở? Ta có thể thường mặc nhiên cho rằng các nhà cung cấp dịch vụ, phần mềm khác đã đảm bảo security cho ta khi ta sử dụng. Tuy nhiên đó là một giả định sai lầm.
• Chuyên gia an ninh và kỹ sư phần mềm hoạt động độc lập với nhau, vì vậy an ninh bị đe dọa bởi sự thiếu giao tiếp, thiếu sự phối hợp từ đầu.

Những vấn đề này có thể gây ra những rủi ro tiềm ẩn về mặt security. Nhưng bản thân chúng cũng có thể giúp các tổ chức xây dựng một thái độ thận trọng hơn trước những rủi ro.

Khi mà hệ thống được mở rộng và trở nên phức tạp hơn, các tổ chức sẽ có xu hướng đánh giá nghiêm túc hơn về những rủi ro. Nỗi lo lắng về việc thiếu các tiêu chuẩn an ninh thông tin có thể ảnh hưởng lớn đến toàn bộ sản phẩm, quy trình phát triển tự động hóa, sẽ khiến các tổ chức chủ động tiếp cận đến với các giải pháp quản lý và ngăn ngừa rủi ro hơn.

Security: Sự bổ sung cho DevOps

Nắm bắt được những điểm yếu trong quá trình phát triển phần mềm

Hiện nay, các team DevOps hiện đại hiểu được tầm quan trọng của software supply chain trong chu trình phát triển sản phẩm. Supply chain là thuật ngữ rộng lớn bao gồm rất nhiều thứ khác nhau (công cụ mã nguồn mở hoặc đóng, dependency, platform…) để mô tả cách thức xây dựng phần mềm hiện đại. Software supply chain là một “con đường”, là một cấu trúc phân lớp bao gồm các phần cứng, Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS), và các công cụ khác, được kết hợp cùng với nhau để hỗ trợ cho phần mềm cũng như quá trình phát triển phần mềm đó.

Hiếm khi ta thấy được một công ty làm phần mềm mà có 100% phần mềm, công cụ được sử dụng là do họ tự phát triển. Hầu hết các công ty phần mềm hiện đại đều sử dụng hàng trăm, nếu không phải là hàng ngàn các building block, các thư viện và công cụ mã nguồn mở, các hệ thống triển khai, cơ sở hạ tầng đám mây và dịch vụ SaaS. Mỗi block này lần lượt là sản phẩm cuối cùng từ một supply chain riêng của nó, mà khi sử dụng, ta không kiểm soát được cũng như không có khả năng nhìn thấy được supply chain trước đó của nó.

CI/CD pipeline

CI/CD pipeline là xương sống, là trụ cột của DevOps. Nó dùng để kết nối developer tới các môi trường triển khai, dùng để tối ưu hóa 4 luồng sau đây:

• Continuous integration: Tích hợp liên tục. Tự động hóa việc xây dựng các bản build ứng dụng từ source code và các library, dependency của chúng.
• Continuous testing: Kiểm thử liên tục. Tự động hóa việc kiểm thử ứng dụng sau mỗi commit.
• Continuous monitoring: Giám sát liên tục. Tự động hóa việc thu thập các dữ liệu về log, metric của ứng dụng cũng như hạ tầng trên từng môi trường triển khai.
• Continuous delivery/deployment: Triển khai liên tục. “One-click” để triển khai toàn bộ ứng dụng lên bất cứ môi trường nào.

4 luồng này, được tích hợp trong các CI/CD pipeline, để nhắm tới mục tiêu tối thượng cuối cùng của DevOps, đó là: Continuous improvement – Cải tiến liên tục.

Lợi thế mà những CI/CD pipeline này đem lại là rất lớn. Chúng giúp cho từng thay đổi nhỏ cũng có thể được triển khai (cũng như phục hồi, rollback) một cách nhanh chóng và chính xác.

Tuy nhiên, bản thân chúng cũng tồn tại những mối rủi ro. Mỗi stage trong một CI/CD pipeline là một “interface” có thể bị tấn công, khai thác. Điều đáng lo ngại hơn là mỗi stage có thể đại diện cho mục tiêu có giá trị cao đối với các kẻ tấn công: Không chỉ vì nó có thể lưu giữ các secret, credential, mà còn vì đây là nơi mà một kẻ tấn công có thể thay đổi mã nguồn, thay đổi cấu hình nào đó một cách lặng lẽ ngay giữa luồng build và deploy mà không ai có thể can thiệp được bởi luồng này đang vận hành tự động.

Kết quả là, supply chain cũng như CI/CD pipeline đang trở nên ngày càng dễ bị tấn công do tính mở và phức tạp của chúng. Chúng để lại rất nhiều vùng xám chưa rõ ràng trong các security framework truyền thống.

Từ DevOps tới DevSecOps

DevSecOps là gì?

DevSecOps là kết hợp của việc tích hợp giữa những công cụ, tiêu chuẩn của Security và triết lý “Continuous improvement” của DevOps thành một phương pháp, quy trình phát triển, triển khai phần mềm nhất quán, tự động, hiệu quả và đảm bảo an toàn bảo mật.

DevSecOps sẽ giúp nhận diện các vấn đề an ninh sớm trong quá trình phát triển thay vì sau khi sản phẩm được release như trước kia.

DevSecOps có thể giảm chi phí liên quan đến việc khắc phục những lỗ hổng an ninh bằng cách tích hợp các công cụ security vào mỗi giai đoạn của quá trình phát triển, có thể ngay từ giai đoạn đưa ra yêu cầu, thiết kế trở đi.

Nguyên tắc bảo mật phải là một phần không thể thiếu trong văn hóa của bất kỳ công ty nào. An ninh thông tin phải là một phần của quá trình phát triển phần mềm. Nói ngắn gọn, DevSecOps sẽ giúp đưa những nguyên tắc, trách nhiệm đó đến với từng developer, đến từng bước trong quá trình phát triển phần mềm.

Giá trị cốt lõi của DevSecOps

Tăng tần suất triển khai ứng dụng an toàn

Khi security bao trùm lên toàn bộ CI/CD pipeline, chất tốc độ sẽ sản phẩm được cải thiện. Ta phải thực tế và chấp nhận rằng giai đoạn đầu của việc tích hợp có thể sẽ rất khó khăn. Khi việc phối hợp giữa các nhóm phát triển và security trở nên mượt mà hơn, những vấn đề này sẽ dần biến mất và chỉ còn lại kết quả tích cực.

Giảm thời gian khắc phục các lỗ hổng nguy hiểm

DevSecOps sẽ cải thiện đáng kể thời gian khắc phục trung bình nhờ việc rà quét sớm và tự động, có luồng feedback tốt hơn và mô hình chia sẻ trách nhiệm. Khi trách nhiệm về security được chia sẻ trên toàn bộ CI/CD pipeline cũng như trong quy trình phát triển phần mềm, thay vì tách biệt hoàn toàn về một nhóm security, các vấn đề an ninh được phát hiện sớm và nhanh hơn. Điều này cũng trực tiếp liên quan đến hiệu quả chi phí, vì nó sẽ tốn nhiều tiền hơn để khắc phục lỗi được tìm thấy trong quá trình vận hành hơn là sửa lỗi được xác định trong giai đoạn thiết kế phát triển.

Cải thiện tư duy về an ninh thông tin

Nói chung, việc phát triển phần mềm hiện nay tương đối là phức tạp. Đưa security vào như một “tính năng” từ đầu sẽ giúp tiết kiệm rất nhiều thời gian cho các nhóm security bằng cách loại bỏ các vấn đề vô hại hoặc false positive nhờ vào các quy trình tự động kiểm soát ở mỗi bước. Nó sẽ tạo ra một nền văn hóa mới, tư duy mới, nơi các phương pháp an ninh tốt nhất được chia sẻ và đem đến lợi ích cho tất cả – bắt đầu ngay từ bước thiết kế, phát triển cho tới quá trình triển khai, vận hành phần mềm ứng dụng.

Best practices

DevSecOps nhấn mạnh rằng security là trách nhiệm của tất cả thành viên trong một tổ chức, và mọi người đều phải tuân thủ và thực hiện đảm bảo an toàn bảo mật thông tin.

Chìa khoá để áp dụng thành công mô hình DevSecOps nằm ở ba yếu tố: Con người, quy trình và công nghệ.

Yếu tố con người

Không quan trọng bao nhiêu công nghệ được áp dụng, yếu điểm lớn nhất về mặt an ninh thông tin luôn là con người. Đây cũng là điểm khởi đầu cho bất cứ quá trình áp dụng DevSecOps nào.

Một trong những điều quan trọng nhất nhưng cũng là khía cạnh khó nhất của DevSecOps là thay đổi cách làm việc truyền thống của security team. Đa số cách tiếp cận rủi ro là loại bỏ khi nó đã xảy ra, thay vì chủ động phòng bị trước.

Security team cần chuyển từ việc hoạt động độc lập sang việc tham gia cùng trong luồng phát triển phần mềm. Điều này vừa giúp tăng nhận thức về an ninh thông tin tới tất cả thành viên trong đội dự án, vừa giúp nhận biết sớm các rủi ro tiềm tàng trong phần mềm, trong hệ thống.

Tại Techcombank, DevSecOps team sẽ nhắm tới việc phá bỏ rào cản này giữa security team và project team, đồng thời cung cấp những chính sách và công cụ hỗ trợ cho việc này. Việc tạo ảnh hưởng đến yếu tố con người này sẽ đặt nền móng vững chắc cho việc thay đổi hai yếu tố “Quy trình” và “Công nghệ” tiếp theo của DevSecOps.

Yếu tố quy trình

Các quy trình thông thường được quy phạm tới từng team và thường ít khi có sự chia sẻ giữa các team với nhau. Điều này có thể gây ra ảnh hưởng tới năng suất trong cả một tổ chức. DevSecOps hướng tới việc thiết lập các quy trình tiêu chuẩn chung, các tài liệu đảm bảo security cho tổ chức để tạo sự phối hợp giữa các team như là một khối thống nhất. Việc xây dựng ra một quy trình, tiêu chuẩn tự động hoá đảm bảo an toàn thông tin là trách nhiệm của team DevSecOps tại Techcombank.

Version control

Khi mọi thứ được tự động hoá, thứ quan trọng nhất cần được track đó là các thay đổi (changes). Mỗi hành động tạo ra changes phải được quản lý bởi version, cũng giống như version control khi code vậy. Việc versioning này sẽ giúp ta ghi lại được lịch sử thực hiện cũng như dễ dàng khi khôi phục lại. Để đáp ứng yếu tố này, DevSecOps team ở Techcombank đã xây dựng một hệ thống Gitlab private nhằm lưu trữ tất cả các mã nguồn được viết ra bởi developer.

Tích hợp

Security cần phải được đưa vào quá trình phát triển sản phẩm sớm nhất có thể, ngay từ bước thiết kế. Phương pháp này được gọi là “shift left” hay “shift security to the left”.

Techcombank áp dụng những công cụ rà soát an ninh thông tin tự động ngay từ giai đoạn đầu của việc phát triển ứng dụng. Điều này vừa giúp những vấn đề về an ninh được phát hiện và ngăn chặn sớm, đồng thời cũng giúp các developer có nhận thức tốt hơn về việc viết code an toàn.

Compliance

Tuân thủ compliance là điều bắt buộc. Nếu nền móng về yếu tố con người đã được thực hiện tốt trước đó, thì việc tuyên truyền về việc tuân thủ compliance sẽ trở nên rất đơn giản và hiệu quả. Bên cạnh đó, compliance có thể không chỉ là các văn bản quy phạm. Ta hoàn toàn có thể xây dựng các metadata biểu diễn cho các compliance requirement và đưa vào các security policy để thực hiện tự động hoá.

Xử lý sự cố

Phản ứng với các sự cố liên quan tới an ninh thông tin không nên là tạm bợ nhất thời. Thay vào đó, việc xây dựng workflow, action plan, runbook, playbook luôn cần được chuẩn bị sẵn sàng từ trước. Điều này sẽ đảm bảo việc phản ứng với các sự cố trở nên có tính chắc chắn, có khả năng đo đếm và nhanh chóng hơn. Theo quy trình và tiêu chuẩn DevSecOps tại Techcombank, các kịch bản khôi phục sự cố cần được thực hiện dưới dạng code và tự động thông qua CI/CD pipeline. Điều này sẽ giúp việc ứng phó sự cố hệ thống trên môi trường live được thực hiện nhanh chóng hơn và số lượng sự cố trong quá trình triển khai cũng sẽ giảm đi.

Yếu tố công nghệ

Công nghệ là thứ cho phép mọi người thực hiện được các quy trình DevSecOps. Đây cũng là yếu tố cuối cùng quyết định việc áp dụng DevSecOps của một tổ chức có đủ trưởng thành, có thành công hay không.

Tự động hóa việc quản lý cấu hình

Tổ chức quản lý và tự động hóa việc quản lý cấu hình dưới dạng code sẽ giúp việc audit, việc đảm bảo baseline, compliance trở nên dễ dàng hơn rất nhiều. Các template dưới dạng code được đưa ra giúp việc rà soát các thay đổi được kiểm soát qua version control, rollback, phục hồi cũng trở nên rất nhanh chóng.

Tại Techcombank, Puppet được sử dụng như là một công cụ kiểm soát cấu hình. Các cấu hình đạt tiêu chuẩn baseline sẽ được định nghĩa trước và quản trị thông qua Puppet. Mọi hành vi cố ý thay đổi ngoài baseline sẽ luôn được phục hồi lại nhanh chóng.

Host hardening

Trước khi bảo mật đến tầng ứng dụng, tầng OS cần phải được an toàn trước. Có vô số những sự cố an ninh bắt nguồn từ việc host, đặc biệt là các host bị expose ra internet, bị khai thác. Do đó, một hardening checklist là rất cần thiết trong việc xây dựng template cũng như trust model cho việc cấu hình host. Kết hợp với tự động hóa việc quản lý cấu hình, host sẽ luôn được đảm bảo ở trạng thái an toàn cao nhất. 

Audit và scan tại tầng ứng dụng

Việc thực hiện audit và scan liên tục là một phương diện thiết yếu của DevSecOps, giúp cho tổ chức hiểu được rõ ràng về các mối nguy. Các giải pháp hiện tại ở Techcombank gồm có:

• Quét mã nguồn: Việc quét mã nguồn có thể được thực hiện bằng cách áp dụng các SAST tool (Static Application Security Testing). SAST tool phân tích mã nguồn của dự án để xác định ra các lỗi liên quan đến bảo mật trong code cũng như vấn đề của các dependency và library mà ứng dụng sử dụng. Các công cụ được DevSecOps team đưa vào tiêu chuẩn gồm có SonarQube và Synopsys Coverity.
• Tích hợp vào IDE: Mọi developer đều cần sử dụng IDE trong việc code. Sử dụng một số plugin trong IDE sẽ giúp ngăn chặn một phần lỗi trong code ngay từ máy cá nhân của developer trước khi cả commit code lên repository. Hiện tại, việc ngăn chặn này đang được thực hiện bằng pre-commit và sắp tới là SonarLint
• Binary scanning: Các package của ứng dụng sau khi được build ra cần phải được rà quét lại dưới dạng binary bằng Synopsys BlackDuck. Việc một lần nữa rà quét lại bản build này giúp đảm bảo chắc chắn rằng phần mềm kể cả đã đóng gói cũng đảm bảo an toàn thông tin.
• Audit trước và sau triển khai: Thêm một bước audit trước và sau triển khai sẽ đảm bảo ứng dụng an toàn tại day-0 và cả day-1 khi triển khai.

Quản lý secret

Secret và credential là các dữ liệu nhạy cảm hoặc thậm chí là tối mật được sử dụng cho ứng dụng. Trong quá trình thực hiện CI/CD, việc sử dụng đến các secret hay credential là một việc thường xuyên xảy ra. Do vậy, sử dụng các công cụ mã hoá và lưu trữ các dạng dữ liệu này là tối quan trọng, đặc biệt trong CI/CD pipeline. Các công cụ, nền tảng hỗ trợ cho việc này đang được áp dụng tại Techcombank có thể kể đến như HashiCorp Vault, AWS Secrets Manager, GPG, Ansible Vault…

Tổng kết

DevSecOps chuyển dịch security từ phản ứng sang chủ động tham gia vào quy trình phát triển phần mềm. Những ưu điểm mà DevSecOps mang lại cho tổ chức là rất nhiều, bao gồm giảm thiểu chi phí, tăng tốc độ triển khai, tăng tốc độ phục hồi, kiểm soát và truy tìm các mối nguy. DevSecOps cũng phá bỏ đi rào cản giữa DevOps và Security, giúp tất cả cùng hoạt động hướng tới những mục tiêu chung của tổ chức.

Thuộc dự án “Inside GemTechnology“ do TopDev hợp tác cùng Techcombank triển khai, chuỗi nội dung thuần “Tech” độc quyền được chia sẻ bởi đội ngũ chuyên gia Công nghệ & Dữ liệu tại Techcombank sẽ được cập nhật liên tục tại chuyên mục Tech Blog | Techcombank Careers x TopDev. Cùng theo dõi & gặp gỡ các chuyên gia bạn nhé!

Các cơ hội việc làm tại Techcombank

Manager DevSecOps

Quận Cầu Giấy, Hà Nội - Quận 1, Hồ Chí Minh

Ngân Hàng

Đăng nhập để xem mức lương

LinuxDevOpsCloudSecurity Engineer

Ứng tuyển

Expert, Software Engineering (Data Operations)

Quận Cầu Giấy, Hà Nội - Quận 1, Hồ Chí Minh

Ngân Hàng

Đăng nhập để xem mức lương

PythonAWSCI/CDSoftware EngineerETLData Operation

Ứng tuyển

(Senior) Enterprise Architect

Quận Cầu Giấy, Hà Nội - Quận 1, Hồ Chí Minh

Ngân Hàng

Đăng nhập để xem mức lương

AWSSolution Architect

Ứng tuyển

Bài viết liên quan

Hơn cả một phương pháp, DevSecOps chính là “triết lý bảo mật” tại Techcombank

Là một thành viên mới tại Techcombank, anh Bùi Nguyễn Tuấn Minh hiện đang là Giám đốc DevSecOps, đây cũng là công việc đầu tiên của anh sau những năm tháng làm việc tại Singapore. Anh cũng là một trong những người góp phần mang lại những góc nhìn mới trong các phương pháp phát triển phần mềm của Techcombank. Được biết, Techcombank là một trong những đơn vị tiên phong ứng dụng phương pháp DevSecOps trong việc phát triển sản phẩm. Đây cũng được xem là một trong những định hướng giúp các ngân hàng số hóa và phát triển mạnh mẽ trong tương lai. Sau đây là những chia sẻ của anh Bùi Nguyễn Tuấn Minh về công việc DevSecOps tại Techcombank. Anh có thể chia sẻ một chút về môi trường làm việc tại Techcombank? Khi chuyển công tác từ Singapore về Việt Nam, mình nhận thấy môi trường và cách thức làm việc [...]

Chia sẻ từ TechcombankLập Trình

Chi tiết

Infrastructure as code (IaC)

Bài viết đến từ anh Bùi Nguyễn Huy Hoàng - Quản lý DevSecOps DevSecOp team @Techcombank I. Tại sao lại sử dụng Infrastructure as Code? Những công việc như ảo hóa, điện toán đám mây (Cloud), container, tự động hóa (CI/CD) giúp đơn giản hóa công việc vận hành hành công nghệ thông tin (IT Operations). Việc triển khai, cấu hình, cập nhật và vận hành dịch vụ sẽ tiêu tốn ít thời gian và công sức hơn. Vấn đề sẽ được phát hiện và giải quyết nhanh chóng, các hệ thống luôn được cấu hình và cập nhật một cách đồng nhất. Những kỹ sư IT sẽ tiết kiệm được thời gian trong công việc vận hành hàng ngày, để có thể nhanh chóng thay đổi, học hỏi và cải tiến bản thân đáp ứng nhu cầu thay đổi liên tục của thế giới công nghệ. Tuy nhiên, ngay cả với những công cụ và nền tảng mới nhất, các [...]

Chia sẻ từ TechcombankLập Trình

Chi tiết