Change background image
LOVE quotion

Bắt đầu từ 4.53' thứ Hai ngày 17/10/2011


You are not connected. Please login or register

Xem chủ đề cũ hơn Xem chủ đề mới hơn Go down  Thông điệp [Trang 1 trong tổng số 1 trang]

DuyHung
DuyHung Xuất sắc

Cấp bậc: Xuất sắc

Giới tính : Nam

Bài viết : 1260

Danh vọng : 2272

Uy tín : 32

SysAdmin Day năm nay đổi tone - mình sẽ chuyển đến các bạn bài viết Sập Server có phải muôn đời của blogger Phạm Huy Hoàng

SysAdmin Day - ngày Quản trị Hệ thống 2020 Server13

Phần 1: Làm gì khi hệ thống sập bất ngờ – xách quần lên công ty

Một chiều thứ 6 đẹp trời nọ, Hùng đang thư thả về nhà, dắt gấu đi chơi cuối tuần, đi ăn khuya. Ăn uống no say, Hùng dắt gấu vào nhà nghỉ (tất nhiên là chỉ để nghỉ thui nha, blog này cho cả các bạn chưa đủ 18 tuổi).

Vào đến nhà nghỉ, Hùng vừa mới tuột quần, chuẩn bị… chạy thẳng vào toilet (chắc do nồi lẩu vừa ăn không sạch lắm). Bỗng dưng, di động reo, anh Sơn team leader trên công ty réo: Hùng ơi, hệ thống sập con bà nó rồi, khách hàng không vào được trang chủ, em lên công ty phụ anh và anh Kha kiểm tra với.

Vội vàng chưa kịp mặc quần, bỏ gấu nằm bơ vơ trong khách sạn, Hùng bắt vội chiếc Grab chạy thẳng lên công ty để tìm lỗi…

SysAdmin Day - ngày Quản trị Hệ thống 2020 795-110

Vui chơi nhưng không quên nhiệm vụ, hãy như Hùng!

Hệ thống sụp là chuyện… bất khả kháng!



Câu chuyện này tuy không có thật, nhưng hẳn sẽ rất quen thuộc với những anh em SysAdmin/DevOps, anh em làm product và startup.

Hệ thống nào dù to đến nhỏ, trong quá trình chạy thể nào chả có vài lần xì hơi sổ mũi, nhẹ thì server bị down từ vài phút đến vài giờ, nặng thì … bay luôn database, mất sạch dữ liệu.

Nói thật, chúng ta không thể nào phòng chống 100% chuyện “sập bất ngờ” này. Đến AWS/Google cũng có lần bị down, khiến vài chục công ty khốn đốn; Gitlab cũng có lần xoá nhầm DB, mất 18h để khôi phục.

SysAdmin Day - ngày Quản trị Hệ thống 2020 Aws-re10

Có lần AWS toang tới mức cái trang show incident status cũng... sập luôn!!

Do vậy, ta chỉ còn cách “sống chung với lũ”, sẵn sàng giải quyết khi hệ thống có vấn đề. Trong bài viết này, Hoàng sẽ chia sẻ 1 số kinh nghiệm khi hệ thống bị sụp nha.

Chuyện của Hùng (phần cuối)


Quay lại câu chuyện của Hùng. Sau khi vác đít chạy lên công ty, Hùng thấy anh Sơn Lead và Kha DevOps đã ở đấy. Hai người kiểm tra Database, kiểm tra network nhưng không thấy lỗi đâu.

Hùng bật log của web server lên, thấy toàn trả về 500. Truy vết 1 hồi, thì lòi ra là do chức năng recommend sản phẩm của công ty có dùng API của bên thứ 3. Nhưng do… chưa thanh toán tiền nên API họ quăng lỗi vì hết limit free, code của bên Hoàng lại… quên xử lý trường hợp đấy nên crash.

