「ITIL文章」【云计算运维新思路】不可变应用环境ARE辩证法+运维AIOW模型

讲师介绍

许杨毅 UCloud应用运维部总监

原百度系统部资深专家。拥有15年互联网系统平台工作经验，先后任职于百度、戴尔中国和新浪网，担任过系统运维主管、高级系统顾问、资深业务架构师和业务运维负责人，致力于互联网运维的工程化实践。

IaaS 运维的两个特点

回到IaaS的本质上，它有两个特点：

1. IaaS非常基础，构成了相当底层的用户应用环境，包括SDN／NFV网络、虚拟机over物理机等，而且它是一个多租户环境，因此单一故障必然带来乘数效应，而整体稳定性由多个子系统的指数效应决定。

2. 不可变Immutbale。从我们日常的工作经验来看，变更是现网故障的主要原因，IaaS的稳定性应该来自于运行环境的确定性。不可变是一个工程目标，而工程化的基础则是：确定性、稳定性和不可变。

ARE 的提出

1. ARE 的起源

基于IaaS运维的特点，我们提出了ARE（Application Running Eevironment）的概念。这个概念并非标新立异，而是为了更好的理解和处理IaaS下的具体问题。

我们提供了众多的产品，包括云主机、云数据库UDB、视频云ULive，UDPN跨域专线，网络可用区等，每一个产品都对应了内部的一套ARE的对象，包括软件版本、产品类型、部署环境以及其他一些定制化的分布式环境需求。

从通常的观点来看，产品上线了以后，除非是在环境的初始化部署、代码升级、回滚、漏洞修复的场景下，否则其所对应的ARE应该是不可变。

同时从软件环境配置SCM（software configuration managment）的管理角度来看，它应该是可配置的，我们因而可以用配置来描述这个环境，它的理想结构应该是树状、可继承（这会带来管理上的好处）。可因为面临业务快速迭代的挑战，这一想法并不现实。

通常实现方法：以配置管理的视角看待ARE环境；配置内容是可以预先定义、可结构化的，配置管理本身是可以代码化的，因此可以做代码管理。

2. 以栈的形式理解ARE

从形式上来讲，我们认为ARE是一个可分层来表示的对象栈；从技术上来讲，ARE是一个复合对象的集合。

ARE静态集：

{os，os_ver，kernel，gilbc，Python，PM2，JVM，编程框架}

ARE动态集：

{硬件的固件，驱动，内核动态加载的各种xxxx.ko，crontab，daemon，route table，flowTable@SDN，tunnel@SDN，***.so，应用代码  }

ARE分布式环境：

{网络拓扑，服务模块，带宽特征，业务流量特征}

如上图，左面Brendan Gregg所描述出来的堆栈，他本身是一个系统调优大师，是Topgun级别的系统工程师，我们可以看到他这个堆栈非常清楚地描述了一个操作系统的堆栈结构。

右侧是一个非常经典的LinuxI/O栈的StackDiagram。

我们想以栈的结构来表述ARE这个概念，通过栈的形式来理解应用运行环境。而在云计算的环境中，大体把它分为内核空间和内部空间两大部分。这些东西基本控制了云计算非常基础的架构，包括系统、网络、SDN。

ARE存在的问题

其实，不同团队对ARE的环境都有自己不同关注的地方，例如，云主机的研发团队，他们对KVM/QEMU感兴趣，想要控制管理它，而SDN的运维团队会对整个环境的SDN流表等配置信息感兴趣，多个团队分别以各自的视角参与到这一个环境中。

如上图，我想表达的意思是，对于这样的一个环境，形成的实际局面就是有非常多的参与部门，每一个部门对其中的一部分都以各自的视角来看问题。事实上形成的就是各个不同的团队从不同的切面(Aspect)参与到这个环境中，大家对此都有需求。

这说明了配置管理参与是多方的，事实上在多数公司中，这一类问题往往交给运维部门来负责的，运维部门碰到的问题就是怎样管理一个折中的配置环境，能不能明确地定义配置环境的组成对象、有几套配置。

带着这些思考，我们发现了一个重要的问题，对于不同的ARE环境，不同的团队有不同的目标。

产品团队对应用环境的需求

• 快速迭代
  产品研发团队觉得第一重要的是保证产品的研发速度，这个需求会导致他们对应用环境产生非常迫切、直接的需求：应用环境要能满足快速迭代、快速释放代码，因此，ARE的变化必然是一个常态。

• 管理灵活
  产品研发团队还希望ARE的管理是非常灵活的。比如，产品特性是需要灰度实现的，这导致产品部门要求可以方便的修改对ARE的集合中的一些对象，并且是在非常多的组合维度上。

  一般来讲，对于灰度能力来说有非常多的组合条件，例如，需要在一个Region某一个IDC的某一个产品针对某一类用户投产新功能，因此需要释放代码。所以，管理灵活是应用环境在研发侧的一个非常迫切的需求。

运维团队对应用环境的需求

• 配置统一
  配置统一而且希望在全网一致、全局一致，而且最好它是树状可集成的。

• 不可变immutable
  最好是上线就不能变更。

• 业务稳定
  运维对应用的稳定性负责是天经地义的？这是运维背黑锅的主要原因。

immutable只是运维的一厢情愿 - 我自己倾向于认为是这样的

