2.1.1 人员

1.运维能力要求

运维是什么？不同的人对运维有不同的认识和见解。先来看看百度百科对运维的解释：企业IT部门采用相关的方法、手段、技术、制度、流程和文档等，对IT软硬件运行环境、IT业务系统和IT运维人员进行的综合管理。可以看出，运维是一个综合性非常强的岗位，不仅需要掌握大量的运维技术与知识，还需要管理、创新等能力。对于刚进企业从事运维工作不久的人来说，对运维的认识往往较为片面，仅限于一些简单操作性工作的理解，比如应用系统出现故障时快速恢复服务、应用上线前编写变更脚本、对数据库进行性能优化等。

运维从狭义上可以理解为“运维技术与资源”，主要包含“监、管、控”，是支撑运营的质量、效率、成本的核心。以下是运维的一些能力要求。

1）运维规范的制定与执行：以TOGAF、COBIT、ITIL、ITSS、SRE、ISO2000、DevOps、敏捷、运维一体化、研运一体化等方法论为基础，结合行业监管或标准，制定内部运维管理规范，约束运维人员的操作行为。

2）监管政策要求的落实：企业需要理解、快速响应、落地监管机构的管理要求。

3）运维基本保障：运维日常工作中会有类似环境配置、监控策略配置、应用发布作业编排、资源扩容、故障处理与问题排查等保障业务稳定运行的环节。

4）运维对象的使用：运维工作人员需要熟悉IT对象的基础运维，如网络、服务器、操作系统、数据库、中间件、JVM、容器、应用等的基本使用与调优。

5）运维服务能力：在ITIL的理念指导下，运维开始面向客户、业务侧等人员以服务的形式提供其价值，并且以服务级别协议（SLA）保障服务的质量，着重服务台、业务咨询、维护、知识库等支持能力的建设。

6）业务连续性管理：基于业务连续性目标，制订业务可用性计划、应急计划、基础架构及应用系统的高可用方案、容灾架构方案、备件冗余资源计划等。

7）安全运维能力：通过对运维所有操作进行审计留痕、系统及软件漏洞的修复、网络攻击识别的预防以及数据的防泄漏等方面的工作保障信息安全。

8）故障管理能力：建设完善的事件管理流程与问题管理流程，如对事件分类进行定义、问题的排查与定位等。

9）持续交付能力：为适应敏态业务发展需求，需要快速提供基础资源、一键应用发布工具等。

10）主动优化能力：运维不但需要提供被动保障的服务，还需要辅助业务开发团队设计应用运行架构以及进行性能优化，提升客户体验等。

11）应急演练：为保障业务连续性，需要针对重大系统故障提供应急恢复能力，并根据应用等级设计其高可用架构，通过应急演练不断提升突发事件响应速度、方案完备性以及人员熟练程度等。

12）业务支撑：根据业务团队实际需求及安全合规审计，为其提供数据维护、数据提取、参数维护等服务。

13）运行分析能力：通过运维数据分析帮助业务团队制订容量计划，提升应用整体性能以及可用性水平。

14）运营能力：运维需要有辅助业务运营的能力，基于运维视角发现业务痛点并共同制定解决方案，持续提升客户及业务体验等。

15）成本控制：运维成本的投入与控制，如针对人力、硬件、带宽、软件等资源成本的评估，以及资源优化和精细化管理。

16）运维开发：运维工具体系的规划与建设，运维开发能力的培养。

不同的企业需要运维的能力有不同的扩展，甚至同一企业在不同的发展阶段，由于企业战略与业务需求的变化，对运维的核心能力要求也会变化。

2.运维组织建设

随着业务规模的不断发展，企业对运维人员的要求越来越高，运维组织与岗位的划分越来越细。在传统企业中，常见的运维团队设计如下。

1）机房运维团队：负责机房和总控中心场所公共环境设施的运维管理，负责各类生产设备硬件系统的建设和运维，负责基础环境设备及系统硬件设备的维修配件、耗品的需求管理。

❑规范制定：负责建立机房环境、硬件系统运维管理流程和工作机制，组织落实相关的风险防范管理措施和技术方案，保障机房环境及硬件系统可用性、可靠性和可维护性。

