咱们是如何将 ToB 服务的交付能力优化 75%？

ToB 服务交付的方式分为公有云部署和私有化部署两种。其中，对成本敏感的中小企业每每采用公有云部署的方式，从而尽可能减小成本。客单价较高的大型企业、政府、银行和事业单位，考虑到数据隐私、安全、合规等要求，每每采用私有化部署的方式。基于对公司营收的巨大贡献，私有化部署便成为了 ToB 企业的重中之重。

在众多私有化部署的场景中，较为复杂的是公有云厂商的专有云产品，之因此复杂，是由于这些厂商直接将公有云的核心功能打包进行私有化部署，和垂直类解决方案每每提供单一功能相比，其难度可想而知。京东云的 JDStack正是采用了此模式。

存在的问题：部署耗时和成本

私有化部署的耗时，通常须要两周左右的时间，给人感受耗时太长了。但从耗时角度去看的话，一个大单从开始到最终结项，历时半年到一年是很正常的，这样看，两周的部署耗时占比不到 10%，并不是项目交付耗时的主要矛盾点。

但若是两周部署耗时的背后，是从研发团队抽调了几十名高级工程师加班加点，夜以继日换来的，可能你们都没法淡定了。假设一次大型央企的异地私有化交付项目，部署耗时 20 天，期间现场累计参与人数超过 60 人，现场峰值人数超过 30 人，30% 的人员是高级工程师，相关人员频繁往返于两地间，粗略估算一下成本，至少 50 万，这样的模式，只能是在起步阶段交点学费吸收点教训。

在部署耗时的优化上，还须要考虑客户所在行业的特殊性，尤为是关系国计民生的领域，互联网的快速迭代，越变越美并不必定适用。咱们能够建议在入场前将咱们须要的资源准备完毕，但也只能是建议。对于在现场部署过程当中，诸如各类审批流程和要求，甲方工做人员天天的工做时长，基于安全因素对数据传输和拷贝的限制等等，都会影响最终的部署耗时。

所以，相比于部署耗时的优化，对部署成本的控制更现实一些。若是部署工做是由外包来进行的，且过程当中不须要公有云厂商的技术支持，那么只要部署耗时控制在客户可接受的范围便可，厂商也会所以具有大规模批量实施的能力。

存在的问题：质量缺陷

什么叫作质量缺陷呢？简单来讲，在你完成一套专有云产品的私有化部署以后，最严重的状况，可能这套系统彻底没法使用，大部分时候，都会有一小部分功能没法使用。

质量缺陷的影响是什么？最糟糕的情形莫过于你成功的将你的客户转化成你的测试团队，从你部署的系统中，源源不断的反馈各类问题，进而逐渐失去了客户对你的信任。

既然是在公有云验证过的产品，为何私有化部署还会出现这么多的功能不可用（或者称之为质量缺陷）？我以为有以下两点：

复杂度：从厂商角度看，公有云产品由数百个模块构成，对外提供几十种功能，涉及到从网络，硬件，操做系统，程序，配置，上下游依赖关系，数据等方方面面，这样一个在公有云厂商中每每是多个部门上千人耗费数年打造的产品，如今让刚成立的交付团队来搞定一个由上千人参与的复杂系统，其难度可想而知，仅仅是可以熟练使用公有云产品提供的这几十种功能，就须要花费很长时间，更况且还要面对数百个模块，数百种配置文件，数百个模块间的复杂依赖，不一样的开发语言，几乎涵盖了业界全部主流的开源软件等，以及为了一个小功能牵一发而动全身的痛苦。

兼容性：从客户角度看，不一样行业不一样客户，真可谓是千人千面。基础设施的供应商不一样，组网协议不一样，硬件的品牌型号规格不一样，操做系统和内核版本不一样，登陆和认证方式不一样，等保要求不一样，资源提供方式不一样，还有各类极小众的东西，好比很是生僻的数据库，十几年前的软件，小众的编程语言等等。专有云产品为了兼容这些差别，必然须要临时开发一些定制化功能，这也成了质量缺陷的重灾区。

存在的问题：可运维性

为何在公有云环境下你们反馈良好的产品，在私有化部署中被如此吐槽，主要是由于在公有云场景下，问题被化整为零了。

举例来讲，各个产品作的都很不错，每一个产品平均仅存在一个部署的小问题，这对于一个研发了数十个模块，拥有百十人规模的团队来讲，已是不错的成绩了。但一样的问题，放在私有化环境下，就很差玩了，五十个产品，每一个产品部署的时候都有一个小问题，而交付团队人员少，对系统的掌握程度也不如研发团队，你让他怎么办？

某云提供的运维手册，多达 2100 页，80MB 的体积，我都不知道本身上次看这种大部头书是何时了。固然，文档也是交付的必要内容之一，从这个角度来讲，某云在国内作的仍是很好的。

如何解决存在的问题呢？

经过下降部署环节的技术难度，实现一键部署的能力，将交付工做交给外包团队，从而具有大规模批量交付的能力。整个的过程大体以下：

• 第一步，对部署流程进行原子化拆分；
• 第二步，对每个原子化的部署步骤进行标准化改造，例如以统一的全局错误码进行异常输出，便于查找解决方案；
• 第三步，对每个部署步骤均进行屡次的部署可靠性验证和回滚验证，确保每个原子的部署操做具有较高的成功率，同时回滚后不会有任何影响二次部署的残留物；
• 第四步，为每个原子操做提供功能测试能力，确保仅在该操做正确无误后，才会进入下一个操做环节；
• 第五步，梳理各个原子操做间的串并行关系和依赖关系，从而生成部署时序图，进而基于部署时序图打造出一键部署能力。

