时光荏苒，转眼间在腾讯已经工作了五年多的时间。从最初负责故障管理平台的建设，到后来专注于可观测性平台伽利略的研发，这五年经历了从业务平台建设到技术产品打造的完整历程。借此机会，对过去五年的工作进行一个全面的总结和回顾。

工作历程概览

这五年主要分为两个阶段：

1. 故障管理平台建设阶段（2021-2022）：负责Oncall平台的核心模块设计与开发
2. 可观测性平台建设阶段（2022-2026）：负责伽利略可观测性平台的SDK与平台能力建设

第一阶段：故障管理平台建设（2021-2022）

规则引擎模块设计与开发

负责规则引擎的设计与开发，这是Oncall平台的核心能力之一。主要实现了以下功能：

1. 多渠道告警接入与筛选：支持对不同告警渠道（007、Aisee、ifeedback等）的告警信息按条件进行过滤筛选
2. 智能分发能力：可根据用户配置，将告警信息分发至指定场景建单
3. 告警内容ETL：支持对告警内容的抽取和替换能力，通过用户自定义的ETL动作，实现同类型告警信息的收敛，将同类型告警追加至同一工单下
4. 执行动作定制化：可通过规则引擎创建工单、抑制工单或恢复工单

技术实现：采用 Kafka + Aviator 的设计方案，相比研究生毕设时使用的 Flink + Drools 方案，更符合腾讯的业务场景。Aviator作为轻量级表达式引擎，能够满足规则引擎的灵活配置需求。

业务价值：通过规则引擎，Oncall平台日均接入告警量超1w+，通过规则引擎过滤+聚合，减少了90%的告警量，帮助业务团队更加直观地定位问题所在，缩短MTTR。

升级策略模块设计与开发

负责升级策略模块的设计与开发，实现了多步升级通知能力：

1. 多步升级策略：支持针对不同工单类型、工单状态、工单等级的多步升级策略通知
2. 灵活通知配置：支持用户配置通知人为值班班或指定用户，支持电话、微信拉群等多种通知方式

技术演进：

• 第一版：由于项目上线时间要求紧，通过轮询DB的方式实现，但存在通知延迟较高且对数据库有不必要查询压力的问题
• 第二版：采用Pulsar延迟队列实现，支持到任意时间的延迟消息，支持大规模延迟消息，使用简单且性能优异

功能完善：后续持续完善升级策略能力，对照PagerDuty补足功能点，新增循环通知、round robin、复制升级策略等功能，提升用户使用体验。

流程引擎建设

基于开源流程引擎Flowable进行企业化改造适配：

1. 后端改造：
   • 添加应用管理部分，针对不同用户实现资源隔离
   • 针对流程定义、流程实例部分对Flowable进一步封装，对外暴露REST和tRPC-Java接口
2. 前端可视化：
   • 提供应用、流程定义、流程实例的前端展示
   • 用户可以通过页面配置所需流程，查看流程当前流转状态
   • 提供数据多维度汇总展示看板
3. 运营推广：完成流程引擎的运营、文档建设与推广使用，线上运行流程实例达到1391个。

代码质量与标准化建设

1. 大仓标准化：
   • 规则模块从大仓legacy迁移至prod，升级策略从小仓移至oncall下
   • 完成大仓标准化开发，使用统一的第三方依赖库，完成pb本地化等大仓要求
   • 使用中心推荐的dev-image，并和大仓维护者积极反馈相关问题

2. 单测覆盖率：故障管理平台java模块单测覆盖率不低于60%，采用大仓同步小仓的方式，并完成bazel化改造

3. 开发规范制定：
   • 撰写前后端交互规范文档，通过通用拦截器解决后端多个微服务返回格式不统一的问题
   • 后端服务间统一采用rpc调用，实现后端通用包，包括后端通用拦截器、错误处理、配置加载等
   • 解决后端服务间http调用和rpc调用混乱不清的问题，大幅减少冗余重复代码

工单服务”瘦身”与架构优化

工单模块优化升级，拆分非工单模块职责的相关代码：

• 将事件、告警、升级策略、chatops、订阅、复盘等代码逻辑从工单模块拆分
• 工单提供事件驱动能力，累计精简拆分代码超4k+行
• 各模块代码逻辑更清晰分明，可读性提高

稳定性建设

1. 中间件监控：配置中间件生产消费监控，优化多个模块的生产或消费问题，提高异步接入建单的稳定性和时效性

2. 错误处理标准化：
   • 后端模块错误返回信息的统一化，制定错误码标准
   • 将trpc框架错误、pb参数验证错误、业务逻辑错误统一化
   • 优化后端service层逻辑，将error信息抛出，让各微服务间更方便清晰地感知问题
3. 用户操作日志：通过拦截器，利用反射记录用户操作行为，解决由于Oncall目前不存在权限管理，用户误操作时易导致的争议问题

验模型渠道标准化

实现PCG所有事件渠道的定义与规范，实现事件接入管理能力：

