京东商智_工程架构高可用设计浅析

大家下午好，今天分享的主题是“工程架构高可用设计”。为什么选择这个topic呢，我们通过各种新闻也知道，上个月的阿里云、滴滴以及这个月前两天腾讯视频都比较密集的分别出现了大面积系统瘫痪，服务不可用的事故，尤其是就在上周滴滴的事故恢复时间长达12H，影响上千万笔订单，营收损失4个亿。这里有技术因素也有非技术因素，“前车之鉴，后事之师”，里面有哪些规律性质的信息我们可以借鉴的呢？今天我分别从技术篇、思维篇、认知篇进行相关的分享，希望能够有所共鸣。

技术篇：鲁棒性架构三板斧

首先简单分享下我工作上面不同阶段与工程架构设计相关的一些经历吧；毕业前在google实习大概一年多，从事大数据计算框架的研发工作，当时谷歌与htc合作推出的nexus系列的手机和平板，并且在2012到2014年期间收购了多家智能穿戴公司，它判断随着智能穿戴的普及可能人均被覆盖上千枚sensor收集行为数据，这势必会需要更强的实时离线数据计算能力，当时MapReduce模式已经出现了一些场景下面的瓶颈，在学届Spark也逐渐投入使用，但是工业界当时比较可靠的或者是国外比较推崇的是twitter的summingbird，所以当时我们研究summingbird、scalding等等的源码，内部孵化代号LAMA的基于lambda架构的计算框架，我负责其中算子的实现，这个过程中感受到了周围同事对于技术趋势的前瞻和兼容并包的创新动力，而创新大概率会失败，但是这个失败我们注意，它不羞耻，而对创新失败的包容才是工程师文化和创新的土壤，其实内部有非常多的探索性质的创新孵化，只有对于创新的包容才能获得业务应用上的惊喜；毕业后基于一些政策的综合考虑加入了搜狐产品技术中心，先后负责垂直搜索和微服务治理与基础架构工作，这是第一次提供C端在线服务，体会到了系统鲁棒性的重要，记得有一次垂搜上线，发布后20min就线上响应性能断崖下降，当时启动了应急预案，standby分组与online分组交替抗压争取修复时间，同时进行主索引数据恢复，这是第一次面对严重的线上问题，也深刻体会到了高可用的重要性；又比如微服务治理，C端的微服务是非常庞杂的，比如微服务鼻祖netflix有4000多个微服务，拓扑关系以及最佳路径，染色追踪，防止成环等等是稳定性面临的多个难题，尤其是C端服务要求返回都在10ms以内，就涉及到大量缓存的精细化使用，确保数据一致性，数据韧性，和多层缓存不浪费存储，这些都是当时重点需要解决的问题；负责以上核心系统后，当时国内广告做的比较好的是阿里妈妈和腾讯广点通，所以来到广点通先后负责DMP、TDC、联盟广告优量汇平台，这里就涉及到一个新的挑战，标准的制定，这个标准涉及到跨多个研发团队的协同开发效率以及对外商业售卖的服务协议标准，提升客户自助消费服务的能力，对内比如DMP传输PB的标准，每一个字段内每一个字节码的含义与规则，确保内部研发团队少量沟通就可高效协同，对外提供比如marketing API供外部KA广告主自助创建投放计划、创建广告素材等等，需要确保该标准对业务的普适性，并且确保外部调用甚至恶意攻击不会穿透或影响到内部服务，其实对于标准的制定尤其是要人和系统都遵循这个标准，是非常非常难的，而且高质量或多或少会伴随可感知的“慢”，印象比较深的是当时技术评审有时候评一周都不让动手写代码，而这个改动仅仅是通信协议里面增加一个字段，这也就是前面提到的高可用不仅仅是技术问题，后面部分也会涉及到相关的内容。
高可用（High Availability）是每位工程师在进行系统设计和代码编写时都不得不思考的重要环节。

高可用的判定标准是一年内业务不可用时间。高可用99.999%（5个9），意味着一年内只允许宕机5.2分钟，但一般情况下我们说的HA指的是4个9，也就是52分钟年内不可用时间；达到99.999%代表这个系统在高可用方面做得相当出色，而由于在线系统线上极其敏感，有一点风吹草动业务就能感知到，HA就显得更加重要，比如我们熟知的搜推广、C端服务、数据服务与实时链路等。

