ToB服务交付方式分为公有云部署和私有部署。其中，对成本敏感的中小企业往往采用公有云部署来最大限度地降低成本。客单价高的大型企业、政府、银行、事业单位，出于对数据隐私、安全、合规要求的考虑，往往采用私有化部署方式。基于对公司营收的巨大贡献，私有化部署成为ToB公司的重中之重。在众多的私有化部署场景中，比较复杂的是公有云厂商的私有云产品。之所以复杂，是因为这些厂商直接将公有云的核心功能打包进行私有化部署，而垂直解决方案往往提供单一的功能，其难度可想而知。在国内，京东云的JDStack、金山云的KingStack、腾讯云的TCE、阿里云的ApsaraStack在国内都采用了这种模式。1、存在问题：部署耗时，成本私有化耗时的部署一般需要两周左右，让人觉得时间太长。但是从耗时的角度来说，一个大订单从开始到最后完成需要半年到一年的时间是很正常的。这样一来，两周的部署时间占比不到10%，不算项目交付的耗时。主要矛盾点。但如果在耗时两周的部署背后，从研发团队调来数十名高级工程师加班加点，日以继夜换来的，恐怕所有人都无法淡定。假设某大型央企私有化异地交付项目部署时间为20天。期间累计现场参会人数超过60人，现场参会高峰人数超过30人。30%的人员为高级工程师，相关人员往返两地频繁。粗略估算一下成本，至少50万，这样的模式只能靠初期交学费来吸取教训。在费时费力的优化部署中，还需要考虑客户行业的特殊性，尤其是涉及国计民生的领域。越来越美的互联网快速迭代，不一定适用。我们可以建议在入场前准备好需要的资源，但也只能是建议。对于现场部署流程，如各种审批流程和要求、甲方工作人员每天的工作时间、基于安全因素对数据传输和复制的限制等，都会影响最终部署时间。因此，相对于部署的耗时优化，部署成本的控制更为现实。如果部署工作外包，过程中不需要公有云厂商的技术支持，只要将部署时间控制在客户可接受的范围内，厂商也有能力实现大规模批次。2、存在问题：质量缺陷什么是质量缺陷？简单来说，当你完成私有云产品的私有化部署后，最坏的情况下，系统可能完全无法使用，大多数时候，一小部分功能无法使用。质量缺陷有什么影响？最糟糕的情况是，你已经成功地将你的客户转化为你的测试团队，而你不断从你部署的系统中反馈各种问题，逐渐失去客户对你的信任。既然是公有云验证的产品，为什么私有化部署会有那么多功能不可用（或者叫质量缺陷）？我认为有以下两点：复杂性：从厂商的角度来看，公有云产品由上百个模块组成，对外提供几十种功能，涉及网络、硬件、操作系统、程序、配置、上下游依赖等、数据等方面，公有云厂商中的这样一款产品往往是由多个部门的数千人耗时数年打造而成。现在新成立的交付团队很难处理一个涉及数千人的复杂系统。众所周知，要熟练使用公有云产品提供的几十个功能，需要很长时间，更何况上百个模块，上百个配置文件，上百个模块的复杂性。依赖，不同的开发语言，几乎涵盖了业界所有的主流开源软件等等，还有为了一个小功能搬动全身的痛苦。兼容性：从客户的角度来看，不同行业的不同客户确实是不一样的。不同的基础设施供应商，不同的网络协议，不同的硬件品牌和型号，不同的操作系统和内核版本，不同的登录和认证方式，不同的安全需求，不同的资源提供方式，以及各种非常小的东西，比如非常不常见的数据库，软件更多与十年前相比，小众的编程语言等。为了兼容这些差异，专有云产品必须临时开发一些定制化的功能，这也成为了质量缺陷的重灾区。3.存在问题：可操作性为什么在公有云环境中反馈良好的产品，在私有化部署中却被吐槽这么多？主要原因是在公有云场景下，问题被分解成多个部分。比如每个产品都做得很好，每个产品平均只有一个部署问题。对于开发了几十个模块的数百人团队来说，这已经是一个不错的成绩了。.但同样的问题在私有化的环境中并不好玩。50个产品，每个产品在部署的时候都会出现小问题，交付团队人少，对系统的掌握程度不如研发团队。你要他做什么？某云提供的运维手册多达2100页，体积80MB。我不知道我最后一次读到这样的书是什么时候。当然，文档也是交付的必要内容之一。从这个角度来说，有些云在国内还是做的很好。4、如何解决存在的问题？通过降低部署过程的技术难度，实现一键部署能力，将交付工作交给外包团队，实现大规模批量交付。整个流程大致如下：第一步，原子拆分部署流程；第二步，规范每个原子部署步骤，比如输出异常，统一全局错误码，方便寻找解决方案；第三步，对每个部署步骤进行多次部署可靠性验证和回滚验证，保证每次原子部署操作都有很高的成功率，同时回滚后不会对二次部署造成影响第四步step是为每个原子操作提供功能测试能力，确保只有操作正确后，才会进入下一个操作环节；第五步，梳理各个原子操作关系之间的串并关系和依赖关系，从而生成部署时序图，然后基于部署时序图创建一键部署能力。这里需要注意的是，一键部署并不代表全自动化部署，很长一段时间内可能无法做到100%全自动化部署。很多环节，尤其是前置依赖，还是需要客户的配合。业内不少厂商也在提出一体机的概念。一体机解决方案确实更好。理想情况下，在客户机房放一批机器，通电架网即可使用，公有云厂商的硬件成本更有优势，客户也能看到“真货”，但在目前，它主要供企业客户使用。5.值得注意的关键点部署流程图是整个解决方案中最重要的环节，没有之一。类似于工程施工图，从头开始对整个工程的所有流程、环节、工艺标准、施工要求、依存关系和注意事项进行了完整的描述。部署流程图不能停留在模块部署的内容上，而是要涵盖从网络实施、硬件放置、操作系统安装到部署服务的所有环节，确保一键部署的成功率。找一个完全空白的环境，不断从头开始重建。相信大家可以整理出一个完美的部署流程图。在这里再次提醒大家，所有环节都要覆盖，尤其是那些你没接触过的部分。以我为例，我在交换机参数的配置上就吃过几次苦头。功能验证，以客户定制需求为例，研发完成后，自测和测试通过。运维验证通过后，版本打包发布，交付发现功能存在缺陷。这时候R&D可能会生气。有问题怎么不早说啊！因此，功能验证需要整合产品、研发、测试、运维、安全、法务、合规、交付、客户功能验收等需求，便于及早发现问题，降低返工成本。具体来说，就是在每个原子操作执行完之后，对涉及到的功能、接口、页面进行全面的验证，在每个阶段完成之后，还要对阶段的组合功能进行验证。同时检查相关模块的实例数量、实例规格、依赖关系、健康状态、配置正确性、错误日志、性能指标等，检查相关配置是否实际生效。多管齐下，保证每个原子操作的正确性都能被准确判断，异常情况下尽可能给出异常原因。一致性维护，使用Puppet等配置管理工具保证服务器配置的一致性，如NTP、DNS、YUM、信任关系，统一收集日志、工具列表和版本、系统参数，避免因缺少造成的质量缺陷手动维护和遗漏问题。例如在部署阶段，由于NTP时钟不同步导致的趋势图无法显示实时数据，定位问题需要耗费大量人力。Checklist主要是对标准规范、统一配置、最佳实践、容易出错的问题和会导致严重后果的问题进行再确认，避免后期大规模返工或失败。例如，配置更改后需要重启服务器才能生效的策略，不仅需要检查配置是否生效，还需要在执行相关步骤后检查服务器的运行时间；Systemd拉取的服务需要检查其设置是否会在开机时自动启动；系统安装好后，确保所有磁盘都是XFS格式，并全部写入系统配置；所有用户自定义的内容都需要再次检查是否生效，比如不同用户要求的超卖比例。虚拟化启动自检，模块虚拟化部署，使其与硬件、网络协议、IP地址等用户资源解耦，实现多环境镜像固化，大大提高成功率模块部署率。短时间内无法虚拟化的模块必须实现启动自检功能。在物理机或虚拟机环境启动前，需要检查环境是否满足你的要求，比如JAVA是否可用，版本是否满足要求，Swap是否关闭等全球标准化，走服务启停方法为例，全部汇聚到Systemd方法拉起服务，用户只需要知道进程名即可实现对任何服务的启停操作，日志切分全部由程序自己实现，无需外部crontab，不仅降低了复杂度，而且大大提高了可操作性。插件化，针对APC产品的定制化功能，尽量由系统以插件的形式支持，避免直接修改相关代码造成后期不可维护。以登录功能为例。目前主流公有云都支持多种登录方式。这样，在私有云模式下，多增加一种登录方式，对整个系统的影响就很小了。六、最终效果通过一键交付整体解决方案的实施，私有化部署的成功率得到了极大的提升。我们现在可以确保所有核心功能在交付后都可以正常使用。同时，私有化部署的耗时控制在我们可控阶段的3天内。此外，我们的兄弟团队提供了SaaS服务的私有化交付，稍微不那么复杂。采用我们的解决方案后，月发货能力在半年内提升了3.6倍，从每月3套增加到每月14套。.七、下一步发展计划在解决了私有化部署过程中存在的问题后，接下来的重点工作是提高系统的自动化运维水平，降低系统的运维成本，逐步移交运维工作从厂家运维到客户的运维。维度团队。主要关注两个方面：运营平台，实现日常运维中的各种场景（包括但不限于日常巡检、故障排除、版本升级、计划执行、问题定位、配置变更、补丁升级）标准化文档转化入库进入运营平台，然后各种场景根据使用的频率和重要性逐步进行自动化和智能化升级，减少运维人员干预的频率。可视化，运维人员的主要工作已经从执行转变为监管，因此可视化将成为主要使用的工具。通过各种大屏，实时展示系统的运行状态、健康状况、核心指标、容量数据等关键信息，方便运维人员了解情况。
