thắc mắc Phân biệt giữa Junior và Senior?

  • Người tạo chủ đề Người tạo chủ đề girlxinhgai
  • Ngày bắt đầu Ngày bắt đầu
vãi thanh niên. Dịch google zero downtime = k bao giờ chết. Để không bao giờ service chết thì phải tự động scale lên. giống như 1 thằng bê hòn đá 50kg thì nó chết, nhưng scale 5 thằng bê thì k chết.
Tính giải thích cho thằng ngu như m hiểu thế nào là auto scale thế nào là zero downtime nhưng nghĩ lại phí quá, t đem giải thích cho bạn bè có ý cầu thị thì hay hơn. M cứ việc đem câu trả lời đó mà đi interview để thiên hạ họ cười cho, chào thân ái ;)
 
Đúng rồi. Giải pháp process controller được sử dụng khá nhiều trong các product lớn. Vì nó có thể mở rộng mà không ảnh hưởng tới các service đang chạy. Thím có thể tham khảo mô hình của tiki được chia sẻ trên youtube
Lần đầu nghe cái này. Thanks thím để tìm hiểu thử :D
 
ông này không biết message queue sinh ra làm gì à ? Sao ông k đẩy message vào queue, gọi RestfuL API thì nó chết mie nó rồi

Hàng triệu message đẩy đồng thời vào một topic ấy.
Rồi giả sử một service trong hệ thống nó chết nó ko phản hồi thì làm thế nào để ko ảnh hưởng đến các service khác hay là chết luôn tất cả service gọi đến nó.

Gửi từ Quốc thoại đến từ 3021 bằng vozFApp
 
auto scale là zero downtime, hệ thống k bao giờ sập. Tôi làm mãi tôi biết.
Rìu lí , mới nghe lần đầu nói auto scale là ko downtime, hay tui chưa phai sé ni o
2021de050d57-8a6d-4fff-bf77-7a8d04d779de.png
 
Vừa hỏi 1 ông bạn IT về vấn đề này. Dăm ba cái lý thuyết thì đi cày cho outsource khoảng 3-4 dự án là biết hết. Nhưng khi interview, nhà tuyển dụng luôn dò hỏi 1 solution nào đó mà NTD đã làm thành công, và yêu cầu ứng viên nêu ra solution đó. Chém ngu nó reject.
1 rou nữa là về English. Pass được rou này kể như cũng đáng cơm gạo
 
Senior ko don thuần chỉ là vấn đề kỹ thuật, còn cả khả năng đi chợ biết cách xài tiền nữa, không kém quan trọng trong các công ty nếu làm dự án, ví dụ đi chạy aws mà ko biết cách đi chợ xài tiền, tăng chi phí, FA nó gõ đầu thì mệt, giải pháp tốt nhất là giải pháp được kê toán duyệt tiền :D. Dự án thành công, tiền hạ tầng ít thì dĩ nhiên duoc đánh giá cao hơn là tốn tiền hạ tầng nhiều.
 
160 instance loại m5 x8, chưa kễ cloudfront, global accelator, lb. Mà đang mùa đứt cáp, ở VN chưa có node bên VNPT lên có edge node , global anycast gì con dân VN cũng khóc hết
Chắc bác devops chính hiệu quá, đó giờ t chỉ manage loại t2 micro còn trầy trật :). T làm BE nhảy sang support nên k dám đụng chạm nhiều :v
 
Chắc bác devops chính hiệu quá, đó giờ t chỉ manage loại t2 micro còn trầy trật :). T làm BE nhảy sang support nên k dám đụng chạm nhiều :v
Không mình là SE thuần, trước giờ mình chưa bao giờ làm devops. Thật luôn là làm tới tầm này nhưng chưa bao giờ mình xài ansible, teraform hay mấy con hàng devops hay xài. Ngày xưa thời mình làm system mấy cái tool đó làm gì có, toàn tự viết để xài, đến bây giờ ví dụ có aws thì mình tự viết tool xài với aws-cli chứ cũng ko động tới mấy món kia. Ngoài xài aws thì mình cũng chuyên về networking, có thể bao xô từ router tới switch, firewall, lập trình cũng chơi luôn. Trước khi xài aws mấy hệ thống kiểu aws toàn xài hàng tự build, nên kiến thức hệ thống mình rất cứng
 
Vừa hỏi 1 ông bạn IT về vấn đề này. Dăm ba cái lý thuyết thì đi cày cho outsource khoảng 3-4 dự án là biết hết. Nhưng khi interview, nhà tuyển dụng luôn dò hỏi 1 solution nào đó mà NTD đã làm thành công, và yêu cầu ứng viên nêu ra solution đó. Chém ngu nó reject.
1 rou nữa là về English. Pass được rou này kể như cũng đáng cơm gạo
biết nhưng chưa chắc hết đâu :byebye: :byebye:
 
Thế anh dùng message queue, khi deploy code mới lên mà vẫn còn message trong queue chưa xử lí xong thì phải làm thế nào.
Giả sử logic của code cũ và code mới là khác nhau và muốn message cũ giữ logic của code cũ.
Câu hỏi Cto hỏi tôi lúc pv senior dev. Cto hàng xịn ở Eu luôn. Nó hỏi tôi đúng 1 câu thôi :sleep:

