导语：

银行业数据中心数字化转型是一项系统性工程既涉及管理层面转型——包括数字化转型战略、基础架构和技术架构转型、技术创新和知识体系转型，又涉及执行层面转型——包括人员管理（P）、流程管理（P）、技术管理（T）、资源管理（R）等。数据中心数字化转型作为一项宏大的系统性工程，必须要依据一个模型或标准化管理体系，有规划、有步骤、分阶段开展，才能保障落地实施成功。本文围绕数字化转型模型进行分析解读，与各位读者共飨。

在银行业数据中心数字化转型之模型篇01篇和02篇的内容中，我们向大家阐述了ITIL 4管理体系和它对数据中心数字化转型的参考价值有哪些，以及ITIL 4体系的创新理念、思维模型、指导原则等内容。在今天的文章里，我们将与大家共同探讨时下炙手可热的参考框架SRE，以及其对数据中心数字化转型有哪些助力作用。

伟大的SRE起源

SRE不仅是运维管理、运维转向运营管理的参考框架，更是数据中心数字化转型的重要参考宝典。SRE灵感来源于玛格丽特•汉密尔顿，她首次提出了“软件工程师”一词，并将软件工程方法论引入了NASA，同时她还是编写阿波罗太空舱操作程序的主要负责人，她开发了航空器导航和控制软件，也正是基于航天零容忍的可靠性理念，SRE越来越让数据中心管理者们关注和青睐。

SRE运维理念的创新

1. 小的改变、大的提升

开发人员与运维人员的目标是不同的，开发人员是以响应业务部门需求，业务功能最快上线为目标。运维人员作为生产环境问题的发现者和直接责任人，则是以保障生产环境可靠性为目标。所以这就形成了我们常说的，开发人员在工作中天然的想法是“加油门”，而运维人员在工作中天然的想法则是“踩刹车”。那么如何让开发人员与运维人员的目标趋向一致，使两者愿意通过共同的努力达成双方认可的目标呢？SRE给出了答案。

传统运维下的可用性计算公式为：

可用性=（总运行时间 - 计划外停机）/ 总运行时间

从上图可以看出，在计算可用性时，计划内停机是不计算在内的，对于开发人员来说，只要提前申请了应用上线请求，经过流程审批后就可以“友好”的发布业务系统维护通知，让客户登录系统时出现“系统正在维护中……”的窗口。由于提前已经设定了计划内停机时间，开发人员普遍认为上线停机是理所当然的，却很少思考计划内停机对可用性的影响。

那么，SRE框架下是如何计算可用性的呢？

SRE引入了“错误预算”概念，并将其应用于新功能上线、系统例行维护、故障处置等，不再区分计划内和计划外停机，只要停业务就会占用错误预算，所以SRE推行的可用性计算公式为：

可用性=（总运行时间 – 错误预算）/ 总运行时间

错误预算的引入，看似是一个很小的变化，但恰恰是这个变化让开发人员与运维人员的目标逐步趋向一致，因为一旦开发人员申请新功能上线就会影响可用性，所以可用性就成为了开发人员与运营人员需要共同保障的目标。错误预算的引入，使得开发人员与运维人员必须想尽办法实现业务上线不停机，如应用高可用、灰度发布等方法，通过开发人员与运维人员的共同努力，以此来保障和有效降低错误预算。

同时，错误预算的推出，更加体现了运营的理念，减少停机就是增加运营收益，保障运营可靠性则成为了开发和运维共同的的目标。

2. 运维的必备技能是开发

SRE倡导日常运维工作占用总工时的50%以内，并将剩余时间花在运维侧研发工作上，通过运维侧的研发工作来改进运维效率，保障系统可用性。

在SRE框架下，通过采取一系列措施，让开发团队和运维团队，尤其是运维管理层，认同运维人员将50%精力用于研发运维支撑工具。

■　第一项措施是运维管理层定期度量成员的时间分配，保障运维人员用于日常运维工作的时间控制在50%以内，从工作分配层面保障投入研发的工作时长。

■　第二项措施是建立开发人员与运维人员轮岗机制，让开发人员主动认识到停机发布、系统不稳定对系统可用性带来的影响，同时让开发人员为运维自动化出谋划策，与运维人员共同改进运维模式，因为开发人员更懂软件架构、更能够使用软件的思维解决问题。

■　第三项措施是对告警和事故进行强制性定期分析，SRE的准则是“对事不对人”，定期分析是尽早发现和堵住漏洞，而不是想办法绕过和掩盖它们，通过定期分析制定告警优化和事故处置的策略，制定运维支撑工具研发计划。

运维侧研发是改变运维模式的唯一方法，构建运维侧研发能力是提高运维效能的根本，保障运维人员50%精力投入到运维侧研发工作是非常革新的理念，在数字化转型的快速推进中非常值得推广。

3. 运维管理的目标是消除琐事

