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

1.系统管理员模式
	负责将现成的软件组件部署到生产环境中，对外提供某种业务服务。系统管理员的主要工作在于应对系统中产生的各种需要人工干预的事件，以及来自业务部门
  的变更需求。开发部(Dev)和运维部(Ops)。

  	Dev/Ops 分离的团队模型的存在的问题：
  	1.直接成本
  	2.间接成本
  		研发团队和运维团队背景各异，技术能力与工具使用习惯上差距巨大，工作目标也截然不同。对产品可靠性的要求理解不同，最后演变成目标和方向上的分歧及
  	  形成的内部沟通问题，最后甚至上升到部门之间的信任和尊重层面。

  	研发和运维的焦点主要在新版本，新配置的变更的发布速度上。研发关注的是如何快速的构建和发布新功能。运维关注的如如何在他们值班期间避免发生故障。绝大部分
 故障是由于部署某项变更导致的。研发想要'随时发布新功能，没有任何阻拦'。而运维部门想要'一旦一个东西在生产环境正常工作了，就不要进行任何改动'。


2.google 的解决之道 SRE
	SRE 团队通过雇佣软件工程师，创建软件系统来维护系统运行以代替传统模型中的人工操作。
	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 可以通过模型预测用户需求，
	  合理部署和配置可用容量，同时可以改进软件以提升资源使用效率。