从技术谈到管理，把系统优化的技术用到企业管理

不少技术人员在职业上对本身要求高，工做勤奋，承担愈来愈大的责任，最终获得信任，被提拔到管理岗位。可是每每缺少专业的管理知识，在工做中不能从总体范围优化工做流程，仍然是“我的贡献者”的工做方式，遇到问题本身上，常常耽误了本职工做。因而翻了不少书，看了不少文章，学习了不少“为人处世的艺术”和“企业发展的战略”，最终把本身干成了研发部主管，技术却逐渐荒废。管理工做是什么呢，技术和管理是大相径庭的两条发展方向吗？

不是的。技术和管理都要作到量化分析，全局优化，存在不少类似的方法。这里用一个系统性能优化的场景举个例子，你们能够体会一下：

公司里有一个程序，运行在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台。

是否是告诉老板必需要买服务器了呢：“须要买1台服务器，带GPU的！”。先别着急。

咱们分析一下程序运行过程：识别函数和比对函数是串行执行的。识别函数忙碌的时候，比对函数是空闲的，它在等待识别的结果。一样的，比对函数忙碌的时候，识别函数也是无事可作的。也就是说，服务器的资源并无获得充分利用，GPU卡和数据库的资源都有很大的浪费。

怎样提升资源利用率呢？能够改变一下程序的架构，调整成下面这样：

 

 

把原来的程序一分为二，分别部署在两台服务器上，中间用一个消息队列交换数据。如今两个程序均可以充分利用服务器的资源。咱们再来计算一下吞吐量： 

• 程序X：处理一个图片须要0.5秒，1台服务器1天处理图片172800（86400 / 0.5），100万图片须要服务器 5.8 台（100万 / 172800），约等于6台。
• 程序Y：处理一个图片须要0.4秒，1台服务器1天处理图片216000（86400 / 0.4），100万图片须要服务器 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系统通常有各类文档，至少有源代码能够查看。企业工做流程常常存在一些模糊的地方，部门和岗位职责的定义不是十分清楚。人也不会像程序同样“听话”，为了完成本身的工做任务，人是有创造性的。因此每一个企业都要整理岗位和工做流程，努力把这些模糊的流程整理清楚，按照本身的业务特色制定一套流程规范，这是十分必要的工做。技术岗位上的人更熟悉实际的工做流程，他们走上管理岗位，在这方面是有优点的。

工做流程明确以后，就能够对流程节点进行度量。咱们能够采用可视化技术对数据进行分析，好比看板、资源投入状态、任务燃尽图等等，寻找卡顿活动，判断瓶颈资源。这方面有一些科学的方法，软件行业也在从制造行业学习精益生产的理论。对于一个大规模的软件企业，在管理方面有所改善，造成的效率提高是巨大的。