Do tối, cả sếp lẫn kế toàn đều nghỉ, Hùng và anh lead quyết định tắt tạm chức năng này, không gọi API nữa, chỉ trả về danh sách trống. Sau khi sửa và deploy, hệ thống hoạt động lại bình thường.

SysAdmin Day - ngày Quản trị Hệ thống 2020 D7bdjg10

Chuyện tiền nong là 1 trong những lý do khiến hệ thống crash nhiều nhất!

Thở phào nhẹ nhõm, Hùng vội bắt taxi quay lại khách sạn, lấy quần và dắt gấu về. May quá, cả gấu lẫn quần vẫn còn đó, chưa bị ai ôm đi mất. Hùng thở phào nhẹ nhõm lần 2. Hết chuyện!

Đấy, câu chuyện của Hùng có kết thúc khá có hậu. Nhưng không phải anh em nào cũng may mắn như vậy. Do vậy, Hoàng chia sẻ một số kinh nghiệm xử lý khi hệ thống bị sụp nhé.

Những việc cần làm khi hệ thống bị sụp


1. Hết sức bình tĩnh!

Với các hệ thống quan trọng, chỉ cần hệ thống sụp 1 giờ, công ty sẽ thiệt hại cả trăm triệu đồng, sụp 1 ngày là cả tỉ đồng. Do vậy, anh em rối và sợ là điều tất nhiên.

Tuy vậy, việc áp lực và hoảng loạn sẽ làm anh em rối trí, khó tìm được cách giải quyết phù hợp. Đôi khi “làm đại” sẽ còn gây ra hậu quả nghiêm trọng hơn.

Do vậy, đầu tiên ta phải hít sâu, thở nhẹ cho bình tĩnh rồi mới tiếp tục nhé!

2. Khôi phục hệ thống trước, điều tra sau

Trên lý thuyết, khi tìm được nguyên nhân làm hệ thống sụp, ta sẽ tìm được cách giải quyết đúng hơn, hợp lý hơn. Trên thực tế, đôi khi việc này sẽ tốn nhiều thời gian hơn, ảnh hưởng tới hình ảnh/doanh thu công ty.

Do vậy, người ta thường khôi phục hoạt động của hệ thống trước, rồi mới tìm nguyên nhân sau. Việc này giúp bạn có thêm thời gian để debug, tìm nguyên nhân.

Một số cách làm phổ biến:

  • Nhiều khi chỉ cần restart server là đã giải quyết được phần lớn vấn đề

  • Nếu gần đây có deploy bản mới của code, nhiều khả năng lỗi là do bản mới. Rollback lại code về phiên bản trước đó có thể giải quyết được

  • Trường hợp xấu nhất, thay vì để server crash, có thể để 1 thông báo “Hệ thống đang bảo trì" .v.v... để hiện cho người dùng


SysAdmin Day - ngày Quản trị Hệ thống 2020 A27a5910

Đôi khi chỉ cần restart server là đã sửa được 69.96% các lỗi!

3. Thu thập dữ liệu để “điều tra”

Nếu xui xẻo hơn, bạn không có cách nào để phục hồi hệ thống nhanh chóng, bạn sẽ phải tìm hiểu nguyên nhân gây lỗi và fix.

Quá trình này cũng giống như fix bug vậy, nhưng phải vừa chạy vừa fix. Theo kinh nghiệm của Hoàng, đây là những thứ các bạn có thể “Điều tra”:

  • Nhờ người dùng chụp màn hình bị lỗi, xem có gì lạ

  • Nếu có dùng các tool như Sentry/LogRocket, lên đó kiểm tra xem có exception nào lạ lạ hay không

  • Kiểm tra log hệ thống để tìm lỗi, kiểm tra các công cụ monitoring xem CPU/RAM có tăng đột biến hay không

  • Nếu dùng Cloud thì lên Dashboard xem có warning gì lạ, có lỗi gì lạ hay không (AWS ngỏm, Google Cloud tèo).

  • Kiểm tra service của các bên thứ 3 tích hợp với hệ thống có lỗi gì không, nhiều khi do lỗi của bên họ!


