Giaosucan's blog - Chia sẻ kiến thức theo cách bá đạo

Ticker

20/recent/ticker-posts

Chiêu binh bình giảng - Xóa data, devops gặp nguy






Lại nói chuyện hồi trước, SRE team được thành lập, gọi là Site Reliability Engineer, là kỹ sư quản lý hệ thống, đảm bảo hệ thống làm việc trơn tru, không trục trặc, ứng phó với các sự cố xảy ra. Đồng thời xử lý những request liên quan đến hệ thống đến từ các team khác.

Theo định nghĩa của Google thì SRE là kĩ sư phần mềm nhưng làm công việc liên quan đến operation là chính. Công việc này chiếm khoảng 50%, chủ yếu là xử lý issue, on-call. 50% còn lại tập trung phát triển tính năng cho hệ thống như auto-scaling, self-healing… 
Như vậy SRE engineer đòi hỏi kĩ năng administration (Ops) cũng như khả năng development (Dev). Cho nên kĩ sư SRE và DevOps có nhiều điểm tương đồng. Tuy hai mà một, tuy một mà hai
Nghe nói ở Fsoft cũng có 1 team như vậy tính ra cũng được 10 nhân mạng, trên thông cloud (aws, gce, azure) dưới tường viết code (python, shellscript). Certification , bằng cấp đầy người (nhẹ nhẹ thì aws architect, sơ sơ thì gce developer engineer)
Team SRE thì quan trọng nhất là Runbook, có thể hiểu nó như là Cửu Âm Chân Kinh của Quánh Tĩnh, Di Thư Võ mộc của Nhạc Phi. Là tập hợp hướng dẫn từng bước cách xử lý sự cố , hay vận hành hệ thống, được viết kĩ lưỡng, tổ chức khoa học để cho các kĩ sư SRE tham khảo.
Runbook được tạo thành khi các kĩ sư SRE làm việc, troubleshooting, và ghi lại kinh nghiệm của họ vào Runbooks. Lâu dần tích tiểu thành đại, mà runbooks trở thành pho bí kíp, đặc biệt hữu ích cho các kỹ sư SRE mới.
Hận thay, việc của SRE engineer cũng như làm dâu trăm họ. Một ngày số request xử lý tính đến cả trăm, trăm dâu lại đổ đầu tằm. Gặp những người quân tử hào kiệt thì cảm thông, nhưng nếu gặp phải kẻ bụng dạ đàn bà, tiểu nhân hẹp hòi thì thật oán hận không kể xiết. Lúc tạo request thì hò hét giục giã liên hồi. Lúc làm xong thì bặt vô âm tín, chẳng một lời cảm ơn, công lao không ai nhắc đến. Đấy còn là công việc trơn tru, rủi thay có lúc xử lý không kịp trễ nải là lập tức bị báo cáo report.
Đấy nói chuyện hồi trước có chú kĩ sư mới vào kinh nghiệm còn non nên lỡ tay Server Reboot, để team mang tiếng xấu là Server Reboot Engineer. Âu cũng là trẻ người non dạ, nên mới bước sa cơ lỡ tay đánh máy.
Chuyện vài tháng đã trôi qua, tưởng chìm vào quên lãng thì ngờ đâu họa vô đơn chí, phúc bất trùng lai. Anh SRE truy cập vào database mongodb của server với quyền admin. Thực chất chỉ là check lại dữ liệu, nào ngờ trong lúc xuất kì bất ý, có lẽ là do tâm trạng đang xốn xang vì corona virus, mà song thủ ra 1 chiêu hiểm độc
db.users.drop()
1 lệnh bay ra như mũi tên bắn khỏi dây cung, làm sao lấy lại được. Vây là toàn users data bay luôn trong vòng 1 nốt nhạc. Anh kĩ sư mặt như chàm đổ, không rét mà run, toàn thân lạnh toát. Chuyện xảy ra vào giờ Ngọ, vào lúc ban trưa, mọi người đang ăn cơm nghỉ ngơi.
Hoảng hồn báo vội cho Team Lead để vào cuộc xử lý sự cố. Tuy nhiên các hệ thống lớn luôn luôn có cơ chế disaster recovery. Các database server trên aws luôn được thiết lập chế độ multi-AZ kèm snapshot theo chu kì. Ngoài ra trên server mongo còn có cron job chạy autoback up


# cat /etc/crontab


# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  | .---------- day of month (1 - 31)
# |  | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  | | |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  | | |  |
# *  * * *  * user-name  command to be executed


# START managed zone: mongo backup -DO-NOT-EDIT-
# dump mongo once a day for dev/qa/uat env at 8pm EST
10 1 * * * root /data/bin/database_backup.py 7 > /tmp/log.out 2>&1
# END managed zone: mongo backup --
Ngoài ra còn có 1 server backup dạng master lưu tất cả các bản backup của database, nên khi có sự cố chỉ việc chạy lệnh phục hồi. Hệ thống lớn như vậy lẽ nào dễ sụp đổ??
Server mongodb này được build dưới dạng cluster, gồm 1 primary database và nhiều read replicas
Cho nên chỉ trong vòng 30 phút, bản backup đã được tìm thấy trong server backup. Runbooks phục hồi hệ thống cũng đã sẵn sàng. Sau khi check database này không sử dụng kĩ thuật sharding
rs0:PRIMARY> db.printShardingStatus()
printShardingStatus: this db does not have sharding enabled. be sure you are connecting to a mongos from the shell and not to a mongod.
rs0:PRIMARY>
Nếu không thì phải làm như vầy
Sau khi test thử data trong local chạy ổn định, anh kĩ sư trong sử ra 1 chiêu database restore 
/opt/mongo/bin/mongorestore  --ssl --host $HOSTNAME:27017 --db users <folder backup>/users
Data đã phục hồi chỉ trong 1 nốt nhạc, không ảnh hưởng lớn đến công việc.
Nhưng hận thay lúc gian nan, hoạn nạn mới biết con người. Internal chưa kịp xử lý thì external đã có kẻ báo cáo lên trên. Ấy gọi là lúc có công thì cho người khác hưởng, nhưng lúc hiểm nguy là phải gánh mọi tội tình. Âu cũng là mình làm mình chịu, giang hồ hiểm ác, lòng người thâm sâu nào thể trách ai

Đăng nhận xét

2 Nhận xét

  1. Anh ơi em là sinh viên , nếu dùng aws để deloy ứng dụng thì mỗi tháng hết bao nhiêu tiền ạ, trên ytb có seri hướng dẫn aws của AWS-GSViec học xong có deloy được code lên ko ạ

    Trả lờiXóa
  2. còn phụ thuộc infra của em thế nào, dùng những dịch vụ gì , bao nhiêu EC2...

    Trả lờiXóa