浅谈办公IT运维与运营的侧重点（it运维的工作特点）

IT运维和运营，即IT Operations，其中IT运维还隐含了IT maintenance（维护）的成分。运维和运营是IT的一体两面，是相互促进的关系。没有好的运维就谈不上运营，没有好的运营的话，运维也不可能持续性良性的发展。下面的导图是我整理的业内常见的对ITOM的理解，都有一定道理：

下面具体来看看怎么理解这张图。

（一）运维从被动维护到主动预警

活着意味着针对办公IT基础架构处于被动维护的形态，到处救火，被动去维持底层架构的可靠性和稳定性。从“活着”到“活得好”意味着IT在运维的稳定性、可靠性、安全性方面要有一个本质的跨越。唯有如此，才能给后续的IT运营带来一个稳固的基础。到具体操作层面：

其一：提高IT办公架构的稳定性、安全性、灵活性

从基础架构层面，涉及到全员都在使用的服务，需要去考虑消除架构的单点风险，并尽可能对核心服务做解耦。当然架构的进化是一个不断妥协、不断优化的过程，需要充分评估公司能够在办公IT上的投入有多少。根据不同的投入，会产生不同可用性级别的架构设计。举个例子：

访问层面可以考虑使用LVS、ngnix去做3-7层的负载，使用LVS做LDAP的负载，使用Ngnix做Exchange的访问负载；数据库层面可以考虑使用群集、复制等技术，使用Alwayson做MSSQL的高可用，使用DAG做Exchange的高可用。

从安全性方面，需要持续性的对基础架构进行安全加固、紧急补丁修复，制定完善的安全加固测试变更流程、核心业务紧急变更流程等。举个例子：

微软补丁更新可以考虑使用系统自带的WSUS服务，去做补丁的自动化测试、审批和安装；遇到重大漏洞需要修复，可发起紧急变更流程，通过邮件、IM的方式知会关联方，调用紧急预案后再进行操作，尽可能将影响面降低到最小。

从灵活性方面，对外提供服务的业务尽可能不要直接暴露出来，应该API化，通过服务网关的形式对外赋能，做到所有业务调用有鉴权、有日志记录。举个例子：

可以基于Django Airflow构建自动化运维平台，将IT的服务API化，提供公共服务网关，将内部的API接口挂到网关上，原则上需要对外的服务，必须经过服务网关，至于内部服务，则只允许内部互相调用，不允许对外发布。比如以前业务要集成LDAP，只能是直接绑定AD的服务器IP，而有了网关，则直接可以访问LDAP服务的API地址，获取目录信息。

其二：制定比较完善的SLA标准

简单来说，从IT运维侧更关注的是可靠性，所以需要制定可靠性指标，具体是99.9还是99；从IT运营侧更关注的是满意度，所以需要制定满意度的考核指标，具体满意度能达到的百分比是多少，是90、80还是其他。SLA的制定主要考虑如下几个方面：SLA协议、SLO目标、SLI指标、服务日历、业务范围（服务目录）等。

首先来了解一下基础概念：

那具体如何计算SLO呢？一个是看可用率；一个是看可用性。公式如下：

• 可用率=（AST-DT）/AST*100。AST（agreed service time）是指约定的服务时间即上面提到的服务日历，DT（Actual downtime during agreed servicetime）在约定服务时间内的停机时间。

• 可用性计算公式，是 MTBF/(MTBF MTTR)， 其值越高，代表可用性越高。系统的可用性程度两个指标，一个指标是 MTBF，表示平均故障间隔时间，MTBF 越高说明出现故障的次数越少；另一个指标是 MTTR，表示平均恢复时间，MTTR 越小说明故障恢复时间越短，系统受影响时长越短。

SLA的核心考量因素是什么？简单来说，包括如下几点：

• 核心服务列表
• 服务周期、服务不可用条件的界定
• 计算公式
• 可用性承诺：几个九
• 免责条款
• 补偿规则
• 责任人

SLI的核心考量因素又是什么？简单来说，主要是制定监控指标，比如延时、ping连续性、探针、API连通性、服务状态等。

有了SLA协议、SLO和SLI之后，我们还需要完善自己的服务响应体系，简单说，就是发生故障了，如何去应急，如何去处理。具体需要考虑的点包括：服务响应时间（2分钟、15分钟、2小时、4小时、8小时等）、服务响应级别（P1、P2、P3、P4）、服务响应流程（普通事件流程、重大事件流程）、服务保障条款（5*8还是7*24、是否提供备件、现场还是远程）等。

其三：支撑SLA目标实现的监控日志体系

有了方法论、有了规范和流程，还需要有对应的工具去落地执行。对于微软服务，可以考虑微软自有的SCOM监控和Power BI可视化服务；对于跨平台的服务（既有微软、又有开源组件），可以考虑使用Zabbix做监控、Grafana做可视化大屏、ELK做日志平台。这里需要特别说明的是，如果是用Zabbix监控微软的应用服务，比如Exchange，可能要结合脚本去做探测。微软自家SCOM的优势是有各种MP包，可以做应用的深度监控，劣势是针对开源平台组件的监控比较弱。

从建立办公IT监控日志体系的角度，我们需要考虑如下几个因素（不是全部，罗列了一部分比较重要的）：

• 基础监控
• 日志监控
• 服务监控
• 应用监控
• 性能监控
• 监控大屏
• SLA视图
• 日志收集
• 日志分析
• 监控告警分级等

有了比较完善的监控体系，再结合SLA的约束，就可以让办公IT运维质量发生根本性的变化，真正实现从被动维护到主动预警。

（二）基于ITIL建立适配的ITOM体系

ITIL目前已经更新到了v4版本，从传统办公IT的角度来看，ITIL主要关注四个方面，即：人、流程、信息和工具（技术）。其中：

• 人侧重于生产力提升和相互连接；
• 流程侧重于自动化、标准化、简单高效；
• 信息侧重于安全、标准及合规；
• 工具（技术）强调自动化、可集成、角色细分。

从数字化办公IT的角度看，在传统IT的基础上，需要额外关注IT资源的云化管理和敏捷项目管理及开发。其中：

• 云化管理方面，需要构建跨云管理的、支持多租户特性、支持权限细分、支持数据合规隔离、支持对接信息化流程、支持服务网关、支持任务工单、支持日志记录、支持报表可视化、支持任务工作流的办公IT自动化云平台。具体涉及的技术栈可能包括：前端（VUE或其他框架）、后端（Django框架）、异步（celery）、工作流（airflow）、脚本执行器（PowerShell、Shell）等。

敏捷项目管理和开发方面，需要进一步在标准项目管理的基础上，制定项目的分级管理制度，针对不同体量和规模的办公IT项目，灵活应对，快速应对，快速上线和迭代。开发迭代需要更敏捷，比如功能迭代考虑使用Jira；持续集成、部署和交付考虑使用Git CI/CD流水线；业务的上线考虑尽可能容器化，通过启docker的方式或使用公司的K8S集群来快速部署、回滚。

（三）从主动运维到主动运营

主动运维做好了，就需要开始以经营的心态来做办公IT的主动运营了。与主动运维不同，主动运营关注的维度更多的是业务数据的可视化呈现、服务的满意度提升，本质上是面向人。我们需要换个角度来思考：

• 老板侧（信息化领导、兄弟部门领导、中台领导）

1. 希望看到的IT运营数据是什么，经营数据是什么？

2. 看这些数据的目的是分析人效比、投资回报率还是做成本分摊？

3. 这些数据折射出什么问题和痛点，如何去指导接下来的IT运营规划工作？

