企业架构与建模之使用ArchiMate进行分析

zoukankan html css js c++ java

企业架构与建模之使用ArchiMate进行分析
企业架构与建模之使用ArchiMate进行分析（全系列完）

4. 使用ArchiMate进行分析

      正如前面所说的那样，一个企业整体效率的提升有时并不是通过某一个领域内的优化就能达到的，而且这种忽视全局的做法往往还会造成不必要的浪费。由此可见，一个能够跨越各个领域、一致性的全局模型是实现企业整体效率提升的重要基础，而这也正是前面几个章节所描述的ArchiMate建模语言的终极目标。不过这样一个全面的企业架构模型的建立并不是最终的目标，如何使得企业内外各干系人在决策时能够做到对企业各层面中各自关注的部分有着深入、一致的洞察才是此模型的终极价值所在。要达到这样一个目标并不容易，这牵扯到如何对企业架构模型进行使用的问题，但是使用这样一个包罗万象的模型并不是一件简单的事情，仅从企业架构的规模和复杂度这两个方面来看足够让人望而生畏了。

      在解释如何使用企业架构模型来辅助干系人进行决策之前，我们首先要明确这一“辅助”的目标是什么，亦即干系人“决策”的含义。“决策”的背后总是“变化”，因为有了变化或将要发生变化干系人才需要进行决策，这既包括在“变”与“不变”进行选择，也包括在各种变化方案之间进行的抉择，而只有对企业各领域具有深入的洞察才能尽量确保选择的正确性。在决策过程中，各干系人需要对各种设计方案进行对比，在成本、质量和性能之间取得权衡，并能够对变化所带来的影响具备明晰的认识。虽然企业架构模型在逻辑上具备这些决策所需要的信息，不过就其本身的复杂度和规模而言，这些信息的获取并不是通过前面所说的几个视角以及相关的几张平铺直叙的视图就能实现的，这需要以企业架构模型为基础进行各种针对性的分析才能达成，而这些分析都包括什么，以及如何进行分析正是本章阐述的重点。

      需要注意的是，架构分析技术并不仅是一种或一套新式的用于分析架构的方法。与前面所讲的ArchiMate建模语言相类似，本章提到的架构分析方法是对所有以企业架构模型为分析对象的方法的总称，而不是仅要重新建立一套分析方法，他既包括了各领域中已经存在的分析方法，也包括了本章后面将会介绍的新的具备跨领域特性的企业架构分析方法。虽然在各领域当中现存的各种分析方法只是针对其领域本身，并且对于模型的详细度要求又普遍高于企业架构模型这一高抽象度模型所能提供的，但是这并不意味着这些技术或思想不能运用到企业架构分析当中，实际上基于跨领域的企业架构模型的分析往往需要领域已有的技术分析结果作为输入，而且由于企业架构模型的这种高度抽象性，这些已有的分析技术思想在企业架构模型中相关领域内也是兼容的。

4.1 分析技术分类

      在对架构分析技术进行详细描述之前，我们先对架构分析技术的种类划分进行概括。《Enterprise Architecture at Work》从两个维度将各种架构分析技术划分到如下图所示的四个象限之中：

      根据各种分析技术的输入和输出的类别，企业架构分析方法可分为“功能性（Functional）”和“量化（Quantitative）”这两种：
- 功能性（Functional）：功能性架构分析方法着眼于架构的功能方面。此种类型的方法可被用于判断系统与架构内容是否相符、了解变更对于架构所带来的影响，以及验证架构的正确性等。
- 量化（Quantitative）：功能性分析并不能解答诸如“多快”、“多省”这样的具有量化指标的问题，而这正是量化分析所要产出的结果。
从分析过程所采用的方式这一维度进行区分，无论是功能性的还是量化的架构分析方法均可被划分为“分析（Analytical）”和“模拟（Simulation）”这两种：
- 模拟（Simulation）：“模拟”可以看作是将模型所描述的客观对象在逻辑上进行虚拟执行的过程。根据前面所述的划分方式，模拟可以进一步划分为功能性模拟和量化模拟这两种：
- 分析（Analytical）：与模拟相比，分析并不具备统计方面的特性，而是用于为各相关干系人提供唯一且可重复的结果。分析也可被进一步划分为量化分析和功能性分析这两种：
      从以上叙述中我们可以看出，企业架构的分析方法可以被归纳到由两个维度所组成的四个象限之中，不过对于采用“模拟”方式进行的分析来说，无论是功能性的还是量化的，其本质上是以对模型的虚拟执行为基础，其具体实施算法还是以“分析”方式为基础，因而本章后续部分的重点将放到各种架构分析方法之上。

