Ôi chết mịa, lỡ tay xóa nhầm con Jenkins cluster rồi
Cái éo gì thế này, terraform code running nó destroy con server rồi
Móa nó, chạy script thế nào mà lại thành sudo rm -rf * bay hết data rồi
Anh ơi, em lỡ tay xóa data trong RDS rồi
Trên đây là một vài tình huống có thật khi bạn làm SRE engineer, thiết kế và quản lý infrastructure. Các sự cố luôn xảy ra, gây ra outage hoặc incident, không chỉ với các công ty nhỏ mà ngay cả các tập đoàn lớn cũng gặp tương tự. Vì 1 lí do đơn giản HUMAN MISTAKE
Sự cố outage của Facebook
Gần đây nhất và nổi tiếng nhất là vụ Outage của Facebook trong 6 giờ vào năm 2021 liên quan đến Border Gateway Protocol, or BGP.
Hiểu một cách kĩ thuật đơn giản thì như thế này, Facebook có nhiều data centers ở nhiều nơi. Nếu bạn ở VN vào facebook xem new feeds, requests sẽ được gửi tới data center gần nhất (VD singapore) thông qua một mạng backbone . Data traffict qua backbone sẽ được điều phối bởi router , router sử dụng giao thức BGP để định tuyến để tìm đoạn đường ngắn nhất đi từ A đến B. Kiểu như bạn muốn đi từ Vạn Bảo đến Trần Duy Hưng để check hàng thì BGP sẽ được router sử dụng để chỉ ra đường đi ngắn nhất. Trong vụ outage này. một thanh niên của Facebook gõ một command để thực hiện một số cập nhật trên BGP, nhưng vô tình làm down luôn toàn bộ kết nối trong backbone network của Facebook. Mặc dù Facebook có audit tool để detect những command nguy hiểm nhưng đen phát tool lại có bug nên không stop được command này. Kết quả là Facebook ngỏm luôn trong 6h. Với nền tảng cả tỉ người dùng như FB thì việc outage này thiệt hại quá lớn
Vụ outage của AWS
Sự cố liên quan đến S3, Một câu lệnh gõ nhầm của nhân viên kỹ thuật đã làm các máy chủ đám mây của công ty tại khu vực Virginia ngừng hoạt động.
Cụ thể là thế này, một nhóm kỹ thuật trong bộ phận Amazon Simple Storage Service tiến hành sửa một vấn đề làm cho hệ thống xử lý hóa đơn thanh toán của S3 hoạt động chậm hơn dự kiến. Để sửa lỗi này, lúc xx giờ sáng PST, một thành viên chính thức của nhóm Amazon S3 (chắc cũng có số má) thực thi một lệnh với dự định loại bỏ một lượng nhỏ máy chủ cho một trong các hệ thống phụ của S3, vốn đang được sử dụng cho quá trình xử lý thanh toán này.
Thật không may, chắc là do ngáo nên anh ks nhập sai input params của command và số lượng máy chủ bị loại bỏ nhiều hơn dự định. Giống kiểu gõ lện rm -rf lỡ tay thêm chữ * , thể là ngỏm luôn
Đến câu chuyện từ các công ty nhỏ hơn
Con người dù giỏi đến mấy thì cũng là con người, human mistake là khó tránh , đến những kĩ sư AWS, FB còn dính thì mấy thanh niên cty F** có chạy đàng trời.
Xóa cluster Jenkins
Công ty nọ deploy Jenkins trên K8s cluster, Jenkins là core của CICD pipeline, số lượng jobs tới hàng chục nghìn, hàng ngày cả trăm developer code buid test tạo PR liên tục, jobs build deploy chạy cả mớ. Môi trường nào dev, qa, prod, chưa kể nhiều team lại đòi phải tạo cluster jenkins riêng dùng cho nó máu tốn tiền cả đống. Đành phải thực hiện dọn dẹp những cluster un-used cho đỡ tốn.
SRE nên quyền lực vô đối , mạnh dạn gõ command pass cluster name
gcloud container clusters delete NAME [NAME …] [--async] [--region=REGION | --zone=ZONE, -z ZONE] [GCLOUD_WIDE_FLAG …]Rủi thay tối qua vừa đi nhậu lại làm vào shot tăng 2 nên đầu óc ngáo ngơ, tên cluster dài quá copy paste cho nhanh, paste nhầm luôn cả con Jenkins CICD
Gõ enter, confirm xong thì mới đái ra quần, thôi xong lỡ tay cho em nó đăng xuất rồi.
Clean server
Server khách hàng được provisioned bởi terraform code, quản lý bởi terraform state, mỗi lần cần update cấu hình server thì sửa code rồi chạy apply bằng CICD pipeline. Code được scan audit review approve đủ kiểu mới được deploy lên AWS.
Con server tháng này mới đc patching bằng bản AMI mới , chạy truyền tham số AMI là xong. Đơn giản gọn nhẹ, jobs approved trong 1 nốt nhạc, chạy deploy mượt mà, yên tâm đi ngủ
Sáng ra điện thoại message cháy máy, mail alert cả rổ ” server down”. Ôi thôi chết mịa rồi, copy nhầm AMI ID, lại không review kĩ terrform plan đã approved. Lại human mistake
Terraform trước khi deploy bao giờ cũng có bước terraform plan confirm những resource nào được tạo, destroy, update hay replaced
Có những resource terrform sẽ replaced theo kiểu destroy cái cũ tạo cái mới chứ không thể update trực tiếp như RDS, ELB thể hiện bằng kí hiệu +/-
Khắc phục
Khi incident xảy ra, thì bạn mới thấy sự quan trọng việc DR, backup and recovery. Bởi vì server destroy tạo lại không khó, nhưng mất data thì thực sự thảm họa vì nó là tiền. Các hệ thống làm DR tốt đều phục hồi hệ thống nhanh chóng.
Cluster Jenkins lỡ tay bị xóa, nhưng toàn bộ dữ liệu về các jobs, config được lưu trên một storage volume được snapshot prediocally daily. Infra Jenkins được viết sẵn bằng code. Toàn bộ config của cluster đã backup bằng Velero, Do đó , mặc dù bị xóa, chỉ việc thực hiện chạy lại code để provisioning và restore lại config bằng velero là hệ thống trở lại bình thường
Server cũng vậy, data nằm trong volume mount đã dc snapshot thường xuyên. AWS Backup snapshot toàn bộ server config qua AMI. RDS đều có cơ chế snapshot nên phục hồi kịp
Nhưng sai lầm thì vẫn là sai lầm, dù phục hồi được nhưng hệ thống vẫn bị outage trong 1 thời gian và user bị ảnh hưởng. Sau mỗi sự code thì RCA report dài dằng dặng, 5Why phân tích tối ngày để detect nguyên nhân và counter measure.
Cho nên HUMAN MISTAKE là khó tránh, chỉ làm sao để giảm thiểu rủi ro
0 Nhận xét