44 điểm bởi GN⁺ 2025-10-21 | 8 bình luận | Chia sẻ qua WhatsApp
  • Sự cố AWS khu vực US-EAST-1 lần này được phân tích không chỉ là một lỗi kỹ thuật đơn thuần, mà là tín hiệu của sự suy yếu mang tính tổ chức do thất thoát nhân sự nòng cốt
  • Nguyên nhân của sự cố cuối cùng vẫn được xác định là vấn đề DNS rất cổ điển, và lỗi endpoint API của DynamoDB đã khiến các dịch vụ khác ngừng hoạt động theo hiệu ứng dây chuyền
  • Khi các kỹ sư kỳ cựu từng nhớ các mẫu lỗi của hệ thống trong quá khứ đã rời công ty, đã lộ rõ dấu hiệu cho thấy tốc độ xác định vấn đề và khôi phục bị chậm đi đáng kể
  • Các đợt cắt giảm nhân sự quy mô lớn và “tỷ lệ nghỉ việc đáng tiếc” 69~81% bên trong Amazon đã cùng tác động, làm lung lay độ ổn định vận hành của AWS
  • Đây không phải khủng hoảng do công nghệ lỗi thời, mà do thiếu con người, và được diễn giải không phải là “một sự cố đơn lẻ” của AWS mà là điềm báo của sự sụp đổ niềm tin kéo dài

Sự cố DNS và gián đoạn dịch vụ

  • Giống như câu đùa "It's always DNS" vốn lưu truyền lâu nay giữa các quản trị viên hệ thống, ở trung tâm của nhiều sự cố dịch vụ luôn là vấn đề DNS
  • 12:11AM(PDT) ngày 20/10/2025, có báo cáo về tỷ lệ lỗi của dịch vụ AWS tại khu vực US-EAST-1 tăng vọt
    • 1:26AM, các yêu cầu tới endpoint DynamoDB bắt đầu thất bại trên diện rộng
    • 2:01AM, xác nhận nguyên nhân là lỗi DNS Resolution của endpoint API DynamoDB, khiến nhiều dịch vụ phụ thuộc rơi vào sự cố dây chuyền
  • DynamoDB là dịch vụ nền tảng của hạ tầng AWS, nên khi dịch vụ ở khu vực đó sụp đổ thì toàn bộ Internet cũng bị ảnh hưởng
    • Ngân hàng, game, mạng xã hội, dịch vụ chính phủ, mua sắm trên Amazon.com đều bị tê liệt trên diện rộng
  • Từ lúc nhận biết vấn đề đến khi xác định được nguyên nhân mất 75 phút, một phản ứng chậm bất thường nếu nhìn vào truyền thống “khôi phục kiểu mẫu” của AWS
    • Việc mất khá nhiều thời gian từ lúc phát hiện sự cố đến lúc nhận diện nguyên nhân được phân tích là bắt nguồn không hẳn từ thiếu minh bạch mà từ thiếu kinh nghiệm
    • Trong khoảng thời gian này, trang trạng thái vẫn chỉ hiển thị thông báo “đang hoạt động bình thường”, nên đã hứng chịu chỉ trích từ cộng đồng

‘Lời tiên tri’ thành hiện thực: Cảnh báo từ những người đã nghỉ việc

  • Theo truyền thống, AWS từng tự hào về năng lực vận hành hạ tầng ở mức rất cao, đến mức chỉ cần một region gặp sự cố cũng đủ trở thành vấn đề lớn; nhưng khi độ phức tạp tăng cao và các sự cố tương tự quá khứ lặp lại, kinh nghiệm thực chiến tại hiện trường trở nên quan trọng
  • Cựu kỹ sư AWS Justin Garrison khi rời công ty năm 2023 đã cảnh báo rằng “các sự kiện quy mô lớn (LSE) đang gia tăng”
    • Ông dự đoán “sẽ có một sự cố nghiêm trọng trong năm 2024”, và đợt sự cố lần này được xem như đã chứng minh điều đó
  • Làn sóng nghỉ việc liên tiếp của các kỹ thuật gia cấp cao bên trong AWS vẫn tiếp diễn,
    và cùng với đó là sự thất thoát của tribal knowledge tích lũy qua nhiều thập kỷ (kiến thức nội bộ dựa trên kinh nghiệm)
  • Với các sự cố như lỗi DNS, điều cần thiết không chỉ là người biết nguyên nhân kỹ thuật,
    mà còn là người nhớ được rằng “liệu hệ thống này trước đây từng gây ra vấn đề tương tự hay chưa”
    • Nhưng những người giữ ký ức đó đã rời công ty vì phản đối RTO(chính sách quay lại văn phòng) và do cắt giảm nhân sự

