Tối ưu hóa thời gian xây dựng hình ảnh Docker: Hướng dẫn thực tế cho nhóm sản xuất

Tối ưu hóa thời gian xây dựng hình ảnh Docker có nghĩa là giảm thời gian cần thiết để tạo ra hình ảnh vùng chứa đáng tin cậy mà không vi phạm hành vi thời gian chạy, khả năng tái tạo hoặc độ an toàn khi triển khai. Đối với người sáng lập, người đứng đầu nền tảng, kỹ sư dữ liệu và nhóm AI, mục tiêu thực tế không chỉ là một Dockerfile sạch hơn. Đó là phản hồi nhanh hơn, xung đột CI/CD thấp hơn và quy trình triển khai mà nhóm của bạn có thể tin cậy.

Vấn đề của người mua rất đơn giản: một thay đổi nhỏ về mã sẽ không khiến cả nhóm phải chờ đợi quá trình xây dựng lại chậm chạp trước khi đường ống dữ liệu, API hoặc dịch vụ đại lý có thể xuất xưởng. Sai lầm mà chúng tôi thấy là coi tối ưu hóa Docker như một danh sách các thủ thuật thay vì quy trình vận hành với các cổng đo lường, đánh giá và an toàn khôi phục.

Tại Van Data Team, chúng tôi bắt đầu bằng cách làm cho đường dẫn xây dựng có thể quan sát được: lớp nào đã thay đổi, bước phụ thuộc nào đã chạy lại, trình chạy CI nào bị mất bộ nhớ đệm và quá trình triển khai nào bị trì hoãn. Sau đó, chúng tôi kết nối bản sửa lỗi với hệ thống rộng hơn, cho dù đó là kỹ thuật đường ống dữ liệu, triển khai dịch vụ AI, tự động hóa báo cáo hay quy trình phân phối nền tảng có sự đánh giá của con người.

Hướng dẫn này cung cấp cho bạn quy trình làm việc sẵn sàng sản xuất: xây dựng cơ sở, cơ cấu lại các lớp Dockerfile, sử dụng bộ đệm một cách có chủ ý, giảm các phần phụ thuộc không cần thiết, xác thực trong CI/CD và ghi lại kết quả để lần chỉnh sửa tiếp theo không hoàn tác cải tiến.

Bài học chính

• Các bản dựng Docker nhanh hơn bắt đầu bằng phép đo chứ không phải phỏng đoán: so sánh các bản dựng cục bộ và CI/CD trong các điều kiện tương tự trước khi gọi một thay đổi thành công.
• Thứ tự lớp thân thiện với bộ đệm thường quan trọng hơn việc chỉ giảm số lượng hướng dẫn Dockerfile.
• Hình ảnh nhỏ hơn và bản dựng nhanh hơn chồng lên nhau, nhưng chúng không có cùng mục tiêu; tối ưu hóa cả hai một cách riêng biệt.
• Các bản dựng nhiều giai đoạn rất hữu ích khi chúng tách biệt công cụ tại thời điểm xây dựng khỏi các tạo phẩm thời gian chạy mà không khiến Dockerfile khó bảo trì.
• Nhóm sản xuất cần các cổng đánh giá về hành vi thời gian chạy, trạng thái bảo mật, khả năng quan sát và hành vi bộ đệm CI/CD.

Tối ưu hóa thời gian xây dựng hình ảnh Docker là gì?

Tối ưu hóa thời gian xây dựng Docker là phương pháp giảm thời gian cần thiết để tạo hình ảnh vùng chứa trong khi vẫn duy trì hành vi thời gian chạy, tính bảo mật, khả năng tái tạo và độ tin cậy triển khai. Thời gian xây dựng bị ảnh hưởng bởi lựa chọn hình ảnh cơ sở, cài đặt phụ thuộc, thứ tự lớp Dockerfile, kích thước ngữ cảnh bản dựng, tái sử dụng bộ đệm, tệp sao chép và hành vi của trình chạy CI/CD.

Phần quan trọng là "trong khi bảo quản." Bản dựng chạy nhanh hơn do bạn đã xóa chẩn đoán, bỏ qua bản cập nhật bảo mật hoặc khiến phiên bản phụ thuộc không thể dự đoán được không phải là cải tiến về mặt sản xuất. Đó là nợ kỹ thuật với thời gian ngắn hơn.