上图，是我在GoogleTrend上找到的“不可变基础架构”的趋势， Immutable Infrastructure概念来自由Google的SRE团队，在2013年达到高峰，可我们不应该忽略其前提条件 → 业界顶尖工程师，强大的运维团队，稳健的业务框架，优秀的软件耦合设计。

Docker很成功的表述了这一潮流，它包装好了软件运行依赖的一切环境，可是容器化并非是万能的银弹。 良好的软件设计和开发质量，完善的测试工作流保障，稳定可靠的运行环境，成熟的CI/CD过程依然是软件应用稳定的保证。

ARE 的其它挑战

• ARE在形式上是分层栈式的—Hierarchy Stack

• 参与团队的多样化，同时各团队仅对局部负责，导致了无法找到权威的仲裁者，如何定义一个具体的ARE对象，因此传统的软件配置管理方法受阻。

• 从配置管理的视角，假设最理想的情况下，ARE是一棵可继承的树状结构，所有的配置项都有着明确的依赖关系和邻居关系，但是实际上呢？

  有一个ARE实例=OS_release，OS_VER，kernel_ver，openFlow_ver，framework，application.so
  其组合的空间，笛卡尔积是6000。

如何管理ARE？

管理ARE的思想

1. 分而治之 Divide & Conquer。

   我们希望各自的业务部门对我们刚刚描述的整体栈图中的各个部分，分别承担管理的义务和职责；

2. 民主协商 Democracy。

   如果冲突了怎么办？比如对内核的某些参数，SDN的网络组觉得应该设成A，另外的一些应用组希望设置成B，大家应该协商寻求一致；

3. 面向切面 Aspect Oriented

   我们把配置管理工具当成一个大的集合或者一个整体的立体结构，我们希望能够以面向切面的视角切到配置管理中去。

有什么收益？

1. 不再寻求预先定义一个配置，不再自上而下地定义一个ARE对象。

   例如：力图将某一个产品统一到一个确定的配置版本上

2. ARE对象从全局一致的目标变更成了一个局部一致。

3. 可自助的管理各个部门对负责的ARE子集进行管理。

   管理的工作具体包括：定义配置、提交配置、检查配置分布、提交ARE变更的申请。

如何实现ARE管理？

为了实现上述的目标，我们做了一些软件上的概念定义：

1. ARE Schema：ARE集合中的所有对象，这个schema是由运维或者系统的团队来负责并完全定义的，它是ARE的全集；

2. ARE Pattern：通过它各个业务方可以自主地设定一个ARE pattern，并且保存下来得到ARE的一个子集，从而成为一个具体的，传统概念上的软件配置对象。

例子：
3月1日出现的一个漏洞，当时出现这个漏洞以后，像我们云计算公司需要快速地修复掉，就直接带来一个线上运维的操作需求——“请在今天晚上12点以前把现网n万台机器修复完成。”

这会带来什么问题呢？
我想表达的是你永远无法预先准备好某一个具体的配置需求。一旦碰到这种问题，运维一般会做一次全网的摸查，哪些系统是这样的，因此会导出一个集合X。

通过ARE pattern，我们就可以有一个查询结果，以这个查询结果得到一组我们需要操作的列表，最终这个需要操作的列表就是我们做运维变更的对象集X，再通过我们统一作业系统去做变更。

通过我们的统一作业系统，对targeting集合X进行操作，修改ARE。

ARE的编排

我们把ARE这个对象本身作为了编排的一个重要目标或者一个对象，以它来指导业务环境的部署或者是业务的变更，以及代码的新上线、回滚、漏洞修复等等。

云计算运维模型和操作规范

上图中的云计算运维工作的模型和操作规范，是我们在内部使用的，借这个机会也跟大家分享一下，也希望听听大家的意见。

云计算环境中运维的难度更高，人为失误或者软硬件故障导致的影响范围更大，事务数量也更多。怎么解决这个问题呢？

云计算公司是我们所有托管在云上其他公司的大运维团队，怎么解决这些问题呢？

杜绝流程缺失，最小化人为失误的可能性，争取做到云计算环境下的6个sigma 的可用性保障。

1. AIOW模型

我们内部做法是通过模型来抽象操作，提出了AIOW的运维模型：

1. A - Action；

2. I - Input，这个操作之前的前置条件和输入量；

3. O - Output，这个操作结束后需要输出的东西，具体中间需要验证的东西，需要确保运行的东西；

4. W - Who/where/what/how,细节。

2. uAppo运维规范

通过口诀来实现规范：

P：优先原则

1. 故障处理原则：通知相关方→恢复业务→保存现场→定位rootcause；
2. 运维日常操作优先级：既定流程优先→请示工作导师→请示上级

B：备份一切原则

操作前备份，现场保留备份。

C：控制原则

1. 运维操作范围可控；
2. 运维操作结果可控；
3. 运维操作内容可控。

T：时间是任何操作要素

1. 任何运维事务都有时间属性；
2. 如果有标准SLA，按照标准，交付事务结果；
3. 如果非标准SLA，给出申请方预计完成时间，超时告知不可完成。

O：对象原则

1. 命名一切对象，包括运维工具、运维命令、被操作的文件/目录、操作的数据库、数据表都必须明确命名，并且引用；
2. 禁止使用口语，“你的、我的、这个、那个”；
3. 统一命名标准，uAppo-x。