读书笔记(SRE:Google运维解密):第18章 SRE部门中的软件工程实践

  • SRE进行软件工程非常合适和有效的原因是:
    (1)SRE组织内所拥有的Google特有的生产环境构建知识的深度和广度使得SRE工程师可以设计和实现出能够应对大规模部署,能够在灾难中优雅降级,可以和其他基础设施项目和工具良好集成的软件。
    (2)SRE是自己工具的直接使用者,所以SRE能够深刻理解要开发工具的重点在哪里。
    (3)与这些工具的直接用户——其他SRE——的密切联系使得获取直接的和高质量的用户反馈变得很容易。向一个对问题和解决方案都很熟悉的内部团体发布工具可以让开发团队更快地进行迭代。内部用户一般对UI的不足和alpha版本的问题有很强的包容性。
     
  • 传统的容量规划方法:
    (a)收集对未来项目需求的预测
    (b)制定资源的采购、构建和分配计划
    (c)评审,并且批准这个计划
    (d)部署和配置对应的资源

缺点:

  • 不可靠性:传统的容量规划过程容易产生出一个非常不可靠的资源配给计划,该计划会由于出现某些看起来很小的改动而全盘失效,例如:
    1)该服务可能出现了效率下降的问题,从而需要更多的资源以满足同样的业务需求。
    2)该服务变得更受欢迎,用户“需求”增加,导致资源的需求也随之增加。
    3)某个新计算集群的上线日期推迟。
    4)与性能有关的某个产品设计决策变化导致服务的部署规模改变,从而导致资源需求改变(例如,产品决定每个视频需要存两份,而不是一份,将会导致资源用量大幅变化)。
  • 耗时巨大,同时不够精确

 

  • 基于意图的容量规划
    将服务的依赖和资源的参数(也就是意图)用编程的方式记录下来,同时利用一个算法自动产生资源的配给方案,包括在哪个集群中将多少资源配置给哪个服务这些细节。如果需求、供给,或者某个服务的产品需求发生变化,我们可以随时重新生成这项计划,以便更好地分配资源。
     
  • 完整表达某个服务的意图所需要的信息:
    (a)依赖关系
    (b)性能指标
    (c)优先级信息
     
  • 将软件开发体系引入专注于服务运维体系的团队中:
    (a)这个目标是一个技术问题,更是一个组织架构问题。
    (b)在SRE中进行软件开发真正要实现的目标是什么。推广更好的软件开发实践,还是想通过软件开发得出一些可以在团队间共享的自动化方案,甚至成为组织内部的标准?

指导经验:

  • 创建并且宣扬一个明确的信息:
    1)该软件方案能够持久地对新SRE员工起到加速作用。
    2)减少同样一个任务的执行方式,使得整个组织可以从某个单独团队的成果中获益,以便促进信息流通。
  • 评估组织的能力:通常情况下,SRE团队缺少作为一个产品团队构建和交付完整产品的经验。为了能更好地开发有用的软件,我们实际上要创建一个产品团队
  • 发布并且迭代:
  • 不要降低标准

更多相关内容:请点击查看