1. 架构优化：事件接入异步建单架构重新设计，数据泳道图重新梳理，减少无用的中间流程和无用的数据字段，提高数据接入侧的稳定性，并且实现数据链路的可追溯可查询

2. 事件能力设计：调研并设计事件的基本能力，定义工单、事件、告警三者之间的关系。实现事件的基本能力，支持事件的收敛、升级，支持事件与工单、告警之间的逻辑关联

Oncall协同标准化

实现工单、业务分类、值班表的订阅管理能力，与Playbook串联：

1. 订阅管理功能设计：调研并设计订阅管理功能，包含工单订阅、业务分类订阅、值班表订阅，明确订阅功能的面向场景

2. 技术实现：

   • 设计实时消费类订阅和分布式定时任务类订阅
   • 设计合理的代码分层结构，通过DI等方式让每一层的职责更清晰
   • 利用pulsar天然分布式的特点，解决分布式定时任务存在的单节点处理性能瓶颈问题

混沌工程探索

1. 技术调研：调研了业内主流的chaosblade和chaosmesh，同时调研了公司内部混沌产品和相关BG的TKE平台，试用相关框架和产品，主导设计了新版的混沌工程架构图

2. 实验环境搭建：

   • 通过CVM自建K8S集群，在自建集群上部署了ChaosMesh服务，验证社区的各项混沌注入能力可用
   • 基于ChaosMesh进行二次开发，通过Controller实现K8S CRD解析与任务调度
   • 新增selector支持腾讯各平台各类型的节点选择
   • 通过K8S Operator支持混沌实验的编排

第二阶段：可观测性平台建设（2022-2026）

伽利略Workflow调用图应用层开发

1. 功能扩展：
   • 扩展调用图入口，丰富使用场景，支持单条trace构建调用图
   • 支持用户在单trace场景的调用图故障定位
2. 展示内容丰富：
   • 调用图上可根据用户选择，展示失败率、CPU内存、事件信息
   • 增加点的弹窗、边的弹窗功能，方便用户在调用图上直接获取节点的健康状态和上下游之间的请求量、耗时等数据
   • 基本做到”一图知所有”，可帮助用户快速定位故障原因
3. 架构重构：
   • 由于历史原因，调用图前端承载了构图、裁剪、下钻等过多的数据处理逻辑
   • 将数据处理逻辑移到apiserver应用层来做，帮助前端减轻数据处理逻辑，让前后端职责分明

伽利略Profiling设计与实现

1. 前期调研设计：参与调研设计与讨论，参与pprof的技术路线讨论与验证相关工作

2. Java Profile调研：针对Java的性能监测，调研业内主流实现方式

3. 应用层实现：根据ClickHouse存储的数据，构建火焰图，计算函数耗时等

伽利略Java SDK设计与实现

这是我在可观测性平台建设中的核心工作之一，从2022年开始持续迭代至今。

基础能力建设（2022-2023）

1. 上报通路打通：实现Java SDK的trace、log、metric到伽利略上报的通路

2. 多框架集成：
   • 提供Opentelemetry开源SDK接入方案
   • 提供trpc java接入方案
   • 提供springboot接入方案
3. 开源协同：作为伽利略Java SDK开源协同主负责人，相关代码准入CR与验证

能力持续迭代（2023-2024）

1. 接入用户增长：Java SDK有效可观测对象从24年1月的172个，到24年5月增长至486个，再到24年7月的516个，最终到24年底的670个，实现持续快速增长

2. 接入生态建设：
   • 升级Java base SDK和trpc插件相关能力，支持多样化采样策略，支持自动配置等
   • 扩展Java agent接入方式，让用户接入复杂度更低、可观测链路覆盖更广
   • 新增spring boot starter接入，大幅降低用户接入成本，0代码侵入的接入更友好更便捷
3. 多协议支持：
   • 同时支持otlp和otp协议上报
   • 新增otp协议，在sdk实现聚合上报，通过otp多值协议，使java用户可以享受高基数的特性支持
   • 优化otp协议上报，减少上报毛刺，指标数据更平滑
   • 切换主被调上报协议，从otel协议切换至otp协议，更好的支持秒级监控能力
4. 多框架支持：
   • 新增支持spring 3.x、Jedis、JDBC等框架
   • 通过AOP帮助用户对常见框架的自动插桩，让用户接入更便捷
   • 实现extension组件，覆盖mybatis、jedis等Java常见框架的伽利略可观测数据上报
5. 多场景支持：
   • 大数据场景能力支持升级，进一步打通Oceanus平台
   • 与Oceanus大数据平台合作，flink任务指标导出推荐使用伽利略，并新增flink日志导出伽利略能力
   • 支持kafka trace上报
6. 共建社区运营：
   • 作为伽利略Java SDK共建社区PMC，运营、推广伽利略接入生态活跃度
   • 对项目进度、质量、可持续性把控负责，目前已有10+同事参与到SDK生态共建中
   • 通过公司的issueshoot共建社区，持续推广、运营Java接入生态社区活跃度

用户推广与支持（2023-2025）

作为Java语言负责人，对接多个客户，快速响应伽利略Java用户在接入时遇到的各种问题：

