Tìm kiếm
40 kết quả cho “IAM”. Tìm không phân biệt dấu.
- Auditing AWS IAM for better security practices Bài tóm tắt · Postman · 2019
…um.com/better-practices/auditing-identity-access-management-iam-systems-at-postman-using-postman-8e7549237813) Bài đăng trên publication DevRel của Postman và cuối bài quảng bá một…
- Prometheus High Availability and Fault Tolerance Strategy, Long Term Storage with VictoriaMetrics Bài tóm tắt · Miro · 2020
…y-and-fault-tolerance-strategy-long-term-storage-with-victoriametrics-82f6f3f0409e) Bài mang tính hướng dẫn kiến trúc hơn là kể chuyện tiến hoá; không có số liệu quy mô. Lấy từ bản…
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- HeraclesQL: A Python DSL for Writing Alerts Bài tóm tắt · Hudson River Trading · 2025
…làm công cụ cho các kỹ sư hệ thống, mạng, datacenter. VictoriaMetrics là phần quan trọng của stack giám sát (2025); hàng nghìn alert viết bằng MetricsQL (gần như PromQL) trên hàng…
- How we rolled out our own permissions DSL at Figma Bài tóm tắt · Figma · 2024
…nền tảng và migrate các rule quan trọng nhất. - Policy kiểu IAM: mỗi policy có loại resource, effect (allow/deny, deny thắng allow ), danh sách permission, điều kiện. Policy độc lậ…
- How We Monitor Apache Airflow in Production Bài tóm tắt · Gojek · 2020
…n schedule delay , dag loading-duration ). - Danh sách nên giám sát: health của scheduler, webserver, worker và tiến trình tự viết (uptime); số worker; số DAG active và thời gian p…
- AWS Multi-Account Architecture with Terraform, Yeoman, and Jenkins Bài tóm tắt · Slalom Build · 2018
…nhất để tạo và bảo trì bằng cùng một pipeline. - Không tạo IAM user trong tài khoản team: người dùng assume role từ tài khoản identity, tránh access key sống lâu. Policy của role…
- Maintaining Machine Learning Model Accuracy Through Monitoring Bài tóm tắt · DoorDash · 2021
…thời dự đoán sai mà mất lâu mới phát hiện vì không có cách giám sát. - Prediction service Sibyl đã ghi log mọi dự đoán (kết quả, ID, giá trị feature, model) vào data warehouse: đủ…
- Reducing Image File Size in the Photos Infrastructure Bài tóm tắt · Etsy · 2017
…. - Chất lượng trung bình về khoảng 73; dung lượng ảnh lưu giảm 25–30% (so một tuần tháng 4/2016 với tháng 4/2017). - Trên trang listing, sau khi js/font/css đã được cache, khoảng…
- Who Watches the Watchmen? Keeping an Eye on Our Monitoring Systems Bài tóm tắt · Mercari · 2022
…-monitoring-systems/) Bài của team Security Engineering về giám sát pipeline thu log bảo mật (SOAR) của chính họ; wiki chỉ giữ phần giám sát pipeline, bỏ qua nội dung bảo mật. Bối…
- Secure access to 100 AWS accounts Bài tóm tắt · Segment · 2018
…umeRole sang role ops-admin ở dev/stage/prod; mỗi người giữ IAM user key trong keychain qua aws-vault , mọi người dùng chung một ~/.aws/config . Thay đổi chính - Hub-and-spoke qua…
- Infrastructure monitoring with Prometheus Bài tóm tắt · Zerodha · 2020
…đường P2P; workload từ bare metal tới cụm Kubernetes, cần giám sát độc lập. Thay đổi chính - Prometheus (đã so với Sensu, Nagios, ELK) vì mô hình label và PromQL. Service discover…
- Protecting our platform from spikes in usage by reducing load from the Monzo app Bài tóm tắt · Monzo · 2023
…tới khách và bật/tắt theo lô. Kết quả Khi bật, lượng lock giảm nhẹ, lượt đọc các bảng giao dịch và số dư giảm rõ; tải lên các thành phần chính giảm 10–30%. Theo Monzo, khách hàng…
- How Discord Reduced Websocket Traffic by 40% Bài tóm tắt · Discord · 2024
…ăm 2019 (chỉ desktop) tốn RAM quá nên bỏ. - Mục tiêu 2024: giảm băng thông client, nhất là mobile. Thay đổi chính - Dark launch : nén một phần nhỏ traffic production bằng cả zlib l…
- How We Halved Go Monorepo CI Build Time Bài tóm tắt · Uber · 2022
…ước sau dùng lại, tránh fetch và patch lại: thời gian push giảm khoảng 65%. - Chặn big change trong giờ làm việc (làm trong vài ngày, hiệu quả ngay): bị phàn nàn vì thay đổi quan t…
- Slashing CI Costs at Uber Bài tóm tắt · Uber · 2025
SubmitQueue giữ mainline luôn xanh (mọi commit đều qua build, unit test, UI test) cho hơn 4.500 kỹ sư, sáu monorepo lớn, bảy ngôn ngữ, hàng chục nghìn thay đổi mỗi tháng.
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- How we reduced our CI YAML files from 1800 lines to 50 lines Bài tóm tắt · Grab · 2022
Cauldron là đội nền tảng ML của Grab. Sản phẩm MerLin Pipelines cho mỗi team một repo chứa các pipeline ML; mỗi pipeline một thư mục con, mỗi thư mục chia thành stage (ví dụ phục vụ model qua Catwalk). Họ dựa vào rules…
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thêm…
- Bảo mật hạ tầng và quản lý secret Chủ đề Thành viên
Khi hệ thống lớn lên, số credential (mật khẩu DB, API key, SSH key, token, cookie phiên) tăng theo số service, pipeline, nhà cung cấp, và chúng rải vào code, cấu hình, hệ build, log. Các nguồn trong wiki cho thấy kẻ tấn…
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- Xử lý sự cố và on-call Chủ đề Thành viên
Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:
- Xác thực và phân quyền (authn/authz) Chủ đề Thành viên
Ở monolith, mỗi dữ liệu thường chỉ có một đường vào, nên kiểm tra quyền nằm ngay đó: một hàm hasaccess?, một API mỗi resource. Khi hệ thống tách thành nhiều service, nhiều client, nhiều loại token, cả hai nửa đều vỡ:
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Batching và khấu hao round-trip Chủ đề Thành viên
Nhiều nút thắt không nằm ở việc mỗi thao tác tốn bao nhiêu công, mà ở chi phí cố định trả cho mỗi thao tác: một round-trip mạng, một lần fsync, một PUT lên object storage, một syscall, một transaction. Khi chi phí cố…
- Coding agent trong engineering (migrate, viết lại, chạy song song, quyền hạn) Chủ đề Thành viên
Từ 2026 các công ty bắt đầu giao cho coding agent những việc trước đây là dự án nhiều tuần: migrate hàng trăm module hay dataset, dọn feature flag, viết lại cả framework hay app. Agent viết nhanh, nhưng ba thứ không tự…
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- Chọn database theo workload Chủ đề Thành viên
Không có database tốt nhất, chỉ có database hợp với mẫu đọc/ghi ở một quy mô cụ thể. Mẫu đó thay đổi khi sản phẩm lớn lên. Ngoài ra, chuyên môn vận hành của đội cũng là một phần của "workload".
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lúc.
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.