运维体系建设(稳定性保障体系6)

运维体系建设(稳定性保障体系6)

（本字共1995字，大约需要阅读5分钟）

容量规划方法——意图法

意图法容量规划是将服务的依赖和资源的参数用数据结构的方式记录下来，同时利用一个算法自动产生资源的配给方案。记录每个服务的真实需求和它们的选择自由度信息，所产生的容量规划在面临变动时可以快速变更，通过算法产生出一个满足最多要求项的最优解。由计算机来处理最佳情况的计算能够节省大量的人力，并避免人为疏忽。

基于意图进行容量规划的工具：将产品意图转换成一个巨大的线性规划表达式，并通过对该表达式求解，并利用一系列组合的最优压缩算法最终形成一个资源分配计划。

意图的表达

意图是服务负责人对如何运维该服务的一个理性表达，是在具体性和抽象性两个方向上的一个折中选择。

意图抽象层次举例：

层次一：我需求50个CPU资源，必须在集群X、Y、Z中，由服务A使用：直接说明具体资源量和具体位置，不说明为什么需要这些资源。此为最具体的意图。

层次二：我需要50个CPU资源，在机房X中的任意3个集群中，由服务A使用：说明具体资源和可选位置，不说明为什么需要这些资源。具有一定选择性的具体意图。

层次三：我想要满足服务A在每个机房的当前需求增长x%，同时保障N+2冗余度：说明了业务需求和具体质量要求。具有一定的抽象度，此为算法可理解的极限。

层次四：我们想要满足服务A的当前需求增长，以99.999%的可靠度运行：说明了业务需求和质量需求。具有高度的抽象度，算法分解困难度高。

图 72 Auxon系统

下面我们对各组件进行介绍：

数据信息（Performance Data）：从已布署的压力测试或监控到的性能数据中，抽取到的以往需求与资源的依赖关系。

每个服务的需求预测数据（Per-Service Demand Forecast Data）描述了以服务为对象的容量预测信息。这些需求可以来自依赖它的服务或需求描述。

资源供给（Resource Supply）：提供可以分配的基础资源上限。

资源价格（Resource Pricing）：提供基础资源的成本信息。这些信息代表了总体资源的成本。

意图配置信息（Intent Config）：向系统输入基于意图的信息渠道。以接近自然语言的格式定义服务和服务之间的依赖关系。主要提取出服务依赖项（Service dependencies）、服务约束（Service constraints）、预算优化权（Budget priorities）

服务依赖项：描述服务的可选位置

服务约束：用于预估资源用量，并将高阶资源转换成低阶资源。

预算优化权：描述在资源不够的情况下，哪些资源请求可以被牺牲掉

Auxon配置语言引擎（Auxon Configuration LanguageEngine）将Intentconfig中的语言转换成机器标准格式。并附加上隐含的需求与资源的依赖关系、需求的容量预测信息等条件。

Auxon求解器（Auxon Solver）根据配置Auxon Configuration LanguageEngine整理后的各种运算条件，结合价格、优先级、可用资源等通过运算求得最优容量线性规划解。

资源分配计划（Allocation Plan）生成可读的何种资源分配给哪个服务使用，以及哪些需求不能得到满足，并说明原因。

从Auxon系统中我们可以抽象出一些设计的哲学：

比喻法(模拟近似法)：当待解决问题的边界不够清晰时，要么因为设计方案不确定，要么因为解决方案不确定，这时不应该等待，而是应该对产品进行更快的发布和迭代。

快速发布与迭代就是不要等待完美的设计，而是设计一个比喻产品的东西，这个东西应该按照既定的规划进行产品化。

这种比喻出来的东西应该与其他部件有明确的接口，力求软件设计更为灵活，以便未来流程或策略有大的变动时（比喻变更），不需要花费很大精力就可重新实现或进行更精确的比喻。同时，也要保证这个比喻产品的东西一直有一个真实的使用案例（保证比喻有效），以确保引导设计可以满足最终真实的需求。

求解器的比喻：回到Auxon系统，这个系统一开始构建了一个简单版的求解器，称之为傻瓜求解器。并不会真正返回一个最优解，但却能让团队对该产品有远景体验有更切实的感觉。

舱壁模式：Auxon设计的一个目标是和其他自动化工具结合，从而使资源分配方案可以直接在生产环境上执行（分配资源、上下线、调整服务大小等），但在设计这个系统时，其它自动化执行系统还未可靠运行。对以上情况，auxon将“资源分配计划”功能设计的更为抽象和实用，后期使得各种自动化系统自行将其整合进来，使得用户界面友好和封装性。如果一个系统必须要有一定的复杂性，那么尽量让复杂性向内部靠拢，尽量避免用户接触复杂性的接口。

在工作中，容量规划需要经常进行的工作，规划的精确度需要根据系统规模、负载情况综合考量。明天我们聊聊稳定性保障体系的第三部分——故障管理。