• 积极处理用户提出的多样化需求，受到用户的高度好评
• 目前伽利略Java已接入阅文集团、CDG广告营销、PCG应用宝、PCG大数据、PCG商业产品部、Oceans（flink）等多个客户
• 公司Java tRPC服务覆盖率基本达到一半

伽利略Android/iOS SDK建设

Android SDK建设（2023-2024）

1. 基础能力：支持Android SDK的trace、log、metric接入能力

2. 端上特有场景：
   • 设计并实现了可观测数据的外网加密上报
   • 支持端上的时钟同步
   • 支持安卓特有的染色采样器
   • 支持过载保护
3. 能力升级（2024-2025）：
   • 支持大客户腾讯视频、QQ音乐、QQ浏览器的SDK接入能力升级
   • 稳定性提升：接入共享式Bugly sdk，监测sdk crash率，升级自监控能力
   • SDK启动速度优化90%：支持用户配置本地数据延迟上报时间点，延迟上报默认时间滞后，优化加密过程中密钥缓存能力
   • 安全性提升：进一步升级加密方案，帮助业务对抗黑产，使用伽利略编码对明文进一步encode
   • 支持压缩优化上报带宽成本
   • 适配游戏侧所需的静默能力
   • 支持多target上报能力
   • 支持所有能力的开关配置，用户按需开启trace、log、metric或其他特性能力
   • 支持海外/国内的正式/测试环境多endpoint的快速配置

iOS SDK建设（2023-2024）

与ovbu同学深度合作：

• 帮助ovbu同学解决IOS SDK接入伽利略时的各种上报问题
• 目前IOS SDK已支持trace、log、metric接入
• 协助开发iOS加密能力

客户端用户增长

• 客户端用户PV从24年1月的1574，到24年5月增长至6339
• 与伽利略产品同学合作，基于23年和ovbu合作的端到端一站式可观测项目的成功经验，推广tme和浏览器的客户端同学接入伽利略

端到端可观测能力

1. 产品白皮书：针对伽利略端场景Session特色能力，与产品和其他研发同学共同撰写端到端可观测产品白皮书，制定相关规范，打造产品亮点

2. 一体化串联：设计客户端、前端、后台一体化串联方案，协助老用户QQ音乐打通端到端串联

3. 共建社区：作为伽利略客户端SDK共建社区PMC，积极推动腾讯视频、QQ音乐、浏览器等业务参与到伽利略客户端SDK建设中

前端可观测平台建设（2024-2026）

这是我在2024年下半年开始重点投入的方向。

用户增长与核心能力（2024）

1. 用户快速增长：
   • 前端uv从24年7月至今从235->439，实现86%的增长
   • target数量从24年7月至今从146->374，实现156%的增长
2. 前端录屏能力：
   • 配合前端录屏sdk，实现后台对应的数据存储能力
   • 设计高效的后台接口，通过提高并发和redis执行优化，保证核心接口响应在10ms内
   • 选择合适的存储，使用cos对二进制文件进行存储
   • 实现录屏的增删改查相关能力
3. Sentry错误聚类：
   • 调研并设计sentry一期的接口
   • 通过学习sentry openapi，设计伽利略错误聚类的api接口，并实现相关部分接口能力
4. 日志架构梳理重构：梳理目前前端可观测日志接入整体处理流程，并给出相关的优化方案

日志流水线能力建设（2024-2026）

1. 能力升级（2024）：
   • 整体方案的梳理，通过调研智研、Datadog、腾讯云日志服务，规划日志流水线未来方案和架构
   • tag重定义算子优化改造，自定义处理脚本的方案设计等
2. 能力增强（2025-2026）：
   • 持续扩展日志流水线功能，新增JSON解析、URL编解码、Grok解析、分隔符解析、KV解析等多种数据处理算子的支持
   • 支持流水线及其处理算子的自定义排序，增强日志处理流程的灵活性与可配置性
   • 增强算子功能，全部支持日志正文及标签（tag）的个性化处理，支持保留/删除能力
   • 支持Python脚本处理能力，显著提升流水线灵活性与扩展性

业务价值：目前线上已配置日志流水线数量超过1000条，用户对日志流水线的多样化需求持续增长。随着用户使用频率的提升，后续将基于实际使用情况对日志流水线进行商业化收费。

日志转指标体系完善（2024-2026）

1. UV指标能力（2024）：
   • 完成日志转UV指标的全链路方案设计与落地
   • 包括应用层方案预研、告警策略配置、PV/UV联动机制等功能开发
   • 提升前端监控系统对用户行为的观测与告警能力
2. 能力优化（2024-2025）：
   • 日志转指标功能优化，支持Histogram类型设置分位值、分桶值
   • 支持通过算法提供智能分桶值建议
   • 梳理并统一日志筛选操作符，提升日志转指标能力的一致性与易用性
3. 批量配置与模板（2025-2026）：
   • 在应用层处理底层多个元数据表不支持并发的问题
   • 重构应用层日志转指标逻辑，支持批量配置，支持模板下发
   • 修复历史存在的多个bug

