今年，中证协下发了《证券公司网络和信息安全三年提升计划》 征求意见稿 （详见 https://www.doc88.com/p-40959715591002.html ） ，提出33项重点工作 ，与运维直接相关的有6项工作。这6 项工作要求与我对行业运维重点工作十分相似，可以看出是身处一线运维工作专家编写而成，值得细细品读。本篇是对第1项的“加强系统上下线管理”作的个人解读。

1、 系统上下线保障工作分析

变更管理通常会划分为重要变更、一般变更、简易变更等类型，其中新系统、重要模块/组件上下线、重大业务逻辑变更、重大基础设施变更归属于重要变更。指导意见中将新系统上线与下线从变更管理中单独提出来，加以强调，突显对这两个环节的重视程度。

新系统上线是从0到1的过程，具体的工作通常包括：上线准备工作、制定技术方案、评估测试管控、上线文档准备、风险评估、安全保障措施、运维监控准备、上线过程协同、上线发布、系统验收、上线试运行等。

新系统上线给企业带来机会与挑战。一方面，作为项目重要里程碑，新系统将为企业业务发展或运营管理助力，通常业务需求方会投入大量精力在上线后的运营推广工作，以期望更好地给业务及客户带来价值；另一方面，新系统上线带来众多的不确定性因素，需要对不确性因素进行管理，不确定性包括：新业务流程的合规性、数据安全、隐私安全等问题；新业务对现有上下游系统在业务及性能层面的影响；新系统在设计上是否满足业务活动的性能、容量要求；配套的稳定性相关的监控、日志、应急、数据备份等非功能性需求是否就绪；功能已知缺陷的影响是否评估；发布上线、环境部署、下线方案是否就绪；对系统业务运行情况的观测能力等。

对于运维组织，通过聚焦上线阶段，做好运维工作左移，提前做好资源交付能力建设提高系统上线速度，利用运维平台能力建设帮助业务研发专注业务逻辑，提前参与到架构及非功能性需求的研发与验收，能够让系统上线后融入平台化管理模式。

相应的，系统下线需要评估对存量业务开展、系统运行、数据安全等影响，以及围绕成本上资源释放的管理，通常的退出工作包括：

• 业务影响分析、业务通知等管理，比如提前做好相关业务运营、客户解释等工作准备。
• 系统下线的操作风险控制，比如作好新旧系统的状态切换、防控数据污染、数据不一致等。
• 系统的业务、程序、配置等数据备份。
• 下线过程的操作留痕。
• 系统数据、环境清理、CMDB配置更新、工作交接等。

指导意见中，围绕系统上下线的风险，我归纳为4点提升：系统业务的风险评估、可运维性的准入评估、上线后的专项运行保障、下线技术保障方案。下面从这四点做个简要梳理。

2、 系统业务风险的评估

指导意见的描述是 “ 组织对重要信息系统上线的业务流程合规性、权限设置清晰度、对其它业务的影响、测试遗留问题对系统上线后的影响等方面进行全面评估。 ”
指导意见首先强调了业务风险，即基于业务流程产生的影响，从新系统自身的业务风险与对存量业务流程的影响。在加强风险评估工作上，可以考虑加强：

• 新系统业务带来的风险防范、监管合规、数据安全、隐私安全等问题；
• 新系统业务流程可用性、终端体验、数据准确性等风险；
• 新系统业务对现有上下游系统在容量、性能方面的影响，以及上下游配合改造对原有业务带来的影响；
• 新系统资源、架构、重要功能是否满足业务期望，以及接下来业务活动的性能、容量要求；
• 系统压力测试、容量评估方案、功能遗留缺陷等是否评估到位等；

针对上述业务风险的评估工作，运维可能考虑推动以下工作：

• 标准化先行，建立业务与技术层面的合规、风险、隐私、安全等方面的管理要求，并辅助相关技术检测手段。
• 业务系统非功能性需求的建设，比如系统回退、版本切换、灰度发布、终端体验感知等配套功能的实现。
• 业务系统技术运营需求的建设，比如对首笔业务感知、业务流水监测、关联系统的技术运营监测等。
• 系统性能与容量管理，包括相关评估指标、基线容量设计、指标数据加工、容量评估分析报告、压力测试等工具建设。
• 相关线上化管理，比如测试遗留BUG清单、相关技术文档的线上化管理等。

3、 可运维性的准备评估

