很多技术人员对自己的专业要求很高，努力工作，承担越来越大的责任，最终获得信任，晋升到管理岗位。然而，他们往往缺乏专业的管理知识，不能从整体工作范围优化工作流程。他们仍然以“个人贡献者”的身份工作。遇到问题，往往耽误自己的工作。于是我看了很多书，看了很多文章，学了很多“为人处事的艺术”和“企业发展的方略”，终于让自己成为了研发部的负责人，但是技术却逐渐变得过时的。什么是管理工作？技术和管理是两个完全不同的发展方向吗？不。技术和管理都必须进行量化分析和全局优化。类似的方法还有很多。下面是一个系统性能优化场景的例子。大家可以体会一下：公司有一个程序运行在10台服务器的集群上。现在业务量变大了，无法处理请求。老板来找你，让你优化这个程序。接到这个头疼的任务后，你把开发、测试、运维各个部门的人都请来开会，想办法解决。有人说要升级数据库，有人说代码太烂需要优化，有人说机器太少再加5台，有人说得改架构去上云，上云之后，就不会有这些问题了。你应该听谁的？不要着急开始。有句话叫“没有测量，就没有优化”，首先要做的就是对这种现象进行“测量”。先找设计师，搞清楚程序的功能是什么，工作流程是怎样的。程序架构：本程序处理图像识别的业务，从网口接收图像，识别图像中的信息，在图像库中进行比对，最后输出相似图像。过程是这样的：弄清楚程序架构，接下来我们需要测量数据。有些数据很容易得到，有些数据似乎没人能弄清楚。于是你给研发组布置了一个任务，就是在程序中埋点，尽快收集一些数据指标。开发人员更改了程序的一个版本并进行了部署。在生产线上跑了一天，得到了一些数据指标：输入：每天需要处理100万张图片，这是从上游流程收集的识别函数：识别1张图片的平均时间为0.5秒比较函数:比较1张图片的平均时间是0.4秒现在我们来计算一下：处理1张图片的时间是0.9秒（0.5+0.4），1台机器1天可以处理96000张图片（86400/0.9），10台机器可以处理1天图片96万张（96000*10），不到100万张。要完成每天100万的处理能力，需要10.4台服务器（100万/96000），约等于11台服务器。你有没有跟老板说你要买服务器：“你需要买带GPU的服务器！”。别紧张。下面分析一下程序的运行过程：识别函数和比较函数是串行执行的。当识别函数忙时，比对函数空闲，等待识别结果。同样，当比较函数忙时，识别函数也无事可做。也就是说服务器的资源没有得到充分的利用，GPU卡和数据库的资源被极大的浪费了。如何提高资源利用率？可以改变程序的结构，调整为：把原来的程序一分为二，分别部署在两台服务器上，中间用一个消息队列交换数据。现在两个程序都可以充分利用服务器的资源。我们再算一下吞吐量：程序X：处理一张图片需要0.5秒，1台服务器一天处理172800张图片（86400/0.5），100万张图片需要5.8台服务器（100万/172800），大概是6。程序Y：处理一张图片需要0.4秒，1台服务器一天处理216000张图片（86400/0.4），100万张图片需要4.6台服务器（100万/216000），大概5台还是需要11台服务器，它似乎没有任何改善。我们再分析一下：原来的方案需要11台带GPU的服务器，现在只需要6台，我们省了5块GPU卡，这已经是一笔不小的开销了。架构师提供了另外一条信息：在原来的方案中，识别功能和比对功能是串行执行的，所以只能以相同的并发线程数执行。新的解决方案被分成了两个程序，所以比较函数可以设置更高的并发线程数，可以增加到原来的4倍。这是个好消息。程序Y的吞吐量可以提高4倍。这样处理100万条数据只需要1.16台服务器，也就是2台服务器左右。根据改进后的架构，只需要6台带GPU的服务器，加上2台不带GPU的服务器，总共8台服务器。不仅可以完成处理任务，还可以预留一些GPU卡用于以后的业务发展。例子说完了，以上就是优化一个IT系统运行效率的过程。其实企业管理也是一个类似的过程，只不过优化的对象不再是机器和程序，而是人的活动。在一个软件公司中，有需求收集、产品开发、项目实施等多个过程。有时候这些流程会卡住，变慢，这好像是IT系统的问题一样。有一个著名的问题：“你的团队需要多长时间才能让只涉及一行代码的更改上线？”从需求到交付的这段旅程有多远。我们可能经常会遇到这样的问题：某位现场运维反馈了一个缺陷，看似是个小问题，修复起来也不麻烦，但是却花了很长时间才解决。事后回顾这个问题，各个部门的人都有话要说：运维：我一发现这个问题，就在Jira平台上提出来了。当时开发没有回复，就下班了。开发：我正在开发该功能的新版本并编写非常复杂的代码。看到这个问题的时候，已经是下班时间了。运维只描述了问题现象，并没有说明现场部署的版本。不知道在哪个版本上解决这个问题，只好先在最新的release版本上改，然后发包测试。我也在Jira上回复了消息，让运维发来现场版本号。测试：收到开发包，打算测试一下。整个集成环境都升级了，我需要把测试环境恢复到老版本。搞了一个上午，下午做了测试，发现了几个缺陷，然后把问题反馈给开发。开发：收到测试提交的bug，修改后又发了一个版本。这次应该没有问题了。运维：环境中的包没有版本标识。我查了好久所有版本的Md5码，才找到版本号返回到Jira上。这个问题很紧急，想尽快解决，于是拿了测试给我的最新版本尝试安装。不知道这个包能不能兼容live环境，只能试试了。搞了一天预发布环境，也没安装。好像不行。开发：我看到实时版本号，这是一个非常旧的版本，已有一年多了。我做这个项目才三个月，微信上AT了好几个人。我不知道代码基线在哪里。我花了很长时间才找到它。来不及修好，还是得交给测试人员。测试：集成环境还是要恢复，我做了三个小时。测试确认没有问题后，再交给运维。运维：收到安装包，在预发布环境中试用，没有问题。生产环境比较麻烦。一开始只更新了一个节点，发现问题还是断断续续的出现。后来才知道原来还要部署2个节点。这次折腾了一天，下次遇到这种情况，我就知道该怎么办了。从每个人的角度来看，他们都很忙，花很多时间解决问题。但从缺陷解决的角度来看，事情总是卡在等待中。在这些劳动过程中，有多少劳动是真正有效的，能够产生价值的？这就是DevOps需要解决的价值流问题。有必要建立一个系统来衡量这个过程并不断优化它。从上面解决一个缺陷的过程来看，技术部门的问题比较多，有些是单点问题，比如：代码管理：代码基线不清晰，版本不能追溯发布管理:发布文件没有妥善保存版本管理:版本号没有标明，编号不清楚。无法判断新旧版本兼容关系基础设施管理：研发人员无法快速获取基础设施，搭建测试环境耗时长部署管理：测试人员手动部署，耗时较长a部署环境管理：现场服务器上部署了哪些流程，没有一套管理方法，需要登录查看，看到这些问题，是否可以着手改进？还是慢慢来吧。就像优化一个IT系统一样，我们需要弄清楚工作流程，然后衡量流程，然后整体优化。当全局不明朗时，局部优化是没有用的。优化局部效率可能会适得其反，并造成更大的浪费。弄清楚整个过程当然有很多困难。一个大问题是企业工作流程不像IT系统流程那么清晰。IT系统一般都有各种文档，至少可以查看源代码。企业工作流程中往往存在一些模糊不清的地方，部门和岗位职责的定义不是很明确。人类不像程序那样“听话”。为了完成自己的工作任务，人类是富有创造力的。因此，每个企业都必须梳理岗位和工作流程，尽量梳理这些模糊的流程，并根据自己的业务特点制定一套流程规范。这是一项非常必要的工作。技术岗位的人更熟悉实际的工作流程，他们走上管理岗位在这方面更有优势。工作流程清晰后，就可以测量流程节点了。我们可以利用可视化技术分析数据，如看板、资源投入状态、任务燃尽图等，找出卡住的活动，确定瓶颈资源。这方面有一些科学的方法，软件行业也在向制造业学习精益生产的理论。对于大型软件公司来说，管理的提升会带来效率的巨大提升。
