Trang chủ > Tùy bút tiểu thuyết > Nội dung chính

Bạn có từng gặp những lỗi khiến bạn mất ngủ không?
2017-05-08

Tôi sẽ kể cho bạn một câu chuyện nhỏlịch bóng đá trực tiếp, đó là một trải nghiệm cá nhân khi làm việc tại một công ty đa quốc gia.

Lúc đólịch bóng đá trực tiếp, tôi đang làm việc trong một nhóm chuyên về phát triển thư viện đa phương tiện trên điện thoại di động. Một ngày nọ, tôi bất ngờ nhận được một lỗi với mức độ nghiêm trọng cao nhất mà công ty có thể đánh giá. Đây là một lỗi vô cùng kỳ lạ, chỉ để tái hiện nó đã mất không ít thời gian. Trong hệ thống theo dõi vấn đề nội bộ của công ty, các tester đã cung cấp đầy đủ hướng dẫn để lặp lại lỗi này. Tóm lại, họ nói rằng khi dùng một mẫu điện thoại từ dòng sản phẩm cụ thể nào đó để phát video từ bộ phim *The Matrix* (Ma Trí), sau khoảng 30 phút, ứng dụng sẽ bất ngờ sập hoàn toàn. Điều khiến mọi người đau đầu không chỉ là sự khó chịu khi phải liên tục thử nghiệm lại mà còn vì không rõ nguyên nhân thực sự gây ra lỗi này. Có vẻ như đây không phải vấn đề nhỏ, bởi nó xuất hiện khá ngẫu nhiên và không dễ để xác định chính xác điểm yếu trong mã nguồn. Chúng tôi đã dành cả tuần để nghiên cứu và tìm cách khắc phục, nhưng vẫn chưa có kết quả khả quan. Đây thực sự là thách thức lớn đối với cả đội ngũ kỹ thuật của chúng tôi.

Bạn có thể tưởng tượnglịch bóng đá trực tiếp, có quá nhiều nguyên nhân có thể gây ra vấn đề sập hệ thống. Ví dụ như việc một thuật toán cụ thể bị lỗi và vượt quá giới hạn bộ nhớ trong quá trình thực thi, hoặc sự rối loạn thứ tự chạy của các luồng đa nhiệm, hoặc tham số được truyền vào bộ giải mã bị sai lệch, v.v., danh sách này thì không hề nhỏ. Vấn đề có thể xuất hiện ở tầng ứng dụng phía trên, cũng có thể nằm sâu bên trong thư viện (library), thậm chí là bộ mã hóa/đi mã hóa (codec) có vấn đề, hoặc là nền tảng hệ điều hành hoặc phần cứng không ổn định (khi đó tôi đang làm việc tại một công ty sản xuất điện thoại, cả phần mềm lẫn phần cứng đều do chính công ty thiết kế). Nói chung, bất kỳ vấn đề nào bạn nghĩ đến hay chưa từng nghĩ đến đều có khả năng xảy ra.

Trên thực tếVSBET, việc phân tích vấn đề này cũng được tiến hành theo trình tự từ trên xuống dưới. Đầu tiên, nếu việc phát lại gặp sự cố, có vẻ như đó là lỗi của trình phát video, đúng không? Vấn đề sẽ được chuyển cho đội ngũ phát triển trình phát video trước tiên. Đội ngũ này sau khi kiểm tra đã xác định rằng mã nguồn của họ không phải là nguyên nhân gây ra vấn đề. Họ sẽ thêm kết quả phân tích vào lịch sử xử lý vấn đề và chuyển vấn đề sang đội ngũ tiếp theo để giải quyết. Nhưng đội ngũ nào nên nhận vấn đề này? Điều này phụ thuộc vào kết quả phân tích từ đội ngũ trước đó. Trong quá trình phân tích, họ sẽ theo dõi đến nơi mà ứng dụng gặp sự cố, cụ thể là trong module mã nào mà họ đang sử dụng. Sau đó, có một người chuyên trách sẽ tìm kiếm đội ngũ chịu trách nhiệm duy trì module liên quan. Vì vậy, lỗi này đã bắt đầu từ tầng trên cùng, đi qua nhiều bước chuyển giao, và cuối cùng đến lượt tôi.

