随着运营商技术升级、业务发展，以及服务能力要求提升，当下新建项目的交付或系统大版本升级大多数都需要历经千辛万苦才达到上线的彼岸。然而，项目上线并不意味着项目结束，“上线”也并不意味着终点，而是一个新的管理模式的开端。

如何尽可能地降低真实业务加载上线后，出现的各种各样问题呢？我们可以从事前防范，事后预案两方面来总结。其中在项目交付过程中主要工作除了系统建设之外，还有大量的验证、测试以及检查工作，其重要性不言而喻，关于事前防范本文不作细表。本文重点总结下运维策略在事后预案中的团队、制度、流程、工具、监控等方面的实战应用。

首先，我们看下新建项目在上线初期经常会出现的五类生产故障。造成这些故障的原因通常都是没有做好相关的运维支撑预案。

其次，我们来看看上线项目将面临哪些困难与挑战呢？在管理方面，如果缺乏有力的管理和监督、有效问题处理机制、合理的制度约束，将严重影响系统上线后的效果。在操作执行层面，项目上线初期，能够快速熟悉并能定位问题的使用人员和维护人员并不多，缺乏对新系统的了解、熟悉度低，需要接受新的业务思想，熟悉系统流程，这让使用和管理人员短时间难以消化和应用，这也是系统上线后的一个阻力。

防患于未然，防重于治，在预防之余，上线后不可能没有困难或阻力，但是在预防工作做扎实后，出现这些问题是可控的，也是新项目的正常问题，解决难度也会降低。我们可以通过五个动作来解决上线运维问题和阻力。

五个动作

动作一：组建运维团队

项目上线模式可以分为两类：

第一类：先试点再推广模式

这种模式的特点是：在试点阶段通常会爆发出很多在上线前测试阶段未发现的问题或者忽略的问题；在推广阶段运维范围从试点变成全省多个地市。当前各项目采用的较多的上线模式。

第二类：全省一次集中割接上线模式

这种模式的特点是：不采用试点，全省集中割接上线模式。具备割接准入条件需要对系统的性能、割接时长、测试场景覆盖率、测试场景通过率、运维团队的组织等方面都提出了严格的标准。

在组建运维团队时，需要根据不同上线模式、上线策略、项目组人员结构、人员能力等进行综合评估。

• 试点上线阶段，最佳的运维团队组建方式：人员按业务、按模块进行分组负责。运维人员配置主要包括：需求、数据、测试和维护人员。通过试点阶段问题的解决，快速提高运维人员解决问题的综合能力。
• 推广上线阶段，最高效的运维团队组建方式：人员按地市进行分组负责。其中每一组负责支撑多个地市的运维工作。此阶段运维人员配置需要在试点人员配置基础上增加相关业务、模块研发进场，快速收敛问题，保障系统度过重保期。
• 全省集中割接上线模式，一步到位，项目管理者提前做好割接期间各项割接工作安排、割接后系统及业务的重保支撑预案；加强日常培训的力度；对运维人员提出可量化的学习目标并且通过每次的割接演练持续提高解决问题的能力等。对于运维团队的组建方式和人员配置可参考“推广上线阶段”。

动作二：制度先行保障

无规矩不成方圆，好的制度一定是建立在提高工作效率，规范标准动作的基础之上。在项目上线前后阶段，通常需要制定的制度包括：版本发布机制、版本测试机制、问题反馈机制和问题沟通机制等，本文重点谈下问题反馈机制和沟通机制。

问题反馈机制：入口统一，使用问题管理工具

在项目上线前两周，首先就要明确上线后问题处理机制。对于问题管理有两种维度：按照分公司维度管理、按照系统功能维度来管理。按照分公司维度管理有利于客户进行问题记录，但对运维支撑带来一定的问题整理工作量；按照系统功能维度管理有利于运维支撑快速进行问题的分析，但对于客户的问题记录有一定的要求。在项目实战中，我们更推荐使用按照系统功能维度来进行问题管理。

接下来就是对问题进行管理，通常各项目组都会采用表格进行管理，表格管理的最大弊端是对于问题维护的工作量较大；问题处理流程经常会形成断点；内外部问题通常多个表格进行维护，每天维护表格的工作量就非常大，而且经过较长时间后的数据积累，表格已经显得臃肿不堪。再此推荐高效的方法，通过问题管理工具化进行管理。我们使用较多的是BSS的问题敏捷管理工具，在此不作为重点说明哈。

最后就是建立问题首问责任制。运维负责人作为首问责任人每天牵头对问题组织进行分类、重点分析和解决。根据问题梳理出每日TOP问题关键点，提交研发及时进行修复，避免问题扩散。原则上在重保期间卡点、阻塞性问题当日必须解决，降低风险。

