SOLUTION ARCHITECT LÀ GÌ

     

Solution Architect là gì? bởi vì sao cụm từ này lại rất phổ cập trong giới công nghệ, vậy làm gắng nào để cải cách và phát triển theo huớng Architect, đâu là những kỹ năng cần bổ sung cập nhật và chú trọng.

Bạn đang xem: Solution architect là gì

Solution Architect là gì?Vai trò của một Solution Architect tương đối rộng và mang tính chất bao quát, họ đang tham gia thẳng với nhóm ngũ marketing ( tức thì từ lúc giai đoạn dự án chưa được hình thành). Từ kia Họ sẽ vắt được các vấn đề tởm doanh của người tiêu dùng và khuyến cáo các chiến thuật thiết kế hệ thống để buổi tối ưu hóa lại các hoạt động kinh doanh. Những đặc điểm nhận dạng một solution architect:

Họ đã thường không trực tiếp kiến thiết phần mềm, Solution Architect sẽ triệu tập vào làm những bài toán trên chức năng lớn kết hợp với các giải pháp công nghệ. Từ đó họ sẽ đề xuất các giải pháp thiết kế, dựa vào những phát âm biết về ghê doanh của doanh nghiệp và khách hàng hàng.Nắm được hầu như xu hướng công nghệ mới, hiểu được các giới hạn của giải pháp, kĩ năng mở rộng, khả năng gia hạn trong tương lai.Họ còn tồn tại trách nhiệm giới thiệu độ ưu tiên cho phương án cần được triển khai. Điều này cũng tùy ở trong vào những yếu tố mà công việc của mục đích này được đảm nhận một phần bởi các vai trò product Manager hoặc Senior Business Analyst.

Trong mục chuyên viên nói, hãy cùng TopDev chuyện trò cùng anh Võ Duy Tuấn – CEO | Teamcrop – chuyên cung ứng giải pháp thống trị bán hàng, làm chủ nhân sự.

Theo anh một Solution Architect bao gồm vai trò như thế nào ở một công ty về quản lý chuỗi bán lẻ ERP? Anh có thể giới thiệu một cách bao gồm về quá trình của mình ở thời điểm hiện tại?Theo tôi, Solution Architect đóng vai trò quan trọng đặc biệt ở hầu hết ở những doanh nghiệp công nghệ. Chính vì họ giúp kiến thiết một bản vẽ xây dựng tốt, bình ổn cho khối hệ thống đang vận hành. Đặc biệt về bảo mật, năng lực mở rộng, tiết kiệm chi phí chi phí.

Để đổi mới một Solution Architect xuất sắc thì chúng ta cần phải chú ý phát triển những khả năng gì?Để đổi thay một Solution Architect giỏi thì cần nắm vững kiến thức về mạng (networking), xây dựng và phương pháp một hệ thống quản lý thì mới có thể thiết kế một hệ thống xuất sắc cho khách hàng hàng.

Anh có thể diễn tả một career path cụ thể cho một Solution Architect được không?


*

Theo kinh nghiệm tay nghề của tôi, một Solution Architect cần phải nắm được bản vẽ xây dựng mình đang chạy gồm hồ hết gì như: server như vậy nào; database, web server,… chạy ra làm sao và sau đó setup cho để chạy, đồng thời triển khai theo dõi (monitor) hay xuyên. Thấy lúc performance giảm, hệ thống bị tấn công thì kịp thời đưa ra những bản vẽ xây dựng mới. Đó rất có thể là thời gian ngắn để giải quyết và xử lý vấn đề tức thì tại thời đặc điểm đó hoặc những kiến trúc để giải quyết và xử lý vấn đề nhiều năm hạn cùng để rất có thể scale lên.Chia sẻ thêm về career path, theo phiên bản thân tôi, tôi xuất thân là thiết kế viên cùng chọn môi trường xung quanh web, lập trình web. Sau đó, tôi phân biệt những vụ việc như vô số người truy vấn thì hệ thống bị chậm. Tôi ban đầu tìm hiểu với thấy bên trên internet có tương đối nhiều kiến trúc xuất xắc được phân chia sẻ. Mỗi kiến trúc đều có những lợi thế, bất lợi riêng và tôi bước đầu tìm gọi những kiến trúc ấy rồi dần áp dụng vào hệ thống của mình. Cứ như thế, dần dần hình thành bắt buộc những “phản xạ về kiến trúc”. Đó là khi bạn dạng thân phát hiện tại rằng: áp dụng phong cách xây dựng này sẽ được tối ưu từng nào phần trăm, áp dụng kiến trúc kia sẽ có được những vấn đề gì.Về suốt thời gian học nên học về lập trình, mạng máy tính xách tay (networking), web và bảo mật .