❑机房规划：负责机房环境规划建设，制定相关的管理原则、方案和实施流程；负责机房容量规划、选址扩容等。

❑环境管理：负责机房基础环境系统等各类硬件设备及系统的建立、运维和管理；负责协调、配合相关部门执行机房总控中心场所的水、冷、风、电等公共环境设施的安装、运维和管理，确保相关设施的安全稳定运行。

❑设备维护：负责实施机房各类计算机设备、基础环境设备及系统各类硬件设备的扩容升级、微码升级、老化更新、故障修复、维修配件及耗品需求管理，保障机房硬件设备和环境设备的性能与容量满足信息系统安全生产要求。

❑机房安全：负责机房环境日常管理，主要包括机房环境及机房设备的监控、巡检和日常维护，配合机房门禁管理部门对进入机房的人员进行授权审核和通行管理，确保机房环境安全。

❑综合布线：负责机房综合布线系统、加密机、加速器及除网络环境外负载均衡器硬件的安装调试和日常运维。

2）网络运维团队：负责网络通信建设总体规划，负责数据中心各类平台系统环境网络接入和技术支持，负责网络管理系统建设及性能优化，负责网络系统安全防护，保障网络运营安全。

❑规范制定：负责建立企业IT网络通信系统运维管理流程和工作机制，组织落实网络通信系统风险防范管理措施和技术方案，保证企业网络通信系统的可用性、可靠性和可维护性。

❑网络规划：按照网络建设的总体架构方案，组织实施企业骨干网、企业边界接入网络、企业局域网络、企业存储网络等网络通信系统建设。

❑网络配置：负责企业各类基础网络设备、网络安全设备、网络管理工具以及网络通信线路等的实施、运维和管理。

❑网络监控：负责定制网络监控系统一体化软件版本，组织企业网络升级和运维管理，负责企业工厂网络软硬件的部署、运维和管理。

❑运行维护：负责企业IT网络通信的需求受理、技术咨询和技术支持，负责网络设备扩容升级、老化更新以及网络通信线路开通、关闭等需求并组织实施。

3）服务台团队：负责24小时全球运维值班人员的管理，组织实施生产事件的应急处置；负责服务台管理，统一受理和处理客户服务请求和故障报修；负责总控中心场所及监控系统的配置、实时监控和日常运营管理。

❑值班排班：负责建立生产系统24小时现场运维管理机制和工作流程，统筹安排各专业条线、各岗位角色的24小时运维值班人员和排班计划。

❑集中监控：负责各类生产环境和系统的24小时集中实时监控，包括机房环境、网络通信、硬件设备、系统平台、中间件、数据库、应用软件等层面的运行状态。

❑服务受理：统一受理企业内部用户服务请求和生产事件报送，提供生产监控事件、服务台受理的服务请求及问题的一线技术支持，保证生产事件和服务请求的及时有效处理。

❑事件跟踪：负责事件管理，对监控事件、服务台报送事件实施闭环管理，保证各类事件得到及时、高效、有序处理。

❑应急响应：负责生产系统紧急事件的应急响应、组织排查和恢复，负责汇总和报告事件信息等工作。

4）系统运维团队：负责资产管理，服务器选型、交付和维修，操作系统运维、漏洞补丁、故障修复等。

❑资产管理：记录和管理运维相关的基础物理信息，包括数据中心、机房机柜、网络、服务器、IP地址等各种资源信息，制定有效的管理流程，确保信息的准确性，开放接口供运维管理工具使用。

❑服务器选型、交付和维修：负责服务器选型与测试，包含服务器安装部署、部件的基础性测试、业务兼容性测试，降低整机功率，提升机架部署密度等。

❑操作系统运维：负责操作系统的选型、定制和内核优化，以及补丁的更新和版本基线制定与发布；跟进日常各类操作系统相关故障；针对不同的业务类型，提供定向的优化支持。

5）数据库运维团队：负责数据存储方案设计、数据库表结构设计、索引设计和SQL优化，对数据库进行变更、监控、备份、架构设计等工作。

