系统上线，逐渐交接到内部团队的手里面；

知识转移，各种技术交付物都要消化学习。

为用户答疑，解决技术问题，

将异常处理，收集优化建议；

System Admin的日常，日日夜夜似瞎忙。

直到有一天，偶然看到ITIL宝典，

参照其理念，梳理系统运维实践。

ITIL 是信息技术服务管理中方方面面的最佳实践库，同时也有相应的认证考试。它是之前我们聊过的ServiceNow等ITMS系统背后的理论基础。

参考ITIL中的概念，我将HR系统管理员的工作理解为：将四类系统运行中的反馈（事故、监控事件、服务请求和改进建议）进行全面地收集，科学地处理，最终有序地产出为两类输出（系统变更和知识库）。

今天聊的HR系统，特指SuccessFactors这样的云端HR软件套件。如果是自开发的HR系统，或者部署在本地服务起的HR系统，公司内部的IT和HR团队要管的事可能还要多得多。

事故（Incident）管理

“事故”这个词听起来有点严重，而“生产事故”这个词一出直接让人怂。实际上，事故不一定是系统down机了、服务中断了，也可能是服务受到影响了，服务质量下降了。

回想一下我们在sap.support.com给SAP开Ticket报问题叫什么？就叫Report an Incident。

在公司内部，事故往往是由用户上报给管理员的，例如用户向管理员反映自己提的休假申请找错了审批人，或者自己的剩余年假天数算错了。

出现事故并不奇怪，上线前测试的场景再充分，也做不到业务场景的100%全覆盖，更何况还有新的业务不断到来。再加上用户超乎想象五花八门的炫酷误操作，造成的事故让管理员气急败坏。

关键是对事故要有及时的响应和正确的处理。

作为系统管理员，要让事故的负面影响降低到最低，尽快让服务恢复正常。

要将所有的事故都记录下来，并要能分析事故对业务的影响（business impact）：业务有多紧急、影响多少人，是完全挂掉了还是只是用着不方便等等。

对于HR系统来说，影响最大的有：影响全公司人按时发薪的事故、可能造成敏感数据泄露的事故、导致用户完全登不上系统事故等。

业务影响的判断标准，应该预先定义好。业务影响不同，事故处理的优先级也不同，预期的解决时间标准（resolution time）也就不同。

这些都需要和上报事故的用户沟通好，毕竟事故处理的体验是很影响用户对系统服务满意度的。

有时事故需要跨团队处理，那么事故的症状（Symptoms）、对业务的影响、已完成的行动、计划执行的行动都应被一一记录。对于紧急、复杂的事故，用户也应该获悉处理的进展。每次进展、事故状态变化时间都应该被记录。上一篇我们在介绍SLA时提到过，这些数据是评估服务质量的依据，解决事故的时长应该符合SLA的约定。

上一篇介绍的Service Desk系统，可以用来上报事故、记录更新、追踪状态变化。对于规模不大的公司，只有一个系统管理员的，及时沟通+Excel记录也能处理好，Excel中可以简化成只记录事故的提交时间和关闭时间。

监控（Monitoring）管理

如果说事故主要是由用户上报的问题，监控则是为了让管理员主动、预先地发现问题。

监控中的发现，被称为事件（Event），按严重程度被分为信息、警告、异常。

SAP SuccessFactors在2018Q2新增了检查工具Check Tool，此后的版本更新中还数次增加检查项目，管理员能够进行一些配置和数据的检查。

我们可以制作一些监控报表，定时发送给管理员，检查数据质量和审批流运转情况等，管理员从这些报表反应的异常中可以提前发现问题或潜在问题。

还可以设置一些Business Rule，提醒管理员有异常。

案例：我们在审批流的判断规则中设置，满足IF条件1则走Workflow1，满足IF条件2则走Workflow2，而当所有条件都不满足，则被认为是异常，进入ELSE条件，审批流向管理员。这样管理员可以及时了解有异常情况发生，同时防止了走错审批流或者根本没有审批的情况发生。