达成高可用非常关键的几个措施，也就是技术篇提到的三板斧我总结就是消除单点故障（SPOF single point of failure）【系统拆分、解耦、异步、隔离、快失败】，实现故障转移（failover）【限流、降级、熔断】，合理冗余（redundance）【幂等重试、补偿、备份、多活、无状态】；这部分是偏总结归类性质的，所以我对每一个方法简单描述下。
A- 系统拆分：早前的系统都是单体系统，也就是All In One的架构，比如电商业务，会员、商品、订单、物流、营销等模块都堆积在一个系统。每到节假日搞个大促活动，系统扩容时，一扩全扩，一挂全挂。只要一个接口出了问题，整个系统都不可用；我们常说“鸡蛋不能放在一个篮子里”，这种连带风险需要从设计初期就进行规避，后续慢慢的就有了我们现在看到的微服务架构，将一个复杂的业务域按领域驱动的思想拆分成若干子系统，每个子系统负责专属的业务功能，做好垂直化建设，各个子系统之间做好边界隔离，降低风险蔓延，避免牵一发而动全身。
A- 解耦：计算机工程有个重要原则“高内聚、低耦合”，就以开闭原则为例，对扩展是开放的，对修改是关闭的。随着业务功能迭代，如何做到每次改动不对原来的旧代码产生影响，类似于大家熟悉的AOP ，（Aspect Oriented Programming），面向切面编程，核心就是采用动态代理技术，通过对字节码进行增强，在方法调用的时候进行拦截，以便于在方法调用前后，增加我们需要的额外处理逻辑；或通过事件机制，通过发布订阅模式，新增的需求，只需要订阅对应的事件通知，针对性消费即可。不会对原来的代码侵入性修改，比如各种MQ，比如JDQ、JMQ、Kafka这些；
A- 异步：同步指一个进程或者线程在执行请求的时候，如果该请求需要一段时间才能返回信息，那么这个进程将会一直等待下去，直到收到返回信息才继续执行下去；效率会大大降低。所谓异步方式，如果是非实时响应的动作可以采用非阻塞方式来完成，线程不需要一直等待，而是继续执行后面的逻辑，完成后通过回调等方式进行通信；或者是日志打印场景，如果是同步的方式，可能文件写入这么基础的动作会阻塞整个主链路，那就可以选择异步日志或上报的模式；
A- 快失败：也就是Fail Fast，让异常的情况尽可能早的终止并做合理返回，避免异常的信息继续往后链路扩散形成难以收敛的问题或浪费存算资源，最简单的比如一个异常参数，应当在入口校验出来，而不能继续往后传递；
B- 限流：对于高并发系统（相对的，C端可能是百万QPS，比如抖音就有几千万的QPS，但是数据可能是几百QPS，这里视计算复杂度有差异，因为C端很多都是缓存操作，但是数据很多是现算），如果遇到流量洪峰，超过了当前系统的承载能力，限流就发挥了作用，而且限流往往和降级联动，我们常用的限流算法比如：计数器限流、滑动窗口限流、令牌桶限流
B- 降级：降级是系统保护的一种重要手段。为了让有限资源发挥最大价值，我们在紧急情况下会临时关闭一些非核心功能，减轻系统压力，并将有限资源留给核心业务。比如大促，业务在峰值时刻，系统抵挡不住全部的流量情况下，系统的负载、CPU 的使用率都超过了预警水位，可以对一些非核心的功能进行降级，降低系统压力，比如把商品评价、成交记录等功能临时关掉。弃车保帅，保证创建订单、订单支付等核心功能的正常使用。当然也分为主动降级与被动降级；
B- 熔断：其实是对调用链路中某个资源出现不稳定状态时（如：调用超时或异常比例升高），对这个资源的调用要进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误，形成雪崩；熔断的主要方式是使用断路器阻断对故障服务器的调用；断路器的状态机有三种状态，关闭、打开、半打开，而半打开在状态机里面是一种试探状态，就是尝试敞开些窗口做一些探针，如果恢复再扩大；
C- 幂等重试：通过冗余的请求确保流程的健壮，重试通常跟幂等组合使用，如果一个接口支持了幂等，那你在性能允许的情况下就可以随便重试，而幂等是需要被调用方做到的，通常可以通过插入前先执行查询操作，看是否存在，再决定是否插入、增加唯一索引、建防重表、引入状态机，比如付款后，订单状态调整为已付款，SQL 更新记录前增加条件判断、增加分布式锁等等手段；
C- 补偿：我们知道不是所有的请求都能收到成功响应。除了上面的重试机制外，我们还可以采用补偿玩法，实现BASE理论的数据最终一致性。业务补偿根据处理的方向分为两部分：正向的，多个操作构成一个分布式事务，如果部分成功、部分失败，我们会通过最大努力机制将失败的任务推进到成功状态；逆向的，跟上面过程差不多，我们也可以采用反向操作，将部分成功任务恢复到初始状态；但是补偿操作有个重要前提，业务能接受短时间内的数据不一致；
C- 备份/多活/无状态：任何服务器都有宕机的可能性，一旦存储了数据，带上状态，如果发生故障，数据丢失，后果是我们无法承受的；所以，备份和无状态这些冗余就需要准备好，例如各种数据集群、主备、双流，任何节点都不是不可或缺的，死掉后集群依然可以正常运转，又如在线服务，扩缩容器都可以做到使用视角无感，那怎么做到呢，就需要无状态，也就是不要某个instance是独特的，比如单独的配置项，单独一份数据等等；虽然有了上面的备份策略，那是不是就万无一失了呢？在一些极端情况，如：机房断电、机房火灾、地震、山洪等不可抗力因素，所有的服务器都可能出现故障，无法对外提供服务，导致整体业务瘫痪。为了降低风险，保证服务的24小时可用性，我们会采用多活策略。常见的多活方案有，同城双活、两地三中心、三地五中心等；
在线工程问题引入分为三类：变更（也就是上线、流入数据变化、施加压力点变化、线上配置变化等等，70%事故都上线引起）、过载（c端这种容易过载，但数据服务相比c端流量虽小但是在线计算压力比较大，集群共享所以一样可能过载）、强依赖故障（如第三方db和api，这又可以递归的归结为强依赖变更、强依赖过载）；上线需要做到随时可回滚，包括但不限于代码、DB、配置文件等等，回滚又分为单点回滚和链路回滚；
下面我们来看下最近密集发生的比如阿里云&滴滴事故分析，看看上面我们啰嗦的这些所谓方法论是不是能发挥作用和对应上的。
原因：变更（线上白名单结果变化）+强依赖故障（AK服务被很多核心链路依赖，引发连锁反应）；应对：冗余（白名单版本快恢复）、故障转移（降级跳过保恢复）、消除单点（FF生成后第一时间校验合法性）

滴滴线上故障，所有基础服务全部不可用持续12h恢复；kubernetes版本升级错了；初步分析原因：1、微服务太多，拓扑不清楚，一部分修复后，其实里面还调用了其他的服务，“核心服务”拉起来后又调用了一些所谓“非核心服务”，不能收敛，导致几乎所有服务都恢复一遍后才整体恢复；2、缺少AB版，冗余不足，容器内部配置并非全部无状态，只换容器或宿主机也拉不起来；

思维篇：工程化思维与习惯

技术相关的相对枯燥，我们总结之后，下面进入到思维篇，这部分相对会有意思一些，主要分享一下做复杂架构设计时候之前经常会用到的几个工程化思维模式和方法：

1、我总结起来是：知目标、有全景、做切割、串流程：

也就是我们需要做一件事情的目的是解决什么角色的什么问题，甚至是解决到什么程度；目标明确后就是梳理可能涉及到的子事项，这些事项如何归类；按照单一职责应当如何切割成具体模块；模块确定后应当如何设计通信机制和协议来保障整个体系串联运转起来，这是一个思维链路，但是实操起来其实很难，这里有三个行之有效的技巧：；

1.1 目标快速锁定：七问：【是个什么事情】+ 【为什么要做，可不可以不做，不做会有什么影响？】+ 【都需要谁或者什么角色来做？】+ 【需要什么时间做，又要什么时间完成】+ 【在什么地方或者系统做合适？】+【怎么做，怎么最高效地做，具体方法或者方案是否靠谱？】+【要做到什么程度算合理，交付物是什么？】
1.2 全景路径规划：邓宁克鲁格效应里面提到的有一个叫认知曲线，大部分人都处于“不知道自己不知道”的阶段，对应到国内，也有人比喻叫做井底之蛙现象；又比如“看山是山看水是水–看山不是山看水不是水–看山还是山看水还是水”，这是一个维度提升和认知扩展后对于所意识到的“全景”的感官的不同状态，就比如下图；而想要看到相对的全景的唯一方法就是升维，比如常说的站高一级看问题，站高一级就能看到事物更全的样貌。

