Cụm PostgreSQL của Fly.io đã ngừng hoạt động suốt 3 ngày và không có bất kỳ thông tin nào về sự cố
(community.fly.io)- Một sự cố vào tháng 7/2023 trong quá trình bảo trì khẩn cấp (emergency maintenance) trên host của Fly.io khiến máy của nhiều người dùng bị kẹt ở trạng thái "stopped" và zombie, không thể khởi động lại, gỡ bỏ hay triển khai lại
- Trên dashboard chỉ hiển thị banner "Service Interruption", còn status page không có thông tin liên quan, nên không thể nắm được nguyên nhân hay ETA khôi phục
- Lệnh fly machine thất bại với lỗi "could not get machine", và dữ liệu bất thường được ghi nhận như ngày tạo trong machine list hiển thị là "1970-01-01"
- Một số người tạm khôi phục bằng cách tạo VM mới với fly scale, nhưng VM bị lỗi vẫn không thể xóa, gây lo ngại tiếp tục bị tính phí
- Không có phản hồi chính thức hay cập nhật trạng thái trong hơn 12–15 giờ, dẫn đến suy giảm độ tin cậy của nền tảng
Sự cố phát sinh và triệu chứng ban đầu
- Buổi sáng, health check của ứng dụng bắt đầu thất bại, và máy được xác nhận ở trạng thái "stopped"
- Trên dashboard chỉ hiển thị banner Service Interruption với nội dung "We are performing emergency maintenance on a host some of your apps instances are running on", ngoài ra không có thông tin nào khác
- Status page không hiển thị sự cố này, nên không thể tìm thấy quy trình xử lý hay ETA
- Khi cố khởi động lại hoặc gỡ bỏ instance máy bị kẹt thì xảy ra timeout
- Khi triển khai lại, phát sinh lỗi liên quan đến unmanaged machine
fly deploychỉ cập nhật những máy cófly_platform_version=v2trong metadata, vì vậy cần cập nhật thủ công từng máy bằngfly machine update --metadata fly_platform_version=v2 <machine id>
Trạng thái máy zombie và cách обход tạm thời
- Một số máy rơi vào "zombie mode" và phản hồi mọi lệnh fly machine bằng "Error: could not get machine"
- Bằng cách cấp thêm VM với fly scale, tính sẵn sàng của ứng dụng được khôi phục, nhưng VM bị lỗi vẫn ở trạng thái bất định và không thể gỡ bỏ hay xóa tài khoản
fly machine listhiển thị dữ liệu sai như ngày tạo "1970-01-01T00:00:00Z"- Một người dùng khác cũng tạo máy mới bằng cách scale up để обход tương tự, nhưng máy gốc không thể gỡ bỏ do lỗi "connection refused"
- Lo ngại sẽ bị tính phí cho cả các VM zombie chưa được dọn dẹp lẫn VM được tạo thêm
- Môi trường staging cũng ở cùng trạng thái
Ảnh hưởng đến container cơ sở dữ liệu
- Một người dùng đã gặp cùng vấn đề từ khoảng 14 giờ trước, và vì đối tượng là container cơ sở dữ liệu, không thể khôi phục chỉ bằng cách scale up đơn giản
- Đã gửi email cho support vài giờ trước với gói trả phí, nhưng không có phản hồi
- Ứng dụng này được host ở region syd, nên có đề cập khả năng một hoặc hai host tại đó đang gặp vấn đề
Ảnh hưởng trên diện rộng và khôi phục tạm thời
- Cho đến hôm qua, họ vận hành 4 máy cho app + Postgres (staging và production), nhưng 3 máy vẫn đang down, bao gồm hai cơ sở dữ liệu
- Vì ứng dụng này là ứng dụng API bên ngoài của công ty, toàn bộ tích hợp (integration) đã bị dừng
- Để duy trì vận hành, họ tạo một dự án mới trên Fly và dựng instance, mất vài giờ để backfill biến môi trường và cấu hình
- Điều này vô tình trở thành một bài kiểm thử năng lực DR (khôi phục sau thảm họa)
- Không có cách lấy dữ liệu từ máy db, nhưng vì đó không phải db production chính nên họ đã reverse-engineer để khôi phục nội dung cần thiết
Lo ngại về độ tin cậy của nền tảng
- Bày tỏ sự ngạc nhiên vì sau 12 giờ vẫn không có phản hồi chính thức
- Đây là lần thứ hai gặp cùng vấn đề: dù dịch vụ down, Fly vẫn báo bình thường và không có thông tin hay phản ứng nào, khiến họ chỉ còn cách chờ đợi
- So sánh với Heroku: nếu host không ổn định, dyno sẽ được tự động chuyển đi nên không phải lo lắng như vậy
- Đây là vấn đề xảy ra ngay cả với một ứng dụng Rails + Postgres tiêu chuẩn quy mô nhỏ, làm dấy lên lo ngại rằng với ứng dụng phức tạp hơn thì việc ứng phó sẽ còn khó khăn hơn
- Những vấn đề này được mô tả là làm sụp đổ hoàn toàn niềm tin vào nền tảng
1 bình luận
Ý kiến trên Hacker News
Fly đã để lại phản hồi trong luồng hỗ trợ: họ thường xuyên kiểm tra diễn đàn nhưng đã bỏ lỡ bài này, đồng thời giải thích rằng sự cố một máy chủ đơn lẻ ở khu vực syd đã kéo dài
Máy chủ đó không thể khôi phục bình thường sau khi khởi động lại và cũng không kết nối lại được với service discovery, nên cần khôi phục thủ công
Các ứng dụng chạy với nhiều instance chỉ bị ảnh hưởng ở một phần instance, nhưng ứng dụng chỉ có một instance thì không thể truy cập trong suốt thời gian sự cố, và Fly nhấn mạnh khuyến nghị cấu hình nhiều instance
Họ cho biết các sự cố toàn cục/theo khu vực sẽ được đăng trên status.fly.io, còn các vấn đề với một máy chủ đơn lẻ trước nay được hiển thị trong tab trạng thái của dashboard, nhưng hiện đang xem xét lại cách truyền đạt đối với các sự cố một máy chủ kéo dài như lần này
https://community.fly.io/t/service-interruption-cant-destroy...
Không thể khôi phục bằng cách khởi động lại, nên tôi đã phục hồi một bản sao lưu cũ lên RDS, và cảm thấy chuyển đi là quyết định đúng
Hơn nữa nghe như đây không phải một container người dùng đơn lẻ mà là dịch vụ PostgreSQL được quản lý, nên kỳ vọng khả năng chịu lỗi trước sự cố máy chủ lại càng hợp lý hơn
Tôi có thể trả khoảng $5~10/tháng, nhưng sẽ không dùng nó cho side project nếu phải chấp nhận sự cố kéo dài 3 ngày
[1] https://fly.io/docs/about/support/
Nếu sự cố đã kéo dài vài giờ thì lẽ ra họ nên dùng Ansible hay gì đó để dựng một máy mới. Dù là phần cứng thật hay VM trên AWS/GCP thì đều làm được
Có vẻ Fly đã chuyển luồng[1] thành riêng tư với người chưa đăng nhập như thể muốn che đậy vấn đề này
Trong luồng đó có trường hợp dịch vụ bị sập nhưng trạng thái Fly vẫn báo bình thường, không có thông tin gì và ngoài việc chờ đợi thì chẳng thể làm gì
Một người dùng khác nói rằng ba trong bốn máy của họ, gồm cả app và PostgreSQL staging/production, vẫn còn đang down, và ứng dụng API bên ngoài bị hỏng khiến toàn bộ tích hợp đều tê liệt
Họ cho biết phải mất vài giờ mới tạo được một dự án Fly mới để dựng instance tạm thời, và không tìm ra cách lấy dữ liệu từ DB machine
Cũng có phản ứng cho rằng thật xúc phạm khi trang trạng thái của tổ chức hiển thị “không có sự cố” nhưng ngay trên chính trang đó ứng dụng lại bị đánh dấu đang bảo trì và không thể truy cập
Cũng có bài viết nói rằng suốt 17 giờ gần như không có cập nhật hay thông báo nào trên trang trạng thái, họ chỉ nhận được cảnh báo từ Better Stack
Bản sao lưu toàn bộ luồng: https://pastebin.com/ebmCSZkC
Tweet gửi cho CEO Fly: https://twitter.com/SouthPawNZ/status/1682181533673857024
[1] https://community.fly.io/t/service-interruption-cant-destroy...
Điều tệ nhất ở Fly là khi có gì đó trục trặc thì không chỉ một thứ hỏng, mà nhiều thứ hỏng cùng lúc, trong khi trang trạng thái vẫn hiện toàn màu xanh
Phản ứng thường либо là im lặng, либо là kiểu quá hời hợt như “triển khai vào thứ Sáu thì chuyện này vẫn xảy ra thôi”
Sản phẩm trông rất đẹp, nhưng cho cảm giác như dịch vụ hosting bất ổn nhất mà tôi từng dùng được gói ghém lại cho bắt mắt
Không thể mỗi tuần phá hỏng công việc của người khác, bắt họ tốn tối cuối tuần để khôi phục, rồi kết lại bằng câu “chúng tôi đáng ra có thể làm tốt hơn”. Câu đó là lời bào chữa cho ngoại lệ, không áp dụng được với một mẫu lặp lại
Thread HN này có nhiều nhiễu, nhưng tôi nghĩ cốt lõi là thế này: có vẻ nhân viên đã thấy vấn đề từ trước khi khách hàng nhận ra, sau khi gửi email tới bộ phận hỗ trợ trả phí thì vẫn mất nhiều giờ mới có phản hồi, và phải khoảng 20 giờ sau mới có cập nhật về host bị sập
Họ không thông báo rõ cho người dùng bị ảnh hưởng về sự cố host hay cách khôi phục, và dù dashboard hiển thị bảo trì khẩn cấp thì trang trạng thái vẫn báo mọi thứ bình thường
Tôi hiểu rằng với đặc tính của gói dịch vụ và kiến trúc này thì kiểu downtime như vậy là điều được đảm bảo và khá phổ biến, nhưng giao tiếp tệ đến mức này thì sẽ mất khách
Nếu giống các nhà cung cấp khác, chỉ cần host mà tôi đang nằm trên đó có dấu hiệu hơi bất thường là gửi email cho tôi, thì ít nhất tôi có thể lập tức làm gì đó với ứng dụng của mình
Tuy vậy, việc họ có thực sự hiểu rõ mình đang ở trạng thái đó hay không thì vẫn còn ý kiến trái chiều
Một máy chủ cụ thể đã gặp sự cố kéo dài bất thường, và gộp các yếu tố này lại thì nhiều người đã trải qua đợt gián đoạn lâu mà không có giải thích
Dashboard chỉ hiển thị sự cố theo region/dịch vụ chứ không hiển thị sự cố của từng máy chủ riêng lẻ, nên mọi người không biết điều này và coi như bị nói dối
Hành vi kỳ lạ trong cấu hình thẻ của Discourse khiến sự việc trông như đang cố che giấu vấn đề
Tóm lại, tôi xem đây là một vụ vừa xui xẻo, vừa có quy trình chăm sóc khách hàng tệ, tài liệu có thể cũng thiếu ở vài chỗ, nhưng là chuyện nhiều khói hơn lửa
Mốc thời gian theo UTC là: 2023-07-17 16:19 host sập, 16:49 đăng lên trang trạng thái cá nhân hóa, 2023-07-19 15:00 khôi phục host, 15:17 đánh dấu đã giải quyết trên trang trạng thái
[1] https://community.fly.io/t/new-status-page/11398
Fly.io không muốn trở thành một bản sao Heroku, nhưng vì marketing và trải nghiệm người dùng được trau chuốt nên cuối cùng lại trông như vậy
Kết quả là họ còn phải đối mặt với cả tệp người dùng kiểu Heroku có thể xem mỗi sự cố host đơn lẻ là một đòn giáng lớn vào thương hiệu
Vì chỉ là dự án vui vẻ nên không sao, nhưng nếu là mục đích nghiêm túc hơn thì tôi không chắc nó có còn tiện để dùng không
Và tôi cũng khó chấp nhận việc có nhiều nhà cung cấp cloud đến mức có thể gọi downtime 20 giờ là “điều được đảm bảo và bình thường”
Đáng tiếc là trong các thread HN liên quan đến Fly.io, tôi luôn cảm thấy có khá nhiều sự công kích thụ động
Tôi đã thực sự muốn thích Fly.io. Thiết lập và sử dụng rất dễ, nhưng thành thật mà nói, tôi không nghĩ nên đặt ứng dụng mission-critical lên dịch vụ này
Cuối cùng tôi đã chuyển hết sang AWS, dù thật sự không hề muốn làm vậy
Máy thường xuyên không chạy, lỗi ngẫu nhiên xảy ra, build thất bại, và dù tôi đã trả tiền cho tier cao hơn vì cần hỗ trợ thì họ vẫn phản hồi chậm và không đọc kỹ câu hỏi
Không thể thêm sidecar, khó tích hợp với giám sát bên ngoài, và tài liệu thì ổn cho đường đi bình thường nhưng thiếu rất nhiều ở các edge case
Với dự án hobby thì vẫn ổn, và hiện tôi vẫn đang đặt khá nhiều dự án cá nhân ở đó, nhưng với hạ tầng công ty thì cái giá phải trả bằng thời gian và sự bực bội quá lớn nên tôi buộc phải chuyển
Nghe như người kế thừa tinh thần của Heroku nên tôi kỳ vọng rất nhiều, nhưng tôi nghĩ vẫn chưa tới mức đó
Tuần trước còn build được, local cũng chạy tốt, rồi sau đó lại build được trên Fly, nhưng đó là downtime không thể hiểu nổi mà không có giải thích nguyên nhân hay phản hồi hỗ trợ nào
Free tier rất hào phóng nên bạn có thể làm khá nhiều trước khi chạm ngưỡng tính phí, nhưng tôi không có nhiều thời gian rảnh, và khi có thì tôi chỉ muốn build dự án của mình thôi
Nó thậm chí chỉ là một site tĩnh nhỏ build bằng Node
Bản thân công cụ thì rất tuyệt, nên nếu họ ổn định được hạ tầng tôi vẫn muốn thử lại
Nếu cùng mức nỗ lực đó mà không thể đưa thông tin vào tài liệu, thì tôi không biết pipeline tài liệu hóa của họ phải tệ đến mức nào
Câu trả lời cho các câu hỏi sử dụng trên diễn đàn nên là “có trong tài liệu rồi, nếu chưa thì tôi vừa thêm vào” và “nếu còn gây nhầm lẫn thì hãy báo tôi, tôi sẽ cập nhật tài liệu”
Tôi phải tự đào log của fly mới thấy proxy không thể chạm tới server, và tôi cũng không có cách nào để tự sửa
Vài giờ sau tôi đăng issue lên diễn đàn nhưng không có trả lời hay dấu hiệu đã đọc, rồi chẳng bao lâu sau nó tự nhiên được sửa như phép màu
Tôi hy vọng họ sẽ thành công, nhưng vì sự thiếu giao tiếp này và cảm giác bất lực vì không làm được gì, nên trong một thời gian tôi sẽ không dùng fly.io nữa
Đây có lẽ là câu trả lời không mấy thỏa đáng, nhưng những gì cá nhân tôi có thể nói chỉ đến mức này: tôi hoàn toàn không biết vì sao chủ đề này trên site cộng đồng của chúng tôi lại bị loại khỏi danh sách
Tôi đang nhìn vào UI quản trị, có một biểu tượng ổ khóa nhỏ cạnh bài viết nhưng tùy chọn “unlist story” vẫn có thể bấm được
Điều tốt nhất tôi có thể nói là tôi khá chắc không có chỉ thị từ cấp trên yêu cầu ẩn chủ đề này. Site là công khai và ai cũng có thể tạo tài khoản để xem chủ đề
Mọi người có thể nói gì về chúng tôi cũng được, nhưng che giấu kiểu này không phải là một trong những điểm yếu của chúng tôi
Về sự cố máy chủ Sydney, tôi vẫn chưa biết đủ nên chưa thể đưa ra câu trả lời hữu ích cho những người đang chạy instance trên đó. Tôi vừa mới quay lại sau khi ra ngoài và đang bắt đầu tìm hiểu
Giờ tôi thấy mọi bài trong danh mục app-not-working đều hiển thị như “private”, nên có lẽ là do thiết lập danh mục. Ở đây private có nghĩa là phải đăng ký tài khoản Discourse mới xem được
Giọng điệu của câu trả lời này và các trao đổi khác từ fly.io cho thấy những yếu tố đó còn thiếu, nếu xét đến dư luận về fly.io
Khi đã có hơn 60 nhân viên mà vẫn gặp nhiều vấn đề như vậy, điều đó không còn trông giống giọng điệu gần gũi mang tính con người nữa mà giống dấu hiệu của một doanh nghiệp không thể mở rộng
Một doanh nghiệp B2B đang tăng trưởng muốn thành công thì cần những thứ như quy trình và giám sát, nhưng nhìn các câu trả lời khác thì có vẻ họ không muốn điều đó, và đó là tín hiệu xấu
Hỏng một lần là sự cố, hai lần là xui xẻo, nhưng ba lần thì là quy trình đã hỏng. Nhìn các bình luận ở đây, có vẻ ở Fly.io chuyện này xảy ra thường xuyên hơn ba lần rất nhiều
Không phải vì bản thân sự cố, mà vì có thể mất vài ngày mới nhận được hỗ trợ
Lần tới các anh có thể đưa ra bảo đảm gì cho cộng đồng rằng hỗ trợ sẽ tốt hơn?
Chúng tôi đã chạy https://changelog.com trên Fly.io từ tháng 4 năm 2022, và kiến trúc hiện tại nằm ở https://github.com/thechangelog/changelog.com/blob/master/IN...
Trong 15 tháng trên Fly.io, với ứng dụng Phoenix + PostgreSQL, chúng tôi đã xử lý hơn 100 triệu request, nhưng rất khó tìm ra lý do để phàn nàn
Có vài lần deploy thất bại và chúng tôi sửa bằng cách chạy lại pipeline, đầu tháng 7 năm 2023 ở Frankfurt có 9 nghìn request trả về 503 trong 10 giây, và có một volume không chịu bị xóa trong lúc thử nghiệm machine rồi biến mất vào ngày hôm sau
Chúng tôi thường nói về trải nghiệm với Fly.io trên podcast Kaizen: https://changelog.com/topic/kaizen
Tập công bố migration: https://changelog.com/shipit/50
PR liên quan: https://github.com/thechangelog/changelog.com/pull/407
Gần đây chúng tôi cũng nói về kế hoạch migration từ apps v1 (Nomad) sang apps v2 (flyd): https://changelog.com/friends/2#transcript-138
Tôi rất tiếc khi nhiều người đã không có trải nghiệm tốt, nhưng tôi tin Fly.io sẽ tiếp tục tiến bộ. Hy vọng một ngày nào đó giai đoạn khó khăn này sẽ trở thành một câu chuyện hay
Bài viết đem lại hy vọng: https://community.fly.io/t/reliability-its-not-great/11253
Tôi khá thích fly.io và mong họ thành công. Họ đang làm việc khó nên chuyện hỏng hóc là có thể xảy ra
Tuy vậy, thiếu giao tiếp thì thật đáng thất vọng, nhất là khi đây chính là điều CEO đã trực tiếp chỉ ra là muốn sửa trong bài viết lớn về độ tin cậy đăng trên cộng đồng vào tháng 3
https://community.fly.io/t/reliability-its-not-great/11253#s...
Trên dashboard của người dùng bị ảnh hưởng, chúng tôi vẫn hiển thị lỗi single-host, còn các vấn đề nền tảng/region thì được phản ánh trên trang trạng thái, nhưng rõ ràng có một vùng ở giữa nơi trạng thái chúng tôi truyền đạt không khớp với trải nghiệm thực tế của người dùng
Gần đây chúng tôi đã bổ sung rất nhiều phần cứng để tránh các vấn đề về dung lượng, và đúng như dự đoán, xác suất xảy ra sự cố diện rộng đã giảm, nhưng số lượng lỗi dạng phần cứng lại tăng lên
Chúng tôi vẫn có thể làm nhiều hơn để giúp người dùng tránh những vấn đề này, tăng tốc độ khôi phục và thông báo tốt hơn khi họ bị ảnh hưởng
Dù chúng tôi có mắc sai lầm trong giao tiếp, chúng tôi vẫn đang lắng nghe những phản hồi như thế này
Dấu hiệu rủi ro lớn hơn là có vẻ Fly không có phương thức tự động hóa để nhanh chóng chuyển workload từ máy chủ bị lỗi sang máy chủ đang hoạt động
Dù container và orchestrator đã trừu tượng hóa khái niệm volume dữ liệu có thể gắn/tháo ra
Tất nhiên, để cung cấp được điều này cần đầu tư kỹ thuật lớn, và tôi cho rằng đó cũng là một trong những lý do khiến storage ở ba ông lớn cloud lại đắt. Dù vậy, nếu cung cấp dịch vụ dữ liệu bền vững thì đây là năng lực bắt buộc phải có
Có sự lệch nhau giữa điều Fly muốn cung cấp và điều thị trường kỳ vọng
Fly muốn tạo ra đổi mới cho phép chạy ứng dụng trên nhiều datacenter, nhưng nếu không có dịch vụ dữ liệu bền vững đúng nghĩa thì tính năng đó không hữu ích với đa số người dùng
Có vẻ họ đang cố giải quyết bài toán persistence bằng SQLite replication, nhưng như vậy thì phần lớn lập trình viên sẽ phải thay đổi cách phát triển ứng dụng để phù hợp với nền tảng Fly
Fly phải chọn giữa việc trở thành một lựa chọn thay thế Heroku ổn định và rẻ hơn, hay đưa ra một cách phát triển ứng dụng riêng để mang lại hiệu năng tốt nhất cho người dùng toàn cầu
App Engine là một ví dụ thú vị. Nó đi trước thời đại và đưa ra một cách phát triển có thể mở rộng tới lưu lượng rất lớn, nhưng mọi người không muốn thay đổi cách làm phần mềm để phù hợp với nó
Bây giờ trông họ như đang loay hoay, vừa dập được đám cháy này thì đám cháy khác lại bùng lên, nên tôi không còn tin vào roadmap kỹ thuật nữa
Chẳng phải đã khoảng 2 năm rồi nhiều người đưa Fly.io vào danh sách “để xem lại sau” hay sao?
Một khi mọi người đã nhận thức là không ổn định thì việc phục hồi danh tiếng thực sự rất khó, đặc biệt là trong ngành IT
Dữ liệu bền vững được xử lý bằng cách export snapshot LVM tạo theo chu kỳ 24 giờ hoặc thủ công sang S3
Tôi thực sự không nghĩ đây là nơi để chạy workload cần persistence. Nếu chạy PostgreSQL ở đó thì phải sẵn sàng hot-load dữ liệu sang instance mới hoặc khôi phục từ backup
Cũng vì lý do đó mà từ lâu trên HN đã có người nói đừng dùng Fly: https://news.ycombinator.com/item?id=31394179
Sau khi tôi yêu cầu xóa tài khoản, tài khoản của tôi rơi vào trạng thái kiểu shadow ban mà không có bất kỳ trao đổi nào
Tôi cũng đã gửi email nhưng đến giờ chưa từng nhận được hồi âm, và sau đó đã chuyển toàn bộ sang Railway app và Google Cloud Run
Tại sao một công ty lại shadow ban chỉ vì ai đó đặt một câu hỏi vô hại?
Điều thú vị là Fly.io tạo cảm giác như lịch sử đang lặp lại. Nó giống với lần đầu tôi gặp Heroku
Fly.io thời đầu cũng mới mẻ và hấp dẫn như khi Heroku mới xuất hiện, và tôi từng rất ấn tượng với sự đơn giản cùng độ dễ dùng của nó
Nhưng theo thời gian, các dấu hiệu vấn đề nhỏ bắt đầu lộ ra, downtime xảy ra thường xuyên hơn, và quy trình deploy vốn nhanh gọn mượt mà lại trở nên chậm chạp đầy khó chịu
Nó giống như một déjà vu của giai đoạn khi những điểm mạnh của Heroku bắt đầu biến mất
Càng nhiều người đổ vào nền tảng thì hiệu năng dường như càng tệ đi, và Fly.io cũng có vẻ đang đi theo con đường: càng nổi tiếng thì càng kém ổn định
Thật đáng tiếc vì nó giống như một câu chuyện cảnh báo cho thấy ngay cả nền tảng đầy hứa hẹn cũng có thể sa sút như thế nào, và tôi hy vọng Fly.io sẽ thoát khỏi vòng lặp này và ổn định lại trước khi trở nên vô dụng như giai đoạn đáy của Heroku
Có lẽ tôi đã đánh giá quá cao lương tri của ngành này, vì nếu nó trở nên nổi tiếng như Heroku thì kiểu gì cũng sẽ có rất đông người đổ đến chỉ để không phải trả tiền
Muốn thử lại mô hình miễn phí hào phóng thì либо phải có một bộ phận chống lạm dụng mạnh và tốn kém, либо phải có túi tiền đủ sâu để đổ thật nhiều phần cứng vào mà chấp nhận thiếu hụt ban đầu
Fly có vẻ không mạnh ở cả hai phía đó. Mà cũng vì vậy tôi lại có điểm thích ở họ. Những thứ đó trông như kiểu trò vô nghĩa của các tập đoàn lớn, còn Fly thì ít mang mùi đó hơn
Nhưng tôi cũng sẽ không ngạc nhiên nếu các kỹ sư Fly đang phải dành phần lớn thời gian để xử lý bọn đào crypto ăn chùa, kẻ lừa đảo và người lạm dụng, cũng như tối ưu phân bổ tài nguyên và giới hạn tự động, thay vì tập trung vào độ tin cậy hạ tầng dài hạn hay trải nghiệm nhà phát triển
Tôi tự hỏi liệu điều này có liên quan đến quy mô hay không. Đến lúc công ty có đủ khách hàng trả tiền để bắt đầu có lợi nhuận hoặc trông hấp dẫn với nhà đầu tư, thì đồng thời cũng tích tụ đủ vấn đề để dần biến từ cảm giác mới mẻ, thú vị ban đầu thành giống hệt đối thủ cũ mà họ từng muốn thay thế?
Trải nghiệm của tôi cũng như vậy. Khi công ty phát triển từ quy mô chỉ vài hộp pizza lên mức “đã phải đặt địa điểm cho sự kiện”, entropy bắt đầu len vào, và những châm ngôn như định luật Conway hay định luật Brooks ngày càng hiện rõ