时隔半年再看时又会有不一样的收获和理解："SRE其实是没有止尽的：当稳定性达到一定标准或者水平时其实就可以向上或者向下去追求SLB，从而进一步提升整体稳定性.稳定是相对的-就看站在那个阶段和格局去思考。"

真的太棒了！内容我感觉就是SRE的BIBLE

个人观点：DevOps推动企业技术价值流快速的流动的一套思想、方法、工具，涉及开发、测试、运维甚至产品，而SRE更偏向运维一些。当然我刚学SRE

谢谢老师一个月的分析，一章不差的看完了，收获颇深。 我和大家不太一样，我在一个小公司就职。所以在学习各种大厂体系的过程中，总有一个困惑，就是体系很牛，但我没法用，因为小公司无论人力资源、技术能力、硬件能力等都太小了，即使理论上学了，但根本无法耗时耗力搭建这么一套东西。 但这次我学习咱们的SRE体会就不太一样，我先了解了MTBF、MTTR(更细的说是MTTR里的四个阶段)，然后对照我们公司的自身的情况对照着表格看，看看是哪个环节是目前的薄弱环节。这样即使我无法向您一样搭建整个体系，我也能针对性的解决最薄弱的环节。 但老师您在课程中也有说：SRE是一套体系，多部门合作出来的，并不是某一个点或某一个技术，那请问老师，对于我们这些中小型公司，资源有限，那怎么做才能让系统全方位的稳定起来呢？

平时以赛带练的场景有很多，除了系统集成测试方的压力测试、可靠性测试、性能专项测试外，还经常做一些局点演示及故障模拟训练，这些都是一些快速暴露问题和提取改进点的有效方式，持续提升系统稳定性。

我觉得PE这个角色很重要，需要整理业务需求和反馈，沉淀到平台工具开发团队和稳定性开发团队。又需要和业务团队沟通交流，来适配技术中台。虽然他不是一手需求设计者，也不是具体技术中台功能开发者。但是确是关键的核心枢纽。

受益匪浅，特别是那句：没有进展也是进展！很多从事故障处理或维护人员没有这个意识，确实很关键！我们团队的指挥官一般是负责整个系统的SE来承担，拉通的同时，也做技术决策，还是比较高效的。

1.我认为是效能和稳定性工具平台的开发。 2.在所有角色中没有重要的轻重，因为我们要的是保证系统稳定运行这一最终目标，所以，哪怕是一根稻草的重量，那也是同等的重要. 3.但是，搭建整套完善的sre是一个长期的工程，安排好优先级可以让团队和公司在在搭建的过程中获得更高的效益，毕竟效益这个东西不是快照，而是一个时间上的积累。 4.所以，我认为优先做效能和稳定性平台的开发会比较好，因为他能比较快的拿出东西，也没有那么多因地制宜的限制，在sre推进的前期，既可以降低公司的顾虑，也可以提高团队的士气。是个开刀的好口子。至于iaas和paas这两块，能用云先用云。而业务这块，这是一件任重道远的事，不适合做先头。

亚马逊的复盘就提倡ask 5why方法，我觉得无论哪种方法，其关键就是故障处理，故障复盘，故障改进需做到整体的闭环，这就需要跳出故障本身，站在更上层考虑整体的业务。比如某个团队的a业务出了故障，找到了问题，自身业务已经修复，那么该问题其他团队的b/c/d业务也可能会遇到，那么如何推动线上的业务全部fix？ 我认为这需要一个良好的有效测试环境，毕竟对b/c/d...来讲是一次变更，要知道变更往往是故障的来源，所以变更之前的有效测试就很重要。

能快速处理好故障的团队，内部文化应该也很优秀。这和军队作战类似，经常打胜仗的部队，其内部作风肯定非常严谨细致。而要提高自身作战能力，肯定是要付出代价的，军人可能会流血。相比业务肯定会存在一些因故障演练带来的损失，但随着你业务规模的扩大，这个代价其实省不了。提前向业务方沟通好的故障演练，往往比事后出故障被动处理要好。整个沟通过程，都应尽量化被动为主动，主动发现，主动汇报，主动安抚，尽量降低客户的负面情绪。而且故障过程中汇报用词也很关键，多站在对方的角度思考。另外，故障的处理应对方式，往往你和团队leader(如果这个leader干过运维，那你是幸运的)的认可度有特别大的关系，不然开展起来会很麻烦，毕竟调用的资源不少，牵扯的人又多，还可能有背锅的风险。