Cách trưởng bộ phận Marketing GitHub Nhật - Hàn tự động hóa vận hành sự kiện nhờ GitHub Copilot

Nếu bạn có thể viết ra cách mình thực hiện công việc, bạn có thể tự động hóa nó. Đây là những gì tôi đã làm để hỗ trợ đội ngũ marketing khu vực APAC của GitHub.

11 tháng 9, 2026

11 phút

Tôi phụ trách marketing cho GitHub tại Nhật Bản và Hàn Quốc, và các sự kiện chính là nhịp đập của công việc này: một chuỗi hội thảo trực tuyến định kỳ dành cho các nhà phát triển doanh nghiệp, các buổi gặp mặt cộng đồng tại Tokyo, và các phiên họp điều hành giới hạn khách mời tại Seoul. Một nhà phát triển ở thị trường này thực sự cần gì vào lúc này? Những chủ đề nào xứng đáng để họ dành ra một giờ đồng hồ, và ai nên có mặt trong phòng? Tôi sẵn lòng dành cả ngày để suy nghĩ về những câu hỏi đó.

Những gì diễn ra sau khi quyết định được đưa ra lại là một chuyện khác. Một khi sự kiện được phê duyệt, một trình tự cố định sẽ bắt đầu:

Mặc dù không có nhiệm vụ nào trong số này là khó khăn, nhưng chúng luôn tiềm ẩn nguy cơ dán nhầm liên kết, bỏ sót một ngày, hoặc viết sai tên chiến dịch mà 15 báo cáo phía sau đang phụ thuộc vào đó.

Vấn đề là thế này: Tôi từng là một kỹ sư. Sự nghiệp đầu tiên của tôi là duy trì cơ sở dữ liệu trên các máy chủ Linux cho khách hàng doanh nghiệp. Dù kỹ năng lập trình có thể đã mai một, tôi vẫn có thể nhìn thấy một quy trình (pipeline) đang "kêu cứu" để được tự động hóa. Đây là lúc tôi đưa GitHub Copilot vào sử dụng và bạn cũng có thể làm điều tương tự trong công việc của mình.

Vì vậy, tôi không viết code. Tôi viết ra các sổ tay vận hành (runbook), đưa chúng cho GitHub Copilot và phát triển quá trình tự động hóa thông qua đối thoại. Ngày nay, một sự kiện mà tôi từng phải tự tay chuẩn bị trong vài ngày giờ đây tự thiết lập từ một GitHub Issue duy nhất, tự sàng lọc người đăng ký mỗi sáng và tự dọn dẹp sau khi kết thúc.

Bài viết này sẽ đi sâu vào cách thức hoạt động của hệ thống đó, và lý do tại sao tôi tin rằng bất kỳ ai có công việc liên quan đến các tác vụ lặp đi lặp lại trên các công cụ có khả năng lập trình (thông qua API hoặc thậm chí chỉ là CLI) đều có thể làm được điều tương tự.

Một sự kiện là một Issue

Tôi không thể nhận ý tưởng nền tảng này là của riêng mình. Các đội ngũ marketing tại GitHub đã có thói quen mở một GitHub Issue cho mỗi dự án. Đây là nơi chứa đựng kế hoạch, các cuộc thảo luận và trạng thái công việc. Issue vốn đã là đơn vị công việc của chúng tôi. Những gì tôi làm là khiến cho Issue đó tự thực hiện công việc.

Ba yếu tố nguyên thủy (primitives) của GitHub gánh vác toàn bộ hệ thống:

Mọi thứ mà một repository mang lại cho các nhà phát triển, nó cũng cung cấp miễn phí cho quy trình marketing của tôi: lịch sử, khả năng hiển thị, đánh giá và một đường dẫn URL cho mọi quyết định.

