如何做一个靠谱的技术运营人

‍‍

本文作者：taydai，腾讯PCG技术运营服务中心副总监

过往十多年互联网产品形态和技术需求在巨变，从PC互联到移动互联和产业互联，基础技术和平台从物理机到容器化、云化；网络从2G到5G；产品的数据量级从百亿级/天到万亿级/天。

但不论发展如何变化，技术运营提供的服务其实本质不会变，从还是需要保证产品极致的用户体验和降本增效，根据产品的生命周期来提炼服务模型：

本文会按质量、效率、成本、安全，结合实际案例论述靠谱运维的原则与方法：

一、质量、效率

原则1: 服务健壮性需依从程序架构容灾调度（全网调度）原则，以最终服务能力构建考量体系。

举个案例：

10年负责taf平台运维时，主导过基于场景细化TAF框架下调度策略和机制。在询问开发时，开发答复是运维不用关心这个，其实开发本身对主控的更新策略、client和server容错轮训策略也不能完整说明，最后查看代码，整理出taf框架的容错保护机制，并演习验证。

当时整理的taf框架调度策略如下：

1) server状态变化，registry会立即更新至数据库，并且registery会每60s异步跟数据库更新信息

2) client采用随机轮训和hash轮训调用server，失败连续超过10次，500次内失败率高90%则屏蔽掉server，屏蔽后并且每10s尝试一次探测是否恢复

3) 服务会定时上报心跳给node，如果未上报则认为服务僵死重启，后每10分钟尝试一次。

详情如下图：

向前一步，16年开始运维逐步接手地图运维工作，当时服务使用自身框架因为同步调用和容错策略健壮性不够等问题，出现了四次事故。运维侧推进业务侧架构改造使用MIG标准的TAF框架和Dache，在架构评审时，技术VP曾老师说过一段话一直记忆犹新：

不管业务使用什么框架，程序架构设计的五点原则是要遵守的：

1)不出现写死调用方式的架构设计。

2)需要有主控实时感知框架节点的运营状态，并且能及时剔除异常节点。

3)基于资源容量、服务状态，可动态伸缩调度

4)尽量使用异步调用少用同步调用。 

5)框架支持多语言异构能力。

更进一步，遵从上述原则，梳理出MIG（12-18年）当时，整体业务架构能力演进以及容灾能力状况如下：

原则2: 通过SLO的设定，端到端基于业务场景保保障业务质量，并且结合故障预防、故障管理体系化保障质量。

机制、工具、数据分析结合实现：

1、树立SLO为重要标准与口径：推广SLO：由SLO与错误预算自动生成工单(高级别工单)，由故障复盘补齐SLO，形成闭环的螺旋式提升。高级别监控告警同理，但需注意监控项与SLO重合度问题，若重合，建议以核心SLO为口径

2、明确级别的标准与整个后续流程：工单背后一定由人来处理。需要避免建单不准确，避免类型不明确，避免分类太复杂。为此，明确、准确、简单、标准化的工单级别与分类至关重要。让接入方follow此标准，而非实现各种个性化需求。

3、明确事中处理机制：机制制定：明确制定事中处理流程，包括升级机制与通告机制，进行Oncall人员培训，以及如何使用。人的引导：明确Oncall人员不是一个人在战斗，明确授予Oncall同学的升级权限，并建立易用的升级与通告功能，是降低Oncall人员压力，缩短MTTR的有效手段。

4、明确事后复盘机制：

机制制定：明确复盘不只进行单一case的措施跟进，针对非自动化的故障来源，同样作为待跟进措施，提升SLO与监控的覆盖，是体系形成闭环的重要部分。由此提升MTTI（故障发现时间），如初始定义的SLO是后端服务入口的指标，无法覆盖域名劫持或代理层故障，是否进行改造排期。

人的引导：定期进行故障复盘会，将覆盖度提升作为非常重要的一环；优秀的故障复盘进行宣导与奖励机制，建立对事不对人的理念，让更多人愿意参与到体系的建设中。

5、明确故障管理体系建设路径：根据Google经验以及ticket现状分析，SLO与故障管理的相互促进是中长期工作，在规则上先紧后松，在建设路径上先查准率后召回率。此策略的制定会影响体系参与者的积极度。

6、数据分析：全流程埋点，进行有价值的数据分析，反哺业务决策、体系闭环；MTTR；运营看板：管理侧运营数据；业务看板：业务侧日/周/天级聚合分析与明细；故障看板：故障数据分析。

原则3: 质量需以用户和价值导向，以最终用户的满意程度和产品价值来构建考量指标体系。

举个案例：

应用宝起初下载成功率只有90%左右，除了单纯解决下载劫持场景和提升下载功率外，需要从从下载到安装到用户激活整条链路来考量。技术手段、产品策略需要完整结合，才能给用户和产品最大价值。

向前一步，18年会对MIG核心产品的用户体验质量的目标始终以用户体验的结合和产品价值来进行考量。

更进一步，在用户体验度量指标确定后，如何实时分析决策就是另一项关键路径。通常会遇到三个问题：

1)数据通过终端上报上报的实时性、清理和计算的实时性。

2)指标多（16年浏览器在做用户体验指标是质量指标超过100个）、纬度多（用户归属、产品版本、功能细项纬度几十个），阈值随产品特性变化多，靠人工分析效率极低。

3)端到端调用分析决策链条长。

相应解法：

1)计算实时性保障：通过客户端和SDK实时可配置抽样上报，基于消息队列，通过程序实时进行数据清洗，存放至时间序列服务中，进行实时计算

2)实时计算特征模型训练（包括周期、非周期、波动、锯齿）结合调用链、基础环境、线上变更，进行收敛决策收敛

3)再补充一点AI in all但不是all in AI，业务的策略场景作为技术运营工程师必须清楚，机器学习只是一种工具和手段

更进一步，在终端发布质量度量魔镜体系构建工作，整体方案如下：

二、成本、效率

原则1: 成本生命周期在预算、预测、交付、运营、核算、服务下线回退，各方职责明确，并且各环节通过工具资源自动化交付，有明确的效率度量，找到短板，循环提升。

  

“随着你对事物的理解不断加深，你就能看到隐藏在扑面而来的复杂事物中的实质。你将明白你面对的事物属于哪种类型，并自然而然地运用正确的原则帮助自己渡过难关。接着，现实会向你发出强烈的信号，或者回报你或者惩罚你，以体现你的原则的运用效果，这样你就能学着相应地调整这些原则。所以我们能不能妥善应对我们遇到的现实，最重要的决定因素是有没有良好的应对原则。”

对谈95后复旦博士：

爱数学，也爱戏剧，做自己喜欢的事最浪漫