Vì sao triển khai DevOps thất bại ở doanh nghiệp vừa và nhỏ, và lộ trình thực dụng thực sự hiệu quả

Một CTO ở startup 22 người mua Kubernetes, một nền tảng CI đầy đủ, Terraform, và một stack observability hiện đại, tất cả trong một quý. Sáu tháng sau, ca trực on-call còn tệ hơn, không hề tốt lên. Các đợt deploy vẫn hỏng vào chiều thứ Sáu, và hai kỹ sư thực sự hiểu pipeline đã lặng lẽ bắt đầu né tránh một số repository nhất định. Đây không phải là câu chuyện hiếm gặp. Đó là kết cục mặc định khi một đội kỹ sư nhỏ cố gắng áp dụng DevOps bằng cách mua các công cụ mà Netflix dùng.

Lầm tưởng đắt giá nhất đối với doanh nghiệp vừa và nhỏ

Lầm tưởng tốn kém nhất trong kỹ thuật ở doanh nghiệp vừa và nhỏ là DevOps chỉ là một danh sách mua sắm. Các đội đọc case study từ Spotify hoặc Google, thấy một chồng công cụ, và cho rằng tái tạo được stack đó sẽ tái tạo được kết quả. Không phải vậy. Các công ty đó không trở nên đáng tin cậy vì họ áp dụng Kubernetes. Họ áp dụng Kubernetes vì họ đã xây dựng được năng lực vận hành đủ mạnh để chạy nó, và vì quy mô của họ thực sự biện minh cho phần chi phí phụ trội đó.

DevOps ở doanh nghiệp vừa và nhỏ không phải là vấn đề công cụ. Đó là vấn đề quy trình làm việc mặc trang phục công cụ.

Tự động hóa không đồng nghĩa với độ trưởng thành vận hành

Có một sự phân biệt hữu ích mà phần lớn các đội gộp lại làm một: tự động hóa và độ trưởng thành vận hành không phải là cùng một thứ. Một đội đã tự động hóa pipeline deploy nhưng không trả lời được câu hỏi "vì sao production hỏng lúc 3 giờ sáng" là đội đã mua tốc độ mà không thêm được sự an toàn. Bây giờ họ chỉ ship code lỗi nhanh hơn.

Độ trưởng thành vận hành là tập hợp các thói quen khiến một sự cố trở nên nhàm chán: một thao tác rollback chỉ tốn một lệnh, một dashboard hiển thị đúng ba chỉ số thực sự quan trọng, một runbook mà kỹ sư trực on-call có thể làm theo lúc 3 giờ sáng, và một buổi post-incident review làm thay đổi được điều gì đó cho tuần sau. Tự động hóa khuếch đại bất kỳ hướng nào bạn đang đi. Nếu thói quen của bạn không vững, tự động hóa chỉ làm cho cú va đập to hơn.

Bốn sai lầm thường gặp

Mua nền tảng trước khi xây dựng thực tiễn. Một đội 15 kỹ sư không cần Kubernetes. Có lẽ họ chỉ cần một máy ảo bình thường cho mỗi service, một health check, và một cơ chế rollback tự động. Kubernetes giải quyết những vấn đề bạn chưa có, và nó tạo ra những vấn đề mới mà đội bạn chưa được trang bị để debug.

Biến pipeline thành dự án cá nhân. Ở nhiều doanh nghiệp vừa và nhỏ, một kỹ sư lặng lẽ trở thành "người DevOps". Họ xây dựng một pipeline đẹp đẽ mà chỉ họ hiểu. Khi họ đi nghỉ, các đợt deploy đóng băng. Khi họ nghỉ việc, pipeline trở thành gánh nặng mà phần còn lại của đội sợ không dám đụng vào. Sở hữu chung không phải là điều tùy chọn; đó là ranh giới giữa hạ tầng là tài sản và hạ tầng là con tin.

Đo sai chỉ số. Tần suất deploy là chỉ số hào nhoáng nếu tỷ lệ thay đổi gây lỗi đang tăng lên. Các đội nhỏ nên quan sát hai con số trước tiên: bao nhiêu lần deploy gây ra sự cố, và mất bao lâu để phục hồi khi có sự cố. Tối ưu tốc độ mà bỏ qua hai con số này chính là cách bạn biến một sản phẩm ổn định thành một sản phẩm lung lay.

Bỏ qua các nền tảng nhàm chán. Hạ tầng được quản lý bằng version control, một môi trường phát triển cục bộ có thể tái tạo được, và một nguồn duy nhất cho secrets đều không hào nhoáng. Đó cũng là ranh giới giữa một sự cố mất hai mươi phút và một sự cố kéo dài hai ngày.

