SRE的偏见看这里！

前言

❝

《SRE实践白皮书》：

Google在2003年启动了一个全新的团队--”SRE团队“，该团队旨在通过软件工程的方法提高应用系统的可靠性；随着SRE相关理论和实践在Google的日臻成熟，SRE实践也从Google慢慢扩散到了整个行业。

❞

作为浩瀚运维大军的我们，可能更多的是通过《SRE: Google运维解密》、《SRE运维之道》这两本书才触摸到SRE的神秘概念与原则，但这似乎离我们满腔热血的去推崇还相差甚远。

读后感

从运维大侃侃交流群中小伙伴们关于SRE的读后真实感受如下：

1. SRE运维之道，这本书非常非常值得看，再次强烈推荐，国内很多解读SRE的，各自有各自的理解，但是都有自己场景和局限性。尤其不要迷信国内大厂。
2. 看过，但是好多场景没遇到过，没体会。
3. 相比GOOGLE的SRE，我认为它更丰富和多元，尤其适合团队管理者看，很多团队管理者不看这些内容，只是听了一言半语，就来推动团队转型，可能会把大家折腾够呛。
4. SRE我认为对于个人职业发展来说，是一个好的职业发展方向，提升了个人职业发展天花板。对于团队发展来说，它的杠杆率不高，只能说是阶段性的价值点吧，真正的高价值内容，我个人认为还是平台工程。

   

是不是很出乎意料，这些声音来源于一线运维及运维管理者们的感慨，突出缺少价值的支撑，无论是利己还是利它！当然SRE追求的核心目标：可靠性、可扩展性、性能、自动化、监控和告警、故障恢复，大家还是更习惯于将其归纳为SLA/SLO、容量管理、DevOps、可观测性等几方面进行建设。

做后感

凡事讲求知行合一，我们要在理解SRE的核心理念后，结合实际工作体验来更好的深刻体会SRE：

1. 传统运维还是挺有用的，在运维规则制定，稳定性，安全性方面做得比SRE好很多；
2. SRE这个名词，我们不要太过于执着，其本质还是运维；
3. SRE就是专注于平台稳定性的运维，开发各种工具满足稳定性；
4. 只是给了个名字，大公司可能会划清；中小公司在意这个？
5. 在中国的SRE，相对是一个中国国情的SRE版本，国内和国外本质的差异，其实还是在文化上的差异；
6. 严格意义的国外SRE我们没有，但是技术上契合的很多，应该也是我们自己的文化特色吧；
7. SRE不过就是运维对敏捷开发的部分妥协而已；
8. 现在的趋势是：不管你做自动化还是devops还是往云原生去，都是让你想尽办法把自己时间节省出来去干其它更多的事情，不是说多有价值的事情，而是你一个人通过各种工具可以干几个人的事情；
9. SRE不是开发，并且独自一个人单打独斗的开发，也不遵循开发的流程，也没有多严格的管控，小规模的使用短期没啥问题，长久了问题会一堆；
10. 运维与优化并非简单的守底线工作，而是需要与开发紧密协作、不断创新和优化的过程。通过引入新技术、优化流程和提高自动化程度等手段，运维团队能够为企业创造更大的价值，推动企业的持续发展；
11. SRE或者运维开发，比较适合中国国情的方案，就是有一个懂程序逻辑但是不写代码的运维，做方案设计，然后交给开发团队来做。因为国内你只能招到看着设计做程序的开发，你招不到能自己设计方案的开发；

    

从以上运维小伙伴们的反馈，可以看出SRE貌似在我们实际工作中水土不服，不外乎以下几点原因：

• 传统运维的价值仍然发挥主要作用；
• 工作中没有SRE文化的支撑；
• 以结果为导向，缺少过程的演进；
• 企业和个人都没有走出舒适区；

无论是哪种原因，我们也没有必要去过渡迎合，顺其自然才能历久弥坚！