每天都有忙不完的杂事与临时性任务，是大部分运维人员的认知，我们暂且认为这些就是SRE所说的琐事，消除琐事是每位运维管理者的追求和梦想，但现实中往往事与愿违，始终难于找到有效的方法。

SRE对琐事的定义（拥有以下部分特征被认为是琐事）：

■　手动性：需要手动执行的任务，包括手动执行脚本

■　重复性的：反复做的工作

■　可以被自动化的：通过计算机能够完成的任务，或者通过某种方法彻底消除的任务

■　战术性的：突然出现、应对式的临时工作，非策略驱动和主动安排的工作

■　没有持久价值：完成任务后，服务状态和效率没有改进

■　与服务同步线性增长：随着流量或用户数量呈线性增长的任务

SRE的公开目标是保障每个工程师能有50%以上的时间投入到运维侧开发工作中去，显然琐事不消除或越来越多，肯定是无法满足这个目标的。如果琐事不加以控制，就会变得越来越多， 最终一定会占据运维人员100%的时间。当然，我们可以通过增加运维人员的数量来解决问题，但通常情况下不但不能加人，而且领导层希望运维团队减人，所以SRE提出的消除琐事的思路是非常正确和值得革新的。

SRE实践成果借鉴

SRE不仅仅对运维有着强有力的革新，同时拥有着大量的实践成果，这些成果可以作为数据中心数字化转型的借鉴。

1. SRE框架下的能力转型

SRE致力于通过自动化和智能化工具改变被称为“琐事”的运维工作，所以运维组织的知识结构有些明显的不同，一是对人才能力要求非常高，既需要懂基础软硬件的系统知识，又需要懂开发，所以招聘难度大，单体人员成本高；二是初级工程师以流水线操作为主，负责执行机器无法替代的工作，如干预支撑工具的操作；三是原有系统运维和应用运维二级工程师转型为运维效能优化类的软件设计和开发人员。

传统运维客户如果计划转型为SRE运维，需要先独立成立SRE运维团队，同时将现有运维人员逐步转型，通过较长时间的过渡、并行，最终将团队优化和转型为SRE模式，前期阶段需要投入较高的并行成本，对于管理者需要足够的革新勇气。

SRE模式下的运维，人员相对减少、单体成本相对较高、系统可靠性提高、运维效能提高，所以选择SRE模式运维不应该单纯的因为成本节约驱动，一定要建立在保障越来越大的业务可靠性、保障运维向运营转型的驱动上。随着银行业数字化深入，运维转向运营成为发展的必然，融入SRE理念也是大势所趋，软件定义运维的时代已然到来。

2. 解决容量规划问题

资源云化解决了传统的建设应用同时购买硬件、硬件资源使用效率低的问题，但云资源池如何进行容量规划也成为了新的难题。SRE对于容量规划提出了新的思考，其观念和方法值得借鉴。

SRE容量规划关注点：

■　必须有一个准确的自然增长（随着用户使用量上升，资源用量也上升）需求预测模型，需求预测的时长应该考虑资源到位的时长，以保障资源预测到获取期间的资源自然增长量。

■　除自然增长外，需要考虑非自然增长因素（环境变化带来的新品发布、商业推广活动、同业竞争等商业因素引发的流量），规划中必须有准确的非自然增长需求来源和统计。

■　必须有周期性压力测试，通过压力测试判定系统性能符合度，以评估满足性能要求下的容量扩容需求，特别是在硬件变化和升级（如下移或信创改造）后，周期性的压力测试尤为重要。

3. 让运维回归简单

就像“盖尔定律”中所描述的那样：任何复杂的系统都是从简单的系统逐渐演变而来的，运维一套云平台、或者运维一套应用系统也是同样的道理，随着时间的推移，一定是越来越复杂，包括架构和关联关系，或者很少有单个运维人员能完全描述清楚，所以要保障运维质量、提高运营效率，一定要将运维工作回归简单。

如何让运维回归简单？

如何让运维工作回归简单，SRE带给我们很多的启示和借鉴：

■　运维工作首先要做好监控，针对监控SRE给予了足够的重视，对外也进行了充分的经验分享。通常情况下，运维人员收到监控告警，然后根据告警去跟踪排查问题，SRE认为当发生了需要运维人员进行人工干预的事件时，监控系统才能发告警给运维人员，运维人员收到告警与推荐的处置方案进行应急处置，而不是收到告警后进一步排查问题，SRE的理念需要监控系统完成根因分析，找到事件的准确原因，对监控系统提出了非常高的要求，这也正是运维侧研发的目标。

■　运维人员需要对复杂的架构、复杂的运维工作进行解耦，让工作回归简单，比如在当下运维人员面对全闭源、紧耦合的全家桶云管平台，当出现问题后需要重度依赖云厂商解决，这种情况下需要做的工作是让云管平台回归全开放、松耦合架构，简化运维问题的处置，让运维回归简单。

■　从管理层维度上，SRE管理者需要为运维侧研发工作预留足够的时间，通过运维侧研发简化运维工作，让运维回归简单，达到可用性目标。（未完待续）

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。