4.2 量化分析方法

      企业架构是个跨越组织中多个领域的架构，虽然组织采用的架构方法可能不同，不过就企业架构的本质来说，一个完整的企业架构至少应该包括业务、应用和技术基础设施这三个层面，因而针对企业架构的量化分析方法也应该将这些层面联系起来，从而为企业给出整体性的量化评估。这些量化评估包括多个方面的指标，他既包括诸如响应时间、资源利用率、吞吐量这样的与时间相关的性能指标，也可能是可靠性方面的度量，亦或是对成本方面所进行的考量。在本章中，我们将着眼于性能指标，介绍一种量化分析方法，用于计算企业架构模型所描述的系统的性能指标。

      通过基于企业架构模型的量化分析，我们首先可以在企业的整体范围内获得优化，因为其分析的对象包含了企业各个领域中的内容，从而避免开篇提到过的单独领域的进化非但没有导致效率的提升，反倒促成了浪费的生成；其次，虽然我们可以通过变化影响分析这一功能性分析方法来获取变更所带来的影响，不过只有结合量化分析，我们才能对这一影响具备更加深入的认识，这同时也说明量化分析和功能性分析并不是相互隔绝的，在实践过程中应该结合使用才能发挥出最大效能；再次，通过量化分析我们可以把企业这一复杂“系统”的输入（业务工作）和支持性资源（用于对业务进行支持的各领域资源，例如业务流程、应用、软硬件环境等）结合在一起，并形成联动关系，从而实现容量规划，即获取在假定业务工作量的前提下各支持性资源的容量需求。

4.2.1 量化分析方法基本原理

      对于架构的量化分析方法种类繁多，不过他们大多都是基于某一特定领域模型的量化分析方法，而对于企业架构模型来说，各种工具所关注的还是主要在于建模部分，其对于企业架构的量化分析支持的并不充分，所以接下来笔者将重点阐述《Enterprise Architecture at Work》中所介绍的企业架构量化分析方法。此企业架构量化分析方法的目标在于对企业架构模型所描述系统的各项性能指标进行考量。从前面有关ArchiMate语言的介绍中我们可以知道，并不是所有的概念元素是与性能指标挂钩的，诸如“含义”、“价值”之类的概念元素是不应该处于此量化分析方法的计算之内的，因而借鉴之前提到过的视角概念，此量化分析方法的分析基础也应该是处在某种视角下的模型视图。下图（源自《Enterprise Architecture at Work》图8.3）展示了这一视角的元素构成，以及此量化分析方法所需的输入和最终计算目标：

      从上图我们可以看出，此企业架构量化分析方法视角实际上与前面ArchiMate众视角中的层次视角非常相像，两者都是采用相互交叠的层次对各种概念元素进行组织，其中层次视角中的专用层（Dedicated layer）对应于此量化分析视角中的实现层（Realisation layer），而他们所同名的服务层（Service layer）在本质上是相同的。除此之外，这两种视角中对于层次之间的关系定义也是一致的，即都是通过“使用”和“实现”关系进行关联，其中位于下层的服务层（Service layer）为上层的服务层或实现层提供各种服务，而位于服务层（Service layer）下方的实现层（Realisation layer）或专用层（Dedicated layer）又对各种服务层所提供的服务进行了内部实现支持。需要注意的是，虽然这两种视角之间具有很高的相似度，但从定义上看两者还是具有明显的区别，由于层次视角并不针对特定的应用环境，因而在此视角之下的视图可以包含所有的概念元素，而对于企业架构量化分析方法视角来说，由于他所面对是针对各种性能指标的考量，因而此视角只包含与性能指标相关的各种概念元素。因此我们可以说，此企业架构量化分析方法视角是层次视角的一个子集或具体应用特化。

      在企业架构量化分析方法视角的两种组成层次中，服务层（Service layer）包括了业务、应用和技术领域中的各种服务行为元素，而实现层（Realisation layer）则是由以上三个领域中的各种主动性结构元素（Resource）、被动性结构元素（Object）和用于表示内部实现功能的行为元素（Internal behavior）所组成的。在实现层中，主动性结构元素（Resource）通过分配关系与内部行为元素（Internal behavior）相关联，用于表示由谁执行了何种行为；内部行为元素（Internal behavior）通过访问关系与被动性结构元素（Object）相联系，用于表示各种内部行为的执行所涉及到的各种信息以及他们之间的读/写关系。

      除了企业架构量化分析视角的概念元素构成之外，上图还展示了此分析方法的输入以及目标性能指标。图中标注在各概念元素图符之外变量代表了此分析方法所需要的各种输入（n、f、S、C），而位于各概念元素图符之内的变量则代表了此分析方法中对各概念元素所考量的各种性能指标（R、T、U），即此分析方法的输出：
