Tuesday, March 24, 2020

Hoa Sơn Luận code

Thần Code Sơn Trang, mười năm đã trôi qua
Tuyết bay trắng trời, gió thổi vi vu như cắt da cắt thịt. Cả 1 vùng tuyết sơn chìm trong sắc trắng, không khí lạnh lẽo thê lương
Một người đại hán tuổi chừng ba mươi, đang ngồi lặng lẽ bên máy tính, song thủ gõ phím lách cách, mục quang sáng ngời đang chăm chăm nhìn màn hình.
Thiếu chủ, đã canh hai rồi, sao người chưa đi ngủ
Một lão nô đầu tóc bạc trắng, tay bưng tách trà dâng lên

Người đại hán nó chính là Dương Cú Đơ, thiếu chủ của Thần Code Sơn Trang. 
Mười năm qua, từ ngày được Hắc Y Nhân truyền cho Coding thập tam thức trong cuốn Clean Code. Ta ngày đêm nghiên cứu thực hành, luyện tập trên cả codefight, hacker rank. Thời gian thoi đưa, đến giờ cũng đã làu thông, level của ta trên codefight cũng đạt hàng top rồi. Nhưng sao ta vẫn không thể ngộ hết được bí kíp này, không sao đạt được cảnh giới code lưu hỏa thuần thanh.
Thiếu chủ, ngài tuy luyện Clean Code trong mười năm, nhưng chủ yếu là bế quan ở Thần Code Sơn Trang này, không làm dự án thật, không tiếp xúc với các cao thủ coding trong thiên hạ. Khác gì có học mà chẳng có hành, kiếm báu đem ra bổ củi. Đâu thể đạt được đến mức coding guru, xuất thần nhập hóa được.Tôi nghe nói ở Thăng Long thành, cứ 5 năm một lần, có tổ chức “Hoa Sơn Luận Code” coding contest nơi người chơi ra tay viết code, diệt “bug”, đả bại testcase, từ đó phân định thiên-hạ-đệ-nhất lập trình, nơi các anh hùng coding trong thiên hạ tụ về, so tài cao thấp để tìm ra coding minh chủ. Sao thiếu chủ không đến đó thi triển tài năng, biết đâu không vang danh thiên hạ, lấy lại thanh danh cho Thần Code Sơn Trang chúng ta.
Dương Cú Đơ nghe xong như tỉnh cơn mê, nghĩ thầm
Hoa Sơn Luận Code, biết đâu ta sẽ tìm được cựu thù đã sát hại cả nhà ta năm xưa. Đúng là cơ hội tốt
Thiếu chủ, xưa kia lão trang chủ uy chấn giang hồ không chỉ là nhờ tài code đạo mà còn cò món bảo vật trấn trang được cất giấu bí mật. Nay thiếu chủ đang trưởng thành, lão nô xin trao lại cho người
Đây là vũ khí đứng đầu trong binh khí phổ, tên là Ô Nha Thử (black Mouse) và Ngọc Tịnh Bàn (Keyboard). Ngày xưa những kẻ

Share:

Devops ký sự (Phần 3)

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
Share:

Tuesday, March 17, 2020

VPN Warp+ 1.1.1.1 ver 5.0















Chỉ cần nhập key có luôn 270TB
Menu > Account > Key > Change key
Mình update key tất cả đều 270TB rồi
Bản 1.1.1.1 mới nhất ver5.0 mới có mục account
92zOE74W-eq4wV360-3Kt2u80v
GsE652x8-nW9SO463-J07N5yu3
h5DVN324-wS3M408E-hZ6V358A
4e512aFG-31N5f9zF-0Q27hNy9
8a0f4Fy7-6sm7I9j2-9Wc72s3G
CD3801Kp-54J68Xab-86yEw3N9
dxsI1095-841r2Fhb-35f6wP9h
5nc30g8j-c8tW217H-M690hm8o
0G2s5Zv8-v0V5n4f9-T3I7u54n
j20uKN14-El862N3y-586JQeH7
Rua84D97-3qWd659N-895G7BMn
31S8sle6-85Dk0nW6-3sV6H8h1
Share: