本文来自微信公众号“twt企业IT社区”，作者/汪照辉，中国银河证券架构师，专注于容器云、微服务、DevOps、数据治理、数字化转型等领域，对相关技术有独特的理解和见解。擅长于软件规划和设计，提出的“平台融合”的观点越来越得到认同和事实证明。发表了众多技术文章探讨容器平台建设、微服务技术、DevOps、数字化转型、数据治理、中台建设等内容，受到了广泛关注和肯定。
横看成岭侧成峰，远近高低各不同。
不同的视角得出的结论可能是不同的，所以概念也总是层出不穷。在讨论一个问题的时候，往往会涉及很多的方面的概念和知识，一些概念是相似的、相互关联的、甚至是重叠的。理解这些概念之间的关系和联系，有助于我们更好的探讨和解决遇到的实际问题。
SRE与系统可靠性
SRE是Google为解决Web系统的可靠性而组建的工程师团队。所以SRE首先是工程师，重点关注的是可靠性，运维的是分布式系统上的业务服务。SRE实践给我们很多新的启示，它提供了一种协调研发和运维关系的方法，通过软件工程的方法让运维人员熟悉开发流程和业务服务逻辑、平台工具，了解软件系统的优势和弱点，从而有的放矢地去通过工程化、自动化等方法增强分布式业务服务的可靠性，以及平台工具的可靠性等等。它和DevOps方法论的目的是一致的。
系统可靠性代表着系统平稳运行不中断和良好用户体验的程度。可靠性高则用户体验就好。提升系统可靠性的方法很多，比如说高可用部署、容错机制、健康自检查、自恢复等。而实际往往需要通过多种机制协调配合才能更好的满足实际可靠性的要求。单体系统高可靠性容易实现，但分布式系统的可靠性就取决于很多相互关联的组件。一个分布式系统的可靠性往往又取决于其依赖的资源和系统。比如说，支撑运行的服务器、数据中心、电路系统，甚至是数据中心制冷系统等等。每一个点的故障都可能会带来依赖其的系统的异常，因此需要通过不同层次和节点的多种高可用、备份、容错等机制来提升可靠性。SRE通过软件工程的方式来提升分布式应用的可靠性，不但以实现自动化工具来提升效率，更从整体上考虑，消除了很多不可靠的因素。
可靠性计算通常是一个时间比值，也就是正常运行时间和总运行时间的比值。而韧性更多是考虑对不稳定性的容忍能力和容忍程度，是个区间值。混沌工程的目的就是要主动探测出某一条件下某一组件、系统、服务等的韧性的区间范围，从而形成知识库，为系统故障预警、智能化运维和运营提供支持。所以，有些人也称混沌工程为韧性工程。
可靠性工程和韧性工程
工程化思想通常是解决复杂的事情。随着分布式系统越来越庞大，彼此间的依赖关系越来越复杂，某一点的可靠性措施无法满足庞大系统的整体可靠性，所以需要以系统工程的思想来考虑分布式复杂系统的可靠性举措，从而发展成为可靠性工程的概念。可靠性不仅仅包括运行时的可靠性，也包括设计、架构、研发、制造、管理等方面的可靠性。作为一个系统来说，特别一个拥有众多组件的复杂系统，其中软硬设备彼此之间可能都是相关的，因此要使整个系统可靠，就得使每一个组件可靠。
将可靠性提升到工程的角度，一方面说明其重要性，另一方面也说明其复杂性。SRE采用软件工程的方法来提升系统的可靠性，通过对软件生命周期整个过程的协调，以自动化的平台和工具支撑研发和运维的协作，减少相互之间的依赖和耦合性，同时提升工作效率和正确度。
可靠性和韧性的追求都是应对系统运行中不确定性状况的能力。不过两个概念关注点不一样，可靠性偏外在的举措来提升，韧性则强调系统内在的能力。韧性工程就是不断的探索系统的脆弱点并通过消除这些脆弱点来提升系统的韧性。一个系统的可靠性不能纯粹靠外部的举措，很多时候引入的组件越多，系统越复杂，脆弱点可能越多，不稳定性反而越高，因此需要尽可能通过改善并增强系统内部的韧性来提升稳定性和可靠性。这其实也就是混沌工程的重要价值所在。
但对大部分运维人员来说，最期待的是不变更，别天天那么多发布。这和研发敏捷变更的追求是矛盾的。立场不同，责任不同，所以也带来的利益和关注点不一样。不变更正常运行的系统，理论上这对运维人员来说是成本最小利益最大的方式。因为任何的变动都会带来意外情况，都可能导致系统异常或不可用，会给运维人员带来麻烦、工作量和绩效差评，所以运维人员对应用系统的发布上线有来自内心天然的排斥感。人天生就有趋利避害的意识，这是人性。工程化的思想也将利益相关的人员纳入其中，满足彼此的利益关切，才能更好的促进目标的实现。
可靠性工程关注的是整个生命周期的过程中可能对可靠性带来影响的各种因素。比如说，软件架构（包括设计架构和部署架构）、代码质量、异常处理逻辑、故障恢复能力等。所以说软件本身的可靠性是基础，然后才能通过其他手段来提升其可靠性。故障自恢复的目的是减少人为操作，尽可能实现自动化，一是提升了效率，二是减少了手工命令输出错误。这也是SRE所要求的。从而也可以说，运维的敏捷才能支撑研发的敏捷。自服务敏捷基础设施是支撑研发敏捷的基础能力。
不折腾是系统稳定性的保障之一，但一旦出现问题，往往也会措手不及，所以它和混沌工程主动去探索系统不稳定的因为是相反的，所以需要演练。很多人也提倡混沌工程来提升系统可靠性和韧性，它也是增强认知从而更好应对不确定性的很好的举措。
应对变化和混沌工程
不过系统运行是动态变化的，特别数字化时代，敏捷应对变化是必需的能力，所以通常需要能动态的应对这些变化。对于任何一个系统来说，其可用的资源都是有限的。比如说，磁盘存储资源，如果应用系统的日志大小和数量没有限制，早晚会导致磁盘资源耗尽而使应用系统进程异常。但通常应用系统运维人员并不参与系统的设计和研发，可能不了解日志文件大小和数量是否进行了限制，所以需要对这些内容进行监控和分析，找到可能会导致系统异常的一些点，然后采取措施消除这些可能会导致系统异常的点，从而也就提升了系统的可靠性和稳定性。要具备应对变化的能力，就需要对环境和系统运行状况能够有所了解，或者有深入的了解，知其然更知其所以然，才能做到敏捷应对。
混沌，指的是一种模糊不清的状态。和一片清明、知其所以然正好相反。混沌工程要做的就是将一片混沌的状态探索为一片清明，所以混沌工程重要的是知识的积累，知识库的建立就非常有必要而且非常重要。用已知的知识探索未知的领域，逐步对系统的内外有清晰的认识。探索过程中有时候是很难控制影响范围的，因为对当前的环境和状态是未知的，因为未知，所以才需要探索，但因为未知，也就难以知道哪里有陷进、哪里是悬崖，犯错甚至牺牲都是有可能的。
不管概念怎么变化，核心的内容其实还是那么多。结合不同的概念有时候可能更好地、全面地理解这些内容。同样，在进行系统建设时，也需要结合不同的概念和系统，来从全局考虑和把握，避免重复的建设和低效的集成。数字化时代，重要的时要具备全局的思想、敏捷的思维和随时随地随需的响应能力。
