SRE Foundation知识点
构建百分百可靠的服务是不可取的，因为一个服务面向用户的不止是可靠，还有创新。当可靠性达到一定的数量级后，再花费大量的成本在可靠性上而忽略服务的创新，这种方式得不偿失。错误预算出现的原因：两个团队的关注点冲突，给这个冲突提供一个缓冲区。当这个缓冲区还未满时，研发可以提高创新速度。当这个缓冲区快满时，研发就需要更多的考虑可靠性。用户对产品的体验也是需要在可靠性和创新之间权衡。而用户对不同的产品敏感度也是不同的，在不同产品中的可靠性也需要权衡。
在SRE团队的职责中，主动性任务和被动性任务兼有，每个SRE团队都坚守的一个重要目标是：利用积极主动的办法，去减少和限制被动性工作的产生。
举一个例子，假设某项服务的一个SLO为成功率99.9%，而它在4周内会收到300万次（0.1%）请求，在此期间的错误预算就是3000次，如果某次服务中断导致了1500个错误请求，那么这次事故将花费50%的错误预算。
监控系统可以衡量一个系统的可用性和质量的重要手段。简单来说就是收集各层的性能或者是业务指标，然后加以聚合和汇总，呈现出动态的视图。可以针对这些指标设置阈值和规则，进行各种各样的报警。 如Email、短信等。但是这样的报警策略并不是很有效的需要人去处理，人需要阅读错误信息，再去排查问题，这本身就是错误的。理想状态下，监控系统应该能自己分析报警信息，然后自动决策，或者是给出合理的建议，让人去选择。
变更管理的最佳事件使用自动化来完成以下项目：◦ 渐进式发布机制。 - 减少受影响面积◦ 迅速而准确的检测到问题的发生。 - 减少故障时间◦ 出现问题时可以自动的快速回滚。 - 减少故障时间
容量规划必须有几个必要的步骤：◦ 必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间。◦ 规划中必须有准确的非自然增长的需求来源的统计◦ 必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来。
SRE要负责资源的部署。添加新的资源可以是机器、或者是集群，当然添加过后还需要改动对应的配置，如负载均衡等等，这些都会对整体的稳定性有些影响，不过这个k8s下目前还是比较简单的。
一个业务总资源使用情况由以下几个因素：◦ 用户流量 ◦ 可用容量 ◦ 资源利用率。SRE可以通过需求模型的预测和监控数据来优化资源的使用率。延迟在负载高的情况下会上升，当负载到达临界值的时候，系统会逐渐变慢，甚至全部停止。SRE可以通过设置预期的延迟目标和维护足够的容量解决这个问题。
页:
[1]