从我们多年项目实践中，告诉您企业为什么要做IT运维管理转型？
业务发展往往驱动着IT运维管理的同步转型或升级，企业IT部门往往习惯于通过采购服务或管理工具满足要求。
但我们常常发现，在各类采购活动中，甲乙双方很容易陷入各自的思维定势，如乙方乐于强调产品工具的功能优势、市场竞争差异或性价比，而甲方用户实际更关心的是平台工具落地时背后所带来的各类成本与后续维护，当中存在着结构性偏差。
即使双方达成合作，充其量是购买了工具能力，而非完整意义上的解决方案，可能在运行一段时间后出现各种不适应，迫使再一次进入新的采购轮回。
本文结合近年来面向企业在IT运维管理转型或升级项目的成功经验，梳理当中关键的驱动因素，归纳规划与选型时关键考虑要点，以供大家参考。
IT运维管理升级驱动因素
经验源于实践，一线管理团队在日常工作中的关注点往往以小见大，反映出本质问题。我们与企业单位的IT运维管理团队交流时，常常听到各种疑虑，比如：
- 近来新上一套APP和小程序应用，部分服务跑在云上，每天可能有几万用户访问，现有的监控工具能管理起来吗？
- 新业务应用发布和变更非常频繁，每周都要耗费大量人力时间在上面，如何改善？
- 现在特别关注大数据分析，经常需要从不同业务系统中抽调数据进行统计，但不同系统取数方法各异，厂商定制接口成本很高，很不灵活，如何解决？
- 新采购一套运维平台，对原来的工具会不会冲突？原来的管理人员能不能很快上手，要不要再招人来管理？要求什么水平？
- 现在单位有很多业务由外包厂商管理，新运维平台怎样给他们用？分工界面如何？
- 如果业务属于多层级架构，每个层级都由独立团队管理，包括采购、建设和维护，他们使用情况无从得知，有什么方法可以自动收集上来，统一分析？
- 运维的人一天忙到晚，到底在做什么，系统出问题怎么定位排障这么慢，有没有方法可以快速看到问题所在？
- 单位有敏感甚至涉密业务，新采购的运维平台对现有系统有什么影响，是否满足安全部门要求，有没有专业安全评测证明？……
我们发现这些不只是技术问题，更多会涉及到诸如组织分工、流程管理、成本分析，甚至是制度规范等。看似杂乱无章，事实上一件事或决策的驱动往往存在复杂因素。仔细分析，上述问题可以归纳两大类：
满足对外的服务要求：
对外服务核心来自于业务，包括新业务系统上线及变更、大数据分析等，关注的是平台工具的能力，体现在敏捷迭代、用户体验、新技术兼容性等。
响应来自内部的管理需要：
对内管理则是围绕如何有效地整合各类IT活动要素，确保满足对外服务的效率和质量，要求在组织、制度、流程、工具和安全等各层面进行分析。
IT运维管理升级外在驱动因素
所有IT规划都来自业务的诉求，包括IT运维管理，脱离业务讨论运维管理需求并不现实。用户鲜少一开始明确自己的运维管理需求，需要持续分析其业务转型升级特点，评估对应所需的服务或能力，然后才能总结为具体的运维管理需求。
IT运维管理存在一定共性，但严格来讲只有在技术层面存在跨行业通用的可能，真正解决方案的落地，势必要紧紧围绕行业特点与发展趋势，深刻剖析，因地制宜，方得要领。
随着互联网+潮流发展，很多单位业务模式逐步从内转外，比如数字化政府、互联网+医疗。面向公众的互联网应用增多，应用系统向移动化、海量化、敏捷化转变，相较于传统业务，对可用性、敏捷性、用户体验都提出较高要求。以下是一些常见的新业务模式对IT运维管理影响和要求：
01 新业务模式对组织分工的要求
在新业务落地过程中，我们发现仅仅依靠传统技术管控方式已经无法满足管理要求。很多信息化部门或团队过往主要是人、事、资源协调的角色，业务由其他部门或外部厂商管理，实际上两者存在一定脱离，形成了以资源类型的横向分工管理模式，比如按网络、服务器系统、云与虚拟化、数据库等维度设立管理岗位。这种模式非常普遍，但其弊端在于，一旦业务出现问题，往往需要多方人员共同排查，难以定位，效率不高。
新业务模式所涉及的技术层次将更加复杂，比如前端放到云上、使用CDN引流、多种缓存或消息队列组件并存，导致应用调用链条加长、专业性更高，势必提高对专业人员垂直化管理业务的能力要求。比如用户访问，从CDN到反向代理、前端、缓存、中间层、数据库甚至到服务器与网络，若要确保用户体验流程，则要求实现端到端链路监控，并快速利用可视化手段表达，异常时及时知晓问题环节，加快排障效率。
它所需要的并非单纯技术手段升级，更多是组织分工与协作模式的适配与优化，需要设立垂直化、全栈式的应用维护角色。反映到运维管理平台上，也要求能够灵活适应组织管理模式的转变，比如按业务维度切割管理、运维工具开发与使用权限分离、细颗粒度授权等。
02 新技术架构对技术水平的要求
新业务系统很大可能引入新型技术架构，比如异构化平台、开源软件等，传统管理工具或人员经验在短时间内无法跟进，整体管理水平不能满足要求，短时间内拉齐并不现实。
所以运维管理平台需要与时俱进，在技术兼容性、开放性、性能容量等方面处于或接近业界前沿，能够驱动调度各类新工具软件，避免盲目选型东拼西凑，缺乏体系化。
同时，运维管理平台应该降低其使用复杂度，降低用户学习门槛，最大程度屏蔽底层技术，使之腾出更多精力专注在业务逻辑之上，相当于赋予管理员撬动复杂技术的杠杆，使之能够平滑过渡技术转型期。
03 快速迭代对自主调度编排能力的要求
新型互联网业务最大特点之一是快速迭代更新，如医疗机构发布的APP达到每周发版更新十几个功能的地步，每次上线都是大量重复性工作与等待，这对于过往的研发和运维团队都无法想象。他们迫切希望利用平台提升持续发布变更的能力，当研发部门发版时，平台可以自动化部署到生产环境，减少人工审核与执行工作量。
这背后本质是一种自主调度与编排的思维，它要求并非一个个固化的好工具，而是赋能团队新能力，一种可以屏蔽底层复杂技术或传统开发复杂性、并专注于将业务逻辑快速转化实现（比如WEB页面化配置）的自定义能力，从而可以应对因不同管理对象、不同动作、不同角色而衍生的无穷运维甚至运营管理场景。
04 业务综合分析对数据融通处理的要求
大数据分析成为热点，但其本质更多在于多维度数据综合分析，比如跨系统取数统计。很多企业单位一直都在做，只是进入互联网+、云计算、AI时代，此类业务需求不断升级放大，不少单位还专门成立数据治理部门团队，但面对不同系统，数据存储或调取标准不一，若按照过往方式，每套系统分别定制接口，势必成本较高且响应迟缓。
在长期实践中，我们逐步总结出需要构建一套规范化的数据融通底座，制定统一接口标准，降低接入和调取的成本，同时平台作为集散地加强接口调度的安全管控，比如鉴权与审核，才是长远之计。再进一步，平台还应该支持通用的数据分析能力，兼容不同类型数据或对象、提供主流算法模型以及便捷的展示框架。
IT运维管理升级内在驱动因素
为了确保对外服务输出持续稳定，完善的内部管理体系必不可少。运维管理的狭义理解，就是针对各类IT资源对象的运行保障，如：数据中心、云平台、虚拟化、系统、数据库、中间件、应用等，围绕其生命周期展开部署、操作、监控、分析等日常活动，最终满足业务或服务输出需求。
若从这点出发，市面上很多专业化、精细化的运维管理工具确实能很好的满足要求，可是再好用的工具，在企业单位实际落地时也会出现一些水土不服的现象，像是反映难用、和实际流程脱节等。
借鉴“运维圣经”——ITIL，运维管理同样是一个宽广领域课题，绝不仅限于工具平台，甚至说它只是最后的表达与载体环节。实际上，IT治理决策者还需要从人员组织、制度规范、流程管理以及技术支撑几个维度进行体系化规划，它必定是一套自上而下逐步延展的设计过程，如下图所示：
一套完善的运维管理体系，绝不是将某个工具软件机械化插到当前业务系统环境中即可实现，事实上它更多作为管理策略与方法的具体表达与载体，是把管理思路转化为具体执行过程的媒介，故而对运维管理平台提出了多层次要求。
01 需切合组织管理特点
每个企业单位都有独特的组织架构，尤其在一些政府单位，从国家到省级到地市，同一套业务牵涉到多层级架构管理，且在过往中早已形成分层自治模式，除了统一采购标准外，各层级单位可以自主把握系统设计、部署实施、人员组织、维护运营等，形成较大差异。即使同一层级单位中，也可能分为单位内部与外包厂商运管分离的状况。
面对这种人员角色众多、团队关系错综复杂，运维管理平台是否可以明确职责分工与边界？对现有组织架构产生什么影响？需要多大学习和管理成本，建设、维护、运营需要新增多少人员？对人员技术水平有什么要求？是否需要奖惩机制，引导用户更积极使用？……
这些实实在的落地问题，一方面是管理者的制度建设，另一方面反映到运维管理平台上，要求有足够可塑性与细致管理颗粒度，真正切合到组织管理特点。
02 需符合制度规范依据
在很多项目的前期可行性研究与初步设计阶段，用户单位与咨询设计团队需要联手制定贴近其生产环境的制度规范体系，根据该体系对运维管理具体方法、流程乃至平台工具形成指导依据作用，便于后续工作开展。
运维管理制度的制定，首先为流程制定提供细化依据，然后流程作为指导日常运维的主要手段，规范了具体技术操作手段与步骤。对于流程产生的执行记录，可以重新反馈到制度和流程中，核对确认IT日常运行是否遵循已建立的制度。如下图所示：
这对运维管理平台提出了很多无形的要求，它必定结合人员具体活动才能准确表达，往往间接体现在细节上。平台至少需要具备完善的执行记录与溯源分析能力，力求颗粒细、同时跨度广，为制度规范和流程执行提供审核依据与优化基础。
03 可以对流程进行质量审核
流程是IT日常工作中最重要的体现环节，是有效协调不同角色组织共同协作、具体化制度规范的手段。事实上很多成功案例中，流程管理工具相较于其他运维工具使用频率更高。对应地，流程的质量审核也成为了运维管理中关键组成部分。结合ITIL服务交付与服务支撑的理念，运维管理平台可以提供以下维度保障：
过程管理：
包括发布管理、变更管理、问题管理、事件管理、服务台、知识库，通过考核具体过程的关键指标，比如不同业务提单数、工单完成数、工单好差评率等，从侧面保障服务执行质量。
技术指标：
可以通过平台或具体业务的技术量化指标衡量，比如服务访问请求数、请求成功率、请求耗时、每分钟/秒交易数等。
业务指标：
可以通过更进一步的内容分析进行衡量，比如每次请求的用户信息、请求地址、返回内容等，严格而言这些也并非真正意义上的业务数据，充其量也是侧面反映其事务执行质量。
实际上这也是常见的过程管控思路，透过直接或间接的评审指标，运维管理平台有能力从多方面监测流程具体执行效果，进而提高整体服务管理质量与水平。
04 需灵活满足技术支撑需求
具体到技术支撑方面，不同企业单位定会存在个性化需求，传统运维管理平台工具往往针对性满足细分领域功能要求，但无法应对随着快速迭代业务带来的无穷场景需求。常见的几类场景有：
- 业务存在多级管控架构时，每层级自主管控程度高，上级单位往往无法有效采集下级单位数据。随着业务发展，数据集中难以实现。倘若各层级使用相同的运维管理“底座”，在其上运行各自业务及打造专属管理工具，则既便于实现数据共享，同时又保留各层级单位自主可控，实现了兼顾平衡。
- 很多运维管理工作都是背后默默进行，团队工作量巨大而不为人知，汇报效果也不理想，运维人员也常被誉为“背锅侠”。这对运维管理平台可视化能力提出了新要求，它应该能够快速以报表、大屏、门户等方式对工作结果进行表达。
- 各部门、单位、团队所使用的自有工具杂乱，无法一站式管理，但鉴于个性化也无法随意废弃，则要求运维管理平台能力很好兼容各类管理工具，形成集中化、体系化的管理模式，成为一个“总指挥协调”的角色。
- 不同部门、单位、团队在实际管理中，肯定对于管理工具或多或少的个性化调整，比如很多自动化脚本，要求运维管理平台可以提供丰富的开发环境与资源，允许用户按需快速开发专属的管理工具，实际减轻工作负担。
- 同时平台还要求易维护，不容易出问题，拥有完善的自身监控体系……
这些场景化需求将无穷无尽，运维管理平台此时作为管理的核心载体，必定要求具备丰富的能力，能够支撑用户体现个性化的适配性，在落地过程中与人员、制度、流程相互磨合渗透，最终达至动态良性互促的状态。
05 要满足安全管理要求
安全永远是贯穿企业单位IT管理的考虑因素。用户往往非常关心引入新平台系统是否符合单位安全要求，有没有第三方安全评测？是否符合现行的安全政策要求，比如国产化？平台传输和存储的安全防护手段是否达到业界水平？……这需要运维管理平台在传输与存储、鉴权与审核，乃至程序代码层面，都不同程度的满足安全要求。
IT运维管理平台如何选择
我们很清楚，没有最好的运维管理平台，但我们需要选择拥有足够可塑性与灵活性的平台，归结起来它应该具备以下特点：
对外服务：
同时面向传统稳态业务与新型敏捷业务模式，它应赋能IT服务团队：弹性而细颗粒的组织分工方法、业界领先技术管理水平与兼容能力、满足复杂场景的自主调度与编排能力、高效低成本的数据融通框架。
对内管理：
引入新的运维管理平台工具，实际上背后代表着一种新的管理思路与体系，它务必符合企业单位IT管理方针：切合组织管理特点、符合制度规范依据、具备流程质量审核能力、满足复杂多样的技术支撑以及安全管理要求。甚至在落地过程中反过来优化现有的制度与流程，形成一种相互促进的良性循环。
再进一步思考，任何管理思路与体系都并非凭空生成，它不可能因由某位天才技术人员灵光乍现而诞生，它必然经历过多年实战、洗礼、反思、优化而沉淀，是一方领域中的智慧结晶。
一套成熟的管理工具与体系，不可能只来自一个团队或企业，它背后很可能还隐含着多方共建力量，或是专业领域的合作伙伴和ISV，或者百家争鸣的技术社区论坛，或者引领行业标准的联盟协会，也可能是代表未来的产学研新生一代。
当企业单位在选择一套运维管理平台的时候，它绝不仅仅在选择工具本身，更多的是在选择一个生态圈子，或者说是一股多方共建、良性共生的生态力量。
总结
如今，IT运维管理今非昔比，不再是技术人员埋头苦干、被动救火的局面，已逐步升级演化为企业单位中一项关键的体系化建设工作。它将直接间接地影响着整个企业单位IT战略落地与业务发展方向，是摆在决策者与管理者面前的一个大挑战，也是一个新机遇。我们一方面要从自身实际出发，另一方面应该更多借助业界的成熟与领先力量，融入生态，携手共进，迈向共赢。
作者：曾嘉成
腾讯云开发者