SysAdmin Day - ngày Quản trị Hệ thống 2020 Keep-c10

Nhắc lại, nhớ bình tĩnh mà điều tra nhen!

4. Cập nhật tình hình cho stakeholder

Khi hệ thống sụp, người sốt ruột nhất thực ra không phải là bạn mà là … sếp của bạn, hoặc sếp của sếp của bạn. Vì vậy, bạn nên báo cáo, cập nhật tình hình cho sếp, chứ đừng im im mà làm kẻo họ sốt ruột.

Bạn chỉ cần báo cáo tiến độ, dự đoán thời gian, thiệt hại:


  • Đã khôi phục được DB, người dùng không ảnh hưởng gì, tầm 1 tiếng nữa xong | Không khôi phục được DB gần nhất, sẽ mất toàn bộ dữ liệu tháng này.

  • Đã tìm ra nguyên nhân gây lỗi, team dev đang nghĩ cách fix

  • Team dev đang test cách fix, sẽ deploy trong vòng 15 phút nữa | Bug khó hơn dự tính, sẽ mất tầm 2-3 tiếng để fix và khôi phục dữ liệu


Những báo cáo này không mất quá nhiều thời gian, nhưng sẽ giúp sếp của bạn có cái mà báo cáo, và các sếp trên cũng đỡ… sốt ruột.

Tạm kết


Ở phần 1, Hoàng đã chia sẻ với các bạn một số kinh nghiệm xương máu để xử lý khi hệ thống bị sập. Hi vọng chúng sẽ giúp các bạn tự tin, đỡ căng thẳng để xử lý khi… server sập thật nhé!

Nếu trong quá trình đi làm, đã từng gặp tình trạng như vậy, hãy comment chia sẻ cách bạn xử lý cho bà con biết nha!
Ở phần 2, Hoàng sẽ chia sẻ cách viết post-mortem, nhìn lại lý do hệ thống bị lỗi, tìm cách rút kinh nghiệm và cải thiện nha!
      
DuyHung
DuyHung Xuất sắc

Cấp bậc: Xuất sắc

Giới tính : Nam

Bài viết : 1260

Danh vọng : 2272

Uy tín : 32

SysAdmin Day - ngày Quản trị Hệ thống 2020 Photo-26

Phần 2: Cách viết POST-MORTEM, nhìn lại vấn đề sau khi xử lý xong sự cố

Ở kì trước, chúng ta đã cùng bạn Hùng xấu số tìm ra lỗi, khôi phục hệ thống chạy lại như thường. Ở kì này, chúng ta sẽ cùng tìm hiểu về những điều chúng ta nên làm, cách viết post-moterm sau khi sự cố xảy ra nha.

Những điều này tuy nhỏ nhưng vô cùng quan trọng, vì nó giúp chúng ta tránh được những sai lầm tương tự trong tương lại đấy.

Post-mortem là cái chi chi?


Nếu coi mỗi lần sập server là một vụ án mạng, tìm bug là quá trình điều tra, sửa bug là quá trình truy bắt hung thủ; thì việc post-motern chính là việc… viết cáo trạng, tóm tắt lại nguyên do án mạng, động cơ gây án, thủ phạm, nạn nhân, .v.v...

Nói tóm lại, sau khi xử lý xong sự cố, chúng ta sẽ viết post-mortem ghi rõ những gì đã xảy ra, nguyên nhân server bị sập, thiệt hại về người và của, cách xử lý, cách phòng chống, .v.v...

SysAdmin Day - ngày Quản trị Hệ thống 2020 Photo-25

Post-mortem giống như 1 bản cáo trạng về nguyên do, hung thủ gây ra án mạng

Tại sao lại phải viết post-mortem?


Ủa, cái gì qua rồi thì cho nó qua đi, còn nhắc lại quá khứ đau thương  mà làm gì?

