Đối thoại cùng CTO của Amazon: Những câu chuyện, thông tin chi tiết và bí mật từ bên trong gã khổng lồ Amazon
Tuyển chọn TechFlowTuyển chọn TechFlow
Đối thoại cùng CTO của Amazon: Những câu chuyện, thông tin chi tiết và bí mật từ bên trong gã khổng lồ Amazon
Nếu bạn muốn trở thành một công ty phát triển nhanh, bạn không thể làm theo cách của doanh nghiệp truyền thống.
Chuyên sâu báo cáo Web3Biên dịch: TechFlow
Ghi chú: Bài viết này thuộc chuyên đề "Ghi chú khóa học khởi nghiệp YC" của TechFlow (cập nhật hàng ngày, đây là bài cuối cùng trong chuỗi). Mục tiêu của chuyên đề là sưu tầm và hệ thống hóa các phiên bản tiếng Trung của khóa học YC. Bài thứ 25 là khóa học trực tuyến của Werner Vogels, CTO Amazon, mang tên "Kinh nghiệm và góc nhìn về công nghệ và các công ty khởi nghiệp".
Trước khi gia nhập Amazon
Trước khi gia nhập Amazon, tôi là một học giả, đã dành mười năm nghiên cứu khoa học tại Đại học Cornell và xây dựng các hệ thống phân tán quy mô lớn. Trước đó, tôi không phải là một nhà khoa học máy tính điển hình. Tôi mới thực sự quyết định quay lại trường học để học sâu hơn khi đã 28 tuổi. Trước đó, tôi làm việc tại bệnh viện, cung cấp xạ trị cho bệnh nhân ung thư tại Viện Nghiên cứu Ung thư Hà Lan. Một ngày nọ, tôi đột nhiên nhận ra rằng mình không thể chịu đựng được việc chứng kiến từng người qua đời xung quanh mình, vì vậy tôi quyết định làm điều gì đó hoàn toàn khác biệt. Khoa học máy tính dường như là một lựa chọn tuyệt vời.
Lúc đó là giữa những năm 80, khoa học máy tính chưa phổ biến như hiện nay. Tuy nhiên, hóa ra tôi có một năng khiếu, dù lúc đó tôi chưa biết. Tôi bắt đầu đắm mình vào lĩnh vực này vì nó chính xác là điều tôi thực sự quan tâm. Tôi lấy bằng tiến sĩ, làm việc vài năm tại một viện nghiên cứu ở Bồ Đào Nha, sau đó được mời gia nhập Đại học Cornell.
Trong thời gian làm việc tại Cornell, ngoài nghiên cứu, tôi thường xuyên tư vấn cho các tập đoàn lớn như HP và một số công ty khác mà tôi không nhớ rõ tên, đồng thời tham gia nhiều hội nghị. Một lần, Amazon mời tôi trình bày về một số nội dung đang nghiên cứu. Ban đầu tôi cảm thấy hơi bất ngờ và bối rối: Thật sao? Tôi cần làm điều này à?
Lúc đó, duyệt web và cơ sở dữ liệu là những vấn đề nan giải đến mức nào? Tuy nhiên, khi bắt tay vào, tôi mới nhận ra đây thực sự là một thách thức kỹ thuật khổng lồ. Amazon không chỉ đơn thuần là một nhà bán lẻ, mà là một công ty công nghệ với quy mô vận hành lớn nhất mà tôi từng thấy, vượt xa so với bất kỳ công ty nào tôi từng tư vấn trước đó. Xét từ góc độ nghiên cứu hệ thống phân tán, những thách thức họ đối mặt thật đáng kinh ngạc.
Khi Amazon đưa ra lời mời làm việc, tôi đã chấp nhận ngay lập tức.
Quy mô vận hành và dẫn đầu công nghệ tại Amazon
Tôi cho rằng phần lớn các nhà nghiên cứu hệ thống phân tán đã nhận ra rằng các công ty lớn này cần vận hành ở quy mô nào, thậm chí không chỉ giới hạn ở các công ty lớn. Dù là công ty internet hay công ty số, muốn thành công đều cần vận hành ở quy mô khổng lồ.
Nhìn lại năm 2004, khi tôi gia nhập Amazon, nhiều người có thể thấy quy mô hoạt động của Amazon lúc đó tương đối dễ dàng. Nhưng điều đó không có nghĩa là bạn có thể dựa vào một vị trí hay hạ tầng thiết yếu nào đó. Vì vậy, rất nhiều công việc đã được thực hiện trong lĩnh vực điện toán đám mây và các công nghệ khác để đảm bảo tận dụng tối đa lợi thế mà chúng mang lại.
Năm 2004, Amazon chỉ đạt được quy mô nhất định thông qua thực tiễn, chứ không có sách vở hay hướng dẫn nào nói rõ cách xây dựng tổ chức hay doanh nghiệp có thể mở rộng. Do đó, tôi cho rằng Amazon đi đầu trong ứng dụng công nghệ, phát triển công nghệ và quy mô vận hành, dẫn trước 5 đến 10 năm. Điều này đặc biệt quan trọng đối với các công ty theo đuổi tăng trưởng nhanh.
Nếu bạn muốn trở thành một công ty phát triển nhanh, bạn không thể làm như các doanh nghiệp truyền thống. Các doanh nghiệp truyền thống thường rơi vào nghịch lý của người tiên phong, một khi điều gì đó thành công sẽ trở nên chậm chạp.
Việc xây dựng một công ty phát triển nhanh liên tục là một câu chuyện hoàn toàn khác, bạn phải cân nhắc kỹ lưỡng hoạt động kinh doanh. Ví dụ, liệu có nên tạo ra nợ công nghệ hay chấp nhận một số việc lặp lại, điều này là không thể trong doanh nghiệp truyền thống vì hiệu quả là mục tiêu chính.
Tại Amazon, tốc độ nhanh, đổi mới nhanh và có ống dẫn thử nghiệm dài hạn là điều quan trọng nhất. Vì vậy, bạn sẵn sàng chấp nhận một số việc lặp lại, cho phép phát sinh một chút nợ công nghệ, miễn là bạn biết phải trả nó.
Do đó, trong các cuốn sách MBA truyền thống khó tìm thấy những sự đánh đổi mà Amazon sẵn sàng thực hiện. Hầu hết, Amazon phải tự phát triển công nghệ, quy trình và quy trình kinh doanh của riêng mình. Tất nhiên, có Jeff Bezos - một nhà lãnh đạo có tầm nhìn, người thực sự hiểu hình dạng tương lai và thế giới hiện đại nên như thế nào.
Chìa khóa để đạt tăng trưởng
Mặc dù Amazon đã đạt được thành công lớn về quy mô, chúng tôi vẫn đối mặt với thách thức trong việc đạt được tăng trưởng lớn hơn. Để bước sang giai đoạn tăng trưởng tiếp theo, chúng tôi cần suy nghĩ và hành động nghiêm ngặt hơn.
Một ví dụ là về hiệu suất. Làm thế nào để đo lường hiệu suất? Chúng ta cần hạ tầng nào để đo lường? Để trở thành một công ty thực sự dựa trên dữ liệu, đưa ra quyết định dựa trên dữ liệu, trước tiên cần có dữ liệu và xây dựng một văn hóa xung quanh cách đánh giá và diễn giải các dữ liệu đo lường này.
Ngay cả khi thời gian tải trang chậm hơn 1,2 giây cũng sẽ ảnh hưởng tiêu cực đến trải nghiệm khách hàng. Chỉ riêng điều này đã cho thấy 50% trải nghiệm khách hàng tệ đi, bạn cần hiểu tình hình tồi tệ đến mức nào. Về mặt kỹ thuật, các yếu tố kiểm soát như 99% hay 99,9% ngày càng trở nên quan trọng. Sau đó, bạn cần xây dựng một cơ chế có thể thực sự nắm vững ngành kỹ thuật 99%, và liên kết nó với các quyết định kinh doanh.
Tôi cho rằng năm 2004, độ tin cậy của chúng tôi khá cao. Có một số quy tắc ràng buộc chúng tôi, ví dụ như chúng tôi phải sử dụng trung tâm dữ liệu ở khu vực cụ thể (SEA). Bất kể bạn làm gì với trung tâm dữ liệu SEA này, bạn đều cần sao chép sang các trung tâm dữ liệu khác, để nếu một trung tâm dữ liệu gặp sự cố, khách hàng sẽ không bị ảnh hưởng.
Mặc dù khách hàng có thể bị ảnh hưởng về độ trễ, nhưng chức năng sẽ không bị ảnh hưởng. Chúng tôi rất giỏi xử lý tất cả các quy tắc này, cho đến một ngày chúng tôi quyết định ngắt kết nối một trung tâm dữ liệu để xem điều gì xảy ra. Chỉ cần điều chỉnh mạng một chút là có thể tách một trung tâm dữ liệu khỏi các trung tâm khác.
Tuy nhiên, thực tế thì tất cả những thứ trông tốt trên giấy tờ này trong thực tiễn không suôn sẻ như người ta tưởng tượng. Mặc dù lần đầu thử nghiệm còn nhiều thủ công, ví dụ chuyển đổi cơ sở dữ liệu thủ công, suốt năm đó chúng tôi luôn luyện tập. Khi bạn thực hiện lần thứ ba hoặc thứ tư, bạn thực tế đã đạt đến mức gần như có thể tự động hóa hoàn toàn mà không cần can thiệp con người. Điều này cực kỳ quan trọng để đảm bảo tính sẵn sàng cao và khả năng chịu lỗi của hệ thống.
Trong nỗ lực của chúng tôi, chúng tôi cũng chú trọng phát triển phân tích dữ liệu và nhận thức. Amazon sở hữu lượng dữ liệu khổng lồ, nhưng việc rút ra thông tin có giá trị từ đó là một thách thức. Chúng tôi cam kết xây dựng các công cụ và mô hình phân tích dữ liệu mạnh mẽ để giúp hiểu hành vi khách hàng, xu hướng thị trường và cơ hội kinh doanh. Phương pháp dựa trên dữ liệu này giúp chúng tôi ra quyết định tốt hơn và cung cấp sản phẩm, dịch vụ cá nhân hóa.
Ngoài ra, chúng tôi còn nỗ lực cải thiện trải nghiệm người dùng. Chúng tôi nghiên cứu sâu nhu cầu và sở thích của người dùng trong quá trình mua sắm, nâng cao trải nghiệm thông qua tối ưu thiết kế, cải tiến giao diện và đề xuất cá nhân hóa. Chúng tôi theo đuổi trải nghiệm mua sắm đơn giản, trực quan và liền mạch để đáp ứng kỳ vọng khách hàng và giành lấy lòng trung thành của họ.
Sự thay đổi vai trò CTO
Sau khi trở thành nhà cung cấp công nghệ, vai trò CTO sẽ thay đổi.
Tôi đã đề cập vấn đề này trong một bài blog. Theo tôi, CTO có bốn loại trách nhiệm khác nhau:
- Thứ nhất là CTO cấp doanh nghiệp, thường phụ trách quản lý hạ tầng, báo cáo với CIO và chịu trách nhiệm quản lý lượng lớn hạ tầng.
- Loại thứ hai là CTO kiểu đồng sáng lập kỹ thuật, phổ biến ở các doanh nghiệp trẻ, có tầm nhìn công nghệ. Nhưng tôi nghĩ vai trò này tiềm ẩn rủi ro nhất định, vì rất nhiều việc khác như quản lý đội ngũ kỹ sư... cũng bị đưa vào phạm vi trách nhiệm của vai trò này. CTO có thể không nhất thiết giỏi xử lý những việc này, chúng ta sẽ thảo luận chi tiết sau.
- Loại thứ ba là CTO kiểu "nhà tư tưởng lớn", thúc đẩy đổi mới phát triển. Ví dụ như các công ty AT&T và Lucent, họ có CTO hoặc văn phòng CTO, chuyên nghiên cứu và thử nghiệm công nghệ thế hệ tiếp theo.
- Loại cuối cùng là CTO chuyên gia kỹ thuật hướng ngoại, khi làm nhà cung cấp công nghệ cho công ty khác, họ phụ trách tương tác kỹ thuật sâu sắc với khách hàng, hiểu cách khách hàng sử dụng sản phẩm, tìm kiếm các mẫu hình sâu hơn, rộng hơn và các điểm đau của khách hàng. Vai trò này không chỉ tập trung vào công nghệ mà còn chú trọng hơn vào tổng thể.
Cần lưu ý rằng các vai trò này ngày càng lấy khách hàng làm trung tâm, chứ không chỉ tập trung vào công nghệ. Quan trọng là đưa phản hồi của khách hàng về công ty, suy nghĩ cần phát triển chức năng hay sản phẩm mới nào, hoặc cần thay đổi quy trình nào để phục vụ khách hàng tốt hơn.
Vì vậy, vai trò CTO của nhà cung cấp công nghệ mang tính định hướng khách hàng mạnh hơn, chứ không chỉ tập trung vào công nghệ.
Văn hóa đặc thù của Amazon
Vì Amazon là công việc thực sự đầu tiên của tôi, tôi từng nghĩ lâu rằng văn hóa làm việc ở nơi khác cũng giống Amazon, nhưng thực tế không phải vậy.
Amazon có một văn hóa độc đáo, rất hiệu quả với các công ty phát triển nhanh. Họ khuyến khích các nhóm độc lập tối đa, cắt giảm cấp bậc và cấu trúc tổ chức. Hệ thống đẳng cấp trong mắt họ là phi tự nhiên.
Họ muốn có các nhóm tự tổ chức, thuê những người thực sự muốn làm việc độc lập, sở hữu sản phẩm. Các doanh nghiệp trẻ đặc biệt cần điều này, chứ không phải người đi theo hay lập trình viên.
Amazon có bộ nguyên tắc lãnh đạo gồm 14 nguyên tắc như kiên định vì khách hàng, tinh thần chủ sở hữu, đào sâu... thúc đẩy sự phát triển văn hóa.
Tại Amazon, phỏng vấn tuyển dụng chủ yếu xoay quanh sự phù hợp về văn hóa, vì một nhân viên không hòa hợp với môi trường văn hóa sẽ gây xáo trộn lớn cho nhóm nhỏ. Amazon rất đề cao nhóm nhỏ, thường từ 10 đến 12 người, mỗi thành viên đều rõ nhiệm vụ của mình.
Khi doanh nghiệp phát triển, vai trò CTO cũng thay đổi, từ ban đầu phụ trách mọi việc liên quan công nghệ, dần chuyển sang tập trung vào quản lý nhóm và đảm bảo kỹ sư có thể cung cấp công nghệ và sản phẩm cần thiết.
So với Phó giám đốc kỹ thuật, CTO chú trọng hơn vào khía cạnh kỹ thuật như xây dựng công nghệ đúng đắn, sử dụng công cụ phù hợp...
Amazon phát triển như thế nào?
Bên trong Amazon trải qua một loạt thay đổi. Họ tạo ra các nhóm độc lập, trông giống các công ty khởi nghiệp, nắm giữ mục tiêu và chương trình đổi mới riêng. Tuy nhiên trước đây, để phát triển nhanh, Amazon vi phạm các nguyên tắc kiến trúc, dẫn đến hạ tầng cơ sở dữ liệu phía sau yếu ớt và không thể mở rộng thêm.
Để giải quyết vấn đề hiệu suất giảm, họ chuyển sang kiến trúc hướng dịch vụ, chia hệ thống thành các khối chức năng độc lập, tức microservice.
Tuy nhiên, khi số nhóm tăng lên, mỗi dịch vụ cần quản lý cơ sở dữ liệu riêng, dẫn đến giao tiếp tăng nhưng đổi mới giảm.
Để cải thiện tình hình, họ tạo ra nền tảng dịch vụ chia sẻ, sử dụng công nghệ ảo hóa và API để quản lý máy chủ. Họ xây dựng các công nghệ này trước trong nội bộ, rồi sau đó tung sản phẩm ra bên ngoài như Amazon S3 và EC2, các dịch vụ này khiến khả năng lưu trữ và tính toán trở nên lập trình được và mở rộng, rất hiệu quả về chi phí cho doanh nghiệp.
Mục tiêu của Amazon là đạt được khả năng lưu trữ và tính toán quy mô internet, phục vụ mọi loại hình doanh nghiệp.
Con đường đổi mới
Đổi mới tại Amazon được chia thành hai cấp độ:
- Thứ nhất là đổi mới cấp nhóm, mỗi nhóm chịu trách nhiệm xây dựng kế hoạch đổi mới cho năm tới, hoàn thành nhiệm vụ độc lập, ví dụ cải tiến động cơ đề xuất để giảm số lượng trả hàng. Họ chịu trách nhiệm vẽ lộ trình, lấy nguồn dữ liệu mới và tương tác với khách hàng theo cách khác.
- Cấp độ khác là đổi mới đòi hỏi đầu tư vốn lớn, như Kindle và Amazon Prime. Những dự án này cần hỗ trợ tài chính lớn. Amazon đặt ra một quy tắc: chỉ khi một dự án đổi mới có khả năng thành công và ảnh hưởng lớn đến bảng cân đối kế toán công ty thì mới tiến hành đầu tư vốn quy mô lớn.
Amazon nhận ra một số quyết định đưa ra trong giai đoạn đầu phát triển công nghệ rất sáng suốt, khi quy mô mở rộng, họ phải xem xét lại kiến trúc và phát triển phần mềm thích nghi với thay đổi. Điều này liên quan đến việc sử dụng nhiều kiến trúc và phiên bản để xử lý các thách thức kỹ thuật như động cơ lưu trữ.
Ngoài ra, giống các công ty khác, Amazon cũng nhận thấy ngoài mở rộng kỹ thuật, cần giải quyết các yếu tố không liên quan kỹ thuật như bán hàng, kiến trúc giải pháp, quản lý kỹ thuật khách hàng và hỗ trợ khách hàng. Tất cả những yếu tố này đều cần thiết để xây dựng một công ty thành công.
Làm thế nào để ra mắt dịch vụ mới?
Chúng tôi mong muốn tất cả các nhóm đều gắn bó chặt chẽ với khách hàng, vì khoảng 95% chức năng và dịch vụ chúng tôi cung cấp nhằm đáp ứng nhu cầu trực tiếp của khách hàng. Ban đầu, các dịch vụ sớm nhất chúng tôi xây dựng gần như đáp ứng mọi kỳ vọng của khách hàng, bao gồm hạ tầng IT cơ bản, lưu trữ, tính toán, cơ sở dữ liệu, mạng và bảo mật.
Tuy nhiên, theo thời gian, khách hàng đưa ra nhiều nhu cầu khác. Họ cần chức năng phân tích, công nghệ đám mây, phát triển di động và hiện nay là blockchain cùng các công nghệ khác, họ muốn có thể sử dụng các công nghệ này mà không cần quản lý chúng. Vì vậy, việc hỗ trợ khách hàng xây dựng đặc tính và công cụ đúng đắn trở nên rất quan trọng.
Khi ra mắt sản phẩm và dịch vụ mới, chúng tôi tuân theo một văn hóa mạnh mẽ: ra mắt với tập hợp chức năng tối thiểu (MVP). Nhưng đây chỉ là điểm khởi đầu để xây dựng công nghệ cần thiết cho kinh doanh. Chúng tôi không thể chỉ phát hành một thứ gì đó sơ sài, mà cần đảm bảo tính ổn định và đáng tin cậy. Sau đó, chúng tôi thảo luận với khách hàng về nhu cầu các chức năng khác.
Ở giai đoạn ban đầu của sản phẩm, chúng tôi không phải lúc nào cũng biết khách hàng cần chức năng gì khác. Ví dụ, khi ra mắt DynamoDB, chúng tôi không biết khách hàng muốn chỉ mục phụ. Chúng tôi không cung cấp ngay từ đầu, nhưng rõ ràng đây là điều khách hàng muốn. Chúng tôi bắt đầu dịch vụ với tập hợp chức năng tối thiểu để quan sát cách khách hàng sử dụng sản phẩm, sau đó từng bước lặp lại và thêm chức năng, dịch vụ mới.
Ví dụ, khi ra mắt Lambda, nó là môi trường không máy chủ, giúp việc phát triển đơn giản, chỉ cần viết mã và triển khai lên S3, không cần lo lắng về máy chủ hay các vấn đề khác. Bạn chỉ trả tiền cho phần thực tế sử dụng, không cần lo lắng về thời gian chờ.
Cách làm này thay đổi quá trình phát triển, chúng tôi có thể quan sát cách khách hàng sử dụng sản phẩm. Họ nhanh chóng bắt đầu áp dụng phương pháp lặp kiểu môi trường gỡ lỗi X-ray và sử dụng chức năng bậc thang để xây dựng các ứng dụng phức tạp hơn. Chúng tôi quan sát thói quen sử dụng của khách hàng để hiểu nhu cầu của họ, ví dụ trong DynamoDB, chúng tôi nhận ra chỉ mục phụ quan trọng hơn trung tâm dữ liệu thứ cấp đối với khách hàng.
Cơ bản, khách hàng đã định nghĩa lại lộ trình của chúng tôi, chúng tôi bắt đầu cung cấp các chức năng quan trọng nhất đối với họ. Đây là phần rất quan trọng. Ngay cả khi trông giống MVP, chúng tôi cũng không thể coi đó là MVP, vì mọi người sẽ xây dựng kinh doanh dựa vào nó và phụ thuộc vào nó. Vì vậy, một cấu trúc văn hóa khác đã hình thành xung quanh sản phẩm.
Năm ngoái chúng tôi có 1.400 lần ra mắt chức năng và dịch vụ mới, con số này tất nhiên sẽ tiếp tục tăng khi số nhóm tăng lên. Chúng tôi sử dụng cấu trúc tương tự trong AWS, mỗi nhóm hợp tác với nhóm khách hàng cụ thể và xây dựng lộ trình theo nhu cầu của họ. Khi dịch vụ ngày càng nhiều, lộ trình cũng ngày càng nhiều.
Tuy nhiên, đây là môi trường tiến nhanh, cách xây dựng phần mềm đã thay đổi lớn. Nếu chúng tôi có thể quyết định khách hàng nên phát triển phần mềm như thế nào, có lẽ chúng tôi vẫn đang phát triển theo cách năm năm hay mười năm trước. Thay vào đó, chúng tôi cần hợp tác chặt chẽ với khách hàng, để họ điều khiển động cơ đổi mới của chúng tôi, phát triển phần mềm theo cách của năm 2020 hay 2025.
Vì vậy, chúng tôi không thể ra quyết định thay khách hàng, mà cần hợp tác chặt chẽ với họ, để họ điều khiển động cơ đổi mới của chúng tôi. Chúng tôi cần quan sát sát cách khách hàng sử dụng sản phẩm và liên tục lặp lại, cải tiến theo phản hồi của họ.
Tóm lại, Amazon Web Services (AWS) theo đuổi đổi mới ở hai cấp độ: cấp nhóm và đầu tư vốn. Thông qua hợp tác chặt chẽ với khách hàng, hiểu nhu cầu và quan sát thói quen sử dụng của họ, AWS có thể cung cấp chức năng và dịch vụ đáp ứng nhu cầu khách hàng. Đồng thời, AWS cũng đầu tư lớn vào nghiên cứu phát triển và ra mắt sản phẩm, dịch vụ, chức năng mới để đáp ứng nhu cầu thị trường luôn thay đổi.
Phương pháp đổi mới này giúp AWS duy trì mối liên hệ chặt chẽ với khách hàng, đảm bảo có thể cung cấp giải pháp ổn định, đáng tin cậy và phù hợp kỳ vọng khách hàng. Thông qua chiến lược ra mắt dựa trên tập hợp chức năng tối thiểu và cách làm lặp lại liên tục, AWS có thể nhanh chóng đáp ứng nhu cầu khách hàng và liên tục cung cấp thêm chức năng, dịch vụ tiên tiến.
Con đường đổi mới của Amazon là một quá trình liên tục tiến hóa và phát triển, luôn lấy khách hàng làm trung tâm. Thông qua việc thấu hiểu sâu sắc nhu cầu khách hàng, quan sát thói quen sử dụng và đầu tư liên tục vào nghiên cứu phát triển, AWS không ngừng thúc đẩy công nghệ và kinh doanh tiến lên, cung cấp giải pháp điện toán đám mây vượt trội cho khách hàng.
Xây dựng sản phẩm do khách hàng dẫn dắt
Chúng tôi hiện diện khắp nơi, dù bắt đầu từ khách hàng hay bên trong Amazon. Là một công ty công nghệ, chúng tôi rất chú trọng phát triển những thứ thực sự quan trọng với khách hàng. Dù là công ty công nghệ nặng, kỹ sư và thiết kế kỹ thuật cũng gánh rủi ro.
Chúng tôi chú trọng vào sản phẩm, chứ không chỉ là công nghệ. Chúng tôi muốn biết có thể làm gì cho khách hàng. Chúng tôi cam kết xây dựng công nghệ tuyệt vời, nhưng đây không phải động lực duy nhất. Chúng tôi quan tâm đến việc giải quyết vấn đề của khách hàng.
Để đảm bảo luôn chú trọng khách hàng, chúng tôi áp dụng một quy trình gọi là "làm ngược". Trước tiên, chúng tôi viết một bản thông cáo báo chí, mô tả rõ ràng, ngắn gọn thứ sắp xây dựng. Sau đó, chuẩn bị một tài liệu gồm 20 câu hỏi thường gặp, trả lời bằng ngôn ngữ đơn giản, dễ hiểu. Trong các trường hợp phức tạp hơn, chúng tôi có thể cần sửa đổi lại hai tài liệu này nhiều lần cho đến khi hoàn toàn rõ ràng về thứ sắp xây dựng.
Tiếp theo, chúng tôi viết tài liệu trải nghiệm người dùng (UX), mô tả chi tiết cách khách hàng sử dụng sản phẩm và tương tác với sản phẩm. Chúng tôi cũng viết tài liệu hướng dẫn người dùng, bảng thuật ngữ và các tài liệu liên quan khác.
Cuối cùng, chúng tôi có được bộ bốn tài liệu mô tả chính xác việc sắp làm.
Là Amazon, chúng tôi luôn tuân thủ nguyên tắc: hóa đơn của chúng tôi sẽ không vượt quá những gì hứa hẹn. Chúng tôi không tùy tiện thêm chức năng phiên bản hai vào phiên bản một. Chúng tôi tập trung xây dựng chức năng đã hứa và chỉ tập trung vào điều đó. Phương pháp này cung cấp cấu trúc mạnh mẽ, giúp suy nghĩ về nhu cầu khách hàng, trải nghiệm sản phẩm và các khía cạnh kỹ thuật.
Trong các cuộc họp Amazon, chúng tôi không dùng slide hay thuyết trình. Chúng tôi có một tài liệu gọi là "bản ghi nhớ sáu trang", mỗi người im lặng đọc trước 30 phút khi họp bắt đầu. Bản ghi nhớ này rất quan trọng vì đảm bảo mọi người đều hiểu rõ nội dung thảo luận.
Viết một câu chuyện là khó khăn, vì vậy chúng tôi khuyến khích hợp tác và phản hồi. Chúng tôi sửa đổi và hoàn thiện bản ghi nhớ này nhiều lần cho đến khi mô tả rõ ràng đặc tính, sản phẩm hay lĩnh vực kinh doanh. Sau 30 phút đọc, mọi người trong phòng họp đều "cùng trang sách", giúp cuộc thảo luận chất lượng cao.
Tóm lại, chúng tôi có văn hóa và quy trình độc đáo để đảm bảo luôn tập trung giải quyết vấn đề khách hàng và cung cấp sản phẩm, dịch vụ xuất sắc.
Công nghệ container
Ngày càng nhiều công ty bỏ qua công nghệ container, đặc biệt trong việc theo đuổi môi trường microservice hơn. Một trong những lý do công nghệ container trở nên phổ biến là khả năng dễ dàng mở rộng/thu hẹp các thành phần, phù hợp với triết lý microservice. Nhiều người bắt đầu tách container từ giai đoạn monolithic để phát triển, đặc biệt xung quanh môi trường không máy chủ.
Tuy nhiên, trước khi sử dụng công nghệ container tồn tại một số vấn đề, đặc biệt trước khi ra mắt Fargate. Bạn cần quản lý nhiều container chạy trên nhiều vùng khả dụng, và cần ánh xạ chúng vào máy ảo. Vì vậy, mặc dù container là lựa chọn phát triển tốt, vẫn cần đầu tư nhiều công sức để vận hành và quản lý các container này. Để đơn giản hóa quá trình này, chúng tôi cung cấp giải pháp có tên Fargate, về cơ bản hủy bỏ mọi quản lý máy ảo nền tảng, chỉ cần đưa container vào là có thể chạy.
Trong tương lai, tôi nghĩ sẽ có ngày càng nhiều công cụ, nền tảng hỗ trợ và hạ tầng được phát triển xung quanh khả năng xây dựng môi trường không máy chủ phức tạp hơn. Tích hợp tốt hơn với các dịch vụ khác sẽ là một trong những định hướng phát triển.
*TechFlow chú thích: Fargate là dịch vụ tính toán do Amazon Web Services (AWS) cung cấp, là một công cụ tính toán không máy chủ (serverless). Fargate giúp các nhà phát triển dễ dàng quản lý và triển khai ứng dụng đóng gói container mà không cần lo lắng về hạ tầng và máy chủ nền tảng.
Công nghệ container là một công nghệ ảo hóa, bằng cách đóng gói ứng dụng và các thành phần phụ thuộc vào các container độc lập, có thể di chuyển được, nhằm đạt được triển khai nhanh chóng và khả năng di động của ứng dụng. Công nghệ container sử dụng công cụ container (ví dụ Docker) để tạo, quản lý và vận hành container, giúp ứng dụng duy trì cách vận hành nhất quán trên các môi trường tính toán khác nhau, mà không cần lo lắng về sự khác biệt hạ tầng nền tảng. Công nghệ container hóa được ứng dụng rộng rãi trong phát triển và triển khai ứng dụng hiện đại, mang lại tính linh hoạt, khả năng mở rộng và tính di động cao hơn.
Bảo vệ khách hàng
Tuy nhiên, tôi cho rằng vấn đề an ninh sẽ trở thành trọng tâm quan tâm của mọi người. Trong năm năm tới, mọi người nên đặt an ninh làm nhiệm vụ hàng đầu, dù là CEO, CTO hay kỹ sư, chúng ta đều cần có ý thức an ninh và đóng vai trò kỹ sư an ninh. Trong vài năm qua, mỗi tuần đều xảy ra các sự cố rò rỉ dữ liệu quy mô lớn, với tư cách là chuyên gia công nghệ và nhà lãnh đạo thương mại số, chúng ta nên cảm thấy xấu hổ và tức giận. Bảo vệ dữ liệu khách hàng là trách nhiệm của chúng ta, vì nếu không bảo vệ khách hàng, sẽ không còn kinh doanh nào cả.
Chúng ta cần bắt đầu suy nghĩ cách bảo vệ dữ liệu thu thập từ khách hàng, dù là thuê xe hay các dịch vụ tiêu dùng khác. An ninh cần trở thành phần mặc định, ví dụ kích hoạt sự kiện an ninh trong ống dẫn tích hợp liên tục và triển khai liên tục, đảm bảo kiểm tra và đánh giá khi thêm thư viện mã nguồn mở mới.
Bản thân ống dẫn phát triển cũng cần an toàn, được trang bị các công cụ tự động hóa để kiểm tra lỗ hổng. Đặc biệt trong lĩnh vực y tế và tài chính, cần tuân thủ các quy định và yêu cầu quản lý khác nhau.
Trong năm năm tới, tôi hy vọng tất cả chúng ta đều có ý thức cao về vấn đề an ninh và đặt việc bảo vệ khách hàng lên hàng đầu. Tại Amazon, dù là vốn trí tuệ hay vốn tài chính, bảo vệ khách hàng sẽ luôn là lĩnh vực đầu tư hàng đầu của chúng tôi.
Những sai lầm phổ biến của công ty khởi nghiệp khi sử dụng AWS
Thứ nhất, đối với những người có kinh nghiệm trung tâm dữ liệu truyền thống, lần đầu sử dụng AWS có thể dẫn đến thiếu tự tin. Mặc dù AWS có lợi thế về tính đàn hồi và khả năng tận dụng, nhưng nếu không sử dụng các dịch vụ cấp cao hơn (như an ninh, phân tích dữ liệu và di động), chúng ta không thể phát huy tối đa tiềm năng, đặc biệt trong phát triển quy mô lớn yêu cầu độ tin cậy cao.
Thứ hai, điều then chốt là xác định loại hình và mục tiêu công ty. Có hai phong cách công ty khác nhau: một loại theo đuổi tăng trưởng nhanh, lượng khách hàng lớn, ít chú trọng doanh thu, thay vào đó dùng đầu tư lớn để mở rộng nhanh và có thể bị mua lại; loại khác theo đuổi phát triển bền vững, muốn xây dựng doanh nghiệp dài hạn chứ không chỉ tập trung vào việc bị mua lại.
Hai loại công ty này sử dụng AWS hoàn toàn khác nhau. Với công ty theo đuổi tăng trưởng nhanh, họ có thể yên tâm tận dụng dung lượng và dịch vụ AWS cung cấp, vì không cần quá lo lắng về chi phí. Với công ty theo đuổi phát triển bền vững, họ cần xây dựng kiến trúc khác, chú trọng hơn vào kiểm soát chi phí và đảm bảo mối quan hệ rõ ràng giữa chi phí và việc thu hút khách hàng.
Đối với người sáng lập công ty khởi nghiệp, Jeff Bezos thường phân biệt họ thành lính đánh thuê và nhà truyền giáo. Lính đánh thuê tham gia khởi nghiệp để theo đuổi tiền bạc, trong khi nhà truyền giáo xuất phát từ tình yêu sản phẩm. Cả hai đều là cách khởi nghiệp hợp lệ, nhưng hỗ trợ kỹ thuật và kiến trúc công nghệ xây dựng sẽ khác nhau.
Vì vậy, cần xác định rõ bạn thuộc loại công ty nào và tương ứng chọn hỗ trợ kỹ thuật và kiến trúc phù hợp.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
深潮TechFlow
