答疑｜没什么能阻挡你拓展边界的渴望
赵成
你好，我是赵成。
最近一直关注你的留言，我发现大家有一些共性的问题，所以专门准备了这次答疑加餐，和你分享我的一些想法，还有我看到的特别有洞见的留言，我们一起继续交流。今天我总共梳理了六个问题，前五个和 SRE 的落地及概念有关，最后一个关于个人成长，那我们就开始吧。
小团队，实践 SRE 可以从哪些方面入手？中小型公司资源有限，怎么做才能让系统全方位地稳定起来呢？
如果确实资源有限，我的建议是跟业务开发坐到一起，就不要独立去做一些事情了，这时还是以满足业务开发的需求为主。如果时间精力充足，可以先从一些重复繁琐工作的自动化入手，先提升效率再说。
再就是，团队规模小的时候，其实恰恰是提升技能全面性的机会，因为这时分工没有这么细，从网络、服务器、操作系统，再到 Web 服务器、应用服务器、数据库、缓存等等，都是学习和接触的好机会。
随着业务的增长，未来团队变大，就可以考虑 SRE 体系化了，建议先做一些分布式、微服务和高可用架构方面的知识储备，未来随着实践的深入，视野自然会逐步打开。
如何定义一个故障？有什么具体方法吗？粒度怎么界定？
定义一个故障，我觉得有两种方式。
一种是我们 SRE 课程第 04 讲中错误预算的计算方式。这种方式是从技术维度来定义，通常会用在一些技术产品中，比如云计算行业里的 CDN、云存储，或者是一些提供开放 API 调用的服务，这种产品根据调用的返回码、响应时延以及错误码等等就可以评估系统稳定性，具体方式我在课程里有详细讲到，你可以再复习一下。这里的关键还是找到能够衡量稳定性的指标，并设定稳定性指标的 SLI 和 SLO，进而推导出错误预算。如果一开始不好衡量，就先从当前的实际情况出发，比如成功率的 SLO 是 98%，那就看怎么提升到 99%，再到 99.9%，逐步提升。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文是一篇关于SRE（Site Reliability Engineering）的答疑文章，作者赵成分享了关于SRE实践和个人成长的一些想法和见解。文章围绕SRE实践中的问题和挑战展开讨论，包括小团队如何入手SRE实践、如何定义故障、SRE在项目架构设计中的作用、国内传统行业的SRE组织架构、DevOps和SRE的区别等。此外，作者还分享了关于个人成长和技能提升的建议，包括如何拓展自己的能力边界、提高英语水平和编码能力等方面的建议。整篇文章涵盖了SRE实践和个人成长的多个方面，为读者提供了丰富的技术知识和实践经验。文章内容丰富，涉及SRE实践的具体问题和个人成长的建议，对于想要了解SRE并提升自身技能的读者具有很高的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《SRE 实战手册》，新⼈⾸单¥29
《SRE 实战手册》，新⼈⾸单¥29
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(5)
- 最新
- 精选
🚩如果开发和运维都能这么配合的话。那什么都不是事了作者回复: 所以，有时候很多事情就是沟通和协作的问题，而不是技术问题。
2020-07-153
小炭以前没怎么听说SRE，一直待在传统行业。一路学过来发现其实我们一直有在做SRE的事情。只是没有明确的叫法和建立流程处理规章制度。作者回复: Google提出SRE的概念，也是将这个行业大家做的事情，体系化和系统化的整理总结了出来，当然Google的另一大贡献就是，不仅仅提出SRE，还给出了最佳实践。
2020-11-092
leslieSRE就是运维的全栈：其实觉得忽略了一点-硬件的理解；前面2本没看，不过把老师的运维体系那本书看成了"狗皮膏药",再结合自身的经验其实还是蛮容易去理解第三本书的，只是那本书距离"狗皮膏药"还有很长的一段路。作者回复: 方向对了，就不怕远。
2020-11-211
mickey谢谢老师分享，学习了。 回想以前在银行做开发，开发项目组有个独立的小组叫做故障处理组，专门负责整个系统的故障排除和处理工作，而且还建立了定期review的会议，介绍近期的故障问题和处理方案。故障组由开发组的同学定期轮岗参与故障处理工作，由老员工带新员工，这样即可以及时处理故障，也能帮助新同事快速的熟悉系统的架构、代码和业务需求、业务流程。2020-05-2116
趁早收获颇多2020-05-161
收起评论