Bằng chứng về chảy máu nhân tài

  • Trong giai đoạn 2022~2025, hơn 27.000 nhân viên Amazon đã bị cắt giảm,
    và dù tỷ lệ theo từng bộ phận không được công bố, AWS cũng được cho là đã chịu ảnh hưởng trực tiếp
  • Theo tài liệu nội bộ, “tỷ lệ nghỉ việc đáng tiếc” lên tới 69~81%,
    nghĩa là những người rời đi chính là nhóm nhân sự mà công ty muốn giữ lại
  • Khi sự bất mãn do lệnh quay lại văn phòng(Return to Office) bùng nổ,
    đã có nhiều báo cáo cho thấy các kỹ sư kỳ cựu giàu kinh nghiệm rời công ty hàng loạt
  • Kết quả là AWS đã được tái cơ cấu thành các đội ngũ chi phí thấp nhưng thiếu kinh nghiệm,
    khiến năng lực vận hành một hạ tầng phức tạp ngày càng suy yếu

Vấn đề mang tính cấu trúc: ‘Frugality’ bị biến chất

  • Trước đây, Frugality(tính tiết kiệm) là một giá trị cốt lõi của Amazon,
    mang triết lý “tối đa hóa hiệu quả với ít tài nguyên hơn”
  • Nhưng gần đây nó đã biến tướng thành ý nghĩa “xử lý mọi thứ gần như không có tài nguyên”
    • Việc cắt giảm nhân sự đã khiến ngay cả bảo trì cơ bản cũng trở nên khó khăn
  • Đây là vấn đề phát sinh không phải vì công nghệ đã cũ, mà vì người duy trì nó lại còn mới

Triển vọng sắp tới

  • Thị trường có thể sẽ xem sự cố lần này là hiện tượng đơn lẻ, nhưng cấu trúc của vấn đề vẫn còn đó
    • Nhân sự giàu kinh nghiệm rời đi, độ phức tạp hệ thống tăng lên,
      tạo thành một vòng lặp khiến khả năng xảy ra “sự cố tiếp theo” ngày càng cao
  • AWS nhiều khả năng sẽ công bố sự việc lần này là “một sự cố đơn lẻ bị cô lập”,
    nhưng nếu khoảng trống nội bộ tiếp tục tích lũy thì nguy cơ tái diễn các sự cố lớn tương tự sẽ rất cao
  • Như cách nói “chickens are coming home to roost”,
    mất mát vốn nhân lực chứ không phải công nghệ đang nổi lên như rủi ro lớn nhất của AWS

8 bình luận

 
jjw9512151 2025-10-23

Đúng là ở đâu có con người thì cũng như nhau cả..

 
shakespeares 2025-10-21

Đây đúng là câu chuyện có thể thấy ở mọi thị trường.
Có vẻ như bí quyết và kinh nghiệm của kỹ thuật IT cũng nên được đối xử tương tự như tay nghề của một thợ hàn lành nghề.

 
bus710 2025-10-21

Tôi chợt nhớ đến một bài viết mình đọc cách đây không lâu, rằng ở Amazon, từ cấp kỹ sư cao cấp level 2 để bước tiếp lên cấp tiếp theo thực sự rất khó, không hiểu sao. Tôi nghĩ những việc như kiểu nghỉ việc đầy tiếc nuối đó có lẽ xảy ra đặc biệt nhiều ở chính khoảng này.

 
botplaysdice 2025-10-23

Ngược lại, ở phía trên có lẽ bạn sẽ nghĩ rằng: 'Cắt giảm nhiều đến thế mà vẫn xoay xở được tới mức này sao...'

 
tujuc 2025-10-21