Khi một đội nhận được một lỗi ở mức độ cao nhất như vậyVSBET, điều đó có nghĩa là họ cần phải tạm dừng một số công việc đang tiến hành và lập tức huy động người để xử lý nó. Điều này giống như một quả khoai tây nóng mà không ai muốn giữ lâu trong nhóm của mình. Sau cả buổi sáng phân tích, cuối cùng tôi đã chứng minh được rằng điểm sụp đổ không nằm trong khu vực mã nguồn mà chúng tôi phụ trách bảo trì, mà lại nằm ở một module sâu hơn mà chúng tôi đang sử dụng. Được rồi, tôi ghi lại kết quả phân tích vào hệ thống, đính kèm nhật ký phân tích, rồi soạn một email tóm tắt. Công việc của tôi đã hoàn thành một cách hài lòng. Tuy nhiên, lỗi vẫn còn đó! Ngay sau khi gửi email, tôi nhận ra rằng vấn đề chưa thực sự chấm dứt. Lỗi vẫn đang tồn tại và tiếp tục làm gián đoạn hoạt động của toàn bộ hệ thống. Tôi tự nhủ rằng dù đã giải quyết xong phần trách nhiệm của mình, nhưng việc này cũng là một lời nhắc nhở rằng trách nhiệm không chỉ dừng lại ở việc xác định vị trí lỗi, mà còn phải đảm bảo rằng vấn đề được khắc phục hoàn toàn. Tôi quyết định liên hệ với đội ngũ phát triển module mà chúng tôi đang sử dụng, gửi cho họ chi tiết lỗi và kết quả phân tích của mình, hy vọng họ sẽ nhanh chóng tìm ra giải pháp. Đợi phản hồi từ họ, tôi cũng bắt đầu tìm hiểu thêm về module đó. Qua tài liệu và các cuộc thảo luận với đồng nghiệp, tôi càng hiểu rõ hơn về cách hoạt động của module đó và nhận ra rằng có thể còn những yếu tố khác cần được kiểm tra kỹ lưỡng. Trong tâm trạng vừa lo lắng vừa phấn khích, tôi tiếp tục theo dõi sát sao tình hình và chuẩn bị sẵn sàng hỗ trợ nếu cần thiết. Đây đúng là một trải nghiệm đầy thách thức, nhưng cũng giúp tôi trưởng thành hơn trong công việc hàng ngày.

Có lẽ sẽ có người tò mòVSBET, cuối cùng thì lỗi này ra sao rồi? Nó cứ thế lẩn quẩn trong hệ thống theo dõi issue được một tháng hay hơn chút nữa. Cuối cùng, do sản phẩm đó bị hủy (có nghĩa là dự án đó đã bị khai tử), tất nhiên những vấn đề kỹ thuật liên quan đến lỗi này cũng không còn ý nghĩa gì nữa. Và thế là, lỗi này cũng chìm vào quên lãng, chẳng có hồi kết rõ ràng nào...

Công ty nước ngoài mà tôi đang nói đến nổi tiếng nhờ quy trình làm việc hoàn hảo và hệ thống quản lý chất lượng. Dù là phát triển tính năng mới hay sửa lỗi phần mềm (bug)tỷ số bóng đá hôm nay, mọi thứ đều dựa vào quy trình để tiến hành. Với số lượng nhân viên đông đảo và sự phân bố trên phạm vi toàn cầu, một quy trình quản lý nội bộ như vậy tất nhiên là điều cần thiết. Giả sử nếu lỗi đó không bị hủy bỏ cuối cùng, liệu nó có được giải quyết thông qua sự thúc đẩy của quy trình? Theo tôi nghĩ, chắc chắn rồi. Chỉ cần thời gian đủ dài, nó sẽ sớm được chuyển cho người thực sự có khả năng xử lý vấn đề. Tuy nhiên, điểm yếu ở đây chính là hiệu suất vận hành tổng thể quá thấp kém. Quy trình tuy tốt nhưng lại mất quá nhiều thời gian để di chuyển từ tay người này sang người khác, khiến công việc trở nên trì trệ. Một số nhân viên thậm chí còn cảm thấy chán nản vì phải chờ đợi quá lâu trước khi nhận được phản hồi hoặc hỗ trợ từ các bộ phận liên quan. Điều này không chỉ ảnh hưởng đến tâm lý làm việc mà còn gây lãng phí nguồn lực quý giá của cả tổ chức.