Tài liệu riêng của Docker giải thích rằng việc sử dụng lại bộ đệm của bản dựng phụ thuộc vào việc các lớp trước có thể được sử dụng lại hay phải bị vô hiệu hóa bởi các hướng dẫn, tệp hoặc đầu vào bản dựng đã thay đổi. Tài liệu về bộ đệm của bản dựng Docker là điểm khởi đầu phù hợp để hiểu về cơ chế.

Một ví dụ đơn giản: nếu Dockerfile của bạn sao chép toàn bộ ứng dụng trước khi cài đặt các phần phụ thuộc, thì mọi thay đổi nguồn có thể làm mất hiệu lực lớp cài đặt phụ thuộc. Nếu trước tiên bạn sao chép package.json, package-lock.json, requirements.txt hoặc các tệp kê khai tương đương, cài đặt các phần phụ thuộc tiếp theo và sao chép mã nguồn sau, thì những thay đổi chỉ có mã sẽ ít có khả năng buộc phải cài đặt lại toàn bộ phần phụ thuộc.

Mô hình đó không phải là phép thuật. Đó là một cách điều chỉnh cấu trúc Dockerfile theo cách ứng dụng của bạn thực sự thay đổi.

Đo lường trước khi chỉnh sửa Dockerfile

Trước khi thay đổi Dockerfile, hãy tạo đường cơ sở. Nếu không, bạn sẽ không biết liệu cải tiến có hiệu quả hay không, liệu nó chỉ giúp ích cục bộ hay liệu nó có làm cho CI/CD trở nên tồi tệ hơn hay không.

Theo dõi những điều này một cách riêng biệt:

Sử dụng lệnh lặp lại để xem xét cục bộ:

time docker build --progress=plain -t app:baseline .

Sau đó thay đổi từng biến một. Nếu bạn thay đổi tất cả hình ảnh cơ sở, cài đặt phụ thuộc, .dockerignore và bộ đệm CI trong một lần, bạn có thể có được bản dựng nhanh hơn nhưng không tìm hiểu được nguyên nhân.

Bản dựng cục bộ và bản dựng CI/CD cũng khác nhau. Máy của nhà phát triển có thể có bộ đệm ấm và bộ nhớ cục bộ nhanh. Trình chạy được lưu trữ có thể khởi động nguội, kéo hình ảnh cơ sở mỗi lần hoặc loại bỏ bộ nhớ đệm giữa các tác vụ trừ khi được định cấu hình. Đó là lý do tại sao việc đánh giá nên bao gồm cả hành vi cục bộ và quy trình.

Đối với các nhóm triển khai kiến trúc hướng sự kiện với hàng đợi tin nhắn, điều này rất quan trọng trong quá trình ứng phó sự cố. Nếu dịch vụ phát trực tuyến cần bản sửa lỗi sản xuất thì hệ thống xây dựng sẽ không trở thành hệ thống chậm nhất chưa xác định trong quá trình khôi phục.

Xây dựng các Dockerfile thân thiện với bộ đệm

Hình minh họa sau đây tóm tắt thứ tự lớp thân thiện với bộ đệm:

Bản dựng Docker hoạt động thông qua các lớp. Khi một lệnh và các đầu vào có liên quan của nó khớp với bản dựng trước đó, Docker có thể sử dụng lại kết quả được lưu trong bộ nhớ đệm. Khi chúng không khớp, lớp đó và các lớp sau có thể cần phải chạy lại. Tài liệu vô hiệu hóa bộ nhớ đệm của Docker trình bày chi tiết hơn về các quy tắc.

Dockerfile có bộ đệm thù địch thường trông như thế này:

FROM node:22

WORKDIR /app

COPY . .

RUN npm ci

RUN npm run build

CMD ["npm", "start"]

Vấn đề là SAO CHÉP . . dòng. Bất kỳ thay đổi nguồn ứng dụng nào cũng có thể làm mất hiệu lực bước tiếp theo, bao gồm cả npm ci, ngay cả khi các phần phụ thuộc không thay đổi.

Phiên bản thân thiện với bộ đệm hơn sẽ tách các bảng kê khai phụ thuộc khỏi nguồn ứng dụng:

