1.3.5　IT服务可靠性及服务流程的挑战

业务部门希望给用户提供100%可用的服务，我们先不考虑保障服务100%可用实现的可行性，以及要投入的成本方面的因素，仅就99.99%与100%的服务可用性对用户最终的使用体验来说，绝大多数情况下可能并没有不同。不过要保持服务可用性99.99%与100%，资源投入可能完全不在一个级别，因此必须考虑投入是否经济的因素。

提高服务可用性主要是通过服务冗余的策略实现的。举例来说，某套系统只有单个节点的可用性为90%，有10%的概率会不可用，那么我们准备两个一模一样的节点，同时对外提供服务，这样当其中某节点出现问题的时候，另一个节点还能响应用户的请求，这样该套系统的可用性可能就提高到了99%，如果我们想把可用性提高到三个九，那就再加一个节点好了。从1个9到3个9，冗余度提高了3倍，成本至少也是3倍，而仅仅只是要把服务的可用性从90%提升到99.9%，更别提99.99%甚至更高级别的可用性保障了。当然，实际情况往往比这个示例要复杂许多，多数情况下也不是简单地加节点就能提高可用性，在系统本身支持弹性伸缩的前提下还要有一系列动作，在负载均衡、缓存、应用、数据库等方面均会有相应投入，这还只是在不涉及应用系统改造、变更发布等环节的场景，单从提高冗余度的角度考虑。

冗余是提高服务可靠性的有效手段，但并不是万能钥匙，在现实场景中，几乎每个服务提供者都要持续不断地发布新的功能、修复已知Bug，不断进行投产变更，服务的发布投产本身也可能引入潜在的风险，从而导致服务不可用。那么能不能少发布或者干脆不发布呢？这就要从IT服务管理环节中的两个关键角色——开发和运维说起。运维角色的关注点是保障业务连续性，希望不动或少动生产环境，而开发角色的主要目标是尽早、尽快发布版本到生产环境，以满足业务和市场需求。这两个角色既有协作也有分歧，既相辅相成又相互制约，针对这一情况，业内普遍使用服务可用性指标SLA（Service Level Agreement）来综合考虑，平衡开发和运维两大角色的关切点，同时控制IT服务的风险。

服务可用性指标的计算非常简单：

可用性=可用时间/（可用时间+故障时间）

这个可用性在业内通常用“几个9”来表示，9越多代表着服务的可用时间越长，服务不可用的时间越短，当然也意味着服务越可靠。以全年365天来计算，将可用性转换成时间，相信更有助于大家理解这个概念：

1年 = 365天 = 8760小时

可用性99.9%，即故障时间 = 8760×0.1% = 8760×0.001 = 8.76小时

可用性99.99%，即故障时间 = 8760×0.0001 = 0.876小时 = 0.876×60≈52.6分钟

可用性99.999%，即故障时间 = 8760×0.00001 = 0.0876小时 = 0.0876×60≈5.26分钟

从上述数据来看，要使服务全年可用性指标在4个9以上，全年的故障时间要在1个小时以内才可以，若要实现5个9，则服务停机时间不能超过5.26分钟。

设置一个服务可用性指标作为科技团队共同的目标任务，而不仅仅只是某个岗位会关注。比如，信息科技团队的年度服务可用性的整体目标是保障99.9%，那么，若服务可用性高于3个9时，IT运维团队可以响应开发团队的发布流程；当服务可用性低于3个9时，则除非发布流程经过特殊审批，否则不再进行投产变更。这种方式是在服务的可靠性、经济性以及机会成本等多个因素间找到平衡点。

此外，不少一线运维团队在工作中会出现这样的情况，一方面IT运维服务部门疲于奔命，加班加点地处理各类突发或重复的事件；另一方面需求部门不断抱怨“IT部门服务水平低、响应不及时”；故障发生前似乎人人无所事事，故障发生后个个手忙脚乱。这里有业务部门对运维工作不够了解的原因，也有运维团队服务管理不够规范的原因。

可能会有些部门管理者寄希望于通过上线一套系统，不管是ITSM还是DevOps，实现对IT服务和IT相关团队的管理，以为软件上线后那些头疼的管理问题就能消失不见。其实没有这么简单，没有任何一套软件或方案能够解决所有问题，甚至新上线的管理软件解决掉一部分问题，可能又引出新的问题，这既要我们能够根据企业实际情况合理配置流程和工具，又要求我们对服务管理软件的使用效果有合理的预期。

很多人在推广一项新的方案时，潜意识中通常会默认一点，就是使用后效率就可以明显提高，可是往往真正工单化、流程化之后，用户会感觉新的流程“把简单问题复杂化了”，甚至会以新的流程导致效率下降，抗拒执行新的流程。

这里存在多方面的原因，一方面，在流程制定过程中，遵照现有的流程，只是将其电子化而非改良优化，或者盲目照搬经典流程，未能切合实际，只流于形式。即使是标榜最佳实践的ITIL，一味教条地照搬也不会有好结果，反倒会对流程贯彻执行产生不好的影响。另一方面，对工具的作用可能还有理解上的误区。实际上，我们在推行工具的过程中，除了考虑效率以外，还有质量、成本、风险、合规等因素。除此之外，IT服务管理需要考虑三大要素——人（People）、流程（Process）、技术（Technology）（简称PPT），流程只是其中之一，过于关注流程而忽略了另外两个关键点，在高手眼里还没出招就已经输了。

IT服务管理非常关键，也极具挑战性，哪些问题要通过流程或工具解决，哪些问题要通过制度或规范才能实现，都要思考清楚，将理论与实际情况相结合，注重工作流程细节的设计和优化，才是IT服务管理的关键。