Sai rồi, đằng sau mỗi lần hệ thống bị sụp là một… sai lầm của team (chưa test code, chạy script ẩu). Nếu như không có post-mortem, không nhìn lại sai lầm, không nghĩ cách cải thiện, thì những sai lầm này sẽ vẫn tiếp tục xảy ra nữa.

Chưa hết, viết post-mortem còn để cho team và các thành viên mới nhìn lại, để thấy sai lầm trong quá khứ, tránh lập lại ở tương lai. Ta cũng có thể viết post-mortem cho khách hàng/cấp trên, để họ hiểu hơn về lý do sập, cũng như tin tưởng chúng ta hơn khi thấy ta có các biện pháp phòng chống.

SysAdmin Day - ngày Quản trị Hệ thống 2020 Learn-10

Không biết về lỗi lầm trong quá khứ, ta sẽ lặp lại chúng ở tương lai!

Quay lại chuyện của Hùng, sau khi viết post-mortem, cả team nhìn lại mới thấy nguyên nhân sâu xa hơn là: Không ai quản lý tiền bạc/credit khi tích hợp với API bên thứ 3.

Tra kĩ hơn, hệ thống còn dùng Twillio để gửi SMS và SendGrid để gửi email, nhưng đã nợ tiền gần 1 tháng. Nếu không trả tiền thì tầm 1-2 tháng nữa là chức năng gửi SMS/Email sẽ… ngừng hoạt động luôn.

May thay, anh lead nhắn 1 phát để bên accounting thanh toán, rồi tạo task để nhắc nhở thanh toán 3 tháng/lần là xong. Mọi thứ lại chạy ngon lành.

Đừng đổ lỗi, đừng tìm thủ phạm, hãy tìm vấn đề


Điều quan trọng nhất khi viết post-mortem là: Ta viết ra để học, để rút kinh nghiệm, chứ không phải để trù dập hay đổ lỗi cho ai đó.

Có nhiều công ty rất lạ, có vấn đề thì cứ lo tìm người code lỗi, lôi người để sót bug ra chỉ trích trước. Đây là 1 nét văn hoá cực kì có hại, dễ ảnh hưởng đến tinh thần cả team.

Theo mình, 1 sự cố xảy ra là lỗi của cả team. Khi có vấn đề thì cùng nhau sửa, chứ không phải chỉ chăm chăm tìm ra thủ phạm! Văn hoá này giúp anh em tin tưởng lẫn nhau, làm việc thoải mái hơn.

Lúc viết post-mortem cũng thế, thủ phạm trong post-mortem chính là bug, là thiếu sót trong qui trình; chứ không phải là bạn Hùng code ẩu, hay bạn Kha quên test case A, B, C; hay do bạn Sơn chạy nhầm script xoá sạch database.

SysAdmin Day - ngày Quản trị Hệ thống 2020 Finger10

Chỉ trích lẫn nhau không phải là cách hay ho để giải quyết sự cố!

Đơn cử như có vụ bạn engineer bên AWS chạy script làm đi tong vài con server. Mới đầu, ta tưởng thủ phạm là bạn engineer đó, nhưng nhìn kĩ hơn, ta sẽ nhìn ra vấn đề thật sự:


  • Lỗi qui trình: Script quan trọng vậy tại sao không có code review trước khi chạy?
  • Lỗi hệ thống: Khi server bị xoá tại sao không ai biết?
  • Lỗi kĩ thuật: Tại sao không thể restore lại các server khi bị xoá. Tại sao backup lại mất vài tiếng mới chạy được.


Các bạn thấy đấy, tìm ra tận gốc vấn đề sẽ giúp ta phòng tránh chúng trong tương lại.

Vậy, viết post-mortem như thế nào cho đúng?