- 输入：
- 输出：
      在明确了此企业架构量化分析方法所采用的视角、输入与目标性能指标之后，我们再来了解一下此方法的算法逻辑：

      上图展示了一个较为完整的企业架构层次模型。这一模型自下而上涵盖了技术、应用和业务这三个领域，不同的领域之间通过“使用”关系进行连接，即位于下方的领域为处于上访的领域提供各种服务。每个领域的内部又被细分为两个层次，而在这两个层次中，位于上方的层次包括了此领域对外所能提供的各种服务，而处于下方的层次则包括了实现本领域服务的各种内部实现元素。需要注意的是，上图所展示的是一个企业架构量化分析方法所适用的较为完整的企业架构层次模型，但这并不意味这该分析方法只能针对这种跨越三个领域（业务、应用和技术）的企业架构模型进行分析，实际上在输入信息充分的情况下，此方法也可以适用于跨域两个领域，甚至是仅有一个领域的情况下。此外，虽然图中不同层次之间相互叠加遮掩，好像只有相邻的两个领域之间才会有直接的“使用”关系，但在实践过程中跨层次的“使用”关系是屡见不鲜的，例如业务流程既可以使用应用领域提供的应用服务，也可以使用技术层所提供的基础设施服务。

      本章介绍的企业架构量化分析方法的计算过程可以分为两个步骤：
- 首先是按照自上而下的顺序（业务—>应用—>技术）将来源于外部的工作负载（到达频率f，例如600个客户请求/天）换算为每个层次中各个节点的被访问频率，即计算出每个节点的到达频率。其计算公式为：
此公式用于计算某个节点a的使用频率，即单位时间内被使用的次数。在公式中：
由此可见，虽然此公式看起来较为繁琐，实际上其意义却较为直白，即任意一个节点的总使用频率等于其本身的到达频率与对其进行直接使用或访问的其他节点各自的总使用频率在经过“使用次数权重”加权后的总和。
- 然后按照自下而上的顺序（技术—>应用—>业务），以每个节点的到达频率f和服务时间S为基础计算出每个节点的响应时间R、处理时间T和利用率U。在此过程中所涉及到的公式包括：
此公式用于计算某行为元素节点a的处理时间，即该行为元素节点处理某一事务所消耗的时间（不包括等待其所使用的其他行为元素节点在处理同一事务时所消耗的时间）。在公式中：
由此可见，任意一个行为元素节点的处理时间等于其所使用的各行为元素节点的响应时间经过“使用次数权重”加权后所得结果与其本身服务时间的总和。由于在计算性能指标时采用的是自下而上的方式，因而首先被计算的是处于最下层的基础设施行为元素的处理时间，而在这一过程中，由于这些首先被计算的基础设施行为元素并不使用其他任何行为元素，所以他们的处理时间应与服务时间相等。
在获得行为元素节点的处理时间后，我们需要通过上面的公式计算分配到该行为节点的资源节点的利用率。在公式中：
由此可见，资源节点的容量和其利用率成反比，这意味着如果在资源的利用率过高而成为性能瓶颈的情况下，提高资源的容量可以解决这一问题，不过过分提高资源的容量也会导致其利用率的下降，从而致使浪费的产生。
行为元素节点的处理时间和资源利用率是决定其响应时间的两个主要因素，因而在通过以上的公式获得这两个参量的值之后，我们需要对行为元素节点的响应时间进行考量。在公式中：
           需要注意的是，这里并没有给出具体的响应时间计算公式，而是代替以函数，这是因为各个节点在事务处理中的各异性导致无法采用统一的计算公式。例如，如果某个节点对于事务处理的数学模型符合M/M/1队列(对于节点a的访问频率符合泊松分布，且此节点的处理时间的统计特性满足指数分布)模型，那么此函数的具体表现形式就应为（其中，为节点a的处理时间，而为此节点所关联的资源的利用率），而如果节点的处理时间的统计特性不满足指数分布，那么此函数就可能需要采用M/G/1队列模型来进行表述了。需要注意的是，采用各种数学模型对节点进行建模并不是唯一办法，我们还可以结合诸如模拟技术等其他更为详尽的技术来对其进行计算。