业务价值：UV指标功能已成功上线，用户通过配置UV指标实现了告警降噪，有效提升了告警的准确性。

前端数据处理流架构重构（2024-2025）

1. 架构设计：对原有服务进行模块化拆分，将系统内置的日志转指标逻辑下沉至底层流水线之后，实现日志流水线能力的复用

2. 落地实施：成功拆分并上线feprocess新服务，实现了架构的平滑升级迁移

3. 价值体现：通过新一代数据处理流，充分复用日志流水线能力，为前端错误码标准化提供了坚实的技术基础

前端错误码标准化（2024-2025）

1. 方案制定：参与制定前端错误码标准化方案，推动前端错误码重定义功能的实现

2. 功能实现：通过底层复用日志流水线能力，并结合错误码标准化方案，在应用层实现了错误码重定义功能

3. 价值体现：极大简化了用户配置流程，提升了系统的易用性和可维护性

Replay功能优化（2024-2026）

1. 成本优化（2024）：
   • 针对Replay功能进行多维度优化，包括带宽成本优化方案设计
   • 在Replay成本分析中，发现并利用COS上传带宽免费的特性，进一步优化了Replay的使用成本
2. 安全性提升（2024-2025）：
   • 针对录屏数据的敏感性，对存储内容实现加密
   • 新增Replay采样率、录屏时长等功能，提升了数据安全性和灵活性
3. 能力扩展（2025-2026）：
   • 支持永久存储，支持区分环境
   • 实现SaaS化能力并完成海外数据上报的适配
   • 持续扩展产品边界

高基数TopK监控方案（2024-2026）

1. 方案设计（2024）：
   • 针对指标监控中的高基数维度数据，设计并实现基于HeavyKeeper算法的热点数据分析方案
   • 有效解决高基数场景下的TopK数据统计与监控难题
2. 能力增强（2025-2026）：
   • 支持topk的k值可配置，基于用户上报数据，自动识别符合数据特性的指标参与计算
   • 优化TopK算法实现，支持K值灵活配置，满足不同用户需求
   • 算法层面创新，依据数据冲突率自动调整width参数，提升计算准确性和效率
   • 实现指标维度数据流头部比例自动识别，按需参与TopK计算
   • 整体流程已沉淀至iwiki并开放给用户使用

业务价值：针对高基数场景，提出并落地了一套完整的解决方案，结合数据特性制定差异化的数据处理策略，有效解决了前端可观测场景下TopK热点数据的高效计算与分析难题。

前端监控指标体系扩展与优化（2024-2026）

1. 默认指标优化（2024）：
   • 前端可观测平台默认指标项的优化与升级
   • 支持p75分位，自定义事件支持展示pv、uv
   • session数据展示中支持性能指标等多个小功能点优化
2. 持续扩展（2025-2026）：
   • 持续丰富前端可观测性核心指标，新增多项关键指标及Core Web Vitals展示
   • 帮助用户更直观、全面地了解前端性能状况
   • 小功能点如平台自动转的指标支持分桶、openapi暴露等

前端AI Agent建设（2025-2026）

1. 能力搭建：
   • 搭建前端领域AI Agent，支持处理Issue、前端系统监控指标的问题分析
   • 基于伽利略现有AI Agent框架，集成前端领域所需的MCP tools
   • 有效打通前端数据链路，实现对前端系统监控指标的理解
2. 场景适配：
   • 针对不同前端业务场景，完成Prompt调试
   • 现已具备Issue自动分析和前端系统指标分析能力

伽利略APP建设（2025-2026）

配合前端同学，设计并实现APP上线相关所需接口：

• 包括登陆、心跳检测、小组件等核心功能
• 接口预留其他平台/组件接入的扩展性
• 伽利略APP成功上线

代码质量与规范

1. Readability认证：
   • 积极参加bg组织的icode和Readablity认证考试，并获得优秀成绩
   • 参加的第一期考试，从1000位腾讯同事中脱颖而出，获得了前十的好成绩
   • 通过Readability Golang考试，同时拥有java和go两个语言的绿带认证
2. 代码审查：
   • 在工作中，主动帮助CR java相关代码
   • 建设java相关流水线，改善组内的java代码质量
   • 承担组内后端CR工作，提高后端代码准入质量
3. 规范制定：
   • 制定前后端交互规范
   • 制定后端服务间通信规范
   • 推动代码标准化和规范化

其他价值与贡献

知识分享与培训

1. 技术分享：
   • 进行中心知识分享，分享了Google、Facebook、PagerDuty等业内外的Oncall设计与相关理念
   • 介绍了故障管理平台、规则引擎和升级策略在实现过程中的技术难点
2. 人才培养：
   • 积极参与应届生培养项目CodeWorld，并获得了银奖和最佳创新奖等荣誉
   • 参与公司的传帮带绿带训练营，作为导师，帮助司内其他同学备考readability

开源协同与共建