Khác với các công ty CNTT truyền thốngtỷ số bóng đá hôm nay, các công ty internet thường được xem là vận hành hiệu quả hơn. Tuy nhiên, có những lỗi kỹ thuật thực sự khó giải quyết hơn, bởi vì môi trường hoạt động của sản phẩm internet luôn thay đổi và phức tạp. Khi đối mặt với một số vấn đề nan giải, chẳng hạn như những lỗi mà người dùng báo cáo nhưng chúng ta không thể tái hiện lại, đôi khi sẽ xảy ra tình huống như sau: sau khi các bạn ở bộ phận backend kiểm tra và khẳng định không có vấn đề gì từ phía server, đến lượt các bạn frontend hoặc mobile kiểm tra, họ cũng nói rằng không phát hiện ra vấn đề nào cả. Cuối cùng, mọi người cũng không thể cứ mãi dồn hết thời gian vào một vấn đề duy nhất, bởi còn hàng tá yêu cầu phát triển khác đang chờ xử lý. Vì vậy, vấn đề này cũng dần bị để sang một bên. Đôi khi, qua một tháng, hai tháng, thậm chí một năm, những vấn đề "cứng đầu" này vẫn chưa được giải quyết. Điều này không chỉ làm mất thời gian mà còn ảnh hưởng đến trải nghiệm người dùng. Một số khách hàng có thể không hiểu tại sao vấn đề mình đã phản ánh lại không nhận được hồi đáp kịp thời. Điều đó có thể dẫn đến việc họ cảm thấy không hài lòng và chuyển sang sử dụng sản phẩm của đối thủ. Do đó, dù gặp khó khăn trong việc xác định nguyên nhân, chúng tôi vẫn luôn cố gắng tìm cách tối ưu hóa quy trình để cải thiện khả năng giải quyết vấn đề, đồng thời khuyến khích các phòng ban phối hợp chặt chẽ hơn để đảm bảo không bỏ sót bất kỳ vấn đề nào quan trọng.

Rõ ràng đây không phải là kết quả mà chúng ta mong đợi. Vậy vấn đề thực sự nằm ở đâu?

Đầu tiênVSBET, không ai có thể hiểu toàn bộ bức tranh một cách hoàn hảo. Giống như ví dụ tôi đã đề cập về công ty nước ngoài mà tôi từng làm việc, mỗi nhóm cơ bản chỉ nắm rõ phần việc của mình, không ai thực sự biết vấn đề thực sự nằm ở đâu. Trong trường hợp lý tưởng nhất, công ty sẽ có những chuyên gia kỹ thuật kỳ cựu, những người đã gắn bó từ thời công ty còn non trẻ và cùng đồng hành với nó suốt chặng đường phát triển. Họ vừa hiểu rõ về mặt kinh doanh, vừa am hiểu sâu sắc về công nghệ, có khả năng phân tích từ góc nhìn chiến lược xuống đến từng chi tiết cụ thể nhất, hoặc ít nhất là làm rõ vấn đề đến mức đủ để chuyển giao cho những người thực sự có khả năng giải quyết nó. Tuy nhiên, trên thực tế, mọi thứ thường không diễn ra theo cách đó. Ngay cả khi công ty có một số nhân viên kỳ cựu, họ thường rời xa lĩnh vực kỹ thuật quá sớm. Họ luôn bận rộn tham dự các cuộc họp khác nhau (và tất nhiên, việc tham gia họp không phải là điều xấu). Nhưng nếu trong thực tế chúng ta không có ai như vậy - một người hiểu rõ toàn bộ bức tranh, thì lúc này cần có những cá nhân thực sự trách nhiệm cao, có khả năng kết nối tất cả các bên liên quan để cùng giải quyết vấn đề. Trách nhiệm đó không chỉ dừng lại ở việc tìm ra câu trả lời, mà còn đòi hỏi sự kiên trì và sáng tạo để biến mọi yếu tố thành một hệ thống hoạt động hiệu quả hơn. Đây chính là lúc sự lãnh đạo tinh thần trở nên quan trọng hơn bao giờ hết, vì không ai muốn vấn đề bị trì hoãn hoặc kéo dài mãi mà không có lời giải. Một người có trách nhiệm mạnh mẽ không chỉ giúp các nhóm phối hợp tốt hơn mà còn thúc đẩy văn hóa làm việc tập trung vào kết quả cuối cùng, thay vì chỉ chú trọng vào từng khía cạnh riêng lẻ.

tình hình hiện trường

hiện trường vụ án