FROM node:22

WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci

COPY . .
RUN npm run build

CMD ["npm", "start"]

Khái niệm tương tự áp dụng cho Python, Java, Go và nhiều hình ảnh nền tảng dữ liệu. Sao chép tập tin phụ thuộc đầu tiên. Cài đặt phụ thuộc. Sau đó sao chép các tập tin nguồn thường xuyên thay đổi.

Đối với Python, một mẫu đơn giản có thể trông như thế này:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

COPY src/ ./src/

CMD ["python", "-m", "src.main"]

Đây không phải là câu trả lời cuối cùng cho mọi dịch vụ Python. Một số nhóm cần các gói được biên dịch, chỉ mục riêng, thư viện hệ thống hoặc tệp khóa có thể tái tạo. Vấn đề nằm ở cấu trúc: đầu vào ổn định trước đầu vào dễ biến động.

Số lớp vẫn còn quan trọng, nhưng nó không phải là mục tiêu duy nhất. Việc kết hợp mọi lệnh thành một câu lệnh RUN dài có thể khiến Dockerfile khó xem lại hơn và có thể làm giảm ranh giới bộ đệm hữu ích. Một Dockerfile có thể đọc được với các lớp có chủ ý thường tốt hơn một tệp nén mà không ai muốn duy trì.

Sử dụng các bản dựng nhiều giai đoạn với ranh giới thời gian chạy rõ ràng

Bản dựng nhiều giai đoạn cho phép bạn sử dụng một giai đoạn để biên dịch, đóng gói hoặc chuẩn bị các thành phần lạ, sau đó chỉ sao chép đầu ra được yêu cầu vào hình ảnh thời gian chạy cuối cùng. Docker ghi lại mẫu này trong hướng dẫn xây dựng nhiều giai đoạn.

Sử dụng các bản dựng nhiều giai đoạn khi không cần phụ thuộc vào thời gian xây dựng trong thời gian chạy. Ví dụ bao gồm trình biên dịch, công cụ kiểm tra, gói phát triển, công cụ xây dựng giao diện người dùng và tài sản tạm thời.

Một ví dụ đơn giản:

FROM node:22 AS build

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci

COPY . .
RUN npm run build

FROM node:22-slim AS runtime

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev

COPY --from=build /app/dist ./dist

CMD ["node", "dist/server.js"]

Mẫu này có thể giảm kích thước hình ảnh cuối cùng và giữ cho hình ảnh thời gian chạy sạch hơn. Nó cũng có thể làm cho quá trình xây dựng trở nên dễ dàng hơn vì mỗi giai đoạn đều có một công việc.

Nhưng các bản dựng nhiều giai đoạn không tự động tốt hơn. Nếu Dockerfile trở thành một mê cung của các thư mục được sao chép, các giả định ẩn và các lượt cài đặt phụ thuộc lặp đi lặp lại thì gánh nặng xem xét sẽ tăng lên. Nhóm có thể tiết kiệm thời gian trong một bước xây dựng và mất thời gian mỗi khi ai đó phải gỡ lỗi hình ảnh.

Một quy tắc thực tế: sử dụng các bản dựng nhiều giai đoạn khi chúng loại bỏ các phần phụ thuộc chỉ dành cho bản dựng khỏi hình ảnh cuối cùng hoặc làm cho vòng đời bản dựng rõ ràng hơn. Đừng thêm chúng chỉ vì chúng trông cao cấp.

Kiểm soát bối cảnh bản dựng, hình ảnh cơ sở và phần phụ thuộc

Bối cảnh xây dựng là tập hợp các tệp được gửi đến trình tạo. Nếu bối cảnh bao gồm bộ đệm cục bộ, tạo phẩm kiểm tra, sổ ghi chép, xuất dữ liệu, ảnh chụp màn hình hoặc tệp được tạo lớn, thì các bản dựng có thể bị chậm lại trước khi Docker đạt đến các bước phụ thuộc của bạn.

Sử dụng .dockerignore để loại trừ các tệp không có trong hình ảnh. Tài liệu của Docker về ngữ cảnh xây dựng và .dockerignore giải thích mức độ ảnh hưởng của các tệp bị bỏ qua đến nội dung được gửi đến trình tạo.

