CDN是什么CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输得更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。简单地说，内容分发网络是一个经策略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内容管理4个要求，而内容管理和全局的网络流量管理是CDN的核心所在。通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务。DNS是什么域名系统（英文：Domain Name System，缩写：DNS）是互联网的一项服务，是Internet上解决网上机器命名的一种系统，它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用UDP端口53。当前，对于每一级域名长度的限制是63个字符，域名总长度则不能超过253个字符。就像拜访朋友要先知道别人家怎么走一样，Internet上当一台主机要访问另外一台主机时，必须首先获知其地址，TCP/IP中的IP地址是由四段以“.”分开的数字组成(此处以IPv4的地址为例，IPv6的地址同理)，记起来不如名字那么方便，所以，就采用了域名系统来管理名字和IP的对应关系。虽然因特网上的节点都可以用IP地址标识，并且可以通过IP地址被访问，但即使是将32位的二进制IP地址写成4个0～255的十位数形式，也依然太长、太难记。因此，人们发明了域名(Domain Name)，域名可将一个IP地址关联到一组有意义的字符上去。用户访问一个网站的时候，既可以输入该网站的IP地址，也可以输入其域名，对访问而言，两者是等价的。一个公司的Web网站可看作是它在网上的门户，而域名就相当于其门牌地址，通常域名都使用该公司的名称或简称。一句话简述：DNS调度是CDN常见的调度方式之一。ADN是什么应用交付网络（Application Delivery Network，简称ADN），它利用相应的网络优化/加速设备，确保用户的业务应用能够快速、安全、可靠地交付给内部员工和外部服务群。从定义中可以看出应用交付的宗旨是保证企业关键业务的可靠性、可用性与安全性。应用交付应是多种技术的殊途同归，比如广域网加速、负载均衡、Web应用防火墙…针对不同的应用需求有不同的产品依托和侧重。ADC是传统的网络负载均衡的升级、扩展，它是一种综合的交付平台设备，其综合了负载平衡、TCP优化管理、链接管理、SSL VPN、压缩优化、智能网络地址转换、高级路由、智能端口镜像等各种技术手段的综合平台。一句话简述：ADN和CDN的区别是一个是侧重于内容分发，一个侧重于应用交付。SCDN是什么SCDN（Secure Content Delivery Network），即拥有安全防护能力的CDN服务，提供稳定加速的同时，智能预判攻击行为，通过智能的调度系统将DDoS攻击请求切换至高防IP完成清洗，而真正用户的请求则正常从加速节点获取资源。加速节点的分布式架构还同时具备防CC攻击的能力，达到加速和安全兼顾。SCDN的架构与全站加速基本一致，区别就是在CDN节点不仅具有加速功能，还配有防火墙，所有请求都是发到CDN节点，这样的好处第一隐藏了源站服务器IP，让攻击者不能直接攻击源站，第二因为CDN节点配有防火墙，可以抵御大部分DDOS和CC攻击。使用高抗性IP保护源站是无法兼具加速能力的，但如网络游戏、金融服务、政企安全、电子商务、医疗服务等不仅易受攻击还要兼备加速的业务场景等领域，则必须要兼备高防御能力和高效化的安全CDN服务。一句话简述：SCDN和CDN的差异在于增加了CDN的安全防护能力。DCDN是什么全站加速DCDN（Dynamic Route for Content Delivery Network）是一项根据CDN加速技术的云技术升级，明智地区分动态和静态内容的浏览。对静态內容直接使用CDN开展加速；对动态內容则开展高效回源拉取，如路由决策优化、协议优化等。全站加速DCDN不仅能提供基础的CDN静态资源加速，而且还进一步提供了动态加速、TCP和UDP四层加速、Websocket七层加速等能力，可以快速地将安全、边缘计算等能力集成到全站加速的全球节点，提升全站性能和用户体验，实现业务提效。一句话简述：DCDN和CDN的差异在于增强了动态加速功能。ECDN是什么ECDN（Enterprise Content Delivery Network）全站加速是腾讯云2019年推出的全能加速平台，由原有DSA动态加速产品升级而来.ECDN 适用于动、静态资源混合型资源的一站式加速，同一平台上可实现站内所有类型资源同时加速，自动识别动静态资源。静态资源可根据腾讯自研的GSLB系统智能分配最优服务节点；动态资源基于回源路由优化技术实现快速回源。一句话简述：ECDN还是普通CDN技术，和DCDN的基本逻辑差不多，无非腾讯给他命名方式和其他家不一样。什么是PCDNPCDN的英文全称是P2P CDN，中文名叫P2P内容分发网络，是以P2P技术为基础，通过挖掘利用边缘网络海量碎片化闲置资源而构建的低成本高品质内容分发网络服务。你可以通过集成PCDN SDK（以下简称SDK）接入该服务后能获得等同（或略高于）CDN的分发质量，同时显著降低分发成本。客户通过集成 PCDN SDK（以下简称 SDK）接入该服务后能获得等同（或略高于）CDN 的分发质量，同时显著降低分发成本。适用于视频点播、直播、大文件下载等业务场景。一句话简述：PCDN=P2P+CDN的融合体。什么是融合CDN融合CDN是在传统CDN基础上，通过技术手段融合各主流CDN厂商的优质节点，以实现全业务处理能力的智能调度加速管理服务。融合CDN打破了单个CDN厂商的节点资源以及调度能力有限的困境，突破了地域时间以及不同运营商的限制，通过强大的智能调度策略来综合利用上述资源来解决实际场景中的问题，可以带来更加优质的服务效果、更加稳定的质量和相对降低的服务成本。一句话简述：融合CDN=多接入几家CDN，采用智能监控，哪家加速效果好用哪个。
前言供应链、CRM、CMS、ERP 、SAP这几个词，大部分人都会觉得很陌生，行业内人了解它们却不清楚，CRM、CMS、ERP、SAP这些究竟是什么意思？有什么区别？它们用在什么地方？都是怎么运作的？{card-describe title="生活中的例子"}网上购物对于我们来说，看到心仪的产品，下单即可，非常简单。但其实从你浏览商品并下单开始，就有一系列复杂的流程在背后悄然运行。这个小小的购物行为，实际上涉及到了多个关键的业务环节和系统。如果这些环节中的任何一个出现问题，都可能导致你的购物体验大打折扣。例如：内容管理系统（CMS）的不完善可能会导致产品信息不准确或不吸引人，影响你的购买决策。供应链的不畅可能会使你心仪的产品缺货，延迟发货，让你焦急地等待。如果企业没有一个有效的客户关系管理系统（CRM），可能无法及时了解你的需求和反馈，无法为你提供个性化的服务，甚至可能因为客户服务不到位而失去你的信任。企业资源计划系统（ERP）和知名的企业管理软件SAP，则在企业的内部运营管理中起着举足轻重的作用。{/card-describe}供应链供应链是围绕核心企业，通过对信息流、物流、资金流的控制，从采购原材料开始，制成中间产品以及最终产品，最后由销售网络把产品送到消费者手中的、将供应商、制造商、分销商、零售商——直到最终用户连成一个整体的功能网链结构。例如，一家电子产品制造企业的供应链，包括从原材料供应商处采购芯片、显示屏等零部件——将这些零部件运输到工厂进行生产加工——把成品通过分销商销售给零售商——最终到达消费者手中的一系列过程。在这个供应链体系中，会涉及到原材料的采购管理、生产计划与调度、物流运输、库存管理等多个环节。CRMCRM （Customer Relationship Management，客户关系管理）是一种用于管理企业与客户之间关系的策略和技术。它的主要功能包括客户信息管理、销售管理、市场营销、客户服务等。例如，通过 CRM 系统记录客户的购买历史、偏好、联系方式等信息，这叫客户信息管理。通过客户分析，可以更好得了解客户需求，在客户下次购物时，根据这些信息为其推荐个性化的商品，优化市场营销效果，这叫用户画像管理。同时，当客户有问题咨询时，客服人员可以通过CRM系统快速了解客户的情况，提供更高效的服务，这叫客户跟进管理。销售人员可以利用CRM系统跟踪销售机会、管理客户订单，提高销售效率，这叫销售管理。{card-default label="CRM" width="85%"}{/card-default}CMSCMS （Content Management System，内容管理系统）是一种用于创建、管理和发布数字内容的软件系统。它可以帮助企业或个人轻松地创建和维护网站、博客、电子商务平台等各种在线平台的内容。编辑人员可以在 CMS 中进行内容的编辑、排版、审核等操作，内容形式多样，支持文章、图片、视频等。内容生产者将内容发布上传到网站知识库中，供知识库成员共同查阅。CMS 还可以管理用户权限，例如拥有不同等级权限的编辑人员可以依照权限对内容进行发布、修改或删除操作。ERPERP （Enterprise Resource Planning，企业资源计划）是一种集成化的企业管理软件系统，它整合了企业内部的各个业务流程和资源，包括财务管理、人力资源管理、采购管理、生产管理、销售管理、库存管理等。例如，通过MRP物料需求，APS手工排产实现生产计划统计，这是计划管理。监测采购流，对采购订单执行跟踪，进行采购经营分析、产品采购需求预测，这是采购管理。通过生产流、生产工单实现生产执行跟踪，进行生产用料统计，这是生产管理。对销售订单执行跟踪，精细化销售出库管理，销售经营分析，这是销售管理。将仓储流可视化，监测实时库存、库存期初期末情况，通过设置安全库存实现库存预警，这是库存管理。财务部门可以通过 ERP 系统实时了解企业的收支情况，这是财务管理。SAP不同于上面的CRM、CMS或是ERP，SAP并不是什么概念的缩写，而是一家知名的企业资源管理系统软件提供商，也就是一家专门做上述CRM/CMS/ERP软件系统的公司，因为其软件系统产品涵盖了ERP、CRM、供应链管理等多个领域，非常有名，常常让大家误以为它也是某个概念的缩写。SAP 的软件具有功能强大、集成性高、可扩展性强等特点，可以支持多语言、多货币、多国家的法律法规等复杂的业务环境，被广泛应用于各个行业的大型跨国企业中。
围绕故障管理谈SRE体系建设学习总结
前言SRE是一个体系化的工程，SRE体系的建设涉及的内容繁多，比如日常需求处理、容量规划、资源部署、监控告警、预案梳理、灾备演练、OnCall值班、应急事件响应、故障处理、运维自动化建设等。故障是众多事项的一个交汇点。{card-describe title="故障考验"}SRE团队的响应速度对服务的掌控能力监控告警的覆盖是否完整配置是否合理灾备预案的体系是否完善是否充分的做了灾备演练应急预案是否有效{/card-describe}SRE的工作职责{card-default label="SRE的工作职责" width="75%"}{/card-default}{message type="success" content="核心目标：稳定性、效率和成本。"/}{callout color="#4def93"}稳定性是核心职责，这是SRE区别于SA、OP、PE的点。通过建设工具、平台、基础设施的建设来提高效率成本连同效率就是降本增效。{/callout}稳定性建设{card-default label="稳定经建设" width="80%"}{/card-default}{callout color="#bcef4d"}什么是稳定性如何度量稳定性如何设置稳定性目标如何提升稳定性{/callout}度量稳定性{message type="success" content="如果你不能度量它，你就无法改进它。--彼得.德鲁克"/}在业界我们通常用MTBF和MTTR这两个关键指标来衡量稳定性，这两个指标分别是「平均故障时间间隔」(Mean Time Between Failure)、「平均故障修复时间」(Mean Time To Repair)。{message type="warning" content="服务状态可以分为"正常态"和"异常态""/}{card-default label="严格定义" width="85%"}{/card-default}{card-describe title="计算公式"}几个关键的时间点：故障维修结束：上一次故障恢复结束的时间；故障开始：故障开始发生的时间；故障维修开始：开始介入故障，开始处理的时间。根据上面这几个时间点就把时间划分为了几个时间段：维修结束 -> 故障开始：T1故障开始 -> 维修开始：T2维修开始 -> 维修结束：T3其中T1的平均值为「平均无故障时间」，MTTF(Mean Time To Failure)T2+T3的平均值为「平均修复时间」，MTTR(Mean Time To Repair)T1+T2+T3的平均值为「平均故障间隔」，MTBF(Mean Time Between Failure){/card-describe}{message type="error" content="MTBF = MTTF + MTTR，因为MTTR通常远小于MTTF，所以MTBF近似等于MTTF；因此我们平时常用的衡量指标就是MTBF和MTTR。"/}设定稳定性目标提高MTBF，降低MTTR{message type="success" content="MTBF的提升可以看作是众多稳定性建设工作的一个结果（稳定）状态，MTTR则是我们对故障的应急处理、恢复服务的过程，是一个集中检验我们稳定性建设水平的过程。"/}{card-default label="MTTR拆解" width="75%"}{/card-default}{card-describe title="MTTI"} MTTI(Mean Time To Identify，平均故障发现时间)：指的是从故障实际发生，到我们真正开始感知、识别、响应的时间。这个过程最长见的渠道可能是服务监控告警、常规巡检、用户或者同事反馈，也可能是舆情监控等。{/card-describe}{card-describe title="MTTK"} MTTK(Mean Time To Know，平均故障认知时间)：也就是我们常说的平均故障定位时间。{/card-describe}{card-describe title="MTTF"} MTTF(Mean Time To Fix，平均故障恢复(解决)时间)：这个时间指从我们定位到故障的原因到我们采取措施恢复业务为止。这里采用的方式可能有很多：故障隔离、容灾切换、限流、降级、熔断等，甚至是重启服务。{/card-describe}{card-describe title="MTTV"} MTTV(Mean Time To Verify，平均故障修复验证时间)：即故障解决之后，我们用来验证服务是否真正恢复的时间。{/card-describe}{card-default label="目标" width="75%"}{/card-default}提升稳定性MTTR的指标被细化之后，我们的目标也就变成了降低这些细化之后的指标；我们可以分而治之、各个击破。{card-default label="提升稳定性" width="75%"}{/card-default}{callout color="#ef4d5d"}MTTI阶段多管齐下；尽可能用更多的手段来覆盖可以发现、暴露问题的通道，包括完善监控的覆盖，建设体系化的监控系统。MTTK阶段工具赋能；这个过程中需要更多的借助工具、平台的能力，建设健全运维系统，比如监控平台、日志平台、链路跟踪平台等，如果能力允许也可以去尝试建设“根因自动定位”系统。MTTF阶段完备预案、一键应急、紧密协作；这个是在故障处理过程中最核心的部分，是真正可以让服务恢复正常的阶段；这个过程有比较多的前置依赖，也就是需要我们在平时做好储备的，比如建立健全预案体系，将预案的执行手段尽可能沉淀到工具平台中，尽可能做到一键直达，缩短预案执行的路径。其次这个过程中可能还会涉及到部门内部、部门之间的协作，尤其是在处理重大故障的场景；这时候就需要有一套可以让大家紧密协作的流程或共识，让大家可以信息互通、各司其职、有条不紊。MTTV阶段自动校验；这个过程也是需要尽可能依赖自动化的手段去做。{/callout}{card-default label="全景图" width="75%"}{/card-default}{card-describe title="SRE阶段职责"}Pre-MTBF预案建设、灾备演练、OnCall值守等；MTTR应急响应；Post-MTBF故障复盘、故障改进、OnCall值守等。{/card-describe}{message type="error" content="整个过程归纳：故障预防 -> 故障发现 -> 故障定位 -> 故障恢复 -> 故障改进"/}{callout color="#f0ad4e"} 夸张一点讲，我们做的所有稳定性建设都是为「故障」服务的，SRE的稳定性建设都必须围绕“提高MTBF”和“降低MTTR”这两个目标展开。{/callout}{callout color="#4d68ef"} 「故障」其实是服务运行中的一个常态，是无法完全避免的；因此我们需要用一个积极的心态，至少是一颗平常心来看待故障，不能惧怕故障，更不要谈之色变；只有我们正视故障，分析并改进才有更可能在未来去规避它；这就需要我们辩证的看待故障，我们需要尽可能从故障中汲取正向的意义，建议把关注点聚焦在「改进」上，而不是「处罚」。{/callout}故障管理故障管理分为故障前、故障中和故障后，在每个环节都有一些核心的工作内容和目标。{card-default label="三段式分解" width="75%"}{/card-default}{callout color="#e54def"}故障前故障预防、灾备预案；目标是尽可能地做足准备工作，毕竟有背方可无患；故障中发现、定位、解决故障；目标是尽可能的提高效率，缩短故障恢复的时间；故障后故障复盘、故障改进；目标是尽可能多的从故障中吸取教训，反思和学习，完善和修复故障中暴露出来的问题。{/callout}故障前关键内容：监控覆盖、架构设计、容量评估、灾备预案、灾备演练、还有持续交付。{card-default label="故障前" width="75%"}{/card-default}监控覆盖的话比较容易理解，服务上线后，只有拥有足够的监控手段，并且尽可能多的覆盖服务的各个环节，才有可能在后面发生问题的时候，快速的感知到。{card-default label="监控体系" width="75%"}{/card-default}{message type="error" content="主要分为客户端质量监控和服务端质量监控。"/}{card-describe title="客户端质量监控"} 在移动互联网兴起之前，大部分的监控产品、监控思路都是集中在服务端的。客户端质量监控我们都使用了哪些手段呢？常规的有一些第三方的拨测、第三方的APM。除了一些商用的产品，当然也有一些免费的工具是可以用的。应对一些流媒体的应用，我们自研了一套融合CDN的监控还有流媒体的监控。这个其实也比较关键，因为现在业务体量大了之后，CDN是不可避免的会用到，但如果没有这部分监控的话，CDN质量就要依赖于用户反馈，链路就会比较长。{/card-describe}{card-describe title="服务端质量监控"}服务端的质量体系是用到了一些比较通用的，像InfluxDB套件、ELK、Prometheus、Open-Falcon、Zabbix。{/card-describe}{card-default label="基础监控" width="75%"}{/card-default}{card-default label="SLA" width="75%"}{/card-default}{card-default label="日志报表" width="75%"}{/card-default}{card-default label="客户端监控" width="75%"}{/card-default}架构设计 架构设计可能会更偏业务侧一些。我们在故障之前，要尽可能做好服务的架构设计，同时在做一些预案之前，也要把服务架构做好梳理。只有当我们把服务的架构了然于胸，才更有可能在故障发生的时候从容不迫，更好地定位问题。 要更多去加入柔性设计，也就是说你的服务要具备一些像降级熔断、故障隔离这些手段，要有这样的柔性设计在里边。这样架构可以提供这些能力，后面才能更好地去做服务的保障。 再有一点就是，要尽可能的去规避常规的风险点，比如说单点之类的；同时还要尽可能地去规避架构里面常见的坑。{card-default label="架构设计/梳理" width="75%"}{/card-default}容量评估 容量评估其实就是我们的服务在上线之前，要去对服务的承载能力做一个压测，这样我们才能更好的了解服务上线之后的状态。然后我们基于这个，再根据业务方量级的评估，去规划服务的容量。 容量评估其实是不能完全依赖于压测的。在压缩之前，要基于我们对自己服务的理解，包括每一条请求大概会耗费多少资源等，要有一个基础的认识，再基于这些认识去评估大概需要用多少后端资源、大概会用多少CPU内存，这些东西是可以用数学计算的方法来计算出来的。{card-default label="容量评估" width="75%"}{/card-default}灾备预案和灾备演练 这两点是比较关键的，跟故障会更强相关。{card-default label="灾备预案/演练" width="75%"}{/card-default}{callout color="#dd4def"}服务梳理在服务梳理阶段，要基于前面的架构图等来梳理请求链路，要分段分层地梳理请求都经历了哪些层次、有哪些阶段、经过了哪些设备、周边有哪些依赖（包括内部的服务依赖、后端的资源依赖、第三方的依赖等），然后还要梳理架构目前是不是有什么风险、流量有没有经过一个单点、有没有哪个点可能是存在瓶颈的……这些都是我们在服务梳理阶段需要去梳理清楚的。预案梳理了解各种情况后，就可以梳理相应的预案了。仔细分析应该用什么样的手段来覆盖，将风险各个击破；然后要尽可能地做多级预案，因为预案如果只有一级的话，容灾能力是不够柔性的；此外，还要借助到一些智能调度的手段；最后就是柔性设计，前面也有提到，是更偏业务侧一些，也就是说在服务里要有尽可能多的手段来做自己的一些failover，可以去做一些降级、熔断等。沙盘推演梳理出来预案后，并不是直接到做演练。要了解预案是不是真的有效，不是直接做演练，而应该是先想清楚。我的建议是去做沙盘推演。在这个过程里，我们要尽可能去发动多的部门协作起来，来看我们的预案是不是有效。毕竟人多力量大，并且不同团队的人对业务可能有不同的理解，在这种头脑风暴下，就有可能碰撞出更多的可能性。然后在这个过程里，会基于一些可能的故障场景、case等来做推演，当故障场景A出现了，梳理出了预案A’，那 A’能不能把故障A完全解决掉？在解决故障场景的时候，有没有引入一些其他的风险点或问题？在这个过程里面，我们都要想清楚，当得出一个大家都认可的推演结果后，预案才推演完了。预案落地这一步是需要做落地，包括文档输出、功能实现、架构适配、工具建设。预案演练落地之后，要通过演练的方法来验证预案是不是真的有效。无损演练和轻损演练：我们做故障演练要尽可能地做到对业务无损，但有些预案本身应对的故障场景就是会损害业务的，那这种时候我们要尽可能降低这种演练带来的损失，比如说选不同的时间段、流量的控制、灰度之类的，尽量去做轻损的演练，既然我们是通过故障演练的方式来确保预案有效，那肯定不能因为故障演练而演练出一个大的故障，这就有些得不偿失了；还有就是单点演练跟组合演练：你的演练到底是要一次演练某个模块，还是说要把一个大故障场景里所有涉及的点都演练一遍？这个也是我们在预案演练里需要考虑的。{/callout}持续交付{card-default label="持续交付" width="75%"}{/card-default}故障中故障真的发生了？去发现定位和恢复。核心手段：：监控告警、日志分析、链路跟踪、故障隔离、容灾切换、降级熔断。{card-default label="故障中" width="75%"}{/card-default}{card-default label="监控告警" width="75%"}{/card-default}{callout color="#ef4d75"} 对比前面这两张文字图，文字图只是告知流量突降30%，这是一种告警方式。中间的图就是由名为“监控大盘”的机器人发送出来的，也是我们服务的架构图。放大图看，我们的业务模块、交互链路已经暴露出来了；图中有一块是红色的，红色代表标识异常，与异常关联的某个组件就变成淡绿色。由于红色这块故障引发了另外一个异常，接连引发了一个又一个的异常。通过这张告警图，收获了更多的信息：首先知道系统挂了，或者系统异常了，然后这次异常大概是由什么引起的。一张图就可以让你非常快速地感知。{/callout}{message type="success" content="实现：基于grafana的插件flowcharting基于draw.io的一个绘图，结合我们的数据填充和告警配置来实现的。"/}{card-default label="日志分析" width="75%"}{/card-default}{card-default label="链路跟踪" width="75%"}{/card-default}{card-default label="链路跟踪" width="75%"}{/card-default}日志分析、链路跟踪、预案执行都是定位手段，在已经定位问题之后，并且匹配了相应的预案，要求去执行预案。当然前提是有相应的预案应对故障场景。然后依据操作手册，分别按不同的故障层次去执行处理。{card-default label="恢复结果确认" width="75%"}{/card-default}恢复之后还要确认执行结果，看服务是否恢复正常。故障后在故障后，我们应该做好以下环节：故障复盘、故障改进、预案完善、容量压测、故障模拟、周边清查。{card-default label="故障后" width="75%"}{/card-default}{callout color="#ef4d8e"}预案完善故障发生之前有做过预案，这些预案是不是完善的？在故障处理的过程中，有没有暴露出问题？是否要完善之前的预案中做的不完善的地方等等；故障模拟意思是用某种手段模拟某些故障，提前知道该如何解决这些问题；周边清查应该具备举一反三的能力，比如A服务出故障，那么A服务周边有一些相关联的服务有可能会受到影响。举个例子，比如集群里面有N台机器，收到机器A磁盘接近100%的一条告警，只需处理机器A就可以了吗？当然不是，在处理完该异常之后，肯定要查看同集群的其他机器是否存在类似情况。{/callout}{card-default label="故障复盘-关键时间线回顾" width="80%"}{/card-default}{card-describe title="故障复盘"} 在故障复盘阶段，最核心的思想就是要回顾关键的时间点：故障是从什么时间发生的？从什么时间到什么时间结束的？在这过程里面有哪些非常关键的操作？有哪些关键的信息？从什么时间点定位到问题？在什么时候执行怎样的操作？这些时间点都是非常重要的。在故障复盘的过程中，要把这些操作的时间点一一还原回去，才能完整地回看操作是否合理有效。{/card-describe}{message type="warning" content="我们应该怎么做，才能更快地恢复业务？我们应该怎么做，才能避免再次出现类似问题？我们有哪些好的经验可以总结、提炼，并固化？"/}{card-default label="故障报告" width="75%"}{/card-default}{callout color="#ef4dda"} 故障解决后绕不开的一点，在故障发生后都会做一个报告，上图就是一个故障报告模板。在报告里面写清楚故障级别、责任人、处理过程、改进措施，将这些关键点归纳成故障报告的文档。到此做个总结，故障本质上是持续迭代的，当故障发生了，开始恢复、复盘、改进、验收，回到稳定运行的状态，再过一段时间又出现故障。同时，服务也持续地迭代，因此要不断去提升稳定性，这是我们都逃不出的一环。{/callout}{card-default label="持续迭代" width="75%"}{/card-default}故障管理体系做好故障管理，需要建设一些SRE体系提供支撑。{card-default label="管理体系" width="75%"}{/card-default}可用性体系SLI是指标，SLO是目标，SLA是我们的目标加上目标未达成的后果{card-describe title="SLA"} 通常运用在双方一些商务合约上，例如使用某云厂商的服务，对方承诺可用性不低于99.95%。一旦没有达到我的要求，处罚性的或者赔偿性的一些条款将会生效，这才是真正意义上的SLA。{/card-describe}{card-default label="可用性体系" width="75%"}{/card-default}{card-describe title="SLI的选择"}容量（Volume）服务承诺的最大容量是多少，从QPS、TPS、流量、连接数、吞吐思考；可用性（Availability）服务是否正常，看HTTP状态码2xx的占比；延迟（Latency）服务响应速度是否够快，rt是否在预期范围内；错误率（Errors）错误率有多少，看HTTP状态码5xx的占比；人工介入（Tickets）是否需要人工介入处理，考虑人工修复。{/card-describe}故障定级、定性、定责定级通用标准{card-default label="通用标准" width="75%"}{/card-default}定级个性化标准除了通用标准，还有一些没有被囊括到体系中来，比如某些电商类、商业化、广告类和金融类的业务，有可能造成资产损失，那么不同的部门会有不同的故障管理的定级策略。{card-default label="个性化标准" width="75%"}{/card-default}定性有效分类{card-describe title="定性有效分类"}{/card-describe}{callout color="#f0ad4e"}故障定性的一些有效分类，即定性故障是由什么原因引起的。是代码质量、测试质量、流程规范出了问题，还是变更操作不够规范呢？还有其他种种原因，我们要对故障做定性的分析和归类。{/callout}定责：判定原则定责任并不意味着处罚。我们整体的故障管理从原则上来说尽量不指责，但不指责不代表着可以持续犯错误。{card-default label="判定原则" width="75%"}{/card-default}{callout color="#ef4d93"}高压线原则：不能犯一些低级的错误；不能持续犯某些错误；上下游原则：根据服务的上下游依赖程度去做判断；健壮性原则：根据服务的健壮性定性。例如服务A挂掉导致服务B出问题，这时候责任不能完全划分到服务A上，还要考虑到服务B本身的健壮性；第三方默认无责：内部做故障定位时，默认第三方无责，当然该追责的还是会追责。{/callout}错误预算SRE里经常听到错误预算，如何做到实际落地？前面讲了故障的定级规则，明确定级规则之后，不同的故障被定为ABC级，按对应计分标准扣分。扣的分数来源于给出的预算。我们每半年为一个OKR考核周期，在一个考核周期里面每个BU会分到一定的故障分，允许在考核周期里由于故障被扣分，如果分数扣完了意味着错误预算用完了。{card-default label="错误预算" width="75%"}{/card-default}组织结构支撑{card-default label="结构支撑" width="75%"}{/card-default}{callout color="#ef4dd2"}故障管理特别依赖于组织结构的支撑，因为故障管理不仅仅是运营部门或者技术保障部门能单独完成的事情，需要不同团队协作。故障委员会是一个虚拟的组织，不是一个实体的组织，由BU接口人负责故障委员会故障判定和定责之类的事情、传达信息给BU内部。当故障发生了，基于判定规则给故障定级、定责。定级意味着每个级别产生对应的故障分；定责会涉及到故障的拆分，比如发生了一个故障，它由A、B两个部门共同承担。根据定责发现责任上A、B部门实际是五五开，因此A、B平分故障分，再从A、B部门的BU负责人各自的错误预算里扣除故障分。通过这种方式就能约束好BU吗？当然不是，要用行政手段来保障，那就是OKR。周期OKR里需要有服务稳定性的目标项才行，把服务稳定性写进OKR后，BU出于压力而去共同做好故障管理。在上述这种组织支撑的情况下，才能更好地推行故障管理。{/callout}SRE体系建设{card-default label="全景图" width="75%"}{/card-default}稳定性建设按照 MTBF和MTTR，把日常时间分成几段，不同时段里要做哪些事情？先是建设演练、Oncall值班，然后应急响应，最后复盘改进、再Oncall。在一个循环里面完成了SRE的工作。PPTV即PPT+V。PPT包涵了人员、流程、技术，是ITIL中的IT管理的三要素。SRE体系建设同样无法脱离这个模型，做好故障管理要有一个合适的组织结构、流程流程保障。未来展望AIOps和混沌工程Chaos Engineering
面向故障处理的可观测性体系建设学习总结
前言本文是作者关于可观测性的理解和实践。主要内容有可观测性在整个商业体系中的位置和价值如何快速发现故障，使用哪类指标告警SRE 在谈论故障定位的时候，谈的是什么如何找到故障直接原因，找到止损依据如何让可观测性系统呈现观点，辅助洞察，定位故障可观测性的价值一个事情，价值太小就不值得投入。{card-describe title="好产品的体验"}产品体验包括功能体验和可靠性体验。功能体验依赖产品设计和迭代速度。可靠性体验追求高可用、低延迟{/card-describe}{card-default label="产品体验" width="75%"}{/card-default}{message type="success" content="如何提升可靠性体验呢？持续优化架构和性能。降低故障发生的频率，降低故障的范围影响，降低故障的恢复时间。"/}{card-default label="故障生命周期图" width="90%"}{/card-default}{card-describe title="三个阶段"}事前：及时发现风险，做好架构、预案和演练事中：及时发现故障，及时定位，及时止损事后：排查根因，落实复盘改进项{/card-describe}可观测性在整个过程中的职能在哪个环节发挥价值。{card-default label="环节" width="80%"}{/card-default}{message type="success" content="可观测性，是在故障发现、定位环节发挥作用的，核心价值就是帮我们快速发现故障、快速定位故障，进而降低故障的影响。"/}{card-default label="可观测性的价值" width="90%"}{/card-default}客户/用户需要好的产品体验，好的产品体验包括可靠性体验，要想有好的可靠性体验，就得减少故障，所谓的降发生、降影响，而这，又依赖了可观测性的能力。所以：可观测性最终是服务于产品体验、服务于商业成功的。核心目标是快速发现、定位故障。如何快速发现故障先定义什么是故障？产品体验受损。电商产品：用户无法下单、无法支付、无法查看商品、无法查看历史订单存储系统：用户无法读、无法写、或者读写延迟过高流媒体产品：无法开启播放、无法拉流、无法浏览视频信息定义产品体验受损电商产品：订单量、支付量、商品/订单访问成功率/延迟存储系统：读/写成功率、读/写延迟流媒体产品：播放量和成功率、拉流延迟、视频浏览成功率/延迟等{message type="success" content="业务指标和SLO指标"/}SLO指标正常的时候，业务指标未必正常。一定要重视业务指标体系的构建和监控。{callout color="#f0ad4e"}业务指标和BI数据的区别。BI数据对准确性要求很高，实时性要求不高。业务指标对准确性要求没有那么高，只要能发现数据趋势即可，对实时性要求很高。{/callout}{message type="success" content="产品的核心业务功能是可枚举的，每个功能对应的结果类指标就是可枚举的，做好结果类指标的告警，就可以保证告警是全的，做到有故障必有告警！"/}{card-default label="结果指标" width="90%"}{/card-default}{callout color="#f0ad4e"}要构建可观测性体系，首先要建立完备的指标体系，其中非常关键的是结果类指标，即业务指标和 SLO 指标，结果类指标配合告警系统可以快速发现故障！从这里也可以看出，监控（monitoring）和可观测性（observability）是相辅相成的，非替代关系。{/callout}SRE谈故障定位数据->特征->观点->洞察{card-default label="信息层级" width="85%"}{/card-default}故障原因五花八门 故障可能是电源模块坏了、机房空调坏了、机柜压住网线了、供电不稳、某个盘故障了、中间件配置错了、被黑客攻击了、分布式中间件脑裂了、写日志hang住了、程序配置错了、程序连接第三方的地址错配成线下地址了、DNS配错了、证书过期了、代码Bug了、疏漏了某个罕见用户流程{message type="success" content="当 SRE 在谈论故障定位的时候，其实谈论的时是如何找到直接原因，尽快止损。而根因，可以留在复盘阶段慢慢找。"/}如何找到故障的直接原因{card-default label="服务依赖图" width="90%"}{/card-default}首先，依赖的基础设施（基础网络、硬件、Runtime环境）不能出问题，依赖的第三方其他服务不能出问题{card-default label="可观测性数据底座" width="90%"}{/card-default}{callout color="#4d8bef"}要建立 metrics、logs、traces、events？是的，但不仅是，只有数据还远远不够，我们需要通过平台工具，通过数据运营整理，帮助用户找到数据特征，建立初步观点，最终形成洞察定位故障直接原因。{/callout}具体要如何做可观测性体系还需要利用平台能力、通过数据运营整理，呈现数据特征、帮用户建立初步观点，最终形成洞察，定位故障直接原因。可观测性体系要告诉我故障模块技术角度来看，一般模块都是有层级关系的，首先是系统，然后是子系统，然后是模块。所以，初始页面应该展示系统的健康状况，如果某个系统有问题，应该可以点击进去查看详情（这个过程称为下钻），下钻到子系统，再下钻到模块，最终找到故障模块。{callout color="#f0ad4e"}那如何衡量一个模块是否健康呢？这其实就可以使用 SLO/SLI 这套体系，每个模块都有几个 SLI，每个 SLI 异常，这个模块就可以定义为异常，进而定义子系统异常、系统异常，这个过程也有种故障冒泡上浮的感觉。{/callout}{card-default label="灭火图" width="85%"}{/card-default}故障模块的各项依赖是否健康模块依赖的数据库、中间件、基础网络、机器硬件、第三方服务等等，都会影响模块的健康状况。所以，当模块异常的时候，我们需要知道各项依赖是否健康，如果依赖也异常，那么模块异常的直接原因基本可以断定是异常的依赖项导致的。{callout color="#f0ad4e"}要用可观测性产品建立这样的视图，核心有两点，一个是依赖的关联关系，一个是依赖项的 SLO 视图（通常体现为 metrics 仪表盘）。{/callout}{card-default label="逻辑示意图" width="85%"}{/card-default}故障是否是变更导致的线上故障，大概 70% 都是变更导致的，所以运维行业中流传一句话叫：“变更是万恶之源”。{callout color="#ef4de2"}在时间维度上做文章。把故障和变更放到一张图上，在时间维度上做对比，比如从故障时刻往前看 1 小时，看看有没有变更，如果有，那个变更很可能就是罪魁祸首。{/callout}{card-default label="变更示意图" width="85%"}{/card-default}{message type="warning" content="变更不仅仅是代码变更，还包括配置变更、机器变更、网络变更等等，变更事件收集得越全，越有价值。"/}提供工具分析数据特征提供工具帮我们分析数据特征，别让用户陷入海量散乱的可观测性 raw data 中。这需要多维分析引导能力、数据串联打通能力。{card-default label="串联" width="90%"}{/card-default}原文面向故障处理的可观测性体系建设
一、决策、信念与行为偏差这些偏差多半会影响信念的形成、商业与经济决策、以及其他一般的人类行为。它们是可复制与再现的，面临特定情境时，一般可预期人们会有相应的偏差倾向。{card-default label="决策、信念与行为偏差" width="75%"}{/card-default}1. 不明确效应我们倾向于避免未知，决策时避开资讯不足的选项，通过添加明确的细节来最大程度地减少歧义，从而提高转化率CTA 按钮应在其旁边包含信息性标签，以清除不确定性。{card-default label="示例" width="50%"}{/card-default}2. 锚定效应人类在进行决策时，会过度偏重先前取得的资讯（这称为锚点），即使这个资讯与这项决定无关。在进行决策时，人类倾向于利用此片段资讯（锚点），快速做出决定。通常被利用在消费场景中的认知偏差，通过前后对比来放大优惠感知，进而促进用户做出有利于我们的决策。{card-default label="示例" width="50%"}{/card-default}3. 注意力偏差在检查所有可能的结果时，我们倾向于关注一些看起来合理且熟悉的事物，从而忽略了其他结果。{card-default label="示例" width="50%"}{/card-default}4. 获得性启发我们认为那些迅速跃入脑海的事情比那些不容易想起的事情更为常见和重要。因此，最近发生的、频繁发生的、极端的、被记住的事情比大多数信息更有影响力。通过创建一些与众不同的东西（在不影响一致性和熟悉度的情况下）让你的设计被记住。{card-default label="示例" width="50%"}{/card-default}5. 可获性层叠这个心理效应有一个更简单的描述，叫做三人成虎，也就是一件事越常被公开谈论，人们就越相信这件事。{card-describe title="示例"} 创建一个醒目的标语，并确保重复多次。如果可能，这个标语以押韵结尾会更好。{/card-describe}6. 逆火效应我们不能轻易改变人们的信念：与根深蒂固的信念相反的证据和论据无济于事，只会巩固信念的地位。{card-describe title="示例"} 通过情感辩论来影响他人的行为，不要尝试直接改变他们的信念。{/card-describe}7. 从众效应我们经常会因为大多数人以同一种方式思考，而改变我们自己的想法。我们在设计中可以营造出一种群体选择的效果来吸引更多的用户，通过展示购买人数和滚动播放购买信息来体现出该商品的热门，让正在犹豫的用户「随大流」下单购买。{card-default label="示例" width="50%"}{/card-default}8. 信念偏差我们更倾向于接受与我们的先验知识相符的论点，而拒绝对该论点的反驳。{card-describe title="示例"} 谈论产品的好处时，不要夸大其词。如果它好到让人无法相信，那么人们将不会相信它。{/card-describe}9. 选择支持偏差做出决定后，我们倾向于称赞我们选择的选项，然后降级其他选项。在用户做出购买决定并成功达成交易之后，是用户分享产品（或添加评论）的绝佳时机；显示肯定的信息，并祝贺他们达成了这一步骤以激励用户。{card-default label="示例" width="50%"}{/card-default}10. 确认偏差当人们本来就持有某种观点时，对这种观点的感知和注意度会被放大，会选择性地回忆或收集关于它的事例。人们对于自己原本就相信的观点会更容易接受，而把反面观点搁置在一旁。在用户研究中，当你的预设想法是用户对A设计的满意度比B设计更高时，在研究中你可能会更关注用户提到的A设计的优点、收集更多用户对于A设计的正面评价。当用户表示对A设计满意时，会觉得“果然是这样”。这种偏误会让你遗漏许多其它信息。{card-default label="示例" width="50%"}{/card-default}11. 知识的诅咒当我们是某个领域的专家时，会不知不觉假设其他人和我们具有相同的理解能力，尤其是对于专业术语的使用。考虑一下大多数用户，他们的技术水平可能不如你想象的那样，并且对你熟悉的事物也不太熟悉。{card-default label="示例" width="50%"}{/card-default}12. 诱饵效应引入第三个选项來加强旧选项的吸引力。{card-default label="示例" width="50%"}{/card-default}13. 差异偏差在有比较项存在的时候，我们对微小的差异变得敏感，而实际上，这些差异并不是很大。{card-describe title="示例"} 在竞争对手旁边展示你的产品优势，以便用户注意到差异，即使是一个很小的差异。{/card-describe}14. 禀(bing)赋效应和没有拥有的物品相比，用户更倾向于保留自己拥有的物品。他们倾向于高估自己拥有的东西，而忽略其客观的市场价值。禀赋效应是损失规避（loss aversion）的一种表现形式，免费试用是禀赋效应的最常见用法。 一旦用户开始使用某种产品并投入了一段时间，那么在试用期结束时，他们很难放手而停止使用。当用户准备离开时，他们会觉得自己即将失去很多美好的事物。{card-default label="示例" width="50%"}{/card-default}15. 功能故着指个体在解决问题时往往只看到某种事物的通常功能，而看不到它其他方面可能有的功能。这是人们长期以来形成的对某些事物的功能或用途的固定看法。{card-describe title="示例"} 当产品挑战到现有的使用传统时，可能会引起一些可用性挑战。 请确保进行可用性测试，并尝试提前解决这些潜在的问题。{/card-describe}16. 巴纳姆效应也称佛瑞效应。人们会对于他们认为是为自己量身定做的一些人格描述给予高度准确的评价，而这些描述往往十分模糊及普遍，以致能够放诸四海皆准适用于很多人身上。{card-describe title="示例"} 在产品文案中，尽量避免使用“大家”，“用户”等描述，使用诸如“你”，“你的”之类的可以更贴近用户，人们理解规范性信息时，存在一种选择性代入感，这种代入感会让人无意识地专注于选择贴合自己认知和经验，从而产生一种“我也是这样”的归属感。{/card-describe}17. 框架效应框架效应的意义是，面对同一个的问题，在使用不同的描述后，人们会选择乍听之下较有利或顺耳的描述作为方案。在大多数情况下，正向表达（例如玻璃杯已满一半）的转换率会更高。{card-default label="示例" width="50%"}{/card-default}18. 频率错觉首次引起我们注意后，我们很快就会从很多地方注意到相关信息。 例如，如果某人想购买一辆新车，通常会突然发现到处都是这辆车。{card-describe title="示例"} 推动广告系列时，使访问者在不同的营销渠道中接触相同的内容，让别人觉得你的产品周围都是，加深这种新产品的印象。{/card-describe}19. 后见之明偏差后视偏见会让人沉迷于“我早就预料到了”这种感受当中，无法真正从事件中汲取到有用的经验，也难以用公平的眼光来评判客观事物和他人，主观上也很容易选择性地忽略许多客观事实。{card-describe title="示例"} 后视偏见会给人带来快感，但也会在工作中影响决策的正确性和公平性，从而带来潜在风险。纠正后视偏见的方法就是在知道事情结果之前，记录下自己的想法，事后做验证并统计相关数据。{/card-describe}{message type="info" content="就是事后诸葛亮"/}20. 当下偏差又称现时偏差，人们更倾向于获取即时收益，而非未来的更大收益。为用户的立即购买提供小折扣（或免费送货），而非承诺他们在将来购买时提供更大的折扣。{card-default label="示例" width="50%"}{/card-default}21. 可辨识受害者效应我们倾向于同情一个特定的人而不是匿名的某一个人。在讲产品故事时，请使用个体案例，而非一般性陈述。{card-default label="示例" width="50%"}{/card-default}22. 宜家效应宜家效应是指人们倾向于高度评价他们参与创造的产品，消费者对于一个物品付出的劳动（情感）越多，就越容易高估该物品的价值。利用宜家效应提高用户粘性的核心是创造低投入、高回报、高贡献价值的任务，保证用户能够完成任务的基础上贡献自己的价值。在学习场景中我们可以利用宜家效应提高用户粘性，将用户留下来坚持学习。{card-default label="示例" width="50%"}{/card-default}23. 影响力偏差我们倾向于高估未来情绪状态的持续时间或强度。{card-describe title="示例"} 描绘在没有你的产品或服务下用户会遭遇的问题，然后，介绍你的产品会如何解决这些问题。{/card-describe}24. 资讯偏差因测量误差所导致的一种偏误现象，有时亦称为观察偏误或分组错误。{card-describe title="示例"} 在展示产品或服务时（在网站上或app内），请确保附有详细说明的照片。 在产品说明中获得的信息越多，用户获得的保证就越大。{/card-describe}25. 沉没成本谬误我们在某件事上投入越多就越难放弃它。因此，我们往往会继续执行这个走向失败的行动，仅仅是因为我们过去已经在此投入了过多的时间、金钱或精力。{card-describe title="示例"} 当游戏玩家支付了每月30元的会员费时，很多人会强迫自己继续玩游戏，因为他们已经在虚拟游戏中投入了大量时间和金钱。{/card-describe}26. 损失趋避指人们面对同样数量的收益和损失时，认为损失更加令他们难以忍受。损失带来的负效用为收益正效用的2至2.5倍。损失厌恶反映了人们的风险偏好并不是一致的，当涉及的是收益时，人们表现为风险厌恶；当涉及的是损失时，人们则表现为风险寻求。限制特价交易的时间以产生紧迫感：“此优惠在x小时内结束”。{card-default label="示例" width="50%"}{/card-default}27. 单纯接触效应人们会单纯因为自己熟悉某个事物而产生好感。它表明某一外在刺激，仅仅因为呈现的次数越频繁（使个体能够接触到该刺激的机会越多），个体对该刺激将越喜欢。坚持使用用户熟悉的 UI 概念、行为、术语、符号和图标。在营销材料、网站和产品上保持一致来优化漏斗，用词保持和行业术语一致，确保你的用户感到舒适。{card-default label="示例" width="50%"}{/card-default}28. 负面偏差相比于中性或者积极的事物，具有负面影响的事物对人们的心理影响更大。通过解决负面体验来说明你的产品价值，如果希望自己的故事能够产生更大的影响,就要尝试多展现情感上负面的内容。{card-default label="示例" width="50%"}{/card-default}29. 忽略可能性当我们承受压力时，我们没有想到风险发生的可能性。结果，较小的风险可能会被高估或被忽略。在转换漏斗中，最小的不确定性可能导致用户对产品的不信任并停止使用。 需要确保所有细节均清晰明了并预先显示，尤其是涉及金钱的事物，例如总成本，折扣（如果存在），附加成本等。{card-default label="示例" width="50%"}{/card-default}30. 乐观偏差与别人相比，我们经常高估自己成功的几率。{card-describe title="示例"} 请确保产品没有隐藏任何可能破坏乐观偏见的令人不愉快的功能（例如额外的费用，可能的延误等）。{/card-describe}31. 鸵鸟效应我们故意避免负面信息（或与我们的期望不一致的反馈），认为如果我们把头埋在沙子里，它们就会消失。{card-describe title="示例"} 与客户支持一起并肩工作，主动去看什么让用户困惑，从处理用户投诉中可以学到很多东西。{/card-describe}32. 规划谬误我们倾向于低估完成一项任务所需的时间，通常规划谬误会导致时间超支，成本超支或收益不足。将大型任务分解为较小的部分有助于解决这些问题。{card-describe title="示例"} 将你的初始估算值乘以2，不，实际上是3。这样做不是因为你懒惰，而是因为你的估计可能是错误的。{/card-describe}33. 对抗心理当我们感到某人（或某物）试图剥夺或限制我们的选择时，对抗心理就会发生。 当它发生时，我们有一种抵制它并采取相反行动的冲动。{card-describe title="示例"} 当你与用户“争论”他的选择时要小心，说服对方时必须循循善诱，永远不要与用户直接对抗。{/card-describe}34. 自制偏差人们经常会高估自己控制冲动行为的能力。我们都认为“标题党”属于旁门左道，但我们还是陷入其中，不是吗？{card-default label="示例" width="50%"}{/card-default}35. 韵律当理由效应人们会更容易把有韵律的、押韵的句子，当作是真实和准确的。一句话只要变得有韵律了，那么就更有说服力了。尽可能的把你的产品文案变得有韵律感，这样更容易说服用户。{card-describe title="示例"} 在大部分广告语都朗朗上口，非常洗脑。{/card-describe}36. 风险补偿也称佩尔兹曼效应。当我们感觉到更大的风险时，我们会变得更加谨慎，而当我们受到更多保护时，我们就会没那么谨慎。所以当我们知道在已经采取了很多安全措施以后，我们更有可能采取冒险的方式行事。{card-describe title="示例"} 在购买或注册前让用户对产品产生尽可能的安全感，让他们获得信心和信任。{/card-describe}37. 选择性知觉我们对事物的看法在很大程度上受到期望的影响，当人们集中注意力时，人们会从环境中过滤掉事物。{card-describe title="示例"} 产品的转化漏斗并没有在用户登录时开始，而是在用户首次看到你的广告时就开始了。营销信息与产品提供内容之间的不一致会让你的用户大失所望，从而导致转化率的下降。在所有媒介上（漏斗的各个阶段）的消息一致将为用户带来正确的期望，从而提高转化率。{/card-describe}38. 幸存者偏差过度关注幸存下来的人或事物，忽略那些被筛选掉的人或事物（可能因为无法观察到），从而得出错误的结论。{card-describe title="示例"} 在需求分析和调研过程中，如果忽视了幸存者偏差，很有可能搜集到的数据，体现的仅仅只是少部分用户的需求和想法，最终将伪需求和小众需求当作主要需求来作为设计，从而让产品从一开始就走向万劫不复。{/card-describe}39. 零风险偏差我们喜欢确定性，即使它适得其反。在有其他方案可以降低整个风险的情形下，仍倾向于完全消除某一项风险的偏见。一个例子是刻意降低个人负责领域的风险，可是代价是整个组织风险的上升。提供退款保证和无风险试用，以降低风险水平，使你的用户感到安全。{card-default label="示例" width="50%"}{/card-default}40. 感知价值偏差我们根据产品的外观或服务方式来感知其价值。正如人们所说：全部在包装中！设计对于产品的成功比你想象的更为重要，多余的空间，错误的边框颜色和未对齐的文字，都会影响转化率，确保UI设计的优先程度。{card-default label="示例" width="50%"}{/card-default}41. 分析瘫痪又称选择超载，选择困难症。当出现太多选择时，我们的大脑就会瘫痪，很难进行选择。选择太多 = 转换率低{card-default label="示例" width="50%"}{/card-default}42. 稀缺效应我们将稀缺物品的价值提高，将常用性物品的价值降低。害怕错过（FOMO: fear of missing out ）使我们更容易受到诱惑和冲动，并促使我们做出轻率的决定。使用“限时优惠”，“有限数量” 等修辞来形容你的产品或服务。给人的印象是许多人正观看此项目，并随时可以抢走最后的几件物品。{card-default label="示例" width="50%"}{/card-default}43. 流畅性启发我们认为那些处理速度更快、更流畅、更顺利的事物具有更高的价值。有时不合逻辑的论点在沟通良好的情况下（由有权威和经验的人提出）也可能会赢得胜利。为用户提供便利（快捷、简单和易于理解的导航）使内容易于浏览（图像，易读的字体）创建“心理捷径”，它将吸引用户，促使他们把你的产品作为首选提供有意义的默认选项，因为用户会认为你考虑了他们的最大利益，并将尽可能选择默认选项添加功能强大的跨产品搜索，以简化特定主题的查找{card-default label="示例" width="50%"}{/card-default}二、社会偏差这些偏差大多是由归因偏差导致{card-default label="社会偏差" width="75%"}{/card-default}44. 行动者-观察者偏差行动者喜欢将他们自己的行为归因于情境性因素，而观察者喜欢将同样的行为归因于行动者稳定的人格素质。{card-describe title="示例"} 我们会用外在、不可控的情境性原因来解释自己的行为，比如上班迟到是因为路上出了意外。但是当我们作为观察者，试图对别人的行为进行解释时，我们会用内在的、稳定的人格原因来解释，比如上班迟到是因为他懒、没有时间观念。{/card-describe}45. 达克效应我们无法认识到我们缺乏能力，并且由于无法分辨能力好与能力差的不同，因而认为大家都一样。能力差的人通常会高估自己的技能水平；能力差的人不能正确认识到其他真正有此技能的人的水平能力差的人无法认知且正视自身的不足，及其不足之极端程度；如果能力差的人能够经过恰当训练大幅度提高能力水平，他们最终会认知到且能承认他们之前的无能程度。{card-default label="示例" width="50%"}{/card-default}46. 错误共识效应人们倾向于高估别人对自己的认同程度，想象其他人像我们一样，并分享我们的观点，信念，偏好，价值观和习惯，认为所有人以同样的方式思考。{card-describe title="示例"} 在没有涉足政坛（或特定国家）的情况下，你最近对你所在国家的选举结果是否感到惊讶？{/card-describe}47. 基本归因谬误解释他人行为时，归因于内在特质（一定是他有这样的人格，才做出这样的行为），而非外在情境（也许是情势所迫，或这个场所有特殊的潜规则）。基本归因谬误是矛盾和问题的常见来源，而且这种认知偏差存在于用户也同样存在于设计师本身。{card-describe title="示例"} 需要设计师能够清楚地分辨「我的观点」和「我的行为」，能够真正将自己从自己所处的立场、角色、职能上抽离出来，复盘整个局面。首先接纳全部的现实，包括他人的想法、观点，先不去判断对错，明白事物的动态变化过程。不要再单一地去判断，因为任何一个视角必然会存在一个立场，它们是当前事物诸多层面中的一方面而已。{/card-describe}48. 晕轮效应晕轮效应是指使用一个人（或事物）的一种品质来对该人或事物进行整体判断，换句话说，我们对一个人、一个产品、一家公司或一个品牌的最初印象会影响我们对其整体特征的解读。通俗来讲，就是第一印象{card-describe title="示例"} 通过使用权威照片和可建立信任关系的视觉效果来充分利用这种具有启发式的方法。{/card-describe}49. 群内偏差群内偏差常被用来引导用户决策，它是指人们会在认知上倾向于自己所属的群体。在体验设计中利用群内偏差的关键点在于打造群体归属感，借由小群体的力量影响用户的决策。比如 Booking 在查看评论的区域加入了筛选评论语言这一按钮，虽然设计的本意可能是为了方便用户更好地理解评论内容，但是在真实的使用过程中可以发现，用户更加信任自己所选标签内的评论内容，因为同语言往往意味着来自相同的国家或者相近的文化背景，用户通过这种方式找到一个小群体，然后被影响进而做出与群体内人们更为相似的决策。{card-default label="示例" width="50%"}{/card-default}50. 权威偏见我们认为权威人士给出的建议准确性更高，并且更容易受到该建议的影响（即使事物主体与该人物的权威性无关）通过宣传产品的知名推荐来建立权威:联系有影响力的人，让他们免费使用你的产品或服务突出显示知名客户或品牌展示来自社会名流的推荐语在产品展示和陈述中使用权威人物（例如医生、教授等）{card-default label="示例" width="50%"}{/card-default}51. 得寸进尺法得寸进尺法又译登门坎效应，是一种通过先提出一个简单的小请求来说服用户同意一个较大请求的劝说方法。通过提供免费试用与用户建立联系。不要用过于复杂的引导流程让用户感到不耐烦。把大块的内容分解成小块或容易解决的内容，让用户保持开心和参与度。{card-default label="示例" width="50%"}{/card-default}三、记忆错误与偏差在心里学和认知科学中，记忆偏差是一种认知偏差，导致记忆的强化、弱化（包括能否想起的机会、想起所需的时间，或两者皆有），或者记忆内容的改变{card-default label="记忆错误与偏差" width="75%"}{/card-default}52. 谷歌效应我们会容易忘记可以在网上轻松找到的信息。你还记得你最好的朋友或孩子的电话号码吗？{card-default label="示例" width="50%"}{/card-default}53. 幽默效应当信息被认为是有趣或幽默时，我们会更好地记住信息。这可以帮助提高产品的转化率，并有助于整体业务的提升。{card-describe title="示例"} 在用户可能感到沮丧的情况下不要幽默。例如，如果你的应用与旧设备不兼容，请不要用有趣的方式说出来，因为此时用户可能很沮丧，无法感知幽默。{/card-describe}54. 真相错觉效应重复的事情越多，我们就越相信。{card-describe title="示例"} 在广告，网站，App Store页面，登录页，新闻通讯等一次又一次地重复你的消息（主要好处，主要区别）{/card-describe}55. 峰终法则用户不仅仅根据平均或所有体验的总和来评估体验，取而代之的是，他们的大脑会严重地偏向峰值（高或低）和体验的终点，峰值如果是愉悦的话，通常对应了用户旅程中令人难忘的愉悦感。通过使产品的最佳功能变得更好，保持产品的竞争优势并提高产品高峰。另外也不要忽视产品的“购买后”体验，确保以精湛的品味结束体验。{card-default label="示例" width="50%"}{/card-default}56. 图片优势效应图片和图像比一千个单词更容易被记住。{card-describe title="示例"} 始终在内容中包含图像，出色的视觉效果将提高转化率。{/card-describe}57. 首因效应又称近时效应、序位效应。列表开头和结尾的项目比中间的项目更容易被用户记住。如果你打算展示一长串信息，请确保第一个是最重要的内容。{card-default label="示例" width="50%"}{/card-default}58. 雷斯多夫效应当很多信息一起呈现时，醒目的信息和被特别强调的信息会比其他信息更容易被人们记住。按钮以不同的样式，大小，颜色和位置显示出来，以达到不同的目的。{card-default label="示例" width="50%"}{/card-default}59. 蔡格尼效应进行中的任务会产生特定于任务的张力。当任务完成时，这种压力可以缓解，但如果任务被中断，它将保持不变。这种张力使相关信息更易于访问和记忆。{card-describe title="示例"} 显示一个不完整的进度栏，以鼓励用户实现自己的目标。{/card-describe}四、统计与几率偏差几率性推论是指根据有关几率的资讯推论事情的可能性，而几率的估算通常来自统计资料，因此两者密不可分{card-default label="统计与几率偏差" width="75%"}{/card-default}60. 基本比率谬误我们倾向于忽略一般信息，而只关注特定案例。{card-describe title="示例"} 不要只分享那些冷冰冰的产品信息。相反地，展示其他相关用户或公司的评价、用例。如果你想更具有说服力 —— 把你的量化数据和一些个人故事相结合。用量化数据合理地支持你的观点。具体的例子会在情感上传递你想表达的信息。{/card-describe}61. 赌徒谬误我们错误地认为，如果在给定时期内某件事情频繁发生，那么这件事情在将来发生的几率就会很小。坚持事实，少依靠直觉，更多的依靠数据。{card-default label="示例" width="50%"}{/card-default}62. 热手谬误错误地认为经历过成功的人更有可能在其他尝试中进一步获得成功。一般是在某人近来做某事很成功时，认为他未来做同一件事也会很成功，而忽略其成功可能只是随机与巧合导致。通过强调一系列成功案例来建立自己的强大品牌。{card-default label="示例" width="50%"}{/card-default}63. 对样本数不敏锐我们经常忽略样本大小并贸然下结论，即使样本数量还未达到足够的统计量。{card-describe title="示例"} 与客户沟通很重要，但不要把产品设想建立在几次面谈的基础上。使用大量数据，并根据实际数据而非假设来做出产品决策。{/card-describe}五、实验与研究偏差这是一些科学实验或统计研究容易放生的偏差{card-default label="实验与研究偏差" width="75%"}{/card-default}64. 取样偏差某些类型的用户被无意中从研究参与者池中剔除了。亦可理解为以偏概全，即以局部事例解释整体原因。{card-describe title="示例"} 比如某研究员正在设计自行车跟踪应用，需要对骑行者进行研究。决定采访并观察北京市的自行车骑行者，但这个研究员没有意识到他们的骑行行为习惯可能与居住在山丘多的郊区的骑行者有很大不同。因此他的研究成果可能有不适用于所有目标受众的风险。{/card-describe}65. 观察者期望效应研究者有时可能会期望出现某种结果，他们无意识地操纵了试验过程，或者错误地解释实验结果，导致研究结果严重歪曲。{card-describe title="示例"} 在用户研究中，研究者的表情、肢体语言等都可能会反映出自己所期待的结果，如果用户察觉到了这些，就可能做一些迎合研究者期望的反应。{/card-describe}66. 社会期许偏差我们倾向于多表达符合社会期许的事情，而隐瞒那些不符合社会预期的事情。例如在询问是否有不良嗜好、性伴侣数量时，大家会有意无意地隐瞒或淡化实情。社会证明是建立信任的好方法。以下是可在产品页面上使用的一些示例：{card-describe title="示例"}知名的客户logo知名的合作伙伴logo客户的好评和真实推荐（来自目标受众）累计数据（客户数量，交易次数等任何有价值的数字）媒体的提及和引用由知名组织颁发的奖项认证证书真实数据支撑案例的链接{/card-describe}{message type="info" content="不要说“我们很棒，因为……”，而是通过其他人来证实。"/}67. 遗漏变数偏差当获得的奖励出乎意料之外，我们获得奖励的喜悦感就会增加。{card-describe title="示例"} 为用户提供每日优惠，免费奖金，奖章，奖品等。每天创建的"动作"越多，用户就越会感受到与产品的联系。{/card-describe}
词语二字动词{callout color="#f0ad4e"}复密，赋能，加持，沉淀，倒逼，落地，串联，协同，反哺，兼容，包装，重组，履约，响应，量化 ，布局，联动，细分，梳理，输出，加速，共建，支撑，融合，聚合，集成，对标，聚焦，抓手，折解，抽象，摸索，提炼，打通，打透，吃透，迁移，分发，分装，辐射，围绕，复用，渗透，扩展，开拓，皮实，共创，共建，解耦，集成，对齐，拉齐，对焦，给到，拿到，死磕{/callout}三字名词{callout color="#ed4def"}感知度，方法论，组合拳，引爆点，点线面，精细化，差异化，平台化，结构化，影响力，便捷性，一致性，端到端，短平快，护城河，体验感，颗粒度{/callout}四字名词{callout color="#4fef4d"}生命周期，价值转化，强化认知，资源倾斜，完善逻辑，抽离透传，复用打法，商业模式，快速响应，定性定量，关键路径 ，去中心化，结果导向，垂直领域，归因分析 ，体验度量，信息屏障，资源整合。{/callout}引用你有哪些屡试不爽的经典话术？ - 07f合一涵的回答 - 知乎
前言有一台旧手机（红米5A）一直放在抽屉里吃灰，最新闲来无事，把他改造成了一台家用server。特此记录改造过程。{card-default label="我的iphone" width="50%"}{/card-default}获取root权限{callout color="#f0ad4e"}博主的手机是红米,获取root权限，首先去官方申请内测权限，解锁bootloader。然后下载开发版，开启root权限。折腾了1天，没有搞定。下载了一个奇兔刷机，利用一键root功能获取了权限,花了我18大洋，但节省了时间，尊重别人的劳动成果。{/callout}{card-default label="小米" width="50%"}{/card-default}{card-default label="奇兔" width="50%"}{/card-default}更新Magisk{callout color="#f410a0"}直接github下载的最新版, 下载地址 。安装后，显示冲突。需要删除旧版本。{/callout}安装模块{message type="error" content="需要安装ACC、Busybox、SSH ,如果下载失败，需要设置里面清除仓库缓存。"/}ACC支持模块Busybox 一个命令工具集SSH 远程连接服务{card-default label="模块" width="50%"}{/card-default}MT管理器{message type="success" content="可以直接在应用商店下载"/}{card-default label="MT管理器" width="50%"}{/card-default}ACC电源控制{callout color="#f0ad4e"}通过github下载配套app。 下载地址 , 用来控制长时间连接充电线的情况下，电池充放电的问题。{/callout}{card-default label="ACCA界面" width="50%"}{/card-default}安装linux deploy{callout color="#f00fdd"}手机下的模拟机软件,通过chroot模式运行。直接通过github下载最新版。 下载地址 {/callout}配置过程{message type="error" content="需要注意两个地方，一个是软件本身的设置，另一个是镜像配置文件。"/}{card-describe title="设置"}锁定wificpu唤醒开机自动启动PATH变量：/system/xbin其余的默认{/card-describe}{card-describe title="配置文件"}发行版，我采用的是debian架构，arm64（手机一般都是这个）linux版本，stable源地址，http://mirrors.tuuna.tsinghua.edu.cn/debian/安装类型，目录路径，/data/linux用户名，root密码， 自己设置本地化，zh_CN.UTF8初始化，启用初始化系统，run-partsSSH，启用，注意更改端口为2201，因为22端口被Magisk的ssh服务占用{/card-describe}{message type="success" content="配置完成后，先点右上角安装，等待安装完成。然后，先停止在启动"/}通过哪吒监控管理{callout color="#f0ad4e"}手机平时放在家里，外出的时候无法管理。而哪吒的后台和客户端配合，刚好有个terminal功能，正好合适。所以给手机转个nezha-agent即可。省去了配置反弹shell或者ssh隧道的麻烦。哪吒监控的安装参考: 哪吒监控部署记录 {/callout}{card-default label="终端功能" width="80%"}{/card-default}nezha-agent设置开机启动{message type="success" content="因为系统采用chroot运行,systemctl不能用。采用rc.local的方式"/}# 编辑rc.local vim /etc/rc.local #!/bin/bash # ip,port 服务端设置 # 密钥 服务端获取 /opt/nezha/nezha-agent -s ip:port -p 密钥 &{message type="success" content="最后重启手机测试, 成功上线。这样就可以在家里没人的时候，下剧看了。"/}使用下载视频ssh root@127.0.0.1 -p22 cd /data/media/0/DCIM/Camera # wget 视频地址url局域网播放器# 局域网电视投屏，mac下之行获取端口信息 dns-sd -B _airplay._tcp dns-sd -L "VIDAA-2d" _airplay._tcp local. {card-default label="端口信息" width="75%"}{/card-default}FAQMagisk版本冲突{card-default label="冲突" width="50%"}{/card-default}{message type="success" content="MT管理器,进去system, app里面找见magisk 删了,重启即可"/}
说明量化交易是指以先进的数学模型替代人为的主观判断，利用计算机技术从庞大的历史数据中海选能带来超额收益的多种“大概率”事件以制定策略，极大地减少了投资者情绪波动的影响，避免在市场极度狂热或悲观的情况下作出非理性的投资决策。
说明云拨测是一种针对互联网应用（Web页面、网络链路等）进行主动式应用性能和用户体验监测的服务。云拔测为云上用户提供开箱即用的企业级主动拔测试应用监测解决方案。以模拟真实终端用户使用场景为视角，对目标进行性能管理和网络性能监控，透视防火墙外的各环节性能。先于用户挖掘故障隐患。{card-describe title="阿里云拔测"}网页性能网络质量文件下载api性能定时拔测即时拔测{/card-describe}要点{callout color="#f0ad4e"}浏览任务IE全元素Chrome全元素网络质量文件下载Lastmile监测点IDC监测点时延丢包率DNS查询用时自定义频率元素错误元素错误率运营商可用性{/callout}
说明服务器的成本挺贵的，而阿里有抢占式实例，腾讯有竞价实例。相当于包月服务器的1-2折，很便宜。就是在资源紧张的时候被收回，适合放置无状态服务。{card-describe title="架构图"}{/card-describe}