toil

注：因为评论功能尚未开通，所以欢迎大家公众号留言讨论，因为后面还会有个番外篇，专门有一部分用来回答问题，如果大家有什么疑问可以公众号留言，我会选择一些典型的问题和答复放在文章中，感谢大家支持！ 上篇介绍了关于SRE、PE和应用运维的一些理解和业界部分公司的玩法，这一篇写一下应用运维在具体做的一些事情和组织方式，看看为什么这个岗位越来越受到重要，越来越受到重视，他的价值到底体现在哪里。然后分析下应用运维这个职业方向的发展趋势，希望对于当前正置身于这个行当的同学能有一些帮助和启发。 关于SRE的定位 首先抛个结论出来， SRE的目标不是Operation，而是Engineering，是一个是“通过软件工程的方式开发自动化系统来替代重复和手工操作”的岗位 ，为了保证达成这个目标，Google强制约定了50%的工作法则，SRE至少保证50%的时间是在做自动化开发的工作上，实际这个比例可能会更高，所以SRE运维的工作内容是低于50%的。书中相关的描述如下： Common to all SREs is the belief in and aptitude for developing software systems to solve complex problems. 所有的SRE团队成员都必须非常愿意，也非常相信用软件工程方法可以解决复杂的运维问题。 这里我个人觉得更准确的理解应该是

云原生的定义 Pivotal 是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源Java开发框架，成为云原生应用架构中先驱者和探路者。 Pivotal最初的定义 早在2015年Pivotal公司的Matt Stine写了一本叫做 迁移到云原生应用架构 的小册子，其中探讨了云原生应用架构的几个主要特征，符合12因素应用： 面向微服务架构 自服务敏捷架构 基于API的协作 抗脆弱性 我已于2017年翻译了本书，详见 迁移到云原生应用架构 。 CNCF最初的定义 到了2015年Google主导成了云原生计算基金会（CNCF），起初CNCF对云原生（Cloud Native）的定义包含以下三个方面： 应用容器化 面向微服务架构 应用支持容器的编排调度 重定义-云原生（Cloud Native） 到了2018年，而随着仅几年来云原生生态的不断状态，所有主流云计算供应商都加入了该基金会，且从 Cloud Native Landscape 中可以看出云原生有意蚕食原先非云原生应用的部分。CNCF基金会中的会员以及容纳的项目越来越多，该定义已经限制了云原生生态的发展，CNCF为云原生进行了重新定位。 以下是CNCF对云原生的重新定义（中英对照）： Cloud native technologies empower

谷歌SRE的7条原则 拥抱合理的风险 最大化系统的稳定性不仅毫无意义，而且会适得其反。不切实际的可靠性目标限制了新功能交付给用户的速度，而且用户通常不会注意到极端的可用性(比如99.99999%)，因为他们的体验是由最不稳定的组件决定的。 拥有100%的可用性需求严重限制了团队向系统交付更新和改进的能力。想要交付许多新特性的服务所有者应该选择不那么严格的SLOs，从而让他们在出现无关紧要的bug时可以继续交付。 服务所有者关注可靠性，因此他们可以选择更高的SLO。SRE准则将这种可接受的风险量化为“错误预算”。当错误预算耗尽时，重点就应该从新功能开发转移到提高可靠性。 服务水平目标SLO（Service Level Objectives） 站点可靠性工程(SRE)规程决定系统的可用性目标，并使用来自工程师、项目所有者和客户的输入来度量可用性。 如果没有一致的方式来描述系统的正常运行时间和可用性，团队间的交流和合作将会很有挑战性。运维团队不断地灭火，但是开发人员很少主动地修复错误。如果没有对正常运行时间的清晰度量，产品团队可能不同意可靠性是一个问题。 所以SLO是推动SRE学科发展的主要因素。SRE确保每个人都同意当可用性超出规范时应该做什么，以及如何度量可用性。这个过程包括所有项目相关的人员的领导。SREs与相关人员一起决定Service Level Indicators