Ngoài ratỷ số bóng đá hôm nay, đối với những vấn đề thường gặp trên các sản phẩm internet, khi người dùng gặp lỗi nhưng chúng ta không thể tái hiện lại sự cố, thì các bạn kỹ thuật thường cảm thấy việc giải quyết trở nên khó khăn. Nguyên nhân chủ yếu là do "dữ liệu" hoặc "thông tin" mà họ có để phân tích là không đủ. Điều này khiến việc xác định nguyên nhân gốc rễ trở nên phức tạp hơn, bởi vì thiếu đi những manh mối quan trọng từ phía người dùng.

Thứ batỷ số bóng đá hôm nay, và cũng quan trọng nhất, điều chúng ta cần là tinh thần bền bỉ không bỏ cuộc.Những con bug cứng đầu giống như con mồi khéo léotỷ số bóng đá hôm nay, nó sẽ kích thích niềm đam mê của một thợ săn xuất sắc.Một số thợ săn bình thường có thể nhanh chóng từ bỏ khi đối mặt với thử tháchtỷ số bóng đá hôm nay, nhưng một thợ săn tài năng sẽ kiên trì theo đuổi mục tiêu cho đến khi thành công. Đối với những lỗi kỹ thuật cứng đầu, không có cách giải quyết nào hiệu quả hơn là bạn phải trở nên kiên trì và bền bỉ hơn cả chúng. Hãy nhớ rằng, đôi khi sự kiên nhẫn và ý chí mạnh mẽ chính là vũ khí mạnh nhất trong hành trình khắc phục khó khăn.

Rất nhiều người thường có suy nghĩ rằng việc sửa lỗi (debug) chỉ là một công việc mang tính chất cơ họcVSBET, không đáng để dành quá nhiều thời gian. Tuy nhiên, trên thực tế, đối với sự phát triển chuyên môn trong lĩnh vực kỹ thuật, đây lại chính là bước quan trọng để "thăng cấp" và đạt đến trình độ cao hơn trong nghề nghiệp. Một mặt, khi bạn luôn chú ý theo dõi một vấn đề cụ thể, bạn sẽ ngày càng hiểu rõ hơn về các mô hình hoạt động liên quan đến hệ thống. Bạn biết được các tham số chuẩn trong tình huống bình thường và cũng có khả năng nhận diện từng dấu hiệu bất thường. Không có cách nào khác có thể giúp bạn hiểu sâu sắc và nhạy bén với hệ thống như thế này. Mặt khác, trước đây tôi đã đọc trong cuốn sách... Chinh phục kỹ thuật: Từ không đến chuyên gia Trong bài viết trướclịch bóng đá trực tiếp, cũng đã đề cập rằng việc nghiên cứu một vấn đề cụ thể có thể dẫn đến sự thay đổi toàn diện trong cấu trúc. Khi cấu trúc cũ không còn khả năng khắc phục các vấn đề dù có sửa chữa kỹ càng đến đâu, nó sẽ dần lột xác và tái sinh như cánh bướm từ kén. Tất cả những yếu tố này tạo áp lực buộc hệ thống phải tiến hóa lên một cấp độ cao hơn. Mỗi khi đối mặt với những thử thách lớn, hệ thống không chỉ đơn thuần là giải quyết vấn đề mà còn phải tự đặt câu hỏi về bản chất của chính mình. Điều này giống như hành trình của một con người khi trưởng thành - phải vượt qua đau khổ và khó khăn để đạt được sự hiểu biết sâu sắc hơn về thế giớ Và từ đó, cấu trúc mới sẽ mạnh mẽ hơn, linh hoạt hơn và có khả năng thích nghi tốt hơn với mọi biến cố trong tương lai.

Trong thực tếtỷ số bóng đá hôm nay, chúng ta thường gặp những vấn đề khó khăn nào? Ít nhất có ba loại vấn đề như sau:

  • Có thể xuất hiện bất kỳ lúc nào;
  • Liên quan đến hiệu suất (tìm điểm nghẽn hiệu năng);
  • Chỉ xảy ra trong môi trường cụ thể.