Một điều đã làm cho điều này trở nên khả thi, và nó không liên quan cụ thể đến các sự kiện: nền tảng quản lý sự kiện của chúng tôi cung cấp một API. CRM của chúng tôi thậm chí không cần API; CLI chính thức của nó bao quát mọi thứ chúng tôi làm, và tôi chưa bao giờ phải cấu hình khóa API cho nó, vì CLI đăng nhập thông qua trình duyệt và xử lý xác thực từ đó. Dù là API hay CLI, yêu cầu vẫn như nhau: một cách thức để can thiệp bằng script. Nếu công việc lặp đi lặp lại của bạn chạy qua một công cụ cung cấp nền tảng sự kiện, CRM, trình tạo biểu mẫu, hay dịch vụ phân tích, thì mô hình trong bài viết này đều áp dụng được cho bạn.

Một nhà phát triển khi đọc đến đây có thể đã nghĩ ngay đến phản đối hiển nhiên: đây chẳng phải là "phát minh lại bánh xe" sao? Các nền tảng tự động hóa marketing đã tồn tại, và một nền tảng tốt có thể đã giải quyết được một phần vấn đề này ngay từ đầu. Nhưng APAC không phải là một thị trường đơn nhất mà là tập hợp của nhiều thị trường rất khác biệt, và ngay cả trong đội ngũ của tôi, quy trình làm việc cũng thay đổi theo từng tiểu vùng và từng phân khúc. Cùng một hội thảo trực tuyến có thể được tổ chức bằng tiếng Nhật cho Tokyo vào tháng này và bằng tiếng Hàn cho Seoul vào tháng sau, với các phân khúc khác nhau, các trường dữ liệu khác nhau trong CRM và định nghĩa khác nhau về một khách hàng tiềm năng chất lượng. Việc bắt một công cụ đóng gói sẵn phải đáp ứng tất cả các biến thể đó đồng nghĩa với ngân sách tùy chỉnh, chi phí tư vấn và phải chờ đợi lộ trình phát triển của người khác. Tự xây dựng từ các công cụ sẵn có đồng nghĩa với việc thay đổi quy trình chỉ là một pull request: tôi mô tả những gì tôi muốn, người đánh giá kiểm tra nó, và nó được đưa vào nhánh chính (main branch) thông qua chính quy trình mà các nhà phát triển sử dụng để thay đổi phần mềm.

Lập kế hoạch cho một sự kiện là một cuộc đối thoại

Quy trình bắt đầu trước khi Issue tồn tại. Tôi mở GitHub Copilot và nói đại ý: "Tôi muốn tổ chức một hội thảo trực tuyến về phát triển có sự hỗ trợ của AI vào tháng 11."

Những gì xảy ra tiếp theo được định hình bởi một tệp tin có tên AGENTS.md nằm ở thư mục gốc của repository. Đó là sổ tay vận hành của đội ngũ chúng tôi, được viết bằng Markdown thuần túy, định nghĩa cách chúng tôi đặt tên chiến dịch, cách các quý tài chính tương ứng với ngày tháng, múi giờ mà mỗi khu vực sử dụng và một email mời tham dự chuẩn mực trông như thế nào. GitHub Copilot đọc nó, sau đó tìm một sự kiện tương tự trong quá khứ, đề xuất tên chiến dịch tuân theo quy tắc đặt tên của chúng tôi, soạn thảo hai phiên bản email mời và hỏi tôi những câu hỏi mà sổ tay vận hành yêu cầu.

Việc đặt một cuộc đối thoại lên đầu quy trình là một quyết định thiết kế, và nó giải quyết hai vấn đề cùng lúc. Nếu tự động hóa mọi thứ, bạn sẽ mất đi sự linh hoạt; vào ngày bạn muốn sự kiện này khác biệt một chút, một quy trình cứng nhắc sẽ không có chỗ để điều chỉnh. Nhưng nếu để con người tự điền mọi thứ, bạn sẽ gặp sai sót. Cuộc đối thoại nằm chính xác giữa hai thái cực đó. GitHub Copilot tuân theo mẫu, vì vậy dữ liệu nằm trong Issue là dữ liệu đúng với định dạng đúng. Và vì đó là một cuộc đối thoại, tôi có thể điều chỉnh các chi tiết cho sự kiện này mà không làm hỏng bộ máy phía sau.

