Head of DevOps, SRE & Security (DevSecOps)
统管六国 145 人的 Group CTO，至今仍亲自动手。中央银行的支付基础设施、三大云上的 AI 智能体平台、裸金属上的十块 A100，以及两项通过审计的认证。
- 99.999%出自柬埔寨国家银行的支付系统 Bakong
- 0 项发现ISO 27001 监督审核零发现；SOC 2 Type II 两次通过
- 145 人分布在六个国家，直接向首席执行官汇报
履历
我负责过的领域
八个领域，同一套证据标准
领导力
145 人 · 6 个国家Group CTO · Head of DevOps, SRE & Security
领导力
145 人 · 6 个国家- 整个组织向我汇报，办公室分布在日本、俄罗斯、瑞士、黑山、泰国和迪拜；我向首席执行官汇报。
- 首先搭建技术组织：高峰期 37 名直接下属，其中 DevOps 12 人、安全 6 人、QA 19 人。
- 在 Everworker：从零开始，没有工具、流程和编制。组建了 4 人安全团队。
支付与 CBDC
99.999%Bakong · CBDC 试点
支付与 CBDC
99.999%- 负责柬埔寨国家银行支付系统 Bakong 的可靠性与安全，该系统以 Java 编写，基于 Hyperledger Iroha。
- 2024 年结算额超过 1500 亿美元，约为柬埔寨 GDP 的 330%；2025 年支付 13 亿笔，均为 NBC 公布数据。
- 集团范围内的 CBDC 试点。为 Central Banking 2020 年“CBDC Partner of the Year”奖项作出贡献。
平台与 AI
300+ 应用 · 99% IaCAWS · Azure · GCP · 裸金属
平台与 AI
300+ 应用 · 99% IaC- 运行在三大云上的 AI 智能体平台，既以 SaaS 形式交付，也可自托管于客户自己的账户中。
- 在被告知需要付费合作伙伴之后，独自完成了 AWS Marketplace 上架，并提供面向三大云的 Helm chart。 AWS Marketplace
- 在迪拜 Moro Hub（Tier III）以裸金属方式部署 10 块 NVIDIA A100；起因是一台被遗忘的 GPU 实例两天内烧掉了数千美元。
- 300 多个应用、700 多个代码仓库、6 个 GitHub 组织。构建时间缩短 40%，成本降低 30% 以上。
可靠性
MTTR −60%从零建立的 SRE 实践
可靠性
MTTR −60%- 为分布在 4 个区域的 20 多个流对齐团队提供嵌入式 SRE：SLI、SLO、错误预算、事件指挥、无责复盘。
- SLA 从 99% 提升到 99.99%。为 5 个关键任务系统实现了备份与 DR 自动化，并且真正执行了恢复。
- 人可以长期承受的值班机制：按日排班，每个班次都有后备人员，每条告警都配有运行手册和指标。
安全与保障
监督审核 0 项发现ISO 27001 · SOC 2 Type II · NIST CSF
安全与保障
监督审核 0 项发现- ISO/IEC 27001:2022：关闭了初次审核的 5 项轻微不符合项，随后以零发现通过第一年监督审核。 Trust Center
- SOC 2 Type II 连续两年通过，范围扩大到隐私和可用性。应客户要求主导了 NIST CSF 项目。
- 面向 100 多名开发者的安全 SDLC：STRIDE 与 VAST 威胁模型、CVSS 与 EPSS 评分、Security Champions。暴露窗口缩短 70%。
- 独立渗透测试：12 项发现（1 项高危、6 项中危、5 项低危）已分诊，关键项已转化为 DAST 回归检查，因此持续受到检验。
产品
2 个产品 · 2 × 12 人端到端负责
产品
2 个产品 · 2 × 12 人- 面向加勒比岛屿的支付系统，配有 12 人的专属团队。
- 面向大型生态系统的积分系统，配有 12 人的专属团队。
Web3
与支付系统同一套关卡Polkadot · Klaytn · SORA
Web3
与支付系统同一套关卡- Web3 Foundation 资助项目、Polkadot 生态开发、Klaytn 与 SORA 生态，使用与支付系统相同的流水线和安全关卡。
- 在 Next-Generation Payments 2023 以及曼谷的金融科技大会上发表演讲。
事件复盘
来自事件响应、审计和客户平台工作。每一起都以建立管控收尾，而不是打个补丁。
源代码外泄与勒索企图
已分析 8.7 万条事件
- 发现
仓库出现异常活动。
- 调查
对包含 8.7 万条事件的审计导出进行取证。凭据的影响范围经过重新测试，而不是凭假设。
- 修复
完成遏制并重置凭据，随后将全组织的访问权限重建为 Pulumi IaC，使手动授权无法卷土重来。
监控看不到的一次凭据轮换
数据零丢失 · 当天修复
- 发现
在一个客户平台上，托管数据库按计划轮换了主密码，应用在夜间失去了数据库连接。没有触发任何告警。
- 调查
应用只在部署时读取一次密码。对告警的复查发现，每条规则都以各自的方式失灵：进程仍然存活；错误阈值设得比这类流量在完全故障时所能达到的值还高；连接池告警则把原因归到慢查询上。
- 修复
当天：应用改用最小权限角色和团队自己掌握的密码，且现在该凭据无法登录时部署会失败。新增告警覆盖连接池为空、health 端点、连接数下限和备份缺失。没有数据丢失。
每四个请求就有一个失败的 webhook
已在上游修复，惠及所有用户
- 发现
在一个客户平台上，固定版本之下的上游镜像发生变化后，约四分之一的 POST 请求出现 webhook 500、签名不匹配和 CSRF 错误。
- 调查
chunked 请求体到达应用时是空的：应用通过 Content-Length 读取请求体，而 chunked 请求没有这个头。这些 500 没有在任何地方留下日志，因为框架的默认日志在关闭 debug 时把它们吞掉了。
- 修复
请求缓冲成为开源部署工具的默认行为，应用在 WSGI 层还原 chunked 请求体，webhook 永远不返回 5xx，错误写入结构化日志。
连接被拒绝，每次持续 14 秒
7,254 次探测，0 次失败
- 发现
一个客户平台的终端用户反馈 443 端口连接被拒绝。当天云上的自动扩缩容器驱逐了边缘代理 37 次，此前每天为 0 到 8 次。
- 调查
代理排空耗时 10 秒，而负载均衡器摘除节点需要约 24 秒。用每半秒一次的探测复现：存在一个 14 秒的窗口，期间约一半的新连接失败。
- 修复
排空时间调到长于 health check，代理强制分散到不同主机，并把这两项设置加入开源工具。跨多次发布共 7,254 次探测，0 次失败。
一个可以跳过步骤的发布流程
部署现在要么全成功要么全失败
- 发现
在一个客户平台上，生产环境在没有后台任务处理器的情况下运行了 20 到 30 分钟，而可用性一直是绿色：worker 没有被部署，所以没有可以告警的对象。
- 调查
发布依赖两个独立的手动步骤，先 web 后 worker，而没有任何机制检查两者是否都已执行。合并前检查和准入控制已排除：git 中的配置是正确的，只是 worker 从未被提交。
- 修复
拆分的服务现在作为一个有序 workflow 部署，两部分不全部成功就会变红，独立的 worker 部署已移除。对等性告警作为兜底保留。
无人信任的告警
误报 89% → 0
- 发现
14 天内 CloudTrail 告警触发 232 次，约 89% 为误报。
- 修复
在 CIS 基线之外新增 8 个检测器，并为每个检测器设置独立排除项：每日触发数为个位数，首个观察窗口内误报为零，每条告警都有运行手册。
停止巡视的看门狗
卡住的运行现在会自行清除
- 发现
一个客户的 dead-man's switch 悄悄停摆了：4.5 天里每次定时运行都以被取消告终。
- 调查
CI 平台留在队列中的一次运行永远占着它的 concurrency group。超时在作业启动前不生效，所以之后每次运行都先等待、然后被取消。一天之内再次发生。
- 修复
短周期的定时 workflow 现在会取消正在进行的运行，因此卡住的运行会被下一次替换，而不是阻塞它。
CPU 只有 4%，账单却涨了 52%
11 个固定节点 → 按需 5-9 个
- 发现
对一个客户平台的成本复查：预测在一个月内上涨 52%，18 个节点的 CPU 使用率约为 4%。
- 调查
部署工具默认的 disruption budget 让单副本服务允许的驱逐数为零，自动扩缩容器因此永远无法排空任何节点。每新增一个 white-label，就多钉住一个节点。
- 修复
允许一次驱逐的 budget 已推广到 13 个仓库。生产环境从 11 个被钉住的节点降到按需的 5-9 个，staging 从 7 个降到 3 个。上游默认值的改动暂缓：对支付类生产环境来说，累积的变更太多。
声称拥有公司并不具备的工具的 ISMS
已核实 29 份政策
- 发现
继承来的 29 份 AI 起草的政策，引用了并不存在的 MDM、EDR 和目录服务。
- 修复
批准前必须核实文中提到的每个工具和角色。AI 起草，证据裁决。