09 你的工作可以用数字衡量吗？
你好，我是郑晔。
今天的分享从日常工作开始。请你回想一下，你每天到岗之后做的第一件事是什么呢？然后你来猜猜我的答案是什么？你可能猜不到，我每天到公司之后，第一件正事是看数字。
我现在服务于一家做数字资产的公司，我们提供的是一个24小时运行的服务。从加入这家公司的第一天开始，公司的人就给我不断灌输一个重要理念——看数字。在我座位的正前方，摆着一个巨大的显示器，上面展示着各种不断变换的曲线、柱状图和数字，这些数字反映的是各种系统运行的指标。
我们就是每天看着这些指标，来发掘一些线上系统问题的，一旦某些指标出现自己不能理解的异常，就要着手调查。
你或许会纳闷，我们不是在探讨“以终为始”吗？怎么变成了一个关于监控的讨论呢？别急，我们确实还在讨论“以终为始”，因为数字是诠释“终”的最好方式。
我们前面讨论了各种“终”，但通常靠语言定义的“终”，或多或少都会存在一些模糊的地方，也就是容易产生误解的地方。而数字却是一个明明白白的“终”。比如，测试覆盖率要求100%，即便你做到了99.9%，不达标就是不达标，没什么好说的，说破天也是不达标。
再比如，之前内容我们讲到精益创业时，提到了一个重要的反馈循环：开发（build）-测量（measure）-认知（learn）。你会发现，在这个循环中，开发（build）是可控的，认知（learn）必须是得到反馈之后才能有的。所以，这里面最需要我们回答的问题是测量（measure）。而这里的测量，最好的检验标准当然就是数字。
或许你会说，数字我们都很熟，还用讲吗？不过在我看来，你还真的未必习惯于使用数字。
熟悉而陌生的数字
从进化的角度来看，人们做事更多是依赖于直觉的。数字，是人类在非洲大草原上奔跑了许久之后才创造出来的东西。著名科普著作《从一到无穷大》的开篇有这么一个故事：
两个匈牙利贵族决定做一次数数的游戏，看谁说出的数字大。
一个贵族说：“好，那你先说吧！”
另一个绞尽脑汁想了好几分钟，说了一个数字：“3”。
现在轮到第一个贵族苦思冥想了，他想了一刻钟，然后说：“好吧，你赢啦!”
这个故事听起来有些荒诞，但一些非洲探险家证实，在某些原始部族里，不存在比3大的数词。如果问他们有几个孩子，而这个数字大于3的话，他就会回答“许多个”。
虽然我们中华民族是一个重视教育的民族，现在也都承认数学是一门重要的基础知识。但我们还是习惯性地观其大略，因为在日常生活领域里，除了买东西发工资，需要对数字斤斤计较的场合并不多。
历史的车轮在不停地滚滚向前，当今社会所面临的复杂度已经远远超过凭直觉就能把事情做好的程度。
一些人说，自己靠直觉就能把事情做好，其实这是一种误解，因为那种所谓的直觉，通常是一种洞见（Insight），洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累，而这其实是某种意义上的大数据。
我们都在说，人类马上就要进入智能时代了。之所以这么说，主要是现在人工智能技术不断地向前发展着。而人工智能作为一门在50年代就已经问世的技术，直到最近几年才得到大踏步的前进，主要归功于基础设施的发展。
在人工智能领域，基于统计的方法早就在学术界提了出来，但由于当时的技术条件所限，人们的数据采集和存储能力都有限，当时的“大”数据和今天的大数据完全不是一个量级的概念。
直到进入到互联网时代，随着处理数据量的增加，基础设施在不断地拓展，进而促使人们采集更多的数据，这个正向反馈也造就了今天的大数据。
原本因为缺乏足够数据支撑，难以施展拳脚的 AI 算法，在今天一下子有了足够的表演空间，从一个边缘角色成为了舞台中心的主角。
今天谈到人工智能，人们主要会谈三件事：算法、算力和数据。算法几乎是行业共有的，而算力在云计算普及的今天也不再是稀缺资源，所以，数据几乎成了兵家必争之“物”。于是，我们看到的现象是各个公司都在努力地搜集各种数据，让数据成为自己的竞争力。所以，在大方向上，数据采集是一个行业共识。
但是，作为这个世界上最了解数据价值的一批人，我们程序员只是在努力地把数据用于不断改善别人的生活，而对于自己日常工作的改善，则思考得少之又少。
我们更习惯的讨论方式依然是靠直觉。比如：增加了这个特性可能会让用户增长，做了这个调整应该会让系统的压力变小。
在一些简单的情形下，或者说大家信息对称、知识背景相差无几的情况下，这样的讨论是很容易得到认同的。而当事情复杂到一定程度时，简单地靠感觉是很难让人相信的。
所以，在我们的工作中，经常会发生的一个现象是，一个人说，我觉得这个有作用，另一个人说，我觉得那个没有。几个“觉得”下来，双方就开始进入了隔空对话的环节，谁也无法说服谁。
如果换成用数字的方式进行讨论，效果就会更好。有一次，为了改善用户体验，我们准备进行一次主页改版。产品团队希望在主页上加上大量的内容，而开发团队则认为太多的内容会导致主页加载变慢，进而造成用户体验下降。
正当这个对话即将进入“空对空”的讨论之时，我们找到了一个测量指标：主页加载速度。只要保证主页加载速度，产品团队就可以按照自己的理解来做调整。于是，一个即将不可挽回的讨论，变成了在一定约束条件下的讨论，双方谁也不再思维发散，讨论就能继续推进了。
如果你认同了数据本身的价值，那么再结合“以终为始”的理念，我们就应该在着手做一件事之前，先来想怎么去测量。无论是在讨论产品特性，还是功能开发，“信口雌黄”是容易的，落到数字上，人们就会多想一下，这是对彼此的约束。
从数字出发
前面的内容我们都是在说应该重视测量指标，重视数字。接下来，我就分享下几个我在实际工作中运用数字的案例，让你看看习惯用数字去思考问题之后，会拓宽哪些思考的维度。
首先是基于数字进行技术决策。有一次，我们打算做一个技术改进，给系统增加一些缓存，减轻数据库的压力。大家一起设计了两个技术方案。如果查询是特定的，我们就准备简单地在某些方法上加上缓存；如果查询是五花八门的，就准备用一个中间件，使用它的查询方案。
系统现在的情况到底是什么样的呢？我们发现并不能立刻回答这个问题。于是，大家决定在系统中增加一些统计指标，让数据给我们答案。然后根据数据反映出的情况，进行具体的决策。
其次是一个准备上线的案例。当时，我们是要做一个影响力比较大的系统升级，因为这是一个系统的关键模块，上下游系统都会受到影响。
谁也不能确定哪个模块会在上线过程中出问题。于是，设计了一个全新的数据面板，将相关的几个模块的核心指标都摆在上面。而我们要做的就是在上线的同时，观察这些指标的变化。
所幸的是，这次上线影响不大，几个指标一路平稳，而大家的信心就源自这些提前准备好的指标。
再次，看一个从数字中发现问题的例子。由于各种历史原因，我们的重点指标面板上，会有几个指标表示的是类似的东西。
比如，某个模块的处理能力，一个指标是站在这个模块内部度量的，而另一个指标则是由这个模块上下游系统度量的。在大多数情况下，它们的表现是一致的。结果有一天两者突然出现了很大的差异，内部度量表现依然良好，而外部度量则出现了很大的延迟。
于是，我们开始追问为什么。一路追寻下来，我们发现，是这个模块内部需要定期将内部状态持久化下来，而在那个时间段内，这个模块就会停止从上游读取数据。所以，在内部看一切正常，而外部看则延迟较大。随后，我们找到了方案，解决了这一问题。
最后再说一个行业中的例子，据我所知，行业里的某些公司已经开始做所谓的 AIOps，也就是通过人工智能的方式，从数据中，发现更多运维的问题。无论哪种做法，都是为了从数字中发现问题，让系统更稳定。
我的一个同事有个观点非常值得玩味，他说，从数字上看，好的系统应该是“死水一潭”。
我是赞同这个观点的，因为出现波动尤其是大幅度波动，又不能给出一个合理解释的话，就说明系统存在着隐患。而让系统稳定，正是我们工作的一个重要组成部分。
回到这一讲的开头，我说每天工作中的一个重要组成部分就是看数字，其实就是在尝试着从数字的趋势中发现问题，如今团队已经习惯了“给个数字看看”这样的沟通方式，内部扯皮的机会也相应地减少了一些。
总结时刻
随着智能时代的来临，人类社会开始逐渐认识到数据的重要性。但我们这群 IT 人在通过数据为其他人服务的同时，却很少把数字化的思维带到自己的工作范围内。这也是工作中很多“空对空”对话的根源所在。
结合着“以终为始”的思考，如果我们可以在一开始，就设计好测量工作有效性的指标，那么就可以更有目的性地去工作了。
而如果我们习惯了用数字去思考，就可以在很多方面让数字帮助我们。我举了几个小例子，比如：基于数据进行技术决策、预先设定系统指标，以及发现系统中的问题等等。希望你也可以把数字思维带到你的日常工作中。
如果今天的内容你只记住一件事，那请记住：问一下自己，我的工作是不是可以用数字衡量。
最后，我想请你分享一下，你的工作中，有哪些应用数字解决问题的场景呢？欢迎在留言区写下你的想法。
感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。
- 彩色的沙漠 👍（43） 💬（3）
数据对技术方案选定，运营方案的改进，验证产品特性是否合理，面试，提供强有力的支撑作用。"数字也是沟通的一把利器，用数字说话，避免空谈"，可以提高沟通效率。 每个公司都有绩效衡量一个员工，但是我遇到的公司对于绩效这件事，衡量指标都都比较主观，唯一比较客官的指标是代码量和BUG数，不知道老师经历的公司是怎么衡量绩效这件事的，谢谢！
2019-01-15 - geoxs 👍（19） 💬（2）
我们的产品之前没有什么监控数据，有一次系统莫名其妙所有的api都变慢了，分析不出原因。最后还是写了个小程序读取系统日志，统计一段时间内每个api的调用情况（调用时间、调用时长、调用次数等等），导出成统计数据以后，一下子就清晰了。
2019-01-15 - Lambda 👍（15） 💬（1）
我们公司对内部系统有专门的的visibility team，对业务数据有metric analysis team，对新的feature有experimentation team
2020-03-04 - helloworld 👍（10） 💬（1）
想法很好，但是我所遇到的公司没有一个按照数字说话的
2019-02-21 - 大彬 👍（10） 💬（2）
特别认同。上周我把一个方案进行推迟了，让同事去搜集某项指标的数据，没数据，一切方案都是空谈。 AB测试，留言量，阅读量，转发量一切数据都是下一步决策和改进的基础
2019-01-14 - javaadu 👍（5） 💬（1）
阅读完“以终为始”这一个模块，感觉这就是TDD在做事中的应用。 另外，我在日常工作中负责团队系统的稳定性建设，对我来说，最重要的就是三个指标：故障率；回滚率；线上问题处理时效，我和我的团队都认同这组数据，大家做结果评估的时候也比较清楚，做计划的时候也能够有的放矢。
2020-02-16 - 西西弗与卡夫卡 👍（4） 💬（1）
比如开发常常关注的是产品经理提的功能有没有实现，实际上也应该了解做出来的有多少人使用，每个页面有多少人使用。 此外，看开发是否努力勤奋，不要光听他说，而是要看看他提交git有多频繁、提交的时间段、代码量有多少。代码质量可以用bug数/代码量来衡量。当然，这些量化未必科学，甚至会被误用，但总胜过凭印象拍脑袋的判断。
2019-01-14 - 大帅哥 👍（3） 💬（1）
线上接口日志统计少，很多业务日志虽然也加上了，但很少去关注。更多的情况是不知道打印哪些日志，更别说相关指标的数字了，上线新功能时只能人工的访问下接口，一个接口异常时，每天都需要花费不少时间去定位。现在有了日志和采集统计，一有问题立马可以看出来，随时做好回滚的准备。
2019-01-15 - mgs2002 👍（2） 💬（1）
原来待过一家公司通过bug数量来定绩效，每个月bug最多的要扣钱。。。
2020-07-08 - AlanP 👍（2） 💬（1）
感觉公司要做到CMM第4级还是有难度的，需要有人持续推进，也需要每个人都有量化的意识
2019-01-15 - Geek_q29f6t 👍（1） 💬（1）
用数字量化“终”，可以帮我们更明确“终”的定义，也能帮我们提前发现“终”存在的问题。
2020-07-31 - 令仔很忙 👍（1） 💬（1）
而当事情复杂到一定程度时，简单地靠感觉是很难让人相信的。
2020-05-23 - Better me 👍（0） 💬（1）
如果我们可以在一开始，就设计好测量工作有效性的指标，那么就可以更有目的性地去工作了。 这里与软件设计之美中的第三节最后总结的做软件设计，先考虑可测试性 相对应，也是结合了以终为始的方式来确保我们最后做出来的系统是可测试的，可减少后期很多集成测试上的小问题，以避免大量时间浪费
2020-06-02 - 亥时 👍（0） 💬（1）
系统的各项指标对于排障是非常有用的 不过对于迭代中工时的统计中 比如 开会、排查线上问题、技术支持等 要不要算在里边 分歧还是蛮大的
2020-05-30 - 新博 👍（0） 💬（1）
明确数字所代表的意义，在沟通的时候，特别是和非技术人员，能让自己的观点更有说服性。也让自己的工作有衡量依据。
2019-02-25