*

Phần mềm quản lí chuỗi bán hàng (ERP) có rất nhiều service không giống nhau. Vậy đối với một hệ thống phức tạp bởi vậy thì cần sẵn sàng phần logging vậy nào cho xuất sắc nhất?Log trong micro service hơi phức tạp. Vày khi xây dựng khối hệ thống lớn, có nhiều vấn đề vạc sinh. Lúc có sự việc phát sinh sẽ rất khó khăn cho việc đào bới tìm kiếm ra nguyên nhân. Hệ thống logging góp tìm ra với phát hiện lý do lỗi. Ví dụ như log request, access log, error log, SQL log,…Bây giờ đặt một bài bác toán: tất cả service A gọi service B với C đồng thời. Trong trường đúng theo B hoặc C bị lỗi thì A sẽ không chạy được và bạn sẽ phải phát âm log của B và C nhằm phát hiện nay lỗi, tuy nhiên, giả dụ A gọi tới rất nhiều service hơi (D,E,F,…) thì liệu có chiến thuật nào để đỡ buộc phải đọc nhiều phần khác nhau nhằm tìm ra lỗi?Đây là vụ việc nổi lên gần đây trong bản vẽ xây dựng microservice. Đối với kiến trúc monolithic như trước, khi bạn thích coi log thì mình chỉ việc coi 1 request là đủ. Vào microservice, vấn đề những service gọi liên đới nhau (chiều sâu 3-4 tầng), câu hỏi nhìn 1 service sẽ tương đối khó đoán để debug được lỗi sinh hoạt đâu. Mặc dù nhiên, một kỹ thuật mới xuất hiện thêm để xử lý bài toán này, đó đó là Distributed Tracing. Đây là 1 trong những kỹ thuật giúp bạn nhìn toàn diện và tổng thể một request từ đầu đến cuối, trải qua hầu hết request khác, đi sâu và kết nối những log ấy lại thành 1 log duy nhất.

Anh hãy chia sẻ vài tips nhằm viết nội dung cho log?

Nội dung của log phụ thuộc vào chính vào nội dung, nhu cầu bạn có nhu cầu log. Vd log request thì log IP; log database thì log loại khác. Lời khuyên của mình là bạn nên quy định một format tiết kiệm nhất cho 1 record log. Vì về lâu năm hạn, log dữ liệu lớn sẽ ảnh hưởng đến thời hạn truy vấn phải khó để monitor sự cố. Cũng chính vì vậy size của log record vô cùng quan trọng.

Xem thêm: Tại Sao Gần Đây Người Đội Mũ Bảo Hiểm Thời Trang Có Bị Phạt Không ?

Anh gồm thể share một số khó khăn kỹ thuật khi không ngừng mở rộng mô hình?Trong việc không ngừng mở rộng mô hình, nhiều khi các Solution Architect sẽ gặp gỡ phải một số trong những khó khăn kỹ thuật. Chẳng hạn như khi làm việc, database sẽ tương đối khó khăn về phần size, quan trọng là bạn phải lựa chọn rất nhiều data storage phù hợp.Ví dụ: Teamcrop phối hợp sử dụng Memory thuộc Clickhouse nhằm lưu dữ liệu lớn và một vài database tùy theo yêu cầu sử dụng.

Theo anh nền tảng Data cùng Devops đã đóng vai trò ra sao cho phần lớn doanh nghiệp dịch vụ thương mại tại thị phần Việt Nam?Theo tôi quan lại sát từ thời điểm cách đó khoảng 3-4 năm, React JS hoặc React Native trở đề xuất thịnh hành. Đến năm 2018, Flutter nổi lên cùng trở yêu cầu phổ biến. Cùng Teamcrop đưa ra quyết định chuyển bản vẽ xây dựng làm app sang Flutter. Những hiểu biết ở Flutter khá tốt, cả team lẫn quý khách đều hài lòng. Theo tôi, trong khoảng 3 đến 4 năm tới Flutter sẽ chiếm lĩnh mảng smartphone app.Và khó khăn khi chuyển từ mẫu cũ sang cái mới chính là bạn sẽ phải học bí quyết tiếp cận, ví như là SDK của Flutter, ngôn ngữ mới Dart của Google, State management mới. Tuy nhiên đây chỉ cần những bài toán nhỏ, so với kết quả mà quy trình mang lại.