❑设计评审：在产品研发初始阶段，参与设计方案评审，从DBA的角度提出数据存储方案、库表设计方案、SQL开发标准、索引设计方案等，使服务满足数据库使用的高可用、高性能要求。

❑容量规划：掌握所负责服务的数据库的容量上限，清楚地了解当前瓶颈点，当服务还未到达容量上限时，及时进行优化、分拆或扩容。

❑数据备份与灾备：制定数据备份与灾备策略，定期完成数据恢复性测试，保证数据备份的可用性和完整性。

❑数据库监控：完善数据库存活和性能监控，及时了解数据库运行状态及故障。

❑数据库安全：建设数据库账号体系，严格控制账号权限与开放范围，降低误操作和数据泄露的风险；加强离线备份数据的管理，降低数据泄露的风险。

❑数据库高可用和性能优化：对数据库单点风险和故障设计相应的切换方案，降低故障对数据库服务的影响；不断对数据库整体性能进行优化，包括新存储方案引进、硬件优化、文件系统优化、数据库优化、SQL优化等，在保证成本不增加或者少量增加的情况下，数据库可以支撑更多的业务请求。

6）应用运维团队：负责线上服务的变更、服务状态监控、服务容灾和数据备份等工作，对服务进行例行排查、故障应急处理等。

❑设计评审：在产品研发阶段，参与产品设计评审，从运维的角度提出评审意见，使服务满足运维准入的高可用要求。

❑服务管理：负责制订线上业务升级变更及回滚方案，并进行变更实施。掌握所负责的服务及服务间关联关系、服务依赖的各种资源。能够发现服务上的缺陷，及时通报并推进解决。

❑资源管理：对各服务的服务器资产进行管理，梳理服务器资源状况、数据中心分布情况、网络专线及带宽情况，能够合理使用服务器资源，根据不同服务的需求分配不同配置的服务器，确保服务器资源的充分利用。

❑例行排查：制定服务例行排查点，并不断完善。根据制定的服务排查点，对服务进行定期检查。对排查过程中发现的问题，及时进行追查，排除可能存在的隐患。

❑预案管理：确定服务所需的各项监控、系统指标的阈值或临界点，以及出现该情况后的处理预案；建立和更新服务预案文档，并根据日常故障情况不断补充完善，提高预案完备性；制定和评审各类预案，周期性进行预案演练，确保预案的可执行性。

❑数据备份：制定数据备份策略，按规范进行数据备份工作；保证数据备份的可用性完整性，定期开展数据恢复性测试。

7）运维安全团队：负责网络、系统和业务等方面的安全加固工作，进行常规的安全扫描、渗透测试以及安全事件应急处理，进行安全工具和系统研发。

❑安全制度建立：根据公司内部的具体流程，制定切实可行且行之有效的安全制度。

❑安全培训：定期向员工提供具有针对性的安全培训和考核，在全公司内建立安全负责人制度。

❑风险评估：通过黑白盒测试和检查机制，定期生成对物理网络、服务器、业务应用、用户数据等方面的总体风险评估结果。

❑安全建设：根据风险评估结果，加固最薄弱的环节，包括设计安全防线、部署安全设备、及时更新补丁、防御病毒、源代码自动扫描和业务产品安全咨询等。为了降低可能泄露数据的价值，使用加密、匿名化、混淆数据，乃至定期删除等技术手段和流程。

❑安全合规：承担安全合规的对外接口工作。

❑应急响应：建立安全报警系统，通过安全中心收集第三方发现的安全问题，组织各部门对已经发现的安全问题进行修复、影响面评估、事后安全原因追查。

8）运维管理团队：负责信息系统生产变更的集中管理和排期，负责组织实施应用系统投产前可用性测试、新项目及新功能上线、版本升级和系统下线，负责运营管理体系的持续改进。

❑规范制定：负责建立信息系统生产变更管理规范、流程和工作机制，组织落实信息系统变更管理风险防范的管理措施，组织实施生产变更的集中管理，负责变更的评估、审批、公示和后评价，确保生产变更的安全性和有效性。