Một bản post-mortem chuẩn thường bao gồm những phần sau:


  • Timeline: Dòng thời gian những chuyện đã xảy ra (lúc mấy giờ sự cố xảy ra, bao lâu khách hàng phát hiện, lúc mấy giờ khôi phục).
  • Ảnh hưởng: Những ai bị ảnh hưởng, trong bao lâu, thiệt hại về người và của là bao nhiêu?
  • Cách khôi phục: Team đã khôi phục hệ thống như thế nào, mất bao lâu, có gặp rắc rối hay khó khăn gì?
  • Tìm hiểu nguyên nhân: Nguyên nhân gây ra sự cố là gì? Đừng chỉ quan tâm nguyên nhân bề mặt, mà hãy đào sâu, tìm hiểu những sai sót trong qui trình làm việc, thiết kế hệ thống.
  • Cách phòng chống: Những biện pháp mà team đã làm/sẽ làm để tránh xảy ra vấn đề tương tự trong tương lai


Hầu như các công ty lớn đều bị… sập server có đôi vài lần. Đa phần họ đều công khai bản post-mortem cho khách hàng đọc nên các bạn có thể tham khảo và viết theo nha:



SysAdmin Day - ngày Quản trị Hệ thống 2020 2019-010

Công ty lớn vẫn có lúc sập server hoặc outage như thường

Note nhẹ: Các bản post-mortem này viết cho đối tượng là user/khách hàng nên không đi quá sâu vào chi tiết hệ thống. Khi viết post-mortem cho team mình, bạn có thể đi sâu vào hệ thống, services, code, qui trình của team nha.

Tạm kết


Ở phần này, Hoàng đã chia sẻ với các bạn việc cần làm sau khi hệ thống sụp. Mình cũng chia sẻ cách viết post-mortem thế nào cho phù hợp.

Tất nhiên, những việc như khôi phục hệ thống, viết post mortem chỉ là việc… chữa cháy. Ông bà ta đã dặn phòng bệnh hơn chữa bệnh. Một team engineer giỏi là một team giữ cho hệ thống hoạt động ổn định, không bị sập, nhờ có các biện pháp phòng chống.

Do vậy, ở phần 3, Hoàng sẽ chia sẻ những biện pháp phòng chống này. Các bạn có thể áp dụng để giúp hệ thống ổn định và khoẻ mạnh hơn nha.
      
DuyHung
DuyHung Xuất sắc

Cấp bậc: Xuất sắc

Giới tính : Nam

Bài viết : 1260

Danh vọng : 2272

Uy tín : 32

SysAdmin Day - ngày Quản trị Hệ thống 2020 58925610

Phần 3 - Phương pháp phòng chống - ngủ ngon không lo Server sập

Ở 2 phần trước, Hoàng đã chia sẻ về những việc cần làm khi hệ thống sập bất ngờ, nên viết post motern như thế nào để tránh gặp phải những sai lầm tương tự.

Tuy vậy, như các cụ đã nói “phòng bệnh hơn chữa bệnh”, phòng chống hệ thống sập thì tốt hơn là chờ hệ thống tèo rồi mới sửa chứ nhỉ. Do vậy, ở kì này, Hoàng sẽ chia sẻ những kinh nghiệm phòng chống nhé.

Tại sao không nên chờ “nước đến chân mới sửa”?


Phần đông những hệ thống của doanh nghiệp, của các công ty lớn đều có một cái gọi là SLA (Service-Level Agreement). Nói nôm na, nó là 1 bản cam kết chất lượng dịch vụ.

Thông thường, trong SLA, các dịch vụ đều phải high availbility tầm 99.9% hoặc 99.99%, tức là 1 tháng chỉ được sập tầm 5 phút (99.99) hoặc hoặc 45 phút (99.9%). Nếu thời gian sập quá mức này, vi phạm SLA, đơn vị cung cấp sẽ bị mất uy tín, đồng thời phải bồi thường 1 khoản không hề nhỏ.

SysAdmin Day - ngày Quản trị Hệ thống 2020 Ska10

