Tìm kiếm
40 kết quả cho “kiểm quyền”. Tìm không phân biệt dấu.
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phản ứng…
- 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ỡ:
- 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ự…
- How to Think About Security in Next.js Bài tóm tắt · Vercel · 2023
…er): một thư viện nội bộ, mỗi hàm nhận người dùng hiện tại, kiểm quyền rồi mới trả DTO đã lọc; chỉ lớp này đọc secret. Bài khuyên cách này cho dự án mới, so với truy vấn thẳng tron…
- Mã hoá đầu cuối và hệ thống mà server không được đọc Chủ đề Thành viên
Một hệ thống bình thường giả định server thấy hết dữ liệu: server fan-out tin nhắn, lưu bản sao lưu, sync thiết bị, thu log để vận hành, chạy model, chống lạm dụng. Khi sản phẩm hứa chính nhà vận hành cũng không đọc…
- Service Architecture at SoundCloud — Part 2: Value-Added Services Bài tóm tắt · SoundCloud · 2021
…ion cho client. - 2019: Tracks VAS là bản đầu tiên, dùng để kiểm chứng mô hình. - 2020: refactor Public API. Endpoint nằm rải giữa Mothership (monolith gốc, cửa chính vào DB) và Pu…
- Lessons learned: Using a cybersecurity vendor to check for malicious links Bài tóm tắt · Dropbox · 2023
…Bối cảnh - Dropbox dùng nhà cung cấp bảo mật bên thứ ba để kiểm virus, malware, phishing; một vendor kiểm các URL nhúng trong tài liệu chia sẻ qua Dropbox và tải lên DocSend. Thay…
- Running Cost-Efficient Export Workloads at Uber Bài tóm tắt · Uber · 2026
…- Viết lại bảng một lần tốn tiền trước nhưng giữ được tiết kiệm lâu dài; nếu không thiết kế đầu–cuối, chi phí chỉ chuyển từ lớp này sang lớp khác. Liên quan - · · - Cùng công ty:…
- 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…
- Incident 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 incident: 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…
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn incident 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.
- 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 data…
- 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…
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- 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…
- Xử lý incident 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:
- 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.
- 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:
- 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:
- 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:
- 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…
- 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), synchronous call 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ả…
- Sharding và tách database Chủ đề Thành viên
Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một incident ở DB đó làm sập mọi tính năng.
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- 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 network round-trip, một lần fsync, một PUT lên object storage, một syscall, một transaction. Khi chi phí cố…
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- Độ 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 incident đ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.
- 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.
- Vector search và index ANN Chủ đề Thành viên
Search ngữ nghĩa, gợi ý và RAG quy về tìm các vector (embedding vài trăm tới vài nghìn chiều) gần một vector query. Vector không có thứ tự tự nhiên, nên B-tree hay inverted index không dùng được; ở quy mô lớn phải dùng…
- Hạ tầng phục vụ LLM inference Chủ đề Thành viên
Phục vụ LLM giống một dịch vụ web ở chỗ cần scale theo tải, deploy phiên bản mới an toàn và phục hồi khi một process chết; nhưng ba đặc điểm làm các công cụ quen thuộc hỏng:
- 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:
- Himeji: A Scalable Centralized System for Authorization at Airbnb Bài tóm tắt · Airbnb · 2021
…Rails, mỗi resource có một API duy nhất để đọc dữ liệu, và kiểm tra quyền nằm trong API đó, nên rất dễ quản lý. - Khi tách sang SOA (data service bọc DB, presentation service ghép…
- Engineering Multi-Agent AI Teams That Build and Test Themselves Bài tóm tắt · Salesforce · 2026
…ẩn đoán, sửa cấu hình, chạy lại; rồi còn phải dựng cả agent kiểm tra công việc của agent khác. Mỗi đội mất 2–4 giờ. Thay đổi chính - Agent Designer: một orchestrator và 7 agent chu…
- Superuser Gateway: Guardrails for Privileged Command Execution Bài tóm tắt · Uber · 2026
…pt); CLI không chạy mà tạo PR trong một repo riêng; CI chạy kiểm tự động trên PR; một engineer khác review và approve; dịch vụ backend kiểm PR đã được duyệt và người gửi có quyền d…
- Dropbox Công ty Thành viên
Dropbox luôn là hybrid: metadata ở data center riêng, nội dung file trên S3. Ở ~500 PB họ tự xây Magic Pocket, theo Dropbox vì hiệu năng và unit economics . Cái giá kèm theo là phải tự dựng cả backbone và edge network .…
- Macaroons Escalated Quickly Bài tóm tắt · Fly.io · 2024
…nghĩa vai trò trước: token admin, token user, token chỉ để kiểm toán, token cho CI/CD deploy đều tự tạo được. - Third-party caveat: caveat trỏ tới một dịch vụ khác (SSO, kiểm toán…
- A deeper dive into our May 2019 security incident Bài tóm tắt · Stack Overflow · 2021
…nguồn mở. - Vào được tầng dev qua một đường đăng nhập thiếu kiểm tra access key. Tầng dev cho phép giả danh mọi user để test, nên leo lên quyền Community Manager; dùng một route tr…
- How Coinbase built a governed platform for internal operations Bài tóm tắt · Coinbase · 2026
…omain ở lại backend. Theo bài: phân tán năng lực, tập trung kiểm soát . - Chuỗi kiểm tra có thứ tự mọi request đều đi qua, không nằm trong handler: chuẩn hoá lỗi (ngoài cùng) → ghi…
- Edge Authentication and Token-Agnostic Identity Propagation Bài tóm tắt · Netflix · 2021
…uỗi, qua header context, có khi qua URL parameter, không có kiểm tra toàn vẹn . - Quy mô (2021): hơn 200 triệu thành viên, hơn 2,5 triệu request/giây, phần lớn cần xác thực; kiến t…
- RocketMQ High-Availability Paper Admitted to ACM FSE: Replication-Free Failover Bài tóm tắt · Alibaba · 2026
…trước; NVMe Persistent Reservation rào quyền ghi (fencing). Kiểm tra người đang giữ, giành quyền nguyên tử, đánh dấu pha quan trọng, backoff, để quyền ghi không bị giành lại giữa c…