Khi chúng tôi mới bắt đầu, cuộc đối thoại này diễn ra trong GitHub Copilot CLI, trên terminal. Điều đó ổn với tôi, nhưng "mở terminal" là một rào cản đối với nhiều người mà tôi muốn đưa vào quy trình này. Với ứng dụng GitHub Copilot, cuộc đối thoại tương tự giờ đây diễn ra trong một cửa sổ máy tính để bàn thông thường. Rào cản gia nhập đã giảm từ "phải thoải mái với dòng lệnh" xuống còn "biết gõ phím".

Tôi muốn làm rõ về sự phân công lao động, vì đó là điểm mấu chốt: GitHub Copilot soạn thảo; tôi quyết định. Mọi tên chiến dịch, mọi tiêu đề email, mọi ngày tháng đều cần sự phê duyệt của tôi trước khi bất cứ thứ gì được thực hiện. Khi kết thúc cuộc đối thoại, GitHub Copilot tạo GitHub Issue với các nhãn (label) phù hợp, và đó là lúc máy móc tiếp quản.

Một nhãn, một sự kiện, được dàn dựng hoàn chỉnh

Ngay khi nhãn "event-setup" được gắn vào Issue, một quy trình GitHub Actions sẽ tiếp nhận và thực hiện trong vài phút những việc mà trước đây tôi phải mất gần cả ngày:

Việc sàng lọc người đăng ký chạy theo lịch trình thay vì theo nhãn. Mỗi sáng, một quy trình kích hoạt bằng cron sẽ lấy danh sách người đăng ký mới nhất cho mọi sự kiện đang mở và chia sẻ danh sách đã được làm sạch. Đối với các sự kiện giới hạn khách mời, nó cũng sàng lọc danh sách chờ dựa trên tiêu chí của chúng tôi (người đăng ký này có phải là nhà phát triển tại một tài khoản doanh nghiệp, sinh viên, hay đối thủ cạnh tranh đang rất muốn tham dự buổi họp điều hành của chúng tôi không?) trước khi bất kỳ ai được phê duyệt.

Quyết định thiết kế mà tôi tự hào nhất là một công tắc bật/tắt đơn giản có tên DRY_RUN, được lưu trữ như một cài đặt (theo thuật ngữ của GitHub là một biến repository) mà mọi quy trình đều kiểm tra trước khi chạy. Bật nó lên, mọi quy trình sẽ chạy thử mà không chạm vào bất kỳ hệ thống bên ngoài nào: không tạo trang đích, không tạo Issue trong các repository khác, không chia sẻ danh sách. Khi bạn là một đội ngũ marketing tự động hóa công việc của chính mình, bạn cần một cách để diễn tập. DRY_RUN chính là công tắc diễn tập đó, và đó là lý do tôi không bao giờ sợ thử nghiệm.

Sau sự kiện, một lệnh slash

Công việc sau sự kiện từng là phần tồi tệ nhất: xuất danh sách người tham dự, định dạng lại các cột để tải lên CRM, đối chiếu tên công ty với hồ sơ tài khoản và viết báo cáo. Bây giờ chỉ cần hai lệnh.

/lead-upload lấy danh sách người tham dự, định dạng chính xác theo yêu cầu của đội ngũ vận hành marketing để tải lên CRM, tạo Issue yêu cầu và đóng các Issue theo dõi. /event-report lấy các số liệu tham dự và kết quả khảo sát, sau đó đăng báo cáo dưới dạng bình luận trên Issue của sự kiện đó, quay trở lại đúng URL nơi mọi thông tin về sự kiện này tồn tại.