Ở Hàn Quốc, khi kỹ sư đạt đến một mức độ nhất định thì hầu như đều trở thành quản lý nên bị đứt quãng... Ở Mỹ thì lại thành vấn đề vì dưới danh nghĩa tối ưu hóa, họ sa thải hết các nhân sự senior... Thật sự không hề dễ dàng...

 
t7vonn 2025-10-21

Đã làm tới mức multi-AZ rồi mà... giờ còn phải chuẩn bị cả cho sự cố ở cấp độ region nữa sao..

 
skageektp 2025-10-22

Tôi nghĩ cũng cần cân nhắc liệu chi phí đó có thực sự lớn hơn chi phí tổn thất hay không.

 
GN⁺ 2025-10-21
Ý kiến trên Hacker News
  • Giữa các nhân viên kỹ sư và công nhân kho, giờ tôi có cảm giác rằng nếu cứ tiếp tục sa thải nhân viên như thế này thì ngày mà ngay cả những người từng làm ở công ty này trước đây cũng rời đi hết sẽ không còn xa nữa
    Dù có hàng trăm nghìn ứng viên kỹ sư H1-B và hàng chục triệu lao động kho là người nhập cư bất hợp pháp đi nữa, nếu một công ty lớn như vậy sa thải hàng loạt quá nhanh thì cuối cùng nguồn nhân lực cũng sẽ cạn kiệt
    Tình huống này làm tôi nhớ đến tập parody Star Wars của Robot Chicken. Trong đó các sĩ quan Đế chế giả vờ bị Darth Vader Force choke rồi giả chết để khỏi bị chém bằng lightsaber, sau đó quay lại với tên khác, còn Amazon thì còn tệ hơn thế. Chẳng ai muốn quay lại nữa cả
    https://www.youtube.com/watch?v=fFihTRIxCkg

    • Nói thật thì, tôi chưa thấy kỹ sư nào thực sự giỏi lại muốn làm ở Amazon lần thứ hai

    • Trong kho thật sự có nhiều người nhập cư bất hợp pháp đến vậy sao? Theo tôi biết thì Amazon đối chiếu danh tính và kiểm tra giấy tờ khá kỹ, thỉnh thoảng có thể có người mạo danh nhưng tôi không nghĩ số đó nhiều đến thế

    • Vấn đề không chỉ là sa thải, tôi còn nhớ ngay khi Amazon áp dụng RTO toàn diện thì tôi nhận được một trận bom email từ recruiter

    • Có vẻ đang tồn tại bầu không khí định kiến về năng lực kỹ sư chỉ vì họ là H-1B
      Trước đây tôi cũng từng làm việc bằng H-1B, giờ đã quay lại Ấn Độ để xây dựng công việc kinh doanh của mình. Tôi từng làm ở Amazon. Đó là một nơi khắc nghiệt, nhưng hồi giữa những năm 90 vẫn đáng làm vì còn có stock option
      Tôi tự tin rằng mình code giỏi hơn khá nhiều người ở đây. Và trong số những người H-1B quanh tôi cũng có rất nhiều người thật sự xuất sắc
      Đừng mang định kiến, hãy đánh giá năng lực trực tiếp. Nếu đánh giá thấp đối thủ cạnh tranh thì cuối cùng chính bạn sẽ thiệt

  • Đây chính là lúc cần giữ người và cung cấp cho họ những công cụ tốt nhất để họ có thể làm việc hiệu quả
    Các công cụ phát triển đang tiến bộ mỗi ngày, và dù trước mắt có thể cắt giảm nhân sự thì hiệu quả cũng sẽ không đến ngay lập tức
    Đó là kiểu chống đỡ hiện tại bằng cách đem tăng trưởng tương lai và tính bền vững của tổ chức ra đánh đổi. Có tự huyễn hoặc thì việc downsizing cũng không diễn ra tốt hơn đâu

    • Trên thực tế thì chiến lược này có vẻ đang hiệu quả. Họ sa thải một phần tư số principal engineer cấp junior, nhưng giá cổ phiếu vẫn tăng, và sau đó ngay cả khi có sự cố diện rộng thì giá cổ phiếu lại còn tăng tiếp. Trước mắt chiến lược của họ có vẻ đang vận hành tốt

    • Giờ thì ngay cả những công ty big tech từng là “tân binh” cũng đang bước vào thời kỳ tập đoàn già nua kiểu IBM

    • Không phải là họ không biết tỷ lệ nghỉ việc cao là điều xấu, mà có vẻ ngay từ khâu thiết kế đội ngũ họ đã đi theo hướng bình quân hóa toàn bộ nhân viên ở mức trung bình và biến họ thành nguồn lực con người có thể thay thế lẫn nhau
      Giờ thì đến cả việc đơn giản là quá giỏi cũng bị xem như “văn hóa cao bồi”

  • Việc quá trình xử lý sự cố thực sự bắt đầu đúng lúc bờ Tây Mỹ bắt đầu ngày làm việc khiến tôi thấy khá đáng ngờ
    Các cập nhật trước đó chỉ nói là “đang theo dõi, đang triển khai biện pháp giảm thiểu” chứ không có thông tin cụ thể

    • Theo tôi biết thì việc khôi phục hình như diễn ra vào khoảng 4 giờ sáng theo giờ Seattle. Giờ làm việc thường là 9 giờ, nên có thể theo giờ New York là khoảng 6 giờ sáng thì họ đã bắt đầu rồi

    • Bài tôi đọc trên Reddit sáng nay giờ thấy càng có ý nghĩa hơn

  • AWS vẫn là cloud tôi thích nhất và tôi đang dùng nó rất hiệu quả
    Tôi cũng từng nghĩ ít nhất nên thử làm ở AWS một lần, nhưng nếu chưa chắc một số lo ngại đã được giải quyết hay chưa thì lại phải suy nghĩ nhiều

  1. Tin đồn về văn hóa công ty khắc nghiệt, và việc manager phải bảo vệ nhân viên khỏi nền văn hóa đó (dù chưa thể sửa ngay toàn bộ Amazon hay cả khối white-collar thì ít nhất cũng cần xây dựng niềm tin của ứng viên từ các team trong AWS trước)
  2. Ngay cả kỹ sư nhiều kinh nghiệm cũng vẫn phải trải qua những vòng coding screening vô nghĩa hoặc phỏng vấn trả lời STAR về các leadership principle
    Nếu manager tương lai còn không bảo vệ được ứng viên ngay trong quy trình như vậy, thì tôi lo họ cũng sẽ không bảo vệ được nhân viên trước những vấn đề văn hóa công ty nghiêm trọng hơn
  3. Việc chuyển sang RTO và các cáo buộc rằng nó được xử lý theo cách không phù hợp với những nguyên tắc cấp cao
  4. Có vẻ phải lên Principal mới thoát được trực on-call, nhưng dù vậy cũng cần tránh dồn quá tải cho đồng nghiệp và phải lưu ý để khác biệt lịch ngủ không tạo ra cảm giác khó xử giữa mọi người
    Có một ý tưởng có thể áp dụng cho toàn bộ FAANG hiện nay: cần liên tục củng cố nhận thức rằng đây là nơi những người thực sự giỏi muốn đến
    Meta chủ yếu xây dựng thương hiệu bằng mức lương cao hơn và các bản phát hành open source·open hardware, còn Google thì từng nhấn mạnh lợi thế kỹ thuật và văn hóa công ty ấm áp (A.K.A. văn hóa rèn luyện nhân viên mới, giờ thì đã mang tính hình thức)
    AWS cũng đã có rất nhiều nhân tài kỹ thuật đáng tự hào, và tôi nghĩ họ cần đầu tư vào việc thu hút cũng như giữ chân những người này, đồng thời chủ động quảng bá hình ảnh đó ra toàn ngành
  • Tôi đã thấy điều tương tự ở startup
    Sau khi bị thâu tóm, nhân sự cốt lõi thường rời đi khi cổ phiếu của họ vest xong, hoặc bị công ty lớn đẩy ra để đưa người khác vào chỗ đó
    Những người thật sự hiểu công nghệ đều rời đi, và cuối cùng chỉ còn lại một codebase lộn xộn không thể duy trì, dẫn đến tình trạng không ai biết cách sửa các vấn đề phát sinh

  • Tôi rất thích cách El Reg chọc đúng vào bản chất của sự việc

    • Giờ tôi mới nhận ra người viết bài là Corey Quinn, người đã viết rất nhiều về AWS

    • Tôi cũng thích cách các tác giả ở đó viết bài rất duyên, có cá tính và hóm hỉnh

    • Họ luôn đâm trúng bản chất trong mọi chuyện

  • “Sự cố xảy ra và sau 75 phút thì họ thu hẹp được nguyên nhân xuống một service endpoint cụ thể”
    Có thật là chuyện đó mất lâu đến thế không? Tôi không làm web, nhưng cảm giác tìm ra được vấn đề nằm ở đâu trong 75 phút đã là khá nhanh rồi
    Hồi còn làm kỹ sư firmware, có nhiều trường hợp phải mất hàng tuần mới tìm ra chỗ bị hỏng

    • Nếu đó là lỗi chỉ xảy ra với tần suất 0,01%, không có bất kỳ tương quan nào và biến mất khi retry, thì đúng là có thể mất hàng tuần
      Nhưng những chuyện như vậy thường không phải sự cố ưu tiên cao; còn các sự cố thực sự khẩn cấp thì thường có thể tái hiện được, và là kiểu một giờ trước còn bình thường mà giờ đột nhiên nổ tung
      Thông thường, nếu là hệ thống cốt lõi của doanh nghiệp được thiết kế tử tế thì chẩn đoán sẽ không mất quá 75 phút. Dĩ nhiên, sửa xong có thể lâu hơn
      Dù vậy cũng không thể nói những hệ thống lý tưởng như thế ngoài đời là phổ biến

    • Với công ty bình thường thì 75 phút có thể không phải là lâu. Nhưng nếu đó là cloud lớn nhất thế giới và phần lớn Internet bị tê liệt thì lại là chuyện khác

    • Trên thực tế, trong thông báo chính thức họ viết là ‘vẫn đang điều tra’, nhưng nội bộ có thể đã suy đoán được nguyên nhân nhanh hơn thế
      Nếu vội cập nhật thì người dùng có thể hiểu lầm không cần thiết, nên cẩn thận là đúng

    • Theo tôi thì 75 phút là gần như tốc độ cao nhất cho việc chẩn đoán bất kỳ sự cố nghiêm trọng nào

    • Amazon được biết đến là sở hữu hạ tầng thuộc hàng tốt nhất ngành
      Vì các công ty khác đều đang dùng hạ tầng Amazon, nên người ta kỳ vọng những nhân sự cấp SRE có thể tóm được kiểu sự cố này thật nhanh

  • Chính kiến thức kinh nghiệm và bí quyết đang dần biến mất trong tổ chức mới là giá trị thật sự quan trọng, đến mức khó mà ghi hết vào một bảng Excel được

    • Nhưng mà, vậy thì ít nhất cũng phải quy đổi được bí quyết đó thành bao nhiêu dòng code, hoặc chí ít là bao nhiêu token, để chúng ta còn có dữ liệu tham khảo lúc sa thải chứ!
  • Khi trong tổ chức, những người chỉ chăm xây dựng thương hiệu cá nhân hoặc các đợt tuyển dụng mang tính trình diễn được ưu tiên hơn người thật sự giỏi và các chuyên gia gắn bó lâu năm, thì lực lượng kỹ thuật cốt lõi hiểu hệ thống bắt đầu bị đẩy ra ngoài
    Khi sự mất cân bằng này phình to như ở AWS, các LinkedIn celeb và nhân sự DEI kiểu checklist sẽ lấn át những người builder thực thụ, còn chất lượng thực thi, tinh thần trách nhiệm và độ hoàn thiện kỹ thuật sẽ dần suy yếu
    Giờ có vẻ ngày càng rõ rằng ban lãnh đạo của Andy Jassy không hiệu quả, và chẳng bao lâu nữa có khi Phố Wall sẽ chính thức yêu cầu thay thế ông ấy

    • Thật lạ khi đổ lỗi cho DEI gây ra sự cố mà không có lấy một bằng chứng
  • Về chuyện nói rằng The Register là một cơ quan báo chí được kính trọng, thật ra tôi có cảm giác là chính họ cũng chẳng muốn bị gọi như vậy đâu...