交付系统要求

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

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

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

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

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

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

• 插件化，对于专有云产品的定制化功能，尽量由系统通过插件的形式来支持，避免直接修改相关代码导致后期的不可维护。以登录功能为例，目前所有的主流公有云，都支持多种登录方式，这样，在专有云模式下，多增加一种登录方式，其对系统整体的影响就非常小了。

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

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