21 điểm bởi GN⁺ 2026-03-11 | 6 bình luận | Chia sẻ qua WhatsApp
  • Sau khi liên tiếp xảy ra sự cố dịch vụ liên quan đến việc sử dụng công cụ lập trình AI, Amazon đã áp dụng quy trình phê duyệt trước bởi kỹ sư cấp cao đối với mọi thay đổi mã có AI hỗ trợ
  • Theo ghi chú nội bộ, nguyên nhân sự cố được chỉ ra là "việc sử dụng GenAI mới mà các thông lệ tốt nhất và biện pháp bảo vệ vẫn chưa được thiết lập đầy đủ"
  • Trong tháng này, website và ứng dụng mua sắm của Amazon đã ngừng hoạt động khoảng 6 giờ, khiến khách hàng không thể hoàn tất giao dịch, kiểm tra thông tin tài khoản hay tra cứu giá; nguyên nhân là do triển khai sai mã phần mềm
  • Tại AWS, trợ lý lập trình AI Kiro cũng đã xóa và tạo lại môi trường, gây ra sự cố kéo dài 13 giờ; như vậy đã có ít nhất hai sự cố liên quan đến AI được ghi nhận
  • Khi rủi ro vận hành từ việc đưa công cụ lập trình AI vào production trở thành hiện thực, Amazon đã ngay lập tức áp dụng biện pháp bắt buộc kỹ sư cấp cao ký duyệt các thay đổi có AI hỗ trợ do kỹ sư junior và mid-level thực hiện

Các cuộc họp nội bộ và biện pháp ứng phó của Amazon

  • Bộ phận thương mại điện tử của Amazon đã triệu tập một cuộc họp kỹ thuật quy mô lớn để phân tích chuỗi gián đoạn dịch vụ liên tiếp gần đây
    • Chương trình họp có bao gồm các sự cố liên quan đến việc sử dụng công cụ lập trình AI
    • Ghi chú briefing nội bộ cho biết trong vài tháng gần đây, số sự cố “rủi ro cao (high blast radius)” đã gia tăng, và “các thay đổi có hỗ trợ Gen-AI” được nhắc đến như một yếu tố chính
  • Tài liệu cũng nêu rõ “các trường hợp sử dụng GenAI mới vẫn chưa được thiết lập đầy đủ” là một yếu tố góp phần gây ra sự cố
  • Phó chủ tịch cấp cao Dave Treadwell cho biết trong email rằng “gần đây khả năng sẵn sàng của site và hạ tầng là không tốt”

Các trường hợp sự cố liên quan đến AI

  • Website và ứng dụng mua sắm của Amazon đã gián đoạn khoảng 6 giờ vào đầu tháng này, và nguyên nhân được xác định là “triển khai sai mã phần mềm”
    • Vì vậy khách hàng không thể hoàn tất giao dịch, kiểm tra thông tin tài khoản, tra cứu giá sản phẩm
  • Tại AWS, sự cố cũng xảy ra trong quá trình sử dụng trợ lý lập trình AI Kiro
    • Vào giữa tháng 12, Kiro đã quyết định “xóa rồi tạo lại” môi trường, khiến dịch vụ máy tính chi phí bị gián đoạn 13 giờ
    • Amazon mô tả đây là “một sự cố rất hạn chế, chỉ giới hạn trong một dịch vụ đơn lẻ ở một số khu vực thuộc Trung Quốc đại lục
    • Về sự cố thứ hai, Amazon nói thêm rằng “không có ảnh hưởng đến các dịch vụ AWS hướng tới khách hàng

Quy trình phê duyệt mới và cải thiện vận hành

  • Treadwell dự kiến sẽ thảo luận nguyên nhân vấn đề và các biện pháp cải thiện ngắn hạn thông qua cuộc họp hằng tuần ‘This Week in Stores Tech (TWiST)’
    • Cuộc họp vốn trước đây chỉ tham gia tùy chọn nay đã được chuyển thành khuyến nghị toàn bộ nhân viên tham dự
  • Từ nay, mọi thay đổi mã có AI hỗ trợ do kỹ sư junior và mid-level thực hiện đều phải có chữ ký phê duyệt của kỹ sư cấp cao
  • Amazon coi đợt rà soát này là “một phần của hoạt động kinh doanh bình thường” và đặt mục tiêu cải tiến liên tục