监控的关键，就是要尽可能做到自动化。

问题(Problem)管理

HR系统的管理员收到用户上报的事故，或者发现了监控的异常，要做根本原因分析（Root Cause Analysis），找出造成他们的原因，也就是ITIL中所谓的问题（Problem）。

Problem是因，一个或多个Incident是果。

HR系统管理员不仅要定位出问题，还要提出短期的应急措施（Workaround）和长期的解决方案（Long-term resolution）或预防措施。

案例：有个员工的休假申请没能匹配到正确的审批流，管理员发现了这个incident。立即采取了应急措施1，手动把该流程的审批人改成了正确的。

为了找到导致事故的问题，他联系了用户询问了他的操作方式，查看了用户的相关数据，并在测试系统重现出了这个问题。通过查看Buiness Rule Log，找到了根本原因：他汇报关系数据调整后，出现了审批流判断规则中没考虑到的情况。

为了评估这个问题的业务影响，管理员首先跑了流程报表确定同样的事故暂时没出现在别的流程，又跑了汇报关系报表发现全公司有6%可能出现同样的事故，而他们人均每周提交休假流程不到1条，影响的范围可控。

初步评估，要根本解决这个问题，要在判断规则中增加6个条件。这个规则已经很复杂，影响所有员工，修改风险高，要测试和回归测试的场景多，不可能很快执行配置变更。

于是一边执行了应急措施2，定时报表监控可能出问题的员工有没有提新流程。同时告知这些员工，先别着急提；一边加班加点在测试系统调整规则、逐一场景验证，之后走紧急变更，长期地解决了这个问题。

运维实践中，我将系统问题大致分为几类，按出现的数量排列分别是配置类、数据类、权限类、产品类、其他类。

比较复杂地配置类和权限类问题，可能需要实施商地顾问协助处理；而产品类地问题，只能报给系统厂商处理。

最近刚好有收到一封邮件，是SAP对一个产品类问题根本原因分析，大致地结构是这样的：

改进（Improvement）管理与业务分析（Business Analysis）

云端系统的一个好处是，在系统上线后也能持续、快速的优化系统、根据业务实际需求调整业务规则、甚至添加新的功能，而无需动到代码。此前介绍过的加密PDF分发就是一个例子。

HR系统管理员要主动识别、收集改进机会（improvement opportunity）。

案例：我们发现员工总对员工档案中某个区间有疑惑，就在这个区间加上相关知识库文章的连接；

发现经理在休假前常常不记得设置流程自动转授权，就设置自动提醒的规则；

发现用户总在一个应该点插入新记录的地方点了修改原记录，就设置在点了修改原记录后报错的规则；

发现HR每天要*载下**同一份报表再做二次加工，我们就将设置好过滤条件和格式报表每天定时发送。

HR系统管理员还要鼓励用户多多反馈系统的改进建议，哪怕是抱怨甚至投诉。用户使用系统、反馈问题、持续优化，这才是一个良性的循环。管理员动不了代码改不了系统的底层设计，但系统可以通过配置实现的扩展，也能帮助我们一点一点提升用户体验。

系统的不断演进，也帮助了在人力资源部甚至整个企业内培养持续改进的意识与文化。

收集到改进机会，管理员要统一记录、评估优先级、考虑如何衡量改进效果、与各方沟通。

对于比较复杂的改进或业务调整，管理员还要主导业务分析（Business Analysis）。这类改进建议通常由HR提出。通过沟通、分析，管理员（有些公司有专门的业务分析师）要能定义出其中的需求，提出能满足需求或者解决问题的建议方案。

建议方案要能提升实际的工作效率，因此并不限于变更系统功能，也可能是线上功能改进、线下处理方式改进、甚至业务流程改变的结合。

在此之后，才是验证和测试技术方案、计划系统变更。

验证与测试（Validation & Testing）