Một ví dụ thực tế ngắn

Một khách hàng thương mại điện tử khu vực đến với chúng tôi với đội ngũ 12 kỹ sư, ba sự cố production mỗi tuần, và một kế hoạch di chuyển toàn bộ sang Kubernetes. Chúng tôi đề nghị họ tạm dừng đợt di chuyển đó trong sáu tuần.

Trong sáu tuần đó, chúng tôi không làm điều gì thú vị. Chúng tôi đưa hạ tầng của họ vào Terraform, viết một script deploy duy nhất mà bất kỳ kỹ sư nào trong đội cũng có thể chạy, chuyển secrets vào một vault được quản lý, thêm các health check có thể kích hoạt rollback tự động, và thiết lập ba dashboard chỉ hiển thị các chỉ số gắn với doanh thu: tỷ lệ đơn hàng thành công, độ trễ checkout, và lỗi payment gateway.

Sự cố giảm từ ba lần mỗi tuần xuống còn một lần mỗi mười ngày. Đội sau đó di chuyển hai service không quan trọng sang Kubernetes, học nó trên lưu lượng thấp rủi ro, và chỉ sau đó mới chuyển luồng checkout. Đợt di chuyển thành công vì đội đã xây dựng được năng lực trước, không phải vì công cụ khác so với kế hoạch ban đầu.

Lộ trình thực dụng cho đội dưới 30 kỹ sư

Bước 1: Sửa nút deploy. Trước tất cả, hãy đảm bảo bất kỳ kỹ sư nào cũng có thể deploy service chính bằng một lệnh, và rollback bằng một lệnh khác. Nếu việc này hôm nay tốn hơn một ngày phối hợp qua chat, đây chính là nơi ẩn giấu lợi ích lớn nhất về độ tin cậy.

Bước 2: Đưa hạ tầng vào code. Terraform hoặc Pulumi, tùy công cụ nào đội bạn đọc trôi chảy. Mục tiêu không phải là tự động hóa để tự động hóa; đó là khả năng tái tạo bất kỳ môi trường nào từ đầu khi có sự cố xảy ra vào thời điểm tệ nhất.

Bước 3: Hợp nhất secrets và cấu hình. Một vault, một quy ước, một nơi để xoay key. Secrets rải rác trong các file dotenv và tin nhắn chat là nguyên nhân âm thầm của một tỷ lệ đáng ngạc nhiên các bất ngờ ở production.

Bước 4: Đo hai chỉ số DORA thực sự quan trọng với doanh nghiệp vừa và nhỏ. Tỷ lệ thay đổi gây lỗi và thời gian trung bình để phục hồi. Theo dõi chúng một cách trung thực trong một quý. Hãy để các con số, không phải các bài viết xu hướng, cho bạn biết cần sửa gì tiếp theo.

Bước 5: Áp dụng container trước khi áp dụng orchestration. Docker mang lại phần lớn lợi ích về tái tạo với một phần nhỏ chi phí vận hành. Kubernetes là quyết định nên đưa ra ở mốc 40 hay 50 kỹ sư, hoặc khi lưu lượng của bạn thực sự đòi hỏi, không phải trước đó.

Bước 6: Viết những runbook nhàm chán. Với mỗi service quan trọng, làm ra một trang duy nhất: nó làm gì, kiểm tra xem nó có khỏe không bằng cách nào, khởi động lại nó ra sao, và gọi ai khi nó không chịu hồi phục. Kiểm thử mỗi runbook bằng cách để một kỹ sư mới làm theo trong một buổi game day rủi ro thấp.

Kết luận thẳng thắn

DevOps không phải là một sản phẩm bạn cài đặt. Với một đội từ 30 người trở xuống, đó là tập hợp các quyết định về quy trình làm việc tạo nên sự khác biệt giữa một nhóm kỹ sư ship code một cách tự tin và một nhóm sống trong nỗi sợ chiều thứ Sáu. Công cụ là phần dễ. Thói quen mới là công việc.

Nếu bạn đang cân nhắc một đợt cải tổ DevOps và muốn có ý kiến thứ hai trước khi cam kết với một nền tảng, đội ngũ của chúng tôi tại MercTechs đã giúp các doanh nghiệp vừa và nhỏ trong khu vực thiết kế các lộ trình thực dụng giúp giảm sự cố mà không bị over-engineering. Chúng tôi thà giúp bạn bỏ qua một stack đắt tiền mà bạn không cần, hơn là bán cho bạn một stack mà bạn sẽ hối tiếc.