Các hệ thống lớn sẽ đòi SLA tầm 99.9 tới 99.99%

Vì vậy, nếu chờ hệ thống sập rồi mới sửa thì gần như không kịp! Mấy anh dev phải nghĩ cách phòng chống, tìm bệnh trước, để có thể sửa chữa hệ thống khi nó mới hắt hơi/sổ mũi, chứ không đợi tới lúc nó ngủm luôn nha!

Làm sao để anh em ngủ ngon, không lo server sập


Đây là những kinh nghiệm xương máu, rút ra từ mồ hôi nước mắt các thế hệ sysadmin/developer/devops ở các công ty nha.

Có hệ thống failover

Failover là 1 trong những biện pháp cơ bản nhất, đơn giản nhất để tránh server sập. Nói đơn giản, failover system tức là 1 hệ thống… dư thừa, chạy song song với hệ thống chính.

Khi hệ thống chính bị sập, ta sẽ tự động chuyển người dùng qua hệ thống failover này, để tránh làm gián đoạn dịch vụ. (Giống như khi các bạn đi mát xa, mấy em nhân viên đẹp bị nghỉ ốm, failover sẽ là mấy em nhân viên ế khách ra phục vụ các bạn vậy á).

Đa phần các database có hỗ trợ failover qua cơ chế master/slave. Khi master có vấn đề thì slave sẽ được promote lên làm master. Ở tầm webserver, ta thường dùng load balancing để cân bằng tải trong 1 cluster nhiều server, 1 server sụp cũng không ảnh hưởng hệ thống.

Cách này khá hiệu quả, nhưng có thể sẽ khá… tốn kém, vì ta phải bỏ chi phí bảo trì, vận hành thêm hệ thống phụ mà không dùng tới.

SysAdmin Day - ngày Quản trị Hệ thống 2020 Diagra10

Có database failover để thay thế khi database chính bị ngỏm

Có monitoring, notification khi thấy có điều bất thường

Thông thường, một hệ thống sập sẽ có 1 số dấu hiệu bất thường trước khi sập. Do vậy, ta phải setup monitoring, có dashboard để dễ dàng nhận thấy những bất thường trong hệ thống.

Thông thường, người ta hay monitor những thứ như CPU/RAM, dung lượng ổ cứng. Nếu là web thì họ sẽ monitor thêm số lượng API được gọi, thời gian API chạy, status trả về là 200 hay 500. Ở tầm cao hơn thì họ monitor những thứ thực tế như số cuốc xe đặt trong 10 phút, số đặt phòng trong 1 giờ, .v.v...

Với vô số những thứ cần monitor như vậy, ta cần có 1 cái dashboard để dễ dàng quan sát tình hình chung. Tất nhiên, không phải ai cũng rảnh mà ngồi nhìn dashboard cả ngày, nên ta sẽ phải setup 1 số notificaiton luôn.

SysAdmin Day - ngày Quản trị Hệ thống 2020 Dashbo10

Nên có 1 cái dashboard cool ngầu như thế này để quan sát hệ thống

Ví dụ, khi CPU/RAM lên quá cao, hoặc khi lượng order tụt xuống nhiều, hệ thống sẽ notify bằng cách gửi SMS/email đến mấy anh DevOps để họ vào kiểm tra, trước khi người dùng phát hiện. Khi cần, hệ thống cũng có thể tự recover bằng cách tăng thêm instance, restart server, .v.v...

Tất nhiên, notify quá nhiều sẽ làm chúng ta… lờn mặt, bỏ qua notification. Do vậy, phải làm một thời gian chúng ta mới biết nên theo dõi những thông số gì, notify khi nào nha.

Backup dữ liệu thường liệu – nhớ diễn tập restore

Hệ thống sập thì có thể chạy lại được. Nhưng dữ liệu mà mất là coi như… công ty đi đứt. Do vậy, việc lưu trữ, backup dữ liệu là vô cùng quan trọng!