为了系统的新功能、新调整能达到预想的要求，而不会带来新的问题，在生产系统变更之前都应该在测试系统做好验证与测试工作。

对于SuccessFactors的管理员来说，做得最多的复杂调整就是改Business Rule了。写Business Rule的条件语句并不算太复杂，但有些错误是靠检查语句很难发现的，要靠各种场景的操作测试，结合Business Rule Log中记录的结果才能定位和解决错误。

回归测试（regression test）是最容易被忽略的测试。我们除了要测试新的功能、新的调整是否按照我们的预期执行了，还要回过头来测试原本一直正常的原有功能会不会因为这次调整反倒不能正常运行了。实践中，这样的情况并不少见。

变更管理(Change Control)

云端HR系统的变更，主要是指各种系统配置调整，这些调整要有计划。

变更的原因可能是因为原有问题的修复、原有功能的改进、业务调整、新需求新功能等。

SuccessFactors上线后主要的变更内容有Buiness Rules、报表、Dynamic Role、权限设置、版本升级后新增的配置点、数据结构等。管理员需要在实践中掌握这些技术、积累测试经验。

即使是验证过的变更，也不一定马上会在生产系统实施。

变更管理就是为了平衡变更带来的风险和收益，变更都要有评估、排期和相应的授权。变更被分为三类：

标准（Standard）: 主要是需要定期完成的规定动作，风险已充分了解，步骤有标准的文档。比如管理员每年年底要调整下年的节假日及调休、每年七月要调整社保公积金配置。

正常（Normal）: 通常的情况，每次有这类变更都需要重新评估、排期，如果有审批流程的还要重新审批。

紧急（Emergency）：处理紧急、突发情况的变更，评估和测试尽量要按照正常类的来做，文档记录工作可以候补。

将变更进行分类，可以作为变更排期的依据。

变更排期（Change Schedule）能够让资源分配更科学、避免冲入、协助各方沟通。排期还应考虑影响业务的时段，要避开避开业务高峰期；有些变更与变更之间有逻辑关联必须按照特定的先后顺序执行，计划时也应考虑。

服务请求（Service Request）管理

HR系统管理员处理要维护系统功能，还会要提供各种服务。

例如问询服务（用户来问这个功能在哪里找、哪个功能要怎么用）、数据导出服务（例如有些数据无法做成自助报表）、数据调整服务（例如有些数据的调整权限没给到员工/经理自助）、流程特殊处理（例如有特殊情况需要加签）。

管理服务请求，是为了保证服务质量。方法类似于管理事故，要有服务水平协议作为衡量标准，让用户和管理员对齐对服务请求处理的预期。

服务请求的处理要尽可能的标准化、自动化。

对于常见的请求、常见的问询，应该整理到知识库中，既保证服务的一致性，又逐渐培养用户自助去知识库找答案的习惯。

知识（Knowledge）管理

HR系统管理员在日常工作中处理事故、分析问题、变更系统、交付请求、解答问询，积累的经验都应该整理成文，在知识库中维护，以便在后续的工作中能够复用、分享，提高工作效率。

知识管理的目标，是保证所有的相关人员，都能在正确的时间、以合适的形式、在权限允许的内获得正确的、层次合适的信息。

系统实施的交付物，往往是几大本上千页的操作手册。这些手册是很难以帮助用户快速地找到解决方法的。

知识不是单纯的信息，而是可以在特定环境下可以使用的信息。

HR系统管理员要理解，是谁、在什么环境下需要这些知识。

在SuccessFactors中，我们也曾介绍可以使用Jam模块的知识库功能管理知识。可以针对不同的用户，比如普通用户、HR用户、系统运维团队创建不同的Jam Group，分别维护适用于他们的知识库文章，并按业务场景对文章进行分类和打标签。

从今以后，吾日三省吾身：

系统配置学会了吗？

业务背景理解了吗？

该沟通的沟通了吗？