1. 开源协同参与：
   • 积极参与开源协同，参与trpc-java重构工作，优化重复代码
   • 在业务相关的云观、tRPC、Oceans大数据平台、TencentOS的多个共建任务中贡献代码
   • 在IssueShoot S7赛季中，获得第一名的好成绩
2. 共建社区运营：
   • 通过issueshoot平台，发布40+共建任务，有20+任务已经完成或在进行中
   • 已完成issue工时达80+，帮助伽利略节约了相关的人力成本
   • 作为”业务方”，了解业务的使用痛点和卡点
   • 通过开源协同，扩展了伽利略的品牌影响力，在tRPC等重要场景，让伽利略成为首选的可观测产品
3. 社区建设：
   • 作为伽利略Java SDK共建社区PMC，运营、推广伽利略接入生态活跃度
   • 对项目进度、质量、可持续性把控负责，目前已有10+同事参与到SDK生态共建中
   • 部分伽利略Java用户以及一些非伽利略用户，都参与到伽利略Java接入生态建设中
   • 甚至伽利略没有发布的feature都有用户主动提MR进行共建支持，社区氛围良好

用户推广与支持

1. Java语言推广：
   • 作为Java语言负责人，对接多个客户，快速响应伽利略Java用户在接入时遇到的各种问题
   • 积极处理用户提出的多样化需求，受到用户的高度好评
   • 通过将Java伽利略接入文档推广至tRPC、云观oteam的首推接入，以及产品、运营等同学的合作努力下，Java接入用户在24年上半年快速增长
   • 目前Java语言接入伽利略已覆盖公司所有BG
2. 客户端推广：
   • 与伽利略产品同学合作，基于23年和ovbu合作的端到端一站式可观测项目的成功经验
   • 推广tme和浏览器的客户端同学接入伽利略
   • 协助新的客户端用户如ima、阅文、天美的客户端顺利接入伽利略
3. 跨团队协作：
   • 在前端可观测方向上，主动与北京其他同学保持良好沟通协作
   • 在sentry建设中，与congczhang讨论相关方案，并帮助测试相关功能
   • 在node sdk建设中，利用java sdk建设经验，帮助dragonhe解决sdk建设中的各项问题
   • 在前端sdk建设中，与yongli积极沟通并请教相关技术内容，让北京团队协作更加高效和谐

工作承担与责任

1. 主动承担：
   • 主动承担团队中边界模糊的工作，制定规范文档，解决前端和后端开发中的痛点问题
   • 提供高质量统一化解决方案
   • 主动搭建用户行为数据流，为平台用户数据分析提供数据源
2. 工作交接：
   • 承担组内其他离职同学的工作任务，例如Oncall平台中的值班表、复盘等模块
   • 承担伽利略平台中的profile模块
   • 完成相关模块后续的功能迭代与维护

专利与创新

独立撰写专利”基于replay的可视化全链路可观测前端故障的方案”，并成功发表。

时间线总结报告

2021下半年

其他价值/贡献
1、积极参加 bg 组织的 icode 和 Readablity 认证考试，并获得优秀成绩，在工作中，主动帮助 CR java 相关代码，建设 java 相关流水线，改善组内的 java 代码质量
2、积极参与应届生培养项目 CodeWorld，并获得了银奖和最佳创新奖等荣誉

综合评语
校招入职后马上体现出出色的开发能力，入职即承担了开源流程引擎的二次开发工作，之后又高质量地快速实现了较为复杂的接入管理、规则引擎、升级策略等功能模块。在需求理解与协作能力上也有不错的能力表现。Readability也是优秀通过，整体表现超出预期 在后续的工作中，可以多进行技术交流分享，增强个人技术影响力，帮助团队营造技术氛围，同时在更多项目中发挥更大价值。

2022上半年

其他价值/贡献
进行中心知识分享，分享了 Google、Facebook、PagerDuty 等业内外的 Oncall 设计与相关理念，介绍了故障管理平台。介绍了规则引擎和升级策略在实现过程中的技术难点。

综合评语
上峰校招入职后就体现出过人的技术能力与思考能力，上半年规则引擎和升级策略稳步升级，并完成了业界主流混沌工程的相关调研与核心模块设计，实现了部分功能开发。 下半年Oncall产品化进入到攻坚期，希望上峰继续发挥自身优势，调研并结合内部组件，实现Oncall更多复杂能力。同时更多参与到CR中，通过自身技术能力帮助团队一起进步，快速成长为团队核心骨干，加油。

2022下半年

其他价值/贡献

1. 主动承担团队中边界模糊的工作，制定规范文档，解决前端和后端开发中的痛点问题，提供高质量统一化解决方案。主动搭建用户行为数据流，为平台用户数据分析提供数据源。
2. 积极参与开源协同，参与 trpc-java 重构工作，优化重复代码。

综合评语
上峰在Oncall平台建设中，对需求理解到位，主导实现多个核心复杂功能模块，整体产出非常不错。 在团队中主动承担代码架构优化工作，有效提升代码复用与功能解耦，项目之余还参与到trpc开源协同、IRead阅卷、日常CR，展现出过人的技术能力与主动担当精神。

2023上半年