Nếu công ty bạn sử dụng Cloud, đa phần các dịch vụ database đều đã có tự động back-up/recovery, chỉ cần tốn thêm phí là xong. Nếu tự chạy, các bạn nên có script backup mỗi ngày, mỗi tuần hoặc… mỗi giờ nếu cần thiết!

Ngoài ra, điều quan trọng hơn là… phải kiếm tra xem dữ liệu đã back-up đấy có đúng không, có restore lại được hay không! Hoàng thấy có nhiều chỗ back-up dữ liệu cả năm nhưng… chưa restore bao giờ, tới lúc cần restore thì mới thấy restore rất chậm, tool restore bị lỗi, dữ liệu back-up bị thiếu.

Do vậy, có back-up là tốt, nhưng phải nhớ kiểm tra xem back-up đó có hoạt động được hay không nhé.

SysAdmin Day - ngày Quản trị Hệ thống 2020 Sql-da11

Đôi khi tới lúc cần, back-up lại không chạy được mới sml nha ahihi!

Test đủ, test kĩ, deploy dần dần

Đương nhiên, nếu hệ thống sụp là do bug, do lỗi của developer, thì để hệ thống ổn định, chúng ta phải tìm cách phát hiện, tiêu diệt những bug này trước khi hệ thống lên production.

Các bạn tester sẽ test để tìm lỗi hệ thống. Tuy vậy, khi hệ thống lớn, nhiều tính năng, việc test này sẽ vô cùng mất thời gian.

Do vậy, người ta thường dùng unit test để test code, kết hợp với automation test để test toàn bộ hệ thống. Thông thường, trước khi code được merge, được deploy lên staging, các test này sẽ được chạy để đảm bảo hệ thống không bị lỗi.

Ngoài ra, phần đông nguyên nhân sự cố thường là do… developer sửa code (thêm tính năng mới, fix bug). Do vậy, người ta thường release bản beta/canary để một số người dùng test trước. Ở hệ thống web, họ cũng hay dùng feature flag để test tính năng mới ở 1 số người dùng/khu vực, trước khi phổ cập cho toàn bộ người dùng.

Nhờ cách này, nếu phiên bản beta, tính năng mới bị lỗi, số lượng người bị ảnh hưởng sẽ ít hơn rất nhiều! Team dev sẽ có thời gian chỉnh sửa cho phù hợp trước khi release bản chính thức.

Tạm kết


Phù, series này khá dài, cảm ơn các bạn đã chịu khó đọc đến hồi kết.

Trong bài này, Hoàng chỉ nói sơ 1 số biện pháp phòng chống, giữ cho hệ thống hoạt động ổn định thôi. Nếu nói chi tiết, chắc là phải mất vài cuốn sách + mấy khoá học vẫn chưa hết. Do vậy, các bạn có thể tìm hiểu thêm về high availability systemDevOps nha.

Lời cuối cùng của series: Nếu hệ thống của bạn có bị lỗi hay bị sụp, cũng đừng quá buồn, hay trách móc team mình. Hệ thống các công ty lớn còn có lúc sụp, nên của ta bị sụp cũng bình thường.

Hãy xem mỗi lần sụp là 1 lần được học hỏi, là cơ hội để ta làm hệ thống ổn định hơn nhé!
      
      

Xem chủ đề cũ hơn Xem chủ đề mới hơn Về Đầu Trang  Thông điệp [Trang 1 trong tổng số 1 trang]

Quyền hạn của bạn

Bạn không có quyền trả lời bài viết
free counters



  • Đoàn Ngọc Khánh

    mobile phone 098 376 5575


    Đỗ Quang Thảo

    mobile phone 090 301 9666


    Nguyễn Văn Của

    mobile phone 090 372 1401


    IP address signature
    Free forum | ©phpBB | Free forum support | Báo cáo lạm dụng | Thảo luận mới nhất