2.SRE与DevOps的关系
作者：互联网
问题：
1.已知的那些所谓最佳实践方案都高度依赖于环境，无法进行广泛的应用。运维团队的工作该怎样良好的开展，也是一个尚未解决的大问题；
2.业界经常将运维视为一个成本中心，想要取得实质性的改变变的举步维艰；
3.上述原因推动了IT领域的工作改革，解决这些问题的最新方案有了两个独立的称谓-DevOps和SRE。
一.DevOps
背景情况：
DevOps是一套松散的实践理论、指导原则和工作文化，旨在打破IT组织中开发、运维、网络和安全各自为政的局面。核心为推动CALMS；
CALMS模型:Culture文化、Automation自动化、Measurement监控,、Sharing分享；
推动CAMS的每一项实践都依赖于工作文化的支持。
核心思想：
1.不再各自为政，打穿部门墙
知识的极度孤立、对局部改进的激励、缺乏协作，在很多情况下，都对业务产生了明显的影响。
2.意外不仅仅是某个人的孤立行为而导致的，而是因为在发生了不可避免的意外故障时，保障措施的缺位
传统、守旧的企业往往会本能地向下挖出“背锅侠”，并给与惩罚；相反，把重心放在如何更好地从事故中恢复比防范意外发生更有意义。
3.做改变得少食多餐，每次的变更要小一点，做的次数要多一点
这种模式结合自动测试、出错回滚，就可以实现变更管理方式的转型，变迁到CICD。
4.工具是DevOps的一个重要组成部分，特别是对于变更管理而言，工具是一项重要的工作，并非常依赖于特定的工具
5.准确的度量至关重要
二.SRE
背景情况：
SRE（网站可靠性工程）是一个工作岗位，是我们探索的一系列工作实践方式，以及一些使这些工作实践充满动力的信念；如果你认为DevOps是一种理念和工作方法，那你就可以认为SRE实现了DevOps中所描述的部分理念，而且比“DevOps工程师”所定义的工作岗位更具体、更清晰。
因此，在某种程度上，SRE类实现了DevOps的接口。
SRE具体原理：
1.运维痛点也是软件问题
SRE的基本信条：做好运维是一个软件开发问题。
SRE应当使用软件工程方法来解决问题，涉及流程变更和业务变更等很多方面，也包括同等复杂但很传统的软件问题，例如通过重构来消除业务逻辑中的单点故障等等
2.以服务质量目标（SLO）为准绳
SRE不会企图提供100%的可用性，产品团队和SRE团队会为服务的用户群体选择合理的可用性目标，并以SLO为准绳来管理该服务
SLO文化含义：作为利益相关者之间协作决策的准绳，SLO一旦违反了，那么一切设计只能无可辩驳的推倒重来。
3.尽量减少琐事
对于SRE而言，任何需要人工操作的、重复性的运维任务都是非常不受待见的，我们相信，对于那些需要由机器来做的运维任务，通常情况下就应该让机器去完成
其它：
1.确定本年度要自动化的工作
明确：哪些内容需要自动化、在什么条件下自动化、如何自动化。要采用软件工程的方法来解决问题，而不是一次又一次的去做琐事。一个SRE团队最终会让所有能自动化的事情都自动化，留下无法自动化的东西。
在Google环境下：要么引入更多服务，直到仍剩余至少50%的工程时间；要么在自动化方面非常成功，于是就可以去做其它完全无关的事情。
2.故障解决的越快，进度就越快
SRE参与工作的主要收益并不只是提高可靠性，尽管这也是显而易见的事实。它实际上还改善了产品开发的输出。
3.与开发人员同舟共济
SRE往往倾向于关注生产问题，而不是业务逻辑问题，由于在工作中他们要采用软件工程工具来解决问题，于是他们也拥有与产品开发团队同样的技能。
通常，SRE在所负责的服务的可用性、延迟、性能、效率、变更管理、监控、紧急响应和容量规划方面具有特殊的专业知识。这些具体能力是SRE为产品和相关产品开发团队提供支持的基础。
4.岗位虽不同，工具可统一
不同团队之间的工具差异越大，他们改善各自工具的成本就越大，企业的整体收益就越小。
总结：
DevOps集中精力去打穿大型组织中的壁垒，SRE通常是面向服务（并面向最终用户）而非面向整体业务。
标签：关系,运维,SRE,DevOps,SLO,自动化,团队 来源： https://www.cnblogs.com/mmworld/p/16139722.html