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

从技术谈到管理，把系统优化的技术用到企业管理 2021-03-21 很多技术人员退职业上对本人要求高，工作勤奋，担当越来越大的责任，最终得到信任，被提拔到管理岗位。但是往往缺乏专业的管理学问，在工作中不能从全体范围优化工作流程，仍旧是“个人贡献者”的工作方式，遇到问题本人上，经常耽搁了本职工作。于是翻了很多书，看了很多文章，学习了很多“为人处世的艺术”和“企业进展的战略”，最终把本人干成了研发部主管，技术却渐渐荒废。管理工作是什么呢，技术和管理是截然不同的两条进展方向吗？ 不是的。技术和管理都要做到量化分析，全局优化，存在很多相像的方法。这里用一个系统功能优化的场景举个例子，大家可以体会一下： 公司里有一个程序，运转在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平台上