*

Hiện ni đâu là 3 technology là thế mạnh mẽ của anh nhất, với 3 công nghệ mà anh hứng thú mà lại mình đang học vào tương lai.Đối với tôi thì PHP, Javascript cùng Dart đó là 3 ngôn từ mà tôi quan tiền tâm cũng như là thế mạnh của mình. Share thêm, sau này theo xu hướng thì tôi muốn tò mò Python để giao hàng Machine Learning, tôi vẫn muốn học thêm những ngôn ngữ Functional Program Learning.

Anh bao gồm thể chia sẻ process tuyển chọn dụng của TeamCrop, với anh suy xét điều gì ở ứng viên?Nhu cầu tuyển dụng của team tôi không thật cao, tuy nhiên vẫn hơi rõ ràng. Ở Teamcrop, tôi mong tuyển rất nhiều bạn: Thích tò mò những technology mới, do công nghệ chỉ khoảng tầm 5 năm sẽ trở bắt buộc lạc hậu. Trình độ chuyên môn không đặc trưng trong quy trình phỏng vấn, vị chỉ trong quá trình thao tác làm việc mới hoàn toàn có thể đánh giá chỉ liệu họ bao gồm tư duy logic, bốn duy lập trình, teamwork,… hay không. đặc biệt nhất vẫn luôn là tính cách, thích giải quyết và xử lý vấn đề. Trong khi còn gồm vòng thử câu hỏi để hiểu nhau hơn.

Công việc mỗi ngày của anh với team như thế nào?Ngoài là Solution Architect, tôi còn thống trị công ty. Các bước hàng ngày của tôi bao hàm những bài toán như monitor hệ thống, họp với team, tò mò về sản phẩm của Teamcrop, đôi lúc lập trình bởi task thu hút nên xắn tay áo tham gia thuộc anh em.

Những ưu điểm hoặc lợi ích, vạc triển bạn dạng thân hoặc điều gì thú vị nhất khi trở thành thành viên của tech team nói thông thường và team của anh ý nói riêng?Khi vào Teamcrop, Thứ nhất , các bạn sẽ không cần làm “quá nhiều”. Doanh nghiệp tôi không theo trường phái “đầu tắt khía cạnh tối” và làm cho quần quật. Xuyên suốt năm qua, cả team nói ko với OT bởi vì tasks chỉ cần làm tại công ty là đủ. Quá trình liên quan tới nhiều là sales, kinh doanh support là chính. Ngoài ra, những benefit cơ phiên bản như lương thưởng tháng 13 là vấn đề hiển nhiên, công ty nào cũng có. Đối cùng với những thành phầm được đón nhận tất nhiên sẽ sở hữu được benefits riêng.

Xem thêm: Cách Làm Cá Trắm Hấp Xì Dầu Nấm Hương Thơm Ngon Vô Cùng, Cá Trắm Nấu (Hấp) Xì Dầu Chinsu

Anh tất cả thể share về một lưu niệm đáng nhớ cũng tương tự kinh nghiệm xương huyết về việc vận dụng một công nghệ mới vào sản phẩm của công ty?Kỷ niệm lưu niệm của tôi đó là khi teamcrop áp dụng technology service worker, trên đây là công dụng lưu file trên trình xem xét giúp mình đỡ mất công request vào server. Trong một lần soát sổ không kỹ, thông số kỹ thuật nhầm và tác dụng là sketch cả tệp tin index.html, thường đang dẫn liên kết tới javascript, khiến cho việc vào đường truyền domain vẫn ko ra content mới bắt buộc phải thay đổi domain do domain cũ ko thể thực hiện được. Từ kia rút kinh nghiệm không sketch file index nữa.Xin cảm ơn phần share vừa rồi từ bỏ anh Tuấn. Hy vọng nội dung bài viết này đã cung cấp những câu chuyện về nghề Solution Architect cũng như giúp chúng ta hiểu hơn những kỹ năng và kiến thức cần đã có được trong lĩnh vực này. Đừng quên quan sát và theo dõi phần tiếp theo sau trong chuyên gia nói để biết thêm những vai trò khác trong lĩnh vực technology nhé!