1.SRE：Google运维解密 --- 介绍

1.系统管理员模式负责将现成的软件组件部署到生产环境中，对外提供某种业务服务。系统管理员的主要工作在于应对系统中产生的各种需要人工干预的事件，以及来自业务部门的变更需求。开发部(Dev)和运维部(Ops)。Dev/Ops 分离的团队模型的存在的问题：1.直接成本2.间接成本研发团队和运维团队背景各异，技术能力与工具使用习惯上差距巨大，工作目标也截然不同。对产品可靠性的要求理解不同，最后演变成目标和方向上的分歧及形成的内部沟通问题，最后甚至上升到部门之间的信任和尊重层面。研发和运维的焦点主要在新版本，新配置的变更的发布速度上。研发关注的是如何快速的构建和发布新功能。运维关注的如如何在他们值班期间避免发生故障。绝大部分故障是由于部署某项变更导致的。研发想要'随时发布新功能，没有任何阻拦'。而运维部门想要'一旦一个东西在生产环境正常工作了，就不要进行任何改动'。2.google 的解决之道 SRESRE 团队通过雇佣软件工程师，创建软件系统来维护系统运行以代替传统模型中的人工操作。SRE 团队有2类工程师 ：1.50% ~ 60% 是标准的软件工程师2.40% ~ 50% 基本满足软件工程师的标准，但同时具有一定程度的其他技术能力。UNIX系统内部细节和1~3层网络知识。DevOps是 SRE 核心理念的普适版，SRE是 DevOps模型在 google 的具体实践，带有一定的特别的扩展。SRE 方法论：可用性改进，延迟优化，性能优化，效率优化，变更管理，监控，紧急事务处理以及容量规划与管理。1.确保长期关注研发工作将 SRE 团队的运维工作限制在 50% 以内。SRE团队应该讲剩余时间花在研发项目上。可以将研发团队成员加入 on-call 体系中，激励研发团队构建出不需要人工干预，可自主运行的系统。每8~12小时的 on-call 轮值期间最多只处理2个紧急事件。确保有足够的时间跟进紧急事件。所以的产品事故都应该有对应的事后总结，包括以下内容：事故的发生，发现，解决的全过程，事故的根本原因，预防或者优化的解决方案。在保障服务SLO的前提下最大化迭代速度：在企业中，最主要的矛盾就是迭代创新的速度与产品稳定程度之间的矛盾。错误预算：任何产品都不是，也不应该做到100%可靠。因为对最终用户来说，99.999%和 100%的可用性是没有实质区别的。从最终用户到服务器之间很多中间系统，这些系统综合起来可靠性要远远低于99.999%。如果100%不是一个正确的可靠性目标，那么多少才是呢？这其实不是一个技术问题，而是一个产品问题。考虑如下：1.基于用户的习惯，服务可靠性要达到多少用户才会满意2.如果这项服务的可靠性不够，用户是否有其他的替代选择3.服务的可靠性是否会影响用户对这项服务的使用模式公司的商业部门或者产品部门必须建立起一个合理的可靠性目标。一旦建立，'错误预算'就是 '1 - 可靠性目标'。如果一个服务的可靠性目标是 99.99%，那么错误预算就是 0.01%。这意味着研发部门和SRE部门可以在整个范围内将这个预算用于新功能上线或者产品的创新等任何事情。错误预算可以用于什么范畴呢？研发团队需要用这个预算上线新功能，吸引新用户。理想情况下，我们应该使用错误预算来最大化新功能的上线速度，同时保证服务质量。这个基本模型建立起来之后，许多常见的战术策略，如灰度发布，1%AB测试等就全说的通了。这些战术性手段都是为了更合理的使用整个服务的错误预算。监控系统:最普遍和传统的监控报警策略是针对某个特定的情况或者监控值，一旦出现情况或者监控值超过阈值就触发报警。但这不是非常有效：一个需要人工阅读邮件或者分析报警来决定目前是否需要采取某种行动的系统从本质上来说就是错误的。监控系统不应该以来人来分析报警信息，而应该是系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。一个监控系统应该只有3类输出：1.紧急报警2.工单3.日志应急事件处理：可靠性是 MTTF(评价失败时间)和 MTTR(评价恢复时间)的函数。评价一个团队将系统恢复到正常情况的最有效指标就是MTTR。任何需要人工操作的事情都只会延长恢复时间,维护一个运维手册。变更管理：SRE的经验告诉我们，大概70%的生产事故是由于某种部署的变更导致的。变更管理的最佳实践是使用自动化来完成如下项目：1.采用渐进式发布机制2.迅速而准确的检测到问题的发生3.当出现问题时，安全迅速的回退改动需求预测和容量规划：需求预测和容量规划简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。一个业务的容量规划，不仅仅包括自然增长(随着用户使用量上升，资源用来也上升)，也需要包括一些非自然增长的因素(新功能的发布，商业推广，以及其他商业因素在内)。容量规划有几个步骤是必须的：1.必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间2.规划中必须有准确的非自然增长的需求来源的统计3.必须有周期性的压力测试，以便准确的将系统原始资源信息与业务容量对应起来。资源部署：资源的部署是变更管理和容量规划的结合物。资源的部署和配置必须非常迅速的完成，而且仅仅是在必要的时候执行，因为资源非常昂贵。效率与性能:一个服务的利用率指标通常非常依赖于这个服务的工作方式以及对容量的配置与部署上。一个业务总体资源的使用情况是由以下几个因素驱动的：用户需求(流量)，可用容量和软件的资源使用率。SRE 可以通过模型预测用户需求，合理部署和配置可用容量，同时可以改进软件以提升资源使用效率。

1.SRE：Google运维解密 --- 介绍相关推荐

SRE Google 运维解密--管理
一.迅速培养SRE加入on-call 在SRE团队的职责中,主动性任务和被动性任务兼有,每个SRE团队都坚守的一个重要目标是:利用积极主动的办法,去减少和限制被动性工作的产生. SRE培训课程推荐的 ...
SRE Google运维解密pdf
下载地址:网盘下载自动化对Google SRE 的价值 62 自动化的应用案例 63 Google SRE 的自动化使用案例 63 自动化分类的层次结构 64 让自己脱离工作:自动化所有的东西 66 ...
读SRE Google运维解密有感(一)
第一章读后感 SRE之道的理解:创建软件系统来运行和替换传统的人工操作. 在实际工作中: 1.我们执行重复性的工作,流程话,新建项目需要那些资源,那些账号,那些权限,制作成流程,一个项目来了相关同事按 ...
《SRE Google运维解密》读书笔记
SRE团队职责: 确保服务可以正常运转,主要方向包括: 可用性改进延迟优化性能优化效率优化变更管理 (渐进式发布) 监控紧急事务处理容量规则与管理 (N+2 模式,google--> ...
《SRE：Google运维解密》
2019独角兽企业重金招聘Python工程师标准>>> 前言问世近一年以来,<SRE: Google 运维解密>一书销量累计已两万余册.我想首先感谢各位读者对本书的支持 ...
读书笔记（SRE：Google运维解密）：第22章处理连锁故障
连锁故障是由于正反馈循环(positivefeedback)导致的不断扩大规模的故障. 连锁故障可能由于整个系统的一小部分出现故障而引发,进而导致系统其他部分也出现故障.例如,某个服务的一个实例由于过 ...
读书笔记（SRE：Google运维解密）：第27章可靠地进行产品的大规模发布
发布协调工程师(Launch CoordinationEngineering,LCE),LCE (a)广泛的经验 (b)跨职能的视角 (c)客观性好的发布流程具有的一些特征: 轻量级:占用很少的开发 ...
SRE（运维工程师）成长路上的十本书籍推荐
今天来整理一下自己在SRE成长路线上一些对自己帮助很大的书籍. 更多内容可以关注微信公众号"SRE说" 运维了解和入门的两本书书籍一:<网站运维:保持数据实时的秘技> ...
一文讲透研发，SRE，运维，DevOps 的区别
研发,SRE ,运维是工种,而 DevOps 是体系.如果拿足球来打比方,研发,SRE ,运维对应的就是前锋,中场,后卫这样的位置,而 DevOps 则是诸如 4-3-3 这样的阵型. 研发也叫研发 ...
常见的自动化运维工具介绍及特点、安装ansible
常见的自动化运维工具介绍及特点.安装ansible 一.什么是自动化运维? 简单来说,自动化运维就是将日常重复性工作按照事先设定好的规则,在一定时间范围内自动化运行,而不需要人为参与. 将周期性.重复 ...

1.SRE：Google运维解密 --- 介绍

1.SRE：Google运维解密 --- 介绍相关推荐

最新文章

热门文章