4.2.2 量化分析方法示例

      为了详尽阐述企业架构量化分析方法，本章以《Enterprise Architecture at Work》中的企业架构量化分析方法示例为蓝本，对此分析方法的使用进行演示。在进行分析之前，我们先来了解一下示例的相关背景：有一家保险公司将文档管理系统作为其中心办公系统，公司中的多个部门都使用此系统进行办公，那么在已知工作负载和各系统的处理能力的情况下，此文档管理系统以及其他的系统或服务的性能指标如何？是否存在性能瓶颈，以及如何突破这些瓶颈呢？通过企业架构的量化分析方法，我们可以对以上问题具有明晰的认识。

      上图所示的企业架构模型视图对该保险公司的日常运行情况作了描述。为了对其中的各个元素节点计算其性能指标，此视图中还对各种输入信息进行了标注：
- 在“索赔处理流程”和“索赔提交流程”这两个业务流程之上分别标注了各自的事务到达频率：600次/天和200次/天。
- 对于每个服务元素则标注了其服务时间S。
- 在视图中的每条“使用”关系之上分别标注了各自的“使用次数权重”n。
为了明确和简化企业架构量化分析方法的使用，除了上述的几项输入之外，我们还要做如下的限定：
- 假设每天的工作时间是8小时，即上面输入的“600次/天”和“200次/天”这两个到达频率实际上为600次/8小时和200次/8小时。
- 每个节点的事务处理数学模型采用M/M/1队列模型。
- 每个相关资源节点的容量默认为1。
在获得了如上的输入和限定后，我们就可以按照下面所示的步骤进行此企业架构量化分析：
- 模型归一化处理。
- 自上而下的工作负载计算。
- 自下而上的性能指标计算。
4.2.2.1 模型归一化

      在实践过程中，企业架构模型通常与前面所述的企业架构量化分析元模型并不相符，这是因为在建模过程中建模人员经常使用各种抽象化规则来简化企业架构。例如，在一系列连续的由使用关系和实现关系组成的关系链可以被简化为关系链的两端元素通过一条使用关系而直接相连，如下图所示：

      在上图的示例中我们可以看到：在处于左半边的模型中，“数据库管理系统”应用组件直接被“管理员”所使用，不过这样的模型很明显并不符合我们正在讨论的企业架构量化分析方法元模型的要求，因而通过归一化处理后我们得到了右侧的架构模型，两者具体含义并无太大差别，只不过经过归一化的模型满足了此量化分析方法的要求，并且具备更加详尽的信息。

由此可见，所谓的模型归一化操作就是以此企业架构量化分析方法的元模型为基准，对需要进行性能指标考量的企业架构模型进行转换，其实能够符合分析方法的模型要求。就本章节的示例来说，将此示例图中所示的模型进行归一化后我们可以得到如下的模型：

      相对于原始的示例模型，此归一化后的模型所做的修改主要在于对内部行为元素的添加。从上图我们可以看出，原来的资源节点并不对外部服务进行直接的实现，而是通过分配关系为每个资源节点关联了新添加的用于表示其内部行为的功能概念元素，并且这些内部行为元素与相应的服务元素之间的实现关系也替代了原来的资源节点和服务元素之间的直接实现关系。此外，原来资源节点与其所使用的服务元素之间的使用关系也被转移到内部行为元素之上。需要注意的是，新添加的各内部行为元素节点及相关的使用或访问关系都需要分别注明服务时间和相应的使用次数权重，这其中，服务时间应与其所实现的外部服务元素的服务时间相同，而由于内部实现元素继承了原资源元素针对其他服务的使用和访问关系，所以使用次数权重也与之相同。通过以上的转换，当前经过归一化的模型符合了前面所提到过的企业架构量化分析方法元模型，但这仅仅是一个示例，并不意味着所有的非归一化模型都要遵照这个规则来进行转化，这是因为原始模型所具备的多样性，而这一规则也只是较为常见归一化规则之一，但无论采用何种规则，其最终目的都是要使进行计算的模型符合此量化分析方法的元模型。

