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