Trong thời đại số hóa ngày nay, công nghệ AI đang góp phần thay đổi toàn diện cách chúng ta sống và làm việc.
Thị giác máy tính, một lĩnh vực quan trọng của trí tuệ nhân tạo (AI), đã trở thành một phần không thể thiếu trong việc xử lý và phân tích dữ liệu hình ảnh và video.
Bài viết này khám phá sự quan trọng, ứng dụng, và cơ hội trong ngành này, giúp bạn đọc hiểu rõ hơn và chuẩn bị hành trang cần thiết để bước vào thế giới AI thị giác máy tính.
Tầm quan trọng của AI thị giác máy tính trong thời đại số
AI thị giác máy tính là gì?
Thị giác máy tính, hay Computer Vision, là một nhánh của AI tập trung vào việc cho phép máy tính “nhìn thấy” và hiểu được hình ảnh hoặc video như con người.
Công nghệ này sử dụng các thuật toán học máy để nhận diện và phân tích các đối tượng và thông tin trong dữ liệu hình ảnh, từ đó đưa ra kết luận hoặc hành động thích hợp.
Thị giác máy tính được ví như đôi mắt của máy móc, giúp chúng tham gia và tương tác một cách thông minh hơn vào cuộc sống hàng ngày.
Ứng dụng của AI thị giác máy tính trong cuộc sống
AI thị giác máy tính có nhiều ứng dụng đa dạng trong thực tế:
Y tế: Tự động hóa chẩn đoán bệnh bằng cách phân tích hình ảnh y khoa như X-quang và MRI.
Thương mại: Giám sát an ninh, nhận diện khuôn mặt trong thanh toán qua điện thoại.
Nông nghiệp: Phân tích hình ảnh nông sản để giám sát sức khỏe cây trồng và tối ưu hóa thu hoạch.
Tự động hóa giao thông: Nhận diện biển báo giao thông và hỗ trợ đỗ xe tự động.
Các dự án thị giác máy tính nổi bật
Dự án nhận diện khuôn mặt
Nhận diện khuôn mặt là một công nghệ nổi bật trong thị giác máy tính, được ứng dụng nhiều trong an ninh và thanh toán. Các thuật toán tiên tiến có khả năng quét và xác định danh tính dựa trên các đặc điểm khuôn mặt, từ đó cải thiện tính bảo mật và tiện lợi.
Dự án phân loại hình ảnh
Phân loại hình ảnh là một dự án thị giác máy tính phổ biến khác, cho phép máy tính phân loại hoặc xác định các vật thể trong hình ảnh. Điều này được ứng dụng rộng rãi trong các hệ thống tìm kiếm và nhận dạng sản phẩm trực tuyến.
Dự án tự động hóa giám sát
Tự động hóa giám sát sử dụng camera thông minh để theo dõi và phân tích hành vi con người hoặc đối tượng trong môi trường. Đây là công cụ hữu hiệu trong việc đảm bảo an ninh, quản lý tự động và hỗ trợ giám sát giao thông.
Làm thế nào để trở thành kỹ sư thị giác máy tính
Kỹ năng cần thiết cho kỹ sư thị giác máy tính
Để trở thành kỹ sư thị giác máy tính, bạn cần sở hữu một số kỹ năng quan trọng:
Khả năng lập trình máy tính mạnh mẽ, với các ngôn ngữ như Python, C++.
Kiến thức về học máy và mạng nơ-ron nhân tạo.
Kỹ năng xử lý và phân tích dữ liệu.
Tư duy logic và kỹ thuật giải quyết vấn đề xuất sắc.
Lộ trình học tập và phát triển
Bắt đầu với một nền tảng vững chắc về toán học và lập trình, tiếp đến nâng cao kỹ năng thông qua các khóa học online hoặc tại các trường đại học. Thực hiện các dự án thực tế và tham gia các cuộc thi về AI sẽ giúp củng cố kiến thức và khả năng thực hành.
Cơ hội việc làm trong lĩnh vực thị giác máy tính
Các vị trí công việc phổ biến
Một số vị trí công nghệ cao bao gồm kỹ sư thị giác máy tính, nhà khoa học dữ liệu, kỹ sư học máy và nhà phát triển phần mềm AI. Các công việc này đòi hỏi khả năng ứng dụng công nghệ thị giác máy tính để phát triển giải pháp thông minh.
Xu hướng tuyển dụng hiện nay
Hiện nay, nhu cầu tuyển dụng trong lĩnh vực AI, đặc biệt là thị giác máy tính, đang tăng mạnh. Các công ty công nghệ lớn đang tích cực tìm kiếm những nhân tài với kỹ năng và kiến thức vững vàng trong lĩnh vực này để đẩy mạnh phát triển sản phẩm và dịch vụ.
Khóa học thị giác máy tính: Lựa chọn và lợi ích
Tiêu chí chọn khóa học phù hợp
Khi chọn một khóa học thị giác máy tính, hãy tìm kiếm những khóa có nội dung chi tiết về học máy, xử lý hình ảnh và thực hành dự án. Khóa học nên do các chuyên gia trong ngành giảng dạy và cung cấp tài liệu học tập đầy đủ, cập nhật.
Lợi ích của việc tham gia khóa học
Tham gia khóa học giúp bạn nắm vững lý thuyết, ứng dụng thực tế, và mở rộng mạng lưới quan hệ trong ngành. Bạn có thể thử sức với các dự án thực tế và chuẩn bị tốt hơn cho cơ hội nghề nghiệp trong tương lai, đồng thời nâng cao giá trị bản thân trong môi trường công nghệ cạnh tranh.
Sự phát triển của AI thị giác máy tính không chỉ làm thay đổi diện mạo của ngành công nghệ mà còn mở ra một chương mới trong các lĩnh vực đa dạng khác trên toàn cầu.
Trong bối cảnh công nghệ ngày càng tiến bộ, Mô hình Ngôn ngữ Lớn (LLMs) đã trở thành một thành tựu nổi bật, mở ra nhiều cơ hội ứng dụng đầy hứa hẹn. Với khả năng học hỏi và xử lý ngôn ngữ tự nhiên một cách thông minh và hiệu quả, LLMs đang tạo ra ảnh hưởng sâu rộng trên nhiều lĩnh vực, từ nghiên cứu và giáo dục cho đến kinh doanh và công nghiệp.
Mô hình Ngôn ngữ Lớn là gì?
Mô hình Ngôn ngữ Lớn (Large Language Models) là một loại trí tuệ nhân tạo được thiết kế để hiểu và tạo ra ngôn ngữ tự nhiên với độ chính xác cao. LLMs sử dụng các mạng neuron để dự đoán từ tiếp theo trong một câu, cho phép chúng viết, dịch và thậm chí suy luận trên ngữ liệu cấu trúc lớn. Những mô hình tiên tiến như GPT-3 và BERT đã chứng tỏ khả năng ấn tượng trong các tác vụ liên quan đến ngôn ngữ, mở ra nhiều cơ hội ứng dụng mới.
Lịch sử phát triển của LLMs
Lịch sử của các mô hình ngôn ngữ lớn (LLMs) thực sự bắt đầu từ những năm 1980, khi mà các nhà nghiên cứu trong lĩnh vực trí tuệ nhân tạo bắt đầu tiến hành các thí nghiệm với mạng neuron và các phương pháp học sâu. Những nỗ lực ban đầu này đã đặt nền móng cho sự phát triển của các công nghệ ngôn ngữ hiện đại mà chúng ta thấy ngày nay. Tuy nhiên, phải đến những năm 2010, với sự ra đời của các mô hình tiên tiến như mạng hồi tiếp (RNNs) và Transformer, LLMs mới thực sự bắt đầu nổi bật và thu hút sự chú ý của cộng đồng nghiên cứu cũng như ngành công nghiệp.
Đặc biệt, vào năm 2018, mô hình BERT (Bidirectional Encoder Representations from Transformers) do Google phát triển đã trở thành một bước đột phá quan trọng trong lĩnh vực xử lý ngôn ngữ tự nhiên. Mô hình này không chỉ cải thiện khả năng hiểu ngữ nghĩa của văn bản mà còn mở ra nhiều cơ hội mới cho các ứng dụng trong nhiều lĩnh vực khác nhau, từ tìm kiếm thông tin đến dịch thuật tự động.
Không lâu sau đó, vào năm 2020, OpenAI đã ra mắt GPT-3 (Generative Pre-trained Transformer 3), một mô hình ngôn ngữ lớn với sức mạnh xử lý vượt trội. GPT-3 đã gây ấn tượng mạnh mẽ với khả năng tạo ra văn bản tự nhiên, trả lời câu hỏi, và thậm chí là viết mã lập trình. Sự phát triển này không chỉ đánh dấu một bước tiến lớn trong công nghệ mà còn mở ra nhiều khả năng mới cho việc ứng dụng trí tuệ nhân tạo trong cuộc sống hàng ngày.
Tóm lại, hành trình phát triển của LLMs từ những năm 1980 cho đến nay đã chứng kiến nhiều bước tiến quan trọng, từ những thí nghiệm ban đầu cho đến những mô hình mạnh mẽ như BERT và GPT-3. Những tiến bộ này không chỉ thay đổi cách chúng ta tương tác với công nghệ mà còn định hình tương lai của trí tuệ nhân tạo trong nhiều lĩnh vực khác nhau.
Ứng dụng của Mô hình Ngôn ngữ Lớn trong thực tế
LLMs trong xử lý ngôn ngữ tự nhiên
LLMs có thể xử lý ngôn ngữ tự nhiên (NLP) với sự chính xác đáng kinh ngạc. Chúng không chỉ tham gia vào việc dịch ngôn ngữ mà còn hỗ trợ viết bài, tạo nội dung, và thậm chí là tạo lời thoại cho trò chơi và ứng dụng thực tế ảo. Với NLP, LLMs giúp cải thiện giao tiếp giữa máy và người, tạo ra các trải nghiệm người dùng cá nhân hóa.
Tác động của LLMs đến các ngành công nghiệp
Trong ngành công nghiệp, LLMs đã mang lại những thay đổi đáng kể. Trong lĩnh vực tài chính, chúng giúp phân tích dữ liệu nhanh hơn và chính xác hơn, từ đó ra quyết định đầu tư hợp lý. Trong y tế, LLMs hỗ trợ chẩn đoán và phân tích triệu chứng bệnh, cải thiện chất lượng chăm sóc sức khỏe. Ngoài ra, trong lĩnh vực truyền thông và giải trí, LLMs đóng vai trò tích cực trong việc phân phối nội dung và đề xuất phim, nhạc dựa trên sở thích của người dùng.
Lợi ích và thách thức của Mô hình Ngôn ngữ Lớn
Lợi ích của việc sử dụng LLMs
Lợi ích của LLMs nằm ở khả năng xử lý và phân tích dữ liệu ngôn ngữ khổng lồ trong thời gian ngắn. Chúng cung cấp khả năng dự đoán, dịch ngôn ngữ tự động và tăng cường chất lượng dịch vụ khách hàng. Ngoài ra, LLMs giúp giảm thiểu sai sót do con người trong công việc nhập liệu và phân tích, từ đó tăng cường hiệu suất lao động.
Những thách thức khi triển khai LLMs
Mặc dù có nhiều lợi ích, việc triển khai LLMs không phải lúc nào cũng dễ dàng. Một trong những thách thức lớn nhất là việc cần lượng dữ liệu và tài nguyên tính toán lớn để huấn luyện mô hình. Ngoài ra, việc đảm bảo tính công bằng và giảm thiểu thiên vị trong các mô hình là một vấn đề cần được chú ý đặc biệt.
Các công cụ và nền tảng phổ biến cho Mô hình Ngôn ngữ Lớn
Các công cụ mã nguồn mở cho LLMs
Trên thị trường hiện nay, có nhiều công cụ mã nguồn mở hỗ trợ phát triển LLMs. Hugging Face Transformers là một trong những thư viện nổi tiếng nhất, giúp các nhà phát triển tiếp cận và triển khai các mô hình tiên tiến một cách dễ dàng. Bên cạnh đó, TensorFlow và PyTorch cũng cung cấp nhiều công cụ hỗ trợ xây dựng mô hình ngôn ngữ.
Nền tảng thương mại hỗ trợ LLMs
Các nền tảng thương mại như Google Cloud AI, AWS với dịch vụ AI của mình, và Azure AI của Microsoft đều cung cấp các giải pháp dành cho LLMs. Những nền tảng này không chỉ cung cấp công cụ mà còn hỗ trợ tài nguyên điện toán đám mây, giúp doanh nghiệp triển khai LLMs nhanh chóng và hiệu quả.
Tương lai của Mô hình Ngôn ngữ Lớn
Xu hướng phát triển của LLMs
Trong tương lai, xu hướng phát triển của LLMs đang hướng đến việc tạo ra các mô hình hiệu quả hơn, sử dụng ít tài nguyên hơn nhưng vẫn đảm bảo tính chính xác và độ mạnh mẽ. Những kỹ thuật như mô hình nhẹ và việc tận dụng chiến lược học không giám sát sẽ giúp tiếp tục cải tiến khả năng của LLMs.
Tác động tiềm năng của LLMs trong tương lai
LLMs có tiềm năng mở rộng ứng dụng ra nhiều lĩnh vực mới như pháp lý, thiết kế và thậm chí là giáo dục. Chúng có thể tự động hóa nhiều tác vụ tẻ nhạt, tăng cường sáng tạo nội dung và cải thiện chất lượng giáo dục thông qua các tài liệu tương tác và cá nhân hóa. Tuy nhiên, một vấn đề đáng lo ngại là việc lạm dụng công nghệ này, đòi hỏi sự quản lý và điều tiết thích hợp.
Trong khi Mô hình Ngôn ngữ Lớn mang lại nhiều lợi ích đáng kể, việc phát triển và ứng dụng đòi hỏi sự cân nhắc kỹ lưỡng để đảm bảo khả năng và tính đạo đức của chúng được tối đa hóa.
Principal Software Engineer là một trong những cấp độ cao nhất mà một software engineer (kỹ sư phần mềm) có thể đạt được. Họ phát triển đội ngũ, đồng thời giám sát các bộ phận kỹ thuật trong các dự án phát triển phần mềm của công ty.
Trong bài viết này, chúng ta sẽ thảo luận về việc trở thành một Principal Software Engineer, cũng như làm rõ trách nhiệm và trình độ của họ.
Principal Software Engineer là gì?
Principal Software Engineer là một vai trò cấp cao trong lĩnh vực công nghệ phần mềm (software engineering).
Các cá nhân trong vai trò này thường có nhiều kinh nghiệm và chuyên môn về phát triển, kiến trúc và thiết kế phần mềm.
Họ đóng vai trò quan trọng trong việc lãnh đạo và hướng dẫn chỉ đạo kỹ thuật của một dự án hoặc một nhóm kỹ sư.
Principal software engineer là gì?
Nhiều người cho rằng sự khác biệt duy nhất giữa Software engineer, Software architect và Principal software engineer là về ngữ nghĩa.
Trong các công ty nhỏ với ngân sách eo hẹp, một người có thể đội hết những chiếc mũ này. Tuy nhiên, đối với các công ty lớn hơn, thì sự phân biệt thường rõ ràng.
Các cấp độ như sau:
Cấp 1: Software Engineer
Cấp 2: Senior Software Engineer
Cấp 3: Staff Engineer
Cấp 4: Principal Software Engineer
Cấp 5: Distinguish Engineer hoặc Fellow
Như bạn có thể thấy, principal software engineer có trình độ cao hơn senior engineer. Họ tập trung nhiều hơn vào công ty nói chung. Các senior engineer và các chuyên gia công nghệ khác hướng nỗ lực của họ vào việc cung cấp giải pháp cho một vấn đề hiện có.
Còn các principal software engineer tập trung phát triển các giải pháp hỗ trợ công ty. Họ chịu trách nhiệm phát triển đội ngũ và các khía cạnh kỹ thuật của các dự án công nghệ phần mềm. Nói tóm lại, nhiệm vụ của họ nặng về quản lý đội nhóm và quyết định phương hướng kỹ thuật của công ty.
Vai trò và trách nhiệm của Principal software engineer
Trách nhiệm của Principal software engineer thường bao gồm:
Vai trò & Trách nhiệm của Principal software engineer
Lãnh đạo kỹ thuật: Họ cung cấp khả năng lãnh đạo và hướng dẫn kỹ thuật cho các kỹ sư khác trong nhóm, thiết lập định hướng kỹ thuật tổng thể, xác định các phương pháp hay nhất và đảm bảo rằng nhóm tuân theo các tiêu chuẩn và hướng dẫn của ngành.
Thiết kế kiến trúc: principal software engineer tham gia thiết kế kiến trúc của các hệ thống phần mềm phức tạp. Họ đưa ra quyết định thiết kế tổng thể, chọn công nghệ và khuôn khổ phù hợp, đồng thời đảm bảo rằng kiến trúc phần mềm phù hợp với mục tiêu của dự án.
Đánh giá code và đảm bảo chất lượng: Họ đánh giá code do các thành viên khác trong nhóm gửi để đảm bảo chất lượng code, tuân thủ các tiêu chuẩn code và các thực hành tốt nhất. Họ giúp xác định các vấn đề tiềm ẩn, đề xuất cải tiến và cố vấn cho các kỹ sư cấp dưới.
Giải quyết vấn đề: principal software engineer thường giải quyết các vấn đề kỹ thuật thách thức nhất phát sinh trong quá trình phát triển dự án. Họ sử dụng sự hiểu biết sâu sắc về hệ thống phần mềm để khắc phục sự cố, tối ưu hóa hiệu suất và đưa ra các quyết định quan trọng.
Đổi mới và nghiên cứu: Họ luôn cập nhật những tiến bộ mới nhất trong phát triển phần mềm, công cụ và kỹ thuật. Họ cũng có thể tham gia vào các hoạt động nghiên cứu và phát triển để khám phá các công nghệ mới có thể mang lại lợi ích cho dự án hoặc công ty.
Hợp tác: principal software engineer làm việc chặt chẽ với product manager, designer và các bên liên quan khác để hiểu các yêu cầu và chuyển chúng thành các giải pháp kỹ thuật. Họ truyền đạt các khái niệm kỹ thuật phức tạp cho các thành viên nhóm không chuyên về kỹ thuật một cách hiệu quả.
Cố vấn và Huấn luyện: Họ cố vấn và huấn luyện các kỹ sư cấp cơ sở và cấp trung, giúp họ phát triển trong sự nghiệp và cải thiện kỹ năng kỹ thuật. Điều này bao gồm việc cung cấp hướng dẫn về thực hành mã hóa, kiến trúc và phát triển nghề nghiệp.
Ra quyết định: principal software engineer tham gia vào việc đưa ra các quyết định quan trọng về lựa chọn công nghệ, đánh đổi và ưu tiên dự án. Họ xem xét các yếu tố như khả năng mở rộng, khả năng bảo trì và hiệu suất khi đưa ra những quyết định này.
Bảo trì cơ sở mã: Họ có thể nắm quyền sở hữu các phần quan trọng của cơ sở mã, đảm bảo rằng chúng được duy trì, cập nhật và cải thiện tốt theo thời gian. Điều này giúp ngăn ngừa nợ kỹ thuật và đảm bảo tính ổn định lâu dài của phần mềm.
Principal software engineer thường được phân biệt với Senior software enigneer bởi phạm vi trách nhiệm rộng hơn, chuyên môn kỹ thuật sâu hơn và ảnh hưởng lớn hơn đến định hướng kỹ thuật của công ty hoặc dự án. Trách nhiệm và kỳ vọng chính xác có thể khác nhau giữa các công ty, nhưng vai trò này luôn liên quan đến sự kết hợp giữa lãnh đạo kỹ thuật, kiến trúc và cố vấn.
Dưới đây là một số nhiệm vụ mà họ thực hiện hàng ngày:
Phát triển và cung cấp các tiêu chuẩn, hướng dẫn kỹ thuật trong mọi hoạt động thiết kế và phát triển phần mềm
Hỗ trợ và tạo điều kiện bảo trì và nâng cấp các ứng dụng phần mềm hiện có
Cung cấp đánh giá thiết kế và đưa ra khuyến nghị kỹ thuật
Hỗ trợ toàn bộ vòng đời phát triển phần mềm (SDLC, software development life cycle)
Đảm bảo mọi dự án đều có chất lượng cao
Cố vấn và đào tạo kỹ sư phần mềm
Hỗ trợ phân tích và khắc phục sự cố của ứng dụng
Tạo ra các giải pháp kỹ thuật hiệu quả và có thể áp dụng, phù hợp với nhu cầu và yêu cầu kinh doanh
Đề xuất các công nghệ mới giúp nâng cao năng suất
Làm việc với các nhóm tròn việc lập kế hoạch, sắp xếp ưu tiên và hoàn thành nhiệm vụ dự án
Tham gia vào các hoạt động đánh giá rủi ro và giảm thiểu rủi ro
Thường xuyên tham dự các cuộc họp để thảo luận về các dự án, vấn đề và ý tưởng
Tham gia kiểm toán kỹ thuật và đảm bảo thực hiện các khuyến nghị
Thực hiện các bài thuyết trình kinh doanh cho ban quản lý
Phối hợp với QA để phát triển các trường hợp thử nghiệm, quy trình và kế hoạch
Kỹ năng và yêu cầu đối với Principal software engineer
Khi tuyển dụng principal software engineer, đây là những kỹ năng và yêu cầu mà các công ty tìm kiếm:
Bằng cử nhân về Kỹ thuật/Khoa học Máy tính hoặc các lĩnh vực liên quan
Kỹ năng cấp cao về ngôn ngữ lập trình (Java, JavaScript, v.v.)
Có kinh nghiệm về các phương pháp phát triển phần mềm khác nhau
Có kinh nghiệm phát triển và bảo trì các hệ thống web phức tạp
Hiểu biết cao về cả mặt phụ trợ và mặt trước của quá trình phát triển phần mềm
Kiến thức chuyên sâu về các công nghệ và công cụ phát triển phần mềm khác nhau
Kỹ năng phân tích xuất sắc
Kỹ năng giao tiếp tuyệt vời
Kỹ năng tổ chức và lập kế hoạch mạnh mẽ
Kỹ năng lãnh đạo và cố vấn đặc biệt
Ngoài ra, họ phải có kỹ năng lãnh đạo và tổ chức tốt vì họ sẽ dành nhiều thời gian làm nhiệm vụ quản lý hơn là nhiệm vụ kỹ thuật.
Mức lương dành cho Principal Software Engineer ở Mỹ
Mức lương cho Principal Software Engineer ở Mỹ có thể rất khác nhau tùy thuộc vào các yếu tố như vị trí, quy mô công ty, ngành, số năm kinh nghiệm và kỹ năng cá nhân.
Phạm vi thấp nhất: 120.000 USD – 150.000 USD mỗi năm
Hạng trung: 150.000 USD – 200.000 USD mỗi năm
Phạm vi cao: $200,000 – $250,000+ mỗi năm
Hãy nhớ rằng những con số này là gần đúng và có thể thay đổi đáng kể. Tại các trung tâm công nghệ lớn như San Francisco, New York và Seattle, mức lương có xu hướng cao hơn do chi phí sinh hoạt và nhu cầu về nhân tài kỹ thuật cao hơn. Ngoài ra, các công ty công nghệ có uy tín và các tổ chức lớn hơn có thể đưa ra mức lương cao hơn so với các công ty khởi nghiệp nhỏ hơn.
Ngoài ra, do ngành công nghệ phát triển nhanh chóng nên mức lương có thể thay đổi theo thời gian. Để có thông tin chính xác và cập nhật nhất, tốt nhất bạn nên tham khảo bảng việc làm, trang web nghiên cứu về lương hoặc báo cáo ngành cụ thể cho vị trí của bạn và năm hiện tại.
Câu hỏi phỏng vấn dành cho Principal Software Engineer
Bạn đã phát triển những loại phần mềm nào trước đây?
Theo bạn, những nguyên tắc nào tốt cho việc phát triển phần mềm?
Giải thích kiến trúc được sử dụng trong công việc trước đây của bạn. Lý do cho những lựa chọn này là gì?
Bạn làm cách nào để thiết kế các ứng dụng có thể mở rộng? Bạn có thể hướng dẫn chúng tôi qua quy trình của bạn không?
Bạn sẽ coi ngôn ngữ lập trình nào là ngôn ngữ lập trình hàng đầu của mình? Tại sao?
Bạn có thích đào tạo và cố vấn cho các kỹ sư phần mềm khác không?
Khi xem lại code của các thành viên trong nhóm, bạn thường xem hoặc kiểm tra những gì?
Kinh nghiệm làm việc phức tạp nhất mà bạn có là gì? Bạn đã giải quyết tình huống này như thế nào?
Kỹ sư nguyên tắc giỏi cần có những phẩm chất gì?
Bạn có thể giúp cải thiện nhóm phát triển phần mềm của chúng tôi như thế nào?
Cùng khám phá cách Amazon Search kết hợp giữa công nghệ và văn hóa để trao quyền cho các builder team của mình, đảm bảo khả năng phục hồi (resilience) của nền tảng thông qua Chaos Engineering.
Đây là câu chuyện về Kỹ thuật hỗn loạn (Chaos engineering) và cách các dịch vụ phân phối ở quy mô cao (hỗ trợ cho Search trên Amazon.com) sử dụng nó để đảm bảo rằng tất cả khách hàng có thể tìm kiếm danh mục mở rộng của Amazon bất cứ khi nào họ cần. Chaos Engineering cho phép các team thử nghiệm các lỗi hoặc sự cố tải để hiểu rõ hơn về việc ứng dụng của họ sẽ phản ứng ra sao và do đó cải thiện khả năng phục hồi. Và đây cũng là câu chuyện về DevOps và cách một nhóm chuyên về khả năng phục hồi có thể tạo ra công nghệ và thúc đẩy các thay đổi giúp nhiều nhóm tham gia vào Search có thể dễ dàng chạy các thử nghiệm Chaos trên nhiều dịch vụ hỗ trợ Search.
Nếu bạn đang muốn triển khai Chaos Engineering để cải thiện khả năng phục hồi, đang tìm cách tạo ra một mô hình trao quyền hiệu quả cho builder team hoặc cả hai, chúng ta hãy tiếp tục.
DevOps
DevOps là một chủ đề lớn và tôi không thể trình bày hết ở đây. Tôi thực sự thích định nghĩa mà một đồng nghiệp đã viết về DevOps.
DevOps là một cách tiếp cận giải quyết vấn đề mang tính cộng tác. Nó coi trọng tinh thần đồng đội và giao tiếp, phản hồi và lặp lại nhanh chóng cũng như loại bỏ xung đột hoặc lãng phí thông qua tự động hóa.
Bạn có thể đã nghe nói về tất cả các công cụ được sử dụng trong DevOps như Kubernetes, Terraform và GitLab, nhưng các công cụ này không phải là nơi thích hợp để khơi chuyện. DevOps là về văn hóa. Hãy xem định nghĩa ở trên: Hợp tác, làm việc nhóm, giao tiếp – đây đều là một phần của văn hóa. Sau đó, các công cụ tự động hóa sẽ cho phép văn hóa hoàn thành phần việc của mình.
DevOps rất lớn, vì vậy ở đây tôi sẽ chỉ tập trung vào các khái niệm DevOps chính được minh họa trong câu chuyện về cách Amazon Search áp dụng Chaos Engineering:
Trao quyền cho các team: DevOps nuôi dưỡng một văn hóa nơi các nhóm được trao quyền thử nghiệm những ý tưởng mới và học hỏi từ cả thành công và thất bại.
Tính sở hữu và trách nhiệm: Trong DevOps, các nhóm ‘sở hữu’ các dịch vụ mà họ xây dựng và chịu trách nhiệm đảm bảo kết quả phù hợp. Trao quyền là điều kiện tiên quyết cho vấn đề này, vì nhóm cần có khả năng hiểu cách sử dụng dịch vụ của họ và có thể thực hiện các thay đổi mà họ thấy phù hợp.
Phá vỡ các bức tường: Động lực đằng sau “DevOps” là phá bỏ các rào cản truyền thống thường tồn tại giữa các team phát triển và vận hành. Bằng cách thúc đẩy sự hợp tác và các mục tiêu chung, DevOps hướng tới việc loại bỏ các rào cản và tạo ra một quy trình làm việc hợp lý và hiệu quả hơn.
Cho phép các nhóm làm được nhiều việc hơn: Đây là lúc mà tự động hóa và các công cụ có thể đóng vai trò chính. Nhưng cơ cấu tổ chức và trách nhiệm cũng rất quan trọng ở đây. Một nhóm tách khỏi nhóm phát triển và vận hành dịch vụ cho họ không phải là lý tưởng (xem phần “phá bỏ những bức tường” ở trên) mà tốt hơn là nên có một nhóm chuyên về development và giảm bớt gánh nặng không phân biệt (undifferentiated heavy lifting) trong việc vận hành dịch vụ. Gánh nặng không phân biệt ở đây là tất cả những công việc khó khăn (“heavy lifting”) cần thiết để hoàn thành một nhiệm vụ (chẳng hạn như triển khai và vận hành một dịch vụ) nhưng không có sự khác biệt đáng kể giữa các dịch vụ (“undifferentiated”). Đây là thuật ngữ được Jeff Bezos đưa ra vào năm 2006, đại ý nói về tất cả những việc nhọc nhằn mà các công ty đang làm nhưng chẳng tạo giá trị gì cho sứ mệnh của nó. Nếu mỗi team dịch vụ phải tự mình làm công việc này thì thật lãng phí. Việc có một nhóm tạo ra các công cụ và quy trình thực hiện phần lớn công việc nặng nề này sẽ giúp loại bỏ gánh nặng cho các nhóm dịch vụ!
Amazon Search
Nếu bạn từng mua sắm trên Amazon.com hoặc bất kỳ trang Amazon nào trên toàn thế giới, bạn có thể đã sử dụng Search để tìm thấy những gì bạn muốn. Tìm kiếm chủ đề như Chaos Engineering trả về hơn 1.000 kết quả (Hình 1) và sau đó, Amazon Search cho phép bạn tinh chỉnh tìm kiếm đó theo nhiều thông số khác nhau như ngôn ngữ, định dạng sách hoặc ngày phát hành.
Hình 1. Amazon Search trả về hơn 1.000 kết quả cho “Chaos Engineering”
Hơn 1.000 kết quả là rất nhiều và Search chịu trách nhiệm cung cấp nhanh chóng các kết quả từ danh mục gồm nhiều triệu sản phẩm cho hơn 300 triệu khách hàng đang hoạt động. Vào Prime Day 2022, Amazon Search đã phục vụ 84.000 yêu cầu mỗi giây. Đó là quy mô khủng khiếp. Các nguyên tắc tôi sẽ chia sẻ với bạn ở đây có tác dụng kích hoạt khả năng phục hồi ở quy mô đó, nhưng chúng cũng hoạt động ở bất kỳ quy mô nào mà hệ thống của bạn chạy.
Amazon Search bao gồm hơn 40 dịch vụ backend, thuộc sở hữu của các builder team khác nhau (còn được gọi là các nhóm two-pizza). Nhóm two-pizza cũng là thuật ngữ Jeff Bezos đưa ra, đại ý là số lượng thành viên mỗi nhóm cần tối ưu sao cho ăn chỉ vừa đủ 2 cái pizza. Mỗi nhóm có quyền sở hữu dịch vụ (hoặc các dịch vụ) của mình, từ thiết kế và thực thi đến triển khai và vận hành. Vì vậy, ta có thể thấy các hoạt động DevOps đang nổi lên trong câu chuyện. Khi nhóm sở hữu cả hoạt động phát triển và vận hành, đó là một cách để áp dụng văn hóa ‘sở hữu và trách nhiệm’, cũng như ‘phá bỏ các bức tường giữa phát triển và vận hành’. Các builder team của Amazon có thể sở hữu việc triển khai và vận hành nhờ có một nhóm công cụ xây dựng (builder tool) trên toàn Amazon tạo ra công cụ và quy trình, loại bỏ các undifferentiated heavy lifting và ‘cho phép các nhóm làm được nhiều việc hơn’. Một nhóm chuyên biệt (Builder tools) cho phép các nhóm two-pizza làm được nhiều việc hơn. Chúng ta sẽ thấy tiếng vang của cách tiếp cận này sau khi nói về cách Search áp dụng Chaos Engineering.
Chaos Engineering (Kỹ thuật hỗn loạn)
Kỹ thuật hỗn loạn là quy tắc thử nghiệm trên một hệ thống nhằm xây dựng niềm tin vào khả năng của hệ thống trong việc chống chọi với các điều kiện hỗn loạn trong môi trường production. – Nguyên tắc của Chaos Engineering.
Một số người cảm thấy khó chịu với thuật ngữ “hỗn loạn” (chaos), nhưng điều quan trọng cần biết là Chaos Engineering không nhằm mục đích tạo ra hỗn loạn. Thay vào đó, đó là việc bảo vệ các ứng dụng của bạn khỏi sự hỗn loạn đang tồn tại trên production bằng cách đưa chúng vào tình trạng hỗn loạn một cách có kiểm soát. Bạn áp dụng phương pháp khoa học, tạo ra giả thuyết. Giả thuyết này dựa trên cách bạn đã thiết kế ứng dụng của mình để có khả năng phục hồi trước các sự kiện cụ thể như lỗi hoặc sự cố tải. Sau đó, bạn chạy một thử nghiệm bằng cách mô phỏng các sự kiện đó và quan sát cách ứng dụng của bạn hoạt động, kiểm tra giả thuyết. Điều này sẽ cho bạn biết ứng dụng của bạn có hoạt động tốt trước những sự kiện đó hay không hoặc bạn có thể cải thiện nó ở đâu.
Việc trao quyền cho các nhóm bao gồm việc trao cho họ quyền tự chủ để tạo và chạy các thử nghiệm hỗn loạn trên các dịch vụ của họ.
The Search Resilience Team (Nhóm phục hồi tìm kiếm)
Search Resilience Team là một nhóm two-pizza trong tổ chức Search, có nhiệm vụ cải thiện và thúc đẩy khả năng phục hồi của dịch vụ Amazon Search. Họ kết hợp mọi thứ tôi đã nói ở trên: DevOps + Amazon Search + Chaos Engineering. Điều đó nói lên rằng, họ không nhất thiết phải mô tả mình là một nhóm DevOps, mà thích tự gọi mình là một tổ chức tối ưu vận hành và quản lý độ tin cậy website (operational excellence and site reliability engineering organization). Nhưng cũng giống như nhóm builder tool của Amazon hoạt động như một nhóm chuyên biệt ‘cho phép các nhóm làm được nhiều việc hơn’ trên toàn bộ Amazon, Search Resilience Team hoạt động như một nhóm chuyên biệt trong Search, ‘cho phép các nhóm làm được nhiều việc hơn’ trong hơn 40 nhóm two-pizza sở hữu dịch vụ trong tổ chức Search.
Hãy nhớ rằng mô hình DevOps không có nhóm Search Resilience tạo ra cũng như sở hữu các thử nghiệm hỗn loạn cho các nhóm dịch vụ của họ. Thay vào đó, họ cần tạo ra một quy trình có thể mở rộng và công nghệ đằng sau quy trình đó để giúp các nhóm dịch vụ đó tạo, sở hữu và chạy các thử nghiệm hỗn loạn dễ dàng hơn, ngay cả trong môi trường production. Để thực hiện điều này, nhóm Search Resilience đã tạo ra Amazon Search Chaos Orchestrator.
Search Resilience team đã có nhiều mục tiêu cụ thể trong việc tạo ra bộ điều phối hỗn loạn. Tuy nhiên, mục tiêu chung là tạo ra một hệ thống giúp các nhóm Search two-pizza dễ dàng hơn trong việc tạo và chạy các thử nghiệm hỗn loạn với các dịch vụ mà họ sở hữu. Hình 2. hiển thị tổng quan về bộ điều phối.
Hình 2. Một hệ thống điều phối thử nghiệm hỗn loạn trên Search
Lưu ý tôi đã tạo chú thích để bạn không thể bỏ lỡ AWS Fault Injection Simulator (AWS FIS). AWS FIS là một dịch vụ được quản lý cho phép bạn thực hiện các thử nghiệm tiêm lỗi (fault injection) trên các ứng dụng được lưu trữ trên AWS và do đó, đây là một lựa chọn đương nhiên khi tạo và chạy các thử nghiệm hỗn loạn trên các dịch vụ Search, tất cả đều được lưu trữ trên AWS bằng dịch vụ AWS như Amazon S3, Amazon API Gateway, Amazon DynamoDB, Amazon EC2, Amazon ECS,… FIS là thứ mà bất kỳ ai chạy trên AWS đều có thể sử dụng. Search Resilience team muốn giúp các nhóm Search sử dụng FIS dễ dàng nhất có thể mà không cần mỗi nhóm phải xây dựng các hoạt động tích hợp và chi phí chung giống nhau.
Họ muốn triển khai các yêu cầu dành riêng cho Search nên mỗi nhóm không phải tự thực hiện. Ví dụ: xem trong Hình 2 trong đó có dòng chữ “Quy trình thực hiện thử nghiệm hỗn loạn”. Bằng cách biến thử nghiệm hỗn loạn thành một phần của quy trình làm việc, họ có thể thêm các bước dành riêng cho Search tiền và hậu thử nghiệm. Ví dụ, các bước tiền thử nghiệm sẽ kiểm tra xem thử nghiệm có vượt qua trong môi trường tiền production hay không trước khi chạy chúng trong môi trường production, đồng thời kiểm tra xem không có sự kiện nào tác động đến khách hàng đang diễn ra trước khi chạy thử nghiệm. Hậu thử nghiệm, quy trình sẽ kiểm tra xem các thang đo (metric) có bị ảnh hưởng bất lợi hay không.
Có một số yêu cầu dành riêng cho Search khác được các nhóm thực hiện dễ dàng hơn bằng cách sử dụng bộ điều phối hỗn loạn. Những mục tiêu này được thể hiện trong Hình 3.
Hình 3. Các mục tiêu của tổ chức Search để kích hoạt Chaos Engineering
Mở rộng quy mô trên hơn 40 dịch vụ Tìm kiếm
Chỉ bằng cách loại bỏ những Undifferentiated heavy lifting, Search Orchestrator sẽ giúp đạt được mục tiêu này. Ngoài ra, Search Resilience team đã tạo giao diện người dùng UX bằng đồ họa để làm cho nó dễ sử dụng. Bạn có thể thấy API Gateway trong Hình 2 ở trên thể hiện hai API. Các nhóm có thể tự do gọi các API này theo chương trình hoặc họ có thể sử dụng UX đồ họa để gọi các API này. Bạn có thể thấy trong Hình 4, đây không phải là UX “đẹp nhất” từ trước đến nay nhưng nó cung cấp cho các nhóm Search tất cả chức năng mà họ cần để xác định và chạy các thử nghiệm hỗn loạn. Điều này cũng phù hợp với Agile và DevOps, nơi chúng tôi chỉ dành nỗ lực cho những thứ quan trọng.
Hình 4. Giao diện người dùng UX cho Amazon Search Chaos Orchestrator
Lên lịch
AWS FIS ghi lại hướng dẫn về cách lên lịch thử nghiệm bằng Amazon EventBridge Scheduler. Nhưng hãy nhớ rằng, chúng ta muốn loại bỏ những công việc không có sự khác biệt. Vì vậy, tính năng này chỉ được tích hợp sẵn trong bộ điều phối và các nhóm Search có thể sử dụng nó. Lưu ý trong Hình 2 rằng Search Resilience team đã đi theo một lộ trình hơi khác, sử dụng Amazon DynamoDb để lưu trữ lịch trình và EventBridge thực sự gọi hàm Lambda để đọc lịch trình và khởi động quá trình chạy thử nghiệm.
Chạy với triển khai
Tương tự như lập lịch, bất kỳ ai sử dụng FIS đều có thể chạy nó với quy trình triển khai của họ. Ví dụ: đây là cách tích hợp nó từ AWS CodePipeline. Nhưng một lần nữa, để tiết kiệm công sức cho nhóm two-pizza, tại sao không làm cho nó hoạt động với quy trình của nhóm. Ngoài ra, Search sử dụng công cụ nội bộ của Amazon cho quy trình và triển khai, do đó, bộ điều phối sẽ đảm nhận việc tích hợp với công cụ này.
Guardrail sử dụng SLO nhất quán
Có rất nhiều thứ cần làm rõ ở đây. Các guardrail (rào chắn) đầu tiên – đây là những thứ PHẢI CÓ cho các thí nghiệm hỗn loạn. Guardrail là những điều kiện bạn xác định cho biết thử nghiệm sẽ gây ra tác động không mong muốn, vì vậy khi những điều kiện này xảy ra, thử nghiệm phải được dừng và khôi phục. Tất nhiên, AWS FIS cho phép bạn xác định các điều kiện dừng dưới dạng guardrail — bạn có thể thấy những điều kiện đó ở phía bên phải của Hình 2. Vậy Search Chaos Orchestrator cung cấp thêm lợi ích gì ở đây? Đó là nơi SLO xuất hiện.
Mục tiêu cấp độ dịch vụ, hay SLO (Service Level Objective), chỉ đơn giản là các mục tiêu trông giống như thế này: Trong khoảng thời gian 28 ngày, chúng ta sẽ phân phối 99,9% yêu cầu có độ trễ dưới 1000 mili giây. Search Resilience team không chỉ xây dựng bộ điều phối thử nghiệm hỗn loạn mà còn xây dựng hệ thống theo dõi định nghĩa SLO. Hệ thống này cho phép các nhóm xác định SLO cho dịch vụ của họ và sau đó giám sát các SLO đó, theo dõi khi dịch vụ không tuân thủ. Search Chaos Orchestrator tích hợp với điều này và sử dụng các SLO này làm rào chắn cho các thử nghiệm do các nhóm dịch vụ vận hành. Ngoài việc dừng thử nghiệm, bộ điều phối còn thông báo cho chủ sở hữu dịch vụ và cắt phiếu theo dõi khi guardrail bị vi phạm.
Dây Andon
Bạn có thấy nút lớn màu đỏ trong Hình 4 có nội dung “Dừng tất cả các thử nghiệm hỗn loạn tìm kiếm” không? Đó chính là dây Andon. Andon được Toyota sản xuất tại các nhà máy của họ, nơi “mỗi người được phép dừng dây chuyền sản xuất nếu họ phát hiện ra điều gì đó mà họ cho là có mối đe dọa đối với chất lượng xe”. Ở đây nó cho phép mọi người dừng tất cả các thử nghiệm nếu có bất kỳ rủi ro nào đối với trải nghiệm của khách hàng. Họ có thể sử dụng nút lớn màu đỏ hoặc lệnh CLI. Bạn có thể xem trong Hình 2 cách triển khai chức năng Andon bằng cách sử dụng chức năng điều kiện dừng được tích hợp trong FIS. Ngoài việc dừng tất cả các thử nghiệm đang chạy, Andon sẽ khiến kỹ sư Search Resilience đang phụ trách phải phân trang. Hầu hết các nhóm two-pizza trên Amazon đều có ít nhất một thành viên trực để xử lý sự cố 24/7, đây là một phần trong vận hành dịch vụ của DevOps.
Metric và thông tin chi tiết
AWS FIS hỗ trợ metric và ghi nhật ký. Bộ điều phối kỹ thuật hỗn loạn sử dụng chức năng đó và tổng hợp kết quả từ tất cả các nhóm Search để trình bày dưới dạng một báo cáo duy nhất.
Một thử nghiệm hỗn loạn trên Amazon Search
Amazon Search, giống như nhiều dịch vụ của Amazon, sử dụng đòn bẩy khẩn cấp (emergency lever) như một phần trong chiến lược phục hồi. Đòn bẩy khẩn cấp là một quá trình nhanh chóng cho phép hệ thống phục hồi sau căng thẳng hoặc tác động. Vì vậy, tất nhiên, Search muốn thử nghiệm để biết đòn bẩy khẩn cấp hoạt động như dự kiến hay không. Trong trường hợp này, một giả thuyết đơn giản hóa có thể như sau:
Khi tải tìm kiếm vượt quá [một giá trị nào đó] và lỗi cũng như độ trễ bắt đầu tăng lên (cụ thể metric nào và bao nhiêu), thì việc kích hoạt đòn bẩy khẩn cấp để tắt các dịch vụ không quan trọng sẽ giữ lỗi và độ trễ trong giới hạn có thể chấp nhận được (xác định các giới hạn này), lên tới [số lượng cụ thể] tải.
Đòn bẩy khẩn cấp cụ thể này sẽ vô hiệu hóa tất cả các dịch vụ không quan trọng, bảo tồn tài nguyên khi hệ thống bị ép, để các dịch vụ quan trọng vẫn khả dụng. Bạn có thể thấy điều này trong Hình 5. Bên trái là trải nghiệm Tìm kiếm thông thường. Bên phải là sau khi đã kéo cần gạt khẩn cấp. Chức năng quan trọng như tiêu đề, hình ảnh và giá được hiển thị, ngoài ra thì không còn gì khác. Tìm kiếm thà hiển thị trải nghiệm ở bên phải còn hơn là không trả lại bất kỳ kết quả nào. Đây là thực hành tốt nhất về khả năng phục hồi được gọi là xuống cấp nhẹ (graceful degradation).
Hình 5. Đòn bẩy khẩn cấp vô hiệu hóa các dịch vụ không quan trọng trong Search và mang lại trải nghiệm xuống cấp nhẹ cho khách hàng
Hình 5. Đòn bẩy khẩn cấp vô hiệu hóa các dịch vụ không quan trọng trong Search và mang lại trải nghiệm xuống cấp nhẹ cho khách hàng
Đối với thử nghiệm hỗn loạn, các sự kiện bao gồm sự kết hợp của việc thêm tải tổng hợp vào hệ thống và sau đó kéo đòn bẩy khẩn cấp. Bằng cách này, Search có thể tạo niềm tin rằng trong trường hợp xảy ra sự cố có lượng tải thực sự cao, đòn bẩy sẽ cho phép Search luôn sẵn sàng.
Kết
Chaos Engineering là phương pháp tuyệt vời để hiểu tốt hơn về khả năng phục hồi các dịch vụ của bạn. Và AWS FIS là một dịch vụ tuyệt vời để tạo và chạy các thử nghiệm hỗn loạn trên AWS. Các nhóm two-pizza trong Search có thể bắt đầu sử dụng FIS và chạy thử nghiệm một cách độc lập. Nhưng bằng cách áp dụng văn hóa DevOps tập trung vào việc ‘hỗ trợ các nhóm làm được nhiều việc hơn’, nhóm Search Resilience đã có thể làm cho quy trình này trở nên dễ dàng hơn nữa đối với các nhóm Search two-pizza và bổ sung nhiều tính năng có giá trị giúp kỹ thuật hỗn loạn trở nên hiệu quả hơn trên toàn bộ Search.
Lớn lên vào cuối những năm 80 và đầu những năm 90, việc tiếp xúc với máy tính của tôi hầu như chỉ giới hạn ở các máy chơi game (tôi đã cân nhắc các máy tính chơi game Atari 800 và Commodore 64 vì tôi chỉ từng thấy các game được chạy trên chúng) hoặc các hệ thống x86 đời đầu. Mãi cho đến khi vào đại học những năm 2000, tôi mới có được máy trạm SPARC, UNIX và Slackware Linux của Sun Microsystems mà tôi có thể cài đặt trên máy Intel 486 của mình ở nhà.
Trước đó, phát triển phần mềm chủ yếu là về phần mềm chạy cục bộ trên máy của bạn hoặc, nếu bạn có quyền truy cập vào phần mềm đó, một máy tính dùng chung với sức mạnh xử lý cao hơn đáng kể có sẵn để bạn… làm những việc liên quan đến kinh doanh. Ở trường đại học, tôi nhớ đã nghe nói về một chương trình được sử dụng bởi các nhà khoa học máy tính cần một bộ xử lý đa lõi để tạo lịch học của hàng nghìn sinh viên; phải mất hàng tuần để tạo và in. Cho đến nay, tôi vẫn không chắc cái nào mất nhiều thời gian hơn – chạy chương trình hay in ra giấy.
Ngày nay, phần lớn phần mềm được phát triển chạy trên đám mây, chạy trên thiết bị yêu cầu quyền truy cập vào đám mây hoặc cung cấp sức mạnh cho phần mềm khác cũng chạy trên đám mây. Rất hiếm khi làm việc trên một hệ thống phần mềm hoạt động trong không gian hạn chế (ví dụ: hệ thống phần mềm nhúng – embedded software system) không có quyền truy cập vào nền tảng điện toán mạnh hơn ở nơi khác. Các hệ thống kế toán hiện xử lý hàng đống dữ liệu được lưu trữ trong các trang trại máy chủ tại cơ sở của công ty hoặc trong data warehouse. Các hệ thống bán hàng hiện quản lý quan hệ khách hàng do bên thứ ba quản lý với các plugin được phát triển bởi nhiều bên thứ ba hoặc nhà phát triển nội bộ hơn.
Nhưng làm thế nào để các hệ thống phần mềm này được xây dựng phục vụ hàng trăm đến hàng triệu người dùng trong khi vẫn duy trì hiệu suất và khả năng phản hồi mà chúng ta ngày càng mong đợi từ phần mềm chúng ta sử dụng ngày nay?
Là một kỹ sư phần mềm trong hơn 20 năm qua, tôi đã chứng kiến nhiều hệ thống được phát triển từ mọi cấp độ của hệ thống. Trình xử lý ngắt trong những ngày DOS cho tới hoạt ảnh dựa trên JavaScript và thậm chí tạo báo cáo không cần mã. Một vài tuần trước, tôi thậm chí đã dùng ChatGPT-4 để tạo một số mã Python dựa trên một số mô tả mà tôi đã cung cấp cho những gì tôi muốn! Nhưng đó là một câu chuyện cho một ngày khác.
Trong bài viết này, chúng ta sẽ nói về thiết kế hệ thống, cách nó trở thành một phần quan trọng trong thực tiễn software engineering hiện đại và cách nó trở thành một trong những lĩnh vực chính mà các software engineer vẫn có thể mang lại giá trị trong ngắn hạn và trung hạn.
Tầm quan trọng của thiết kế hệ thống (Systems design)
Tầm quan trọng của Thiết kế hệ thống (System Design)
Ngày xưa, tôi là kỹ sư phần mềm trong một công ty gặp vấn đề trong việc xử lý gánh nặng thành công mà chính họ đã mang lại. Tôi sẽ gọi công ty này là Friendster. Khi tôi gia nhập công ty, dự án mà tôi được giao đã bị trễ và có nhiều lỗi liên quan đến quản lý bộ nhớ. Dịch vụ cốt lõi của họ (vâng, nó là một microservice trước khi chúng tôi gọi nó vào năm 2007) được viết bằng C++ nhưng bị rò rỉ bộ nhớ, mất quá nhiều thời gian để xử lý các yêu cầu và được thiết kế để lưu vào bộ đệm và cung cấp dữ liệu trong bộ nhớ của chính nó. Nó cần phải không trạng thái (stateless) nhưng cuối cùng lại trở thành trạng thái (stateful).
Một vài tuần sau khi bắt đầu dự án, tôi đã xin lãnh đạo kỹ thuật cấp cao bỏ việc lặp lại dịch vụ này và thay vào đó hãy viết một cái gì đó từ đầu đáp ứng các yêu cầu; nó sẽ là một sự thay thế của việc triển khai hiện có. Chúng tôi đã phải vượt qua thời hạn vì dịch vụ chỉ có thể xử lý thêm vài tháng tăng trưởng nữa trước khi không thể xử lý kích thước của bộ đệm theo cách cũ nữa.
Khởi động lại dịch vụ mất nhiều thời gian hơn thời gian nó có thể duy trì cho đến khi rò rỉ bộ nhớ làm nó ngừng hoạt động. Đây là khoảnh khắc “đặt cược sự nghiệp của tôi”. Chúng tôi phải làm cho nó hoạt động.
Trong thiết kế hệ thống. Điều đầu tiên chúng tôi làm là liệt kê những yêu cầu mà hệ thống phải đáp ứng, hợp đồng giữa các dịch vụ phụ thuộc (mã PHP frontend) và dịch vụ cốt lõi này và kế hoạch về cách chúng tôi sẽ đáp ứng ba yêu cầu phi kỹ thuật chính : hiệu suất (performance), hiệu quả (efficiency) và khả năng phục hồi (resilience).
Thiết kế hệ thống liên quan đến việc hiểu các ràng buộc theo đó hệ thống phải thực hiện chức năng của nó, các chức năng được yêu cầu là gì và những thuộc tính nào của hệ thống là quan trọng để giữ liên quan đến tất cả các thuộc tính khác. Khi bạn đã xác định những điều này, bạn có thể bắt đầu thiết kế một hệ thống đáp ứng các yêu cầu và lập kế hoạch phân phối giải pháp một cách có hệ thống.
Các thành phần của thiết kế hệ thống
Khi chúng ta nói về thiết kế hệ thống, thường có một số thành phần đòi hỏi điều này:
Kiến trúc – giải pháp tổng thể trông như thế nào? Liệu nó liên quan đến nhiều hệ thống con? Có các thành phần riêng lẻ tạo nên một tổng thể? Làm thế nào để chúng tương tác, và làm thế nào để chúng liên quan đến nhau?
Cấu trúc liên kết (Topology) – Có phân lớp cho giải pháp không? Nếu đây là một hệ thống phân tán, thì các dịch vụ thành phần được đặt ở đâu về mặt vật lý hoặc logic trong mối quan hệ với nhau?
Thiết kế cấp thấp — Bạn đã xác định những giao diện nào thông qua đó các phần khác nhau của hệ thống tương tác với nhau? Có thuật toán cụ thể nào bạn đang sử dụng để giải quyết các khía cạnh chính của giải pháp (hiệu suất, hiệu quả, thông lượng, khả năng phục hồi, v.v.) không?
Nó giúp hiểu những điều đầu tiên như: hệ thống có độc lập không (tức là sẽ không có quyền truy cập vào các tài nguyên bên ngoài) hay nó được phân tán? Nó sẽ có giao diện người dùng hay nó sẽ không tương tác (ví dụ: nó có tạo báo cáo được in ra hay nó sẽ yêu cầu đầu vào của con người hoặc hệ thống khác trong quá trình hoạt động)? Nó có cần xử lý nhiều lưu lượng truy cập không? Nó có nghĩa là chỉ được sử dụng bởi mười người tại bất kỳ thời điểm nào hay 10 triệu người dùng sẽ sử dụng nó tại bất kỳ thời điểm nào?
Khi bạn đã có câu trả lời cho một số câu hỏi này, việc đưa ra quyết định thông qua các nguyên tắc thiết kế hệ thống sẽ dễ dàng hơn.
Các nguyên tắc thiết kế hệ thống
Các nguyên tắc của thiết kế hệ thống (System Design Principles)
Một số nguyên tắc chính để thiết kế hệ thống phần mềm trong thời đại hiện đại này đã không xuất hiện cho đến khi hệ thống cần mở rộng quy mô — từ hệ thống một người dùng thành hệ thống có thể xử lý hàng nghìn, thậm chí hàng triệu người dùng cùng một lúc. Dưới đây là một số chúng tôi sẽ đề cập trong bài viết này:
Khả năng mở rộng (Scalability)
Độ tin cậy (Reliability)
Khả năng bảo trì (Maintainability)
Khả dụng (Availability)
Bảo mật (Security)
Scalability (Khả năng mở rộng)
Một hệ thống có khả năng mở rộng khi nó có thể được triển khai để xử lý sự tăng trưởng về tải với sự tăng trưởng tương ứng về tài nguyên. Hệ số mở rộng của một hệ thống được định nghĩa là sự tăng trưởng về lượng tài nguyên cần thiết để phục vụ cho sự tăng trưởng về tải trên hệ thống. Chúng tôi gặp hai trường hợp mở rộng điển hình với các hệ thống phần mềm: mở rộng chiều dọc và mở rộng chiều ngang.
Mở rộng chiều dọc đề cập đến việc cung cấp thêm khoảng không hoặc tài nguyên máy đơn cho hệ thống phần mềm để xử lý sự gia tăng về yêu cầu. Hãy xem xét trường hợp của một thiết bị lưu trữ gắn mạng. Bạn cung cấp càng nhiều dung lượng lưu trữ thông qua thiết bị, thì thiết bị có thể lưu trữ càng nhiều dữ liệu. Nếu bạn cần nó xử lý nhiều kết nối đồng thời hơn và Hoạt động I/O (IOP), thông thường bạn cần bổ sung thêm sức mạnh tính toán và giao diện mạng để xử lý lượng tải tăng lên.
Mở rộng theo chiều ngang đề cập đến việc sao chép một hệ thống hoặc nhiều máy bằng các bản sao của phần mềm để xử lý sự tăng trưởng các yêu cầu. Hãy xem xét trường hợp máy chủ nội dung web tĩnh ẩn sau bộ cân bằng tải. Thêm nhiều máy chủ hơn cho phép nhiều máy khách hơn kết nối và tải xuống nội dung từ các máy chủ web và khi tải đã giảm, số lượng máy chủ web có thể được thu nhỏ xuống kích thước phù hợp với nhu cầu hiện tại.
Một số hệ thống có thể xử lý mở rộng lai hoặc chéo. Ví dụ: một số kiến trúc cơ sở dữ liệu phân tán cho phép tách các nút tính toán và lưu trữ để khối lượng công việc tính toán nặng có thể sử dụng các nút có nhiều tài nguyên tính toán hơn. Ngược lại, khối lượng công việc nặng của IOP có thể chạy trên các nút lưu trữ + tính toán. Ví dụ: các ứng dụng xử lý luồng có thể tách các khối lượng công việc yêu cầu nhiều bộ nhớ và điện toán hơn (ví dụ: khối lượng công việc tìm nguồn cung ứng sự kiện hoặc phân tích) và mở rộng những khối lượng công việc đó một cách thích hợp và độc lập khỏi khối lượng công việc nặng của IOP (ví dụ: nén và lưu trữ).
Reliability (Độ tin cậy)
Một hệ thống đáng tin cậy khi nó có thể chịu được lỗi một phần và phục hồi mà không làm giảm chất lượng dịch vụ nghiêm trọng. Một phần của độ tin cậy của hệ thống bao gồm khả năng dự đoán các hoạt động của nó về độ trễ, thông lượng và tuân thủ phạm vi hoạt động đã thỏa thuận.
Các phương pháp thông thường để đảm bảo độ tin cậy của hệ thống bao gồm:
Thiết lập dự phòng hệ thống để hỗ trợ chuyển đổi dự phòng minh bạch hoặc gián đoạn tối thiểu.
Xây dựng khả năng chịu lỗi trong trường hợp lỗi nội bộ hoặc lỗi do đầu vào gây ra.
Xác định rõ ràng các hợp đồng và mục tiêu về độ trễ, thông lượng và tính khả dụng.
Thiết lập đủ công suất dự phòng để đáp ứng sự gia tăng tải đột biến và tự nhiên.
Các biện pháp bảo vệ chất lượng dịch vụ để thực thi giới hạn tỷ lệ và cách ly khách hàng/hoạt động.
Thực hiện hạ cấp dịch vụ nhẹ nhàng trong các tình huống quá tải hoặc lỗi nghiêm trọng.
Điều quan trọng cần nhớ để tạo ra các hệ thống đáng tin cậy là xử lý các lỗi tiềm ẩn theo cách được xác định rõ ràng mà các hệ thống phụ thuộc có thể phản ứng. Điều này nghĩa là nếu có những yếu tố đầu vào có thể khiến hệ thống khả dụng cho tất cả mọi người, thì đó không phải là một hệ thống đáng tin cậy. Tương tự, nếu hệ thống phụ thuộc vào một hệ thống khác có thể không đáng tin cậy, thì nó sẽ xử lý sự không đáng tin cậy đó bằng các chiến lược để đảm bảo độ tin cậy.
Khả năng bảo trì (Maintainability)
Một hệ thống có thể bảo trì được khi được thay đổi với nỗ lực tương xứng và được triển khai với sự gián đoạn tối thiểu của người dùng. Điều này đòi hỏi phải triển khai hệ thống theo cách giả định rằng các yêu cầu sẽ thay đổi và hệ thống đủ linh hoạt để xử lý những thay đổi có thể thấy trước về hướng. Điều đó cũng có nghĩa là đảm bảo rằng mã có thể đọc được để nhóm người bảo trì tiếp theo (có thể là cùng một nhóm nhưng nhìn nó bằng con mắt mới trong tương lai) có thể bảo trì phần mềm và phát triển phần mềm để đáp ứng nhu cầu trong tương lai.
Không ai muốn bị mắc kẹt trong việc duy trì phần mềm cứng nhắc, khó thay đổi, không được tổ chức tốt, tài liệu kém, thiết kế kém, chưa được kiểm tra và lắp ráp lộn xộn.
Đảm bảo chất lượng mã cao là một phần của kỹ thuật xuất sắc phản ánh tính chuyên nghiệp và tay nghề xuất sắc. Đây không chỉ là một việc nên làm mà còn được biết là cho phép các nhóm kỹ thuật có chức năng cao và hiệu suất cao cung cấp phần mềm có thể thay đổi và mở rộng để mang lại giá trị một cách nhất quán.
Availability (Tính khả dụng)
Nếu dịch vụ của bạn không khả dụng, nó có thể không tồn tại.
Thiết kế hệ thống nên giải quyết cách hệ thống luôn sẵn sàng để duy trì sự liên quan đến khách hàng và người dùng hệ thống. Điều này có nghĩa là:
Giới thiệu các dự phòng để xử lý các lỗi hệ thống cơ bản.
Có các kịch bản sao lưu và khôi phục cũng như hướng dẫn vận hành để khôi phục hệ thống khỏi các sự cố nghiêm trọng.
Loại bỏ càng nhiều điểm lỗi đơn lẻ khỏi hệ thống.
Cùng với khả năng mở rộng theo chiều ngang, hãy có các bản sao theo khu vực và thiết lập mạng phân phối nội dung (nếu thích hợp) để cung cấp dữ liệu của bạn.
Giám sát tính khả dụng của hệ thống từ quan điểm của khách hàng để hiểu rõ hơn cách hệ thống của bạn đang phục vụ khách hàng.
Tôi đã sớm học được rằng một hệ thống không ổn định và không khả dụng đôi khi có thể là nguyên nhân lớn nhất khiến khách hàng của bạn mất lòng tin. Một khi bạn đã đánh mất lòng tin của khách hàng thì sẽ rất khó lấy lại được.
Security (Bảo mật)
Thiết kế hệ thống nên coi bảo mật là một khía cạnh quan trọng, đặc biệt là trong thời đại của các hệ thống kết nối internet, nơi các mối đe dọa và lỗ hổng bảo mật có thể gây hại thực sự cho khách hàng của chúng ta và người dùng hệ thống. Mục tiêu của việc xây dựng phần mềm an toàn không phải là để đạt được sự hoàn hảo mà là để hiểu những rủi ro liên quan đến vi phạm và tấn công. Có một mô hình đe dọa bảo mật thích hợp và một cách tiếp cận có hệ thống để hiểu rủi ro nằm ở đâu và loại mối đe dọa nào đáng để ưu tiên và thiết kế các biện pháp giảm thiểu là bước khởi đầu của thực tiễn kỹ thuật và thiết kế an toàn.
Ngày nay, bảo mật không còn là tùy chọn nữa khi các hệ thống phần mềm trở thành một phần của các dịch vụ quan trọng đối với nhiều bộ phận của xã hội hiện đại. Việc coi trọng vấn đề bảo mật trong các hệ thống mà chúng ta thiết kế ngay từ đầu sẽ giúp chúng ta tiến gần hơn đến khả năng tin cậy tốt hơn vào phần mềm mà chúng tôi xây dựng và triển khai để đáp ứng nhu cầu của người dùng. Giành được lòng tin của khách hàng đã đủ khó và chỉ cần vi phạm một lần là mất đi phần lớn niềm tin.
Cách hình mẫu thiết kế hệ thống hiện đại
Với các khía cạnh trên, một số hình mẫu cho các hệ thống phân tán hiện đại đã xuất hiện để giải quyết một số khía cạnh này theo những cách khác nhau. Hãy khám phá một số mẫu thiết kế phổ biến hơn mà chúng ta thấy ngày nay liên quan đến năm khía cạnh của thiết kế hệ thống.
Microservices (Vi dịch vụ)
Microservices – Hình mẫu System Design hiện đại
Với sự gia tăng của các hệ thống phân tán tập trung vào việc xây dựng độ tin cậy và quy mô thông qua dự phòng, hiệu quả và hiệu suất thông qua mở rộng theo chiều ngang và khả năng phục hồi thông qua việc tách các bộ phận của hệ thống thành các dịch vụ hoạt động độc lập, thuật ngữ “microservice” đã trở nên phổ biến nhờ đạt được những điều sau:
Ràng buộc việc phát triển, triển khai, vận hành và bảo trì các dịch vụ độc lập với các nhóm sở hữu các dịch vụ này trong một hoạt động kinh doanh lớn hơn. Chúng ta có thể làm điều này bằng cách phục vụ khách hàng bên ngoài trực tiếp hoặc gián tiếp thông qua khách hàng nội bộ thông qua API.
Cho phép microservice mở rộng quy mô độc lập theo nhu cầu.
Việc cung cấp dịch vụ thông qua một hợp đồng được xác định rõ ràng cho phép việc triển khai phát triển để duy trì dưới dạng một dịch vụ độc lập hoặc một hệ thống dịch vụ.
Nhìn qua các khía cạnh của chúng ta, microservice có các thuộc tính hấp dẫn, khiến nó trở thành một mô hình tốt để tuân theo nếu nó áp dụng cho trường hợp sử dụng:
Khả năng mở rộng: Các vi dịch vụ phi trạng thái (stateless microservices) thường được thiết kế để có thể mở rộng theo chiều ngang và cũng có thể hưởng lợi từ việc mở rộng theo chiều dọc. Trong trường hợp các microservice được triển khai trong môi trường điều phối được đóng gói (ví dụ: cụm Kubernetes), các dịch vụ này thậm chí có thể chạy trên cùng một nút mang lại khả năng sử dụng tốt hơn phần cứng hiện có và mở rộng quy mô theo nhu cầu với dung lượng khả dụng. Một nhược điểm là sự phức tạp khi triển khai khi một microservice phát triển về quy mô và mức độ quan trọng trong biểu đồ microservice.
Độ tin cậy: Các vi dịch vụ phi trạng thái thường được lưu trữ phía sau bộ cân bằng tải và được phân phối theo địa lý để tránh sự cố mất điện trong khu vực chiếm toàn bộ dung lượng của hệ thống. Một nhược điểm của việc xây dựng độ tin cậy với các vi dịch vụ phi trạng thái là hệ thống lưu trữ thường sẽ cần phải đáng tin cậy bằng hoặc hơn so với việc triển khai/thực thi vi dịch vụ. Khi đó, các vi dịch vụ có trạng thái phải chịu tác động tồi tệ nhất của cả hai phương pháp, trong đó chi phí cho độ tin cậy thường ở dạng cung cấp quá mức để xử lý các sự cố ngừng hoạt động tiềm ẩn.
Khả năng bảo trì: Các vi dịch vụ triển khai hợp đồng ổn định và được xác định rõ ràng được cung cấp thông qua API cho phép khách hàng lập trình dựa trên API đó và quá trình triển khai phát triển độc lập. Tuy nhiên, việc điều phối các thay đổi đối với API liên quan đến việc di chuyển ứng dụng khách và phối hợp giữa các nhóm có thể tốn kém, dẫn đến một giai đoạn vi dịch vụ có nhiều phiên bản được hỗ trợ tích cực cho đến khi ứng dụng khách cuối cùng di chuyển từ triển khai cũ hơn. Điều này chỉ trở nên tồi tệ hơn khi nhiều khách hàng bắt đầu tương tác với microservice.
Tính khả dụng: Microservices thường dựa vào môi trường triển khai và cơ sở hạ tầng bên ngoài để đáp ứng các yêu cầu về tính khả dụng của máy khách. Nhược điểm của điều này là sự phụ thuộc vào cơ sở hạ tầng cụ thể mà microservice được triển khai để cung cấp giải pháp có tính sẵn sàng cao. Các hệ thống như lưới dịch vụ và bộ cân bằng tải phần mềm trở thành những phần quan trọng của cơ sở hạ tầng không còn được kiểm soát bởi quá trình triển khai. Đây có thể là một điều tốt nhưng cũng có thể là một nguồn bảo trì liên tục vì các hệ thống này cũng có chu kỳ cập nhật và chi phí vận hành.
Bảo mật: Xác thực, Ủy quyền, Quản lý danh tính và Quản lý thông tin xác thực có thể được ủy quyền cho phần mềm trung gian hoặc thông qua các cơ chế bên ngoài (ví dụ: danh tính khối lượng công việc trong Kubernetes), trong đó việc triển khai microservice có thể tập trung vào việc tích hợp logic nghiệp vụ có liên quan. Nhược điểm, cũng như tính khả dụng, là các phần bên ngoài này của giải pháp trở thành các phần quan trọng của cơ sở hạ tầng mang lại chi phí vận hành của chính chúng khi triển khai vi dịch vụ.
Microservices là một cách tuyệt vời để chia nhỏ một ứng dụng lớn, nơi có thể xác định các phân vùng logic yêu cầu các miền độ tin cậy và tỷ lệ mở rộng của riêng chúng. Tuy nhiên, khi bắt đầu từ đầu, việc thiết kế các vi dịch vụ ngay từ đầu sẽ kém lý tưởng hơn vì nguy cơ chia nhỏ các dịch vụ thành các phần quá nhỏ. Chi phí liên lạc giữa các vi dịch vụ — thường là các yêu cầu HTTP hoặc gRPC — là đáng kể và chỉ phát sinh nếu cần thiết. Một cách tốt để xác định xem chức năng có phù hợp với một dịch vụ hay không bằng cách làm theo một phương pháp như Thiết kế hướng miền (Domain driven design) hoặc Phân rã chức năng (Functional decomposition).
Serverless (Không máy chủ)
Serverless – Hình mẫu System Design hiện đại
Giống như trong các giải pháp dựa trên vi dịch vụ, việc sử dụng các triển khai serverless sẽ ủy quyền thêm các phần chính của chức năng phục vụ các yêu cầu tới cơ sở hạ tầng bên dưới. Nếu trong Microservices, dịch vụ được phục vụ bởi một quy trình liên tục, thì các giải pháp Serverless thường chỉ triển khai một điểm đầu vào để xử lý yêu cầu tới một điểm cuối (thường là URI qua HTTP hoặc gRPC). Trong triển khai Serverless, không có máy chủ thực tế nào được định cấu hình mà thay vào đó, môi trường triển khai sẽ tạo ra các tài nguyên cần thiết để xử lý các yêu cầu khi chúng đến. Đôi khi, các tài nguyên đó duy trì một thời gian để khấu hao chi phí đưa chúng lên, nhưng điều đó có nghĩa là là một chi tiết thực hiện.
Hãy xem qua các khía cạnh của thiết kế hệ thống để xem các giải pháp Serverless sắp xếp như thế nào:
Khả năng mở rộng: Các giải pháp serverless có khả năng mở rộng theo chiều ngang như microservice, nếu không muốn nói là hơn thế vì chúng được thiết kế có kích thước phù hợp theo yêu cầu. Nhược điểm của phương pháp này là cần có nhiều quyền kiểm soát hơn và ủy quyền đầy đủ chức năng mở rộng quy mô cho cơ sở hạ tầng Serverless bên dưới.
Độ tin cậy: Độ tin cậy của Serverless phụ thuộc vào khả năng mở rộng theo chiều ngang và định tuyến lưu lượng mạng. Điều này có nhược điểm tương tự như giải pháp Microservices.
Khả năng bảo trì: Việc triển khai serverless dễ bảo trì hơn vi dịch vụ do tập trung vào logic nghiệp vụ để xử lý các yêu cầu với bản soạn sẵn tối thiểu. Điều này có cùng vấn đề với quá trình phát triển API mà microservice gặp phải.
Tính khả dụng: Các triển khai Serverless có sẵn như môi trường mà chúng được triển khai. Điều này có cùng các vấn đề, với cơ sở hạ tầng cơ bản trở nên quan trọng hơn bản thân giải pháp.
Bảo mật: Việc triển khai Serverless hoàn toàn phụ thuộc vào cấu hình bảo mật của cơ sở hạ tầng bên dưới. Điều này có cùng một vấn đề, với cơ sở hạ tầng cơ bản trở nên quan trọng hơn so với chính giải pháp thực tế.
Các giải pháp không có máy chủ, hay Chức năng dưới dạng Dịch vụ, là một cách rất hấp dẫn để tạo nguyên mẫu và thậm chí triển khai các giải pháp cấp sản xuất bằng cách tập trung vào giá trị và logic kinh doanh, đồng thời để cơ sở hạ tầng cơ bản xử lý khả năng mở rộng, độ tin cậy và tính khả dụng của dịch vụ. Đó là một điểm khởi đầu điển hình để có được một giải pháp với gánh nặng vận hành tối thiểu và đối với hầu hết các nguyên mẫu, đó là một cách tuyệt vời để chứng minh giả thuyết của chúng tôi. Đây cũng là một trải nghiệm điển hình khi một khi các giải pháp này đạt đến giới hạn mở rộng quy mô, chi phí liên quan đến việc vận hành các giải pháp này sẽ trở nên đủ cao. Chúng được biến thành các triển khai vi dịch vụ tối ưu hơn được điều chỉnh theo quy mô cần thiết.
Event-driven (Hướng sự kiện)
Thiết kế hệ thống hướng sự kiện – Hình mẫu System Design hiện đại
Tuy nhiên, có một số lĩnh vực sự cố nơi mà việc xử lý giao dịch trực tuyến không được yêu cầu và các triển khai vi dịch vụ và không có máy chủ không hoàn toàn phù hợp với hóa đơn. Hãy xem xét các trường hợp xử lý giao dịch có thể được thực hiện trong nền hoặc khi có sẵn tài nguyên. Một trường hợp khác dành cho các hoạt động xử lý nền trong đó kết quả không nhất thiết phải có tính tương tác.
Các hệ thống hướng sự kiện tuân theo mô hình có một nguồn sự kiện (event source) và các bồn sự kiện (event sinks) – nơi các sự kiện (tin nhắn) đến từ đó và được gửi tương ứng. Quá trình xử lý lần lượt xảy ra từ người đăng ký và nhà xuất bản đến các source và sink này. Một ví dụ về hệ thống hướng sự kiện là một chatbot có thể tham gia vào nhiều thảo luận (event source và sinks) và xử lý tin nhắn khi chúng đến.
Các hệ thống hướng sự kiện phân tán có thể có nhiều trình xử lý tin nhắn đồng thời đang chờ trên cùng một nguồn, có khả năng xuất bản nhiều sink đóng vai trò là nguồn cho các trình xử lý tin nhắn khác. Mô hình kết nối các bộ xử lý với nhau thông qua source và sink được gọi là quy trình sự kiện (event pipeline). Thông thường, có một triển khai duy nhất cho các sink và source cung cấp giao diện hàng đợi tin nhắn và mở rộng theo nhu cầu về các tin nhắn đi qua hệ thống. Nhiều hệ thống quản lý hàng đợi phân tán cũng có thể hưởng lợi từ việc mở rộng quy mô theo đường chéo một cách hiệu quả, như Apache Kafka, RabbitMQ, v.v.
Hãy xem xét các hệ thống hướng sự kiện phân tán thông qua năm khía cạnh:
Khả năng mở rộng: Cả triển khai trung gian tin nhắn/sự kiện và trình xử lý thông báo đều có thể mở rộng độc lập. Một số nhược điểm xuất hiện khi có quá nhiều tin nhắn/sự kiện đang được xử lý và nhu cầu về trung gian sự kiện tăng vượt xa khả năng có sẵn trong hệ thống.
Độ tin cậy: Việc triển khai trình môi giới thông báo tốt mang lại mức độ tin cậy cao và bạn không nên tạo triển khai trình môi giới thông báo của riêng mình. Nhược điểm là sự phụ thuộc vào giải pháp đáp ứng nhu cầu về độ tin cậy của giải pháp (ví dụ: xử lý các giao dịch tài chính rất khác so với xử lý định tuyến nhắn tin tức thì trong phòng trò chuyện).
Khả năng duy trì: Nếu bạn sử dụng định dạng trao đổi tin nhắn linh hoạt như Bộ đệm giao thức, thì việc phát triển các bộ viết và đọc tin nhắn trong khi sử dụng cùng một ngôn ngữ mô tả dữ liệu là điều hợp lý. Điều này vẫn yêu cầu sự phối hợp, nhưng không khó bằng việc phát triển các hợp đồng API trên các hệ thống xử lý giao dịch trực tiếp (như trong các dịch vụ vi mô và triển khai không có máy chủ).
Tính khả dụng: Vì các tin nhắn thường được lưu trữ trong phương tiện lâu bền nên các hệ thống hướng sự kiện thường dễ dàng cung cấp hơn, đặc biệt vì chúng thường là các ứng dụng không tương tác. Chi phí khả dụng có thể đến từ các tin nhắn cũ và độ trễ xử lý hàng đợi không giới hạn.
Bảo mật: Các hệ thống hướng sự kiện phải quản lý tính khả dụng của dữ liệu độc lập với danh tính và thông tin đăng nhập. Việc đảm bảo rằng chỉ một số dịch vụ hoặc bộ xử lý tin nhắn nhất định mới có thể truy cập vào hàng đợi hoặc nhật ký tin nhắn cụ thể trở thành công việc toàn thời gian khi dữ liệu đa dạng hơn được chuyển thẳng qua hệ thống.
Kết
Software engineering hiện đại đòi hỏi phải thiết kế các hệ thống có thể mở rộng, đáng tin cậy, có thể bảo trì, khả dụng và an toàn. Việc thiết kế các hệ thống phân tán đòi hỏi sự nghiêm ngặt đáng kể vì thực tế phức tạp của hệ thống hiện đại ngày càng tăng cùng với nhu cầu của xã hội về các dịch vụ phần mềm tốt hơn. Chúng ta đã xem xét ba hình mẫu thiết kế hiện đại cho các hệ thống phân tán và làm việc thông qua năm khía cạnh của các hệ thống được thiết kế tốt.
Là kỹ sư phần mềm, chúng ta chịu trách nhiệm thiết kế các hệ thống giải quyết các mối quan tâm chính của hệ thống phân tán trong thời hiện đại.
Chỉ cần “lỡ tay” google về việc học Data/AI, 10 phút sau Facebook của bạn sẽ dày đặc quảng cáo các khoá học với những câu từ hoa mỹ nhất: Ngành hot nhất, tốp thu nhập cao nhất, cơ hội việc làm rất nhiều, lương nghìn đô, nghề trending,…. Nghe mà sướng trợn mắt 🤣
Nhưng bạn nào trái ngành học Data Analytics ra đi xin việc sẽ biết cái khổ khi tìm đỏ mắt không ai tuyển, có offer thì lương chưa được 10 triệu. Lúc đó bạn sẽ trở về mặt đất ngay lập tức.
Data Analytics là một ngành thú vị, nhưng hiện nay, người mới học rất khó xin việc làm và nó không có màu hồng như các trung tâm hay kể. Vì mọi người đổ xô đi học data nên vài nơi bất chấp sự thật về thị trường việc làm để bán khoá học. Họ dùng các bài báo ở Mỹ, phương tây, lấy mức lương và các số liệu thống kê ở chỗ khác về đánh lận người học.
Mình cũng là một người tự học chuyển ngành sang Data, nên muốn chia sẻ một chút với các bạn đang muốn dấn thân. Hy vọng cung cấp một góc nhìn khác để các bạn cân nhắc chính xác hơn.
Lưu ý:
Công ty của mình đang làm là công ty của Mỹ, có chi nhánh ở Việt Nam, và mình cũng từng đi nộp loanh quanh khu vực ĐNA nên mình sẽ nói ở thị trường Mỹ và Việt Nam thôi.
Bài viết này không có ý khuyên bạn đừng học Data Analytics, mình chỉ muốn cảnh bảo một tương lai không phải màu hồng như các trung tâm hay vẽ ra thôi
Nếu bạn thấy bạn thực sự muốn làm và đam mềm ngành này => CHIẾN
Data Analyst là con đường nhẹ nhàng nhất để vào ngành Data ?
Khi các bạn chuyển ngành, luôn có những yêu cầu về chuyên môn và kỹ thuật, gọi chung là entry barrier (rào cản vào nghề).
Trong khi các vị trí Data Engineer, Data Scientist có những rào cản rất lớn về kỹ thuật và học thuật, thì Data Analyst lại dễ bước chân vào hơn, vì nó là sự giao thoa giữa công nghệ và một chuyên ngành nào đó (tài chính, retail, marketing, operation, SCM, ….)
Một vị trí Data Analyst cần các yếu tố cơ bản:
Kỹ năng phân tích dữ liệu (bao gồm tư duy và kỹ năng công nghệ)
Chuyên môn ở mảng mà bạn đang phân tích
Kỹ năng giao tiếp
Việc chuyển qua làm Data Analyst dễ vì 2 trong số 3 yếu tố đó không thuộc ngành kỹ thuật mà thuộc về chuyên môn khác. Chính bản thân mình cũng chọn con đường này vì nó nhẹ nhàng, đỡ sốc hơn.
Nhưng đừng hiểu nhầm. Data Analyst có entry barrier thấp hơn các vị trí khác, không có nghĩa là nó dễ hơn các vị trí đó.
Vì sao Data Analyst dễ thất nghiệp?
1/ Việc đã ít, lại còn bị cạnh tranh
Vì tính chất giao thoa giữa chuyên môn và kỹ thuật, bạn sẽ không thể có việc nếu không rành chuyên môn mà công ty đang cần phân tích. Và bạn sẽ phải cạnh tranh với những người có chuyên môn mạnh.
Một xu hướng bây giờ là các công ty đang tìm cách phân phối chức năng Analytics về từng phòng ban cụ thể.
Phòng data (hoặc IT) vẫn sẽ có Data Analyst nhưng chỉ cần số lượng rất ít, chuyên setup data model, chuyên phân tích các vấn đề về bản chất của data thu thập được, sau đó các phòng ban khác sẽ tuyển người biết làm chuyên môn để query vào dạng ad-hoc. Ví dụ:
Phòng marketing sẽ tuyển thêm Marketing Analyst, vừa biết marketing, vừa mạnh các kỹ năng về data.
Phòng tài chính sẽ tuyển Financial Analyst ,….
Hoặc cũng có các công ty lập nên các Analytics Department, sau đó tuyển Marketing Analyst, Financial Analyst, cho vào chung một bộ phận, và giảm bớt tuyển Data Analyst thuần tuý.
Công ty mình cũng nhận nhiều project thiết kế và tạo Data Model để các phòng ban khác query vào rồi kéo thả trong PowerBI. Có nhiều doanh nghiệp họ outsourcing luôn phần Data Analytics ra ngoài như vậy, đôi khi sẽ rẻ vừa hiệu quả hơn là xây dựng đội ngũ nội bộ.
Với xu hướng này, việc làm Data Analyst thuần kỹ thuật sẽ ngày càng ít đi.
Bạn – những người mới – sẽ chịu sự cạnh tranh khốc liệt từ các senior ở các ngành khác nhảy qua. Họ chỉ cần bổ sung thêm skill về Data, kết hợp các yếu tố có sẵn như chuyên môn tốt, leadership, communication skills,…
Họ không có cái mác Intern hay Fresher.Cạnh tranh với nhóm này thì hụt hơi!
2/ Cơ hội việc làm nhiều nhưng không dành cho Data Analyst và cũng ít tuyển fresher/intern
Các bạn có thể đọc thấy ngành Data đang rất HOT và nhiều cơ hội việc làm. Nhưng có thứ những quảng cáo khoá học không bao giờ nói với bạn. …
Nhiều ở mảng nào? Ngành data có rất nhiều vị trí: Data Analyst, Data Engineer, Data Scientist, Data Analytics Engineer, Database Administrator, AI Engineer…
Nhiều ở đâu? Ở Mỹ hay ở Việt Nam? Hay ở Châu Âu
Nhiều lúc nào? Cách đây 5 năm? 10 năm? Hay khi nào?
Hiện tại ở Việt Nam, thị trường việc làm ngành data cũng khá sôi động. Nhưng trong khi thị trường Mỹ luôn có chỗ cho intern, chương trình hợp tác để nuôi dưỡng tài năng, thị trường Việt Nam lại chỉ muốn tuyển người làm được việc ngay.
Vì thế thị trường việc làm Data ở Việt Nam bị lệch hẳn sang hướng từ Associate level trở lên. Hiếm khi nào tuyển fresher, intern, vì không nhiều doanh nghiệp có đủ nguồn lực tài chính, thời gian để training và chờ nhóm này phát triển.
Đó là về level, còn về vị trí, trong 3 vị trí chính Data Analyst / Data Engineer / Data Scientist thì thực tế tuyển dụng Data Analyst là hiếm nhất.
Doanh nghiệp chủ yếu tuyển Data Engineer (DE) vì nhóm này có thể tạo tác động trực tiếp lên hệ thống một cách tức thì. Chỉ cần có một bạn DE setup và migrate được hệ thống data cũ chậm chạp của công ty lên Cloud hoặc số hoá nó thành các hệ thống On-premise là thấy công ty khác hẳn liền. (Lưu ý là Data Engineer cũng hiếm khi tuyển fresher và intern nhé). Cái nào có tác dụng liền thì tất nhiên sẽ được ưu tiên.
Data Scientist thì mình chỉ thấy tuyển từ Middle hoặc từ 1 năm kinh nghiệm trở lên, và cũng là làm cho các dự án nước ngoài chứ không phải Việt Nam.
Các công ty về AI tại Việt Nam thì toàn tuyển người top thôi, hoặc bạn phải theo các chương trình residency (ươm mầm tài năng) từ rất lâu trước chứ không phải cứ học vài khoá học là xong. Mà AI đang cao trào nên các vị trí cho Data Scientist mở cũng nhiều lắm.
3/ Kinh tế suy thoái
Kinh tế suy thoái khiến cho các công ty cắt giảm ngân sách của team data lại vì không phải team nào cũng đem lại hiệu quả ngay. Vì thế họ sẽ có xu hướng tuyển người biết nhiều thứ.
Data Analyst mà biết thêm chút Machine learning thì càng hiệu quả để làm việc với Data Scientist. Data Analyst mà thêm kiến thức Data Engineer thì chúng ta sẽ có role Data Analytics Engineer, làm được nhiều thứ hơn, cần thì ETL luôn, biết xài Spark Airflow này nọ, giảm tải cho team, giảm gánh nặng tài chính cho công ty nữa.
Từ các ý trên, ai còn nghĩ ngành Data này học xong có việc luôn thì nên cẩn thận coi lại background của mình đã.
4/ Chưa kể giờ còn có AI!
Chính trong PowerBI đã có AI thể tự generate DAX function để vẽ chart chỉ bằng cách nhập yêu cầu theo ngôn ngữ tự nhiên, các module dự đoán, và khả năng gắn với các predictive model,…. Có sẵn hết. Gắn là chạy. Có thể các công nghệ này chưa chín tới, nhưng bạn sẽ thấy mọi thứ thay đổi nhanh thôi.
PowerBI giờ đã trang bị AI
Mình cũng dùng ChatGPT rất nhiều, vì nó thực sự giảm rất nhiều khối lượng công việc. Tất nhiên là dùng phải cẩn thận, mình phải hiểu rõ kết quả, mình chỉ nhờ nó làm bớt việc tay chân thôi. Sự tiện dụng của ChatGPT trong lập trình là không thể chối cãi.
ChatGPT có thể xử lý những cấu SQL phức tạp
Trong Tinh Tế có anh Thầy Giáo Sang có thể solo viết nguyên cái web app để ảnh dạy học nhờ ChatGPT.
Chat GPT không thay thế được một Data Analyst, nhưng nó cho công ty một lý do để không tuyển thêm người mới, mà nâng cấp team của họ lên với công cụ tốt hơn. Chuyện entry level data analyst thiếu việc vì AI theo mình là không thể tránh khỏi.
Những thắc mắc về nghề Data Analyst
1/ Phải cực giỏi Python mới gọi là dân data???
Các bạn nhìn vào giáo trình Data Analyst của vài trung tâm thấy dạy Python là chính. Lên các hội nhóm thấy vài anh chị lâu năm “gatekeeping” cái ngành này. Kiểu data analyst thì phải thế này thế kia, tech stack phải cỡ này, data phải cỡ trăm triệu dòng,… blah blah
Mình không nghĩ vậy. Tuỳ thị trường và công ty mà họ sẽ có những khái niệm rất khác nhau về một Data Analyst.
Có công ty thì cần bạn giỏi SQL là đủ, data infrastructure có đội Data Engineer lo rồi. Clean data này họ cũng có DE lo luôn ròi.
Có công ty thì đòi bạn phải giỏi cả Python.
Có chỗ Data xấu quá mà không có DE thì tuyển DA rành pandas, chỗ có DE thì tuyển DA mạnh về phân tích.
Có công ty đòi bạn phải master PowerBI, có công ty lại cần người giỏi Excel + VBA,…
Muôn hình vạn trạng. Mỗi quốc gia, mỗi ngành mỗi khác.
Miễn là bạn phân tích được dữ liệu, dù chỉ 1000 dòng thôi, nhưng tìm ra được các thông tin quan trọng và tạo sự tác động tích cực cho công ty, bạn chính là data analyst.
Tuỳ năng lực và độ phức tạp mà mức lương sẽ khác nhau. Nhưng phân tích dữ liệu thì không nhất thiết phải phức tạp.
2/ Mới học Data Analytics ra có được lương nghìn đô không?
Mình khẳng định luôn là được nhưng chuyện lương nghìn USD nó không hoàn toàn thuộc phạm trù bạn giỏi kỹ năng Data cỡ nào (vì như đã nói ở trên, Data Analyst không chỉ biết mỗi data). Vấn đề còn nằm ở chỗ bạn có biết tiếng anh hay không và công ty của bạn làm thế nào.
Đôi khi bạn không giỏi kỹ thuật lắm, nhưng bạn giao tiếp tốt, bạn rành chuyên môn, bạn có kỹ năng về leadership, làm việc với client được. Thì những giá trị đó sẽ bù lại. Quan trọng là các kỹ năng của bạn có thể kiếm tiền về cho công ty cỡ nào.
Các trung tâm hay nói học ra lương nghìn đô, nhưng công ty VN sẵn sàng bỏ ra nghìn USD cho một vị trí entry, cho một người mới là rất khó.
Còn nếu chỗ bạn apply một công ty Mỹ hay một công ty làm outsourcing các dự án tính bằng tiền đô thì chi ra $1,000 lại rất đơn giản với họ vì số tiền đó chả bao nhiêu so với quy mô dự án. Nhưng mà những kèo này thì … không nhiều.
Một thực trạng chung của ngành IT mà mình quan sát được: Không tiếng anh = lương thấp dù nhiều năm kinh nghiệm. Úp to chứ lúc deal thấp hơn nữa. Nhiều công ty lợi dụng việc bạn ko biết tiếng anh để ép giá.
3/ Tự học trên mạng có ra làm Data Analyst được không
Chắc chắn là được, nhưng còn tuỳ người. Bạn hoàn toàn có thể tự học kỹ năng data nhưng chuyên môn thì mình không chắc. Tuỳ xuất phát điểm và chuyên môn làm việc trước đó mà mỗi người mỗi khác. Rồi cách học nữa. Có người chỉ học mỗi 1 khoá data analyst, có người sẽ học thêm các thứ râu ria,….
Từ lý thuyết học ra làm việc thực tế nó rất khác các bạn ạ.
Ví dụ như các bạn học trên Datacamp cẳng hạn. Họ dạy SQL cũng gọi là ổn. Nhưng nếu bạn học theo track DA của họ thì lại thiếu mất phần setup một cái database SQL hay dùng các database client hay các tính năng như Store Procedure, các kỹ thuật Partition, Indexing,…. Thành ra các bạn bị giới hạn ở chỗ chỉ biết query, trong khi thực tế đi làm thì phải tương tác với database ở mức cao hơn vậy.
Nên các bạn cần chuẩn bị thêm các “giá trị khác” của bản thân để bù lại trong thời gian đầu.
4/ Học trung tâm có ổn không?
Chất lượng trung tâm thế nào thì mình không không nói được vì mình chưa bao giờ học ở đó. Nhưng rất khó để 1 khoá học có thể đáp ứng được nhu cầu, vì thị trường bây giờ đòi hỏi rất đa dạng như đã kể ở trên.
Mình có coi giáo trình của một trung tâm rất lớn thấy họ dạy rất sát thực tế việc làm DA ở Việt Nam, nhưng coi phản hồi học viên thấy quá trình dạy không ổn lắm. Có trong tâm khác cũng nổi tiếng thì dạy toàn Python với Machine Learning.
Nói chung cái này thì tuỳ mỗi người thôi. Có người cầm tay chỉ việc thì lúc nào cũng nhanh. Nhưng phải lựa các chỗ uy tín. Với mình thấy các khoá học giờ đắt quá.
Đừng học IT hay Data chỉ vì nghe trung tâm quảng cáo
Trung tâm nói lương cao
Không có gì sai khi chọn học một ngành nghề vì tiền cả. Là người Châu Á, chúng ta quá quen với kiểu muốn con cái học bác sỹ, kỹ sư để mong con cái có thu nhập tốt, công danh sáng lạng. Nhưng lương IT ở Việt Nam không cao như nước ngoài hay trên internet hay nói đâu các bạn.
Mình thấy ở Việt Nam có nhiều cách kiếm tiền khoẻ hơn đi làm IT.
Trước đây mình có công ty riêng, biz riêng. Và mình thấy với cùng mức độ nỗ lực thì kinh doanh đem lại cho mình nhiều tiền hơn. Tuy nhiên vì mình có mục tiêu rất cụ thể, không phải vì tiền, nên mình chấp nhận và có thể bền bỉ học tiếp.
Có một câu chuyện khá hay mình đọc được trên Reddit, đó là người giàu có ở thung lũng Silicon không phải là mấy anh lập trình, mà là bà bán mì Ramen góc đường, net worth hàng chục triệu USD. Các anh dev luôn vui vẻ chi tiền khủng ở đây để bù lại những áp lực công việc của họ.
Nếu vấn đề của bạn là muốn kiếm tiền thì mình tin là có nhiều con đường khác nhanh hơn và dễ hơn, đỡ nhức đầu hơn. Không nhất thiết phải đâm đầu vào đây nếu bạn không thích nó.
Nếu bạn muốn theo đuổi vì cảm thấy nó hợp, sống với con số, biểu đồ nó làm bạn thoải mái, bạn muốn tạo giá trị bằng con đường này…. Thì mình ủng hộ bạn hết cỡ.
Trung tâm nói học ra có việc hoặc hỗ trợ việc làm
Khi các trung tâm nói là hỗ trợ việc làm, tức là họ đang lấp liếm. Thực ra họ chỉ hỗ trợ các bạn TÌM VIỆC cho đến khi có việc thì thôi. Còn bao lâu có việc thì họ không nói và mức độ hỗ trợ tới đâu cũng vô cùng mơ hồ.
Mình nằm vùng trong hàng chục group tuyển dụng việc data, mình kết nối với nhiều HR trên Linkedln và theo dõi việc làm Linkedin rất nhiều. Nhưng chả có chỗ nào cho thấy cái sự “HOT” “ nhu cầu cao” như các khoá học nói cả. Toàn bán khoá học với cả lừa đảo nhập liệu thôi.
Mình tin là những người dạy học ở các trung tâm đều là các anh chị có chuyên môn cao và biết thực tế thị trường, những quảng cáo kia là do team marketing dựa trên “truyền thông ở một vũ trụ song song nào đó” viết nên. Nên nếu các trung tâm có đọc được bài này thì hy vọng mọi người điều chỉnh lại cho đúng hơn
Data analytics là một kỹ năng quan trọng và ai cũng cần. Không theo chuyên nghiệp về data cũng nên học để nâng cấp skillset, tư duy,…
Nhưng chốt lại là không có chuyện cứ học data analyst ra là sẽ có việc, offer nghìn đô liền nhé anh em. Phải có các yếu tố khác nữa.
Các cộng đồng nguồn mở đóng một vai trò then chốt trong việc tạo và phát triển các dự án phần mềm. Đây là sự đồng thuận chung giữa các nhà phát triển, nhưng việc xây dựng một cộng đồng hợp tác, toàn diện và sáng tạo không phải là điều dễ dàng.
Linus Torvalds có câu nói nổi tiếng: “Trong mã nguồn mở, chúng ta cảm thấy mạnh mẽ rằng để làm điều gì đó tốt, bạn phải có nhiều người tham gia”
Trong bài viết này, chúng ta sẽ bắt đầu tìm hiểu các kỹ thuật khác nhau để thiết lập nền tảng của một cộng đồng nguồn mở.
Cộng đồng nhà phát triển
Công nghệ nguồn mở được xây dựng dựa trên các nguyên tắc cốt lõi về tính minh bạch, cộng tác và đổi mới dựa vào cộng đồng. Những nguyên tắc này cho phép các nhà phát triển và người dùng sản phẩm cộng tác và đóng góp cho một dự án, đồng thời cho phép họ phát triển sản phẩm hơn nữa để phù hợp với nhu cầu cụ thể của họ.
Xây dựng cộng đồng mã nguồn mở
Việc thiết lập một cộng đồng đóng góp lại cho dự án, theo thời gian, thường mang lại những lợi ích sau:
Tăng cường đổi mới: Cộng đồng nhà phát triển nguồn mở khuyến khích cộng tác và cho phép đóng góp từ nhiều nhà phát triển khác nhau. Điều này dẫn đến các giải pháp sáng tạo và tiên tiến hơn.
Phát triển nhanh hơn: Với một cộng đồng các nhà phát triển làm việc trong một dự án, quá trình phát triển có thể tiến triển với tốc độ nhanh hơn. Các nhà phát triển có thể chia sẻ kiến thức và chuyên môn, xác định và khắc phục sự cố nhanh hơn, đồng thời giúp nhau vượt qua các trở ngại.
Áp dụng rộng rãi hơn: Các dự án nguồn mở thường có cơ sở người dùng rộng hơn do khả năng tiếp cận và chi phí thấp. Điều này có thể dẫn đến việc áp dụng và sử dụng công nghệ rộng rãi hơn.
Chất lượng được cải thiện: Các cộng đồng nguồn mở thường có quy trình xem xét nghiêm ngặt đối với các đóng góp, điều này có thể dẫn đến chất lượng code cao hơn và ít lỗi hơn.
Tăng khả năng hiển thị: Xây dựng một cộng đồng nguồn mở có thể giúp thúc đẩy một dự án và tăng khả năng hiển thị của nó. Điều này có thể dẫn đến nhiều quan hệ đối tác, cơ hội tài trợ và sự tham gia của cộng đồng.
Tính bền vững: Các dự án nguồn mở có thể bền vững hơn trong dài hạn, vì chúng ít phụ thuộc vào một tổ chức hoặc cá nhân duy nhất để phát triển và bảo trì. Cộng đồng có thể tiếp tục hỗ trợ và nâng cao dự án ngay cả khi những người sáng tạo ban đầu rời khỏi.
Hợp tác là cốt lõi của việc xây dựng một cộng đồng mã nguồn mở mạnh mẽ. Các dự án nguồn mở phát triển dựa trên sự hợp tác và như vậy, điều quan trọng là phải thúc đẩy một môi trường khuyến khích điều đó. Xây dựng một cộng đồng nguồn mở bao gồm một số bước chính, chẳng hạn như:
Xác định nhiệm vụ và mục tiêu của bạn
Xây dựng bộ quy tắc ứng xử
Thiết lập hướng dẫn đóng góp
Đầu tư tài liệu
Xây dựng lòng tin
Ghi nhận và khen thưởng những đóng góp
Chọn cơ sở hạ tầng cộng đồng của bạn
Liên tục đánh giá và cải tiến
Chúng ta hãy xem xét kỹ hơn cách thực hiện các bước này trong thực tế.
Xác định sứ mệnh và mục tiêu của bạn
Xác định nhiệm vụ và mục tiêu của một dự án nguồn mở là bước đầu tiên quan trọng trong quá trình phát triển. Một tuyên bố sứ mệnh được xây dựng tốt cung cấp sự hiểu biết rõ ràng về mục đích của dự án, các vấn đề mà dự án muốn giải quyết và giá trị mà nó tìm cách cung cấp cho người dùng.
Xác định mục tiêu, sứ mệnh của cộng đồng
Cộng tác là chìa khóa thành công của bất kỳ dự án mã nguồn mở nào. Khi bạn xác định nhiệm vụ và mục tiêu của dự án, điều cần thiết là xem xét cách những người đóng góp khác có thể cộng tác. Điều này liên quan đến việc xác định các lĩnh vực mà những người đóng góp có thể gia tăng giá trị cho dự án của bạn, loại đóng góp mà bạn mong đợi và cách bạn dự định cung cấp hỗ trợ và hướng dẫn cho những người đóng góp. Điều này không chỉ tạo ra một cộng đồng hòa nhập và đa dạng hơn mà còn nâng cao tiềm năng thành công của dự án.
Dưới đây là một số mẹo bạn có thể làm theo khi xác định nhiệm vụ và mục tiêu dự án của mình:
Xác định vấn đề hoặc nhu cầu dự án của bạn nhằm giải quyết
Xác định đối tượng mục tiêu của bạn
Viết một mô tả dự án rõ ràng, ngắn gọn, gói gọn các mục tiêu và giá trị của dự án của bạn
Thêm các chủ đề này vào readme của dự án là một cách dễ dàng để có được tầm nhìn về nhiệm vụ và mục tiêu của dự án của bạn. Bằng cách xác định nhiệm vụ và mục tiêu của dự án, bạn tạo ra một lộ trình hướng dẫn sự phát triển của dự án và thu hút những người đóng góp tham gia cộng đồng.
Tạo Quy tắc ứng xử
Quy tắc ứng xử đặt ra các tiêu chuẩn cho hành vi mà những người tham gia dự án phải tuân theo. Bằng cách triển khai và thực thi quy tắc ứng xử, bạn có thể thúc đẩy một môi trường xã hội tích cực trong cộng đồng của mình. Ngoài ra, quy tắc ứng xử giúp ngăn chặn và giải quyết hành vi không phù hợp hoặc có hại, chẳng hạn như quấy rối hoặc phân biệt đối xử, có thể tác động tiêu cực đến cộng đồng và các thành viên của cộng đồng.
Xây dựng quy tắc ứng xử
Bằng cách có một bộ quy tắc ứng xử rõ ràng, tất cả các thành viên của cộng đồng đều nhận thức được những gì được mong đợi ở họ và cách xử lý các tình huống khi các tiêu chuẩn này không được đáp ứng. Điều này có thể thúc đẩy một nền văn hóa tích cực và tôn trọng hơn trong cộng đồng, từ đó có thể thu hút và giữ chân những người đóng góp đa dạng hơn.
Có một bộ quy tắc ứng xử có thể giúp xây dựng lòng tin giữa các thành viên trong cộng đồng, đặc biệt là những người có thể đã trải qua hành vi loại trừ hoặc quấy rối trong các môi trường khác. Nó cho thấy rằng cộng đồng coi trọng và ưu tiên sự an toàn và hạnh phúc của các thành viên, đồng thời cam kết thúc đẩy một môi trường hòa nhập và thân thiện cho tất cả mọi người.
Đừng ngại áp dụng các khuôn mẫu đã được thiết lập.
Giao ước cộng tác viên là một nơi tuyệt vời để bắt đầu và đã được sử dụng bởi nhiều dự án nổi tiếng bao gồm Kubernetes, Mastodon, Golang và git!
Thiết lập nguyên tắc đóng góp
Nguyên tắc đóng góp là một cách để truyền đạt cách mọi người nên đóng góp cho dự án của bạn. Điều này cung cấp cho những người đóng góp các hướng dẫn để đảm bảo họ đang gửi các yêu cầu có ý nghĩa cho dự án của bạn.
Thiết lập nguyên tắc đóng góp
Các nền tảng như GitHub và GitLab có thể xác định nguyên tắc đóng góp trực tiếp trong kho mã của bạn.
Dưới đây là hai ví dụ mà chúng tôi cảm thấy làm nổi bật mục tiêu của hướng dẫn đóng góp
Việc thiết lập các nguyên tắc đóng góp đảm bảo dự án của bạn được thiết lập có tính đến những người đóng góp bên ngoài.
Một chủ đề chính nên được cộng hưởng từ những chủ đề ban đầu này là tầm quan trọng của tài liệu! Cho dù bạn đang xuất bản nguyên tắc cộng đồng hay xác định cách thức hoạt động của dự án, tài liệu là điều cần thiết cho sự phát triển của cộng đồng.
Đầu tư vào tài liệu
Tài liệu là một thành phần thiết yếu của bất kỳ dự án nguồn mở thành công nào. Nó cung cấp cho người dùng, người đóng góp và người bảo trì sự hiểu biết rõ ràng về mục đích, chức năng của dự án và cách sử dụng nó một cách hiệu quả. Tài liệu tốt cũng đóng một vai trò quan trọng trong việc tạo điều kiện thuận lợi cho sự hợp tác và phát triển cộng đồng bằng cách giúp những người đóng góp dễ dàng hiểu cách thức hoạt động của dự án và cách họ có thể đóng góp. Trong bối cảnh này, đầu tư vào tài liệu dự án nguồn mở không chỉ là vấn đề cải thiện trải nghiệm người dùng hoặc giảm thời gian bảo trì, mà còn là đầu tư cho sự bền vững và tăng trưởng lâu dài của dự án. Theo cách này, tài liệu có thể đóng một vai trò quan trọng trong việc đảm bảo sự thành công liên tục và tác động của các dự án nguồn mở.
Đầu tư vào tài liệu
Nói tóm lại, tài liệu tốt dẫn đến những điều sau:
Cộng tác tốt hơn
Tăng áp dụng
Tăng hiệu quả bảo trì và hỗ trợ
Tăng trưởng cộng đồng
Bền vững lâu dài
Có vô số công cụ giúp bạn sắp xếp tài liệu của mình.
Tài liệu là một cách tuyệt vời để tăng sự tham gia của cộng đồng, bất kể công cụ là gì. Quan trọng hơn, tài liệu là một bước đi đúng hướng để thiết lập niềm tin với các nhà phát triển.
Xây dựng lòng tin
Lòng tin là điều cần thiết trong bất kỳ cộng đồng nào, đặc biệt đối với cộng đồng nhà phát triển đang làm việc trong một dự án nguồn mở. Các nhà phát triển cần cảm thấy tự tin rằng các mục tiêu của dự án phù hợp với các giá trị của họ. Niềm tin là yếu tố cốt lõi trong việc thúc đẩy cộng tác, khuyến khích đổi mới và tạo cộng đồng giữa các nhà phát triển.
Xây dựng lòng tin
Nếu không có sự tin tưởng, cộng đồng nhà phát triển khó có thể làm việc hiệu quả cùng nhau hoặc đóng góp các kỹ năng và chuyên môn của họ cho dự án. Xây dựng niềm tin đòi hỏi sự minh bạch, cởi mở và giao tiếp rõ ràng.
Dưới đây là một số mẹo để thiết lập niềm tin trong cộng đồng nhà phát triển của bạn:
Minh bạch: Minh bạch là điều cần thiết trong việc xây dựng niềm tin với cộng đồng nhà phát triển. Hãy minh bạch về các mục tiêu của dự án, quy trình ra quyết định, tài chính và lộ trình. Chia sẻ thông tin một cách cởi mở và chủ động, đồng thời đảm bảo rằng mọi người trong cộng đồng đều có thể dễ dàng tiếp cận thông tin đó.
Khuyến khích sự tham gia của cộng đồng: Khuyến khích sự tham gia của cộng đồng là một cách khác để xây dựng lòng tin. Cho phép các thành viên cộng đồng đóng góp cho dự án theo những cách có ý nghĩa, cho dù thông qua đóng góp mã, tài liệu hoặc các hoạt động khác.
Lắng nghe phản hồi: Lắng nghe phản hồi từ cộng đồng là rất quan trọng trong việc xây dựng lòng tin. Thừa nhận và giải quyết các vấn đề kịp thời, đồng thời thông báo các bước đang được thực hiện để giải quyết chúng. Điều này cho thấy rằng bạn coi trọng đầu vào của họ và cam kết cải thiện dự án.
Xây dựng mối quan hệ: Xây dựng mối quan hệ với các thành viên cộng đồng là rất quan trọng trong việc xây dựng lòng tin. Tham dự các sự kiện cộng đồng, tham gia các diễn đàn và phòng trò chuyện, đồng thời tương tác với các thành viên cộng đồng trên mạng xã hội. Kết nối cá nhân này giúp xây dựng ý thức cộng đồng và thúc đẩy niềm tin giữa các nhà phát triển.
Duy trì chất lượng: Duy trì chất lượng trong dự án là một cách khác để xây dựng niềm tin với cộng đồng nhà phát triển. Đảm bảo rằng cơ sở mã được duy trì tốt, tài liệu được cập nhật và có thể truy cập được cũng như các lỗi được khắc phục kịp thời. Điều này cho thấy rằng bạn cam kết cung cấp một sản phẩm chất lượng và bạn thực hiện dự án một cách nghiêm túc.
Nhất quán: Khi một dự án nhất quán, điều đó có nghĩa là nó tuân thủ một bộ tiêu chuẩn nhất định và quá trình phát triển có thể dự đoán được. Khả năng dự đoán này giúp các nhà phát triển đóng góp cho dự án dễ dàng hơn và giảm nguy cơ nhầm lẫn hoặc hiểu lầm.
Cảm ơn những người đóng góp của bạn: Cảm ơn những người đóng góp không chỉ là một cách để thể hiện lòng biết ơn mà còn là một cách để ghi nhận và động viên những đóng góp của họ, xây dựng danh tiếng tích cực và thúc đẩy sự hợp tác trong cộng đồng.
Charm, một công ty tập trung vào việc xây dựng các công cụ để làm cho dòng lệnh trở nên hấp dẫn, là một ví dụ về công ty đã thành lập một cộng đồng nhà phát triển mạnh mẽ bằng cách thực hành nhiều mẹo được liệt kê ở trên. Gần đây nhất, Charm đã chứng minh điều này bằng cách tạo một kênh cộng đồng trên youtube giới thiệu cách người dùng tận dụng thư viện của họ trong các ứng dụng khác.
Ghi nhận và khen thưởng những người đóng góp
Công nhận và khen thưởng những đóng góp là một khía cạnh quan trọng khác của việc xây dựng một cộng đồng nhà phát triển mạnh xung quanh một dự án nguồn mở. Nó không chỉ giúp xây dựng niềm tin mà còn thúc đẩy những người đóng góp tiếp tục làm việc cho dự án.
Ghi nhận và khen thưởng
Công nhận và cảm ơn những người đóng góp cho công việc của họ trong ghi chú phát hành (release notes), bài blog hoặc cập nhật mạng xã hội. Bạn cũng có thể đề cập đặc biệt đến những người đóng góp trong tài liệu hoặc trang web của dự án. Bằng cách ghi nhận công khai những đóng góp của họ, bạn đang dành cho họ sự công nhận xứng đáng, điều này có thể giúp ích rất nhiều trong việc xây dựng lòng tin và lòng trung thành.
Một cách khác để công nhận những đóng góp là tạo ra một hệ thống khen thưởng những người đóng góp. Điều này có thể bao gồm việc cung cấp các ưu đãi như quà tặng, vé sự kiện hoặc quyền truy cập vào các tài nguyên độc quyền. Điều quan trọng cần lưu ý là không nhất thiết phải tập trung vào phần thưởng bằng tiền.
Cuối cùng, điều quan trọng là đảm bảo rằng tất cả các đóng góp được đánh giá một cách công bằng, bất kể nền tảng hoặc mức độ kinh nghiệm của người đóng góp. Bằng cách đánh giá tất cả các đóng góp như nhau, bạn đang gửi một thông điệp rằng mọi đóng góp đều quan trọng và mọi người đều có điều gì đó để cống hiến.
Chọn cơ sở hạ tầng cộng đồng của bạn
Xây dựng cơ sở hạ tầng cộng đồng của bạn là một bước quan trọng trong việc xây dựng một cộng đồng nguồn mở thành công. Cơ sở hạ tầng cộng đồng bao gồm các công cụ và nền tảng bạn sử dụng để hỗ trợ cộng tác và phát triển giữa các thành viên trong cộng đồng. Dưới đây là một số ví dụ về các công cụ và nền tảng cần thiết để xem xét:
Chọn cơ sở hạ tầng cộng đồng
Hệ thống quản lý kiểm soát nguồn (SCM): Hệ thống SCM là một công cụ được sử dụng để quản lý mã nguồn và các tệp khác liên quan đến phát triển phần mềm. GitHub, GitLab và Bitbucket là những hệ thống SCM phổ biến cho phép các nhà phát triển quản lý và cộng tác trên mã một cách hiệu quả.
Trình theo dõi sự cố: Trình theo dõi sự cố là công cụ cho phép bạn theo dõi các lỗi, yêu cầu tính năng và các sự cố khác liên quan đến phần mềm của bạn. Các vấn đề về GitHub, Jira và Bugzilla là những công cụ theo dõi vấn đề phổ biến mà bạn có thể sử dụng để theo dõi các vấn đề do cộng đồng đưa ra.
Nền tảng giao tiếp thời gian thực: Nền tảng giao tiếp thời gian thực, chẳng hạn như Slack hoặc Discord, cho phép các thành viên trong cộng đồng của bạn giao tiếp trong thời gian thực, cho phép cộng tác nhanh chóng và hiệu quả.
Diễn đàn hoặc Diễn đàn thảo luận: Một diễn đàn hoặc diễn đàn thảo luận, chẳng hạn như Discourse hoặc Reddit, cho phép các thành viên cộng đồng thảo luận về ý tưởng, đặt câu hỏi và chia sẻ kiến thức. Những nền tảng này rất cần thiết để xây dựng ý thức cộng đồng và tạo không gian để các thành viên kết nối.
Điều quan trọng là chọn các công cụ và nền tảng có thể truy cập và thân thiện với người dùng. Mục tiêu là giúp các thành viên cộng đồng dễ dàng đóng góp và cộng tác, đồng thời đảm bảo rằng công cụ cộng đồng được chọn hỗ trợ các mục tiêu và sứ mệnh của cộng đồng bạn.
Liên tục đánh giá và cải tiến
Liên tục đánh giá và cải thiện cộng đồng nguồn mở đảm bảo rằng cộng đồng đang đáp ứng nhu cầu của các thành viên và đạt được các mục tiêu của mình.
Liên tục đánh giá và cải tiến
Dưới đây là một số cách để thu thập phản hồi và cải thiện cộng đồng nguồn mở:
Yêu cầu phản hồi: Yêu cầu phản hồi từ các thành viên cộng đồng là điều cần thiết để hiểu nhu cầu của họ và cải thiện cộng đồng. Phản hồi có thể được thu thập thông qua khảo sát, thử nghiệm người dùng hoặc bằng cách khuyến khích các thành viên cộng đồng cung cấp phản hồi thông qua các diễn đàn trực tuyến hoặc các kênh khác
Đo lường tiến độ: Đặt số liệu và theo dõi tiến độ có thể giúp xác định xem cộng đồng có đạt được mục tiêu của mình hay không. Các số liệu có thể bao gồm những thứ như mức độ tương tác của cộng đồng, tỷ lệ đóng góp hoặc sự hài lòng của người dùng.
Xác định các lĩnh vực cần cải thiện: Thường xuyên đánh giá cộng đồng về các lĩnh vực cần cải thiện là một phần quan trọng trong việc xây dựng một cộng đồng thành công. Điều này có thể được thực hiện bằng cách xem xét phản hồi, phân tích số liệu và thu hút đầu vào từ các thành viên cộng đồng.
Thử nghiệm: Thử các phương pháp hoặc công nghệ mới có thể giúp cải thiện cộng đồng và thu hút các thành viên. Thử nghiệm những ý tưởng hoặc công cụ mới có thể giúp tìm ra những cách hiệu quả hơn để đạt được mục tiêu của cộng đồng và có thể giúp giữ chân các thành viên tham gia và hào hứng với sự tiến bộ của cộng đồng.
Ăn mừng thành công: Ăn mừng thành công và công nhận sự đóng góp của các thành viên trong cộng đồng là một phần quan trọng trong việc xây dựng một cộng đồng thành công. Công nhận và khen thưởng những người đóng góp có thể giúp xây dựng lòng tin, truyền cảm hứng cho những người khác đóng góp và giúp tạo ra một môi trường tích cực và hỗ trợ trong cộng đồng.
Liên tục đánh giá và cải thiện cộng đồng nguồn mở cho phép cộng đồng phát triển để đáp ứng nhu cầu của các thành viên và đạt được mục tiêu của mình. Điều này giúp xây dựng lòng tin, cải thiện chất lượng tổng thể của cộng đồng và thu hút những người đóng góp mới.
Kết
Xây dựng một cộng đồng nhà phát triển là một nỗ lực đầy thách thức nhưng bổ ích. Nó đòi hỏi một tầm nhìn rõ ràng, giao tiếp hiệu quả và cam kết minh bạch, tin cậy và toàn diện.
Một cộng đồng nhà phát triển thành công có thể thúc đẩy sự đổi mới, cộng tác và chia sẻ kiến thức cũng như tài nguyên. Bằng cách làm theo các mẹo và phương pháp hay nhất được thảo luận trong blog này, bạn có thể xây dựng một cộng đồng nhà phát triển vững mạnh và thịnh vượng góp phần vào sự phát triển và thành công của dự án nguồn mở của bạn.
Hãy nhớ liên tục đánh giá và cải thiện cộng đồng của bạn, công nhận và khen thưởng những đóng góp cũng như tập trung vào nhu cầu của các thành viên trong cộng đồng của bạn! Với sự cống hiến và làm việc chăm chỉ, bạn có thể xây dựng một cộng đồng nhà phát triển trao quyền và truyền cảm hứng cho các nhà phát triển để cùng nhau đạt được những điều tuyệt vời.
Hãy theo dõi để biết thêm nội dung tôn vinh các nhà phát triển và những đóng góp của họ cho công nghệ nguồn mở.
Ra mắt vào cuối năm 2022, có thể khó mà đánh giá vị trí của công nghệ Web3 vào năm 2023.
Bitcoin đã tăng lên 47.000 đô và giảm xuống còn 16.000 đô. Khối lượng giao dịch NFT đạt đỉnh là 17 tỷ đô vào tháng 1 năm 2022 và một năm sau đó đã giảm xuống chỉ còn 143 triệu đô.
“Chuỗi khối”(blockchain) và “tiền số” (digital currencies) đã trở thành thuật ngữ hàng ngày trên các phương tiện truyền thông chính thống. Chúng ta đã chứng kiến sự sụp đổ của FTX và tất cả các hậu quả kéo dài của nó.
Đó là một năm đầy biến động trong thế giới web3—đầy rẫy suy đoán, sự cố và bê bối. Nhưng điều này có nghĩa là web3 đã chết và các công nghệ cơ bản đã lỗi thời? Khó mà nói được.
Mặc dù làn sóng nhiệt tình đối với NFT và tiền điện tử đã giảm, nhưng cộng đồng vẫn còn rất nhiều và tích cực đầu tư không chỉ vào công nghệ mà còn để đảm bảo những lời hứa về một mạng internet phi tập trung được hiện thực hóa.
Thế giới nói chung đang thất vọng với các hoạt động thu thập dữ liệu của các đối thủ nặng ký trong ngành công nghệ.
Phạm vi tiếp cận toàn cầu của Thương mại điện tử cần các hệ thống thanh toán đáng tin cậy có thể hoạt động trên toàn thế giới.
Trong khi phần lớn các cuộc thảo luận xung quanh bộ sưu tập NFT tập trung vào các vụ mua lại và thua lỗ nổi tiếng, thì bản thân các NFT mới chỉ vạch ra bề nổi của những gì có thể xảy ra.
Web3 vẫn ở đấy
Chúng ta vẫn đang trong những ngày đầu của blockchain. Hãy nhớ rằng chúng ta đã sử dụng thuật ngữ “web 2.0” từ năm 1999 (24 năm trước!) nhưng blockchain đã lặng lẽ gia nhập thị trường như một công nghệ nền tảng cho Bitcoin vào năm 2008 (15 năm trước). Khoảng cách 9 năm đó nghe có vẻ nhỏ, nhưng hãy nhớ rằng chín năm trước, hầu hết các công ty lớn mới bắt đầu chuyển sang đám mây.
Web3 vẫn ở đây
Ngày nay, các công nghệ chuỗi khối mang đến nhiều sức mạnh hơn các giao dịch tiền điện tử cơ bản. Các ứng dụng tài chính ngân hàng hỗ trợ thanh toán xuyên biên giới chỉ trong vài giây chứ không phải vài ngày. Các giao dịch đa chuỗi và liên chuỗi thông qua các ứng dụng DeFi cho phép tăng tính thanh khoản của tiền điện tử và cải thiện trao đổi với các loại tiền tệ.
Các nhà phát triển chuỗi khối có thể xây dựng các sidechains (chuỗi bên) tùy chỉnh của riêng họ để hỗ trợ tích hợp với các giao dịch thời gian thực, chi phí thấp trong trò chơi điện tử và các trường hợp sử dụng khác. SDK (Software Development Kit, bộ công cụ phát triển phần mềm) có sẵn ở hầu hết mọi ngôn ngữ phổ biến, giúp các nhà phát triển web2 ngày nay dễ dàng sử dụng các khả năng viết mã hiện có của họ và nắm bắt công nghệ phi tập trung.
Các ứng dụng mới nổi của blockchain và tiền điện tử bao gồm:
Thanh toán xuyên biên giới
Theo dõi thời gian thực hàng hóa trong chuỗi cung ứng và logistics
Lưu trữ hồ sơ sức khỏe điện tử
Theo dõi giao dịch cung ứng năng lượng, bao gồm chứng chỉ năng lượng tái tạo
Quyền công dân và theo dõi thông tin xác thực xuyên biên giới
Tài liệu hóa các thỏa thuận pháp lý, chẳng hạn như bất động sản và tín dụng carbon
Bất chấp mọi thứ đã được báo cáo trong tin tức về tiền điện tử và chuỗi khối trong năm qua, tiềm năng của chúng phần lớn vẫn chưa được khai thác. Những tiến bộ của chuỗi khối đang mang lại tiện ích kinh tế và kỹ thuật cho cả người dùng và nhà phát triển. Nó thực sự là một công nghệ mới nổi với cơ hội dường như vô tận.
Công nghệ đằng sau các tiêu đề
Công nghệ bao gồm một chuỗi khối khá phức tạp. Theo nghĩa đơn giản nhất, blockchain là một cơ sở dữ liệu: nó lưu trữ dữ liệu theo thứ tự.
Tuy nhiên, một chuỗi khối không hoạt động như một cơ sở dữ liệu đơn giản với tất cả dữ liệu trên một máy chủ, mà giống như một sổ cái phân tán: nhiều máy tính trên khắp thế giới lưu trữ các bản sao dự phòng của tất cả dữ liệu trong chuỗi khối và chia sẻ công việc xác nhận giao dịch, mà không cần một cơ quan trung ương hoặc trung gian.
Sổ cái phân tán (Distributed Ledger)
Trong một chuỗi khối, mỗi nút (node) có một bản sao của sổ cái chuỗi khối và tham gia vào quá trình xác thực giao dịch. Các giao dịch mới được phát lên mạng và các nút làm việc cùng nhau để xác minh dữ liệu giao dịch và thêm nó vào chuỗi khối.
Quá trình này được gọi là sự đồng thuận và nó đảm bảo rằng tất cả các nút trên mạng đồng ý về trạng thái của chuỗi khối và nó vẫn an toàn và chống giả mạo.
Mặc dù một số chuỗi khối được tập trung và quản lý bởi một tổ chức duy nhất, nhưng hầu hết đều là nguồn mở và phi tập trung, nghĩa là chúng được quản lý và duy trì bởi một cộng đồng các nhà phát triển.
Ví dụ: Sổ cái XRP là một chuỗi khối công khai, không cần được cho phép (permissionless), nghĩa là bất kỳ ai trên internet đều có thể thiết lập trình xác thực và tham gia mạng. Việc triển khai tham chiếu của giao thức là nguồn mở và bất kỳ nhà phát triển nào cũng có thể đề xuất sửa đổi phần mềm này.
Do tính chất phi tập trung của Sổ cái XRP, không có cơ quan đơn lẻ nào có thể đưa ra quyết định cho mạng. Thay vào đó, các thay đổi của mạng được xác định bởi một nhóm nhỏ các trình xác thực cụ thể, những người bỏ phiếu thay mặt cho lợi ích tốt nhất của Sổ cái XRP.
Nói như vậy, để các sửa đổi được thông qua, ít nhất 80% cộng đồng người xác thực phải bỏ phiếu “đồng ý” và ngưỡng tối thiểu đó phải được duy trì trong ít nhất hai tuần. Nếu cả hai điều kiện đó được đáp ứng, thì các đề xuất sửa đổi có thể được thông qua.
Các giao thức đồng thuận chạy các chức năng mã hóa để đảm bảo tính toàn vẹn của mạng và sổ cái của nó. Chúng thường bao gồm:
Chức năng băm (Hash function): Tạo dấu vân tay kỹ thuật số duy nhất của mỗi giao dịch trên chuỗi khối. Chúng là các hàm một chiều nhận đầu vào (ví dụ: giao dịch) và tạo ra đầu ra duy nhất, có độ dài cố định dựa trên đầu vào đó (SHA-256 là một ví dụ về hàm băm). Các hàm băm đảm bảo tính toàn vẹn của dữ liệu vì bất kỳ lỗi nào trong quá trình truyền hoặc thay đổi khác đều dẫn đến một giá trị băm hoàn toàn khác. Nếu bạn nhận được cùng một đầu ra từ hàm băm, bạn biết rằng bạn có cùng một dữ liệu đầu vào.
Mật mã khóa công khai (public-key cryptography): Được sử dụng để cho phép liên lạc an toàn giữa các nút trên mạng. Mỗi nút trên chuỗi khối có một khóa chung và một khóa riêng. Khóa công khai có thể được chia sẻ với bất kỳ ai, trong khi khóa riêng được giữ bí mật. Chữ ký số là để đảm bảo tính xác thực và tính toàn vẹn của các giao dịch trên chuỗi khối. Mỗi giao dịch trên chuỗi khối được ký bằng khóa riêng của người gửi, tạo chữ ký số có thể được xác minh bằng khóa chung của người gửi.
Các nút trình xác nhận thực thi giao thức đồng thuận và thường có thể chạy trên phần cứng bán sẵn (tùy thuộc vào yêu cầu năng lượng và tính toán cho chuỗi khối cụ thể). Các chuỗi khối khác nhau sử dụng các giao thức đồng thuận khác nhau để tính toán trạng thái cuối cùng của giao dịch trên sổ cái.
Vì Sổ cái XRP là mã nguồn mở nên bất kỳ ai cũng có thể tìm hiểu cách thức hoạt động của nó, đóng góp vào cơ sở mã và báo cáo sự cố. Hoặc họ có thể chỉ cần viết và sử dụng ứng dụng; đúc, quản lý và tương tác với NFT; và nhiều hơn nữa.
Thuật toán đồng thuận, mức tiêu thụ năng lượng và thời gian giao dịch
Hai thuật toán đồng thuận phổ biến nhất từ lâu đã là Proof of Work (PoW) và Proof of Stake (PoS).
Proof of work (PoW) vs Proof of stake (PoS)
Trong thuật toán PoW, mọi nút trên mạng cạnh tranh để giải quyết các vấn đề về mật mã nhằm xác thực giao dịch.
Điều đó tốt cho các mạng nhỏ gồm vài chục máy tính, nhưng nhân chi phí tính toán này lên hơn 100.000 nút và nó tăng lên rất nhanh. Điều này được kết hợp bởi thực tế là các nút nhanh nhất để xác thực các giao dịch thường nhận được phần thưởng tài chính, do đó, một cuộc chạy đua vũ trang cạnh tranh để triển khai hàng nghìn GPU mạnh mẽ, ngốn điện để giải các câu đố mã hóa này nhanh hơn các nút khác trong mạng.
Các phương pháp PoW là nguyên nhân khiến Trung Quốc cấm khai thác tiền điện tử hoàn toàn, Nhà Trắng đưa ra thông cáo báo chí về những lo ngại về năng lượng và cộng đồng Ethereum thúc đẩy và chuyển sang phương pháp PoS tiết kiệm năng lượng hơn vào năm 2022.
Trong các thuật toán PoS, thay vì giải một câu đố mật mã trên mọi nút, các nút nắm giữ cổ phần (stake) lớn hơn trong mạng (tức là số lượng mã thông báo – token càng nhiều, cổ phần trong chuỗi khối càng lớn) là những nút xác thực giao dịch.
Chúng vẫn thực hiện quy trình xác thực mật mã, nhưng đó chỉ là một phần nhỏ trong số các nút trên mạng có cổ phần lớn nhất. Các thuật toán cũng không kém phần phức tạp và các cơ chế xác thực tương tự như PoW, đó là lý do tại sao các giao dịch PoS cũng có thể mất vài phút hoặc vài giờ để được xác thực.
Ethereum chuyển sang PoS “vì nó an toàn hơn, ít tốn năng lượng hơn và tốt hơn để triển khai các giải pháp mở rộng quy mô mới so với kiến trúc bằng chứng công việc trước đây.”
Đó là một sự thay đổi to lớn trong cách vận hành của chuỗi đó và giúp giảm hơn 99,9% lượng điện tiêu thụ. Trên thực tế, to lớn đến mức họ gọi nó là Sự hợp nhất (The Merge).
Theo CoinTelegraph, Ethereum trên PoW đã sử dụng 112 TWh mỗi năm và trên PoS hiện đang sử dụng 0,01 TWh mỗi năm. Để tham khảo, Bitcoin vẫn đang sử dụng năng lượng khổng lồ—nhiều hơn nhiều quốc gia trên trái đất.
Có nhiều lựa chọn thay thế cho các thuật toán PoS và PoW, với nhiều sự đánh đổi khác nhau về tốc độ, mức độ tập trung và hiệu quả.
Các chuỗi như Sổ cái XRP và Stellar sử dụng thuật toán “đồng thuận liên kết” (federated consensus) hoặc “bằng chứng liên kết” (proof of association) trong đó một tập hợp con các nút cùng nhau xây dựng và đồng ý về khối giao dịch tiếp theo.
Các chuỗi khác, chẳng hạn như Ignite, sử dụng các hệ thống kết hợp kết hợp các yếu tố của liên kết và PoS. Các hệ thống này hiệu quả hơn nhiều so với PoW và nhanh hơn cả PoW và PoS vì chúng tránh được công việc cạnh tranh lãng phí để giải các câu đố về mật mã. Ví dụ: các giao dịch trên XRPL mất 3-5 giây để được xác thực, thay vì vài phút hoặc vài giờ.
Ngoài ra, cả PoW và PoS thường cho phép trình xác thực chiến thắng xây dựng một khối theo ý muốn của chúng—điều này dẫn đến việc các công cụ khai thác và trình xác thực đánh lừa hệ thống để nhận được giá trị có thể trích xuất tối đa (MEV) từ mỗi khối. Các thuật toán đồng thuận liên kết thường ít gặp phải những vấn đề này vì chúng luôn sắp xếp từng khối giao dịch theo thứ tự chuẩn.
Giúp cho cuộc sống của các developer trở nên dễ dàng hơn bằng sự trừu tượng hóa, dApps và hợp đồng thông minh
Web2 mang đến cho chúng ta những trải nghiệm ứng dụng phong phú, điện toán đám mây, giao tiếp không đồng bộ và nhiều tính năng tập trung.
Trên thực tế, không thể phát triển ứng dụng web2 mà không trả tiền cho các công ty và tuân theo chính sách quyền riêng tư, điều khoản và điều kiện cũng như trách nhiệm ủy thác của họ.
Web3 cung cấp cho các nhà phát triển khả năng viết và chạy các ứng dụng hoàn toàn độc lập, phổ biến rộng rãi và phi tập trung. Không có giới hạn và không có sự phụ thuộc của công ty.
Web2 vs. Web3
Để biến điều này thành hiện thực, hầu hết các chuỗi khối lớn đang nỗ lực để thu hút và đưa các nhà phát triển vào nền tảng của họ bằng SDK (Software Development Kit, bộ công cụ phát triển phần mềm) dễ sử dụng và tài liệu chất lượng cao (ví dụ: Solana, Cardano, XRPL).
Chuỗi khối nguồn mở được phổ biến rộng rãi và cung cấp mảnh đất màu mỡ cho sự đổi mới. Mỗi loại đều có hỗ trợ tích hợp cho các giao dịch tài chính bằng cách sử dụng mã thông báo gốc của chúng (ví dụ: SOL, ADA, XRP), đảm bảo rằng mọi người có thể thanh toán và được thanh toán.
Nhiều chuỗi hỗ trợ phát triển dApps—các ứng dụng phi tập trung. Chúng có thể được viết bằng nhiều ngôn ngữ lập trình, tùy thuộc vào những gì chuỗi hỗ trợ.
Nói chung, cộng đồng nhà phát triển của một chuỗi nhất định càng lớn thì chuỗi đó hỗ trợ càng nhiều ngôn ngữ. Ví dụ: Ethereum hỗ trợ .NET, Go, Java, JavaScript, Python, Ruby, Rust, Dart và Delphi. XRPL hỗ trợ Python, JavaScript/TypeScript, C++, Java, React.js và Ruby.
Một số ứng dụng blockchain được hỗ trợ bởi hoặc được viết dưới dạng hợp đồng thông minh (smart contracts). Hợp đồng thông minh là các đoạn mã bất biến, chống giả mạo tồn tại trên chuỗi khối và tạo điều kiện thuận lợi cho các tương tác hoặc thỏa thuận giữa ứng dụng, người dùng và chuỗi.
Các chuỗi khối cung cấp các bản tóm tắt và SDK đơn giản để các nhà phát triển có thể thiết lập và chạy nhanh chóng với quá trình phát triển ứng dụng.
Ví dụ: Ethereum cung cấp nhiều công cụ phát triển ứng dụng để giúp mọi người thử nghiệm, xây dựng giao diện người dùng và thử nghiệm triển khai hợp đồng thông minh và dApps của họ.
Nhược điểm của hợp đồng thông minh là vì chúng không thay đổi và được chia sẻ trực tuyến, nếu bất kỳ ai tìm thấy lỗi trong mã của hợp đồng, họ có thể khai thác nó để làm lợi thế cho mình và nhà phát triển không thể dễ dàng vá lỗ hổng đó. Điều này làm cho việc phát triển các hợp đồng thông minh trở thành một nhiệm vụ tế nhị với số tiền đặt cược cao hơn so với nhiều dự án khác.
Sổ cái XRP hỗ trợ khả năng lập trình thông qua một số giao thức và tiêu chuẩn. Nó bao gồm các giao dịch viên gốc cung cấp các chức năng vượt trội đã được thử nghiệm và tiêu chuẩn hóa. Đề xuất Hooks sẽ tiếp tục mở rộng khả năng lập trình trên sổ cái. Hooks là những đoạn mã nhỏ, hiệu quả cho phép thực hiện logic nhanh chóng và dễ dàng trước và sau một giao dịch — tất cả đều có nguồn gốc từ Sổ Cái.
Điều này rất quan trọng vì các hợp đồng thông minh tiêu chuẩn có thể phức tạp và khó điều hướng, đặc biệt đối với các nhà phát triển mới sử dụng web3.
Không giống như các giao thức khác, XRPL cũng có hỗ trợ riêng cho NFT, có nghĩa là các nhà phát triển không cần xây dựng hoặc duy trì hợp đồng thông minh để đưa các dự án NFT của họ vào cuộc sống.
Điều này làm giảm rào cản gia nhập cho các nhà phát triển, người sáng tạo và bất kỳ ai khác muốn tương tác với NFT trên XRPL. Ngoài ra, tiền bản quyền tự động được thực thi ở cấp giao thức giúp đảm bảo giá trị tối đa cho người sáng tạo và nhà phát triển. Các hoạt động cốt lõi như đúc và ghi có nguồn gốc từ Sổ cái để thúc đẩy tính dễ sử dụng bất kể cấp độ kinh nghiệm.
Một sửa đổi sắp tới, XLS-30d, đề xuất một Nhà tạo lập thị trường tự động (AMM, Automated Market Maker) gốc trên XRPL. Đề xuất sẽ bao gồm các tính năng đặt giá thầu và bỏ phiếu, cho phép hoán đổi mã thông báo đơn giản và sẽ tạo ra tính thanh khoản cao giữa mã thông báo và các cặp tiền tệ. Chức năng của AMM cho phép các nhà phát triển ứng dụng tạo giao diện cho các nhà giao dịch và nhà cung cấp thanh khoản (LP) đồng thời giới thiệu một cơ chế đấu giá mới khuyến khích các nhà kinh doanh chênh lệch giá đồng thời giảm tác động của tổn thất tạm thời mà LP phải đối mặt.
Các nhà phát triển làm cho chuỗi tốt hơn—cho mọi người
Cộng đồng XRPL hiện cũng đang thử nghiệm sidechains (chuỗi bên).
Chuỗi bên cho phép các nhà phát triển xây dựng và thử nghiệm các tính năng tùy chỉnh trong môi trường giống như hộp cát (sandbox) —được kết nối với, nhưng khác biệt với mạng chính—cho phép đổi mới mà không làm gián đoạn hoặc ảnh hưởng đến mạng chính.
Các tính năng của Sidechain cuối cùng có thể được đề xuất dưới dạng sửa đổi và được hợp nhất vào mạng chính nếu được cộng đồng bình chọn.
Ngoài ra còn có sự phát triển và thử nghiệm liên tục của chuỗi bên Ethereum Virtual Machine (EVM) để đưa các hợp đồng thông minh dựa trên Solidity gốc của Ethereum vào hệ sinh thái XRPL.
Khi các nhà phát triển làm nhiều việc hơn trên các chuỗi khối, chắc chắn chúng ta sẽ thấy những cải tiến về tiện ích, bảo mật, khả năng mở rộng, chi phí và tính bền vững.
Càng nhiều người sử dụng, càng có nhiều cải tiến và càng có nhiều khả năng nhiều nhà phát triển (và người dùng) sẽ tiếp tục áp dụng công nghệ này. Hiệu ứng mạng và danh sách các tính năng sáng tạo đang phát triển nhanh chóng đã hấp dẫn các nhà phát triển muốn chuyển từ các quy ước web2.
Cách các developer có thể nâng cao kỹ năng và bắt đầu xây dựng
Những đổi mới được củng cố bởi blockchain và những lợi thế so với web2 đang trở nên khó có thể bỏ qua. Các giao thức Web3 đang giúp việc xây dựng trên các công nghệ phi tập trung trở nên dễ dàng hơn bao giờ hết.
Developer và cơ hội với web3
Công nghệ Web3 không chỉ là “một bản nâng cấp” hay “một bước tiến” từ web2—nó là một mô hình hoàn toàn mới để làm việc trên các ứng dụng. Chúng phi tập trung, không cần cấp phép, có thể mở rộng và ổn định.
Các nhà phát triển có thể sử dụng những gì họ đã biết và nâng cao kỹ năng cho các công nghệ web3. Lần đầu tiên, họ có thể tham gia trò chơi với toàn quyền sở hữu tài sản và tài sản trí tuệ của mình.
Bằng cách sử dụng các ngôn ngữ lập trình mà họ đã biết, họ có thể nâng cao kiến thức chuyên môn về lĩnh vực của mình và tận dụng lợi thế của tính phi tập trung.
Khi chọn một chuỗi để bắt đầu, các nhà phát triển nên xem xét:
Sự chấp nhận: Bạn có muốn xây dựng một chuỗi thời gian chính với nhiều người dùng, một chuỗi đang phát triển với cơ sở người dùng ngày càng tăng hay tham gia sớm vào một thứ gì đó hoàn toàn mới không?
Dễ phát triển: Có đầy đủ tài liệu, SDK được hỗ trợ và đầy đủ tính năng, hệ sinh thái của các ứng dụng dApp hiện có để khám phá và quá trình tích hợp ma sát thấp không?
Chức năng sổ cái và thời gian giao dịch: Sự đồng thuận hoạt động như thế nào? Có hiệu quả và nhanh chóng không?
Tác động môi trường: Tiêu thụ năng lượng và tính bền vững có phải ưu tiên cho chuỗi khối không?
Thời gian để dApp đầu tiên: Mất bao lâu để xây dựng một ứng dụng? Phút? Giờ? Tuần?
Cộng đồng: Có cơ sở người dùng và nhà phát triển sống động, sôi nổi không? Họ có đam mê về chuỗi, sự phát triển của nó và web3 không?
Chuỗi khối và tiền điện tử có khả năng tạo ra một tương lai tốt đẹp hơn và có một cộng đồng các nhà phát triển sôi nổi đang xây dựng, thử nghiệm và lặp lại trên công nghệ để giúp khám phá các trường hợp sử dụng và ứng dụng trong tương lai.
Có một số chương trình như trợ cấp và tiền thưởng để giúp các nhà phát triển ở mọi cấp độ bắt đầu với kinh phí và tài nguyên họ cần để đưa các dự án và ứng dụng web3 của họ vào cuộc sống.
Sổ cái XRP gần đây cũng đã ra mắt một cổng thông tin học tập trực tuyến, nơi các nhà phát triển có thể tìm hiểu thêm về kiến thức cơ bản về tiền điện tử và chuỗi khối hoặc đi thẳng vào mã hóa trên XRPL với các khóa học bằng các ngôn ngữ như React.js (hiện đang ở giai đoạn thử nghiệm).
1. Zoom bổ sung tính năng mới, cạnh tranh với Slack, Calendly, Google và Microsoft
Các tính năng này bao gồm tóm tắt cuộc họp do AI cung cấp, phản hồi email dựa trên lời nhắc và tạo bảng trắng cùng với video “Trò chuyện nhóm” và công cụ lên lịch cuộc họp.
Zoom đang mở rộng trợ lý Zoom IQ của mình để cung cấp các bản tóm tắt do AI cung cấp và “đặt thêm câu hỏi” ngay cả khi bạn tham gia cuộc họp giữa chừng. Sau khi cuộc họp kết thúc, bot sẽ đăng một bản tóm tắt lên tính năng trò chuyện nhóm của Zoom. Cho đến thời điểm hiện tại, Zoom IQ có khả năng ghi lại các điểm nổi bật, chia cuộc họp thành các chương và tự động liệt kê các mục hành động.
Zoom IQ
Zoom còn ra mắt Zoom Scheduler phiên bản beta công khai — một công cụ giống như Calendly để chia sẻ tính khả dụng để đặt lịch hẹn.
Zoom cũng giới thiệu các không gian làm việc chung ảo được gọi là Zoom Huddles, nơi mọi người có thể ghé vào hoặc rời đi bất cứ lúc nào. Tính năng này tương tự như tính năng Slack Huddles, được giới thiệu vào năm 2021 để có các cuộc trò chuyện nhanh bằng giọng nói hoặc dựa trên video trong thời gian thực.
2. Spotify ra mắt ‘Niche Mixes’, danh sách nhạc mà bạn có thể xây dựng chỉ dựa trên mô tả
Spotify đã ra mắt một tính năng mới có tên là Niche Mixes cho phép bạn tạo các danh sách kết hợp được cá nhân hóa của riêng mình chỉ dựa trên một vài từ mô tả trong tab Tìm kiếm.
Spotify Niche Mixes
Chẳng hạn, bạn có thể nhập “hoạt động, rung cảm hoặc thẩm mỹ”, sau đó thêm từ “mix” để tạo danh sách phát tùy chỉnh.
Spotify cho biết:
“Chúng tôi đang cung cấp cho người nghe quyền truy cập vào hàng chục nghìn Bản phối dành riêng cho họ dựa trên hầu hết mọi thứ họ có thể nghĩ ra.
Tính năng này cho phép người dùng tạo danh sách phát ngay lập tức cho hầu hết mọi thứ.
Ví dụ: bạn có thể tìm kiếm “feel good morning mix”, “90s running mix” hoặc “driving singalong mix”, trong số những thứ khác.
3. Asana sắp ra mắt các công cụ làm việc thông minh mới với AI
Asana, được xây dựng dựa trên biểu đồ công việc đã công bố một bộ bảng điều khiển mới hôm nay để cung cấp cho các nhà quản lý dữ liệu họ cần để đảm bảo các dự án luôn nằm trong ngân sách và đạt được mục tiêu.
Asana AI
Alex Hood, giám đốc sản phẩm của Asana, chia sẻ rằng:
“Chúng tôi đã tạo báo cáo điều hành có thể hữu ích ở bất kỳ cấp độ nào của công ty. Vì vậy, bất kể [công việc của bạn] là gì, bạn có thể có bộ bảng điều khiển về những thứ bạn quan tâm xuất hiện ngay lập tức chỉ bằng cách chọn [trong Asana] nhóm, dự án và danh mục đầu tư nào mà bạn quan tâm”.
“Bước tiếp theo sẽ là sử dụng AI để tạo danh mục về những thứ bạn quan tâm ngay lập tức. Vì vậy, giúp chúng trở nên ngày càng thông minh hơn, nhưng thực tế là chúng có thể ở bất kỳ cấp độ nào trong toàn bộ tổ chức, đó là một phần của lần ra mắt mới này”
“Chúng tôi đang cung cấp khả năng xem khối lượng công việc của bất kỳ ai trong toàn bộ lĩnh vực hoặc tổ chức… Chúng tôi hiển thị [dữ liệu này] ở định dạng rất trực quan, vì vậy bạn có thể biết ai đang làm việc hết công suất, ai đang ở dưới khả năng và bạn có thể cân bằng tải giữa họ trong một tổ chức thậm chí không chia sẻ hệ thống phân cấp”
“Chúng tôi có ba tính năng mới này chưa được hỗ trợ bởi AI. Nhưng chúng là những tính năng hướng chúng ta đến các loại vấn đề mà chúng ta muốn giải quyết bằng AI, bởi vì thế hệ tiếp theo dựa trên chúng sẽ được điều khiển bởi AI”
4. Google Search đang bổ sung các tính năng mới ‘Perspectives’ và ‘About this author’ để giúp người dùng xác minh thông tin
Tính năng Perspectives là carousel sẽ xuất hiện bên dưới Tin bài hàng đầu (Top stories) và giới thiệu thông tin chi tiết từ nhiều nhà báo, chuyên gia và những tiếng nói có liên quan khác về chủ đề bạn đang tìm kiếm.
Google Perspectives
Ý tưởng đằng sau tính năng này là cung cấp cho người dùng nhiều tiếng nói đáng chú ý về một chủ đề tin tức để mở rộng hiểu biết của họ về chủ đề này. Google cho biết carousel sẽ sớm ra mắt bằng tiếng Anh ở Mỹ và sẽ có sẵn trên máy tính để bàn và thiết bị di động.
Google cũng tung ra một tính năng mới gọi là “Giới thiệu về tác giả này” (About this author) cho phép người dùng dễ dàng tìm hiểu thêm về các tác giả đằng sau nội dung họ đang đọc. Với tính năng mới này, người dùng sẽ có thể tìm thêm thông tin về lý lịch của các tác giả mà Google hiển thị trên Tìm kiếm.
Tính năng “Giới thiệu về tác giả này” là bản mở rộng của tính năng “Giới thiệu về kết quả này” hiện tại của Google, tính năng này ra mắt lần đầu tiên vào năm 2021 bằng tiếng Anh.
5. Microsoft cho phép trí tuệ nhân tạo mở rộng về an ninh mạng
Là một phần trong nhiệm vụ tiếp tục đưa AI tổng quát vào tất cả các sản phẩm của mình, Microsoft hôm nay đã giới thiệu Security Copilot, một công cụ mới nhằm mục đích “tóm tắt” và “hiểu rõ” thông tin tình báo về mối đe dọa.
Security Copilot
Microsoft lập luận rằng Security Copilot, tích hợp với danh mục sản phẩm bảo mật hiện có của họ, được cải thiện tốt hơn nhờ các mô hình generative AI từ OpenAI — cụ thể là GPT-4 tạo văn bản mới ra mắt gần đây.
Phó chủ tịch điều hành Microsoft Security Charlie Bell cho biết
“Việc nâng cao trạng thái bảo mật đòi hỏi cả con người và công nghệ — sự khéo léo của con người kết hợp với các công cụ tiên tiến nhất giúp áp dụng kiến thức chuyên môn của con người ở tốc độ và quy mô. Với Security Copilot, chúng tôi đang xây dựng một tương lai nơi mọi người bảo vệ đều được trao quyền với các công cụ và công nghệ cần thiết để biến thế giới thành một nơi an toàn hơn.”
Microsoft không tiết lộ chính xác cách thức Security Copilot kết hợp với GPT-4. Thay vào đó, nó làm nổi bật một mô hình tùy chỉnh được đào tạo — có lẽ dựa trên GPT-4 — cung cấp sức mạnh cho Security Copilot “kết hợp một tập hợp ngày càng tăng các kỹ năng dành riêng cho bảo mật” và “triển khai các kỹ năng và truy vấn” nguyên tắc cho an ninh mạng.
Roblox là một nền tảng trò chơi trực tuyến và cộng đồng chơi game được phát triển bởi Roblox Corporation. Nền tảng này cho phép người dùng tạo, chia sẻ và tham gia vào các trò chơi được tạo bởi cộng đồng.
Roblox là gì? Ảnh: Roblox
Roblox cho phép người dùng tạo các trò chơi sử dụng ngôn ngữ lập trình Lua và chia sẻ chúng với người dùng khác trên toàn cầu.
Ngoài ra, Roblox cũng cung cấp cho người dùng một số trò chơi được phát triển bởi chính Roblox Corporation, bao gồm các trò chơi phiêu lưu, mô phỏng, thể thao và nhiều thể loại khác.
Roblox là một nền tảng được yêu thích đặc biệt đối với trẻ em và thanh thiếu niên vì tính năng tương tác và sáng tạo của nó. Nền tảng này cũng có tính năng xã hội mạnh mẽ, cho phép người dùng kết nối và giao tiếp với nhau trên toàn thế giới.
Những sự thật thú vị về Roblox
Roblox và một vài sự thật thú vị
1. Công ty game đầu tiên được niêm yết công khai
Vào tháng 3 năm 2021, Roblox Corporation đã chính thức niêm yết công khai trên sàn NASDAQ, trở thành một trong những công ty trò chơi đầu tiên được niêm yết công khai từ khi công ty Tencent của Trung Quốc và Netmarble của Hàn Quốc được niêm yết vào năm 2018.
Việc niêm yết công khai của Roblox đã thu hút sự chú ý của giới đầu tư và đánh giá công ty lên đến khoảng 38,2 tỷ USD.
2. Nền tảng trò chơi trực tuyến phổ biến nhất thế giới
Roblox đã trở thành một trong những nền tảng trò chơi trực tuyến phổ biến nhất thế giới.
Theo thống kê từ Roblox Corporation, vào tháng 12 năm 2021, Roblox có hơn 230 triệu người dùng đăng ký và trên 40 triệu trò chơi được tạo ra trên nền tảng này.
Điều đáng chú ý là hơn 50% số lượng người dùng của Roblox là trẻ em dưới 16 tuổi, và Roblox đã trở thành một phần không thể thiếu trong cuộc sống và giải trí của các em nhỏ trên toàn thế giới.
3. Roblox Studio
Nền tảng này không chỉ là một nơi để chơi game, mà còn là một nơi để học tập và phát triển kỹ năng lập trình cho các em nhỏ.
Roblox cung cấp một công cụ lập trình đơn giản, gọi là Roblox Studio, cho phép người dùng tạo ra các trò chơi, xây dựng thế giới ảo, tạo ra các mô hình và học cách viết mã lập trình bằng ngôn ngữ Lua.
Các em nhỏ có thể học hỏi kỹ năng lập trình và phát triển tư duy logic thông qua việc tạo ra các trò chơi và thế giới ảo của riêng mình trên nền tảng Roblox.
Ngoài ra, Roblox cũng cung cấp một loạt các khóa học và tài nguyên miễn phí để giúp người dùng học lập trình và phát triển kỹ năng của mình.
4. Một cách tiếp cận mới với công chúng
Nền tảng này cũng đã trở thành một trong những cách để các nghệ sĩ và nhà sản xuất âm nhạc tiếp cận với công chúng của mình.
Nhiều nghệ sĩ như Lil Nas X và Zara Larsson đã tổ chức các buổi biểu diễn âm nhạc trực tuyến trên Roblox để giới thiệu âm nhạc mới của họ cho cộng đồng người chơi trên nền tảng này.
Ngoài ra, Roblox cũng đã hợp tác với các nhà sản xuất âm nhạc để tạo ra các sự kiện âm nhạc đặc biệt trên nền tảng của mình.
Các sự kiện này bao gồm cả các buổi biểu diễn trực tiếp và các phần thưởng trong game liên quan đến âm nhạc. Việc kết hợp giữa âm nhạc và trò chơi đã tạo ra một trải nghiệm thú vị cho người chơi trên Roblox.
5. Một nền tảng quảng cáo mới
Nền tảng này đã trở thành một trong những cách hiệu quả để các nhà quảng cáo tiếp cận với đối tượng khách hàng tiềm năng của mình.
Do đa dạng và phong phú về nội dung, Roblox có thể đáp ứng nhu cầu của nhiều nhãn hàng và công ty khác nhau để quảng cáo sản phẩm hoặc dịch vụ của họ.
Các nhà quảng cáo có thể tạo ra các trò chơi hoặc sản phẩm liên quan đến thương hiệu của mình trên nền tảng Roblox.
Ngoài ra, họ cũng có thể sử dụng quảng cáo banner hoặc video để quảng bá sản phẩm của mình đến người chơi trên Roblox.
Do đó, Roblox đã trở thành một kênh quảng cáo hiệu quả đối với các nhãn hàng muốn tiếp cận với khách hàng tiềm năng của mình, đặc biệt là đối với đối tượng người dùng trẻ tuổi.
6. Nơi kiếm tiền
Nền tảng này đã trở thành một trong những nơi để các nhà phát triển game độc lập có thể kiếm tiền và phát triển sự nghiệp của mình.
Roblox cho phép các nhà phát triển tạo ra các trò chơi và bán chúng trên nền tảng của mình để kiếm tiền.
Người chơi trên Roblox có thể mua các sản phẩm trong game hoặc mua phiên bản Premium để có thể truy cập vào các tính năng đặc biệt.
Các nhà phát triển có thể kiếm tiền từ các sản phẩm trong game mà họ tạo ra hoặc từ việc bán phiên bản Premium của trò chơi của họ.
Nhiều nhà phát triển trên Roblox đã kiếm được số tiền đáng kể từ việc tạo ra các trò chơi phổ biến trên nền tảng này.
Một số ví dụ nổi bật bao gồm “Adopt Me!” của DreamCraft, “Jailbreak” của Badimo, và “MeepCity” của alexnewtron.
Roblox đã trở thành một cơ hội tuyệt vời cho các nhà phát triển game độc lập để phát triển sự nghiệp của mình và kiếm tiền từ đam mê của mình.
Sự kiện về chủ đề Roblox trong tháng 03
Không đi đâu xa, tháng 3 này, GAMBA sẽ tổ chức buổi chia sẻ về chủ đề mang tên: Get to Know Roblox Game Development Process với sự tham gia của 2 speaker trẻ tuổi, tài năng:
Anh Toan Tran, content creator và là chủ kênh “GÀ CÔNG NGHIỆP TV”, 325K subs
Anh Dao Le, Principle Software Engineer tại Roblox
Technical Event #17: Roblox Game Development Process
Đây là event được thiết kế phù hợp với các bạn là game developer, sử dụng quen thuộc Lua/Unity/Java, cũng như các bạn designer sử dụng Blender/3D Max.
