RS
DVI'm a Senior Site Reliability Engineer at DataVisor in Japan. DataVisor sells fraud detection as a service, mostly to banks and payment providers; I started on the China team and moved to Japan as the company opened up the Japanese market and data-residency rules made local infrastructure a requirement. We're a four-person SRE team responsible for the whole company's infrastructure layer, and I'm primary on-call for it: 50 self-managed Kubernetes clusters, 6 AWS regions, 600+ nodes.
My share of the platform:
- Cluster lifecycle — took the fleet from Kubernetes 1.24 to 1.29 with zero customer-impacting downtime. How →
- Infrastructure as code — the build path those clusters come from: baked images, Ansible roles, kubeadm control planes, worker changes shipped as immutable replacement.
- CI/CD — the Jenkins delivery layer, moved onto Kubernetes and then stabilized. How →
- Observability — the monitoring platform, rebuilt when Prometheus Federation stopped scaling. How →
- Analytics data platform — moved off ClickHouse onto Doris with compute–storage separation, and taken down into the query engine itself. How →
- Ops agents — an on-call triage agent that takes an alert or a customer-reported symptom and runs the investigation itself: pulls metrics and logs, decomposes latency layer by layer, rules layers in and out, and comes back with a root-cause hypothesis and the evidence chain behind it. Every irreversible action stays behind a deterministic gate — the agent may read production, never change it. The hard part isn't the reasoning, it's context: one raw range query returns 30K tokens, so fetching is pushed down to subagents that must answer in 500, and the main loop keeps only judgment. How →
inI was a Cloud Software Development Engineer at Intel working on the cloud-ification of 5G vRAN — moving the radio access network off purpose-built silicon and onto general-purpose servers. I wrote Go microservices and Kubernetes operators for platform tooling, and an internal infrastructure-as-code daemon that held kernel-level machine configuration to a declared spec on bare-metal nodes carrying real-time traffic. This is also where I learned observability from the ground up — Prometheus, Loki, Jaeger, OpenTelemetry — and eventually why labeling CPU is not monitoring.
Four of them in under two years: Tencent (QQ live-streaming), ByteDance (data platform), App Annie (web backend), Baidu (risk-control data engineering).
Tencent is the one that changed how I see systems. Feature development on a high-traffic consumer product in Go and tRPC, and my first walk through a complete microservice and distributed architecture as it actually runs in production — service discovery, config center, Kafka, centralized logging, monitoring and alerting, managed MySQL and Redis, and releases going out canary-first, batch by batch, with a rollback path. Not the demo version of those words: the version where the traffic is real and every one of those pieces exists because something once went wrong without it. Baidu was the other half of the education — data engineering on Hadoop, MapReduce, Hive, Elasticsearch and Airflow, in a risk-control group, which is the same problem domain I'm in today.
MSc in computer science and technology, in Beijing.
BEng in electronic information engineering, in Wuhan.
Every claim above links to the thing itself. The full version is a résumé you can zoom into — same timeline, then a nine-axis honest capability radar, then domain pages, then the write-ups. Open the deeper résumé → (EN / 中文)
What AI agents do to the SRE job
Side work, on my own time — not part of any job above.
I'm working out what monitoring, triage and on-call become once an agent takes the first pass and a human keeps the last word. The interesting question isn't whether an agent can read a dashboard; it's what has to be true before you let one near production — which actions stay irreversible-by-human, how you know the investigation was any good, and what an error budget means when the thing burning it is a model.
I'd rather build the argument than speculate about it, so it exists as code: an agent control plane that governs agents the way SRE governs a service — SLOs, error budgets, sealed tools, autonomy as a budget rather than a grant — an on-call triage harness that investigates end to end but cannot mutate anything, and the context infrastructure my own agents run on. The current thesis is written up in SRE in the age of AI agents; the rest goes on my blog, in English and Chinese.
Bio
I'm a site reliability engineer in Tokyo, working on the infrastructure behind real-time fraud detection. The work I like is the work where the abstraction runs out: a tail latency that is exactly 1.00 seconds because a human typed that number into a config; a migration that turns out to be a memory-engineering problem; a query router that is really an admission controller. I go one layer down until the number explains itself, then I write down what the layer taught me.
Before that I spent three years at Intel on 5G vRAN cloud-ification, learning observability and bare-metal reconciliation on nodes that were not allowed to hiccup. Outside the job I run my own knowledge base, my own memory system, and my own learning loop the same way I'd run a service, on the theory that a life is also a system you can instrument.
Featured writing
Long-form write-ups from the deeper résumé — every one is a system I actually operated. Shorter, broader posts live on the blog.
Engine work
Done on an Apache Doris fork — the mechanism written to be upstreamable and proposed as a DSIP, the routing policy deliberately kept internal.
Two new SQL statements in the Doris frontend. EXPLAIN ESTIMATE PLAN surfaces the per-operator resource estimates the cost-based optimizer already computes while building a physical plan and then discards into one opaque cost number — cardinality, selectivity, row width, scan bytes, blocking-operator state. EXPLAIN ROUTE PLAN turns those numbers into a heavy-or-light verdict in 6–8 ms, before any backend touches data. The diff is purely additive — 15 files, +1,310 lines, no change to the cost model or the statistics calculator — because the work was to expose existing math, not to invent new estimation.
The interesting part was not the rules but the estimator's blind spots, which a second benchmark round exposed: a point query whose window function was bounded by its own filter, read as a full-table scan; and a 3,727-column SELECT * that the byte-volume model priced as cheap when it measured 253 seconds cold, because the cost of a wide read is not bytes but cold-opening thousands of column files in object storage. Both were fixed by replacing an estimate with a structural fact — bounded input cardinality, projected output column count — which is also why a later revision dropped byte-estimate rules altogether. The routing write-up →
Downstream of that came the layer that actually makes a query cheaper, and it is deliberately targeted rather than general: query text, workload and shape are inputs we don't control, so the only lever left is making the shapes a caller might write structurally cheaper — attacking avoidable fan-out and nothing else. A cross-tablet point-query index prunes 566 tablets to about one before any tablet is opened; a wide-read prefetch removes the serialization of column reads rather than the reads themselves. Both fail open: a broken index can only make a query slower, never wrong. Fan-out is the floor →
Pet projects
Things I build after hours, mostly to run my own life as an operated system.
Kubernetes-style governance for AI agents. One process, one SQLite file, no infra deps: per-task-class SLOs, multi-window burn rates, error budgets and hard caps — plus a cross-model judge that scores outputs without sharing the agent's blind spots, outcome-derived verdicts that can retroactively flip a "pass" to "fail", sealed tools behind a single deny-by-default gateway, and an Earned Autonomy Gradient where autonomy is a budget the agent spends, auto-contracting on burn and only promoting with an operator signature.
The repo my agents live in. Three-layer memory (global rules loaded every session, dynamic observations retrieved on demand), skills as versioned reusable capabilities, and a daily observer / weekly reflector cron that accumulates what I'd otherwise forget. Written for AI readers first, humans second.
Anki already logs what I actually did every day. This turns that log into a control loop: a deterministic engine plus a fleet of agents that replaces "I think I'm studying in a balanced way" with "the log says you haven't touched listening in three days," and proposes the cheapest way back on track. Frozen contracts first, then four parallel builders; Anki is just the first sensor.
My Japanese corpus is a repo: generators, TTS pronunciation audio, and a build step that emits .apkg decks. Sentences are source, cards are artifacts — so regenerating a deck is a build, not an afternoon of copy-paste.
A résumé where content is data and every capability claim has to link to an artifact — bullet → project deep dive → thinking, with an honest radar that shows a target line next to the current one. See it →
A Kindle syncer that watches a folder and mails PDFs to my device; a Hexo blog on systems, infrastructure and AI; Anki audio back-fillers; deep-research and slide-generation pipelines that drive several agents in parallel.
DV我是 DataVisor 日本的高级 SRE。公司做的是以 SaaS 形式交付的欺诈检测，客户主要是银行和支付机构；我从中国团队起步，随着公司开拓日本市场、数据合规要求基础设施必须本地化而转到日本。四人 SRE 团队负责全公司的基础设施层，而我是它的 primary on-call：50 个自管理 Kubernetes 集群、6 个 AWS region、600+ 节点。
我负责的部分：
- 集群生命周期 —— 把整个 fleet 从 Kubernetes 1.24 推到 1.29，零客户可感知停机。 怎么做的 →
- 基础设施即代码 —— 这些集群是怎么造出来的：镜像烘焙、Ansible role、kubeadm 控制面，worker 变更走不可变替换。
- CI/CD —— Jenkins 交付层，迁上 Kubernetes 之后再稳定化。 怎么做的 →
- 可观测性 —— Prometheus Federation 扛不住之后重建的监控平台。 怎么做的 →
- 分析数据平台 —— 从 ClickHouse 迁到 Doris 存算分离，并且一路做到查询引擎里面。 怎么做的 →
- Ops agent —— 一个 on-call triage agent：接一条告警或一个客户报的现象，自己把调查跑完 —— 拉 metrics 和日志、逐层拆解延迟、逐层排除或坐实，最后带着根因假设和支撑它的证据链回来。所有不可逆动作都挡在确定性门禁之后：agent 可以读生产，永远不能改生产。难点不在推理，在上下文：一条 raw range query 就是 3 万 token，所以取数下沉给 subagent、必须用 500 token 之内答复，主循环只留判断。 怎么做的 →
in我在 Intel 做云软件开发工程师，方向是 5G vRAN 的云化 —— 把无线接入网从专用芯片搬到通用服务器上。我写 Go 微服务和 Kubernetes operator 做平台工具，也写了一个内部使用的基础设施即代码 daemon，把内核级机器配置收敛到声明的 spec 上，跑在承载实时流量的裸机节点上。这里也是我从零学可观测性的地方 —— Prometheus、Loki、Jaeger、OpenTelemetry —— 以及最终想明白为什么「给 CPU 打标签」不叫监控。
不到两年里四段：腾讯（QQ 直播平台）、字节跳动（数据中台）、App Annie（Web 后端）、百度（风控数据开发）。
腾讯那段改变了我看系统的方式。在一个高流量 C 端产品上做业务开发，用 Go 和 tRPC，也第一次完整走过一套在生产里真实运转的微服务与分布式架构 —— 服务发现、配置中心、Kafka、集中式日志、监控告警、托管 MySQL 与 Redis，以及先灰度、再分批、留回滚路径的发布。不是这些词的 demo 版本，而是流量真实、每个部件都因为「缺了它出过事」才存在的那个版本。百度是这份教育的另一半 —— 在风控业务组做数据开发，Hadoop、MapReduce、Hive、Elasticsearch、Airflow，而风控正是我今天所在的同一个问题域。
硕士，计算机科学与技术，北京。
本科，电子信息工程，武汉。
上面每一条声明都链接到它本身。完整版是一份可以逐层放大的简历 —— 同一条时间线，然后是九轴的诚实能力雷达，再是域页面，最后是长文。 打开深度简历 → （EN / 中文）
AI agent 会怎么改变 SRE 这份工作
业余时间做的，不属于上面任何一份工作。
我在想清楚一件事：当 agent 接手第一遍、而人保留最终决定权之后，监控、triage 和 on-call 会变成什么样。有意思的问题不是「agent 能不能读懂 dashboard」，而是让它靠近生产之前必须成立什么 —— 哪些动作必须留给人不可逆地执行、你凭什么判断这次调查靠不靠谱，以及当烧 error budget 的是一个模型时，error budget 还意味着什么。
我更愿意把论证做成代码而不是空想，所以它是存在的东西： 一个 agent control plane，用 SRE 治理服务的方式治理 agent —— SLO、error budget、sealed tools、把自主性做成预算而不是授权；一个端到端调查但不能改动任何东西的 on-call triage harness；以及我自己那些 agent 赖以运行的 context infrastructure。当前的论点写在《AI agent 时代的 SRE》里，其余的放在我的博客上，中英双语。
关于我
我是一名在东京的 SRE，做的是实时反欺诈背后的基础设施。我喜欢的那类活儿，是抽象层用尽的地方：一个恰好是 1.00 秒的尾延迟，因为有人把这个数字敲进了配置；一次迁移，最后发现它其实是内存工程问题；一个查询路由器，其实是准入控制器。我会一层层往下走，直到那个数字能自己解释自己，然后把这一层教给我的东西写下来。
在此之前我在 Intel 做了三年 5G vRAN 云化，在不允许打嗝的节点上学会了可观测性和裸机收敛。工作之外，我用运维一个服务的方式运维自己的知识库、记忆系统和学习闭环 —— 基于一个假设：一个人的生活也是一个可以被度量的系统。
精选文章
来自深度简历的长文 —— 每一篇背后都是我真正运维过的系统。更短、更泛的文章在博客上。
引擎工作
在一个 Apache Doris fork 上完成 —— mechanism 按可 upstream 的标准写、并作为 DSIP 提出，routing policy 刻意留在内部。
在 Doris FE 里新增两条 SQL 语句。EXPLAIN ESTIMATE PLAN 把成本优化器在构建物理计划时已经算出、却折叠进一个不透明 cost 数字然后丢掉的 per-operator 资源估算暴露出来 —— 基数、选择率、行宽、扫描字节、阻塞算子状态。EXPLAIN ROUTE PLAN 把这些数字在 6–8 毫秒内变成 heavy/light 判定，发生在任何 BE 碰到数据之前。这个 diff 是纯增量的 —— 15 个文件、+1,310 行，不改 cost model 也不改 statistics calculator —— 因为这件事要做的是把已有的数学暴露出来，不是发明新的估算。
有意思的地方不是规则，而是估算器的盲区，第二轮 benchmark 把它们照出来了：一条窗口函数被自己的过滤器夹住的点查，被读成了全表扫；以及一个 3,727 列的 SELECT *，字节体量模型说它便宜，实测冷跑 253 秒 —— 因为宽读的成本不是字节数，而是从对象存储冷启动打开上千个列文件。两处的修法都是把估算换成结构事实（被夹住的输入基数、投影输出列数），这也是后来一次修订索性砍掉所有字节估算规则的原因。 路由那篇 →
再往下才是真正让一条查询变便宜的那层，而它刻意是定向的而不是通用的：SQL 文本、负载、查询形态都是我们控制不了的输入，所以剩下的唯一杠杆是让调用方可能写出的形态本身在结构上变便宜 —— 只打可避免的扇出，别的不碰。一个跨 tablet 点查索引在打开任何 tablet 之前把 566 个 tablet 剪到约 1 个；一个宽读预取消掉的是列读的串行化，而不是那些读本身。两者都 fail-open：坏索引只能让查询变慢，不能让它出错。 扇出是地板 →
业余项目
下班后做的东西，大多是为了把自己的人生当成一个被运维的系统来跑。
给 AI agent 的 Kubernetes 式治理。一个进程、一个 SQLite 文件、零基础设施依赖：按任务类分的 SLO、多窗口燃烧率、error budget 与硬上限 —— 外加一个不与 agent 共享盲区的跨模型 judge、能把「通过」追溯翻成「失败」的结果导出判定、藏在单一 deny-by-default 网关后面的 sealed tools，以及一条 Earned Autonomy Gradient：自主性是 agent 花出去的预算，燃烧时自动收缩，只有拿到操作者签名才升级。
我那些 agent 住的仓库。三层记忆（每次 session 被动加载的全局规则 + 按需检索的动态观察）、把能力做成可复用且带版本的 skill，以及每日 observer / 每周 reflector 的 cron，替我累积那些否则会忘掉的东西。写给 AI 读者看的，人是第二顺位。
Anki 本来就记录了我每天真正做了什么。这个项目把那份日志变成一个控制回路：一个确定性引擎加一队 agent，把「我觉得我在均衡地学」换成「日志说你三天没碰听力」，并给出拨回正轨最省力的那条路。先冻结契约，再四路并行 builder；Anki 只是第一个传感器。
我的日语语料是一个仓库：生成器、TTS 发音音频，以及一个吐出 .apkg 卡组的构建步骤。句子是源码，卡片是产物 —— 于是重新生成一个卡组是一次 build，不是一下午的复制粘贴。
一份「内容即数据」的简历，每一条能力声明都必须链接到实物 —— bullet → 项目深页 → 思考，配一张诚实的雷达：把目标线画在当前线旁边。 看看 →
一个 Kindle syncer，盯着一个目录、把 PDF 邮寄到设备；一个写系统、基础设施与 AI 的 Hexo 博客；Anki 语音补齐脚本；以及并行驱动多个 agent 的深度调研与幻灯片生成流水线。