4.2.2.2 工作负载计算

      在获得归一化的模型之后，接下来我们需要将最上层所承担的工作负载自上而下地传递给下面的各个层次。在进行计算之前，我们需要再次对此步骤所需的输入和限制进行明确：
- 工作负载来源于最上层，即索赔处理流程和索赔提交流程这两个业务流程的到达频率（分别为600件/天和200件/天）。
- 工作时间为8小时而不是24小时，所以上述的到达频率可分别换算为：
下表展示了不同的资源元素所提供的服务元素在前述的工作负载下所承担的工作负载（需要注意的是，与《Enterprise Architecture at Work》中的相应示例相比，本示例中有关的计算结果与原书中的计算结果0.0278不一致，并由此导致了的计算结果也出现了不一致的情况。笔者怀疑原书中的这两个结果与其所示的模型并不相符，如果当“损害报告搜索服务”被索赔处理流程和索赔提交流程这两个流程所共同使用，且其与索赔提交流程之间使用关系的使用次数权重时会得出0.0278这样的结果，但如果这一结果成立，那么最终的就会因为的改变而由0.02777变为0.0347，这又与原书示例结果相矛盾，因而再一次证实了书中示例的计算结果之间存在矛盾）：

4.2.2.3 性能指标计算

量化分析方法的最后一步采用自下而上的方式，对各个资源节点以及相应的行为元素节点的利用率、处理时间和响应时间进行计算。在进行计算之前，我们需要再次明确一下必要的输入和限制：
- 每个行为元素（服务元素和内部行为元素）都需要注明其服务时间。
- 每个元素节点的工作负载应已在上一步计算中获得。
- 每个资源元素节点的容量应已经确定。本示例中，每个资源节点的容量均默认为1。
- 每个行为元素节点的事务处理数学模型应已经确定。在本示例中，每个行为元素节点的事务处理数学模型均采用M/M/1队列模型。
      本示例中各个元素节点的性能指标以及计算过程总结如下：

      从上表中我们可以看出，由于资源的容量有限，所以其所分配的行为元素的处理时间会小于响应时间，并且在资源处在高利用率的情况之下，这两者之间的差别还可能会非常大，例如对于“查看组件”来说，其利用率达到84.4%，而同时其响应时间达到了处理时间的6倍以上，这也印证了虽然资源利用率高表明资源被充分利用，不过这同时也非常可能是性能的瓶颈所在，通过增加资源的容量可以改善这个问题，但是也可能导致浪费的产生，因而这两者之间需要做好权衡，但不管如何权衡，这种分析方法起码赋予了决策者更好的洞察力，使其决策更加有理有据。

      除了针对一套输入数据进行分析之外，我们还可以通过编制不同的输入数据而获取相应的分析结果，从而对某个性能指标随输入的变化而产生变化的趋势进行更为直观的观察。下图来源于《Enterprise Architecture at Work》中图8.8，他展示了索赔处理流程的不同到达频率与查看组件的响应时间之间的关系：

      如图所示，当索赔处理流程的事务到达频率达到大约651件/天时，查看组件的相应时间趋近无穷，这就证明在此种情况下该组件的利用率已经达到满负荷的100%，这也表明了此组件在当前容量下的处理极限。在此，我们可以惊喜的发现业务中的问题和IT方面的支持能力有了量化性的关联，而这种跨领域的联系也正是此量化分析方法甚至是企业架构精神的最佳体现。

