Chỉ số SLA - Nâng tầm cung cấp và sử dụng dịch vụ

Chỉ số SLA - Nâng tầm cung cấp và sử dụng dịch vụ

Những mẩu tin ngắn hàng ngày dành cho bạn
  • Hẳn là nhiều người ở đây đã nghe đến kiểu tấn công bảo mật Clickjacking rồi nhỉ. Kẻ tấn công thường nhúng một website (thường là mục tiêu) vào trong một iframe trên website của chúng, sau đó làm mờ hoặc ẩn nó đi rồi đặt vào vị trí các nút bấm trên web, ví dụ "Bấm vào để nhận quà". Đâu ai ngờ rằng phía trên nút bấm đó là một nút bấm khác trong iframe. Khá nguy hiểm!

    Nhưng trình duyệt đã có cách ngăn chặn kiểu tấn công này bằng các quy tắc như tiêu đề X-Frame-Options, frame-ancestors của CSP và SameSite: Lax/Strict của Cookies...

    Mới đây, đã xuất hiện thêm kiểu tấn công mới - "DoubleClickjacking" 😨. Đại ý là "hắn" lợi dụng hành động double click để lừa người dùng bấm vào một nút mà hắn muốn. Chi tiết hơn trong bài viết này: DoubleClickjacking: A New Era of UI Redressing.

    » Xem thêm
  • Mọi người đã nghe nói đến Jujutsu - jj - một dạng quản lý phiên bản cho mã nguồn (version control system) chưa? Có vẻ như nó đang nhận được nhiều sự quan tâm.

    Chờ xíu! Chẳng phải git đã quá tốt rồi sao? Thế thì chế ra thằng jj để làm gì nữa? Cũng hơi khó trả lời nhỉ? Mỗi công cụ sinh ra chắc chắn phải cải thiện hoặc khắc phục được nhược điểm của cái trước. Cho nên jj ắt hẳn phải làm được điều gì đó mà git chưa làm được nên mới nổi lên như vậy.

    Thật ra mình đã nghe nói đến jj từ vài tháng trước rồi, nhưng vào đọc thì toàn kiến thức cao siêu. Hoặc là đang mang nặng cái lối suy nghĩ của git vào trong đầu rồi nên chưa lĩnh hội ra được điều gì cả.

    Mình hay có kiểu cái gì đọc lần 1 mà không hiểu thì đọc tiếp lần 2, lần 2 không hiểu thì đọc tiếp lần 3... đến lần thứ n mà vẫn không hiểu thì bỏ. Cơ mà không phải là từ bỏ mà một thời gian sau đó quay lại đọc tiếp. Đến một lúc nào đó khả năng mình sẽ hiểu ra một ít vấn đề, thế mới tài 😆.

    Thì cái jj này có vẻ như nó đang mở ra được tính linh hoạt trong việc "cam kết" mã. Tưởng tượng bạn đang làm việc trên một dự án, đang ở nhánh này, muốn sang nhánh khác để sửa, nhưng mà lại đang viết dở ở nhánh này, thế là phải stash, rồi checkout, rồi commit, rồi merge hoặc rebase lại vào nhánh cũ... nhìn chung quá trình làm việc với git nghiêm ngặt đến mức cứng nhắc, cần nhiều thao tác để giải quyết một vấn đề, chưa kể cái cây commit (commit-tree) nữa thì ôi thôi, khỏi xem cho đỡ nhức mắt. Thế nên ông jj này đang làm cách nào đó để bạn khỏi cần phải quan tâm đến các nhánh luôn, sửa trực tiếp vào commit. Nghe ảo nhỉ 😂.

    Đấy mới lĩnh hội được đến đấy, hy vọng sau n lần đọc lại nữa mình sẽ viết được một bài chi tiết hơn về công cụ này.

    » Xem thêm
  • Gòi gòi tới công chiện gòi 🤤🤤🤤

    » Xem thêm

Vấn đề

Vào những năm 2010, nếu tham gia vào các diễn đàn về công nghệ, nơi có nhiều người cùng chung sở thích lập trình và chia sẻ những thủ thuật ở trên mạng. Bạn sẽ rất dễ dàng nhìn thấy những bài viết về nội dung chia sẻ hosting hoàn toàn miễn phí cho ai có nhu cầu. Điều kiện cũng rất đơn giản, chỉ cần để lại thông tin như tên, địa chỉ email hoặc đôi khi kèm theo cả mục đích sử dụng, thì chỉ sau một thời gian ngắn, họ sẽ gửi đầy đủ thông tin về mail của bạn.

