应用运维新兵的晋级之路

导语 

随着银行对金融科技要求不断提高，各种变革和职能调整成为必然，科技运营管理的应用运维工作也不例外，新同事的加入和老员工的轮岗成为一种常态，这使得应用管理员常常需要面对应用系统的交接与调整工作。不管是新入职员工还是老应用管理员，在接管一个新系统之初，他就是一名应用运维新兵，如何安全顺利接管一个应用系统，不妨从以下几个关键方面逐步展开。

一、夯实底座：从基础技术能力起步

俗话说“万丈高楼平地起”，对于应用管理而言，扎实的技术基础就是稳固的地基。应用管理员需着重培养核心技能，全力夯实技术底座。在操作系统方面需要掌握各类常用的命令，要具备初步Shell、Python编程能力，能够熟练编写数据库SQL语句和识别高风险SQL语句，能初步掌握常用数据库的基础操作，此外还需掌握应用管理工作中常用的各类运维工具平台。这些基础技能是深入探索应用系统的“钥匙”，只有熟练掌握，才能在后续工作中游刃有余。

二、熟悉业务：从业务场景理解系统

正所谓“知其然，更要知其所以然”，业务学习是熟悉应用系统的首要任务，是深入了解熟悉一个系统的根本所在。如果不了解业务，就如同盲人摸象，根本无法知晓系统的真正用途。在接手应用系统之前，必须从业务视角出发，全面了解业务规则和流程。要弄清楚系统承载的具体业务内容、提供的功能模块以及服务的用户群体。作为应用管理员，必须牢记“技术服务于业务”这一核心理念，业务是根基，技术是手段，只有清晰把握业务需求，才能充分发挥技术优势，更好地为业务发展保驾护航；对业务需求不恰当的理解或实现，很可能在后续系统运营中埋下重大隐患，充分理解业务流程和规则、熟悉业务需求才能在一定程度上防范这类风险。要熟悉业务可以从阅读系统主管业务部门发布的管理办法、操作规程、营销计划方案等方面入手，在这个过程中，重点掌握业务术语、理解业务规则、熟悉关键业务流程，逐步构建起对业务的清晰认知。

三、全面梳理：构建”两图、一表、两预案“运维知识图谱

在完成业务学习后，接下来就要对应用系统进行全面梳理，在前任管理员交接的文档上，自己动手实践，构建充分理解后的“两图（系统内逻辑架构图、系统间上下文游关系图）、一表（系统数据库表）、两预案（技术应急预案和业务应急预案）”的运维知识体系图谱。

上下游关系图.png

首先，要重点梳理系统内部逻辑架构图，明确系统包含哪些子模块，每个模块的具体功能和作用，关键业务流程是如何实现的，以及模块之间的调用关系。在这个过程中，需要运用模块化思维，结合之前所学的业务知识进行理解，避免陷入细节的泥沼，做到抓大放小。其次，要理清系统间依赖关系，明确数据流如何通过联机交易、批量交易、文件传输、中间件等方式在上下游系统间传递，从而了解具体业务场景在多系统间的功能实现。

同时，还需对系统的数据架构进行梳理，形成数据资产表，内容包括数据库实例、表结构和表数据。详细记录数据库的部署方案、应用连接方式，以及数据库中各个表的用途、表中字段的含义。

在两图、一表的梳理阶段，通过对交易请求链路分段分层式的拆解，梳理请求经历了哪些系统、模块和设备，进而发掘架构目前的风险点、瓶颈点后，就可以分析用什么样的手段来将风险各个击破，形成相应的技术预案。在此基础上，结合业务场景，通过加入降级、熔断等方式，形成业技联动的业务预案。

在系统全面梳理过程中，不可避免会遇到各种历史遗留问题。此时，可遵循 “二八原则”，优先处理重要且关键的部分，再逐步攻克细节；同时遵循“白名单原则”，先将确定健康的资源标注整理出来，把剩余的零散问题记录在案，形成一个“账本”。后续根据问题的紧急程度和自身工作量，合理安排时间逐一解决，切记不要急于求成，也无需过度焦虑，每解决一个问题，就是向全面掌握系统迈进了一步。

四、动态分析：深入理清系统运行脉络

完成系统全面梳理后，接下来就要深入了解系统的运行状态，从服务调用关系入手，对系统的运行态进行全面且深入的分析。分析服务调用需从具体交易出发，细致观察交易请求的流转过程，主要包含三个层面：一是不同应用系统间交互所依赖的联机、文件或中间件等形式；二是系统内业务模块逻辑之间的流转顺序；三是在基础资源层面，交易如何串联服务器、vip和域名等资源。在分析过程中，可借助现有的系统运维手册、投产评审材料、需求开发文档、变更实施控制表等资料，仔细甄别、核对，确保对系统运行脉络的准确把握。

五、风险管控：构建防御性运维体系

应用管理员的核心工作之一，就是关注系统何时可能出现问题，以及出现问题后如何迅速解决。在对应用系统的稳定状态有了清晰了解后，就需要将目光转向系统的异常状态。

首先要重视告警管理。告警是对监控信息的高度浓缩，虽然监控体系的梳理可以循序渐进，但告警管理必须尽快落实到位。告警存在不同的级别，应优先梳理出影响业务正常运行的关键告警。与交接同事充分沟通，明确每个模块必须处理的告警项及其影响范围，做好详细记录，并在日常工作中留意业务告警，逐步形成“错题本”和应急预案，以便在出现问题时能够迅速响应。

其次要严格管控变更。一是应用变更管控需要在技术和制度并行发力：许多生产环境中的问题在开发、测试阶段难以暴露，且部分问题不会立即显现。因此，针对变更必须建立一套系统的评估和验证机制。从技术和制度两个维度发力，能够通过技术手段解决的问题，优先采用技术方案，对于技术暂时无法解决的，再通过制度进行约束，最大程度降低变更带来的风险。二是应用变更左移：应用管理员不仅要参与系统的架构评审、设计评审和测试评审，还应该有选择性的参与到业务需求评审当中。在业务需求评审阶段，应用管理员重点关注业务需求规则可能对安全运营存在的隐患，需求投产时间安排的合理性等；在架构评审阶段需要重点关注系统架构设计的韧性，使用的技术和组件是否符合企业标准规范；在设计评审阶段重点关注高可用设计、熔断降级限流策略以及性能容量评估等；在测试阶段重点关注非功能测试场景和指标，功能测试覆盖的全面性：边界测试、业务场景、反案例测试等。

结语  

总之，应用运维工作是一个“认知-实践-迭代”的往复循环过程，只有通过持续系统化的知识沉淀、工具链搭建、流程优化，逐步构建起“业务+技术+流程”的多维能力模型，从被动救急响应到主动积极预防，实现从一名应用运维新兵到老兵的蜕变，最终打赢安全运营这场没有硝烟的保卫战。

王广雨.jpg

负责G行核心系统应用运维工作。应用运维人员的核心竞争力更多的在于运维方法论的总结，寻到规律，事半功倍。希望能与各位前辈共同探讨应用运维能力提升方法。