4.3 功能性分析方法

      从分析目标来看，针对企业架构的功能性分析方法可以细分为静态分析和动态分析两种，前者分析的目标是企业架构的结构关系，而后者则是针对架构所描述的各种行为进行分析。相对于量化分析方法，用于分析架构基本结构和行为的方法长期以来一直是各架构分析方法的重点，不同的组织已为其贡献了很多非常成熟的分析方法，而且这其中的每个方法都需要耗费一部整书的篇幅才能描述清楚，因而本节只能对其中具有代表性的方法进行列举，详细内容还需要有兴趣的读者进一步阅读。

      静态分析是以企业架构的结构组成为目标的功能性分析方法，因而其分析主体是各种概念元素以及他们之间的结构关系，而这其中最具代表性的就当数影响分析了（Impact-of-change analysis）。顾名思义，影响分析是以由于变化而产生的影响为分析目标的功能性分析方法，这是一种通用性的分析方法，而并不是企业架构所独具的。据笔者考证，影响分析首先是被 Bohner 和 Arnold在1996年于《Software Change Impact Analysis》中所定义的，从书名我们就可以看出，该分析方法起源于软件设计领域，是用来对软件设计中的变更所产生的影响进行界定的方法。不过此书对于变更影响分析的定义却有着更为宽泛的含义，即变更影响分析旨在明确变更所可能产生的潜在结果，并对为了适应变更所应作的修改进行估计。由此可见，这一定义并没有绑定软件设计这一领域，所以将此分析方法放在企业架构中也应该是适用的。

      《Enterprise Architecture at Work》对变更影响分析在企业架构中的应用做了简要的描述，其中心思想在于：以发生变化的结构元素为起点，沿着结构型关系进行搜索，寻找与其发生关联的受到影响的各个结构性元素，再以这些结构性元素为起点，沿着之前的结构关系方向重复这个搜索过程，直到所有受影响的结构性元素被搜索出来为止。书中还通过一个示例形象化地描述了变更影响分析在企业架构方面的应用：有一个保险公司在销售保险的过程中除了自己销售外还通过第三方的代理来进行保险推销，这些代理的工作也只在于向客户推销保险产品，并保证保险合同签署之前各种文件工作的正确性。目前该公司考虑能否抛开这个代理的角色，但又不知道如此会产生什么样的影响。

      诚然这种事情的影响是无法精确估计和定义的，因为这其中包括了各种无法估计的有形和无形的影响，但是通过对企业架构进行影响分析，公司至少还是能对从业务到IT各层面中的有形的结构性影响有所认识。以下三张视图就对这种影响进行了展示：

变更影响示例—视图1

变更影响示例—视图2

变更影响示例—视图3

      以上三张视图中：第一张视图展示了由于业务角色“第三方代理”发生变化而受到影响的业务合作集合“洽谈”和“合同订立”；第二张视图展示了“合同订立流程”中由于变更而受到影响的业务交互“规范化申请”和“检查并签署合同”；最后一张视图展示了在应用层面进而受到影响的应用服务“客户管理服务”和应用组件“客户关系管理系统”。虽然这三张视图分别展示了受到变更影响的各个结构元素，但是这并不意味着所有的影响都被这三张图所涵盖了，因为视图是视角的具体表现内容，其所反映的只是企业架构的某一个方面的内容，因而对于变更影响结果的展示需要站在相关干系人视角的基础之上。实际上《Software Change Impact Analysis》根据所分析的目标对象的不同，将变更影响分析方法分为可追溯性方法和依赖性方法两种，前者着眼于需求、规范、设计元素和相关测试之间的关系，而后者则关注于程序模块、变量和逻辑等之间关系，这实际上也是站在不同视角对于变更分析方法的具体应用，与企业架构的视角精神是一致的。因而在实践过程中，我们的企业架构分析方法应该不是一个具有唯一形式的分析方法，根据视角的不同，此分析方法所实际关注的概念元素和关系应该是有所区别的。

      与静态分析方法不同，动态分析方法将企业架构的行为作为分析目标。目前，在各个领域（例如业务领域）中已经存在了很多成熟的动态分析方法。借助于这些方法，我们也可以对企业架构中的某一领域进行深入分析，并根据企业架构的跨领域特性，将分析结果延展到企业架构的其他领域之内。这其中经常用到的就是进程代数（Process algebra）和数据流网络（Data flow network）分析方法。通过这些动态分析方法，我们可以对企业架构的正确性加以验证，也可以使干系人对企业架构的行为获得更为深入的共识。
查看全文

相关阅读:
centos7 升级openssh到openssh-8.0p1版本
 CentOS7.6安装docker最新版
 通过iptables限制docker容器端口
 nginx设置反向代理，获取真实客户端ip
CentOS7.6使用Virt-manager创建虚拟机报错
 CentOS7添加/删除用户和用户组
 ubuntu14.04 部署nfs服务
 centos7 firewall指定IP与端口访问（常用）
linux下yum安装最新稳定版nginx
C语言中点操作符(.)和箭头操作符(->)