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

微信邦

来源 /无限运营部

编辑 / Coding学院

转眼加入鹅厂快10年，从TAF基础框架运维到从0到1助力浏览器登顶再到逐步依托米格云的面向MIG所有产品。业务形态从SP业务、门户网站到智能终端再到IoT，质量从纯后台服务质量到端到端基于用户体验价值再到数据服务质量，成本从自有资源为主到云平台资源为主，变更方式从DO分离到研发运营一体化，对应的开发从十几人到上千人，在扑面而来的变化中，也会迷失技术运营的本质而故此失彼，前事不忘后事之师，希望能不断总结反思，保持初心继续前行。

       回顾历程分为四个阶段：

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

       产品形态和技术需求的变化如下：

         

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

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

     根据产品的生命周期，技术运营提供的服务提炼如下：

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

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

一、质量

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

举个案例：

10年负责taf平台运维时，主导过基于场景细化TAF框架下调度策略和机制。tay在询问开发时，开发答复是运维不用关心这个，其实开发本身对主控的更新策略、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，在架构评审时，曾总说过一段话一直记忆犹新：

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

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

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

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

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

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

更进一步，遵从上述原则，MIG整体业务架构能力演进以及容灾能力状况如下：

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

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

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

举个案例：

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

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

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

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

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

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

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

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

相应解法：

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

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

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

基于上述的解法构建的整体技术方案如下：

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

2.效率：

原则1:在保障SLO（服务水平目标）的前提下，基于线上运营数据，通过流程和工具持续优化，最大化产品迭代速度。

举个案例：

10年时手机浏览器还在内测阶段，后台服务之间相互调用依赖，开发随意发布出了几次故障，之后tay接手手机浏览器运维工作，第一件事就是找每个开发理解服务逻辑，召集所有开发收回发布权限，每个开发只关心自己服务就好，由运维统一制定发布计划每周两版本方式保证产品迭代速度。救火的事情明显减少，研发效率不降反升，运维在整体架构的设计和话语权和明显提升。随着手机浏览器的后台服务和开发逐渐增多，发布的相应流程和监控机制也逐渐完善，在15年完全交由开发发布，也完成了从人工控制到流程、工具支持的转变。

向前一步，为更快给用户提供最新的功能，研发迭代的目标一定是功能越快上线越好，同时我们也认为频繁的发布可以使得每个版本之间的变更减少，这种方式使得测试和调试变得简单。之前在职责上运营部重点关注CD阶段，对于CI阶段只是资源和基础质量的支持，17年也爆发了乐问吐槽MIG开发机的问题，当下在整体推荐研发运营一体化方案，希望能在保证SLO的前提下进一步提升研发效率。这里着重强调灰度发布的意义，不同业务量下，系统表现会不一样，尤其在当前数据算法模型直接会对用户体验产生影响的当下，构建多级灰度环境和ABTest能力，是业务产品工程能力的关键。

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

更进一步，在15年运维侧也基本完成终端发布质量度量魔镜体系构建工作，整体方案如下：

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

3.成本：

原则1:不管业务架构如何变化业务运维需要以业务资源成本第一责任人角度主导关注成本规划和管理。究其原因：

1)服务容量不管是自身资源还是云资源对可用性来说都是极为重要的，所以这里运维必须关注并主导容量的规划。

2)对于业务场景、架构、应用组件的深入理解，找到合理资源和架构方案支持产品快速发展是运维提升自身技术能力和价值体现的关键路径之一。

举个案例：

17年手管SDK请求量不断增加，业务接入和逻辑层按容量规划进行了扩容，但数据层的请求并未完整关注，一方面数据层容量不足另一方面程序重试导致雪崩。解决方案对手管业务建立完整全链路容量分析报表，并找到架构隐患点解决。

再举个案例：

翻译君是MIG明星级AI类创新产品，之前为追求性能对于翻译的在线服务采用多线程方案，但是看实际压测数据随着线程数的增加CPU吞吐量也会明显下降，从线上数据分析40字以下的翻译占比60%+，铁一样的事实，推进开发根据字长修改线程模型，当前线程模型10字以下单线程，10-30字6个线程，30字以上使用GPU方案，

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

更进一步：面对新的数据驱动的业务架构，理解数据架构和计算原理，建立数据资源模型和管控机制，是业务运维下一个非常明确的发力方向，能看得到的事情：
1)深度结合业务当前的场景进一步加深对当前的数据架构和数据应用的理解。

2)计算平台特性、资源种类、应用场景三个方面形成有效的知识积累和模型积累

3)主动参与到数据计算、机器学习等的技术调优

原则2:容量从管理到规划，保障业务有足够的容量和冗余度去服务预测中的未来需求。一个业务的容量规划，既包括自然增长容量，也需要包括一些非自然增长的因素（新功能、新产品发布、运营推广等因素）的快速支持。（此处原则参考SRE）

容量规划的三个步骤是必需的：

1)必须有一个准确的自然增长需求预测模型，需求预测的时间要超过资源获取的时间。

2)必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应。

3)规划中必须有明确的非自然增长的需求收集和形成规划的策略。

4.安全：

原则:安全是底线。常规管控有漏洞快速解决是基础。通用方案的快速彻底推进，研发控制漏洞减少，外部风险提前感知，内部系统防渗漏能力提升，是主动应对的关键。

举个案例：

16年2月，加拿大安全实验室citizenlab通过安平通报手机浏览器数据传输加密方式为RSA密钥128位易破解方案，准备在4月15日通过华尔街日报等国外媒体发布相关漏洞。之前该实验室也爆过UC浏览器类似漏洞并且UC浏览器对外确认完全修复漏洞后，又被挖出漏洞，引发又一轮报道。

当时技术侧应对方案提示加密强度并修改为云控下发在一个月内完成50%的用户更新。同时方案推进至MIG所有客户端业务完成加密完善，各业务接入层也都各自收敛统一。

对外媒沟通也联合市场部、法务、国际传讯的同事应对华尔街日报的提问。由于应对及时并未该事件并未造成公关问题。同时MIG所有业务产品的接入层加密也统一进行了一轮加固。之后MIG也没发生过类似的安全公关危机。

安全无小事，出事就是大问题是底线。合理的安全规范和策略是变被动为主动的关键。

以上是tay个人经历中觉得有意思值得反思总结的点滴，再把基于此提炼的如何成为一个靠谱的业务运维的部分原则总结如下：

1.质量

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

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

2.效率

原则：在保障SLO（服务水平目标）的前提下，基于线上运营数据，通过流程和工具持续优化，最大化产品迭代速度。

3.成本

原则1：不管业务架构如何变化业务运维需要以业务资源成本第一责任人角度主导关注成本规划和管理。

原则2：容量从管理到规划，保障业务有足够的容量和冗余度去服务预测中的未来需求。一个业务的容量规划，既包括自然增长容量，也需要包括一些非自然增长的因素（新功能、新产品发布、运营推广等因素）的快速支持。

4.安全

原则:安全是底线。常规管控有漏洞快速解决是基础。通用方案的快速彻底推进，研发控制漏洞减少，外部风险提前感知，内部系统防渗漏能力提升，是主动应对的关键。

最后，附上之前拜读《原则》这本书中达里奥对于原则很经典的观点，个人觉得很受用，也希望能在以后的日子里随着变化不断充实技术运营的原则。

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