Tranh cãi về cắt giảm nhân sự và số sự cố gia tăng

  • Financial Times đưa tin một số kỹ sư cho biết sau các đợt cắt giảm nhân sự, số sự cố cấp ‘Sev2’ (mức gián đoạn trung bình cần phản ứng nhanh) đã tăng lên
  • Amazon trong những năm gần đây đã tiến hành nhiều đợt tái cơ cấu, và chỉ riêng tháng 1/2026 đã cắt giảm 16.000 vị trí khối doanh nghiệp
  • Tuy nhiên, công ty không đồng tình với nhận định rằng cắt giảm nhân sự là nguyên nhân khiến sự cố gia tăng

Hướng đi sắp tới

  • Amazon đang biến việc rà soát khả năng sẵn sàng của website và đánh giá hiệu suất vận hành thành hoạt động định kỳ
  • Công ty đồng thời thúc đẩy việc sử dụng an toàn công cụ lập trình AI và tăng cường hệ thống phòng ngừa sự cố
  • Động thái này được đánh giá là một ví dụ nữa cho thấy tầm quan trọng của quy trình kiểm chứng bởi con người trong bối cảnh AI đang được triển khai ngày càng rộng rãi

6 bình luận

 
click 2026-03-11

Việc kỹ sư cấp cao review mã do AI tạo ra cũng không thể đảm bảo là an toàn.
vụ CrowdStrike không phải do AI,
Heartbleed cũng là sự cố từ thời chưa có AI.

Kết cục thì cốt lõi vẫn là muốn quy trách nhiệm cho một ai đó,
và vì về mặt pháp lý phải có con người chịu trách nhiệm nên tôi lại nhớ đến kiểu hài đen của mấy anh chị kế toán thuế từng nói rằng chúng ta sẽ không bị thay thế.

 
sea715 2026-03-11

Đúng vậy, nên có lẽ chuyện này sẽ còn tiếp diễn trừ khi họ đưa vào AI agent thứ gì đó giống như chữ ký pháp lý..

 
click 2026-03-11

Vậy thì chi phí sử dụng Anthropic hay OpenAI chắc sẽ phải tăng lên mức khổng lồ nhỉ
Vì mỗi lần gọi API lại phải trả phí bảo hiểm mà

 
sea715 2026-03-11

Ừm... tuy chỉ là suy đoán thôi, nhưng tôi có cảm giác kiểu như IAM sẽ lại xuất hiện thứ gì đó tương tự...

 
yeobi222 2026-03-11