Một .dockerignore thực tế có thể bao gồm:

node_modules
__pycache__.pytest_cache
.env
dist
build
coverage
*.log
data/raw

Hãy xem xét điều này một cách cẩn thận. Đừng bỏ qua các tập tin mà bản dựng thực sự cần. Đối với các nhóm dữ liệu và AI, đây là rủi ro phổ biến khi các tập dữ liệu cục bộ, các tính năng được tạo, kết quả đánh giá hoặc các tạo phẩm mô hình nằm gần mã ứng dụng.

Lựa chọn hình ảnh cơ bản cũng có vấn đề. Hình ảnh tối thiểu có thể làm giảm kích thước tải xuống và dung lượng hình ảnh cuối cùng nhưng chúng có thể ảnh hưởng đến khả năng tương thích và gỡ lỗi. Hình ảnh cơ sở rất nhỏ có thể hữu ích cho dịch vụ thời gian chạy hẹp. Hình ảnh cơ sở tiêu chuẩn có thể tốt hơn khi nhóm của bạn cần chẩn đoán quen thuộc, công cụ shell hoặc khả năng tương thích gói.

Sự phụ thuộc cần có kỷ luật tương tự. Chỉ cài đặt những gì thời gian chạy cần. Làm sạch bộ đệm của trình quản lý gói khi không cần thiết. Ghim các phiên bản nơi khả năng tái tạo rất quan trọng. Tách biệt các phần phụ thuộc phát triển khỏi các phần phụ thuộc sản xuất nơi hệ sinh thái hỗ trợ nó.

Đây là nơi tối ưu hóa Docker trở thành một chủ đề kỹ thuật sản xuất chứ không phải là nhiệm vụ chỉ dành cho Dockerfile. Hình ảnh vẫn phải hỗ trợ giám sát, gỡ lỗi khẩn cấp và khôi phục. Hình ảnh nhỏ hơn khiến người vận hành bị mù khi xảy ra sự cố không phải là một cải tiến.

Quy trình làm việc CI/CD cho nhóm sản xuất

CI/CD thay đổi vấn đề tối ưu hóa vì tính khả dụng của bộ đệm tùy theo nền tảng. Máy cục bộ có thể sử dụng lại các lớp trong nhiều tuần. Người chạy CI có thể bắt đầu từ một môi trường trống. Trình chạy tự lưu trữ có thể giữ bộ nhớ đệm nhưng đưa ra các trách nhiệm bảo mật và bảo trì khác nhau.

Sử dụng quy trình công việc này:

1. Ghi lại đường cơ sở từ nhật ký CI và bản dựng cục bộ.
2. Xác định các bước Dockerfile chậm nhất.
3. Xem lại kích thước bối cảnh bản dựng và .dockerignore.
4. Sắp xếp lại các lớp xung quanh đầu vào phụ thuộc ổn định.
5. Đánh giá xem liệu các bản dựng nhiều giai đoạn có làm rõ sự tách biệt giữa bản dựng và thời gian chạy hay không.
6. Định cấu hình bộ đệm CI theo phương pháp được hỗ trợ trên nền tảng của bạn.
7. Chạy thử nghiệm thời gian chạy từ hình ảnh được tạo.
8. So sánh kết quả cục bộ và CI/CD.
9. Ghi lại sự thay đổi và hoạt động dự kiến của bộ nhớ đệm.

Đối với các dịch vụ AI, hãy thêm một đánh giá nữa: xác nhận rằng tối ưu hóa hình ảnh không ẩn các thay đổi đối với lời nhắc, tập dữ liệu đánh giá, cấu hình định tuyến mô hình hoặc kiểm soát ngân sách mã thông báo. Hình ảnh Docker có thể xây dựng nhanh hơn nhưng bản phát hành của bạn vẫn cần các cổng đánh giá và xem xét nếu nó thay đổi hành vi của tác nhân. Công việc Phát triển tác nhân AI của chúng tôi coi các tác nhân có thể triển khai như hệ thống sản xuất chứ không chỉ là các gói mã.