Trong bài viết, một số thông báo rõ thời gian "tài trợ" hoặc thời gian dùng thử là 1 hoặc nhiều tháng, hoặc cho đến khi nào họ không còn khả năng duy trì máy chủ nữa thì thôi. Thời điểm đó, tôi còn đang là một cậu học sinh, nên không thể bỏ qua được những phi vụ hấp dẫn như thế này. Vừa có hosting để dùng, tốc độ cao, dung lượng lớn, mà lại còn miễn phí. Quả đúng là mọi thứ đều miễn phí!

Thực tế qua nhiều lần đăng ký và sử dụng những dịch vụ như thế này, không có nhiều cái hoạt động được như cam kết, hoặc là không dùng được, có lỗi phát sinh, hoặc đang chạy thì lăn ra chết. Chậc! Cũng phải chấp nhận thôi vì đó giờ chỉ dùng vào mục đích thử nghiệm mã nguồn "đồ chơi" thôi mà.

Internet thời nay đã khác xưa rất nhiều. Tôi không còn thấy những bài viết chia sẻ về hosting như ngày xưa nữa. Thay vào đó là những bài viết chia sẻ máy chủ, VPS, hoặc cũng có nhiều "tay chơi" hào phóng sẵn sàng tài trợ toàn bộ chi phí duy trì máy chủ cho một bên nào đó, miễn là đáp ứng được một vài điều kiện mà họ đề ra. Nhưng hầu như chúng vẫn có một điểm chung là phải phụ thuộc vào người khác. Hệ thống ổn định thì không sao nhưng nếu chẳng may một ngày đẹp trời nào đó, máy chủ chia sẻ bỗng biến mất không dấu vết, dữ liệu cũng chưa kịp sao lưu thì coi như là mua bực vào người.

Tôi rút ra được một bài học đó là nhiều thứ cần phải trả tiền mới mua được sự đảm bảo. Tiền càng nhiều thì tính cam kết càng lớn. Cũng đơn giản thôi! Để vận hành và duy trì bất cứ cái gì đều phải có một đội ngũ đằng sau đó. Họ làm việc để cho hệ thống ổn định, còn chúng ta trả tiền để họ làm việc đó. Nhưng không phải vì thế mà dịch vụ miễn phí bị đánh đồng với chất lượng kém. Ngày nay nhờ vào công cuộc tối ưu phong cách vận hành mà chi phí để chạy các dịch vụ miễn phí không đáng kể, hoặc việc duy trì gói miễn phí cũng tương đương với chi phí marketing cho dịch vụ của họ.

1-2 năm trở lại đây, trước khi quyết định lựa chọn sử dụng dịch vụ của một bên nào đó, tôi thường dành thời gian để tìm hiểu xem ai là người đứng đằng sau nó. Ai làm ra nó, tổ chức nào vận hành và họ có tên tuổi, chỗ đứng nào chưa. Hay thậm chí là "moi móc" cả trong quá khứ đã có những vụ lùm xùm nào liên quan đến hay chưa. "Ôi dào, ông cứ làm quá lên, dùng được thì cứ dùng thôi lúc nào xảy ra vấn đề thì hẵng tính!". Hmm... tôi là người dùng Internet đủ lâu để hiểu được những rắc rối như thế này!

Chẳng đâu xa, gần đây khi đang triển khai bản cập nhật mới cho ứng dụng OpenNotas lên Cloudflare Workers thì một vấn đề đã xảy ra. Trang web liên tục bị chuyển hướng về trang chủ trong khi không có bất kỳ sửa đổi nào liên quan đến hành vi điều hướng, nếu không kiểm tra lại trước khi bấm nút "Publish", có thể người dùng ứng dụng ghi chú của tôi đã gặp phải những rắc rối đáng tiếc. Tôi đã mở một vấn đề trên trang trợ giúp cộng đồng của Cloudflare và hy vọng có ai đó sẽ giúp mình tìm ra nguyên nhân. Sau một ngày dài chờ đợi, có lẽ mọi người đều tất bật với công việc của mình nên chẳng ai biết hoặc quan tâm đến những chủ đề như vậy cả. Cũng may là trước đó đã tìm hiểu về một số bên cung cấp dịch vụ tương tự như Cloudflare và sau đó tôi đã chuyển ứng dụng của mình sang để cho nó hoạt động lại bình thường.

