Nền tảng AI
Kỹ Thuật Nền Tảng Là Gì? Các Nền Tảng, Trải Nghiệm Nhà Phát Triển và Rào Cản Bảo Vệ
Thêm Unite.AI vào các nguồn ưu tiên của bạn trên Google
Kỹ thuật nền tảng là thực hành xây dựng và vận hành các khả năng nội bộ chia sẻ giúp các đội phần mềm triển khai và chạy ứng dụng thông qua quy trình tự phục vụ được hỗ trợ. Nền tảng được xem như một sản phẩm, người dùng của nó là các nhà phát triển và các nhóm kỹ thuật khác.
Một nền tảng không tự động là một cổng thông tin, cụm Kubernetes, hay một tập hợp các script. Nó trở nên hữu ích khi giảm tải nhận thức và thời gian dẫn dắt đồng thời cải thiện độ tin cậy, bảo mật, khả năng quan sát và tính nhất quán của tổ chức.
Những điểm chính
- Bắt đầu bằng nghiên cứu nhà phát triển và các điểm ma sát lặp lại, không phải một bộ công cụ đã định sẵn.
- Cung cấp các con đường vàng tùy chọn, được hỗ trợ, với các lối thoát rõ ràng cho các ngoại lệ hợp lý.
- Tiết lộ các khả năng qua API, mẫu, tự động hoá và tài liệu; một cổng chỉ là một giao diện.
- Đo lường kết quả người dùng và mức độ chấp nhận sản phẩm cùng với việc giao hàng, độ tin cậy, bảo mật và chi phí.
Nền tảng như một sản phẩm nội bộ
Một đội nền tảng xác định người dùng nội bộ, hành trình, điểm đau và kết quả mong muốn. Họ duy trì lộ trình, mức dịch vụ, tài liệu, hỗ trợ và vòng phản hồi giống như bất kỳ đội sản phẩm nào. Việc chấp nhận được đạt được nhờ tính hữu ích, không phải do chỉ định một đội trung tâm.
Điều này mở rộng sự hợp tác DevOps. Các đội ứng dụng giữ quyền sở hữu dịch vụ của mình trong khi nền tảng cung cấp các khả năng tái sử dụng và chính sách.
Các khả năng, cổng thông tin và con đường vàng
Các khả năng có thể bao gồm kho mã, môi trường, CI/CD, bí mật, danh tính, hạ tầng, khả năng quan sát, danh mục dịch vụ, chi phí và tích hợp sự cố. Một cổng nhà phát triển có thể hiển thị chúng, nhưng việc điều phối và các dịch vụ vận hành mới tạo nên nền tảng thực sự.
Con đường vàng là một cách được hỗ trợ tốt để thực hiện một nhiệm vụ phổ biến. Nó nên mã hoá các mặc định bảo mật và vẫn minh bạch. Các đội cần một lối ngoại lệ được quản lý khi yêu cầu khác nhau.
Kiến trúc và rào cản bảo vệ
Sử dụng các giao diện ổn định và API khai báo để nền tảng có thể phát triển phía sau chúng. Tách plane điều khiển khỏi các khối tải, giới hạn quyền truy cập, bảo tồn siêu dữ liệu sở hữu và làm cho các thay đổi được tạo ra có thể xem xét và đảo ngược.
Tích hợp các kiểm tra DevSecOps, chính sách và nguồn gốc artefact vào quy trình làm việc. Rào cản bảo vệ nên cung cấp phản hồi nhanh và biện pháp khắc phục có thể hành động thay vì từ chối không giải thích.
Đo lường và phát triển
Đo lường thời gian tới lần triển khai đầu tiên, thời gian dẫn dắt, phục hồi khi thay đổi thất bại, tính sẵn sàng của nền tảng, gánh nặng hỗ trợ, mức độ chấp nhận, sự hài lòng, trạng thái bảo mật và chi phí. Tránh tính số lần đăng nhập cổng như một chỉ số thay thế cho việc cải thiện giao hàng.
Cài đặt công cụ đo lường cho nền tảng thông qua các thực hành vận hành IT operations và phỏng vấn người dùng thường xuyên. Loại bỏ các con đường không sử dụng, tiêu chuẩn hoá nơi lặp lại tốn kém, và cho phép đa dạng khi nó tạo ra giá trị sản phẩm.
Nền tảng nhà phát triển nội bộ và con đường vàng
Nền tảng nhà phát triển nội bộ là một sản phẩm cho phép truy cập hạ tầng và các khả năng vận hành đã được phê duyệt thông qua giao diện tự phục vụ. Nó có thể kết hợp cổng, danh mục dịch vụ, mẫu, API, công cụ dòng lệnh, quy trình triển khai, bí mật, môi trường và khả năng quan sát. Nền tảng không thay thế đám mây hay Kubernetes; nó tổ chức chúng thành các khả năng có thể sử dụng.
Con đường vàng là một cách có quan điểm, được hỗ trợ để hoàn thành một nhiệm vụ phổ biến, chẳng hạn tạo dịch vụ với kho mã, pipeline CI, môi trường chạy, bảng điều khiển, cảnh báo và siêu dữ liệu sở hữu. Nó nên là lựa chọn an toàn và dễ nhất đồng thời cho phép các ngoại lệ hợp lý. Một con đường bắt buộc không thể hỗ trợ khối tải thực tế sẽ trở thành nút thắt hoặc bị bỏ qua.
Các đội nền tảng nên xem nhà phát triển như khách hàng và các khả năng như sản phẩm. Các buổi phỏng vấn khám phá, phân tích sử dụng, dữ liệu hỗ trợ, lộ trình, tài liệu và mục tiêu mức dịch vụ quan trọng như tự động hoá. Việc chấp nhận là bằng chứng cho tính hữu ích, nhưng chỉ chấp nhận không chứng minh rằng việc giao hàng, độ tin cậy, bảo mật hoặc trải nghiệm nhà phát triển đã được cải thiện.
Plane điều khiển, giao diện và mô hình vận hành
Plane điều khiển của nền tảng điều chỉnh ý định đã khai báo của nhà phát triển với các tài nguyên nền tảng. Định nghĩa dịch vụ có thể yêu cầu môi trường chạy, cơ sở dữ liệu, khu vực và mức độ tin cậy; các bộ điều khiển chuyển đổi chúng thành cấu hình đám mây, mạng, chính sách và khả năng quan sát. Các trừu tượng ổn định nên ẩn đi sự phức tạp phụ trợ mà không che giấu trạng thái vận hành cần thiết cho việc gỡ lỗi.
Các giao diện có thể bao gồm cổng web, API, cấu hình dựa trên Git, CLI và các thành phần pipeline tái sử dụng. Giao diện tốt nhất phụ thuộc vào tần suất nhiệm vụ và quy trình làm việc của người dùng. Mỗi giao diện cần xác thực, ủy quyền, xác thực dữ liệu, lịch sử kiểm toán, giải thích lỗi và quản lý phiên bản. Tự phục vụ mà không có quản lý vòng đời dẫn tới tài nguyên bị bỏ rơi và sự lan truyền cấu hình.
Một đội nền tảng sở hữu các khả năng chia sẻ và các con đường đã được định sẵn, trong khi các đội ứng dụng giữ trách nhiệm về hành vi phần mềm và kết quả kinh doanh. Các đội bảo mật, độ tin cậy, tài chính và hạ tầng đóng góp chính sách và dịch vụ. Ranh giới trách nhiệm rõ ràng ngăn nền tảng trở thành một hàng đợi ticket không có trách nhiệm hoặc một nỗ lực tập trung mọi quyết định kỹ thuật.
Đo lường giá trị và tránh thất bại nền tảng
Đo lường thời gian dẫn dắt tới lần triển khai sản xuất đầu tiên, thời gian cung cấp môi trường, tần suất triển khai, tỷ lệ thất bại thay đổi, thời gian phục hồi, tải nhận thức, khối lượng hỗ trợ, độ tin cậy và mức độ chấp nhận kiểm soát bảo mật. Phân đoạn kết quả theo đội và khối tải. Việc ra mắt mẫu nhanh hơn có giá trị hạn chế nếu các thay đổi ngày thứ hai vẫn chậm hoặc các sự cố trở nên khó chẩn đoán hơn.
Các thất bại phổ biến bao gồm xây dựng trước khi hiểu người dùng, sao chép ngăn xếp của công ty lớn, để lộ hạ tầng thô phía sau cổng, ép buộc tiêu chuẩn hoá quá sớm và tối ưu hoá cho đầu ra của đội nền tảng. Bắt đầu với một hành trình lặp lại gây đau đớn, lập bản đồ các bước và thời gian chờ, cung cấp một con đường mỏng đầu cuối, và lặp lại dựa trên kết quả quan sát được.
Nền tảng phải phát triển mà không làm mất ổn định mọi dịch vụ. Sử dụng hợp đồng có phiên bản, cửa sổ ngừng hỗ trợ, di chuyển tự động, kiểm tra tương thích và ranh giới sở hữu rõ ràng. Theo dõi các phụ thuộc của nền tảng để một sự cố plane điều khiển không chặn mọi triển khai hoặc gây hại cho các khối tải đang chạy. Ghi chép quy trình khẩn cấp và thường xuyên kiểm tra khả năng phục hồi sau thất bại nền tảng.
Ví dụ thực tế: một con đường tự phục vụ cho API mới
Một nhà phát triển chọn một mẫu API đã được phê duyệt và cung cấp tên dịch vụ, chủ sở hữu, phân loại dữ liệu, ngôn ngữ và mức độ tin cậy. Nền tảng tạo ra một kho mã, chính sách phụ thuộc, pipeline CI, môi trường thử nghiệm, cấu hình triển khai, mục danh mục dịch vụ, bảng điều khiển, cảnh báo và một sổ tay khởi đầu. Chính sách xác thực tên, khu vực, quyền và mức độ phơi bày mạng trước khi cung cấp, trong khi các artefact được tạo vẫn có thể kiểm tra và thuộc sở hữu của đội.
Nền tảng cung cấp các hoạt động vòng đời — tạo môi trường, triển khai, mở rộng, thay đổi bí mật, xem log, quay lại và ngừng sử dụng — qua API ổn định và một cổng. Các khối tải đang chạy vẫn tiếp tục nếu cổng không khả dụng. Các ngoại lệ sử dụng điểm mở rộng được ghi chép và thời hạn thay vì thay đổi thủ công không được theo dõi. Các mẫu có phiên bản và di chuyển tự động ngăn các cải tiến nền tảng phá vỡ ẩn danh các dịch vụ hiện có.
Đo lường thời gian từ khi tạo kho mã tới một triển khai sản xuất ổn định, nỗ lực của nhà phát triển, nhu cầu hỗ trợ, thất bại thay đổi, phục hồi, tuân thủ chính sách và mức độ chấp nhận theo loại khối tải. Phỏng vấn những người dùng bỏ qua con đường và kiểm tra nơi họ chờ đợi hoặc thoát khỏi abstraction. Đội nền tảng nên ưu tiên điểm ma sát lặp lại lớn nhất, công bố độ tin cậy và lộ trình, và loại bỏ các khả năng không dùng. Một danh mục được chăm chút không phải là nền tảng nếu các đội vẫn cần ticket cho mỗi thao tác quan trọng.
Việc chấp nhận nên được triển khai theo giai đoạn. Bắt đầu với các đội tình nguyện và một lớp khối tải, chứng minh các hoạt động ngày thứ hai, sau đó di chuyển với công cụ và hỗ trợ. Công bố mục tiêu dịch vụ và trạng thái phụ thuộc của nền tảng, và thiết kế một lối thoát khẩn cấp được kiểm soát nhưng có thể sử dụng trong thời gian sự cố. Phương thức chargeback hoặc showback có thể hiển thị chi phí tài nguyên, nhưng các đội sản phẩm cũng cần các mặc định hợp lý để quản trị tài chính không trở thành một hàng đợi phê duyệt thủ công khác.
Danh sách kiểm tra triển khai thực tiễn
Biến khái niệm thành một quy trình có giới hạn, có thể kiểm thử: nghiên cứu người dùng → thiết kế con đường → xây dựng → tự phục vụ → vận hành → cải thiện. Đặt tên cho người chịu trách nhiệm, ghi chép dữ liệu và các phụ thuộc, thiết lập một nền tảng đơn giản, xác định tiêu chí chấp nhận và dừng, kiểm thử các lỗi đại diện, và định nghĩa giám sát, quay lại và đánh giá trước khi mở rộng phạm vi. Ghi lại các phiên bản và giả định để đội khác có thể tái tạo kết quả và hiểu những gì đã thay đổi.
Trước khi ra mắt, thực hiện một cuộc đánh giá sẵn sàng được ghi chép với những người xây dựng, vận hành, bảo mật và bị ảnh hưởng bởi hệ thống. Kiểm thử các trường hợp bình thường, điều kiện biên, thất bại phụ thuộc và lạm dụng; bảo quản bằng chứng và rủi ro chưa giải quyết. Xác định ai có thể phê duyệt phát hành, thay đổi ngưỡng, ghi đè đầu ra hoặc dừng hoạt động. Xem lại quyết định sau khi dữ liệu thực tế xuất hiện, vì một dự án thí điểm kỹ thuật thành công không đảm bảo hiệu suất đáng tin cậy ở quy mô lớn hơn.
- PRODUCT: người dùng, lộ trình, phản hồi và hỗ trợ.
- CAPABILITIES: API, tự động hoá, dịch vụ và chính sách.
- OUTCOMES: luồng công việc, độ tin cậy, bảo mật và chi phí.
Câu hỏi thường gặp
Kỹ thuật nền tảng có đang thay thế DevOps không?
Không. Kỹ thuật nền tảng là một cách mở rộng các nguyên tắc DevOps bằng cách cung cấp các sản phẩm chia sẻ và khả năng tự phục vụ. Sự hợp tác và sở hữu dịch vụ vẫn là yếu tố thiết yếu.
Cổng nhà phát triển nội bộ có phải là nền tảng không?
Thường không. Một cổng chỉ là một giao diện. Nền tảng còn bao gồm API, tự động hoá, hạ tầng, chính sách, dịch vụ, tài liệu, hỗ trợ và quyền sở hữu vận hành.
Tài liệu tham khảo chính
