Sai lầm của tôi giúp công ty tiết kiệm 500.000 USD
(ludic.mataroa.blog)- Một kỹ sư giảm thiết lập nhàn rỗi 10 phút sau khi chạy truy vấn của Snowflake, khiến chi phí cơ sở dữ liệu dự kiến hằng năm giảm từ khoảng 1 triệu USD xuống còn 500.000 USD
- Advanced Analytics Platform, bị trì hoãn nhiều năm, ngay cả sau khi ra mắt vẫn phụ thuộc vào một chuỗi ETL phức tạp đan xen giữa bảng tính, S3, Lambda, MongoDB, Snowflake và stored procedure JavaScript
- Cốt lõi của sự lãng phí chi phí là kiến trúc xử lý chưa đến 1TB dữ liệu mỗi ngày, nhưng compute vẫn bật rất lâu sau những truy vấn trung bình 2 giây
- Thay đổi trước tiên được áp dụng cho một phần compute; quản lý thừa nhận hiệu quả tiết kiệm nhưng vẫn muốn trì hoãn triển khai toàn diện, còn trong PowerPoint thì được đóng gói như một tối ưu hóa thông qua phân tích mẫu sử dụng
- Ngay cả sau khi cắt giảm 500.000 USD, phần thưởng vẫn không chắc chắn, trong khi gánh nặng họp hành và báo cáo chỉ tăng lên; đây trở thành một ví dụ cho thấy sự kém hiệu quả của tổ chức tạo ra chi phí chính trị lớn hơn nhiều so với một hành động ngắn của cá nhân
Nền tảng phân tích bị trì hoãn nhiều năm
- Công ty quyết định xây dựng một nền tảng phân tích và tuyển nhân sự liên quan với mục tiêu làm việc theo hướng dựa trên dữ liệu hơn
- Kỹ sư gia nhập với vai trò nhà khoa học dữ liệu không được làm công việc khoa học dữ liệu thực sự; khi yêu cầu compute cho machine learning hoặc data pipeline, anh được trả lời rằng phải chờ đến khi Advanced Analytics Platform, tức AAP, được triển khai
- Ban đầu AAP dự kiến ra mắt vào tháng 1, nhưng bị lùi sang tháng 3, rồi sau đó bị hoãn với lý do Covid
- Ba năm sau khi anh rời công ty, AAP đã sẵn sàng ra mắt, nhưng hóa ra những tính năng thực sự cần thiết ngay từ đầu lại không có trong kế hoạch
- Cùng tuần đó, 4 kỹ sư rời công ty, và sau khi đưa ra điều kiện, anh gia nhập đội AAP
Nợ kỹ thuật lộ rõ ngay sau khi ra mắt
- Dù mới ra mắt chưa lâu, AAP đã có nhiều nợ kỹ thuật và rủi ro vận hành
- Ngay ngày đầu tiên, một đồng nghiệp mới được tuyển đã phát hiện trong repository của dự án một file có thể xóa production thông qua pipeline CI/CD nếu di chuyển nhầm sang thư mục sai
- File này cũng chứa các khóa và mật khẩu cần cho tài khoản quản trị
- Việc thay đổi quyền truy cập cơ sở dữ liệu chỉ là upload một CSV khoảng 2KB nhưng lại đi qua một lộ trình quá dài
- Python parse bảng tính
- Kết quả được đưa vào S3
- Lambda chuyển đổi lại sang S3
- MongoDB lấy file S3
- Một Lambda khác chuyển bản ghi MongoDB sang S3
- Snowpipe đưa dữ liệu S3 vào Snowflake
- Stored procedure JavaScript pivot dữ liệu Snowflake sang dạng quan hệ
- Đội bảo mật yêu cầu một định dạng có thể dễ dàng quét nội dung độc hại, nên mọi thứ được chuyển thành CSV, nhưng công cụ quét thực tế lại không được triển khai
- Các hàm Lambda bắt đầu bằng
counter = 1, dấu vết của cách triển khai trước đó, và dòng này cứ tiếp tục bị sao chép - Các bài kiểm thử CI/CD vẫn ở trạng thái thất bại trong nhiều tháng vì việc dùng lệnh
teekhi debug đã ghi đè mã lỗi - Việc truy xuất mật khẩu API cũng bị xoắn thành hai bước
- Khi tìm một khóa như
service-passwordtrong dịch vụ AWS, giá trị trả về cũng làservice-password - Giá trị đó lại được dùng trong một dịch vụ khác để tìm mật khẩu thật
- Khi tìm một khóa như
- Script tạo file cấu hình pipeline bắt đầu bằng 600 dòng bị comment, với lý do có thể sẽ cần sau này
Thiết lập Snowflake gây vượt chi phí
- Nền tảng này đắt gấp nhiều lần mô hình vận hành trước đó và vượt xa ngân sách chi phí cơ sở dữ liệu
- Có vẻ chi phí vận hành hằng năm ban đầu được nhắm ở mức khoảng 200.000 USD, nhưng chi phí dự kiến thực tế đã tiến gần 1 triệu USD
- Cơ sở dữ liệu là Snowflake, và Snowflake tính phí theo kích thước máy tính chạy truy vấn
- Compute chỉ phát sinh chi phí khi đang bật
- Đội chạy khoảng vài nghìn truy vấn mỗi tuần, phần lớn là các truy vấn thử nghiệm của developer để chỉnh sửa từng chút các báo cáo PowerBI mà hầu như không ai đọc
- Thời gian chạy truy vấn trung bình khoảng 2 giây, nhưng compute được cấu hình để vẫn ở trạng thái nhàn rỗi trong 10 phút sau truy vấn
- Khoảng một tháng sau khi gia nhập, anh phát hiện thiết lập này và đề xuất điều chỉnh, nhưng chỉ có các cuộc thảo luận mang tính quy trình rằng cần làm discovery, còn việc thực thi thì không diễn ra
Thay đổi 5 phút và kiểm chứng
- Vài tháng sau, khi nhận được thẻ “Discovery: Optimise Costs”, anh cần có kết quả để nói trong buổi standup tiếp theo nên quyết định tự xác nhận giả thuyết cũ
- Anh yêu cầu cấp quyền quản trị cho một kỹ sư mới có vẻ có năng lực ở đội khác, nhưng quản lý không cho phép
- Thay vào đó, anh chia sẻ thông tin xác thực cơ sở dữ liệu cấp thấp không phải quyền quản trị, và kỹ sư đó đã kiểm chứng bằng lẽ thường khả năng tiết kiệm chi phí
- Vào 4 giờ chiều ngày cuối tuần làm việc, sau khi xác nhận trong phòng chat kỹ sư không có quản lý rằng không có vấn đề gì, anh thay đổi thiết lập
- Để an toàn, trước tiên anh chỉ áp dụng cho một phần compute, không phải toàn bộ
Hiệu quả tiết kiệm và phản ứng của tổ chức
- Thứ Hai tuần sau, hóa đơn dự kiến giảm từ khoảng 1 triệu USD xuống còn 500.000 USD
- Đội đóng gói điều này như một thành tích tiết kiệm chi phí lớn, nhưng từ góc nhìn của anh, nó gần như chỉ là chặn khoản tiền vốn đang bị lãng phí
- Các đội khác đặt vấn đề rằng kỹ sư mới gia nhập đúng thời điểm khoản tiết kiệm này xuất hiện, và chất vấn vì sao trước đây không ai biết về khoản tiết kiệm như vậy
- Quản lý vui mừng nhưng cho rằng nếu áp dụng thay đổi ngay cho toàn bộ compute, bộ phận sẽ bị chú ý quá mức và có thể nảy sinh những câu hỏi không mong muốn
- Có hàm ý rằng nên triển khai từ từ để thay đổi trông giống như một công việc mất nhiều thời gian
- Anh phải viết PowerPoint, và câu chữ được tóm lại theo kiểu “phân tích thống kê thận trọng về các mẫu sử dụng đã cho thấy cơ hội phân bổ tài nguyên hiệu quả hơn”
- Thay đổi thực tế chỉ là điều chỉnh thiết lập để compute đắt đỏ không còn ở trạng thái nhàn rỗi cả ngày
Gánh nặng còn lại sau thành tích
- Anh cho rằng nhờ tìm được vài kỹ sư giỏi và hành động không chính thức, anh đã dễ dàng tạo ra thành quả lớn hơn cả bộ phận
- Anh nhận định rằng những người có năng lực vẫn tồn tại trong tổ chức, nhưng cấu trúc tổ chức khiến họ không thể phát huy sức mạnh
- Sau khi tiết kiệm 500.000 USD, anh yêu cầu tăng lương 30.000 USD, nhưng tin nhắn không được đọc; anh dự đoán mình sẽ không nhận được gì, hoặc cùng lắm khoảng 5.000 USD
- Các cuộc họp để nói về việc tiết kiệm chi phí lại tăng thêm, và anh cũng phải gánh việc viết PowerPoint
- Anh kết luận rằng có lẽ không làm gì thì tốt hơn cho bản thân; anh đã hành động trong 5 phút và tạo ra thành tích lớn nhất sự nghiệp, nhưng ngay lập tức phải gánh thêm việc
1 bình luận
Ý kiến trên Hacker News
Toàn bộ bài viết này quá đồng cảm
Hồ sơ sự nghiệp của tôi trong Hải quân Mỹ ghi nhận khoản tiết kiệm chi phí hơn 50 triệu USD. Mỗi lần làm gì đó tôi đều phải làm PowerPoint và trình bày trước các tướng lĩnh, có lần còn suýt bị phạt nặng vì không để cấp trên nhận công. Trớ trêu là cấp trên đó hoàn toàn không biết tôi đã làm gì nên cũng chẳng có ý định nhận công
Một phần trong số đó là thời gian tôi làm các dự án toàn tổ chức với tư cách Lean Six-Sigma Black Belt, và tôi ghét đến mức ghét luôn cả cụm từ đó. Công việc đúng nghĩa là cắt giảm chi phí của DOD nhiều nhất có thể, và đó là giai đoạn tệ nhất trong sự nghiệp của tôi. Đó là phần thưởng cho việc tôi tự ý giải quyết được các vấn đề giúp tiết kiệm hàng triệu đô
Tôi đồng ý với phần cuối bài. Phải cẩn thận khi làm điều tốt ở nơi làm việc. Phần thưởng gần như không bao giờ là tiền, mà là nhiều việc hơn với cùng mức lương
Trước đây tôi từng ở một nơi tốt hơn nhiều, và nếu tôi chủ động đứng ra tiết kiệm hàng triệu đô thì thật sự được chúc mừng, sếp cũng ghi nhận công lao của tôi
Tuyệt đối không nên ở lại một nơi làm việc có văn hóa độc hại. Kể cả khi tiền tốt hơn cũng vậy. Không gì bào mòn tâm hồn bằng việc bị đè nén bởi những kẻ cơ hội vô năng, nhỏ nhen và những người cuồng kiểm soát
Ý chính là “Điểm hay của chính phủ Mỹ là nó quá lớn, nên nếu phương án tối ưu tiết kiệm 30% mà phương án hạng hai chỉ tiết kiệm 29%, thì vẫn tiết kiệm được hàng chục đến hàng trăm triệu đô và chẳng ai nhận ra”
Một trong các dự án lớn là hiệu quả năng lượng của các doanh trại quân sự xa xôi. Khi chuyển nhiên liệu đến một số khu vực ở Afghanistan, chi phí khoảng 100 USD mỗi gallon, trong khi các máy phát điện di động chạy hàng loạt chỉ ở mức 20–40% công suất. Theo tôi nhớ thì khoảng 70% là hiệu quả nhất; bằng cách dựng các tòa nhà nhỏ hoặc gom nhiều lều vào một máy phát, có thể giảm đáng kể lượng nhiên liệu sử dụng và cải thiện cả chất lượng dịch vụ
Tôi từng làm kỹ sư FAANG trong những công việc liên quan trực tiếp đến dòng tiền, và cũng có kinh nghiệm ở nhiều lĩnh vực có thể hữu ích
Rồi tôi lại nghĩ rằng việc tìm đúng người và đúng mảng để làm có lẽ chiếm 95% công việc, nên cuối cùng bỏ cuộc
Thế nhưng nếu học các khóa đó thì cơ chế thăng chức lại đẩy lên rất nhanh
Tôi muốn một công việc làm công ăn lương ổn định, nhưng tôi biết rằng nếu mình làm tốt, các quản lý sẽ xem đó là thời gian rảnh và chất thêm việc cho đến giới hạn. Những người tham lam sẽ không bao giờ đồng ý chia doanh thu hay chia lợi nhuận; họ chỉ kiểu tăng 5% mỗi năm rồi bảo im miệng mà làm
Vài công ty trước, họ yêu cầu tôi liệt kê tên các dự án mà tôi đang chủ động bảo trì; trong Excel với cỡ chữ mặc định, danh sách đó chiếm trọn hai màn hình. Tôi kiệt sức đến mức rơi vào trầm cảm nặng
Tệ hơn nữa là tôi cũng ghét cái trò vô nghĩa như nghi thức quy phục mang tên tìm việc
Tôi nhớ đến các bài viết của Dan Luu: https://danluu.com/nothing-works/
Công cụ phần mềm cho chip cũng tương tự. Chuẩn thông thường là thuê các nhà cung cấp EDA lớn làm công cụ, nhưng các công cụ tùy chỉnh do chúng tôi tạo ra mang lại hiệu quả lớn và thường chỉ do một người xây dựng hoặc bảo trì
Trong thời gian tôi ở đó, phần lớn chu kỳ mô phỏng chạy trên một trình mô phỏng tùy chỉnh do một người bảo trì, nhờ vậy tiết kiệm cho công ty hàng triệu đô mỗi năm chi phí mô phỏng. Giá tiêu chuẩn lúc đó là vài nghìn đô mỗi năm cho một giấy phép trình mô phỏng, còn cụm máy chạy mô phỏng có khoảng một nghìn máy
Nếu một người có thể xây dựng hoặc bảo trì một công cụ trị giá hàng triệu đô mỗi năm cho công ty, đáng lẽ đối thủ cạnh tranh cũng sẽ làm điều đó, nhưng thực tế đa số không làm. Cũng giống như việc họ có thể ra mắt nhanh hơn và rẻ hơn nếu thuê người biết mở wafer ra xem, nhưng các đối thủ lại không làm
Dan Luu nói về “phiên bản bàn tiệc cocktail của giả thuyết thị trường hiệu quả”, còn phiên bản kinh tế học của “không có gì hoạt động” thì gần với https://en.wikipedia.org/wiki/The_Market_for_Lemons hơn. Bài đó nói về vai trò của thông tin và bất cân xứng thông tin trên thị trường
Giả thuyết thị trường hiệu quả thất bại vì tri thức hoàn hảo là bất khả thi và lựa chọn bất lợi thực sự tồn tại
Cũng có những công ty hoàn toàn trái ngược với những gì bài gốc mô tả. Một khi đã làm ở một công ty như vậy, bạn sẽ không thể chấp nhận quay lại an phận ở một nơi tệ nữa
Toàn bộ bài viết đúng là vàng
Các quản lý hỏi làm sao có thể tiết kiệm được nhiều như vậy mà không cần họ giúp, yêu cầu chuẩn bị slide, hỏi đi hỏi lại chuyện gì đã xảy ra, rồi phải triển khai từ từ để trông như đó là việc được làm dần dần theo thời gian chứ không phải chỉ nhờ một nút gạt nhỏ; người viết đã xin tăng lương tương xứng với tác động tạo ra nhưng không thành
Vì lợi ích của chính mình, có lẽ nên ứng tuyển vào những nơi như FAANG. Ít nhất khả năng được đối đãi tốt hơn sẽ cao hơn
Và nếu thêm metadata Twitter card vào blog thì có lẽ khi hiển thị trên Twitter sẽ đẹp hơn
“Xin chào, tôi sẽ giải thích vì sao chúng ta có thể tiết kiệm 500.000 đô la. Về cơ bản, trong một ngày tôi đã xem lại hạ tầng ban đầu được triển khai tệ đến mức nào, và gỡ bỏ tính năng kiểm thử mã đang gây ra vấn đề. Đây là một oversight hoàn toàn ở mọi mặt: phát triển, quản lý, kiểm thử. Nhìn chung đoạn mã này gần như tệ nhất có thể mà vẫn cứ được đưa lên production. Và tôi được dặn là đừng nói những điều này vì ai cũng sẽ trông rất tệ, đồng thời hãy triển khai dần dần để các quản lý trông như đã làm gì đó”
Rồi tôi sẽ đặt mic xuống và rời sân khấu
Thành thật mà nói, chắc tôi sẽ mất gần hết động lực quan tâm. Dù đã làm việc này gần 20 năm, và ngay cả với tư cách một người vẫn phải quan tâm đến công việc vì còn phải trả hóa đơn và nuôi con, tôi vẫn thấy vậy
Tôi lập một bảng tính mô hình chi phí, viết tài liệu rồi đưa cho sếp; ông ấy nói “để tôi xem”. Hai tuần sau tôi hỏi đã xem chưa, thì ông ấy nói “có vẻ đúng đấy. Làm tốt lắm”. Tôi hỏi có định thử áp dụng không, và câu trả lời đúng là kiệt tác
“Không, chúng ta không được trả lương để tiết kiệm tiền, mà được trả lương để tiêu tiền”
Lúc đó tôi mới thật sự hiểu hợp đồng Cost+Award Fee của chính phủ là gì
Nhược điểm là có lẽ bạn phải viết tài liệu đó trước khi thay đổi, rồi để cả nhóm review và đạt được “alignment”
Không phải là vô tình tiết kiệm được 500.000 đô la, mà là cố ý tiết kiệm 500.000 đô la rồi giờ đang hối hận. Hai việc đó không giống nhau
Tổ chức quy mô lớn kém hiệu quả đến mức đáng ngạc nhiên là không hiểu sao vẫn cạnh tranh được, nhưng họ có nhiều tiền, có lợi thế kinh tế theo quy mô và những thứ tương tự. Trong quá trình đó, dù đốt hàng triệu đô la vào những lãng phí và kém hiệu quả ngu ngốc, cũng chẳng mấy ai bận tâm
Dù vậy họ vẫn cung cấp dịch vụ hoặc sản phẩm có giá trị. Dù kém hiệu quả đến đâu, họ vẫn hiệu quả hơn việc hoàn toàn không tồn tại. Vì thế ngay cả khi không có cạnh tranh, các tổ chức như vậy vẫn xuất hiện
Có thể hỏi vậy cạnh tranh với tổ chức nhỏ thì sao. Tổ chức nhỏ ít có hiệu quả theo quy mô hơn, nhưng nếu hiệu quả ở các mặt khác thì đôi khi vẫn có thể cạnh tranh hiệu quả với doanh nghiệp lớn. Nhưng khi phát triển thành tổ chức lớn, cuối cùng họ cũng sẽ mang những kém hiệu quả của tổ chức lớn
Mọi chuyện đơn giản là vận hành như vậy. Không phải không ai quan tâm; ngược lại, chủ sở hữu công ty cực kỳ quan tâm. Vấn đề là theo đúng nghĩa đen, chẳng ai biết cách giải quyết
Doanh nghiệp lớn có xu hướng kết thúc với những kiểu thất bại giống các công ty bị nhà nước kiểm soát theo lối chuyên quyền. Cũng thú vị khi Trung Quốc đã đi trên lằn ranh giữa kiểm soát và tăng trưởng trong chuyện này tốt đến mức nào
Họ vừa bóp nghẹt thị trường, vừa ngày càng kém hiệu quả hơn
Cạnh tranh là câu chuyện cổ tích được kể để các MBA bắt đầu doanh nghiệp mới và tạo vẻ như có cạnh tranh. Ngay từ đầu họ đã chẳng có cơ hội
Nếu có thể tối ưu để loại bỏ toàn bộ lãng phí, tôi nghĩ lẽ ra chúng ta đã có giảm phát, trong khi máy tính và quy trình kinh doanh liên tục trở nên hiệu quả hơn
Trước đây tôi từng tìm ra một lỗi và khôi phục được 4 triệu USD doanh thu hằng năm
Việc đó bị ém đi để bảo vệ đội ngũ và các lãnh đạo đã để sai sót ấy kéo dài lâu như vậy. Tôi không được tăng lương, nhưng có thêm vài đồng minh và có thể sống thong thả một thời gian
Hai máy chủ có liên quan đến một số dữ liệu feed, và tôi nhận ra dây cáp được nối kỳ lạ, không giống phần mô tả chức năng mà tôi được nghe
Chi phí downtime ước tính của hệ thống này là khoảng 7 triệu USD mỗi phút. Tôi nêu vấn đề với vài nhân viên phụ trách và đội mạng, nhưng bị phớt lờ hoàn toàn với lý do “chúng tôi không thể nào nối như vậy được” và vì tôi là lính mới
Vì thấy có vẻ quan trọng, tôi nêu lại vấn đề trong cuộc họp nhóm hằng tuần; ai đó đi kiểm tra trực tiếp rồi quay lại nói đúng như tôi đã nói. Đó là chuyện lớn, và đội mạng phải làm khẩn cấp khoảng 2 tuần để xử lý gọn gàng vấn đề
Mọi người đều giận tôi. Dù tôi đã ngăn một thảm họa cho công ty, việc tôi làm khiến mọi người trông tệ đi, nhất là vì vị thế của tôi trong đội còn thấp. Đó là một bài học quan trọng
Hệ thống tôi tạo ra để sửa lỗi thực chất là một cuộc tấn công trung gian vào việc gửi đơn thuốc của nhà thuốc. Vì các nhà thuốc không bao giờ áp dụng cập nhật giá, chúng tôi định giá lại ngay trước khi đơn thuốc đi vào hệ thống của hãng bảo hiểm. Tôi làm cho một chuỗi nhà thuốc độc lập nhỏ và không có hệ thống pha chế trung tâm
Với trí tuệ thiên tài vô hạn khi ấy, tôi đặt tên hệ thống theo tên người mình thầm thích. Trụ sở chính thích đến mức lập một giải thưởng hằng năm mang tên hệ thống của tôi, và rốt cuộc nó trở thành giải thưởng mang tên người tôi thầm thích, nhưng tôi quá xấu hổ để nói nguồn gốc thật
Dù đã 25 năm trước, đến giờ mỗi năm vẫn có cúp in tên người tôi từng thầm thích được làm ra và trao tặng. Chắc người đó mà biết thì sẽ phát hoảng
Những chuyện như thế này đã tồn tại từ xưa đến nay
Ngày xưa tôi bước vào một phòng đầy terminal VT100, đúng cuối tuần cuối kỳ nên các sinh viên CS buồn chán đang chờ biên dịch xong. Nhìn hệ thống, tôi thấy tất cả job biên dịch đều được đưa vào batch queue, mà mức ưu tiên mặc định của queue đó thấp hơn tác vụ tương tác. Vì vậy chỉ một lần gõ phím ở bất kỳ đâu cũng có ưu tiên cao hơn, và càng nhiều người kiểm tra vị trí job biên dịch của mình thì nó càng chậm
Trong 15 phút tiếp theo, tôi liên tục tăng ưu tiên của job đứng đầu queue, và một giờ sau mọi người hoàn tất công việc rồi về nhà. Căn phòng thuộc về tôi. Chiến thắng của quản trị viên hệ thống không chính thức ;-)
Vài tháng trước tôi phát hiện một S3 bucket liên tục phình to và ngốn 80.000 USD mỗi tháng, nhờ đó tiết kiệm cho công ty 1 triệu USD mỗi năm
Xem xét thì thấy một hệ thống không còn dùng nữa đang sao chép file vào bucket đó. Tôi liên hệ các bên liên quan, họ tắt nó và xóa file
Cấp trên có vẻ không quan tâm lắm. Sếp của sếp tôi bảo thử liên hệ đội khác lẽ ra đã phải bắt được chuyện này, rồi mọi việc kết thúc ở đó
“Ví dụ, chúng tôi đã chạy 234.745 lệnh INSERT vào [table name deleted]_HOURLY, và tất cả đều dưới 1000 hàng”
Đây là câu thật sự xuất hiện trên Slack hỗ trợ Snowflake của tổ chức chúng tôi, và gần như cùng một vấn đề. Các giao dịch nhỏ rải rác theo thời gian liên tục đánh thức cluster. Sản phẩm này không được thiết kế cho các use case phổ biến như nạp dữ liệu liên tục khối lượng nhỏ
Tôi là quản trị viên data warehouse có kinh nghiệm thực tế, nên đang chứng kiến mọi người lần lượt trải qua các lần vượt chi phí và tái khám phá mô tả công việc của tôi. Họ nghiêm túc nói những câu như “tự quản lý thật, nhưng cần giám sát chi phí và viết lại quá trình nạp dữ liệu cũng như truy vấn cho hiệu quả hơn”. Tôi sợ phải hỏi họ nghĩ cả ngày tôi làm gì
Từ rất lâu trước đây, ở một thiên hà xa xôi, tôi đã thay thế một việc vốn cần N × (giấy phép Oracle + máy chủ Sun) bằng một script Perl dưới 100 dòng và một máy chủ Sun, tiết kiệm hơn 300 triệu USD mỗi năm
Trong quá trình đó còn phát minh ra MapReduce. Trước cả Google
Bài toán là tính nhiều thống kê từ log máy chủ web. Ví dụ như 10 trang phổ biến nhất. Giải pháp ban đầu là vì log rất lớn nên nạp toàn bộ vào cơ sở dữ liệu Oracle chạy trên nhiều máy chủ, rồi chạy nhiều truy vấn SQL, lặp lại hằng ngày
Bộ sưu tập các bình luận HN ấn tượng dưới bài viết của tác giả rất hay: https://ludic.mataroa.blog/compliments/
Rất có thể nhiều người trong tổ chức đã đi trước tác giả rất xa. Khả năng còn cao hơn là một kỹ sư hoặc quản lý trong cùng nhóm đã để dành sự kém hiệu quả đó để dùng vào thời điểm cần cắt giảm chi phí, và tác giả đã phá hỏng cơ hội ấy. Khi đó, nếu không còn gì để cắt, nỗi đau lớn và đánh giá hiệu suất tệ gần như là điều tất yếu
Có lẽ nó ngủ đông vì chất lượng thảo luận trên HN đã tụt đến mức gần như mọi bình luận đều có thể trở thành đối tượng
[1] https://twitter.com/shit_hn_says