Mặc dù Cloudflare rất nổi tiếng và được nhiều người dùng nhưng nếu chịu khó tìm hiểu bạn sẽ thấy nhiều bài viết của người dùng khiếu nại về dịch vụ của Cloudflare. Tôi cũng là một người dùng của Cloudflare từ rất lâu về trước, từ hồi mà nó chỉ đơn thuần cung cấp dịch vụ DNS cùng với một vài tính năng của CDN. Trong trí nhớ của mình khi đó là nó khá tệ. Khó dùng và hay lỗi. Như vậy, tôi rút ra thêm một bài học nữa là không phải cái nào nổi tiếng, nhiều người dùng cũng đều tốt. Nó vẫn tốt cho đến khi gặp vấn đề!

Tất cả những những thứ vừa kể ở trên phản ánh một điều về niềm tin của người dùng đối với một sản phẩm, dịch vụ. Một nhà cung cấp dịch vụ tốt sẽ làm hài lòng được đại đa số người dùng. Và sự hài lòng đó thường dựa trên Thỏa thuận mức dịch vụ (SLA) của nhà cung cấp với người dùng.

SLA là gì?

Theo Amazon, SLA - Service Level Agreement là hợp đồng nhà cung cấp dịch vụ thuê ngoài và công nghệ, quy định mức dịch vụ mà một nhà cung cấp cam kết phân phối cho khách hàng. Thỏa thuận này nêu rõ các chỉ số, chẳng hạn như thời gian hoạt động, thời gian phân phối, thời gian phản hồi và thời gian xử lý. SLA cũng cung cấp thông tin chi tiết về hướng hành động khi các yêu cầu không được đáp ứng, chẳng hạn như hỗ trợ bổ sung hoặc giảm giá.

Hay nói ngắn gọn, SLA là sự cam kết giữa nhà cung cấp dịch vụ đối với khách hàng. Một nhà cung cấp đáng tin tưởng là khi họ có một bộ SLA trong đó nêu rõ những thông số cần đảm bảo trong khi sử dụng. Ví dụ như không ai muốn thuê một máy chủ hoạt động chập chờn, sống nay chết mai, mà cần phải cam kết hoặc nêu rõ thời gian sống của máy chủ cần đạt được một con số nào đó. Ví dụ như lên đến 99,99% hoặc thấp hơn cũng phải cần được nêu ra để người sử dụng biết được tính khả dụng của dịch vụ mà mình sắp dùng.

Tuân thủ SLA mang lại nhiều lợi ích quan trọng cho cả nhà cung cấp dịch vụ và khách hàng, giúp xây dựng niềm tin, tăng hiệu quả hoạt động và nâng cao uy tín thương hiệu. Khi nhà cung cấp dịch vụ đáp ứng đúng cam kết trong SLA, khách hàng sẽ thấy yên tâm và tin tưởng hơn vào dịch vụ. Có uy tín cao và được đánh giá tích cực trên thị trường. Điều này giúp thu hút thêm khách hàng mới, tạo lợi thế cạnh tranh và gia tăng danh tiếng. Thiết lập rõ ràng các kỳ vọng giữa nhà cung cấp và khách hàng ngay từ đầu, giúp hạn chế các tranh chấp về chất lượng dịch vụ hoặc trách nhiệm của mỗi bên.

AWS là một trong những nhà cung cấp dịch vụ đám mây hàng đầu mà có một bộ SLA đầy đủ và chi tiết. AWS có chính sách cung cấp bồi thường dưới dạng tín dụng (một dạng tiền bồi hoàn) dịch vụ khi SLA bị vi phạm, khách hàng cần phải gửi yêu cầu trong thời gian quy định và chứng minh ảnh hưởng thực tế đến hệ thống của họ.