指导意见的描述是“ 对重要信息系统的备份能力要求、信息安全防护措施、测试报告、验收报告、风险评估报告、应急预案、系统运维非功能需求以及上线方案等运维方面进行全面评估 。 ”

运维工作关键主线是为了应对运行风险，新系统上线的可运维性评估重点是为了更好地应对技术风险、业务风险、设计风险、数据风险、安全风险，从事前防范，事后快速止损的思路推动可运维性工作。可运维性的评估工作可以考虑如下：

（1） 稳定性架构设计评估

系统的稳定性架构可以考虑从高可用、故障恢复、数据完整性、部署环境角度推进工作。

高可用是运维管理的一条底线保障要求，运维主要工作是消灭单点风险，提升系统韧性，比如数据库中提到的主备、主从、分布式，数据中心的两地三中心、分布式多活，以及将一个应用系统同一个服务组件部署在多个数据中心机房、不同物理机的多个虚拟机上、为应用的负载均衡提供网络硬件或软件负载均衡器等。为了更好地推进评估工作，运维需要主动建立相关架构高可用的规范与可应用的参考模式。

故障恢复可借鉴最佳实践、具体信息系统的特点等，制定相应的故障恢复能力要求，比如应用拆分、服务或系统交互解耦、服务无状态、减少总线节点服务依赖、增加异步访问机制、多层次的缓存、数据库优化、限流与削峰机制、基础设计快速扩容等。

数据完整性是运维保障的底线要求，持久化数据的生命周期通常会比系统与硬件的生命周期长很多，很多新系统上线或架构调整都考虑数据迁移工作。同时，还要关注一些复杂性数据处理，比如：批次、清算、对账等操作，这些操作极易受数据问题影响，运维侧需要关注数据处理的异常中断原因定位、哪些环节是可以应急中断、中断后是否支持多次重试、与第三方系统约定数据不一致时以哪方为基准等等应急处置机制。

选择合适的技术和部署方式是系统可运维性的关键，需要选择性能稳定、易于维护的技术，并根据业务需求选择合适的部署方式，如云计算、容器化等。

（2） 非功能性需求的评估

运维的非功能性设计是主动应对可运维性问题的切入点，直接决定系统在生产环境的成本与收益，甚至决定系统生命周期的长短。以下罗列运维侧需要推动的非功能设计。

• 系统运行状况可观测。云原生提出可观测的监控指标、日志、链路三要素同样适用于传统以主机为代表的技术架构。运维是在一个黑盒子的成品上进行监控、日志、链路完善，像NPM、APM、BPM等是运维侧发起的一些解决方案。从非功能设计看可观测，需要运维前移，推动必要的监控、日志、链路相关的研发规范，提升主动上报监控性能指标数据的能力，优化日志的可读性，并提供必要的基础设施服务支持，比如支持系统监控数据上报、日志采集分析等。
• 故障隔离与服务降级 。故障隔离和服务降级的目的是以牺牲部分业务功能或者牺牲部分客户业务为代价，保障更关键的业务或客户群体服务质量，是防止连锁性故障蔓延的方法。在设计中，运维侧需要从系统或业务角度，梳理应用系统所调用的各个服务组件，对各个服务组件出现故障时的假设，及应对措施。
• 终端版本向下兼容 。移动化后终端版本的管理越来越重要，在架构上一方面需要尽量保证升级后的版本要向下兼容正在流通的低版本的可用性；另一方面要对流通的版本进行收敛管理，支持多种在线更新机制。
• 基于基础平台运行 。无论是基础设施平台，还是PaaS层的应用平台，或持续交付工具链，系统均需要尽量与公司现有基础平台对接，避免引入新的技术栈。
• 性能冗余设计 。系统设计时要考虑最高并发的情况，并在此基础上增加性能支持的能力，防范业务量突增带来的性能影响，相比业务连续性，资源成本的控制应排后。
• 可配置而非硬编码 。在应急时，发现有些“参数”硬编码在程序中，无法快速调整，需要推动配置管理。另外，IP的DNS域名改造也是可配置的一个方向，减少人工在后台修改。

（3） 运维保障准备工作评估