上面说的比较抽象，这里推荐一个比较有效的方法：推演与归纳：类似于下盲棋，两个人面前没有棋盘和棋子，脑子里面就对棋局全景进行推断；在全景路径规划时候，需要锚定目标，把要解决的问题依靠自己的经验和对事情本身的判断进行抽象、归类，这个过程就是归纳。形成一定的框架后，在用实际的一些可能发生的情况，把什么时间做什么事情很详细地在脑子里面进行模拟，用户做什么操作，对应到什么系统处理什么事情，而这一系列的操作就是去印证归纳的问题是否可以按照设定的路径得到解决。

1.3 模块切割与流程串联：确定好目标和全景后，就要把初步设计出来的框架进行切割，来明确系统的分工和职责，这里就需要相互独立、不重不漏（MECE），避免因为划分的空档而把事情掉在地上，也要避免职责重叠形成三不管的灰色地带。

2、不知道如何设计时，就回归客观世界

有一句话说的是：普通的工程师工作在规则里，优秀的工程师工作在规律里。什么是规律，是对于一类事情的动线抽象，在什么情况下满足什么条件就必然发生的抽象，而规则是发现规律的人为了快速拉齐认知，而设计出来的条条框框，你理解不理解都按照这个做就有保障了。而规律的本质无论是工程系统的设计还是客观世界都是相通的。
比如从基于强主机的单体架构进化为分布式架构的过程：为什么要这么做，因为系统崩塌风险更低、稳定性与扩展性更强、成本更少；类比客观世界好比专制集权社会与民主社会，前者社会稳定与繁荣非常依赖于领导者的英明与活得长久，而后者则依赖性低很多，同时伴随着选举制度，计算机的slave-master模式也如此；而选举算法比较有名的有bully、raft、paxos等，以最简单的bully算法为例，它是1982 年发表的，这是分布式系统中很常见的选举算法，它的选举原则是“长者”为大，也就是在所有存活的节点中，选取 ID 最大的节点作为主节点。假如有一个集群，各个节点可以相互连接，并且每个节点都知道其他节点的信息（ Id 和节点地址）

比如我们去餐厅吃饭，九十年代时候会发现大量打饭窗口排队的现象，每个顾客顺序点餐，而现在我们点餐往往是扫码点餐后就可以干别的去了，等食物准备好后会手机通知取餐即可，这让整个用餐效率大幅度提升；对应到计算机设计里面就是同步和异步过程，或者是生产者消费者的模式，我们对于有时间成本的操作，往往采用回调或者消息通知的方式提升相同资源情况下的整体吞吐；

3、架构不是洁癖，架构是合适的阶段，恰如其分的设计

2017年的时候，我和一个在字节工作的同学聊天，他说他们有个一千多人的研发群，每天无数个线上问题，在里面报回滚，我当时觉得这么简陋么，也没太细想；后来2020年时候不经意的和一个在拼多多工作的前同事聊天，他也说他们有个大群，里面很多人报上线问题然后联合回滚，后来在脉脉上看到temu也有这个现象；我觉得这并不是很差的表现，而是架构的设计方式与公司和业务的发展阶段有关，如果在字节和拼多多当时的阶段，研发们人人自危，一堆人事事复盘，可能发展速度就丢掉了，也就成长不起来了；我们在工程交接的时候会发现很多同学会吐槽，这些的什么玩意儿，这里那里都不优雅，但是是否考虑过这种设计是不是当时条件下的最优解呢，所以架构不是洁癖，架构是合适的阶段，恰如其分的设计，要避免提出“何不食肉糜”这种不接地气的设计。

4、架构是为解决问题服务的，初心不变

任何工程架构设计都应当以解决问题为出发点，而不是炫技为出发点，避免浮沙筑高台；优秀架构没有银弹，先明确解决什么问题，问题导向，避免运动式架构迁移与升级，运动式看起来快，气势磅礴，大刀阔斧，但是很容易被反噬；比如文革时期，要解决什么问题呢，解决思想问题，左右问题，吃不饱饭的问题，但是命令式的一刀切做法，让初心偏离，但是高压还在的时候看似平静，高压不在后很快遭到反噬与清算。所以架构设计也是为解决问题服务的，要实事求是，实践是检验优秀架构的唯一标准，没有银弹也没有权威。

5、效率优先与敬畏线上是一种思维习惯