Một quy trình CI cũng sẽ giúp khắc phục các lỗi có thể xảy ra. Nếu cấu hình bộ đệm bị hỏng, quá trình xây dựng vẫn sẽ hoàn tất từ ​​trạng thái nguội. Nếu máy nhân bản phụ thuộc bị lỗi, nhật ký sẽ hiển thị nguyên nhân. Nếu hình ảnh thời gian chạy thiếu thư viện bắt buộc, các thử nghiệm khói sẽ phát hiện ra nó trước khi triển khai.

Khi Nhóm Dữ liệu Van thực hiện loại đánh giá quy trình làm việc này, các sản phẩm cung cấp sẽ cụ thể: bản đồ tín hiệu từng bước xây dựng, ghi chú đánh giá Dockerfile, đánh giá khoảng trống bộ đệm CI/CD, danh sách kiểm tra rủi ro triển khai và phạm vi triển khai gắn liền với dịch vụ hoặc nền tảng dữ liệu của bạn. Các nhóm có thể xem xét các tùy chọn tương tác khi họ cần chạy nước rút tập trung thay vì xây dựng lại nền tảng rộng.

Bảng quyết định: Sử dụng chiến thuật nào

Bảng này không phải là danh sách kiểm tra các thay đổi bắt buộc. Đó là một hướng dẫn lựa chọn. Việc tối ưu hóa phù hợp tùy thuộc vào ràng buộc nào đang thực sự gây tổn hại cho nhóm: độ trễ của nhà phát triển, chi phí CI, độ trễ triển khai, truyền hình ảnh, độ tin cậy trong thời gian chạy hoặc gánh nặng đánh giá.

Các chế độ lỗi và cổng đánh giá

Bản dựng Docker nhanh nhất không phải lúc nào cũng là bản dựng tốt nhất. Đội sản xuất cần có lan can.

Những lỗi thường gặp bao gồm:

• Tối ưu hóa kích thước hình ảnh mà không cần đo thời lượng xây dựng.
• Sắp xếp lại các lớp theo cách vô hiệu hóa bộ đệm thường xuyên hơn.
• Cài đặt các gói không cần thiết vì chúng hữu ích một lần trong quá trình gỡ lỗi.
• Loại bỏ các công cụ vận hành mà hỗ trợ sản xuất vẫn cần.
• Coi một bản dựng cục bộ ấm áp là bằng chứng cho thấy CI/CD đã được cải thiện.
• Thêm các bản dựng nhiều giai đoạn mà chỉ tác giả gốc mới hiểu được.
• Lặp lại các tuyên bố về điểm chuẩn từ các nhóm khác mà không phù hợp với bối cảnh của họ.
• Bỏ qua các bài kiểm tra thời gian chạy sau khi thay đổi Dockerfile.

Một cổng đánh giá tốt sẽ đặt ra bốn câu hỏi:

1. Quá trình xây dựng có nhanh hơn trong các điều kiện tương đương không?
2. Hình ảnh cuối cùng vẫn chạy cùng một khối lượng công việc phải không?
3. Sự thay đổi có bảo tồn khả năng tái tạo và trạng thái bảo mật không?
4. Nhóm có ghi lại những gì cần duy trì ổn định trong bộ nhớ đệm không?

Dưới đây là danh sách kiểm tra đánh giá thực tế:

Docker build optimization review

[ ] Baseline local build captured
[ ] Baseline CI/CD build captured
[ ] Slowest build steps identified
[ ] Build context reviewed
[ ] .dockerignore checked from a clean checkout
[ ] Dependency layer order reviewed
[ ] Base image choice justified
[ ] Multi-stage build used only where helpful
[ ] Runtime smoke test passed
[ ] CI cache behavior verified
[ ] Image size tracked separately from build time
[ ] Rollback path remains clear
[ ] Notes added for future maintainers

Đối với những người sáng lập và điều hành, điểm quan trọng hơn là khả năng dự đoán. Việc xây dựng chậm gây khó chịu. Các bản dựng không thể đoán trước là rủi ro hoạt động.

Một nhóm triển khai các công việc hàng loạt có thể chấp nhận việc xây dựng chậm hơn nếu việc xây dựng đó hiếm khi xảy ra và đáng tin cậy. Nhóm gửi các bản sửa lỗi thường xuyên cho các API hướng tới khách hàng có thể cần phản hồi nhanh hơn. Nhóm triển khai quy trình làm việc của tổng đài viên có thể cần thời gian đánh giá dành riêng cho lộ trình phát hành, vì chỉ riêng tốc độ xây dựng không chứng minh được rằng tổng đài viên an toàn để phát hành.

