#217 - Lỗi hệ thống tại Slack và cách Dropbox chuẩn bị cho thiên tai
Trong số này, chúng ta tìm hiểu về:
Sự cố xảy ra tại Slack vào ngày 22 tháng 2.
DropBox đã kiểm tra hệ thống của mình đối phó với thiên tai như thế nào.
Mocker, giả lập hệ thống tại Grab.
Lời giải cho góc lập trình tuần trước: Longest String Chain.
Đề bài toán góc lập trình tuần này: LRU Cache.
Những bài viết hay
Vào ngày 22 tháng 2, tại Slack đã xảy ra một sự cố nghiêm trọng dẫn đến một số lượng lớn user không thể truy cập vào Slack (bao gồm cả tác giả của bài viết này).
Vào khoảng 6h sáng, Slack bắt đầu nhận được một số report từ user về sự cố khi kết nối với Slack, một số nhóm technical trong Slack cũng bắt đầu nhận được các cảnh báo về sự cố đang xảy ra.
Khi một user bắt đầu một phiên hoạt động mới trên Slack (sau khi khởi động lại máy hay ngắt kết nối khỏi network một thời gian), Slack client sẽ thực hiện một quá trình gọi là "booting" (được mô tả trong bài viết sau). Trong quá trình này, dữ liệu (danh sách các channel, user, team, nội dung hội thoại, v.v...) sẽ được tải về từ Slack server và được cache trên client. Slack sẽ không thể sử dụng cho tới khi quá trình boot được hoàn tất, nếu Slack không thể boot thì người dùng sẽ nhận được một "error page".
Ở thời điểm ban đầu của sự cố, lượng tải trên database system tăng lên nhiều hơn bình thường. Slack lưu trữ dữ liệu tại Vitess, một horizontal scaling system MySQL. Vitess hỗ trợ keyspace, các logical database. Các table khác nhau trong một keyspace sẽ được shard bởi các key khác nhau. Trong quá trình sự cố xảy ra, một keyspace tại Vitess đã trở nên quá tải một cách nghiêm trọng (keyspace này chứa thông tin về channel membership, được shared bởi user).
Đâu là nguyên nhân khiến Slack đi từ trạng thái hoạt động ổn định sang bị quá tải? Câu trả lời nằm ở những tương tác phức tạp giữa các ứng dụng, Vitess datastore, hệ thống caching, và hệ thống service discovery.
“Các hệ thống phức tạp chứa các lỗi tiềm ẩn bên trong chúng. Sự phức tạp của các hệ thống này khiến chúng không thể chạy mà không có những lỗ hổng này. Bởi vì những yếu tố này không đủ để gây ra hỏng hóc nên chúng được coi là những yếu tố phụ trong quá trình vận hành. Việc loại bỏ tất cả các lỗi tiềm ẩn này không chỉ bị giới hạn bởi chi phí kinh tế mà còn vì thực tế rất khó để thấy được những lỗi đó có thể góp phần gây ra một sự cố như thế nào.”
Mời các bạn cùng đọc bài viết sau.
(by lpv)
That time we unplugged a data center to test our disaster readiness
Ngày 18 tháng 11 năm 2021 là một ngày bình thường như bao ngày khác tại Dropbox. Tuy nhiên một điều đặc biệt đã xảy ra vào ngày hôm đó. Vào khoảng 5h chiều, một nhóm kỹ sư đã rút phích cắm vật lý tại Data Center San Jose, qua đó ngắt kết nối Data center với phần còn lại của Dropbox network.
Trong một thế giới mà thiên tai ngày càng phổ biến, điều quan trọng là chúng ta cần phải xem xét các tác động tiềm tàng của những sự kiện như vậy đối với Data center. Từ quan điểm sẵn sàng với thiên tai, điều này có nghĩa là đảm bảo Dropbox không chỉ đo lường rủi ro, mà còn thực hiện các chiến lược để giảm thiểu rủi ro đó.
Sau khi thực hiện migrate từ AWS vào 2015, Dropbox đã tập trung nhiều data tại San Jose. Mặc dù metadata được replicate qua nhiều datacenter tại các vùng khác nhau, nhưng thực tế San Jose vẫn là nơi mà hầu hết các dịch vụ bắt nguồn và trưởng thành. Do San Jose nằm gần đứt gãy San Andreas, điều quan trọng là cần đảm bảo được ngay cả khi một trận động đất xảy ra cũng sẽ không làm cho Dropbox "offline".
Một thông số quan trọng để đảm bảo với khách hàng sự chuẩn bị sẵn sàng với các sự cố, là Recovery Time Objective (RTO). RTO đo lường khoảng thời gian mà hệ thống cần để phục hồi sau một sự kiện thảm khốc. Trong nhiều năm, Dropbox đã làm việc liên tục để giảm RTO để chuẩn bị cho các thảm họa tiềm ẩn, bao gồm cả động đất.
Với nhóm Disaster Readiness (DR) dẫn đầu, đỉnh điểm chính là việc rút phích cắm theo đúng nghĩa đen tại Data center San Jose, Dropbox đã có thể giảm RTO của mình hơn một bậc.
Và đây là câu chuyện về cách họ đã làm điều đó như thế nào, mời các bạn cùng đọc.
(by lpv)
Mockers - Overcoming Testing Challenges at Grab
Vào năm 2018 tại Grab có khoảng hơn 250 microservices trong hệ thống backend. Việc đảm bảo một hệ thống có thể thay đổi dễ dàng và không ảnh hưởng tới những hệ thống xung quanh đòi hỏi hệ thống đó phải được kiểm thử thường xuyên và đảm bảo tính đúng đắn của hệ thống.
Với sự giới hạn của hệ thống kiểm thử trên môi trường staging hiện tại mà họ gặp phải trong mỗi lần phát hành phiên bản mới và sữa lỗi, đội ngũ kỹ sư của Grab đã giới thiệt ra Mockers, một Go SDK kết hợp với CLI tool để có thể quản lý tập trung và giả lập hệ thống một cách dễ dàng và nhanh chóng, tiết kiệm được thời gian và làm tăng khả năng mở rộng.
Mockers sẽ tạo ra các mock server cho cả các microservice sử dụng HTTP và gRPC. Để setup một mock server cho HTTP microservice cần cung cấp API Swagger specification. Với một gRPC mock server, bạn cần cung cấp các file protobuf.
Những lợi ích mà Grab đã đạt được sau quá trình chuyển từ Conventional Testing qua Mockers như sau:
Tự động xác minh API contract giúp cho phát hiện sự thay đổi contract kịp thời.
Kiểm tra khả năng phục hồi với những yêu cầu ngoài hệ thống như giả lập gọi sự kiện không thành công hoặc fallback 1 cách dễ dàng.
Không phải tập trung vào việc duy trì mock data khi một microservices thay đổi, chỉ cần cập nhật thông qua một lệnh đơn giản.
Đơn giản hoá quá trình kiểm thử cho service mới qua đó có thể mở rộng hệ thống.
Mời các bạn cùng đọc bài viết sau để tìm hiểu nhé.
(by sonnv)
Here’s Bill Gates’s Advice to New Programmers. It Should Not be Ignored
Hành trình của một lập trình viên là một hành trình đầy hấp dẫn. Đó là một chặng đường dài và gian khổ, đầy thử thách và gian nan. Khi mới bắt đầu, bạn chắc chắn sẽ gặp phải nhiều chướng ngại vật trên đường đi. Việc học ngôn ngữ lập trình đầu tiên của bạn có thể khó khăn và dễ dàng khiến bạn nản lòng nếu bạn không chắc mình đang làm gì.
Tuy nhiên, nếu bạn cần vài lời khuyên từ một người biết một hoặc hai điều về lập trình, thì bạn không thể không lắng nghe từ Bill Gates. Khi ông ấy có điều gì đó để nói, cả industry sẽ dừng lại và lắng nghe. Đó là lý do tại sao bạn không nên bỏ qua lời khuyên của ông ấy dành cho các lập trình viên mới vào nghề.
Hãy cùng tác giả của bài viết hiểu rõ hơn về những điều mà Bill Gates chia sẻ:
- Don’t Overthink, Just Dive In: Đừng suy nghĩ quá nhiều, chỉ cần đi sâu vào
- Know Your Tools Well — Really Well: Hãy hiểu thật rõ về công cụ của bạn
- Get Good at Reading the Code: Hãy đọc code thật giỏi
- Learn To Make Things as Simple as Possible: Học cách biến mọi thứ trở nên đơn giản nhất có thể
- Learn to Work In The Group: Học cách làm việc theo nhóm
- Visualize First Then Create It: Hình dung trước rồi tạo điều gì đó
- Know the Joy of Creating Something: Biết niềm vui khi tạo ra thứ gì đó
(by maison)
Góc Lập Trình
Đề ra tuần này: LRU Cache
Lời giải đề bài tuần trước: Longest String Chain
Đây là một bài toán mở rộng của bài toán quy hoạch động kinh điển dãy con tăng dài nhất Longest Increasing Subsequence (gọi tắt là LIS).
Gọi L(i) là độ dài dãy con tăng dài nhất ở vị trí i. Công thức đệ quy cho bài toán LIS là:
L(1) = 1L(i) = (1, L(j)+1)với mọi j thỏa mãn:0 < j < ivàA[j] < A[i]
Nếu bạn đọc đã biết đến bài toán trên, thì sẽ nhận thấy lời giải của bài toán này chỉ khác với bài toán LIS ở bước kiểm tra A[j] < A[i]. Thay bước kiểm tra này bằng bước kiểm tra “word[i] có phải là chuỗi tiền nhiệm (predecessor) của word[j]” hay không, ta sẽ có được lời giải của bài toán. Tuy nhiên lưu ý đối với bài toán này, có thể thay đổi thứ tự của các phần tử trong dãy, nên trước tiên ta phải sắp xếp lại mảng đầu vào theo thứ tự tăng dần. Giải thuật cho lời giải trên như sau: https://pastebin.com/a2J65sW3
Lời giải trên có độ phức tạp là O(S*N^2) với N là độ dài của mảng words, S là độ dài lớn nhất của phần tử trong mảng.
Để ý kỹ hơn, trong bài toán này, ở mỗi bước lặp, ta không bắt buộc phải duyệt tất cả các phần tử từ j = 0 đến i - 1, mà chỉ cần kiểm tra xem có phần tử words[i] nào trước đó là predecessor của words[j] hay không, mà chỉ cần thay mảng L[i] bằng một bảng băm Map<String, Integer>, và thay việc duyệt j từ 0 đến i - 1 bằng việc duyệt tất cả các predecessor của words[j]. Độ phức tạp time complexity của toàn bộ giải thuật là O(NlogN). Mời bạn đọc tham khảo chi tiết cài đặt lời giải trên tại đây: https://pastebin.com/DVm6LrnE
Code & Tools
ML For Beginners: Một repo chứa chương trình giáo dục của Azure Cloud Advocates tại Microsoft cho người mới bắt đầu học Machine Learning
mongo-rocks: Một repo chứa module cho MongoDB với storage engine từ RocksDB
Góc Sponsors
Là một trong những siêu ứng dụng hàng đầu ở khu vực Đông Nam Á, Grab cung cấp đa dạng dịch vụ cho hơn 187 triệu người dùng tại 428 thành phố ở tám quốc gia. Tại Grab, chúng tôi tin rằng nhân tài chính là trái tim của công ty, vì vậy chúng tôi luôn cố gắng tạo ra một môi trường tuyệt vời để tối ưu hoá tiềm năng của các Grabbers.
Những lý do bạn sẽ thích làm việc ở Grab:
Đồng nghiệp thân thiện, chuyên môn cao.
Môi trường làm việc đa quốc gia, cân bằng giữa cuộc sống và công việc (work-life balance)
Được tham gia giải quyết các bài toán khó (high scale, high traffic), với nhiều impact (vài trăm triệu người dùng)
Lương tháng 13 + lương thưởng bonus theo hiệu quả công việc.
Rất nhiều khoá học training đào tạo nội bộ cũng như đào tạo được cung cấp bởi các đối tác như Microsoft, Amazon, ..
Hiện văn phòng R&D của Grab đang tuyển nhiều vị trí như: Backend Developer, Frontend Developer, DevOps Engineer, Lead Software Engineer, ... Bạn có thể tham khảo tại Jobs - Grab Careers để biết thêm chi tiết.
Quotes
“A common fallacy is to assume authors of incomprehensible code will be able to express themselves clearly in comments.”
— Kevlin Henney
Bạn đánh giá nội dung số newsletter này thế nào?
(1 = Rất tệ / 5 = Rất tốt)
(Việc đánh giá của các bạn là rất quan trọng, sẽ giúp chúng tôi liên tục cải thiện nội dung newsletter tốt hơn)
Đính chính
Trong số trước do sơ xuất trong quá trình biên tập, tại chuyên mục History có một đoạn như sau "Ngoài ra, giao thức reverse-engineering của Tridgell đã phần nào vi phạm quy định sử dụng của BitKeeper". Chúng tôi xin đính chính lại câu này như sau: "Ngoài ra, việc Tridgell dịch ngược mã nguồn (reverse-engineering) của BitKeeper đã vi phạm quy định sử dụng của BitKeeper".
Xin cáo lỗi cùng bạn đọc.