其他价值/贡献
通过 Readability Golang 考试，同时拥有 java 和 go 两个语言的绿带认证

综合评语
上半年上峰在多个领域快速落地了多个核心功能，包括伽利略核心Trace调用图、Java SDK的建设与协同、Oncall的升级策略、团队与权限管理等等。 业务理解、技术能力、协同能力、研发效率都非常出色，有力地打造和提升了中心产品的核心竞争力。

2023下半年

其他价值/贡献

1. 在伽利略用户推广过程中，作为 Java 语言负责人，对接多个客户，快速响应伽利略 Java 用户在接入时遇到的各种问题，积极处理用户提出的多样化需求，受到用户的高度好评。目前 伽利略 Java 已接入 阅文集团、CDG广告营销、PCG应用宝、PCG大数据、PCG商业产品部、Oceans（flink）等多个客户。Android 已接入 浏览器、腾讯视频 等用户。
2. 积极参与开源协同，完成在业务相关的 云观、tRPC、Oceans大数据平台、TencentOS 的多个共建任务，在 IssueShoot S7 赛季中，获得第一名的好成绩。在参与开源协同中，成为”业务方”，了解业务的使用痛点和卡点，同时通过开源协同，扩展了伽利略的品牌影响力，在 tRPC 等重要场景，让伽利略成为首选的可观测产品。

综合评语
过去半年上峰在这些方面表现不错：

1. 上峰近一年投入伽利略的产出非常突出，是伽利略Java语言和Android的负责人，为伽利略面向阅文、CDG、大数据领域等接入奠定了坚实的基础
2. 还积极投身多个开源协同，包括云观、tRPC、Oceanus等，在IssueShoot S7赛季获得了贡献榜第一名
3. 在这个过程中，上峰体现了超强的技术能力、工作态度和用户思维，是保证伽利略项目成功的核心人物

下一阶段希望在以下方面继续积极提升自己：

1. 后续OnCall产品也会重点拓展C端用户，这块也非常依赖端的能力，期待上峰在这一块有更好的表现

上峰近一年投入伽利略的产出非常突出，是伽利略Java语言和Android的负责人，为伽利略面向阅文、CDG、大数据领域等接入奠定了坚实的基础。同时还积极投身多个开源协同，包括云观、tRPC、Oceanus等，在IssueShoot S7赛季获得了贡献榜第一名。在这个过程中，上峰体现了超强的技术能力、工作态度和用户思维，是保证伽利略项目成功的核心人物。 建议可以考虑将所有这些产出提炼分享出来，增强中心、产品、个人在公司的影响力，实现多赢

2024上半年

其他价值/贡献

1. 作为后台开发同学，主动参与到伽利略用户推广拓客中，积极响应客户接入需求，与众多接入用户维护良好关系，打造伽利略品牌口碑。积极推动伽利略接入生态共建，使 Java/Android/iOS 接入生态社区活跃。
2. 主动参与公司的 Oteam 共建，在 tRPC Java、云观 等 Oteam 中持续贡献代码。
3. 承担组内其他离职同学的工作任务，例如 Oncall 平台中的值班表、复盘等模块，伽利略平台中的 profile 模块。并完成相关模块后续的功能迭代与维护。

综合评语
在24H1这个周期，上峰围绕Java这个场景，做了一系列工作，包括后台的Java生态的建设，以及客户端的Android生态的建设。上峰在完成这部分工作的时候，积极响应用户的需求和咨询，积极学习Android的开发，为整个团队做了很多补位的工作，很好的弥补了伽利略缺乏Java开发及Android开发的问题。这部分工作虽然繁杂，但获得了团队内同学的一致认可，给上峰积攒了非常多的好的口碑，为上峰后续建立更大的团队影响力奠定了一定的基础。 后续期待上峰继续加油，后续伽利略前端可观测的大部分工作会放在北京团队，上峰作为北京团队成长最快的后台开发，期待能够有更好的整体技术视野，能够协同好团队的其他后台和前端同学，确保伽利略前端可观测的整体技术架构和稳定性都朝着更好的方向去发展。在技术方面，也期待上峰不仅仅只关注手头的事情，也对伽利略整体的架构更加的熟悉，对可观测行业更加的熟悉，在团队内建立更多的技术影响力，在Oteam也建立更多影响力。另外是北京也有相当一部分伽利略的客户，期待上峰也能够作为伽利略在北京的桥头堡，继续对北京客户的状态保持好关注，为伽利略建立好在他们心目中的口碑。

2024下半年

其他价值/贡献

1. 在前端可观测方向上，主动与北京其他同学保持良好沟通协作，在sentry建设中，与congczhang讨论相关方案，并帮助测试相关功能，在node sdk建设中，利用java sdk建设经验，帮助dragonhe解决sdk建设中的各项问题，在前端sdk建设中，与yongli积极沟通并请教相关技术内容，让北京团队协作更加高效和谐。
2. 参与公司的传帮带绿带训练营，作为导师，帮助司内其他同学备考 readability。
3. 通过 issue shoot 平台，发布 40+共建任务，有20+任务已经完成或在进行中，已完成 issue 工时达80+，帮助伽利略节约了相关的人力成本。

