Tag: job

  • 5 cấp độ của làm việc từ xa – và tại sao bạn có thể đang ở cấp độ 2

    5 cấp độ của làm việc từ xa – và tại sao bạn có thể đang ở cấp độ 2

    Bài viết được đăng trên Medium tuần trước, đọc thấy có nhiều thông tin hữu ích nên dịch để giới thiệu với mọi người trong thời kỳ mô hình WFH – Work From Hearts đang lên ngôi <3

    COVID-19 đã buộc các công ty trên toàn thế giới phải ban hành – hoặc tạo ra – các phương thức làm việc từ xa. Các công ty như Box, Amazon, Airbnb, Facebook, Google và Microsoft đều đã và đang thử nghiệm với nhân viên của họ một số biến thể của hình thức làm việc từ xa.

    Giờ đây, các tổ chức truyền thống ở các lĩnh vực như bất động sản, kế toán và chính quyền địa phương cũng bắt đầu với hình thức này.
    Các cuộc gọi nhóm video call trên Zoom, như trong tấm ảnh dưới đây, được thực hiện bởi một số nhóm làm việc vừa bắt đầu làm quen với hình thức làm việc từ xa, đang tràn ngập trên Twitter và LinkedIn cũng như Facebook.

    Tuy nhiên, cũng giống như các công việc có giá trị, luôn có nhiều mức độ thành thạo và tinh tế khác nhau tương ứng với từng quy mô của nó.
    Nhiều nhân viên lần đầu làm việc từ xa coi đó đơn giản là tải xuống Zoom, Slack và truy cập vào email, rồi coi đó là cách giải quyết trọn vẹn cho hình thức làm việc từ xa.
    Nhưng chiếc áo không làm nên thầy tu – còn rất nhiều điều quan trọng khác mà chúng ta cần quan tâm khi bắt đầu với hình thức làm việc từ xa.

    Công ty Automattic

    Nói đến đẳng cấp cao nhất trong hình thức làm việc từ xa, có rất ít công ty có thể làm điều đó tốt hơn Automattic – công ty đứng sau WordPress – nơi sở hữu khoảng 35% số trang web trên mạng Internet.

    Automattic – tại thời điểm viết bài – có 1.170 nhân viên nằm rải rác trên 75 quốc gia, nói 93 ngôn ngữ. Tự hào có mức định giá công ty là 3 tỷ đô la Mỹ, đã thực hiện một số thương vụ đáng chú ý như mua lại WooCommerce và nền tảng blog, Tumblr.

    Công ty này không có văn phòng, với các nhân viên hợp tác làm việc qua phương thức duy nhất là làm việc online.

    Matt Mullenweg

    Người sáng lập của Automattic, Matt Mullenweg (vì tên anh ta có 2 chữ “t”, nên tên công ty này cũng được nhân đôi số chữ “t” theo) gần đây đã xuất hiện trên kênh podcast Making Sense nổi tiếng của Sam Harris để nói về cái mà anh ta gọi là 5 cấp độ của các nhóm phân tán (anh ta thích dùng từ “phân tán” thay vì “từ xa” vì cụm từ “từ xa” kia ngụ ý rằng vẫn còn một nơi làm việc tập trung.)

    Những ý kiến của Mullenweg thật đáng khích lệ (ít nhất là đối với tôi), nó tương tự như những gì tôi đã nói với nhiều khách hàng và đối tác của mình – “Các công cụ chỉ tốt tương đương với cách bạn sử dụng chúng”. Trên thực tế, lạm dụng các công cụ thực sự có thể khiến chúng ta giảm năng suất.

    Bên dưới là cách giải thích và diễn giải của tôi về những ý kiến của Mullenweg về 5 cấp độ của làm việc từ xa.

    Năm cấp độ của làm việc từ xa

    Cấp 1: Hành động không có chủ ý

    Các công ty không có chủ ý hỗ trợ làm việc từ xa, tuy nhiên các nhân viên vẫn có thể tiếp tục một phần công việc nếu họ ở nhà trong một ngày.

    Họ có quyền truy cập vào điện thoại thông minh và email của mình. Và có lẽ họ cũng sẽ tham gia vào một vài cuộc họp.

    Nhưng rồi họ sẽ tạm gác hầu hết mọi việc cho đến khi họ trở lại văn phòng, rồi lại trở thành một cái bóng của chính bản thân mình trong văn phòng như thường lệ.

    Cấp 1 là nơi mà phần lớn các tổ chức & nhân viên đang làm việc trước khi có sự bùng phát của đại dịch COVID19.

    Cấp độ 2: Tái tạo lại văn phòng làm việc dưới hình thức trực tuyến

    Đây là nơi hầu hết các tổ chức hiện đang cư trú trong dịch COVID19 – đặc biệt là những tổ chức truyền thống.

    Đây là nơi nhân viên của bạn có quyền truy cập vào phần mềm họp trực tuyến (ví dụ: Zoom), phần mềm nhắn tin (ví dụ: Slack) và email, nhưng thay vì thiết kế lại công việc để tận dụng các phương tiện mới này, cuối cùng các nhóm sẽ xây dựng lại cách họ làm việc trong văn phòng như trước đây nhưng dưới hình thức trực tuyến.

    Điều này làm trầm trọng thêm nhiều thói quen xấu đã xâm nhập vào văn phòng hiện đại và ngăn chặn khả năng suy nghĩ của những người lao động tri thức – đó là khi bạn phải nhìn vào các cuộc gọi video 10 người trong khi chỉ cần hai người là đủ, hay hơn 60 lần gián đoạn mỗi ngày qua Slack và các cuộc gọi điện thoại, kiểm tra thông báo và trả lời email hơn 70 lần một ngày trong suốt cả ngày, hoặc là khả năng phản hồi nhanh được mong đợi đối với tất cả các nhân viên, khiến họ bị buộc dây với chiếc máy tính như một phản xạ có điều kiện.

    Mullenweg coi việc thiếu thiết kế lại công việc xung quanh các phương tiện mới tương tự như sự thiếu hiệu quả trong nhiều dự án chuyển đổi kỹ thuật số trị giá hàng triệu đô la, mà ở đó các quy trình thủ công bị lỗi và dư thừa được tạo ra trong những năm 1980 lại tiếp tục được số hóa một cách hiệu quả – nhưng chờ đã – chúng vẫn là các quy trình bị lỗi, và chúng bị dư thừa cơ mà?

    Ở cấp độ 2, mọi người vẫn được yêu cầu có mặt trực tuyến từ 9h sáng tới 5h chiều và nếu bạn ở cấp độ 2, bạn vẫn còn một chặng đường dài để đi.

    Cấp độ 3: Thích nghi với các công cụ mới

    Ở cấp độ 3, các tổ chức bắt đầu thích nghi và tận dụng lợi thế của các công cụ mới. Mullenweg nói đến các tài liệu được chia sẻ (chẳng hạn như qua Google Doc), được nhìn thấy bởi tất cả mọi người và cập nhật liên tục theo thời gian thực trong suốt cuộc thảo luận, từ đó có được sự hiểu biết chung về những gì được thảo luận cũng như được quyết định, giúp loại bỏ nguy cơ bị lãng phí thời gian khi có sự hiểu nhầm về nội dung muốn truyền đạt.

    Ở giai đoạn này, các công ty cũng bắt đầu đầu tư vào các thiết bị tốt hơn cho nhân viên của mình, chẳng hạn như công cụ hỗ trợ cho các cuộc gọi video như webcam và micro chống ồn.

    Giao tiếp bằng văn bản hiệu quả trở nên cấp thiết khi các công ty muốn ủng hộ cho hình thức làm việc từ xa. Khó chịu với việc phải tham gia vào những cuộc gọi bất chợt, và ưu tiên cho giao tiếp bất đồng bộ (sẽ được nói đến chi tiết hơn ở phần tiếp theo), hầu hết các giao tiếp tại Automattic dựa trên nền tảng văn bản, và do đó phối hợp ăn khớp một cách nhịp nhàng và đúng lúc trở thành yếu tố quyết định.

    Trên thực tế, Mullenweg chia sẻ rằng hầu hết các công việc tuyển dụng ở công ty ông được thực hiện qua văn bản thay vì các cuộc gọi điện thoại hoặc cuộc gọi video cho ứng viên.

    Khi nhắc đến các cuộc họp:

    • Chỉ tổ chức một cuộc họp nếu điều đó là hoàn toàn cần thiết và không thể đạt được kết quả tương tự bằng hình thức cuộc trò chuyện nhanh, cuộc gọi điện thoại, email, văn bản hoặc tin nhắn.
    • Giới hạn thời gian mặc định cho cuộc họp là 15 phút và chỉ kéo dài thời gian nếu thực sự cần thiết (cuộc họp càng ngắn, bạn sẽ càng phải trao đổi ngắn gọn và rõ ràng, hạn chế được thời gian nói chuyện lan man vô nghĩa).
    • Đặt một lịch trình họp cụ thể và kết quả mong muốn trước khi thực hiện cuộc họp.
    • Chỉ mời những người bắt buộc phải có (trừ khi là những quyết định lớn cần nhiều người tham gia, còn thường thì hai người sẽ đưa ra được quyết định trong khi ba người lại hiếm khi).
    • Đồng ý về các bước triển khai tiếp theo, phân bổ người có trách nhiệm và đặt ngày đến hạn (điều này đặc biệt quan trọng để tránh các cuộc họp boomerang – họp xong như chưa họp).
    • Không bao giờ, sử dụng một cuộc họp chỉ đơn giản là để truyền đạt thông tin – đó là những gì mà email hoặc tin nhắn được thiết kế để giải quyết. Nhiều người thực sự đang thấy rằng hầu hết các cuộc họp này thực tế có thể giải quyết qua email.

    Cấp độ 4: Giao tiếp bất đồng bộ

    “Tôi sẽ đụng tới nó cho tới lúc thích hợp.” –  Đây là bản chất của giao tiếp bất đồng bộ.

    Thực tế là hầu hết mọi thứ không đòi hỏi phải phản ứng lại ngay lập tức. Đối với hầu hết mọi thứ chẳng hạn như thư điện tử hay tin nhắn tức thời nên thực hiện công việc của nó là truyền đạt thông tin, còn người nhận sẽ trả lời khi đến thời điểm phù hợp với họ.

    Nếu một cái gì đó thực sự khẩn cấp, thì phương thức giao tiếp sẽ phản ánh điều đó. Nhấc điện thoại, hoặc vỗ vai người muốn gọi – nhưng chỉ khi đó là việc thực sự khẩn cấp.

    Bên cạnh lợi ích rõ ràng và to lớn của việc dành cho những người lao động tri thức có thời gian suy nghĩ, sáng tạo và đi vào trạng thái dòng chảy (một trạng thái tâm lý theo đó chúng ta có năng suất cao hơn năm lần theo McKinsey), giao tiếp bất đồng bộ còn khiến mọi người đưa ra quyết định tốt hơn.

    Như Robert Greene nói: nếu bạn muốn cắt cảm xúc ra khỏi phương trình, hãy tăng thời gian phản hồi của bạn. Cho mọi người thời gian để suy nghĩ giữa câu hỏi và câu trả lời, thay vì trở thành nạn nhân của việc luôn phải thốt ra điều đầu tiên xuất hiện trong đầu ở các cuộc họp hay khi bị vỗ vai, sẽ mang lại lợi ích chung cho tổ chức về lâu dài.

    Để tránh việc chuyền qua chuyền lại cũng như mất nhiều thời gian trao đổi, hãy chắc chắn rằng các thông điệp bất đồng bộ luôn đảm bảo:

    • Cung cấp đầy đủ và chi tiết bối cảnh của tình huống, cũng như cung cấp các hành động cần thiết một cách rõ ràng đi kèm với các kết quả mong muốn.
    • Cung cấp thông tin về ngày cần hoàn thành.
    • Cung cấp cách thức liên hệ trong trường hợp người nhận cần thêm thông tin hoặc không thể đáp ứng yêu cầu của bạn.

    Ví dụ:

        “Chào An,

        Kèm theo là tài liệu hợp nhất cho công ty mới được tách ra từ công ty hiện tại của chúng tôi.

        Vui lòng ký vào tài liệu khi được yêu cầu và gửi lại cho tôi trước 4 giờ chiều thứ Sáu tuần này.

        Nếu bạn có bất kỳ mối quan tâm nào, hãy gọi cho tôi vào số 555 1983.”

    Các công ty thực sự thực hiện giao tiếp bất đồng bộ đã vượt qua cuộc cách mạng công nghiệp, và không còn giới thiệu sự hiện diện của mình thông qua năng suất, hoặc sản lượng hàng giờ, như các nhà máy hiện tại đang làm.

    Mullenweg chỉ ra rằng các đội phân tán toàn cầu, những người làm việc bất đồng bộ và thành thạo với cách làm việc kiểu chạy tiếp sức, có thể hoàn thành lượng việc cao gấp ba lần so với một nhóm làm việc với các thành viên ở trong văn phòng từ 9 giờ sáng đến 5 giờ chiều.

    Đánh thức con cú đêm trong bạn

    Một yếu tố chưa được bàn tới trong các cuộc trao đổi đó là nhịp sinh học.

    Khoa học cho thấy các mô hình ngủ phổ biến của chúng ta – các kiểu nhịp sinh học – được lập trình từ khi sinh. Mọi người hoặc là cú đêm hoặc sẽ là chim sâu buổi sớm.

    Nhà vật lý thiên văn Sabrina Stierwalt đã viết cho Science American rằng:

    Sở thích của chúng ta đối với cái này hay cái khác được mã hóa trong các gen được gọi là gen “đồng hồ hoặc gen “chu kỳ” qua đó điều chỉnh nhịp sinh học của chúng ta, và liên quan trực tiếp đến huyết áp, sự trao đổi chất, nhiệt độ cơ thể cũng như mức độ hormone.

    Một số nghiên cứu đã phát hiện ra rằng khoảng 30 đến 40% dân số là những con cú đêm, điều đó có nghĩa là ngày làm việc 9h đến 5h hiện đại đang phá hoại những nỗ lực sáng tạo và trí tuệ của gần một nửa lực lượng lao động.

    Stierwalt nói rằng ngày làm việc thường bắt đầu từ 7 đến 9 giờ sáng. Tuy nhiên, những con cú đêm có thể gặp hiện tượng “lệch múi giờ do tác động xã hội” nếu họ thức dậy sớm thế này – nghĩa là, họ có thể cảm thấy hiện tượng tương tự như hiện tượng chúng ta đã gặp sau một chuyến bay qua đêm. Những người dậy sớm thường ít gặp phải tình trạng lệch múi giờ này, điều này giúp họ có lợi thế hơn những con cú đêm.

    Các nghiên cứu cho thấy rằng trong khi những người dậy sớm tỉnh táo hơn vào buổi sáng, thì cú đêm cho thấy sự tập trung mạnh mẽ hơn và sự chú ý kéo dài hơn 10 giờ sau khi thức dậy so với đồng loại “chim sâu buổi sớm” của họ.

    Các công ty bất đồng bộ cung cấp cho cú đêm sự linh hoạt trong việc bắt đầu ngày làm việc mới muộn hơn, miễn là phải đảm bảo có những khoảng thời gian mà họ và đồng nghiệp khác cùng làm việc với nhau.

    Và như Mullenweg chia sẻ: Công ty Automattic đang ở cấp 4

    Cấp 5: Niết Bàn (Nirvana)

    Đây là nơi nhóm phân tán của bạn hoạt động tốt hơn bất kỳ nhóm làm việc trực tiếp tại chỗ nào từng có thể. Mullenweg đánh đồng mức độ này với việc nhấn mạnh hơn vào thiết kế môi trường, trong đó luôn có sự quan tâm đến văn hóa tổ chức, và môi trường vật lý mà mọi người đang làm việc.

    Nhược điểm

    Tất nhiên, có những ưu và nhược điểm với hầu hết các quyết định.

    Có thể tìm thấy ba nhược điểm hoặc mối lo ngại lớn đối với các đội mới làm việc từ xa và cách đối phó với chúng dưới đây:

    Liên kết đội và xây dựng

    Thay vì nói với nhân viên của họ ở văn phòng 11 tháng một năm và được nghỉ 4 tuần, Automattic lật ngược lại kịch bản này: “Nhân viên có 11 tháng làm việc từ xa một năm và phải dành thời gian để đi lại tới 4 tuần một năm cho các sự kiện gắn kết và xây dựng đội nhóm.”

    Họ cũng sử dụng các ứng dụng được xây dựng tùy chỉnh để theo dõi ai đã gặp ai, và sau đó chỉ định chỗ ngồi, nói tại một bữa tiệc tối, để mọi người ngồi với những người mà họ chưa gặp trước đó.

    Sự thấu hiểu và giao tiếp trong văn phòng

    Với tất cả mọi người làm việc trực tuyến, bạn bỏ lỡ các cuộc trò chuyện tán gẫu khi chạm mặt nhau ở quầy ăn/cây lấy nước, hay tình cờ nghe thấy người khác nói về điều mà bạn có thể giúp đỡ, hoặc có ngay nhận thức chung về các hoạt động của nhóm nhờ việc đứng từ xa lắng nghe những cuộc trao đổi.

    Để giải quyết sự thiếu hụt này, Automattic sử dụng một plugin WordPress có tên P2, hoạt động như một blog nội bộ và là nơi có một số lượng đáng kể các cuộc trò chuyện và hoạt động được ghi lại.

    Sự an toàn

    Mullenweg nói đến sự an toàn với phương thức bảo mật đầu cuối sử dụng trong hình thức BYOD – sử dụng thiết bị cá nhân như máy tính xách tay và điện thoại thông minh.

    Tuy nhiên, thay vì nhấn mạnh hay tập trung quá mức đến sự kiểm soát truy cập, chúng ta cần được bảo vệ để chống lại các hành vi độc hại. Với hơn 70% các vụ hack CNTT sử dụng kỹ thuật Social Engineering – kỹ thuật thao túng hành vi con người để xâm nhập vào bên trong thay vì tập trung khai thác các lỗ hổng bảo mật của máy móc, thiết bị.

    “Hiện tại, làm việc tại nhà là một đặc quyền và nó không phải là quyền của nhiều người, vì vậy chúng ta hãy chú ý hơn về cách thức mình làm việc, hãy chứng minh rằng chúng ta có thể làm việc hiệu quả hơn so với làm việc tại văn phòng qua đó chúng ta sẽ được cho phép làm việc từ bất cứ nơi nào chúng ta muốn thường xuyên hơn.”

  • Web Architecture?

    Web Architecture?

    Bài này thực ra là đi copy từ đây, nhưng dịch lại theo ngôn ngữ dễ hiểu thôi : ).

    Web hiện tại thì nó như thế này : )

    Trông có vẻ phức tạp nhưng gần như mình sử dụng hết các phần trong này đó. Thông thường thì mình không để ý đến 9a và 9c, 10 cũng khá optional nhưng thôi cứ đề cập cả.

    Câu chuyện ở trong bài viết hơi khác nhưng mình sẽ diễn giải lại thế này.

    Khi bạn tìm kiếm techover trên Google, kết quả đầu tiên tìm được sẽ là: https://magz.techover.io/. Khi ấn vào link đó, trình duyệt sẽ truy cập đến DNS server tìm kiếm cách truy cập đến magz.techover.io, sau đó trình duyệt sẽ gửi request. Request đầu tiên sẽ truy cập đến CDN Cloudfront của magz.techover.io, các request đã cache sẽ đựoc response luôn từ Edge Location của Cloudfront. Các request khác sẽ đến Load Balancer, và chọn ngẫu nhiên 1 trong 5 Server LightSail của techover. Webserver sẽ truy vấn vào database, tra cứu một số thông tin về các hình ảnh có trong bài viết từ S3 và thực hiện thay đổi database. Và tất nhiên giờ đây, Server sẽ luôn response cho người đọc chế độ xem dưới dạng HTML và gửi lại cho trình duyệt của người dùng, trước tiên chuyển qua bộ cân bằng tải. Trang này chứa các tài sản Javascript và CSS mà mấy cái này thì lại được cache ở CDN ở ban đầu ấy, vì vậy trình duyệt của người dùng liên hệ với CDN để lấy nội dung. Cuối cùng, trình duyệt hiển thị rõ ràng trang cho người dùng xem. Tiếp theo, khi người đọc tìm kiếm bài viết tương tự Server sẽ gửi yêu cầu đến Fulltext Search Service bằng cách sử dụng tiêu đề bài viết và các từ khóa có trong nội dung. Tương lai gần, dịch vụ này cũng phục vụ cho custom feed cho từng user một dựa trên các sở thích hay xu hướng tìm kiếm các từ khóa ở techover. Nhưng bây giờ mỗi khi người dùng đăng bài, chúng tôi sẽ lưu trữ tạm kết quả của trang home ở một Server cache Redis để phục vụ người dùng tốt hơn. Sau đó người dùng viết bài, các tác vụ upload ảnh, resize khá nặng vì vậy sẽ đẩy các công việc này vào queue SQS và được thực hiện bởi các worker, mà các worker này sẽ xử lý không đồng bộ, cập nhật database phù hợp với kết quả, các hình ảnh này sau khi được xử lý xong sẽ được lưu trữ trên S3 và có một CDN Cloudfront khác phục vụ request. Đấy là toàn bộ bức tranh của trang techover hiện tại, cũng khá đủ component.

    Tiếp theo thì mình sẽ đi qua từng cái ở trên kia, mấy cái khóa ở trường đại học thường sẽ dùng số 101 để cho các khóa introduction nên ông tác giả để như thế. Chắc sẽ có một vài series 102, 103 để nói rõ hơn.

    DNS

    Domain Name System, tên nó là thế. Gần như đây là một thứ cốt lõi trong thế giới Web hiện nay. Ở mức cơ bản nhất, DNS cung cấp tra cứu key-value từ một tên miền – domain (ví dụ: google.com) đến địa chỉ IP (ví dụ: 85.129.83.120), được yêu cầu để máy tính của bạn định tuyến(route) yêu cầu đến server phù hợp. Tương tự với số điện thoại, sự khác biệt giữa tên miền và địa chỉ IP là sự khác biệt giữa cuộc gọi của Nguyen Van A, và cuộc gọi 0945123456. Giống như bạn cần một cuốn sách điện thoại để tra cứu số của A trong những ngày xưa, bạn cần DNS để tra cứu địa chỉ IP cho một tên miền. Vì vậy, bạn có thể nghĩ DNS là danh bạ điện thoại cho internet. Có nhiều chi tiết khác chúng tôi có thể đi vào đây nhưng mình sẽ bỏ qua vì nó không quan trọng cho bài 101 này.

    Thực ra có một series khác nói về cái này rõ hơn, có thể tìm thấy ở đây này.

    Load Balancer

    Cân bằng tải, thực ra trong ví dụ của techover thì Load Balancer (LB) còn sau cả CDN nhưng nó không tiêu chuẩn và không hay dùng như thế lắm nên mình để ở đây.

    Hồi ở đại học thì mọi người sẽ biết đến khái niệm mở rộng theo chiều ngang (Horizontal scaling) và mở rộng theo chiều dọc (Vertical scaling). Thì mở rộng theo chiều dọc là nâng cấp phần cứng: Ram, CPU, Bandwidth, … cho Server làm cho Server mạnh hơn đúng nghĩa theo chiều dọc, còn mở rộng theo chiều ngang là thay vì bạn nâng cấp, bạn sẽ mua thêm Server mới, đặt ngang hàng với Server cũ, không tin thì xem ở Stackoverflow này.

    Lúc phát triển một ứng dụng web, thường thì mọi người sẽ thích mở rộng theo chiều ngang hơn vì nó đơn giản, chỉ cần cài thêm server là được. Các vấn đề bất ngờ như: Server sự cố, crash, mất điện datacenter bất ngờ, sự cố thiên tai, … có thể dễ dàng được phòng chống bằng cách đưa thêm Server, ngoài ra khi có nhiều Server chúng ta sẽ có thể bảo trì một trong các Server một cách dễ dàng mà không làm ảnh hưởng đến người dùng vì vẫn còn những Server khác hoạt động. Thuật ngữ thường dùng ở đây là fault tolerant. Thứ hai, việc mở rộng theo chiều ngang cho phép các component của ứng dụng không liên kết quá chặt chẽ với nhau (low coupling) (như Web Server, Database, Service, v.v.), bằng cách cho mỗi component chạy trên một cum Server khác nhau. Cuối cùng, lý do cốt lõi nhất, đồng ý bạn có thể mở rộng theo chiều dọc tuy nhiên đến một lúc nào đó bạn không để mở rộng được nữa,ví dụ như giới hạn của rack server, của datacenter, không có máy tính nào trên thế giới đủ lớn để thực hiện tất cả các tính toán ứng dụng của bạn, trong khi đó việc mở rộng theo chiều ngang gần như không hạn chế. Ví dụ thực tế như này, Netflix một lúc có thể chạy vài chục đến vài nghìn EC2 instance mỗi loại, thậm chí có dùng cả GCP và Azure, không có Server nào đủ lớn để chạy toàn bộ ứng dụng của Netflix trên một Server duy nhất cả.

    Lan man hơi nhiều, nhưng trở lại với Load Balancer, có thể nhận ra rằng Load Balancer lại là cái không thể thiếu để thực hiện mở rộng theo chiều ngang. LB định tuyến các request từ user/client đến các Server khác nhau và đưa kết quả về lại cho user/client, mấy cái Server này thường là các bản sao của một server gốc, hay đơn thuần chỉ là bạn cài đặt lại toàn bộ Server đó. Bất kỳ Server nào trong số đó cũng nên xử lý request theo cùng một cách để nó chỉ là vấn đề phân phối các request trên toàn bộ các Server để không Server nào bị quá tải.

    Đó, Load Balancer về mặt khái niệm là đúng theo nghĩa đen, tất nhiên đằng sau đó là một loạt các công nghệ khác nhau, nhưng cuối cùng vẫn phải đề cập ở một bài viết cụ thể hơn.

    Web Application Servers

    Ở high level, các Web Application Server tương đối đơn giản để mô tả. Những server này thực thi logic nghiệp vụ cốt lõi xử lý request của người dùng và gửi lại HTML cho trình duyệt của người dùng. Để thực hiện công việc của mình, các server này có kết nối với nhiều cơ sở hạ tầng phụ trợ như database, caching, queue job, searching service, các micro-service khác, logging, v.v. Như đã đề cập ở trên, mọi người thường có sử dụng 1 hoặc nhiều load balancer trong cùng một ứng dụng. Web App thì có thể sử dụng nhiều ngôn ngữ khác nhau (Node.js, Ruby, PHP, Scala, Java, C # .NET, v.v.) và một framework MVC cho ngôn ngữ đó (Express cho Node.js, Ruby on Rails , Play Framework cho Scala, Laravel cho PHP, v.v.). Tuy nhiên, đi sâu vào chi tiết của các ngôn ngữ và khung này nằm ngoài phạm vi của bài viết này.

    Database

    Hiện nay, mỗi Web Application thường sử dụng một hoặc nhiều database để lưu trữ thông tin. Database cung cấp các cách xác định cấu trúc dữ liệu của bạn, insert dữ liệu mới, search/select dữ liệu hiện có, update hoặc xóa dữ liệu hiện có, thực hiện tính toán trên dữ liệu và hơn thế nữa. Trong hầu hết các trường hợp, các Web Application Server, cũng như các Worker Server làm việc trực tiếp một Database. Ngoài ra, mỗi Backend có thể có cơ sở dữ liệu riêng của mình và riêng biệt với với phần còn lại.

    Trong bài viết nay, thường sẽ tránh nói sâu về một loại công nghệ cụ thể, thế nên chỉ đề cập đến 2 loại database: SQL và NoQuery.

    SQL là viết tắt của Structured Query Language, ngôn ngữ này cung cấp một cách truy vấn tiêu chuẩn cho các bộ dữ liệu quan hệ có thể truy cập được đối tượng. Cơ sở dữ liệu SQL lưu trữ dữ liệu trong các bảng được liên kết với nhau thông qua các quan kệ: Id, Foreign Id . Hãy xem qua một ví dụ đơn giản về lưu trữ thông tin địa chỉ lịch sử cho người dùng. Bạn có thể có hai bảng, useruser_addresses, được liên kết với nhau bởi id người dùng. Xem hình ảnh dưới đây cho một phiên bản đơn giản. Các bảng được liên kết bằng cột user_id trong user_addresses là một Foreign key, với cột id trong bảng user.

    Nếu bạn không biết nhiều về SQL, tôi khuyên bạn nên tìm hiểu hướng dẫn như bạn có thể tìm thấy ở W3School tại đây. SQL gần như xuất hiện ở mọi Web Application Server, nhìn chung gần như bạn không thể làm Web mà không biết gì về SQL cả. NoQuery, viết tắt của từ Non-SQL, là một công nghệ cơ sở dữ liệu mới hơn đã xuất hiện để xử lý lượng dữ liệu khổng lồ có thể tạo ra Web Application với quy mô lớn (hầu hết các biến thể của SQL không thể mở rộng theo chiều ngang quá tốt và chỉ có thể mở rộng theo chiều dọc đến một điểm nhất định). Nếu bạn không biết gì về NoQuery, mình khuyên nên bắt đầu với một số link dưới đây:

    I would also keep in mind that, by and large, the industry is aligning on SQL as an interface even for NoSQL databases so you really should learn SQL if you don’t know it. There’s almost no way to avoid it these days.

    Về cơ bản cũng sẽ ghi nhớ rằng, gần như tất cả phần mềm đang liên kết với SQL như một giao diện thường thấy ngay cả đối với NoSQL, họ cũng tạo ra các framework cũng như library để hỗ trợ truy vấn NoSQL như một database SQL thông thường, thế nên thực sự cần biết về SQL, kiểu gì bạn cũng gặp những thứ này thôi.

    Caching Service

    Caching Service cung cấp một một nơi lưu trữ theo kiểu key-value đơn giản, cho phép tra cứu các thông tin với độ phức tạp O(1). Các ứng dụng thường tận dụng các Caching Service để lưu kết quả của các tính toán nặng và khó để có thể lấy lại kết quả từ cache thay vì tính toán lại chúng vào lần tiếp theo khi chúng ta cần. Một ứng dụng có thể lưu trữ kết quả từ truy vấn database, kết quả gọi đến một API ở bên ngoài, HTML cho một URL nhất định và nhiều hơn nữa. Dưới đây là một số ví dụ từ các ứng dụng trong thế giới thực:

    • Google lưu trữ kết quả tìm kiếm cho các truy vấn tìm kiếm phổ biến như Taylor Swift hay World Cup, thay vì tính lại chúng mỗi lần
    • Facebook lưu trữ nhiều dữ liệu có thể hiển thị lúc bạn đăng nhập, chẳng hạn như dữ liệu bài đăng, bạn bè, v.v. À có một bài chi tiết về vụ Facebook ở đây

    Job Queue & Servers

    Hầu hết Web Appliaction cần thực hiện một số async job ở background mà không liên quan trực tiếp đến việc tiếp nhận và đáp ứng request của người dùng. Chẳng hạn, Google cần thu thập dữ liệu và lập chỉ mục toàn bộ internet để trả về kết quả tìm kiếm. Google không làm điều này mỗi khi bạn tìm kiếm. Thay vào đó, Google thu thập dữ liệu web không đồng bộ, cập nhật các chỉ mục tìm kiếm khi duyệt các trang web. Mặc dù có các kiến ​​trúc khác nhau cho phép thực hiện async job, nhưng phổ biến nhất là kiểu Queue hay Queue Job. Cài này bao gồm hai thành phần:

    • Một là queue, tất nhiên rồi, thường thì có thể dùng database queue, Redis queue, xịn xò hơn thì dùng dịch vụ cloud như SQS của AWS hay Task Queue ở GCP, Queue này lưu trữ một danh sách các async job. Đơn giản nhất là queue FIFO
    • Hai là cái thực hiện công việc trong queue, thường được gọi là Worker hay Job Server. Bất cứ khi nào Application cần chạy một job, theo một thứ tự thông thường hoặc được xác định bởi hành động của người dùng, thì Application sẽ thêm một job vào queue. Ví dụ, Techover sử dụng queue job làm nhiều background job cần thiết cho công việc. Techover dùng các job để resize ảnh, xử lý CSV để gắn tag, cập nhật Elastic Search index, gửi email đặt lại mật khẩu và nhiều cái nữa. Đầu tiên chúng tôi sử dụng một queue FIFO đơn giản sau đó nâng cấp lên hàng đợi ưu tiên để đảm bảo rằng các hoạt động cần kíp như gửi email đặt lại mật khẩu đã được hoàn thành càng sớm càng tốt. Worker Server, thông thường được cài đặt riêng hoặc có thể chạy cùng với Application Server cho tiết kiệm tài nguyên, các Server này kiểm tra queue job để xác định xem có job nào để làm hay không và nếu có, họ sẽ lấy job (pop) ra khỏi queue và thực hiện(execute). Chi tiết về vụ ngôn ngữ và framework thì lại không đề cập ở bài viết này nhé.

    Full-text Search Service

    Nhiều Web Application, nếu không phải hầu hết đều hỗ trợ một số tính năng tìm kiếm trong đó người dùng nhập vào một đoạn keyword(query) và Web Application trả về kết quả có liên quan nhất về keyword đó. Công nghệ dùng cho chức năng này thường được gọi là Full-text Search, trong đó sử dụng một inverted index để nhanh chóng tra cứu các tài liệu có chứa các từ khóa truy vấn.

    Ví dụ cho thấy cách ba title của document được chuyển đổi thành một inverted index để tạo điều kiện tra cứu nhanh từ một từ khóa cụ thể đến các document có từ khóa đó trong title. Lưu ý, các từ phổ biến như trên mạng, trong đó có các từ phổ biến, như “in”, “the”, “with” (Stop word), thường không được đặt trong một inverted index.

    Mặc dù nó có thể thực hiện Full-text Search trực tiếp từ một số cơ sở dữ liệu (ví dụ: MySQL hỗ trợ Full-text Search), nhưng chúng ta có thể sử dụng một Search Service riêng biệt, tính toán và lưu trữ inverted index và cung cấp query interface. Full-text Search Platform nổi tiếng và phổ biến nhất hiện tại là Elaticsearch mặc dù có các tùy chọn khác như Sphinx hoặc Apache Solr.

    Services

    Khi một Application đạt đến một quy mô nhất định, có khả năng sẽ có một số Service nhất định được refactor để chạy như các Application riêng biệt. Những service này không tiếp xúc với thế giới bên ngoài nhưng sẽ tương tác cùng Application và các service khác. Ví dụ như Techover, có một số service hoạt động và theo schedule:

    • Service gửi mail
    • Service chạy hằng đêm để đồng bộ tài khoản
    • Service export file thành PDF

    Data

    Ngày nay, các công ty sống dựa vào người dùng và dữ liệu. Hầu như mọi ứng dụng ngày nay, một khi nó đạt đến một quy mô nhất định, tận dụng một data pipeline để đảm bảo rằng data có thể được thu thập, lưu trữ và phân tích. Một data pipeline điển hình có ba giai đoạn chính:

    1. Ứng dụng sẽ gửi data, điển hình là các sự kiện về tương tác của người dùng, đến data Firehose, nơi cung cấp các interface dùng để nhập và xử lý data. Thông thường, data thô được chuyển đổi hoặc xử lý thêm data và chuyển sang một Firehose khác. AWS Kinesis (bao gồm cả Kinesis Data Firehose)và Kafka là hai công nghệ phổ biến nhất cho mục đích này.
    2. Data thô cũng như data được chuyển đổi cuối cùng được lưu vào Cloud Storage. AWS Kinesis cung cấp một cài đặt Firehose, giúp lưu trữ data thô vào Cloud Storage S3.
    3. Data được chuyển đổi cũng thường được lưu vào một loại database để phân tích – Data Warehouse, cũng không phải là loại database dùng cho Application thường thấy. Ở AWS thường chúng ta sẽ dùng AWS Redshift, đây là một sản phẩm ưa chuộng của giới ít tiền nhất là các startup, bên cạnh đó các công ty lớn hơn sẽ thường sử dụng Oracle hoặc các Data Warehouse. Nếu các bộ dữ liệu đủ lớn, các Hadoop-like NoSQL như MapReduce có thể dùng để phân tích dữ liệu. Một bước cuối cùng mà thường không được hình dung trong sơ đồ kiến ​​trúc: Load data từ Application vào dịch vụ Data Warehouse. Ví dụ: tại một số trang web sẽ chuyển data từ một OLTP Database vào Redshift mỗi đêm. Việc này giúp cho các data scientist có toàn bộ dữ liệu đầy đủ nhất để phân tích và đưa ra các quyết định.

    Cloud storage

    Theo AWS: "Cloud storage là một phương thức đơn giản và có thể mở rộng để lưu trữ, truy cập và chia sẻ dữ liệu qua Internet". Bạn có thể sử dụng nó để lưu trữ và truy cập bất cứ thứ gì như khi bạn lưu trữ trên hệ thông localfile với thêm lợi ích là có thể tương tác với nó thông qua API RESTful qua HTTP. Amazon S3 cho đến nay vẫn là bộ lưu trữ đám mây tuyệt vời nhất hiện nay và là nơi Techover dùng để lưu trữ video, ảnh và âm thanh, CSS và Javascript, dữ liệu người dùng(tất nhiên là private bucket) và nhiều cái khác nữa.

    CDN – Content Delivery Network

    CDN cung cấp cách transfer các file như HTML tĩnh, CSS, Javascript và hình ảnh trên web nhanh hơn nhiều so với lấy chúng từ một Server nào đó. Nó hoạt động bằng cách distribute các content trên nhiều máy chủ (Edge Location) trên toàn thế giới, để enduser có thể tải xuống các file này từ đó thay vì máy chủ gốc. Ví dụ trong hình ảnh bên dưới, một người dùng ở Tây Ban Nha yêu cầu một trang web từ một trang web có Origin Server ở New York, nhưng các file tĩnh cho trang được tải từ Server Edge CDN, ở Anh, ở Pháp, điều này giúp người dùng tải trang nhanh hơn trải nghiệm mượt mà hơn.

    Về vụ CDN thì có thể xem thêm ở bài viết này.

    EOF

    Cũng hết những cái đề cập từ đầu rồi, bài viết này với mục đích 101 để mọi người hình dung rõ hơn về thế giới web :).