Người ta bảo kế toán thuế là người phải vào tù, nhưng công ty bảo hiểm đâu có đi tù thay được, nên rốt cuộc là...

 
GN⁺ 2026-03-11
Ý kiến trên Hacker News
  • “mandatory meeting” lần này là cuộc họp vận hành toàn công ty diễn ra hằng tuần
    Chỉ là vì tuần trước có sự cố vận hành lớn nên tỷ lệ tham dự tuần này cao hơn thôi
    Có cảm giác báo chí đang phóng đại quá mức

    • Mỗi khi đọc tin tức về một việc mà mình biết rõ tình hình nội bộ, cảm giác về độ chân thực lúc nào cũng khác
    • Bài báo nói rằng “thường thì tham dự là tùy chọn nhưng lần này có yêu cầu tham dự”, nên tôi tò mò không biết điều đó có đúng không
      Ngoài ra còn nhắc đến chính sách “thay đổi mã do AI hỗ trợ của kỹ sư junior và mid-level phải được senior phê duyệt”
      Dù là cuộc họp định kỳ, nếu có công bố chính sách mới thì tôi nghĩ vẫn đáng để đưa tin
    • Ở New York, storefront của Amazon bị sập suốt chiều thứ Sáu tuần trước
      Giá không hiển thị và cũng không thể thêm hàng vào giỏ
      Nếu đó là đối thủ như Walmart thì chắc đã lên tin rồi, nên thấy khá lạ
    • Có vẻ thread này đã được gộp từ một bài có tiêu đề khác. Thời gian của bình luận còn sớm hơn rất nhiều so với bài gốc
    • Tôi đồng ý với ý “báo chí phóng đại”. Từ khi có cable news thì chuyện đó lúc nào cũng vậy
  • Chính sách “junior và mid-level engineer không được push mã AI nếu không có senior phê duyệt”
    có vẻ xuất phát từ ảo tưởng rằng senior review là lời giải vạn năng
    Trên thực tế, nếu senior phải xác minh đầy đủ đoạn mã thì thời gian bỏ ra gần như ngang với việc tự viết
    Tức là review có giá trị, nhưng nó không biến mã tệ thành mã tốt
    Cuối cùng, vấn đề là khi xây một hệ thống “idiot proof” thì người ta lại ngộ nhận rằng có thể thuê cả ‘idiot’ cũng được

    • Hồi đầu sự nghiệp, mentor của tôi từng nói “code review không phải để bắt bug mà là để chia sẻ ngữ cảnh
      Việc phát hiện bug chỉ là tác dụng phụ, còn điều thực sự quan trọng là làm cho việc test dễ hơn và giảm độ phức tạp của mã
      Nhưng những việc như vậy lại không giúp ích cho chuyện thăng tiến
    • Muốn mã do AI tạo ra dùng được thì expert review là bắt buộc
      Hiệu quả nhất là phải giám sát từ ngay khi model đang làm việc
      Nếu không thì AI sẽ tuôn ra cả một quả bom mã chất lượng thấp
      Nếu chuyên gia bỏ ra thời gian gấp 5–15 lần để sửa thì còn tạm ổn, còn không thì codebase sẽ bị phá nát
    • Review code của người khác nhiều khi còn chậm và rối hơn tự mình viết
      Đặc biệt là code tệ thì thời gian để hiểu còn tăng gấp đôi
    • Tôi thấy sửa code cẩu thả còn khó hơn viết mới
      Vì phải giữ đồng thời code cũ và cách giải mới trong đầu để so sánh, nên tải nhận thức rất lớn
    • Nếu AI giúp junior tăng năng suất gấp 10 lần, thì phải cân nhắc là tăng số senior lên 10 lần hay giảm số junior đi
      Rốt cuộc có vẻ đây là một bước tiến hóa tự nhiên khi doanh nghiệp chuyển sang tập trung vào quản trị hiệu suất trung bình
  • Bên trong Amazon, đa số chỉ quan tâm đến chuyện không bị sa thảiđược thăng chức
    Đánh giá lập trình viên được quyết định bởi “tốc độ xử lý ticket”, “số lượng comment trên PR”, và “viết tài liệu”
    Không dùng AI thì sẽ bị tụt lại trong cạnh tranh
    Trong cấu trúc như vậy, yêu cầu “hạn chế dùng AI” trên thực tế rất khó vận hành

    • Dù là để lại quá nhiều comment trên PR hay không để lại comment trên PR của người khác thì đều sẽ bị bất lợi
    • Nhiều thảo luận trên PR cũng có thể là dấu hiệu cho thấy ai đó làm việc một mình mà không cộng tác
      Team phối hợp tốt thì thảo luận trên PR lại ít hơn
    • Kết luận: đừng làm việc trong một văn hóa cạnh tranh kiểu Hunger Games
  • Tôi nghĩ thứ thực sự cần là quy trình self-review
    Push thẳng code do AI viết ra là rất nguy hiểm
    Nên thêm tùy chọn “bắt buộc self-review” ở những nơi như GitHub để tác giả phải xác nhận rằng mình đã tự kiểm tra

    • Chỉ lướt qua output của AI thì không phải review. Cần mức độ hiểu kiểu ‘grok’ theo nghĩa Heinlein
    • Tôi dùng git và Sublime Merge, và đã tạo thói quen tách riêng việc chỉnh sửa và review
      Vì UI cục bộ nhanh nên tôi nắm được luồng của dự án tốt hơn
    • Với những người còn chẳng đọc lại code của chính mình thì thêm một cái nút nữa cũng vô ích
    • Chỉ riêng self-review thôi cũng có thể bắt được các lỗi như debug output
    • Team của chúng tôi đã thêm checklist self-review vào mẫu PR
      Nghe có vẻ hiển nhiên, nhưng thực tế là nó có ích
  • Mức độ tin cậy vào ban lãnh đạo của Amazon đang giảm đi
    Kỹ sư kỳ cựu nghỉ việc, chất lượng AI đi xuống, và các sự cố xảy ra thường xuyên khiến người ta có cảm giác năng lực kỹ thuật đang suy sụp

    • Cũng dễ hiểu khi những senior lâu năm không muốn dành thời gian chỉ để review code AI
  • Có vẻ những người ra quyết định không hiểu nút thắt cổ chai của pipeline
    Dù AI có tạo diff nhanh hơn gấp 10 lần, nếu review vẫn là nút thắt thì tốc độ tổng thể cũng không đổi
    Kết quả là chỉ tăng chi phí và độ bất định

    • Có lẽ bước tiếp theo sẽ là ý tưởng “để AI review code do AI viết”
  • Nếu AI code review diễn ra ở bước PR thì lợi thế năng suất sẽ biến mất
    AI có thể làm ra một tính năng trong 10 phút, nhưng review của con người lại tốn thời gian gấp 10–20 lần
    Điều thật sự khó là biết “cần làm cái gì và vì sao” cũng như “đã làm đúng chưa”
    AI vẫn chưa làm được hai chuyện đó

    • Từ góc nhìn của CEO, nếu cuối cùng con người vẫn phải tự xem xét thì lợi thế tốc độ của AI trở nên vô nghĩa
      Cho đến khi LLM làm tốt cả sản xuất lẫn review thì rủi ro chỉ tăng thêm
    • Nếu senior phải phê duyệt mọi PR thì họ sẽ trở thành reviewer code chuyên trách
      Đây là một chính sách không khả thi trong thực tế
    • Những người ủng hộ AI tin rằng rồi một ngày model sẽ được cải thiện và nút thắt review sẽ biến mất
      Khi đó sẽ đến thời kỳ test xong là có thể deploy ngay
    • Thật đáng ngạc nhiên khi lãnh đạo lại không biết thực tế này
    • Thực ra có lẽ lãnh đạo cũng biết. Đây chỉ là một cái phanh để ngăn chất lượng code suy giảm
  • Bản chất của code review không phải là phát hiện lỗi mà là đồng bộ hóa team và học hỏi
    Thông qua review, mọi người chia sẻ thiết kế và tiêu chuẩn, đào tạo junior, và đưa nhiều góc nhìn khác nhau vào
    Chính quá trình đó mới là cốt lõi để giảm lỗi ngay từ đầu

    • Như Deming từng nói, nguyên tắc “inspection does not improve quality” cũng áp dụng cho phần mềm
      Vì nếu đi sai hướng từ khâu thiết kế thì rất khó quay lại
  • Cơn sốt AI đang ngốn quá nhiều thời gian và tiền bạc

    • Nhưng hiện giờ lại không có thứ gì khác để theo đuổi
    • Không xác minh code thì rốt cuộc cũng giống như đánh bạc
  • Tôi lo cho tương lai của phần mềm hạ tầng quan trọng
    Nếu cả phần mềm hàng không cũng bị cuốn theo xu hướng này thì có thể dẫn đến hậu quả chết người

    • Dù vậy, code cho hạ tầng cốt lõi có lẽ vẫn sẽ tiếp tục được viết theo hướng lấy con người làm trung tâm
      AI nhiều khả năng sẽ được dùng như công cụ hỗ trợ để nâng cao chất lượng mà thôi