综合评语
上峰一直是团队内能力非常强非常有潜力的同学，面对困难的时候的态度也非常的积极。作为伽利略Java SDK和Android SDK的负责人，在项目中要支持好Android的一些需求是比较有挑战的，上峰都能够克服困难解决。在其他的后台需求方面，上峰也能够很好的解决好，包括录屏、日志流水线等功能都支持的很好。在上述工作中，上峰的需求理解快，执行力强，获得了诸多好评。上峰是很有潜力的，但整体在团队内的影响力建立还需要一点耐心和主动，期待通过一些有技术难度和挑战的功能利如日志流水线等，建立在团队内的技术影响力，同时凝聚好北京团队。期待上峰和伽利略一起努力一起加油。未来一定可以走的很远。

2025上半年

综合评语
上峰在这个周期，一如既往的保持了较好的产出，完成了top k降纬，日志流水线，以及众多的SDK开发的工作。期待上峰能够在后台开发领域，能够承担更多独立的板块的开发，能够找到自己特长的领域，在团队内形成很好的差异化优势。北京还是非常重要的，既有我们众多的客户，也有我们很多合作伙伴，不管如何团队还是希望北京团队能够越来越强。期待上峰能够和前端可观测领域的同事一起，通过自己的技术深度和积累，将前端可观测领域打造出有竞争壁垒的产品。

2025下半年

其他价值/贡献
独立撰写专利”基于replay的可视化全链路可观测前端故障的方案”，并成功发表。

综合评语
上峰在这个周期产出多，是一位让团队非常放心的”多面手”。他不仅在自己负责的Java/Android SDK领域持续深耕，解决了多环境、成本优化等难题；更在后台核心业务上（如AI Agent、TopK、日志流水线）展现了很好的攻坚能力。另外，能独立输出技术专利，说明上峰在日常开发中具备了很好的总结和创新意识。 作为北京团队的核心后台骨干，上峰很好的支撑了前端可观测领域的后台建设。 期待上峰后续能够： 继续强化”差异化优势”，不仅仅是补位，而是要在前端可观测的后台架构（如AI分析链路、复杂数据清洗）上形成自己的技术壁垒，成为该领域的权威； 随着北京团队承载的业务越来越重，期待上峰能发挥更强的技术辐射力，协同好北京的前端和后台同学，共同把伽利略打造成客户心目中的标杆产品。继续加油。

工作成果总结

业务成果

1. 故障管理平台：
   • 日均接入告警量超1w+，通过规则引擎过滤+聚合，减少了90%的告警量
   • 线上运行流程实例达到1391个
   • 异步链路处理能力提升至2w条/min
2. 伽利略Java SDK：
   • Java SDK有效可观测对象从24年1月的172个，增长至24年底的670个，实现近4倍增长
   • 公司Java tRPC服务覆盖率基本达到一半
   • 已接入阅文集团、CDG广告营销、PCG应用宝、PCG大数据、PCG商业产品部、Oceans（flink）等多个客户
3. 伽利略客户端SDK：
   • 客户端用户PV从24年1月的1574，增长至24年5月的6339，实现4倍增长
   • 已接入腾讯视频、QQ音乐、QQ浏览器等头部APP
4. 前端可观测平台：
   • 前端uv从24年7月的235增长至439，实现86%的增长
   • target数量从24年7月的146增长至374，实现156%的增长
   • 线上已配置日志流水线数量超过1000条

技术成果

1. 架构优化：
   • 工单模块”瘦身”，累计精简拆分代码超4k+行
   • 前端数据处理流架构重构，成功拆分并上线feprocess新服务
   • 实现前后端职责分明，提升系统可维护性
2. 能力建设：
   • 实现高基数TopK监控方案，解决高基数场景下的数据统计难题
   • 完成日志流水线能力建设，支持多种数据处理算子
   • 实现前端AI Agent，支持Issue自动分析和系统指标分析
3. 标准化：
   • 完成大仓标准化开发
   • 制定前后端交互规范和后端服务间通信规范
   • 实现错误码标准化和错误处理统一化

五年工作感悟

这五年在腾讯的工作经历，让我从一个专注于业务开发的工程师，成长为能够负责技术产品全链路建设的资深开发。在这个过程中，我深刻体会到了几个重要的变化：

1. 从业务到产品：从最初负责故障管理平台这样的业务支撑系统，到后来负责伽利略可观测性平台这样的技术产品，让我学会了如何从用户角度思考问题，如何做好产品的推广和运营。

2. 从单打独斗到团队协作：通过开源协同和共建社区，我学会了如何与不同团队、不同背景的同学协作，如何通过社区运营来推动技术产品的生态建设。

3. 从技术实现到架构设计：从最初实现具体功能，到后来负责整个模块的架构设计和重构，让我对系统设计有了更深入的理解。

4. 从被动接受到主动承担：从最初按照需求开发功能，到后来主动发现问题和痛点，提出解决方案并推动落地，让我学会了如何主动思考和承担责任。