Ví dụ thực tế

Hãy xem xét một dịch vụ đường dẫn dữ liệu thường xuyên thay đổi mã chuyển đổi nhưng hiếm khi cập nhật các phần phụ thuộc. Dockerfile đầu tiên sao chép toàn bộ repo, cài đặt các gói Python và sau đó chạy thử nghiệm. Mỗi lần chỉnh sửa mã sẽ kích hoạt cài đặt phụ thuộc. Cách khắc phục là sao chép tệp khóa hoặc tệp yêu cầu trước, cài đặt các phần phụ thuộc, sau đó sao chép mã nguồn. Đầu ra không phải là một bản viết lại anh hùng. Đó là Dockerfile phù hợp với mô hình thay đổi thực sự của nhóm.

Bây giờ hãy xem xét dịch vụ báo cáo ngoại vi bên trong nền tảng phân tích nội bộ. Giai đoạn xây dựng cần có công cụ Node và bộ đóng gói. Thời gian chạy chỉ cần nội dung được biên dịch và máy chủ. Quá trình xây dựng nhiều giai đoạn có thể tách biệt những mối lo ngại đó, giảm những gì được đưa vào sản xuất và làm rõ những phần phụ thuộc nào thuộc về thời gian chạy.

Ví dụ thứ ba là bộ chạy CI/CD luôn khởi động nguội. Dockerfile có thể đã được cấu trúc tốt nhưng quy trình sẽ loại bỏ bộ đệm giữa các công việc. Trong trường hợp đó, Dockerfile không phải là cách khắc phục duy nhất. Nhóm cần xem lại cấu hình bộ đệm CI, hành vi của trình chạy, hành vi kéo hình ảnh cơ sở và chính sách lưu trữ giả.

Các ví dụ này có chung một mô hình: đo lường nút thắt cổ chai, thay đổi yếu tố hẹp nhất để giải quyết nút cổ chai đó, sau đó xác thực trong môi trường mà độ trễ thực sự gây tổn hại.

Đối với các nhóm xây dựng nền tảng sản xuất, thời gian xây dựng Docker phải là một phần của cuộc trò chuyện về độ tin cậy giống như khả năng quan sát, chất lượng dữ liệu, khôi phục triển khai và tự động hóa quy trình làm việc. Đó là lý do tại sao các dịch vụ kỹ thuật dữ liệu và AI của chúng tôi thường bao gồm việc đánh giá quy trình phân phối cùng với quá trình triển khai quy trình hoặc ứng dụng.

Kết luận

Tối ưu hóa thời gian xây dựng hình ảnh Docker là một quy trình sản xuất chứ không phải thủ thuật Dockerfile một dòng. Con đường đáng tin cậy là đo lường bản dựng hiện tại, xác định các bước chậm, các lớp cấu trúc xung quanh việc tái sử dụng bộ đệm, giảm sự phụ thuộc không cần thiết, sử dụng các bản dựng nhiều giai đoạn để làm rõ ranh giới thời gian chạy và xác thực kết quả trong CI/CD.

Các nhóm tốt nhất cùng nhau tối ưu hóa tốc độ và độ tin cậy. Họ không loại bỏ hỗ trợ vận hành chỉ để làm cho hình ảnh nhỏ hơn. Họ không tin tưởng vào việc xây dựng cục bộ ấm áp là bằng chứng cho thấy việc triển khai đã được cải thiện. Họ ghi lại hành vi bộ đệm dự định để các chỉnh sửa trong tương lai duy trì mức tăng.

Nếu các bản dựng Docker đang làm chậm quá trình phát hành nền tảng dữ liệu, triển khai dịch vụ AI hoặc phản hồi sự cố sản xuất, thì Van Data Team có thể biến vấn đề thành một kế hoạch triển khai: bản đồ tín hiệu từng bước xây dựng, đánh giá bộ đệm CI/CD, đề xuất Dockerfile, danh sách kiểm tra xác thực thời gian chạy và đường dẫn phân phối trong phạm vi thông qua thực hành kỹ thuật do người sáng lập chỉ đạo của chúng tôi.