（转）“版本上线延时”问题与对策的探讨

【交易技术前沿】“版本上线延时”问题与对策的探讨 / 王洪涛

2017-08-28 上交所技术服务

本文选自《交易技术前沿》第二十五期 （2016年12月）。
王洪涛
海通证券股份有限公司，上海 200001
E-mail ：wht@htsec.com
摘 要：在与业务部门甚至不同公司的技术团队的沟通过程中，我们发现存在着很多的认识偏差，或者说很多时候看起来大家认为显而以见的内容和想法，怎么就沟通起来那么难呢？技术整体效率上有一个指标“版本上线延迟”，意思是从版本发布了到最后上线投入生产的时间。本文的一个目的就是希望在为什么需要控制”版本上线延时”这么一个简单的问题上予以探讨。分析主要是什么原因导致“版本上线延时”，以及我们可以采取哪些措施尽量弥补这方面的裂缝。本文不是一个项目管理的专业文章，更希望的是能够构建这方面的桥梁，试图以非专业的语言使得大家能达成一些共识。
关键字：延时、对策
1、版本快速上线的重要性
我们在多个环节都在提版本的快速上线，互联网企业更是强调快速迭代，然而在各种沟通当中，明显还存在着各种声音，对于版本快速上线的认识存在误区和不足，造成开发团队与业务需求方，甲方乙方面临各种冲突。 现在经常面临的问题：
我就只需要修正这一个bug，为什么要升级这么大一个升级包？
我就是不上线，里面的功能对我没啥用，我不上！我不上对你又没什么影响！
上线时间拖拖就拖拖呗，又不影响你后续功能的开发！
10年前上线的一个软件或功能我用得好好的，厂商居然说不支持就不支持了！这个厂商也太不负责任了。
今天（这周）能上线吗？又有什么东西不行啊？都要急死人了。
其中1，2，4的问题，对于开发人员、软件产品维护者应该是比较常见的！而第3、5个问题则是对于软件项目的管理应该相当常见！
那么为什么这几个在业务需求方或者甲方看来如此简单，如此显而易见的要求，对于开发和产品团队却是一个心口的痛，甚至有时候控制不好形成灾难性后果呢？
第一、 这几个看起来很简单的要求会使得产品或项目会产生很多的临时分支版本，如控制不住甚至会造成多版本共存。多版本多分支对于软件开发和产品管理很容易形成两线甚至多线作战；
第二、 多版本管理所带来的压力不仅仅是开发，更是软件生命周期长链条的各个环节，从开发、单元测试、集成测试都面临问题；
第三、 随着产品迭代，最先版本由于成本收入的压力（用户数量的急剧下降、开发队伍难以维持等）将逐渐减少投入，使得支持力度下降，出故障的可能性上升，从而影响产品和公司口碑。
第四、 所有软件产品都是有BUG的，只是早发生或晚发生的问题，尤其是用户数较少的情况下，不同的用户都有可能会发现BUG。对于其它用户发现的BUG，在开发人员修复该问题后，不可避免的需要同步升级到所有用户，以免其它用户因该已知BUG而发生生产事故。
这种版本管理的复杂度、多线作战的投入呈级数上升，且随着时间的推移原有版本的人员、技术支持资源都难以保证，这也是各种软件厂商对于版本的支持都会有时间策略的一个根本原因！
“2015年1月14日，微软已经正式停止对Windows 7操作系统的主流支持服务。微软对Win7扩展技术支持将持续到2020年1月14日。”
微软产品的主流支持服务(Mainstream Support)期限通常为五年，在此期间内，微软免费为产品提供安全补丁与技术更新。主流服务过期后，产品进入扩展支持(Extended Support)阶段，微软继续为其提供一段时间的扩展支持，安全补丁仍然免费，但技术更新转为付费。
所谓主流支持，包括免费的事件支持、保证期索赔、修复非安全性以及安全性漏洞，以及设计改变和功能要求，也就是说，停止主流支持服务之后微软不会再为Win7推出更新服务包（Service Pack）。拓展支持，其中免费的只包括安全补丁。
2、版本快速上线的阻碍因素
然而我们在讨论完了这些简单要求给开发和产品团队带来的困扰之后，也需要讨论一下为什么新版本不能及时上线，除了用户认识方面的问题，有些也是存在各种主客观因素使得不能及时升级。笔者作为开发人员、开发管理人员、项目管理人员、运维管理人员等角色在甲方和乙方都工作多年，碰到了多种多样的问题，总结而言，主要存在以下主要几个因素：
一、 客户/用户担心其原有功能会受到不可知的影响，这需要其做仔细的全功能回归测试，而用户方可能在测试人员、测试案例、测试经验、测试精力、测试时间等方面均存在不足；
二、 该系统与其他系统有关联，每次变更都可能存在系统间接口的变动，协调各关联系统的测试周期、同步测试、完整测试难度很大；
三、 安全、等保方面要求的强制性在增强，尤其是近一年来。而技术服务提供商和证券公司内开发团队对这些方面的认识或重视度还没有跟上，出现了资源倾斜短板，导致匹配相关要求的软件产品质量不够好，多次反复修改，使得上线时间拉长；
四、 升级需要部署调整，硬件、软件资源没有及时协调，使得上线需要的资源缺乏，工程实施方面存在不足。
五、 系统本身干系人非常多，特别在牵涉多个部门的情况下，各个部门的关注点存在差异，人员安排与配合都容易出现问题。
六、 公司团队自己内部没有把握，很担心，不愿意上线。
3、版本快速上线条件优化
总的来说，这些因素可以归属于以下几个方面：
测试成本和测试手段；相关资源的协调安排、项目管理；用户沟通和协调；安全及控制能力。针对这些问题，笔者提出一些应对方法，希望能在证券公司现有架构下、以较低的成本能获得明显的改善：
一、 加强项目管理培训和内部流程梳理优化
及时梳理优化项目管理流程，同时采取各种有效培训使得熟悉生产及上线要求成为项目管理人员的一种基本能力。一直以来，证券行业技术团队的过于精干使得行业IT人员在项目管理方面是有整体优势的，然而，近年来，整个证券行业的技术团队急剧扩张以及各种规范要求的变化演进，使得这种能力在近段时间出现了某种程度的缺失甚至断层。
在已知新出现的规范要求的变化上，比较明显的变化有：
系统上线前要做应用安全扫描（如果有源代码的，还需要做代码安全检查），服务器都需要做安全扫描（安全方面比较多，原来也有这些要求但是执行上没有现在这么严格）。
系统各种备份建设的要求（主备温灾，RTO,RPO等概念和明确要求）。
采购流程的要求（对于国有企业比较明显）。
统一的服务管理难度越来越高，尤其是伴随着业务的复杂化和系统的多样化，各个系统之间的数据交互日趋复杂。
对于项目进展到某些阶段针对一些常见使得上线延迟的问题及早安排，例如充分考虑硬件设备采购周期，提前采购（或保持一定的资源冗余，例如私有云或预备部分标准资源）；安全扫描在初始进入测试阶段（有条件最好在开发阶段就每日扫描）就开始扫描；设备运行环境也在安装时就开始扫描，及早打上补丁；尽早确定项目备份等级，在项目初期就作为一个评估规范项；加强系统间接口管理，做好相关系统的测试验证和接口分析工作。
二、 业务部门测试人员保障机制
测试人员特别是业务部门测试人员配置目前看是严重不足的，所以在某些重点版本情况下，对于技术开发团队都可能会需要全员测试，全员成为测试人员，推动保障测试进度。
而在我们行业内，业务部门的测试人员安排严重不足更是目前非常普遍的情况，一些业务部门对于业务系统的测试认识存在偏差，对于参加业务系统测试不够重视，导致业务系统的测试很少能排入重点工作清单。或者说，安排来做业务测试的人员基本上都是业务新手，把参与系统测试作为新人熟悉业务的一种锻炼途径。
对于此，证券行业需要向其他行业学习，将安排参与系统业务测试的人员作为年度工作、日常工作中非常重要的一部分。建议业务部门在提出业务需求时就充分考虑好参与业务测试的工作。当然技术团队在排计划（开发、测试、实施等计划）的时候，也建议将业务部门参与测试的人员作为重要资源进行排期。
业务部门有时候会因为突发的因素（比如突然出差或者由于某项监管部门的某项突然的专项行动等）使得原有的承诺无法达成，因此业务部门在安排人员时也需要注意内部人力资源的配备，应避免一个系统只有某个特定的人员才能验收甚至只有某个特定人员才能测试的情景。这种单点验收（测试）人员的安排对于系统建设来说将是非常大的风险隐患。业务部门需要有意识的平时就做好人员安排，配备好A/B角，有条件的还应该建立分公司营业部业务条线人员测试参与体系。
同时目前业务需求更多的仅考虑了一般性的业务测试流程，或者说更多的关注于某单一业务测试的场景，而对于多并发测试场景的设计、多业务多流程并发测试场景的设计则处于极度缺乏状态。这也是需要业务部门配置业务专家、业务测试团队来精心设计的原因。上线后的业务级故障之所以会发生，多数也是因为发生了一些当时没有预料到或需求中未提及的、没有测试到的“低频”业务场景，而这些依靠技术公司、技术部门的测试人员是很难全面覆盖的。
三、 运用高效、有效的测试/分析工具（或环境）降低系统更新上线的消耗和故障概率
在多接口、复杂的系统建设发布之后，高效的测试工具（或环境）也是一种非常重要的配套需要。事实上，构建多套相对独立的、分工明确的测试环境，并为这些测试环境常规配备其主要测试任务所需要的测试工具，且保障这些测试环境和工具的可用性，将极大地影响测试效率，从而提高上线系统的并发度。
现在的系统很少是完全独立运行的，可能对外开放了很多接口，或者调用了很多接口，一个升级包的修改，如果要与之相连的所有系统都来验证功能正常，这个面临的工作量将是巨大的，甚至很多时候是不可能完成的任务。尤其是在很多的情况下，系统内的修改不会直接对接口定义进行变更，然而如果没有高效的方法来验证，谁也无法保证那些接口功能就真的不会受到影响。
因此技术开发商或者开发团队，对于此类对外提供接口服务支持的系统，需要下功夫开发高效测试工具和分析工具，例如接口发包测试工具、从生产环境录制通讯包工具、日志回放工具等等，通过这些工具及时发现接口的变动情况、充分模拟生产环境中各系统之间的接口调用情况等。
同时还需要借助各种测试和分析工具来完善服务治理，在存在接口变动时，需能清晰找到受影响的上下游。除了人工血缘分析（比如查看服务管理文档）外，也过工具分析生产环境或测试环境上的系统间调用情况，可以成为为人工分析补漏的一种重要途径。
四、 高度重视多部门间协调的项目
多部门间协调的项目，首先要定好业务主管部门，业务主管部门需要能切实负起主管责任来协调多个部门，如若该系统的业务主管部门主管人员不能保证足够的时间，具备较强的协调能力则容易出现灾难性后果。如果一个公司内存在着比较明显的业务条块分割情况，对于需要多个部门间协调的项目在立项和需求上就需要谨慎。如果是时间非常紧迫的业务型系统，有时将系统缩减为部门级项目可能会是更明智的选择。当然，如果有调查，我相信一般公司都不会承认自己是个难以部门间协调的公司，每个部门也都会表态说一定会好好配合（毕竟这是个政治正确的问题）。
要通过内部沟通而建立起集中一致的系统，笔者认为，是需要一个高效率机制或存在集权式管理方式的，否则其内部沟通成本将可能是难以承受的。毕竟沟通成本除了时间外，更多的是对人的消耗，而人对于金融机构而言是最重要的资源，是经不起这种消耗的。烟囱式部门级系统建设在各种咨询报告中都成为抨击的对象，然而如何以及在什么层面破除烟囱式系统的建设，这不是一个纯粹的技术问题，需要充分考虑公司内部的现实情况，充分平衡冗余设备成本与沟通成本、时间机会成本。
五、 公司内部建立起追求专业、敢于担当以及尊重人的专业判断能力的技术氛围
证券行业是个高度竞争且技术密度要求高的服务行业，各种新的技术和新的业务模式都会层出不穷。我们必须紧跟时代潮流，才能使得公司不断进步，保持应有的竞争力和行业地位。然而各种新的技术和业务模式在带来竞争力的同时，也会自然的给决策人员带来一种内心的恐惧感，特别是对于不熟悉的领域。
因此内部需要有业务和技术专家级人才团队，这样才能充分拥抱新的技术，同时又有专业、敬业的牛人把控风险，使得公司能够不断了解、接受、采用新技术，不断走在行业前列，日积月累下来就会不断拉开差距。
同时公司内也需要建立起尊重人的专业判断能力的氛围，法条型的控制措施一定要能带来实际的效果。如果增加的控制措施经过推演后发现很难发挥实际的效果，或者控制措施成本较高，大幅超过保证正常运转的成本或使得效率下降到难以承受的水平，那这种控制措施最好不要增加，否则很容易成为一种形式。在很多情况下，人的专业判断能力可以综合平衡风险、收益，判断极端情况，不太可能也不必所有都通过条文规则来规定。
够专业、敢担当，不怕风险又有能力控制风险，既规范又充分尊重人的专业判断能力，形成合力，公司才能不断取得成绩。
4、总结
控制“版本上线延时”及时上线，对于技术公司、对于开发团队都是极为重要的。
对于技术服务商，可能关系到利润是正还是负，甚至会关系到公司的生存与发展。而对于证券公司来说，这方面的管理也是极为重要的，系统的及时上线可能对于某一个点不是那么重要，但日积月累就将造成巨大的差异，请大家牢记：
1.01的365次方=37.8
0.99的365次方=0.03
同时它也关系着所有项目参与其中人员的方方面面，业绩、成就感，公司和团队的凝聚力、战斗力也都与此密切相关。