mod

极客时间专栏/SRE实战手册/结束语/答疑｜没什么能阻挡你拓展边界的渴望.md

@@ -0,0 +1,86 @@
+<audio id="audio" title="答疑｜没什么能阻挡你拓展边界的渴望" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/67/64/67cdbe4d4691f3e9c1fd5ea7b7b4e464.mp3"></audio>
+
+你好，我是赵成。
+
+最近一直关注你的留言，我发现大家有一些共性的问题，所以专门准备了这次答疑加餐，和你分享我的一些想法，还有我看到的特别有洞见的留言，我们一起继续交流。今天我总共梳理了六个问题，前五个和SRE的落地及概念有关，最后一个关于个人成长，那我们就开始吧。
+
+1. **小团队，实践SRE可以从哪些方面入手？中小型公司资源有限，怎么做才能让系统全方位地稳定起来呢？**
+
+如果确实资源有限，我的建议是跟业务开发坐到一起，就不要独立去做一些事情了，这时还是以满足业务开发的需求为主。如果时间精力充足，可以先从一些重复繁琐工作的自动化入手，先提升效率再说。
+
+再就是，团队规模小的时候，其实恰恰是提升技能全面性的机会，因为这时分工没有这么细，从网络、服务器、操作系统，再到Web服务器、应用服务器、数据库、缓存等等，都是学习和接触的好机会。
+
+随着业务的增长，未来团队变大，就可以考虑SRE体系化了，建议先做一些分布式、微服务和高可用架构方面的知识储备，未来随着实践的深入，视野自然会逐步打开。
+
+1. **如何定义一个故障？有什么具体方法吗？粒度怎么界定？**
+
+定义一个故障，我觉得有两种方式。
+
+一种是我们SRE课程[第04讲](https://time.geekbang.org/column/article/215649)中错误预算的计算方式。这种方式是**从技术维度**来定义，通常会用在一些技术产品中，比如云计算行业里的CDN、云存储，或者是一些提供开放API调用的服务，这种产品根据调用的返回码、响应时延以及错误码等等就可以评估系统稳定性，具体方式我在课程里有详细讲到，你可以再复习一下。这里的关键还是找到能够衡量稳定性的指标，并设定稳定性指标的SLI和SLO，进而推导出错误预算。如果一开始不好衡量，就先从当前的实际情况出发，比如成功率的SLO是98%，那就看怎么提升到99%，再到99.9%，逐步提升。
+
+还有一种是我在《赵成的运维体系管理课》[第 28 讲](https://time.geekbang.org/column/article/4628)中讲到的，如果我们负责的是一个业务系统，比如电商类的，这时就要**从业务维度**进行分析，比如影响到的交易额、订单数、访问用户数等等。我给你放一张图，你可以参考下。
+
+<img src="https://static001.geekbang.org/resource/image/72/2e/7228f86a4bb7da3d6841181a951d592e.jpg" alt="">
+
+1. **SRE是否需要从项目开始就参与系统架构设计？如果只是在项目上线运行后才接触，遇到架构不合理的地方如何处理？**
+
+SRE是不是要在项目开始的时候就参与到系统架构设计中，答案是肯定的。即使不是在项目开始时介入，也要在做技术方案和架构设计阶段就要参与进来，这个时候不一定参与架构本身的设计，但是要**给架构提出明确的稳定性要求**，比如哪些是核心部件？它们的稳定性要求应该是怎么样的，也就是SLO要达到多少？承诺的容量水平是多少？如果要做到高可用，是需要集群模式，还是主备模式？故障时的应急切换机制应该怎么设定？等等。这些要求决定了高可用的架构应该怎么设计。
+
+如果是上线后才接触，还是先从SLO入手，建立SLO的稳定性衡量标准，然后看哪里不达标，就推进解决。SRE更多的要成为稳定性的监督者和推进者，而不是各种问题的救火队员。
+
+1. **国内传统行业的SRE组织架构是什么样的，有必要设置SRE岗位吗？**
+
+国内传统行业的SRE组织架构基本也是我在[09讲](https://time.geekbang.org/column/article/219387)中提到的组织架构。其实最开始我也很好奇传统行业会不会特别不一样，后来走访了一些企业后，我发现其实是殊途同归的，因为不论是传统行业还是互联网行业，大家**选择了相似的架构演进方向，就需要有配套的组织架构**，无论是实线的组织架构，还是虚线的协作模式，形式上大致相似。
+
+至于是否有必要设置SRE岗位，我觉得真的不能把SRE只当成一个岗位来看，它实际传递的是一种稳定性的理念。遵循这种理念去做，这个岗位是不是叫SRE其实都已经不重要了，比如在阿里和蘑菇街，甚至是国外的Facebook，都叫做PE，在这些公司里PE在职责上跟SRE是一样的。
+
+讲到这里呢，就多说一下PE（Production Engineer）这个角色，翻译成中文是生产系统工程师，最早是由雅虎定义出来的一个岗位，注意，这个岗位不是运维。这个角色的职责其实是由软件架构师承担的，也就是架构师负责设计架构，参与核心功能研发，对于产品了解得也最全面，所以系统上线后，维护的工作自然由他来承担，同时，随着线上问题的解决和处理，以及对线上问题的反思和总结，他又会不断完善架构设计和改造，是一个不断正循环的过程。
+
+所以，你看，PE这个角色从一开始就是有非常高的要求的，并不是普通角色能承担的。阿里也是在收购了雅虎中国后，将PE的角色和先进机制引入到了阿里的技术体系中，国外很多公司也沿用了PE这样的角色，可以说从根本上，PE跟SRE的要求和作用是一样的。
+
+1. **DevOps和SRE有什么区别？**
+
+这个问题，是我在[第01讲](https://time.geekbang.org/column/article/212728)中留的作业题，我发现很多同学的回答已经非常深入了，我分享两位同学的理解。
+
+来自于加硕同学：
+
+> 
+DevOps核心是做全栈交付，SRE的核心是稳定性保障，关注业务所有活动，两者的共性是都使用软件工程解决问题。
+
+
+> 
+DevOps的诞生是由于互联网商业市场竞争加剧，企业为减少试错成本，往往仅推出最小可行产品，产品需要不断且高频地迭代来满足市场需求，抢占市场（产品的迭代是关乎一整条交付链的事），高频的迭代则会促使研发团队使用敏捷模式，敏捷模式下对运维的全栈交付能力要求更严格，运维必须开启DevOps来实现全栈交付。因为不断的迭代交付（也就是俗称的变更）是触发故障、非稳定性的根源，而对于互联网产品来说，服务稳定性缺失会造成用户流失，甚至流到竞争对手那里， 因此关注业务稳定性也变得十分重要，SRE由此诞生。
+
+
+来自无聊的上帝：
+
+> 
+<p>DevOps主要是以驱动价值交付为主，搭建企业内部的功效平台。SRE主要需要协调多团队合作来提高稳定性。<br>
+例如：<br>
+与开发和业务团队落实降级；<br>
+与开发和测试团队推动混沌工程落地；<br>
+与开发团队定制可用性衡量标准；<br>
+与开发、测试、DevOps、产品团队，共同解决代码质量和需求之间的平衡问题。</p>
+
+
+我为什么觉得这两位同学的留言有见地呢？因为他们都找到了看待这个问题的全新的角度，不是单纯地比较这两者应该采用什么技术，做什么事情，而是聚焦到我们要解决什么问题上。DevOps的出发点是“更加高效地交付用户价值”，而SRE的出发点是“保障和提升系统稳定性”，两者要做的事情其实本质上差别不大，但是角度不同，那么在执行的时候，要解决的问题也就会有所差异。
+
+1. **在工作职责和经验有限的情况下，怎么不断提升自己，拓展自己的能力边界？怎么提高英语水平？怎么提升编码能力？**
+
+我觉得对于我们技术人来说，最好的提升自己的方式就是实践，解决实际问题，然后思考总结，比如输出总结文章等等。**解决的问题越多，能力自然会提升，边界和视野自然会打开。**
+
+关于提高英语水平，我觉得也是一样，就是多听多看多说。
+
+这一部分，我不打算分享太多细节，为什么呢？因为我觉得关于学习和成长，是需要我们每个人沉下心来从一点一滴做起的，比如从读第一篇英文文章和论文开始，不懂的单词一个一个查清楚，一句话看不懂，耐心多读几遍，今天读不懂，明天后天再回头来读，再体会。
+
+**学习真的就是这样一点一滴积累，耐住性子**，一开始可能积累得会比较慢，但是慢慢地就会越来越快。
+
+所以，最终的建议就是，**从现在开始，先做起来再说吧**。
+
+讲到这里，我就给你推荐一下系统学习SRE的资料吧，我认为到目前为止，最体系化的学习资料就是Google官方发布的[3本书](https://landing.google.com/sre/books/)，全英文版，要学习英语就从他们开始学起吧。
+
+<img src="https://static001.geekbang.org/resource/image/02/28/0268abfb2fe30182b7ad385b3b347428.png" alt="">
+
+关于这三本书的阅读循序，建议你先读兼具普适性和参考性的第二本，然后再看第一本，最后读第三本。
+
+好了，今天的答疑就到这里了。学习的过程中，如果你还有什么疑惑或者心得体会，欢迎继续写在留言区，和大家一起交流。

极客时间专栏/SRE实战手册/结束语/结束语｜聊聊我的SRE落地心路历程.md

@@ -0,0 +1,35 @@
+<audio id="audio" title="结束语｜聊聊我的SRE落地心路历程" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/32/e0/3215ba424ab84611039ca716f0bedde0.mp3"></audio>
+
+你好，我是赵成，不知不觉我们已经来到了结束语，非常感谢你的一路陪伴。
+
+学完咱们的专栏，我想对于SRE到底是怎么一回事儿这个问题，你应该有一个大致的了解了。就像我们在开篇词中提到的，**SRE真的没有那么神秘**，你平时在做的很多事情本身就属于SRE的范畴，学到这里，你应该对此深有体会了。
+
+其实这个感受我也是在不断实践的过程中总结出来的。刚接触这个概念的时候立马被它吸引，但同时也觉得这东西有点儿高大上，自己有种心有余而力不足的感觉。幸好和团队一起，就是一点一点死磕，解决一个又一个具体的问题，然后因为一直有这样一个大的框架和目标在那里，最后慢慢发现，这个框架居然已经落地得差不多了。如果总结下我自己实践SRE的心路历程，我觉得王阳明《传习录》里的“**知者行之始，行者知之成**”就特别恰当、准确。
+
+你是不是在想，这不就是知行合一嘛，也没啥特殊啊！嗯，确实是，听起来、说起来都挺简单的，但是很多时候我们想要做到还真不容易。
+
+其实，在学习这个课程的过程里，我们也需要知行合一，从知出发，到行完成一个闭环，然后积累新的知，把这个知行的循环一直继续下去。
+
+这么说，有点抽象，这里我特别举咱专栏里一位同学的例子。这位同学名字叫胡凯，他一边学习课程，一边和我探讨一些SRE问题。每次提问，他总是可以带着具体场景和具体问题，非常有针对性，而且针对不同的场景，他又会有自己的一些见解和解决方案，然后在与我讨论的过程中，不断迭代优化他的思路和方案，特别是在SLO设定这一块，因为很多监控指标都是现成的，他马上就根据我们课程里给出的VALET方法，整理出了一个新的表格，这种从更多SLO维度分析稳定性的方法，一下子就解答了他之前一直以单一维度判断稳定性的很多疑惑和问题。
+
+像胡凯这样的同学，我们专栏里还有很多，大家都提出了非常好的问题，也分享了自己的思考和总结。这个我们一起交流探讨的过程，对于我来讲也是一次难得的学习机会，我想这就是“教学相长”的意义吧。
+
+那么，接着这个话题，我再唠叨几句我的期待吧。这个课程基础篇的几讲是我花费心思最大的内容，因为我想从基础上就讲明白SRE的一些概念和理论。说实话，这部分内容也是需要你花费很大的精力和实践去消化的。如果你之前有过一些实践，再结合我们的课程去看的时候，你会发现理解起来就会轻松很多，也会有更多的收获；如果你现在还没有那么多的实践，这些内容你理解起来还没那么直观，那接下来就要抓住工作中的具体场景和问题，先去实践下，再回过头来看这几讲，到时候你肯定会有不一样的理解，我也会在这里，继续等你提出更好的问题来。
+
+所以你看，对于我们从书本、课程中学习到的知识，要想把它们真正地转化为自己的能力，唯一的方法就是实践、思考、优化实践，并且不断重复这个过程。
+
+对于我们要学习的SRE来说，也是这样。我认为很多人之所以没能好好落地SRE，一个最大的障碍不是技术难度、甚至不是组织架构和文化等问题，而是大家先把自己局限在了概念上，很多人深深地沉浸在SRE到底是什么，它跟现在非常流行的DevOps、AIOps、混沌工程以及各类中台的概念到底是怎样的一个关系？我们该怎么选？……**纠结在这样那样的问题中，结果就是在问题漩涡中停滞不前，迈不出第一步，那就永远都走不前去**。
+
+这时候应该怎么做呢？我的建议就是，从你遇到的实际问题出发，从你所在的实际场景出发，解决问题，满足场景需求，先做起来再说，然后参考优秀的实践案例和分享，再做优化和调整。
+
+其实，在蘑菇街实践SRE的时候，我们也不是天天把SRE挂在嘴边，也不是动不动就提DevOps、AIOps这些名词的，相反，我们提到的更多是面对某个场景，我们的容量评估应该怎么做？细化到每个应用、每个接口上限流阈值是多少，降级和熔断的具体判断策略是怎么样的？发生故障时，我们Step by Step的响应过程应该是怎么样的？需要哪些人参与？大家应该怎么协作？对于监控，怎么才能更准确？需要用到什么具体算法，参数应该怎么设定？……
+
+你看，这些问题基本都是针对具体问题和具体场景的，而且针对这些问题和场景业界都已经有非常多的经验和案例供我们参考了，也就是我们大有可为的地方太多了。你可以设想一下，如果这些问题都能够解决得很好，我们是不是就已经达到了SRE的标准了呢？我们是不是就已经是SRE了呢？
+
+我想答案是肯定的。
+
+好了，到这里，我们专栏的内容就全部结束了。Google给我们呈现的SRE是理论性的、指导性的，业内在这方面的实践还是相对稀缺。想要更好地落地SRE，那就需要我们每一个团队和每一个热爱SRE的同行一起实践、一起总结、一起分享。
+
+那还等什么，SRE并不神秘，让我们一起探索出一条适合我们自己的SRE实践之路。
+
+[<img src="https://static001.geekbang.org/resource/image/0f/77/0ff24b3805b9494193071ab274498777.jpg" alt="">](https://jinshuju.net/f/LpoFKG)