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 / 中文)
Bio
I'm a site reliability engineer in Tokyo, about four years in. Three of them were at Intel on 5G vRAN cloud-ification, which is where I learned observability and bare-metal work from the ground up. Since 2025 I've been at DataVisor looking after the infrastructure behind real-time fraud detection: the clusters, the path changes take to reach them, the monitoring stack, and the analytics store underneath. Before all that, four internships in under two years — that's where I first saw what a consumer product actually costs to run.
Outside work I build agents for ops, and I keep my own notes, memory and learning loop the way I'd keep a service: written down, measured, and reviewed when the numbers move.
Featured writing
Long-form write-ups — every one is a system I actually operated. The four at the top are the ones I'd hand someone first; the rest is grouped by what it is.
The rest, and shorter posts, are on the blog.
Pet projects
After-hours work, mostly about running my own life and my own agents as operated systems. All four have code you can read.
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 same SRE triage agent built at two abstraction layers — once as a Claude Code skill, once as a standalone Python agent on the SDK — sharing one knowledge base. Building it twice is the point: it separates what the harness gives you for free from what you have to write yourself, which is the only honest way to find out where the product layer ends.
The repo my agents live in, and the one I get the most daily use out of. 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.
Its most useful application so far is a goal-versus-behaviour loop: Anki already logs what I actually studied each day, so a deterministic engine reads that log and replaces "I think I'm studying in a balanced way" with "you haven't touched listening in three days," then proposes the cheapest way back. Anki is just the first sensor.
Every capability claim has to link to an artifact — bullet → project write-up → thinking — with an honest radar that draws a target line next to the current one. One markdown source feeds both this site and the blog. See the deeper version →
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 / 中文）
关于我
我是一名在东京的 SRE，工作四年左右。前三年在 Intel 做 5G vRAN 云化，可观测性和裸机那一套是在那儿从零学的。2025 年起在 DataVisor，负责实时反欺诈背后的基础设施：集群本身、变更到达集群的那条路径、监控栈，以及底下那个分析存储。再往前是不到两年里的四段实习 —— 我第一次看清一个 C 端产品真正的运行成本，是在那时候。
工作之外我做面向运维的 agent，也用运维一个服务的方式对待自己的笔记、记忆和学习：写下来、度量、数字变了就复盘。
精选文章
长文 —— 每一篇背后都是我真正运维过的系统。最上面四篇是我会先递给别人看的；其余按性质分组。
其余的文章，以及更短的随笔，在博客上.
业余项目
下班后做的东西，大多是把自己的生活和自己的 agent 当成被运维的系统来跑。四个都有可读的代码。
给 AI agent 的 Kubernetes 式治理。一个进程、一个 SQLite 文件、零基础设施依赖：按任务类分的 SLO、多窗口燃烧率、error budget 与硬上限 —— 外加一个不与 agent 共享盲区的跨模型 judge、能把「通过」追溯翻成「失败」的结果导出判定、藏在单一 deny-by-default 网关后面的 sealed tools， 以及一条 Earned Autonomy Gradient：自主性是 agent 花出去的预算，燃烧时自动收缩，只有拿到操作者签名才升级。
同一个 SRE triage agent 在两个抽象层各写一遍 —— 一遍做成 Claude Code skill，一遍用 SDK 做成独立 Python agent，共用同一套知识库。 写两遍本身就是目的：它把「harness 免费给你的」和「你必须自己写的」分开，而这是唯一诚实的办法去搞清楚产品层到哪儿为止。
我那些 agent 住的仓库，也是我日常用得最多的一个。三层记忆（每次 session 被动加载的全局规则 + 按需检索的动态观察）、把能力做成可复用且带版本的 skill， 以及每日 observer / 每周 reflector 的 cron，替我累积那些否则会忘掉的东西。写给 AI 读者看的，人是第二顺位。
目前它最有用的一个应用是「目标 vs 行为」的闭环：Anki 本来就记录了我每天真正学了什么，于是一个确定性引擎读那份日志， 把「我觉得我在均衡地学」换成「你三天没碰听力」，并给出拨回正轨最省力的那条路。Anki 只是第一个传感器。
每一条能力声明都必须链接到实物 —— bullet → 项目长文 → 思考，配一张诚实的雷达：把目标线画在当前线旁边。 一份 markdown 源同时供给这个站点和博客。看更深的版本 →