自动化系统的演进
草率地进行自动化可能在解决问题的同时产生出其他问题。 因此，虽然我们认为在大多数情况下以软件为基础的自动化是优于手动操作的，但是比 这两个选择更好的方案是一个不需要这些的系统设计一个自治的系统。或者换一种 方式来看，自动化的价值不仅来源于它所做的事情，还包括对其的明智应用。我们将讨 论自动化系统的价值，以及SRE对自动化系统的态度的演进历史。
自动化的价值：
一致性、平台型、修复速度更快、行动速度更快、节省时间
如果我们持续产生不可自动化的流程和解决方案，我们就继续需要人来进行 系统维护。如果我们要雇佣人来做这项工作，就像是在用人类的鲜血、汗水和 眼泪养活机器。这就像是一个没有特效但是充满了愤怒的系统管理员的Matrix世界
自动化的演进遵循以下路径：
1)没有自动化 73
手动将数据库主进程在多个位置之间转移。
2)外部维护的系统特定的自动化系统
SRE在他或她的主目录中保存了一份故障转移脚本。
3)外部维护的通用的自动化系统
SRE将数据库支持添加到了每个人都在使用的“通用故障转移”脚本中。
4)内部维护的系统特定的自动化
数据库自己发布故障转移脚本。
5)不需要任何自动化的系统
数据库注意到问题发生，在无须人工干预的情况下进行故障转移。
自动化程序的不同体现在三个方面：
●能力，即准确性。
●延迟，开始执行后，执行所有步骤需要多久。
●相关性，自动化所涵盖的实际流程比例。
集群上线自动化进化遵循这样一个路径：
1. 操作人员触发手动操作(无自动化)。
2. 操作人员编写，系统特定的自动化。
3. 外部维护的通用自动化。
4. 内部维护，系统特定的自动化。
5. 不需要人为干预的自治系统。
可控的故障模式
配置文件，或者服务的任何输入都应该经过正确性和准确性检查再提供给服务。服务在接收到不合理的配置文件或者输入数据时，应该继续保持之前的状态正常工作，同时发出错误输入的警报。错误的输入数据一般分为以下几类：
不正确的数 据
在处理数据之前，应该检查数据的语法，甚至在可能的情况下，检查数据语义的正 确性。同时，服务应该注意空数据、部分数据或者截断数据的可能性(服务应该在 新数据比之前的数据小N%的时候发出警报)。
过期的数 据
这些数据可能会影响到目前的数据。应该在数据过期之前发出警报。
服务应该追求在出现故障时仍能够保持工作，可能会牺牲一定程度的访问控制能力，或者使用简化逻辑。我们发现，最安全的方式是在服务收到新数据之后，仍然维持之前的配置运行，直到某个人来批准采用新数据这些数据可能是无效的。
渐进式发布
非紧急的发布过程应该是按阶段进行的。不管是配置文件改变，还是二进制文件改变， 都会引入一定的风险，我们通过小规模地应用这些变更来控制这些风险。每次发布部署的容量百分比，以及每个阶段之间等待的时间应该由服务的规模、发布的规模，以及服务所能承受的风险来决定。同时，每个部署阶段中包括多个地理位置也是好主意，这样可以更快地检测到由于流量峰谷或者不同地理区域的流量带来的问题。
整个发布过程应该是有监管的。为了确保发布过程中没有未预料的情况发生，工程师或者是一个可靠的监控系统应该对发布过程进行监控。如果出现了意外情况，回退是第一选择，后续再进行详细的分析，这样可以降低平均恢复时间(MTTR)。
发布协调检查列表
架构
架构草图，服务器类型，客户端请求类型
编程性客户端的请求
物理机与数据中心
物理机数量与带宽数量，数据中心，N+2冗度，网络QoS
新的域名，DNS负载均衡
流量预估、容量以及性能
HTTP流量与带宽预估，发布时的峰值，流量的组成，6个月的预测
压力测试，端到端测试，每个数据中心最高延迟下的容量
对其他我们关注的服务的影响
存储容量
系统可靠性与灾难恢复
当下列情况发生时，服务会怎么样
物理机故障，机柜故障，集群故障
两个数据中心之间的网络故障
对每种需要联系其他服务器(后端)的服务器来说：
如何检测后端故障，后端故障如何处理
如何在不影响客户端和用户的情况下重启服务器
负载均衡，速度限制，超时，重试，以及错误处理
数据备份/恢复，灾难恢复
监控与服务器管理
监控内部状态，监控端到端行为，警报的管理
监控监控系统
有关财务的警报和日志
在集群环境下运行服务的技巧
不要在代码中给自己发送海量邮件，会导致邮件服务器崩溃
安全
安全设计评审，安全代码评审，垃圾邮件风险，验证，SSL
发布之前的可见/可访问性控制，各种类型的黑名单
自动化与人工任务
更新服务器、数据，配置文件的方式和变更管理
发布流程，可重复的构建过程，金丝雀测试，分阶段发布
增长问题
空余容量，10倍增长，增长型的警报
扩展性的瓶颈，线性扩展，与硬件性能的同步扩展，所需要的变更
缓存，数据分片/重新分片
外部依赖
第三方系统，监控，网络条件，流量配比，发布时的流量峰值
优雅降级，如何避免意外对第三方服务造成过载
与合作伙伴、邮件系统，以及Google内部服务良好对接
发布时间与发布计划
不可改变的截止日期，外部事件，星期一或者星期五
该服务标准的运维流程，以及其他服务的运维流程
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
