供应链与CRM、CMS、ERP、SAP的区别 前言供应链、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 的软件具有功能强大、集成性高、可扩展性强等特点，可以支持多语言、多货币、多国家的法律法规等复杂的业务环境，被广泛应用于各个行业的大型跨国企业中。

aws免费申请vps使用教程，可免费使用一年 前言在国内，主流的云服务器厂商有阿里云和腾讯云。国外有亚马逊aws,甲骨文，微软等。由于竞争非常激烈，各个商家都相继推出了免费试用或者永久试用的套餐来吸引新客户。云计算的鼻祖亚马逊云，提供了很多免费试用的产品，其中免费一年的electric computer cloud类似阿里腾讯的轻量云服务器，直译为弹性云计算，简称EC2 再简称VPS。亚马逊云科技官网注册亚马逊账号进入官网，选择免费套餐类别。或者直接点击右上角创建AWS账户。{card-default label="官网首页" width="80%"}{/card-default}创建免费账户{card-default label="创建账户" width="80%"}{/card-default}填写账号信息{card-default label="填写邮箱" width="80%"}{/card-default}将收到的验证码填入{card-default label="验证码" width="80%"}{/card-default}设置账号和密码{card-default label="账号密码" width="80%"}{/card-default}根据实际情况填写个人资料{card-default label="填写个人资料" width="80%"}{/card-default}然后按照提示，一步一步完成注册即可。等待一段时间审核，{card-default label="完成注册" width="80%"}{/card-default}收到邮件后，登录账号即可创建一台免费的vps。测试了一下速度可以。{card-default label="通知邮件" width="80%"}{/card-default}创建免费vps申请的免费实例{card-default label="免费实例" width="80%"}{/card-default}

《红楼梦》人物关系 图谱

硅云香港vps测试报告 硅云香港节点的vps测试报告，在实际使用的过程中网络很卡。用docker的过程中，网络莫名奇妙的不通，感觉有限制。

围绕故障管理谈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 在谈论故障定位的时候，谈的是什么，如何找到故障直接原因，找到止损依据，如何让可观测性系统呈现观点，辅助洞察，定位故障

《思考快与慢》笔记 提升自己关于思考的认知能力

《金字塔原理》笔记 思维思考方法论

《心路沧桑-从国民党60军到共产党50军》笔记 心路沧桑-从国民党60军到共产党50军滇军 云南⽤历史唯物主义和辩证的唯物主义的思想⽅法去反思。正视两个基本的历史事实，掌握三个基本思想方法,发掘三个领域的思想资源历史的曲折应该历史的反思西方人 重视生活对个人的价值中国人 重视个人对他人（家庭、团体、社会、历史）的价值。旧军队忠义观念这种鲜明的阶级属性，是反思传统文化的历史学家、社会学家应该正视的基本史实如今,有人把新中国成立后大陆的这些“极端评价”说成纯意识形态的“左祸横行”，并试图以此彻底否定亿万劳苦大众得以翻身解放的中国革命。这是一个需要史学，心理学，社会学解析并完成学理创新的学术课题。构成⼈的神经基本单位的神经元，其兴奋性具有⼀种很特殊的现象，当刺激强度未达到某⼀程度时，即⽆神经冲动之发⽣；当刺激强度达到某种程度⽽能引起冲动时，该神经冲动⽴即达到最⼤强度。此后的刺激强度纵使再继续加强或减弱，对已引起的冲动强度不再发⽣影响。此种现象称之为“全有全⽆律”被浦绍林、杨宗贵们视为政治⽣命的“群众反映”，曾是⽑泽东时代共产党队伍⽤以评价⼲部、约束领导并且使⽤频率很⾼的⼀个流⾏词语，如今，已趋于消失，取⽽代之的是贬斥“冒杂⾳”。给曾泽⽣当了⼋年侍从副官的乔景轩曾写过⼀篇《回忆曾泽⽣军长》的⽂章，其中评价曾泽⽣在旧军队时“很讲旧道德”。当这篇被认为相当客观的⽂章编⼊某书时，编辑将“很讲旧道德”⼀句中的“旧”字删掉了。⼀字之删，将往⽇效劳于阶级压迫制度的曾泽⽣抬上仙境，将曾泽⽣痛苦却又有价值的思想转变过程⼀笔抹杀，也将晚辈对历史⼈物的认识导⼊迷途。备周则意怠;常见则不疑。阴在阳之内，不在阳之对 防备得周全时，更容易麻痹大意；习以为常的事，也常会失去警戒。秘密常潜藏在公开的事物里，并非存在于公开暴露的事物之外。公开暴露的事物发展到极端，就形成了最隐秘的潜藏状态。