Sent from Samsung SM-G996B using vozFApp

Theo mình thì, Tùy vào lúc build dự án, nếu đã dự trù có những case như này thì áp dụng api version, message cũ chạy api cũ, message mới chạy api mới chung trên 1 hệ thống
nếu k chia version được vì 1 số lý do nào đó ví dụ như logic cũ và mới bị conflict về mặt data thì mình nghĩ chỉ có cách chờ message cũ xon hết, và chấp nhận down time để k nhận thêm message mới rồi deploy code mới
Hóng bác chia sẽ thêm :D

Sent from Samsung SM-G973F using vozFApp
 
thì mày cứ đi phỏng vấn rồi ném offer lên đây.
Em xây dựng hộ anh 1 hệ thống CI CD zero downtime

ngu kiến của mình, trước mình có làm 1 cái đơn giản, load balancing, 1 con nhận request, 2 con xử lý, con nhận sẽ xem status của 2 con kia để đưa request tới đúng nơi
lúc CD thì deploy con 1 thì disable con 1, server vẫn hoạt động trên con 2, xong con 1 thì enable lại, rồi qua con 2
mình nghĩ sẽ không có downtime trong case deploy này

Sent from Samsung SM-G973F using vozFApp
 
Theo mình thì, Tùy vào lúc build dự án, nếu đã dự trù có những case như này thì áp dụng api version, message cũ chạy api cũ, message mới chạy api mới chung trên 1 hệ thống
nếu k chia version được vì 1 số lý do nào đó ví dụ như logic cũ và mới bị conflict về mặt data thì mình nghĩ chỉ có cách chờ message cũ xon hết, và chấp nhận down time để k nhận thêm message mới rồi deploy code mới
Hóng bác chia sẽ thêm :D

Sent from Samsung SM-G973F using vozFApp

Thế mới nói cần 1 SA hoặc 1 TA xịn. Mới làm được 1 hệ thống xịn xò để cân bằng được nhiều yếu tố. Thế mới làm nên 1 software xịn cho tụi tư bản, vừa đáp ứng được functional requirement và non functional requirement chứ ko phải chỉ biết cắm đầu code clean, dùng design pattern lòe tụi member đâu.
Ví dụ như ko thấy được case này từ đầu, và data nó chuyển từ hệ thống IOT về liên tục thì làm sao mà chấp nhận downtime được, chả lẽ lại đi tắt máy móc? Mà đập code đi sửa lại theo design mới thì đâu phải ngày một ngày hai là sửa được.
Còn quay trở lại vấn đề câu hỏi bên trên thì nếu gặp vấn đề đó mình chấp nhận là mất data, hoặc downtime để xử lí vì mình biết là lúc đó chỉ có trời mới cứu nổi. Mọi thứ cần học phí mà :gach: cái gì cũng phải trade off, hoặc mất tiền để chuyển hướng request qua service mới, queue mới, worker mới. Vẫn để hệ thống cũ chạy song song rồi shutdown dần dần

Sent from Samsung SM-G996B using vozFApp
 
Chắc thằng @girlxinhgai chuẩn bị đi pv lên đây khích đểu để lấy tài liệu ôn tập. Mấy ông cũng rảnh đi test nó nữa. Phỏng vấn offline kiểu này thì hỏi đéo gì mà chả trả lời được.
 
XGboost khác gì với LightGBM :shame: :shame:
Với Catboost cùng 1 bộ số hyperparams thì chạy với 2 mode CPU và GPU có cho kết quả giống nhau không? Giải thích vì sao?

Chém đi bạn hiền
Mời bác giải thích hộ cái, xgboost vs lightgbm thì không nói làm gì một cái phát triển cây theo chiều dọc, một cái phát triển cây theo chiều ngang.

Câu catboost thì sao nhỉ không hiểu lắm cơ bản machine learning là apporixmately function đặc biệt là các ensemble models nên kết quả trọng số thường xấp xỉ nhau chứ không bằng trằn trặn vậy vấn đề bác raise là gì.

Còn mấy câu bác đang challange bạn này thì mình nghiz chỉ là câu hỏi cho junior chứ tầm senior đíu phải chơi điện tử như thế này mad phải giải quyết các vấn đề cụ thể bao gồm nhưng không giới hạn toàn bộ ky thuật để giải quyết 1 bài toán từ sampling data, labeling như nào, evaluation metric để chịu kpi như nào?
 
Rìu lí , mới nghe lần đầu nói auto scale là ko downtime, hay tui chưa phai sé ni o
2021de050d57-8a6d-4fff-bf77-7a8d04d779de.png
F12 =]]
Còn vụ level fresher senior các kiểu thì lúc phỏng vấn sẽ ra level nha, cty có job bands sẵn. Bạn lừa được người phỏng vấn của 3-4 vòng thì bạn xứng đáng được nhận level đó ;) Còn lúc làm việc ra sao thì chưa cần tính đến.
 

Tệp đính kèm

  • Untitled.png
    Untitled.png
    66,3 KB · Lượt xem: 189

Thống kê chủ đề

Ngày tạo
girlxinhgai,
Người trả lời cuối
darkrose,
Trả lời
279
Lượt xem
37.913
Quay lại
Lên đầu trang