这里须要注意的是，一键部署并不等于全自动化部署，在至关长的时间，可能也没法作到 100% 的全自动化部署，不少环节尤为是前置依赖仍是须要客户配合的。

业内众多厂商也在提一体机的概念，一体机的解决方案确实更好，理想状况下，把一批机器放到客户的机房，加电并设置网络就可使用了，并且公有云厂商的硬件成本更有优点，客户也能看到 " 实物”，只是在当下，主要是在企业客户中使用。

值得注意的关键点

部署流程图，是整个解决方案中最重要的环节，没有之一。相似于工程施工图，将总体工程从无到有的全部过程、环节、工艺标准、施工要求、依赖和注意事项，进行完整的说明。部署流程图决不能止步于模块部署的内容，而是要涵盖从网络的实施、硬件的上架、操做系统的安装到部署服务的全部环节，这样才能保证一键部署的成功率。找一个彻底空白的环境，不断的从零重建，相信你们均可以梳理出完善的部署流程图。在这里再次提醒你们，要覆盖全部环节，尤为是那些你从未接触的部分，以我为例，在交换机参数配置上就吃过好几回亏。

功能验证，以客户的定制化需求为例说明，研发开发完毕自测经过，测试也经过了，运维验证经过后打包发版，交付发现功能上有缺陷，这时候，研发可能就愤怒了，有问题，怎么不早说！所以，功能验证是须要整合产品、研发、测试、运维、安全、法务、合规、交付和客户各类角色对功能验收的要求，便于及早发现问题，减小返工的成本。具体来讲，在每一个原子操做执行完毕后，对涉及到的功能、接口、页面进行充分的验证，在每一个阶段完成后，也要对该阶段的组合功能进行验证。同时，对于相关模块的实例数量，实例规格，依赖，健康状态，配置正确性，错误日志以及性能指标等进行检查，以及相关的配置是否真正生效。多管齐下，确保可以准确判断每一个原子操做执行的正确性以及在异常状况下尽量给出异常缘由。

一致性维护，经过 Puppet 等配置管理工具来确保服务器配置的一致性，如 NTP、DNS、YUM、信任关系、日志统一收集、工具列表和版本以及系统参数，避免手工维护缺失和遗漏致使的质量缺陷问题。例如在部署阶段，NTP 时钟不一样步致使的趋势图没法展现实时数据，进而耗费了很是大的人力来进行问题定位。

检查清单，主要是对标准规范、统一配置、最佳实践，易错问题且会致使严重后果的问题再次确认，避免后期的大规模返工或者故障。例如，配置变动后须要重启服务器才能真正生效的策略，不只要检查其配置是否生效，还须要在相关步骤执行完毕后，确保检查服务器的运行时间；经过 Systemd 拉起的服务，要检查其设置了开机自动启动；系统安装后，要确保全部磁盘均为 XFS 格式且所有写入系统配置中；全部用户定制化内容，所有须要再次检查是否生效，如不一样用户要求的超卖比。

虚拟化和启动自检，将模块实现虚拟化部署，从而可以和硬件、组网协议、IP 地址等用户资源解耦，实现镜像在多套环境下的固化，从而大幅提高模块部署的成功率。短期内没法实现虚拟化部署的模块，则必须实现启动自检功能，在物理机或者虚拟机环境下启动前，须要检查环境是否知足本身的要求，例如 JAVA 是否可用，版本是否符合要求，Swap 是否关闭等。

全局标准化，以服务启停方式为例，所有收敛为 Systemd 方式拉起服务，用户仅须要知道进程名就能够实现任意服务的启停操做，日志切分则所有由程序自行实现，不经过外部的 crontab 来进行，这样既下降了复杂度，也大幅提高了可运维性。

插件化，对于专有云产品的定制化功能，尽可能由系统经过插件的形式来支持，避免直接修改相关代码致使后期的不可维护。以登陆功能为例，目前全部的主流公有云，都支持多种登陆方式，这样，在专有云模式下，多增长一种登陆方式，其对系统总体的影响就很是小了。

最终效果

经过一键交付总体解决方案的落地，私有化部署的成功率大幅提高，咱们目前已经能够确保交付后全部核心功能都可正常使用。同时，私有化部署的耗时，在咱们可控的阶段，控制在 3 天内。

另外，咱们的兄弟团队，提供 SaaS 化服务的私有化交付，复杂度略低一些，在采用咱们的方案，半年间每个月交付能力提高了 3.6 倍，从每个月 3 套提高到每个月 14 套。

咱们是如何将 ToB 服务的交付能力优化 75%？

下一步发展计划

在解决私有化部署过程当中的问题后，接下来的重点工做是提高系统的自动化运维水平，下降系统的运维成本，逐步将运维工做从厂商交接给客户的运维团队。主要在两个方面发力：

操做平台，将平常运维工做中的各种场景（包括但不限于平常巡检，故障处理，版本升级、预案执行、问题定位、配置变动、补丁升级），进行标准化的文档改造并录入到操做平台，而后按照使用频率和重要性逐步将各种场景进行自动化和智能化的升级，减小运维人员须要介入的频次。

可视化，运维人员的主要工做从执行变为监督，所以可视化会变为主要的使用工具。经过各种大屏，将系统的运行状态、健康度、核心指标、容量数据等关键信息进行实时展现，便于运维人员了解状况。

若是您想了解更多关于JDStack 专有云，欢迎点击“连接”阅读。

欢迎点击“京东云”了解更多精彩内容