这里举两个例子，我们进电梯的时候如果后面没有人排着，我们是先按关门还是先按楼层呢，我一般是先按关门，开始执行关的动作后再去按楼层，因为整体效率更高；效率优先的思维不仅是我们做系统设计的时候需要用到，平时生活中也会发现很多点滴；另一个对于线上的敬畏给我印象很深的是，之前公司的一个研发负责人，他和我说他每天洗澡进浴室之前都会做一件事，就是把手机放在防水袋里带进去，避免线上问题等信息延误，这个当时我工作没几年觉得是不是有些严重了，但是回过头来想一下线上问题争分夺秒，无论是应急处理还是做决策，都耽误不得，这是一种习惯，而习惯和要求有个很明显的区别，就是如果把这些规则当作要求我们往往觉得有些累，但是如果内化为自己的习惯，其实会觉得很自然，反而不会累。

6、合理的架构设计在落地过程中与配套的规则、标准、机制密不可分

一个普通的规则得以落地，往往需要强制外力，比如“老板要求必须这么做“，比如交通法规，其实很多人不愿意遵守，都想有塞就加，都想走公交车道，有法规，我们就难受了，这其实是依靠强制外力也就是权力机关确保的；而好的规则设计，往往来自于制衡或者叫”博弈“；最简单的就是一个问题摆在那里，应该是谁去解决呢，当然是谁痛谁解决，因为他有动力，一个没有原动力的规则是很难持久的。这里涉及到一个自然界普遍存在的熵增原理（任何一个孤立系统，在不受到其他系统制约或干预的情况下，不可能自发向低熵状态演进，即不会自发地由无序变得有序），需要助推与制衡形成飞轮，才能持续运转；

说到制衡与博弈，分享一个《博弈论》里面的经典案例：智猪博弈；“智“简单来讲就是假设猪具有基本的趋利避害的本能。情景是：一大一小两头猪被关在同一个猪圈里，猪圈很长，一头有一踏板，另一头是食物的出口和食槽。两头猪要想进食，先要跑到猪圈另一端踩下踏板，然后再跑回这头的食槽。如果一头猪跑过去踩踏板，那么另一头猪就可以等在这头坐享其成；如果两头猪同时跑过去踩踏板，那么大猪吃的就较多，而小猪吃的就较少；如果两头猪都不动，那就都吃不到。我们假设：猪每踩一下踏板，另一边就会有相当于10份的猪食进槽，但是踩踏板以后跑到食槽加起来要消耗相当于2份的猪食。如果两只猪同时踩踏板，同时跑向食槽，大猪能吃到7份，净收益5份；小猪能吃到3份，净收益1份。如果大猪踩踏板后跑向食槽，而小猪等在食槽边，可以吃到4份（小猪的食量最多吃这么多），净收益4份；大猪吃到6份，净收益4份。如果大猪等在食槽边，小猪去踩踏板，那么大猪可以吃到9份，净收益9份；小猪只能吃到1份，但要付出相当于2份猪食的体力，净收益负1份。如果双方都懒得动，那么所得都是0；

我们先来看小猪，它如果跑去踩踏板，最多只能吃到3份；不踩踏板，反而有可能吃到4份。因此，对小猪来说，最佳的选择就是舒舒服服地等在食槽边。反观大猪，由于小猪有“等待”这个优势策略，大猪只剩下了两个选择：要么等待，1份也吃不到；要么乖乖踩踏板，可以吃到4份。所以，“等待”就变成了大猪的劣势策略。当大猪知道小猪是不会去踩踏板时，心想去踩踏板总比不踩强吧，所以只好为了一点残羹不知疲倦地奔忙于踏板和食槽之间，也就是他不得不在这一套规则框架下作出确定性选择；这其实就是带有制衡性质的规则的一种，终归是需要让运行在规则里的角色具备原动力才是可运行的。（因为规则是要运行在人群上的，所以我们必须要考虑人的思维的充分复杂性，智猪博弈是一种非零和博弈。在这种博弈中，两个玩家的收益是相互影响的，即一方的收益增加会导致另一方的收益减少。因此，每个玩家的策略和行为都需要谨慎考虑，以确保自己获得最大的收益。从心理学的角度来看，智猪博弈是一种充满挑战和压力的情境。在这种情境下，每个玩家都需要保持冷静和理智，以避免被对方的行为所影响。此外，每个玩家还需要考虑对方的心理状态和行为模式，以便更好地预测对方的行动。从收益最大化的角度来看，智猪博弈是一种充满竞争和合作的情境。在这种情境下，每个玩家都需要在竞争和合作之间取得平衡，以获得最大的利益）。