Về ví dụ mà tôi đã đề cập trước đó liên quan đến việc CPU đạt mức sử dụng tối đalịch bóng đá trực tiếp, đó thuộc loại vấn đề đầu tiên. Khi đối mặt với loại tình huống này, bên cạnh việc nghiên cứu kỹ lưỡng mã nguồn, chúng ta cũng cần chuẩn bị thật chu đáo trước khi vấn đề xảy ra. Điều đó có nghĩa là phải ghi lại càng nhiều thông tin nhật ký càng tốt. Chỉ như vậy, khi vấn đề thực sự xuất hiện, chúng ta mới có thể "bắt" được nó một cách hiệu quả. Ngoài ra, điều quan trọng không kém là phải thường xuyên theo dõi và phân tích các hoạt động của hệ thống để phát hiện dấu hiệu bất thường từ sớm. Một hệ thống được giám sát chặt chẽ sẽ giúp giảm thiểu nguy cơ gặp phải những sự cố không mong muốn.

Vấn đề liên quan đến hiệu năng thì khó ở chỗ khi vấn đề xảy raVSBET, các yếu tố ảnh hưởng lẫn nhau khiến ta không thể phân biệt đâu là nguyên nhân, đâu là kết quả. Đôi khi, chúng ta cần tiến hành các phân tích Profiing phức tạp để tìm ra nguyên nhân gốc rễ. Đối với các vấn đề trên client, có rất nhiều công cụ Profiling đã được phát triển và hoàn thiện, nhưng tình hình trên server lại phức tạp hơn nhiều. Mình chợt nhớ đến bạn Hồ đã dịch một bài viết có tên Nhận diện vấn đề hiệu năng trên trang Thần Duẩn của mình. Bài viết đó thực sự rất hay và đáng để đọc. Nó giải thích rõ ràng mối quan hệ giữa thời gian phản hồi và tốc độ xử lý, đồng thời mô tả các điểm uốn trong hiệu năng một cách ấn tượng và đầy tính hướng dẫn. Đường link gốc của bài viết như sau: [địa chỉ].

https://mp.weixin.qq.com/s/-M2EfUc_XLKnU049T49ZWA

Trong những năm đầu khởi nghiệpVSBET, khi lượng truy cập ngày càng tăng, vấn đề về hiệu suất cũng xuất hiện liên tục, đặc biệt là các vấn đề liên quan đến hiệu suất của cơ sở dữ liệu. Tuy nhiên, những khó khăn mà tôi nhớ nhất vẫn là những thách thức gặp phải vào giai đoạn đầu khởi nghiệp. Có lẽ vì thiếu kinh nghiệm thời điểm đó nên chúng để lại dấu ấn sâu sắc trong tâm trí. Tôi còn nhớ một buổi sáng cao điểm lưu lượng truy cập, vài máy chủ web lần lượt ngừng hoạt động. Sau khi khởi động lại, bộ nhớ bắt đầu tăng lên và chỉ sau vài phút, bộ nhớ lại bị vượt quá giới hạn. Nhóm chúng tôi phân tích sơ qua nhưng vẫn không thể xác định được nguyên nhân cụ thể. Vì vậy, tôi quyết định bàn bạc với bạn Lý Phù ngồi bên cạnh rằng, hay cậu chịu trách nhiệm restart các máy chủ định kỳ thay vì đợi nó tự out of memory (OOM). Ít nhất thì dịch vụ trực tuyến sẽ không hoàn toàn không khả dụng. Còn tôi sẽ tập trung dùng các công cụ để phân tích. Sau đó, tôi dùng jmap dump toàn bộ heap của hệ thống ra file, rồi copy file này sang một máy rảnh rỗi khác và khởi chạy jhat để quan sát. Kết quả rất rõ ràng: vấn đề nằm ở cấu trúc dữ liệu ConcurrentHashMap gây ra hiện tượng rò rỉ bộ nhớ. Khi phân tích đến đây, nếu không có kinh nghiệm liên quan, có lẽ vẫn không hiểu được sự việc. Tuy nhiên, khi tham khảo tài liệu trên mạng, chúng tôi nghi ngờ rằng có thể trong mã nguồn có sử dụng HttpSession, mà HttpSession được quản lý bở Tìm kiếm trong mã nguồn dự án, đúng như dự đoán, mã đã sử dụ getSession(). Trong kiến trúc web phân tán, HttpSession thực tế không phải là lựa chọn tốt, nhiều công ty có kinh nghiệm thường cấm lập trình viên sử dụng tính năng này, nhưng vẫn có người quên quy định này. May mắn thay, những nơi sử dụng HttpSession này đều khá dễ sửa đổi. Sau khi chỉnh sửa, vấn đề về bộ nhớ cũng được giải quyết ngay lập tức. Lời bài học rút ra từ câu chuyện này là dù có kinh nghiệm hay không, đôi khi chúng ta cần có cái nhìn tổng quan và linh hoạt trong cách tiếp cận vấn đề. Đồng thời, việc học hỏi từ các tài liệu và chia sẻ của cộng đồng cũng là một phần quan trọng giúp chúng ta giải quyết vấn đề nhanh chóng hơn.

