Tôi hiểu việc tìm thấy sự hài hước trong thảm họa này, nhưng tôi thắc mắc trách nhiệm thuộc về ai thì sẽ thế nào
Tôi đã thấy trên HN vài lần nói rằng sự cố này gây thiệt hại hàng tỷ đô la, nhưng vẫn chưa thấy nhiều chuyện kiện tụng
Có phải giấy phép của họ kín kẽ đến mức khách hàng không có cách nào được bồi thường không? Nếu là người tiêu dùng có PC cá nhân bị treo vài giờ/vài ngày thì tôi còn hiểu được, nhưng thật vô lý khi ngành công nghiệp chấp nhận mức phơi nhiễm rủi ro như thế này
Đây cũng là một lý do lớn khiến kỹ thuật xây dựng được xem là một lĩnh vực nghiêm túc. Nếu một cây cầu sập, không chỉ có trách nhiệm tài chính mà còn có khả năng chịu trách nhiệm hình sự, và sinh viên kỹ thuật xây dựng được dạy đi dạy lại rằng nếu hành xử phi đạo đức hoặc chấp nhận rủi ro không thể chấp nhận được với tư cách kỹ sư, họ có thể phải vào tù
Liệu kỹ sư phần mềm có con đường nào để đạt tới mức trách nhiệm giải trình và chuẩn mực thực hành như vậy không?
Kỹ thuật xây dựng khác ở chỗ nó thiết kế sản phẩm vật lý. Không thứ gì được thiết kế sát đúng ngưỡng giới hạn, mà mọi thứ đều có biên an toàn đủ lớn
Kiểu như tính toán một cây cầu kín xe tải chạy qua trong lúc vừa có bão lớn vừa có động đất, rồi cộng thêm 20%. Nếu không chắc dầm có chịu được không thì làm nó lớn hơn; phép tính sai 0,5% cũng không thành vấn đề lớn
Nếu trong tài liệu thiết kế có lỗi đánh máy khiến người ta định đặt một dầm 150 foot vào khe hở 15,0 foot, nhà thầu thi công sẽ hỏi lại để xác nhận. Vì vậy, cầu sập gần như chắc chắn là kết quả của sơ suất nghiêm trọng
Ngược lại, trong lập trình, chỉ cần một dấu < được dùng thay vì <= cũng có thể tạo ra khác biệt giữa trạng thái bình thường và thiệt hại hàng tỷ đô la. Không lập trình viên nào trên Trái Đất có thể viết một ứng dụng có độ phức tạp không tầm thường mà 100% không lỗi
Ngay cả vi nhân seL4, vốn nêu cao chứng minh tính đúng đắn hình thức, cũng có lỗi. Trình biên dịch và bộ kiểm chứng về mặt kỹ thuật là khả thi, nhưng chúng sẽ không phàn nàn khi bạn bắt chúng làm điều rõ ràng là sai
Việc chấp nhận trách nhiệm gần như không giới hạn cho cả những sai sót nhỏ nhất là điều không người bình thường nào có thể chấp nhận
Nếu muốn quy trách nhiệm cho kỹ sư phần mềm, trước hết phải tìm cách phân biệt giữa sai sót thiện chí thường ngày và sơ suất nghiêm trọng, nhưng việc hình thức hóa điều đó sẽ cực kỳ khó
Khi Delta dọa kiện về khoản thiệt hại 500 triệu đô la, CrowdStrike đã công khai đáp rằng theo hợp đồng, giới hạn trách nhiệm của CrowdStrike chỉ ở mức vài triệu đô la một chữ số
Sau đó họ gửi danh sách nói rằng nếu vụ kiện bắt đầu, họ sẽ yêu cầu trong quá trình cung cấp chứng cứ các kế hoạch sao lưu, kế hoạch chuyển đổi dự phòng, lịch và kết quả kiểm thử, thời điểm diễn tập khôi phục từ bản sao lưu gần nhất, v.v.
Về cơ bản ý là: “Nếu kiện, chúng tôi sẽ đào sâu vào thực hành IT của các anh đến mức còn khiến các anh xấu hổ hơn chúng tôi, và cho thấy lỗi là ở các anh”
Có biện pháp khắc phục, nhưng đúng như đã nói, nó không dành cho người bình thường. Các doanh nghiệp đang và sẽ tiếp tục kiện CrowdStrike, và nhìn vào các tài liệu CrowdStrike công bố thì có vẻ các công ty bị thiệt hại có khả năng thắng rất cao
Có vẻ họ có nhiều khả năng thuyết phục được thẩm phán, bồi thẩm đoàn hoặc trọng tài rằng CrowdStrike đã phạm sơ suất nghiêm trọng, và rõ ràng gây ra thiệt hại trực tiếp cùng tổn hại uy tín gián tiếp cho các doanh nghiệp
Thành thật mà nói, tôi cũng không chắc CrowdStrike có theo kiện đến cùng không. Phần lớn có lẽ sẽ được dàn xếp ngoài tòa, và trong vài năm tới có thể chúng ta sẽ thấy CrowdStrike sụp đổ
Nhiều công ty có bảo hiểm cho các sự cố làm đứt nguồn doanh thu. Giống như bảo hiểm mùa vụ của nông dân hay bảo hiểm thiệt hại thảm họa của các nhà bán lẻ lớn, tôi nghĩ cũng sẽ có thứ gì đó cho tình huống hạ tầng sụp đổ khiến doanh thu về 0 trong một khoảng thời gian
Ngay cả khi tất cả những người bị ảnh hưởng đòi ClownStrike bồi thường 100% thiệt hại, doanh thu của ClownStrike cũng không đủ gánh số thiệt hại đó. Dù muốn làm công ty đóng cửa, bạn cũng không thể thu hồi số tiền gần với thiệt hại thực tế
Vì vậy tôi tò mò rốt cuộc người ta sẽ đề xuất gì. Mã không có lỗi gần như là bất khả thi, và một phần rủi ro là do người dùng chấp nhận
Bạn có thật sự nghĩ phần mềm bắt buộc phải không có 100% lỗi trước khi được sử dụng không? Bạn sẽ chứng minh điều đó bằng cách nào? Nếu vậy thì câu hỏi tiếp theo là mã của chính bạn sạch đến mức nào mà bạn nghĩ điều đó khả thi
Có thể, nhưng câu trả lời là thời gian. Kỹ thuật xây dựng có lịch sử hàng nghìn năm, còn kỹ nghệ phần mềm trẻ hơn rất nhiều và nền tảng của lĩnh vực này vẫn đang thay đổi
Ít nhất ở nước tôi, từ cuối thập niên 1970 đã có các dự luật về chế độ cấp phép cho nhà phân tích hệ thống, lập trình viên máy tính điện tử, người vận hành máy xử lý dữ liệu, nhân viên đánh máy(!)
Nếu những luật như vậy được thông qua, sự phát triển phần mềm ở nước chúng tôi đã tụt lại hàng chục năm. Ví dụ, một dự luật từng muốn chỉ cho phép người có giấy phép “người vận hành máy xử lý dữ liệu” được “thao tác và vận hành thiết bị hoặc máy xử lý điện tử, bao gồm thiết bị đầu cuối (thiết bị số hoặc thiết bị hiển thị)”
Vấn đề này vượt ra ngoài CrowdStrike; nó cho thấy cách tiếp cận bảo mật nói chung: mua sản phẩm bảo mật có sẵn để làm hài lòng cơ quan quản lý và công ty bảo hiểm, trong khi thực sự không quan tâm nó làm gì và hoạt động ra sao
Tôi không có ý nói không nên quản lý công nghệ bằng quy định, nhưng mô hình hiện tại kiểu “mua cái này để giảm trách nhiệm” không hiệu quả
Tệ hơn là những người đã dự đoán được chuyện này, tức bộ phận IT, có lẽ chẳng thể làm gì. Rất có khả năng nó đã bị ban lãnh đạo công ty bắt buộc vì yêu cầu “bảo hiểm an ninh mạng” hoặc quy định nào đó khác. Thật điên rồ
Tôi đã thấy nhiều nhân viên IT giỏi có cảm giác như vậy, nhưng theo kinh nghiệm của tôi, hầu hết bộ phận IT không mấy quan tâm liệu nó có giải quyết vấn đề thực tế hay không, miễn là đáp ứng các mục cần có trong hợp đồng
Ở công ty cũ, một phần mềm tương tự CrowdStrike đã được cài lên workstation của tôi vào cuối tuần, và khi quay lại tôi thấy thời gian biên dịch chậm hơn 20%
Lúc đó tôi đang đo việc đó nên có hàng chục số liệu đo, và đã dùng truy vết ETL cho thấy phần mềm kia là nguyên nhân, nhưng IT không thừa nhận. Vì hợp đồng của nhà cung cấp ghi rằng sẽ không có ảnh hưởng hiệu năng đối với workload của chúng tôi
Phần lớn bộ phận IT có lẽ không lường trước được chuyện này, và việc họ không xây dựng toàn bộ chiến lược bảo mật quanh khả năng đó cũng là điều dễ hiểu. Tôi không biết câu chuyện kiểu này xuất phát từ đâu
Falcon đã và vẫn đang mang lại cho khách hàng lợi ích bảo mật thực tế, có thật. Điều đó không có nghĩa nó loại bỏ mọi rủi ro, cũng không có nghĩa nó không tạo ra rủi ro riêng
Như mọi vấn đề kỹ thuật, đúng nghĩa là một trò chơi của các đánh đổi. Điều này hẳn cũng không xa lạ với những người ở đây
Đột nhiên HN đầy những chuyên gia bảo mật ngập tràn thiên kiến hậu nghiệm và thiên kiến sự kiện mới nhất, giải thích các doanh nghiệp đã có thể né viên đạn này ra sao, nhưng lại không xét đến những viên đạn thật mà họ vốn đang né được nhờ dùng Falcon
Đây là chuyện có thể được dùng làm video bằng chứng trước tòa hoặc trong kiện tụng, không phải chuyện để cười
Vốn dĩ có lẽ chỉ là một khoảnh khắc kín giữa những người mê bảo mật với nhau, nhưng giờ lại bị công khai để công chúng bình thường, những người đã chịu thiệt hại lớn, có thể thoải mái chế giễu
Tôi hoàn toàn không thấy vị lãnh đạo của CrowdStrike xem nhẹ tình hình. Ngược lại, bài phát biểu đó có vẻ như là thừa nhận tình hình một cách nghiêm túc, công nhận đây là một sai lầm khổng lồ, và sẽ tiếp nhận chiếc cúp đó như dấu ấn của sự ô nhục cũng như một câu chuyện cảnh tỉnh cho các nhân viên CrowdStrike trong tương lai
Tôi nghĩ việc vị lãnh đạo đó nhận giải này là một hành động thực sự có phong thái. Tất nhiên, nói như vậy hoàn toàn không có nghĩa là CrowdStrike được miễn trách nhiệm hay nghĩa vụ bồi thường đối với sự cố
Nếu in lên áo thun thì có thể sẽ buồn cười
When I use
REGEXP
I use it in my
KERNEL CODE
Bi kịch và hài kịch là hai mặt của cùng một đồng xu
Vấn đề bảo mật máy tính đã xuất hiện từ thời Chiến tranh Việt Nam, và Mỹ thực sự đã nỗ lực tìm ra các mô hình bảo mật máy tính hiệu quả. Thế nhưng chúng ta đang sống trong một xã hội về cơ bản đã xóa điều đó khỏi ký ức
Tại sao một trình quét phải chạy 24/7 trên mọi thứ mà máy tính định thực thi?
Tại sao hệ điều hành phải dựa vào quyền ngoại vi?
Đổ lỗi cho CrowdStrike chỉ khiến chúng ta rời mắt khỏi thất bại thiết kế căn bản mà hằng ngày chúng ta đều phớt lờ trong các hệ điều hành như Linux, MacOS, Windows, v.v.
Vẫn đang đổ lỗi cho Microsoft, nhưng không phải là không thể chạy phần mã được cập nhật bên ngoài kernel và chỉ dùng mã kernel mode cho việc quan sát và hành động, chứ không dùng cho logic
Tôi làm trong ngành IT, và là người xui xẻo đúng lúc đang on-call khi Clown Strike đánh sập phần lớn hạ tầng
Cá nhân tôi nghĩ rất có thể chúng tôi đã khôi phục trong vài giờ thay vì vài ngày, nhờ đã kiên quyết không dùng mấy thứ nhảm nhí dựa trên cloud
Tôi khá lo rằng chẳng bao lâu nữa chúng tôi sẽ phải đối mặt với một sự cố lớn dựa trên cloud khác, vì những người như giám đốc IT không coi đây là vấn đề và không thực hiện bất kỳ biện pháp nào để ngăn mấy thứ nhảm nhí như vậy
Tôi đã lặp đi lặp lại đến phát chán rằng “chỉ có kẻ ngốc mới phụ thuộc vào máy tính của người khác”, và tôi đồng ý 100% với câu đó
Thật kỳ lạ khi có những quản lý hoặc lãnh đạo hiểu vì sao điểm lỗi đơn lẻ trong hạ tầng nội bộ là xấu, nhưng lại cho rằng việc sản phẩm/dịch vụ của nhà cung cấp bên ngoài trở thành điểm lỗi đơn lẻ thì vẫn ổn
Dường như họ nghĩ rằng chỉ cần ký hợp đồng và trả tiền thì thứ đó sẽ được xây dựng và bảo trì bởi những siêu nhân không bao giờ mắc lỗi, khác với kỹ sư nội bộ. Tôi không hiểu nổi niềm tin sai lầm này
Đồng ý 100%. Hơn nữa, tôi còn ngạc nhiên khi thấy người ta trả chi phí vô lý cho các dịch vụ cloud như Azure VD
Chỉ với một phần ngân sách cloud hằng năm, công ty hoàn toàn có thể tự xây dựng một hạ tầng rất ổn định và có thể hoạt động cả offline
Giọng điệu nghe rất công kích. Dù nói đúng, tôi cũng không nghĩ mình muốn làm việc cùng
Có lẽ nếu không nói hung hăng như vậy thì ý chính sẽ được truyền đạt tốt hơn
Khi những CTO ngớ ngẩn tiếp nhận lời khuyên từ các hội nghị thượng đỉnh CTO, các consultant có động cơ méo mó, và đủ loại hội nghị ngẫu nhiên, thì cũng không làm được gì nhiều
Phần lớn các giải “Thất bại hoành tráng nhất” trước đây đương nhiên do Microsoft thống trị
Có thể tiếp tục chuyền quả bóng bẽ mặt, nhưng nếu tin rằng kiểu sự cố production này là do quy trình tệ, thì Microsoft rõ ràng cũng đóng vai trò lớn ở đây
Tôi thật sự tò mò làm sao CEO và CTO vẫn giữ được ghế sau mớ hỗn độn này
911 không hoạt động ở nhiều thành phố và luồng vận hành bệnh viện chậm đến mức gần như tê liệt, vậy mà vẫn có thời gian đến Defcon để đùa cợt sao?
Vẫn còn bệnh viện nào chưa sửa xong máy tính à? Dĩ nhiên CS đã làm hỏng chuyện, nhưng ngoài bồi thường thiệt hại và thay đổi quy trình thì tôi không biết hiện tại còn có thể làm gì khác
Cảnh báo để mọi người không lặp lại sai lầm tương tự không có vẻ là cách dùng thời gian tệ
Đúng là CS đáng bị chỉ trích ở đây, nhưng tôi cho rằng việc đưa CS vào các hệ thống trọng yếu như 911 tự nó đã là một sai lầm lớn
Tuy nhiên, người làm chuyện đó có lẽ biết rằng mình có thể tránh trách nhiệm, nên chắc cũng chẳng có lý do gì để bận tâm
1 bình luận
Các ý kiến trên Hacker News
Tôi hiểu việc tìm thấy sự hài hước trong thảm họa này, nhưng tôi thắc mắc trách nhiệm thuộc về ai thì sẽ thế nào
Tôi đã thấy trên HN vài lần nói rằng sự cố này gây thiệt hại hàng tỷ đô la, nhưng vẫn chưa thấy nhiều chuyện kiện tụng
Có phải giấy phép của họ kín kẽ đến mức khách hàng không có cách nào được bồi thường không? Nếu là người tiêu dùng có PC cá nhân bị treo vài giờ/vài ngày thì tôi còn hiểu được, nhưng thật vô lý khi ngành công nghiệp chấp nhận mức phơi nhiễm rủi ro như thế này
Đây cũng là một lý do lớn khiến kỹ thuật xây dựng được xem là một lĩnh vực nghiêm túc. Nếu một cây cầu sập, không chỉ có trách nhiệm tài chính mà còn có khả năng chịu trách nhiệm hình sự, và sinh viên kỹ thuật xây dựng được dạy đi dạy lại rằng nếu hành xử phi đạo đức hoặc chấp nhận rủi ro không thể chấp nhận được với tư cách kỹ sư, họ có thể phải vào tù
Liệu kỹ sư phần mềm có con đường nào để đạt tới mức trách nhiệm giải trình và chuẩn mực thực hành như vậy không?
Kiểu như tính toán một cây cầu kín xe tải chạy qua trong lúc vừa có bão lớn vừa có động đất, rồi cộng thêm 20%. Nếu không chắc dầm có chịu được không thì làm nó lớn hơn; phép tính sai 0,5% cũng không thành vấn đề lớn
Nếu trong tài liệu thiết kế có lỗi đánh máy khiến người ta định đặt một dầm 150 foot vào khe hở 15,0 foot, nhà thầu thi công sẽ hỏi lại để xác nhận. Vì vậy, cầu sập gần như chắc chắn là kết quả của sơ suất nghiêm trọng
Ngược lại, trong lập trình, chỉ cần một dấu
<được dùng thay vì<=cũng có thể tạo ra khác biệt giữa trạng thái bình thường và thiệt hại hàng tỷ đô la. Không lập trình viên nào trên Trái Đất có thể viết một ứng dụng có độ phức tạp không tầm thường mà 100% không lỗiNgay cả vi nhân seL4, vốn nêu cao chứng minh tính đúng đắn hình thức, cũng có lỗi. Trình biên dịch và bộ kiểm chứng về mặt kỹ thuật là khả thi, nhưng chúng sẽ không phàn nàn khi bạn bắt chúng làm điều rõ ràng là sai
Việc chấp nhận trách nhiệm gần như không giới hạn cho cả những sai sót nhỏ nhất là điều không người bình thường nào có thể chấp nhận
Nếu muốn quy trách nhiệm cho kỹ sư phần mềm, trước hết phải tìm cách phân biệt giữa sai sót thiện chí thường ngày và sơ suất nghiêm trọng, nhưng việc hình thức hóa điều đó sẽ cực kỳ khó
Sau đó họ gửi danh sách nói rằng nếu vụ kiện bắt đầu, họ sẽ yêu cầu trong quá trình cung cấp chứng cứ các kế hoạch sao lưu, kế hoạch chuyển đổi dự phòng, lịch và kết quả kiểm thử, thời điểm diễn tập khôi phục từ bản sao lưu gần nhất, v.v.
Về cơ bản ý là: “Nếu kiện, chúng tôi sẽ đào sâu vào thực hành IT của các anh đến mức còn khiến các anh xấu hổ hơn chúng tôi, và cho thấy lỗi là ở các anh”
Có vẻ họ có nhiều khả năng thuyết phục được thẩm phán, bồi thẩm đoàn hoặc trọng tài rằng CrowdStrike đã phạm sơ suất nghiêm trọng, và rõ ràng gây ra thiệt hại trực tiếp cùng tổn hại uy tín gián tiếp cho các doanh nghiệp
Thành thật mà nói, tôi cũng không chắc CrowdStrike có theo kiện đến cùng không. Phần lớn có lẽ sẽ được dàn xếp ngoài tòa, và trong vài năm tới có thể chúng ta sẽ thấy CrowdStrike sụp đổ
Ngay cả khi tất cả những người bị ảnh hưởng đòi ClownStrike bồi thường 100% thiệt hại, doanh thu của ClownStrike cũng không đủ gánh số thiệt hại đó. Dù muốn làm công ty đóng cửa, bạn cũng không thể thu hồi số tiền gần với thiệt hại thực tế
Vì vậy tôi tò mò rốt cuộc người ta sẽ đề xuất gì. Mã không có lỗi gần như là bất khả thi, và một phần rủi ro là do người dùng chấp nhận
Bạn có thật sự nghĩ phần mềm bắt buộc phải không có 100% lỗi trước khi được sử dụng không? Bạn sẽ chứng minh điều đó bằng cách nào? Nếu vậy thì câu hỏi tiếp theo là mã của chính bạn sạch đến mức nào mà bạn nghĩ điều đó khả thi
Ít nhất ở nước tôi, từ cuối thập niên 1970 đã có các dự luật về chế độ cấp phép cho nhà phân tích hệ thống, lập trình viên máy tính điện tử, người vận hành máy xử lý dữ liệu, nhân viên đánh máy(!)
Nếu những luật như vậy được thông qua, sự phát triển phần mềm ở nước chúng tôi đã tụt lại hàng chục năm. Ví dụ, một dự luật từng muốn chỉ cho phép người có giấy phép “người vận hành máy xử lý dữ liệu” được “thao tác và vận hành thiết bị hoặc máy xử lý điện tử, bao gồm thiết bị đầu cuối (thiết bị số hoặc thiết bị hiển thị)”
Vấn đề này vượt ra ngoài CrowdStrike; nó cho thấy cách tiếp cận bảo mật nói chung: mua sản phẩm bảo mật có sẵn để làm hài lòng cơ quan quản lý và công ty bảo hiểm, trong khi thực sự không quan tâm nó làm gì và hoạt động ra sao
Tôi không có ý nói không nên quản lý công nghệ bằng quy định, nhưng mô hình hiện tại kiểu “mua cái này để giảm trách nhiệm” không hiệu quả
Tệ hơn là những người đã dự đoán được chuyện này, tức bộ phận IT, có lẽ chẳng thể làm gì. Rất có khả năng nó đã bị ban lãnh đạo công ty bắt buộc vì yêu cầu “bảo hiểm an ninh mạng” hoặc quy định nào đó khác. Thật điên rồ
Ở công ty cũ, một phần mềm tương tự CrowdStrike đã được cài lên workstation của tôi vào cuối tuần, và khi quay lại tôi thấy thời gian biên dịch chậm hơn 20%
Lúc đó tôi đang đo việc đó nên có hàng chục số liệu đo, và đã dùng truy vết ETL cho thấy phần mềm kia là nguyên nhân, nhưng IT không thừa nhận. Vì hợp đồng của nhà cung cấp ghi rằng sẽ không có ảnh hưởng hiệu năng đối với workload của chúng tôi
Falcon đã và vẫn đang mang lại cho khách hàng lợi ích bảo mật thực tế, có thật. Điều đó không có nghĩa nó loại bỏ mọi rủi ro, cũng không có nghĩa nó không tạo ra rủi ro riêng
Như mọi vấn đề kỹ thuật, đúng nghĩa là một trò chơi của các đánh đổi. Điều này hẳn cũng không xa lạ với những người ở đây
Đột nhiên HN đầy những chuyên gia bảo mật ngập tràn thiên kiến hậu nghiệm và thiên kiến sự kiện mới nhất, giải thích các doanh nghiệp đã có thể né viên đạn này ra sao, nhưng lại không xét đến những viên đạn thật mà họ vốn đang né được nhờ dùng Falcon
Đây là chuyện có thể được dùng làm video bằng chứng trước tòa hoặc trong kiện tụng, không phải chuyện để cười
Vốn dĩ có lẽ chỉ là một khoảnh khắc kín giữa những người mê bảo mật với nhau, nhưng giờ lại bị công khai để công chúng bình thường, những người đã chịu thiệt hại lớn, có thể thoải mái chế giễu
Tôi nghĩ việc vị lãnh đạo đó nhận giải này là một hành động thực sự có phong thái. Tất nhiên, nói như vậy hoàn toàn không có nghĩa là CrowdStrike được miễn trách nhiệm hay nghĩa vụ bồi thường đối với sự cố
When I use
REGEXP
I use it in my
KERNEL CODE
Bi kịch và hài kịch là hai mặt của cùng một đồng xu
Qua xcancel: https://xcancel.com/singe/status/1822324795645575263
Vấn đề bảo mật máy tính đã xuất hiện từ thời Chiến tranh Việt Nam, và Mỹ thực sự đã nỗ lực tìm ra các mô hình bảo mật máy tính hiệu quả. Thế nhưng chúng ta đang sống trong một xã hội về cơ bản đã xóa điều đó khỏi ký ức
Tại sao một trình quét phải chạy 24/7 trên mọi thứ mà máy tính định thực thi?
Tại sao hệ điều hành phải dựa vào quyền ngoại vi?
Đổ lỗi cho CrowdStrike chỉ khiến chúng ta rời mắt khỏi thất bại thiết kế căn bản mà hằng ngày chúng ta đều phớt lờ trong các hệ điều hành như Linux, MacOS, Windows, v.v.
Vẫn đang đổ lỗi cho Microsoft, nhưng không phải là không thể chạy phần mã được cập nhật bên ngoài kernel và chỉ dùng mã kernel mode cho việc quan sát và hành động, chứ không dùng cho logic
Tôi làm trong ngành IT, và là người xui xẻo đúng lúc đang on-call khi Clown Strike đánh sập phần lớn hạ tầng
Cá nhân tôi nghĩ rất có thể chúng tôi đã khôi phục trong vài giờ thay vì vài ngày, nhờ đã kiên quyết không dùng mấy thứ nhảm nhí dựa trên cloud
Tôi khá lo rằng chẳng bao lâu nữa chúng tôi sẽ phải đối mặt với một sự cố lớn dựa trên cloud khác, vì những người như giám đốc IT không coi đây là vấn đề và không thực hiện bất kỳ biện pháp nào để ngăn mấy thứ nhảm nhí như vậy
Tôi đã lặp đi lặp lại đến phát chán rằng “chỉ có kẻ ngốc mới phụ thuộc vào máy tính của người khác”, và tôi đồng ý 100% với câu đó
Dường như họ nghĩ rằng chỉ cần ký hợp đồng và trả tiền thì thứ đó sẽ được xây dựng và bảo trì bởi những siêu nhân không bao giờ mắc lỗi, khác với kỹ sư nội bộ. Tôi không hiểu nổi niềm tin sai lầm này
Chỉ với một phần ngân sách cloud hằng năm, công ty hoàn toàn có thể tự xây dựng một hạ tầng rất ổn định và có thể hoạt động cả offline
Có lẽ nếu không nói hung hăng như vậy thì ý chính sẽ được truyền đạt tốt hơn
Danh sách những người từng đoạt Pwnie Award để so sánh: https://en.wikipedia.org/wiki/Pwnie_Awards
Có thể tiếp tục chuyền quả bóng bẽ mặt, nhưng nếu tin rằng kiểu sự cố production này là do quy trình tệ, thì Microsoft rõ ràng cũng đóng vai trò lớn ở đây
Tôi thật sự tò mò làm sao CEO và CTO vẫn giữ được ghế sau mớ hỗn độn này
911 không hoạt động ở nhiều thành phố và luồng vận hành bệnh viện chậm đến mức gần như tê liệt, vậy mà vẫn có thời gian đến Defcon để đùa cợt sao?
Cảnh báo để mọi người không lặp lại sai lầm tương tự không có vẻ là cách dùng thời gian tệ
Tuy nhiên, người làm chuyện đó có lẽ biết rằng mình có thể tránh trách nhiệm, nên chắc cũng chẳng có lý do gì để bận tâm