• 监控和告警。建立完善的监控覆盖面，包括基础设施、平台软件、数据库、中间件、操作系统、性能等技术指标监控，与特定系统相关的业务功能、客户体验指标监控，以及与系统上线后重要业务功能首笔出现的监控。
• 日志规范化 。日志分析是认识应用系统的关键手段，可关注以下几点：一是“存储”，因为行业或企业内部有保存日志数据的要求，需要一个成本可控、可横向扩容、支持海量日志数据的管理平台；二是“查询”，日志是感知线上系统运行状况，了解代码级问题的一个窗口，在出现业务问题、故障应急等场景下，可以利用日志查询问题，需要建立实时的数据采集、高效的日志检索能力；三是“监控”，基于日志分析关键字、正则检索、模式匹配等方式，能够提供监控能力； 四是“分析”，对日志的非结构数据进行加工处理，生成非结构化数据，进行运行数据分析，实现异常发现、故障定位、性能分析、容量评估等分析工作。
• 故障恢复和处理 ：系统出现故障时，需要能够快速恢复并进行处理，包括：技术与业务应急预案、应用系统架构韧性相关功能交付、新系统上线多团队集结保障支持、系统关闭方案、关联系统回滚、应急变更发布方式等。
• 文档和知识库 ：根据组织软件交付的协同机制，明确新系统上线的文档交付清单，比如：项目与需求、技术架构图、测试结论（含压力测试）、安装部署（与环境相关）、应用/业务监控、首笔功能监控及保障、重要功能清单、重要配置与参数、运行效能评估等文档。

4、 上线后的专项运行评估与保障

指导意见的描述是 “ 在系统上线时密切关注业务运行情况，做好业务保障工作。 ”

新系统运行评估是指在新系统上线后，安排一个重点保障阶段，组织不同角色的团队进行专项运行评估与保障，确保新系统满足设计要求并具备投入商业运行的能力。

在组织形式上，如果系统可进行功能、流量、用户等控制，可以考虑建立一周或一个月的试运行，在试运行评估达标后才转为正式上线，如果系统无法控制，则考虑建立一周的特别保障工作。在此阶段，需要根据保障方式内容，召集业务、产品、项目、研发、测试、运维等角色，做好分工进行全面的运营管理工作，并按日、周、月发布运行评估情况。

在评估与保障方案上，此阶段的重点保障业务可用、数据完整性、性能指标、安全性、可靠性、稳定性等维度的稳定性，进行主动的技术运营保障。不同维度涉及的保障方案需要提前召集专家商讨制定，以业务可用为例，需要产品、研发、测试、运维参与，明确有哪些重要业务功能、如何主动监控首笔业务发生、如何监控重要业务的交易量与交易成功率、业务日志报错情况、批处理任务状态等关注点，并提前将关注点转化为技术指标，实现在线业务监控或业务运行看板等。

5、 下线技术保障方案

指导意见的描述是 “ 运用技术手段开展重要信息系统下线的技术和业务影响评估，制定完整的系统停用和数据迁移保管方案，并组织评审及进行系统停用后的安全检查 。”

系统下线通常包括整体下线与部分模块下线，下线前不仅要明确系统承载业务与风险评估，还要明确下线对上下游关联系统的影响。以下是常见的注意事项：

• 影响分析：提前分析系统重要功能运营情况、下线后业务是否有替代系统、如何保证用户业务开展、涉及哪些上下游系统，下游系统是否涉及改造等。
• 事先通知：需要提前通知业务人员、上下游系统负责人、用户等关联方，提前做解释工作，以便提前做好工作准备，应对系统下线。
• 系统维护：提前做好系统状态、流量控制，明确是否设置系统维护状态，做好操作风险控制、新旧系统的状态切换、防控数据污染与数据不一致等问题，以免在下线过程中出现意外情况
• 数据备份：制定数据、程序、配置等备份方案，并进行数据备份，以免数据丢失或损坏。
• 用户验证：在系统下线前，安排技术与业务人员进行必要的验证，确认下线方案正确性。
• 留痕跟踪：对相关信息进行记录，对操作过程进行登记留痕，以便后续的审核和跟踪。
• 资源释放：完成备份后，需要进行系统环境清理工作，释放硬件资源、软件许可与资源。
• 交接工作：在系统下线前，需要进行必要的交接工作，以确保工作的顺利进行。

总的来说，新系统 从0到1，伴随着风险与挑战。运维组织 需要从组织、流程、平台、场景角度打造一个完整的系统上下线协同工作机制，评估各种风险，制定相关技术方案，主动应对突发风险，确保系统业务安全稳定，并避免对存量业务系统产生影响。同时，运维组织还要以系统上下线作为事件驱动的切入点，推动可运维性的相关工作的落地。