❑生产调度：负责统一组织和协调企业信息化相关的各项生产活动，包括应用项目投产、系统升级、系统下线、生产维护性活动、灾备切换演练及应急演练、特殊日安排等，进行生产环境（含生产、准生产、投产演练和灾备环境）、技术资源、时间窗口等各项生产资源的调度和排期，制订总体工作计划并控制执行，确保生产任务合规、有序执行。

❑投产控制：负责组织实施应用系统投产前的可用性测试，负责应用系统上线及版本升级和系统下线的投产管理，组织和协调投产版本准入控制、投产环境准备、投产前演练等投产准备工作，组织完成投产相关工作。

❑资源协调：负责生产活动的对外沟通协调和组织调度。

建立运维组织架构非常重要的一个原则就是“专业层级原则”，即根据运维能力的分类与分级，建立不同专业职能和层级的管理团队、技术团队和服务团队。例如，银行业的综合管理部门的生产调度团队、应用运维团队、服务台团队等。

3.运维组织转型

运维组织的转型离不开运维组织架构和体系的变化，康威定律在某种程度上也可以用来指导运维组织架构设计。

❑第一定律：组织沟通方式会通过系统设计表达出来。

❑第二定律：时间再多，一件事情也不可能做得完美，但总有时间做完一件事情。

❑第三定律：线型系统和线型组织架构间有潜在的异质同态特性。

❑第四定律：大的系统组织总是比小系统更倾向于分解。

下面先来看看运维技术架构的变化。

1）基于传统建设方法。通过一个运维管理门户，将众多运维系统或工具封装到这个运维管理门户中，通过统一身份认证，工具间的URL跳转来实现一体化运维的表象，但底层的数据无法打通，相应共性组件也无法复用。这只能治标不能治本。

2）基于平台化建设方法。把通用的运维能力构建在平台内部，形成各个原子能力模块，再通过SOA的架构进行封装，将运维所需的场景功能和平台的原子能力模块进行隔离。这样做的好处在于避免了烟囱式的建设方法，让运维的数据和功能得到有效的治理。

这两种运维技术架构或许可以给我们一些启示。

1）组织沟通方式会通过系统设计表达出来。第一种运维技术架构建设是一种离散式的运维组织沟通方式，每个纵向领域技术组自己进行技术选型，这样的组织方式就是传统的方式，公司有不同的运维组，如网络、操作系统、数据库、办公应用、业务应用等，但是每个组相对独立，这种模式在当前的内外部运维环境下就会遇到问题。

2）企业的运维场景往往需要跨系统、跨流程、跨组织，天然具备个性化、全流程化的特点，这也是当前对运维组织的要求。

3）没有完美，只有更好。组织的转型无法一次解决，但是与运营技术架构匹配的组织将带来更大的效能。

转型的目标离不开运维的价值呈现，运维需要从运维支撑提升到增值服务，也就是除了稳定，还要考虑能否通过自动化和标准化释放运维人员。从PaaS化运营技术架构的变化趋势来看，如果把运维组织当成技术架构来看的话，应该有一个“运维发动机式的组织”，对外输出运维解决方案，这个组织在PaaS化的技术运营体系下称为技术运营组，如图2-2所示。

利用输出解决方案和工具的方式，提升现有人员日常的运维工作效率，例如把日常巡检、提数、配置管理等运维操作自动化、标准化，且标准化要体现在简便的Web交互界面功能上。这样运维人员就能得到一定程度的解放，他们就可以作为运维组的“甲方”，去仔细思考自己的运维如何更稳定、更高效、更可控。

定义好统一的工具开发或场景构建的标准，并构建起流程式的赋能机制，运维逐步转向运维开发。不断提升公司一体化运营平台的能力，从烟囱式系统建设转变为平台化建设，只有这样，才能实现更为高效的数据化运营和智能运营。

采用自生长式的运营模式，授人以鱼不如授人以渔，技术运营组的人员可以为一线运维人员开发工具，或让一线运维人员利用研运一体化平台为自己制造工具，从而不断提升运维人员的水平，同时实现简单工作的自动化和重复工作的标准化。