腾讯一线研发经验分享|令我工作质效并增的5大方法论
👉腾小云导读
作为一名拥有 6 年腾讯工作经验的后台开发者,作者深知在一个庞大且复杂的技术栈中,拥有正确的方法论和思维方式对工作效能影响有多大。在这篇文章中,作者将结合在腾讯工作的具体项目和案例,分享5个方法论:量化、对比、记录&流程、规范&统一、自动化。希望这些经验和方法论能对广大开发者有所帮助,尤其是对于后端开发者而言。
👉看目录,点收藏
1 量化1.1 技术指标数据 1.2 业务指标数据2 对比 2.1 同比环比 2.2 前后对比3 记录&流程 3.1 记录 3.2 流程4 规范&统一 4.1 规范 4.2 统一5 自动化 5.1 持续集成和持续部署(CI/CD) 5.2 自动化测试 5.3 脚本和工具
5.4 监控与告警
6 结语01
第一个方法就是量化,因为量化是所有方法的基础。量化是将抽象的概念、现象或过程转化为可测量、可分析的数值的过程。通过量化,开发者可以更好地理解、比较和改进系统或过程。在软件开发中,量化可以帮助开发者确定关键性能指标(KPI)和衡量软件项目的成功程度。
在实际项目中,我们通常会把关键指标分成两类进行量化:一类称之为业务指标数据,另外一类称之为技术指标数据。对于一个合格的后台开发人员来说,需要同时关注业务指标数据和技术指标数据,才能更好的感知业务情况。下面我们展开来讲。
1.1 技术指标数据
在技术指标数据中,项目一般也会有几类量化数据。第一种是服务器(容器)基础数据,第二种是业务埋点监控数据,第三种性能基准数据。
1.1.1 服务器(容器)基础数据
服务器基础数据是每个公司都默认会有的基础监控数据,主要统计服务器的基础信息,比如 CPU、内存、IO 等。开发者可以通过这些监控数据来查看服务器是否故障,服务器的负载是否正常,服务消耗的资源情况和趋势等信息。
在腾讯内部,服务器的基础监控最开始都是通过一个叫 monitor 的服务来查看,告警的话一般都是 TMP(Tencent Monitor Platform)。比如 Ping 无响应或响应超时、硬盘空间不足。
云原生化之后,普通开发者基本不需要关注服务器本身的监控数据了,只需要关注对应的 Pod 数据。但是,逻辑是差不多的。
1.1.2 业务埋点监控数据
服务器的粒度是比较大的,无法感知每个用户的情况,所以就需要通过在服务中埋点增加关键指标数据和日志,然后再根据各种维度进行相关的数据统计。
在后台开发领域,由于产品形态的不同,关键的指标也一般都不相同,但是也有一些通用的指标数据。比如各个模块的处理时间、接口的响应时间、正常响应的次数、响应异常的次数,根据用户、分组、时间的维度。
对这些关键进行统计,得到相应的业务技术指标,比如错误率、超时率、平均耗时、最大耗时、在线人数等。
在我个人的项目中,早先是通过 monitor 统计了一些指标数据,比如并发、请求数,正常响应,错误响应等。但是 monitor 是机器维度,无法进行更多维度的分析。所以第一次优化,是通过将这些数据通过埋点的方式写在日志,然后再通过ELK建各种视图进行数据分析。关键的的指标数据再通过 ES API 写到 MySQL 中持久化。第二次优化又将一些指标数据拆分出来使用Prometheus 存储替换了原来的 monitor 那一部分。
1.1.3 性能基准数据
性能基准数据也是技术指标数据中非常关键的一个组成部分。通过对系统的关键组件和关键链路进行基准测试,可以了解各个组件的的性能,再通过对服务的性能测试,可以通过计算得到一个数值,能够准确的进行资源评估。比如服务预计 QPS 是 1 万,那需要清楚的知道需要多少核的机器部署服务,需要多少核的数据库,多大的缓存,以及后续是否还有优化的空间,系统的瓶颈是什么。
1.2 业务指标数据
不同的业务指标数据的定义不尽相同,我们以腾讯内部的直播和语音为例讲述。
以直播业务为例,开发者会定义房间数、同时在线人数,起播数,起播成功次数,卡顿人数,卡顿次数等业务相关指标。
以语音为例的话,会定义请求次数,会话数,请求耗时,音频长度,音频处理耗时,实时率等业务相关指标。
通过分析以上的业务指标定义的规律,可以发现:业务指标数据定义一般遵循以下的逻辑:
定义逻辑 | 解析 |
关注业务核心 | 业务指标数据的定义通常与业务核心密切相关。例如直播业务的房间数、在线人数等,以及语音业务的请求次数、会话数等。 通过关注这些核心指标,可以更好地了解业务的运行状况和发展趋势。 |
关注用户体验 | 用户体验是业务成功的关键因素。因此,在定义业务指标时,需要关注那些直接影响用户体验的数据。 例如,直播业务中的卡顿人数和卡顿次数,语音业务中的请求耗时和音频处理耗时等。通过监测和优化这些指标,可以提高用户满意度,从而促进业务增长。 |
关注效率和性能 | 业务指标数据还需要关注系统的效率和性能。这包括关注资源利用率、系统稳定性和响应时间等指标。 例如,直播业务中的起播成功次数,语音业务中的实时率等。通过持续优化这些指标,可以降低系统成本,提高服务质量。 |
动态和静态指标结合 | 在定义业务指标时,既需要关注动态变化的指标,如同时在线人数、请求次数等;也需要关注静态指标,如房间数、会话数等。 动态指标有助于开发者实时监控业务状况,而静态指标有助于开发者了解业务的总体规模和发展趋势。 |
系统和业务层面相结合 | 在定义业务指标时,需要同时关注系统层面和业务层面的数据。系统层面的指标有助于开发者了解基础设施的运行状况,而业务层面的指标有助于开发者了解产品和服务的表现。 通过整合这两方面的数据,可以更全面地了解业务的运行情况,并制定有效的优化策略。 |
总之,业务指标数据的定义需要遵循以上逻辑,来确保关注业务核心、用户体验、效率和性能等多个方面。通过持续监测和分析这些业务指标,可以更好地了解业务的运行状况,并采取相应措施优化产品和服务。
02
在有了量化的业务指标数据和技术指标数据之后,就需要具备一定的数据分析能力,才能利用这些数据更好的提前预警问题,发现问题和解决问题,优化服务,提升产品质量和竞争力。
所以第二个方法论就是对比。为啥叫对比而不叫数据分析呢?因为数据分析是一个专业的领域,涉及的领域非常多。作为一个普通的后台开发人员,很难成为一个专业的数据分析师。但是通过对比其实就能解决很多技术问题。
2.1 同比环比
在后台开发过程中,需要每天关注服务运行的技术指标数据和业务指标数据,以确保系统的稳定性和可扩展性。通过进行同比(比如这周一对比上周一)和环比(比如今天对比昨天)分析,可以更好更快地了解系统的发展趋势和业务变化。同时,这也有助于开发者及时发现潜在的问题,如性能瓶颈、资源浪费等。
在我个人经历的项目中,每天都会有关键数据同比和环比的情况。这样可以及时发现业务的变化情况、发现一些周期性的规律(比如,教育行业的寒暑假对业务的影响其实非常大)。
只有通过同比环比的对比才能更好的发现这些规律,及时的做一些策略的调整避免资源的闲置和不足。
2.2 前后对比
在后台开发过程中,经常需要对系统进行优化或修改。在进行这些操作之前,需要先对系统进行备份,以便在优化或修改后进行前后对比,确保优化或修改的有效性。
在腾讯,我们会使用版本控制系统(如 Git)来管理代码,确保每次优化或修改都可以轻松回滚。同时,也会使用自动化测试和持续集成来验证修改的正确性和性能影响,确保只会有变更点发生了变更。
而有时候排查问题会发现日志量很大,而且没有将埋点覆盖到每一处。这种情况下,只能通过不断的分析异常发生的前后日志,耐心的对比前后的不同处和相同处,最终找打那个触发的变量。这样可以帮助开发者更好更简单的排查到问题原因。
03
对于后台开发者来说,记录有时候是比开发更重要的。因为没有记录,很多东西可能都找不到在哪里,非常的浪费时间。而流程是为了保证质量。
实际上,我们团队出现了几次事故,基本上都是因为研发人员操作流程不合规导致。流程不等于墨守成规,而是以一种高效的有质量保障的方式去执行一些容易出错的操作。
3.1 记录
记录在后台开发过程中具有举足轻重的地位。它可以帮助开发人员跟踪问题、共享知识以及提高协作效率。以下是一些关于记录的例子:
记录点 | 价值 |
代码注释和文档 | |
会议纪要和讨论记录 | 在团队会议和讨论中,记录关键决策和讨论结果有助于团队成员回顾和跟进,确保团队在同一目标下协同工作。 |
错误追踪和问题记录 | 记录并追踪项目中发现的问题和错误,有助于及时解决问题,提高项目的质量和进度。 |
知识库和经验分享 | 通过建立知识库、记录和分享开发过程中的经验和教训,可以帮助团队成员快速学习和成长,提高整体团队的技能水平。 |
3.2 流程
流程在保证项目质量和提高工作效率方面具有至关重要的作用。
在腾讯内部,流程旨在规范开发人员的行为,防止错误的发生,并确保高质量的结果。以下是一些「流程」在腾讯内部的应用:
代码审查:通过设立代码审查流程,确保每一段代码在提交前经过同事的审查,以发现并修复潜在的问题和错误。
自动化测试:通过实施自动化测试流程,可以在短时间内测试大量用例,提高软件质量并减少人为错误。
发布管理:制定严格的发布流程和上线策略,确保在发布新功能或修复问题时不会对现有系统造成不良影响。一般会有发布周知和发布审批,需要同步测试结果,发布特性,灰度策略,影响范围等信息。
故障应对和回滚:在出现故障时,设立应对和回滚流程,以便迅速的回滚的上一版本。
04
规范&统一主要指的是开发者在编码或者写文档、或者使用其他组件时,使用规范的方式,且尽可能的用统一的方式或者组件或框架,避免在同一个领域使用多个不同的轮子。
在代码的规范这块,腾讯内部有多种语言的编码规范。虽然没有强制执行,但是这个代码规范的代码是可以帮助开发者更好的理解彼此的代码逻辑,更好的维护的开发。那不光要尽可能的遵循这一套规范,而且要尽量避免使用不同的规范。
4.1 规范
4.1.1 代码规范
遵循编码规范:确保团队成员遵循公司内部的编码规范。这包括命名规范、代码格式、注释规范等。这有助于提高代码的可读性,降低维护难度。
使用代码检查工具:利用代码检查工具(如 CodeCC)来自动检查代码是否符合规范。这有助于确保团队成员的代码风格一致,避免在代码审查阶段浪费时间在格式问题上。
4.1.2 文档规范
遵循文档模板:为团队制定文档模板,确保所有文档的结构和格式统一。这有助于提高文档的可读性,方便团队成员快速找到所需信息。
使用统一的文档平台:使用统一的文档管理平台(如 iwiki)来存储和共享文档。这有助于确保团队成员能够方便地访问和更新文档,避免信息的丢失和混乱。
4.2 统一
4.2.1 组件和框架的统一
统一技术栈:尽可能在团队内部统一使用相同的技术栈,避免在同一个领域使用多个不同的组件、库或框架。这有助于降低学习成本,提高协作效率。
组件和库复用:在开发过程中,尽量复用现有的组件和库,避免重复造轮子。这有助于减少开发时间,降低维护成本,同时确保项目的质量和稳定性。能使用腾讯云的资源就不要自建相关服务。
定期技术评审:定期组织技术评审会议,讨论团队内部使用的组件、库和框架,评估其适用性和性能。这有助于确保团队使用的技术是最佳实践,避免不必要的技术债务。
05
在后台开发的过程中,需要用到一些自动化的工具来提升效率。比如 CICD、自动化测试、脚本和工具。自己写脚本,自动化的目的有两个:
一个是最大化的提高我们的效率、解放重复劳动,二是流程标准化、减少人工出错的可能性。
06
-End-
原创作者|滕达
技术责编|滕达
后端都要学习什么?欢迎在评论区分享对你后端职业生涯有帮助的项目、文章、教程、书目、思维方法......
我们将选取获赞量最高的2位朋友,送出腾讯云开发者-限定随行杯1个(见下图)。4月24日中午12点开奖。快邀请你的开发者朋友们一起来参与吧!小云p.s.记得收藏这篇文章,定期回来捞捞网友们的新干货哦~
后台回复「后端」看更多鹅厂经验