问题沟通机制：主要分对内和对外问题沟通两种

上线后对内、对外问题沟通主要通过运维负责人牵头和发起进行。

对内问题沟通，重点根据问题分类（缺陷或需求）、问题优先级，每天定时组织需求、研发、数据等相关负责人进行问题分析和确认解决时间。

对外问题沟通需要进行分层，对于客户管理层主要通过日例会、周例会方式进行汇报，重点体现在问题的整体收敛进度和后续的解决计划、人员保障方面内容。对于一线人员沟通主要通过QQ群、企业微信群等及时通讯工具，重点体现在对个体问题或群中的消息及时进行响应以及问题处理进行确认等。

动作三：问题处理控制

问题处理流程主要包括五个关键的环节：问题提出、问题响应、问题转派、问题处理、问题关闭。我们发现很多项目虽然上线成功，但是上线效果不好，追其根本原因之一发现问题并未进行闭环管理，导致上线效果未尽人意，很可惜。并且，上线之初是问题集中爆发的阶段，留给项目组解决问题通常也就一周左右 黄金时间段。通过有效的版本管理和升级流程、问题管理流程来应对集中爆发问题的版本发布及管理，避免出现版本的混乱。问题处理可以采取下面4小步： 

动作四：工具辅助

查理·芒格说“如果你的工具只有一把锤子，你会认为任何问题都是钉子。”因此，在系统上线初期需要构建项目多维度、多元化的工具，工具箱箱中的工具越多越好，可以在项目管理、版本管理、测试管理、运维管理、系统安全等方面起到很大的帮助。

动作五：监控保障

有效且合理的监控能为项目组在上线运维过程带来极大的帮助，特别是有效且合理的自动化监控，极大的减轻了运维人员的工作量。在这里连续强调了两次“有效且合理”，那什么是有效且合理的监控？

监控要全面

监控系统运行环境的健康度，网络的健康度，各功能模块的进程运行的健康度，业务指标的健康度等。通过对SaaS、PaaS、IaaS 层的自动化监控，向我们及时提供系统健康情况。SaaS层重点监控网络、设备使用率等指标；PaaS重点监控容器CPU、内存使用率，文件系统使用率等指标；IaaS 层重点监控业务进程存活情况、业务指标波动情况等。

监控成体系化

从系统各功能模块或者业务逻辑线条的各关键点进行自动化监控点的设置，监控点的内容中需要体现“面-线-点 ”信息，通过由点到线，由线到面的自动化监控，可以捕获到哪个系统的哪个功能模块的哪个点有问题，为我们快速定位问题节省了很多的排查时间。例如：业务监控方面，需要细化监控点，从产品业务粒度、资源配置原子服务粒度、存量资源可用率拆分颗粒度，进行“点”的监控；各产品业务场景涉及的业务工单情况、原子服务配置情况、资源可用率等串起来形成“线”的监控，所有产品业务场景涉及的情况汇总后就形成资源配置“面”的监控。通过一系列有联系的监控点，可以推导出当前系统健康情况，异常点在什么地方，对后续分析定位起到指引作用。

监控多维度化

多维度可以精确定位问题点，通过对环境容器内存、CPU使用率，对内部环境-网关-对端网关进行网络互通监控，对进程存活监控、业务工单或访问量波动情况监控，进行多个维度设置监控点。例如，我们的进程监控点和该进程对应功能影响的业务监控点，是互相有关联的，这两个维度的监控，指向的是同一功能当两个监控点同时出现波动时，那系统功能大概率出现问题了。

监控多途径化

多途径，很好理解，既要有短信监控、也要有企业微信或钉钉等监控，这样避免其中一种监控途径本身出现问题时，我们无法及时获知监控信息。

写在结尾

项目上线后，运维管理的本质是项目组尽最大的努力通过事前准备、事后预案来保障系统稳定，守住上线取得的来之不易的成果。对于项目交付的生命周期，从项目启动之初的需求管理工作开始，在经过版本研发管理、数据配置管理、接口研发管理、数据迁移管理、测试管理、割接管理阶段后来到了最后一个环节，也就是本文谈到的上线运维管理，其中每个环节执行的质量和进度都是相互依赖、相互影响、相辅相成。

本文最后用纳瓦尔宝典中的一段话作为结尾：“你的脑海中是不是会偶尔出现一首歌曲的旋律，它总是挥之不去？这就是记忆痕迹。其实所有思想的形成莫不是痕迹效应的结果。”希望本篇中的观点、方法如同痕迹效应，能带给参与到项目交付的同学一点帮助、启发或参考。