5. 从技术深度到技术广度：从最初专注于Java后端开发，到后来涉及Go、前端、云原生、可观测性等多个技术领域，让我对技术有了更全面的认识。

这五年的工作经历，不仅提升了我的技术能力，更重要的是培养了我的产品思维、协作能力和责任意识。希望在未来的工作中，能够继续在这些方面持续成长，为公司创造更大的价值。

随笔

哈哈哈哈，其实上面的内容是AI帮忙总结的，但是内容确实都是真实的。下面随便聊聊在腾讯工作这几年的一些真实感受吧。

网上大部分评价腾讯是国内互联网最养老的地方吧，作为一个阿里、字节、腾讯、百度都体验过一遍的人，确实我是比较认可网上的这种评价的，不过这些互联网大厂都太大了，部门和部门之间，甚至是组和组之间，都有可能有比较大的差异，可能你在的组每天晚上干到10点+，隔壁组就六七点下班，这种可能性都是存在的。所以这种对比只能说是从概率学上来看了，举个例子，你去腾讯遇到一个七八点就能下班的工作的概率可能百分之四五十，但是你如果去字节遇到这种工作的概率可能也就百分之十，从这种角度来说，腾讯整体来看还是比较偏轻闲的。或者从okr的角度来看，腾讯的okr我自己这么多年基本上没填写过，没有特别的硬性指标压在身上，但是字节不同，虽然当时只是实习，但是那会的双月okr至今让我无法忘记，不过效率上肯定还是字节的效率高的多，工作强度完全不在一个level上，字节一年人间三年，字节和心脏只有一个可以跳动，当时我们宿舍3个人去字节实习，三个人心脏都疼，还是很真实的。

为啥腾讯相对而言会轻松些，个人认为也有其业务/营收方面的原因，社交/游戏这两头，腾讯长期处于无人竞争的地位，而且这两者又相辅相成，比如王者/吃鸡这类型的游戏，可能你上线并不是因为你想玩，而是你身边的社交圈，你的朋友们在玩，他们喊你上线，然后游戏中又认识了一些好友，加上微信又反哺社交。从财报上来看，腾讯的利润率让人都感叹这简直是在贩卖“电子鸦片”，由于业务和营收的稳定，所以整体公司的战略发展上一直都不是激进派，相比于其他大厂打得水深火热，比如电商，字节/阿里/京东/拼多多，群雄鏖战，一不注意可能就被甩开淘汰，这种时候，公司员工又怎么可能过的舒适安逸呢。有鹅选鹅，绝对不是一句空话。

说完宏观上的一些个人感受，再细聊聊我自己这几年工作的经历。工作四年多五年，领导换了3个，身边的同事裁的裁走的走，再回首只剩自己孤身一身，互联网的不稳定性体现的淋漓尽致。还记得刚入职的时候，北京这边的副总监离职了，请我们所有人吃饭，当时刚入职没多久，完全不懂这意味着啥，随着时间推移才明白，没有领头羊的地方很难有长期发展，之前中心在北京有几十号人，隔几个月走一批隔几个月走一批，小刀慢砍，最终连一个小组长都没有了，最终到我的时候，我们中心在北京算是彻底没人了，这几年，吃的最多的饭就是散伙饭，如果说这场工作就是一场和平精英游戏，那我可真是跑毒决赛圈选手了。不过也能理解，毕竟大老板们都在深圳，距离确实太远了增加了额外的管理成本，并且我们作为一个公司内的技术产品，并不是特别需要“跑客户”，虽然我们在北京离腾讯新闻/腾讯视频部分业务方比较近，但实际工作中，我们也并不存在经常需要线下对接的场景，因此地理因素只剩下了劣势，我要是老板，我也会做出同样的决定，干掉北京分部。

虽然所在的部门在北京的战略上一直是收缩的，但是我在的可观测这个技术产品，在腾讯内部却发展的非常迅猛，接入量和用户数一直突飞猛进，所以深圳那边其实一直是在招聘扩充的，在一个快速发展的核心业务里，个人成长确实还是存在很多机会的，如果做出来一些非常显著的成果，也会得到相应的回报，从建立一套覆盖后端的可观测系统，再到实现端到端的全链路监控，再到最近的AI Agent实现RCA，基本上可以说伽利略这个可观测团队，在国内基本上是走在前列的，从公司内网km，或者到脉脉上，都有人夸，优秀的团队里才更容易实现个人价值，这一点我是非常赞同的。也算是乘上了团队发展的风吧，拿了几次高绩效，前期晋升也非常的快，如果是边缘业务的话，机会肯定是少很多的。

这一次换工作，去家门口的央企了，之前的经历都在在互联网公司混，还没有体会过所谓的“上岸”是一种什么样的生活状态，从目前的了解来看，国企央企并不是曾经那样的铁饭碗，也都面临着营收压力带来的降薪/裁员，所以走一步看一步吧，毕竟还不到30，还可以再折腾折腾～多体验体验，才知道自己真正想要的是什么吧。