Bản dịch của bài viết được chuẩn bị riêng cho các học viên của khóa học , bắt đầu từ hôm nay!
Bạn đã bao giờ đưa một dịch vụ mới vào sản xuất chưa? Hoặc có thể bạn đã tham gia hỗ trợ các dịch vụ như vậy? Nếu có, điều gì đã thúc đẩy bạn? Điều gì tốt cho sản xuất và điều gì xấu? Bạn đào tạo các thành viên nhóm mới về cách phát hành hoặc bảo trì các dịch vụ hiện có như thế nào.
Hầu hết các công ty đều áp dụng phương pháp tiếp cận “Miền Tây hoang dã” khi nói đến thực tiễn hoạt động công nghiệp. Mỗi nhóm quyết định các công cụ và phương pháp hay nhất của riêng mình thông qua việc thử và sai. Nhưng điều này thường ảnh hưởng không chỉ đến sự thành công của dự án mà còn cả các kỹ sư.
Việc thử và sai tạo ra một môi trường mà việc đổ lỗi và đổ lỗi là điều phổ biến. Với hành vi này, việc học hỏi từ những sai lầm và không lặp lại chúng ngày càng trở nên khó khăn hơn.
Các tổ chức thành công:
- nhận thấy sự cần thiết phải có hướng dẫn cho sản xuất,
- nghiên cứu các phương pháp hay nhất,
- bắt đầu thảo luận về các vấn đề sẵn sàng sản xuất khi phát triển hệ thống hoặc thành phần mới,
- đảm bảo tuân thủ các quy tắc chuẩn bị cho sản xuất.
Việc chuẩn bị cho quá trình sản xuất bao gồm một quá trình “xem xét”. Việc đánh giá có thể ở dạng danh sách kiểm tra hoặc một bộ câu hỏi. Việc xem xét có thể được thực hiện thủ công, tự động hoặc cả hai. Thay vì liệt kê các yêu cầu tĩnh, bạn có thể tạo các mẫu danh sách kiểm tra có thể điều chỉnh cho phù hợp với nhu cầu cụ thể. Bằng cách này, các kỹ sư có thể có cơ hội kế thừa kiến thức và đủ linh hoạt khi được yêu cầu.
Khi nào cần kiểm tra mức độ sẵn sàng của dịch vụ để sản xuất?
Sẽ rất hữu ích nếu tiến hành kiểm tra mức độ sẵn sàng sản xuất không chỉ ngay trước khi phát hành mà còn khi chuyển nó sang nhóm vận hành khác hoặc nhân viên mới.
Kiểm tra khi:
- Bạn đang phát hành một dịch vụ mới vào sản xuất.
- Bạn chuyển giao hoạt động dịch vụ sản xuất cho một nhóm khác, chẳng hạn như SRE.
- Bạn chuyển giao hoạt động dịch vụ sản xuất cho nhân viên mới.
- Tổ chức hỗ trợ kỹ thuật.
Danh sách kiểm tra sẵn sàng sản xuất
Cách đây một thời gian, để làm ví dụ, tôi danh sách kiểm tra để kiểm tra sự sẵn sàng cho sản xuất. Mặc dù danh sách này có nguồn gốc từ khách hàng của Google Cloud nhưng nó sẽ hữu ích và có thể áp dụng bên ngoài Google Cloud.
Thiết kế và phát triển
- Phát triển quy trình xây dựng có thể lặp lại, không yêu cầu quyền truy cập vào các dịch vụ bên ngoài và không phụ thuộc vào lỗi của hệ thống bên ngoài.
- Trong giai đoạn thiết kế và phát triển, hãy xác định và đặt SLO cho dịch vụ của bạn.
- Ghi lại những kỳ vọng về sự sẵn có của các dịch vụ bên ngoài mà bạn phụ thuộc vào.
- Tránh một điểm lỗi duy nhất bằng cách loại bỏ sự phụ thuộc vào một tài nguyên toàn cầu. Sao chép tài nguyên hoặc sử dụng phương án dự phòng khi tài nguyên không khả dụng (ví dụ: giá trị được mã hóa cứng).
Quản lý cấu hình
- Cấu hình tĩnh, nhỏ và không bí mật có thể được chuyển qua các tham số dòng lệnh. Đối với mọi thứ khác, hãy sử dụng dịch vụ lưu trữ cấu hình.
- Cấu hình động phải có cài đặt dự phòng trong trường hợp dịch vụ cấu hình không khả dụng.
- Cấu hình môi trường phát triển không được liên quan đến cấu hình sản xuất. Nếu không, điều này có thể dẫn đến việc truy cập từ môi trường phát triển đến các dịch vụ sản xuất, điều này có thể gây ra các vấn đề về quyền riêng tư và rò rỉ dữ liệu.
- Ghi lại những gì có thể được cấu hình động và mô tả hành vi dự phòng nếu hệ thống phân phối cấu hình không khả dụng.
Quản lý phát hành
- Ghi lại quá trình phát hành một cách chi tiết. Mô tả cách các bản phát hành ảnh hưởng đến SLO (ví dụ: độ trễ tăng tạm thời do thiếu bộ nhớ đệm).
- Tài liệu phát hành canary.
- Xây dựng kế hoạch đánh giá bản phát hành canary và nếu có thể, cơ chế khôi phục tự động.
- Đảm bảo việc khôi phục có thể sử dụng các quy trình tương tự như quá trình triển khai.
Khả năng quan sát
- Đảm bảo rằng bộ số liệu cần thiết cho SLO được thu thập.
- Đảm bảo bạn có thể phân biệt giữa dữ liệu máy khách và máy chủ. Điều này rất quan trọng để tìm ra nguyên nhân của sự cố.
- Thiết lập cảnh báo để giảm chi phí lao động. Ví dụ: xóa cảnh báo do hoạt động thường ngày gây ra.
- Nếu bạn sử dụng Stackdriver, hãy đưa số liệu nền tảng GCP vào trang tổng quan của bạn. Thiết lập cảnh báo cho các phần phụ thuộc GCP.
- Luôn truyền bá các dấu vết đến. Ngay cả khi bạn không tham gia vào quá trình truy tìm, điều này sẽ cho phép các dịch vụ cấp thấp hơn khắc phục sự cố trong quá trình sản xuất.
Bảo vệ và an toàn
- Đảm bảo tất cả các kết nối bên ngoài đều được mã hóa.
- Đảm bảo các dự án sản xuất của bạn có thiết lập IAM chính xác.
- Sử dụng mạng để cách ly các nhóm phiên bản máy ảo.
- Sử dụng VPN để kết nối an toàn với các mạng từ xa.
- Lập tài liệu và giám sát quyền truy cập của người dùng vào dữ liệu. Đảm bảo rằng tất cả quyền truy cập của người dùng vào dữ liệu đều được kiểm tra và ghi lại.
- Đảm bảo rằng các điểm cuối gỡ lỗi bị hạn chế bởi ACL.
- Vệ sinh đầu vào của người dùng. Định cấu hình giới hạn kích thước tải trọng cho đầu vào của người dùng.
- Đảm bảo dịch vụ của bạn có thể chặn có chọn lọc lưu lượng truy cập đến cho từng người dùng. Điều này sẽ chặn các hành vi vi phạm mà không ảnh hưởng đến người dùng khác.
- Tránh các điểm cuối bên ngoài bắt đầu nhiều hoạt động nội bộ.
Quy hoạch năng lực
- Ghi lại quy mô dịch vụ của bạn. Ví dụ: số lượng người dùng, kích thước tải trọng đến, số lượng tin nhắn đến.
- Ghi lại các yêu cầu về nguồn lực cho dịch vụ của bạn. Ví dụ: số lượng phiên bản máy ảo chuyên dụng, số lượng phiên bản Spanner, phần cứng chuyên dụng như GPU hoặc TPU.
- Giới hạn tài nguyên tài liệu: loại tài nguyên, khu vực, v.v.
- Hạn chế hạn ngạch tài liệu để tạo tài nguyên mới. Ví dụ: giới hạn số lượng yêu cầu API GCE nếu bạn sử dụng API để tạo phiên bản mới.
- Hãy cân nhắc việc chạy thử tải để phân tích sự suy giảm hiệu suất.
Đó là tất cả. Hẹn gặp bạn ở lớp!
Nguồn: www.habr.com