Đây là các kỹ năng của tác nhân (agent) GitHub Copilot, và đây là phần tôi muốn bạn lưu tâm nhất: một kỹ năng là một tệp Markdown. Mỗi kỹ năng là một SKILL.md: một quy trình được viết bằng văn xuôi, hướng dẫn GitHub Copilot phải làm gì, theo thứ tự nào và cần lưu ý điều gì. Các tệp của tôi đọc giống như những sổ tay vận hành mà tôi từng giữ trong đầu, vì đó chính xác là những gì chúng thể hiện.

Nếu bạn có thể viết một sổ tay vận hành, bạn có thể viết một kỹ năng.

Các kỹ năng cũng là thứ giữ cho hệ thống luôn linh hoạt. Không có hai thị trường nào trong khu vực Châu Á - Thái Bình Dương (APAC) thực hiện việc theo dõi sau sự kiện giống hệt nhau. Khán giả khác nhau, phân khúc khác nhau, quy ước địa phương khác nhau, và một quy trình được lập trình cứng (hard-coded) sẽ ép buộc mọi thị trường vào một khuôn mẫu duy nhất. Một quy trình viết bằng Markdown thì linh hoạt: mỗi thị trường có thể điều chỉnh sổ tay vận hành cho phù hợp với thực tế của riêng mình mà không cần chạm vào bộ máy bên dưới. Đó chính xác là lý do tại sao các bước sau sự kiện nằm trong các kỹ năng của GitHub Copilot thay vì trong các quy trình cố định.

Chúng tôi coi các kỹ năng như code ở một khía cạnh: các kỹ năng mới được thêm vào thông qua pull request và được đánh giá trước khi hợp nhất, với tệp CODEOWNERS điều hướng việc đánh giá đến người quản lý. Tự động hóa marketing với một quy trình phê duyệt. Khả năng quản trị này cũng được cung cấp miễn phí cùng với nền tảng.

Các rào chắn tích hợp cho phép tôi thử nghiệm

Tôi đã tự động hóa một quy trình liên quan đến dữ liệu khách hàng và thông tin xác thực API, trong một repository mà cả đội ngũ của tôi có thể nhìn thấy, trong khi bản thân hầu như không cần viết code. Sáu tháng trước, tôi sẽ nói rằng sự kết hợp đó là liều lĩnh. Điều thay đổi suy nghĩ của tôi là nhận ra có bao nhiêu rào chắn đã được thiết lập sẵn trước khi tôi bắt đầu.

Một số rào chắn tôi đã tự xây dựng: công tắc DRY_RUN, một bộ kiểm thử chạy trên mỗi pull request và đánh giá code cho mọi thay đổi. Những thói quen tiêu chuẩn của nhà phát triển. Hóa ra chúng bảo vệ công việc marketing cũng tốt như cách chúng bảo vệ phần mềm.

Nhưng những rào chắn quan trọng nhất lại đi kèm với nền tảng:

Một điều nữa mà các kỹ năng mang lại, gần như là một tác dụng phụ: vì mỗi quy trình giờ đây là một đơn vị công việc được đặt tên và cố định, tôi có thể khớp mô hình với công việc, lựa chọn từ danh sách mà tổ chức của chúng tôi đã phê duyệt. Một mô hình nhanh, chi phí thấp xử lý việc làm sạch danh sách hàng ngày; một mô hình mạnh mẽ hơn sẽ soạn thảo nội dung chiến dịch.

Và một thất bại trung thực để bạn không lặp lại: quy trình sàng lọc buổi sáng đã từng thất bại âm thầm trong năm ngày trước khi có ai đó nhận ra danh sách đã cũ. Tự động hóa mà bạn không giám sát giống như một quả bom hẹn giờ. Hãy cung cấp cho mọi quy trình theo lịch trình một cách để "kêu cứu" nếu có lỗi xảy ra để bạn không bỏ lỡ.

Bắt đầu với một nhiệm vụ

Đây là những gì tôi muốn gợi ý, từ một người từng làm việc thủ công nay đã "hồi phục" gửi đến những người khác.