除了制衡，更重要的是基于规则的协作，《博弈论》里面有另一个很好的案例与此有关，就是囚徒困境，时间有限就不细说，感兴趣的同学可以下来了解。

认知篇：高可用难的不是技术

最后一部分是认知篇，也就是回应分享开始提到的高可用难的不是技术，那是什么呢？

引入：中国的经典著作《孙子兵法》中说：古之所谓善战者，胜于易胜者也。故善战者之胜也，无奇胜，无智名，无勇功。曹操看后批注：善战者无赫赫之功。从字面意思我们可理解为：真正会打仗的人，一般都不怎么出名，因为赢得都太容易。真正善战的人，都是准备充分，按部就班，打的仗也不精彩，甚至是打之前就已经确定了必赢，所以没有什么故事可讲，自然也就出不了名；善战者无赫赫之功下一句就是：善医者无煌煌之名，就好比我们的中医，最牛的是治未病，但是好像没有发生过一样，病人也不买账，历史上这类例子非常多啊，随便举一个：唐卫国公李靖,灭亡了四大强权势力,为大唐扩充疆域数万里.但是有的史评认为他战功可疑,因为所有对手总是还没站稳脚跟就被打得屁滚尿流,完全太弱了，很多战役没杀几个人就结束了.有的史评描述说把李靖的位置换个猴子指挥也不会输。那可以避免打仗，对手没准备好，看起来仗打的不艰苦卓绝，没有血流成河的自我感动的过程，背后原因是什么呢？换个猴子相同的战场还会是这样的局面么？

我们《技术篇》里提到的这些，是不是在很多故障复盘的改进措施里，都会重复看到上面的影子，说明其实指导思想、解决方案是不缺的，那到底缺的是什么呢？技术上真的没有那么的难，想当年淘宝稳定性很差的某一年，新任CTO上来后把稳定性列在了第一考核指标，三个月后淘宝的稳定性就提升了N个档次。但难就难在没有银弹，只能靠大量的细节来落地做好稳定性这个系统工程的事情，这意味着的是大量的投入，能不能在稳定性这件事上保持持续的一定的投入，甚至当成做业务功能实现一样的必须的投入，这才是真正做好稳定性最难的，毕竟就算有指导思想、解决方案和技术能力，但没有相应的投入，那自然会默默埋下一些隐患，最终呢，债总还是要还的。很多做过稳定性这事的人都知道，做这个事情最麻烦的是很难被认可，做的好，不出问题，不懂的人不知道你做了什么，出了问题的时候会问你之前干啥来着，所以会看到很多公司都是运动式的做稳定性，一阵一阵的。所以高可用工程一方面需要工程师们的技术素养，一方面也需要群体认知与文化土壤；
避免谈“锅”色变的工程师文化：架构设计有一个我觉得很正确的话就是“困难守恒定律”，我们在做需求的时候时间紧任务重，缺少加固，考虑稳定性因素不足，只要速度而绕过一些问题，而事后再做架构提升又往往难以说明亮点，但是问题不会因为绕过/回避而消失，不会因为我不解决而不需要解决，或早或晚，越早消除其实成本越低。谷歌最早在 2003 年就提出了 SRE（Site Reliability Engineering，站点可靠性工程）概念，经过 20 年发展，SRE已经发展为一个体系化的工程。这里面有一句话很经典：“系统正常，只是该系统无数异常情况下的一种特例。故障是不可避免的，不管是再牛的系统、再知名的科技公司”。最近关注到谷歌 SRE 工程师 Michelle Brush 在 InfoQ 英文站发表视频演讲，分享了谷歌 SRE 工程的关键策略——反“背锅”文化。Brush 认为，反“背锅”文化并不是完全对个人无问责，而是构建一种持续改进的文化，并赋予人们权力，创建一种能让正确行为持续发生的环境。这句话是我翻译的有点拗口，其实就是问责只是说明职责在谁，而不一定和处罚挂钩，当然不是说一定不需要处罚，而是不应该让工程师形成有问题就面临斥责或处罚的这样的条件反射，损伤工程师的积极性远比问题本身对公司伤害更大更深远，所以营造积极健康的工程师文化是优秀架构与高可用工程的隐形保障。
以上就是今天的分享内容，包含了技术、思维与认知，信息量较大，希望大家有所收获。