Vào tháng 2 năm 2017, Amazon S3 ở khu vực miền Đông Hoa Kỳ (us-east-1) đã gặp phải sự cố lớn khiến nhiều dịch vụ phụ thuộc vào AWS bị ảnh hưởng trong vài giờ. Sau sự cố, AWS đã bồi thường cho khách hàng theo chính sách SLA của họ dưới dạng tín dụng dịch vụ. Tháng 11 năm 2020, dịch vụ AWS Kinesis gặp trục trặc kéo dài gần 24 giờ, gây gián đoạn cho các dịch vụ phụ thuộc như Cognito và dịch vụ phát trực tuyến của nhiều công ty. AWS cũng đã cung cấp Service Credits cho các khách hàng bị ảnh hưởng bởi sự cố này, dựa trên thời gian dịch vụ bị gián đoạn và ảnh hưởng đến khách hàng.

Như vậy không phải hiển nhiên mà AWS được rất nhiều cá nhân, tổ chức sử dụng.

Bài học rút ra

Trước khi biết đến khái niệm về SLA, điều tôi thường thấy trên một số trang cung cấp dịch vụ hoặc các câu giới thiệu dịch vụ thường hay nhấn mạnh vào những cam kết của họ. Ví dụ như cam kết thời gian uptime của máy chủ lên đến 99,99%, cam kết hoàn tiền trong vòng 30 ngày sử dụng dịch vụ... Từ đó hình thành thói quen tìm những câu cam kết khi tìm hiểu một dịch vụ nào đó. Tuy rằng những câu nói này hết sức đơn giản và ngắn gọn nhưng mang lại sự an tâm một phần nào đó.

Từ khi vận hành trang blog nhỏ bé này, tôi luôn cố gắng mang đến những cam kết dành riêng cho độc giả. Ví trước đây đã có một thời gian cam kết trả lời mọi câu hỏi của độc giả, hoặc một thoả thuận ngầm rằng ít nhất phải có một bài viết mỗi tuần. Gần đây tôi đang thực hiện một cam kết nữa là mỗi ngày một bài viết ngắn trong chuyên mục Threads của blog - nơi đăng tải những chia sẻ ngắn gọn của bản thân trong ngày hôm đó. Tiếp theo, tôi đang tiến tới một cam kết về việc gửi bản tin tổng hợp hàng tuần hoặc mỗi 2 tuần. Mặc dù chiến dịch này đã bắt đầu từ hơn 1 tháng trước nhưng do số lượng người đăng ký nhận thông báo chưa nhiều nên phải tạm thời ưu tiên những công việc quan trọng hơn. Nếu bạn đọc quan tâm đến tính năng này, hãy tích cực đăng ký nhận thông báo bản tin tổng hợp qua email ngay phía dưới bài viết.

Ngoài ra, tôi cũng đang cố gắng cam kết cập nhật ứng dụng ghi chú OpenNotas ít nhất mỗi 2 tuần để sửa lỗi và nâng cao trải nghiệm người dùng.

Tổng kết

SLA là một thỏa thuận quan trọng cho nhà cung cấp dịch vụ và cả người dùng. Đảm bảo được SLA sẽ giúp nhà cung cấp ghi điểm trong mắt người sử dụng dịch vụ và nhiều hơn thế. Tuy vậy SLA đòi hỏi khả năng vận hành không hề đơn giản và tiêu tốn nhiều nguồn lực. Nhưng không phải vì thế mà chúng ta bỏ qua, hãy bắt đầu với những cam kết dù là nhỏ nhất.

Cao cấp
Hello

Tôi & khao khát "chơi chữ"

Bạn đã thử viết? Và rồi thất bại hoặc chưa ưng ý? Tại 2coffee.dev chúng tôi đã có quãng thời gian chật vật với công việc viết. Đừng nản chí, vì giờ đây chúng tôi đã có cách giúp bạn. Hãy bấm vào để trở thành hội viên ngay!

Bạn đã thử viết? Và rồi thất bại hoặc chưa ưng ý? Tại 2coffee.dev chúng tôi đã có quãng thời gian chật vật với công việc viết. Đừng nản chí, vì giờ đây chúng tôi đã có cách giúp bạn. Hãy bấm vào để trở thành hội viên ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (0)

Nội dung bình luận...
Bấm hoặc cuộn mạnh để sang bài mới