Đang tải bảng tin…
Ruby Flow0 Hot0 bình luận23 phút đọc
Ozymandias on Rails. Cartography of a Ruin
A practical guide for engineering leaders inheriting a large Rails monolith, focused on how to triage and prioritize production problems effectively. Key themes include: why the loudest errors in trackers are rarely the most costly, how to surface silent failures (latency, data integrity, developer experience) that never appear in error trackers, and how to build a weighted triage model in Ruby that scores issues across customer, financial, developer, and business dimensions using non-linear severity tiers. The post also covers alert fatigue and normalization of deviance, the clustering of failures in unowned code, and how flipping the axis of ownership tooling (e.g., Packwerk) from consumers to producers makes violations actionable. References Google SRE golden signals, DORA metrics, Accelerate, and Adam Tornhill's code hotspot analysis.
Nguồn: https://baweaver.com/writing/2026/07/02/ozymandias-on-rails-cartography-of-a-ruin. 8sync News chỉ tóm tắt và dẫn link; bản quyền nội dung thuộc tác giả và nguồn gốc.
Đề xuất cho bạn
DevBlogs1 Hot5 phútAI
Enabling MLflow OpenAI Autolog on PySpark Workers
Khi phân phối các cuộc gọi LLM trên các worker PySpark bằng mapInPandas, MLflow's openai.autolog() không ghi lại traces do ba vấn đề: worker không kế thừa URI theo dõi và tên experiment từ driver, xuất traces bất đồng bộ gây xung đột thread khi kết thúc process, và không hỗ trợ liên kết trace cha-con. Giải pháp là thiết lập tracking URI, experiment name và tắt MLFLOW_ENABLE_ASYNC_TRACE_LOGGING=false trong hàm worker. Sau khi hoạt động, việc theo dõi từng cuộc gọi phát hiện chi phí ẩn do Spark lazy evaluation thực thi lại nhiều lần các cuộc gọi LLM.
Lập trình viên muốn tối ưu hóa và theo dõi hiệu suất mô hình ML trên Spark với OpenAI, đặc biệt khi sử dụng mapInPandas, nên đọc bài này để khắc phục lỗi trace không hoạt động và khám phá cách khắc phục vấn đề tái thực hiện LLM nhiều lần do tính chất lazy evaluation của Spark.