Những vấn đề thuộc loại thứ ba - những vấn đề chỉ xuất hiện trong các điều kiện cụ thểVSBET, thường rất khó để giải quyết. Thông thường, chúng chỉ ảnh hưởng đến một số lượng nhỏ người dùng, do đó sự quan tâm của mọi người cũng không được nhiều. Những vấn đề như vậy xảy ra khá phổ biến trong quá trình phát triển ứng dụng client, đặc biệt là đối với ứng dụng Android, chủ yếu là do môi trường thực thi quá phức tạp. Đôi khi, vấn đề chỉ xuất hiện trên một số dòng máy cụ thể, đôi khi nó chỉ xảy ra với một nhóm người dùng nhất định, và có lúc nó thậm chí chỉ xuất hiện trong điều kiện mạng cụ thể nào đó. Điều này khiến việc xác định nguyên nhân trở nên vô cùng khó khăn và đòi hỏi sự tinh tế trong việc phân tích và xử lý.

tấn công cướp lưu lượng

Không giữ hoạt động

Có lẽ mọi người đã nhận ra rằngtỷ số bóng đá hôm nay, để giải quyết các vấn đề cụ thể xảy ra ở phía người dùng, điều quan trọng là phải thu thập được nhật ký hoạt động tại chỗ của họ. Ví dụ như Mars Xlog mà WeChat đã mở nguồn, chính là công cụ chuyên thực hiện việc này và nó thực sự rất hữu ích. Theo tin đồn, tác giả gần đây sẽ tung ra một số tính năng mới. Nếu bạn đang sử dụng phiên bản iOS của WeChat, hãy thử nhập ":up" khi thêm bạn bè, bạn sẽ thấy giao diện báo cáo nhật ký của WeChat (với phiên bản Android, tôi không biết cách nào để bật tính năng này, những ai biết có thể để lại bình luận bên dưới). Những nhật ký được gửi lên ở đây, theo như thông tin tôi được biết, đều là những thông tin được in ra bằng Xlog.

chỉ xảy ra trong điều kiện cụ thể nào đó Sử dụng sự thật để nói chuyệnVSBET, thay vì dựa vào phán đoán chủ quan, nên là nguyên tắc cơ bản khi hành động của các kỹ thuật viên.Nếu phải vi phạm nguyên tắc này để đưa ra kết luậnVSBET, thì chúng ta không đưa ra kết luận.

Mọi việc luôn không thể hoàn hảoVSBET, thế giới này cũng không tồn tại trạng thái hoàn hảo. Chương trình trong quá trình vận hành chắc chắn sẽ gặp lỗi.

Ngay cả những vấn đề chỉ xảy ra một lần cũng vẫn là vấn đề. Cốt lõi của kỹ thuật chính là nghệ thuật khiến mô hình logic hoàn hảo hoạt động trơn tru trong thế giới không hoàn hảo. 。

Miễn là chúng ta tiếp tục nỗ lựclịch bóng đá trực tiếp, chắc chắn chúng ta sẽ làm tốt hơn so với trước đây.

(Kết thúc)

Các bài viết được chọn lọc khác ：


Bài viết gốctỷ số bóng đá hôm nay, vui lòng ghi rõ nguồn và bao gồm mã QR bên dưới! Nếu không, từ chối tái bản!
Liên kết bài viết này: /7cfaggnx.html
Hãy theo dõi tài khoản Weibo cá nhân của tôi: Tìm kiếm tên tôi "Trương Thiết Lệ" trên Weibo.
Tài khoản WeChat của tôi: tielei-blog (Trương Thiết Lệ)
Bài trước: Bảo vệ sự tôn nghiêm của công nghệ
Bài sau: Cuộc phiêu lưu của ba byte

Phân loại mục

Bài viết mới nhất

Liên kết thân thiện:

quay hu vip888 trò chơi bắn cá trò chơi bắn c kết quả bóng đá trực tiếp Tỷ Lệ Kèo Nhà Cái slot machine chơi game bắn c