分析这些问题，首先是做业务需求分析、制定成本收入核算规则及模板。不要出现办公IT的不同资源，核算维度不一致、规则不统一，导致最终数据汇总分析困难，无法有效呈现。其次需要有工具支撑，在运维可视化的基础上，基于IT自动化云平台做运营数据的汇总分析，能让老板清晰看到每个部分使用办公IT服务的数量和成本，使用率的变化趋势，人员的变动趋势等。这里面涉及到的资源包括：运营报表的设计和开发、后端数据的收集、汇总和整理等。

• 用户侧（个人用户和业务用户）

这里的用户是一个笼统的说法，个人用户包括公司的员工以及外部服务的个体客户对象（比如关联实体、独立实体等）；业务用户包括公司的各个使用办公IT服务的业务部门（比如使用到了IT的SMTP发信服务，LDAP认证服务等）。

首先个人用户关注的更多是办公体验，是不是用起来简单、效率高，是不是切实提高了用户的生产力，这些直接的感受和实际的使用情况决定了用户对办公IT的服务满意度。来自用户的反馈信息，也能够帮助IT持续提升服务水平和质量。具体落地来看，需要思考：

1. 服务入口是不是简单统一，用户是不是可以通过一个固定渠道来获取IT的多样化服务（电话、现场、邮件、IM等）？

2. 有没有对应的服务流程，比如紧急服务支持流程，VIP支持流程，设备申请和退回流程，会议申请流程？

3. 有没有分级的响应机制和团队，比如从服务台到1.5线再到2线、3线工程师的层级？

对于服务入口来说，一般会在企业内网门户放置IT服务主页，将所有IT可提供的服务目录统一放到一个地方；对于服务形式的多样化来说，需要有工单系统做支撑，从而支持通过电话、邮件、IM等多种渠道联系到IT；对于服务流程来说，可以考虑有专门的VIP支持小组，紧急case应急预案，特殊用户考虑服务到工位等；对于团队的设置来说，从服务台、1.5线到2线，再到厂商这种4级支持模式就可以了；对于和员工密切相关的入离职流程来说，由于涉及到多个部门，多个审批环节，可以考虑设置线上及线下的共享服务大厅，为用户提供一站式的服务支持。以上措施和手段，其实就是一个人员、信息、流程和技术（工具）的有机结合；对于员工自助服务来说，可以设置自助服务终端机，也可以将IT的自助服务门户和移动端的协同办公APP做集成，用户通过移动端APP的统一工作台界面，获取到IT的自助服务，比如邮箱扩容、密码重置、资源申请等。

其次看业务用户，说白了就是办公IT的服务除了做内部用户服务的支撑，让用户爽，还要做内部和外部业务的赋能，让业务也爽。通过IT自动化运维云平台作为连接器，所有对外提供的服务都可以访问公共平台获取（OpenAPI），统一业务申请的入口，任务工单化，所有的交互操作均合规，有审计记录。办公IT对外经常提供给业务使用的服务包括：LDAP认证、SMTP邮件、监控、日志平台、多租户云管平台、SSC或者BPM相关的IT业务流程自动执行接口等。业务满意主要看可靠性，也就是业务在使用办公IT服务的时候，能够达到几个九的可靠性。一般对外开放的服务，至少要达到99.9的水平，如果是实时性要求比较高的服务，可能需要达到至少99.95，比如核心业务电话外呼的报警推送。

以上虽然聊了很多，但本质上涉及的IT运营内容还在一个比较初级的阶段，也可以说是从信息化往数字化过渡的阶段，如果这个阶段的运营和运维都做的比较到位了，那么后期其实可以考虑基于大数据、AI技术，持续做场景化运营，把办公IT运营往精细化、个性化方向去带。

最后，我们也不能忽视两个矛盾：

• 企业办公IT需求的快速增长和成本投入不足的矛盾
• 企业业务的快速变化和办公IT建设项目周期长的矛盾

这两个矛盾的解决方式，在上文中也能窥见一二，根据不同企业场景的实际变化，仁者见仁，智者见智吧。