阮:云计算架构下的企业运维治理

本篇文章7337字，读完约18分钟

阮:云计算架构下的企业运维治理 12月20日至22日，第十一届中国国际数据中心行业年会在北京国家会议中心举行。本次会议由中国信息与通信研究院、云计算发展与政策论坛和数据中心联盟主办。由中国国际数据中心行业年会组委会主办，中国国际数据中心圈主办，得到众多媒体的大力支持。 中国国际数据中心圈12月26日报道，第11届中国国际数据中心行业年会(IDCC2016)于12月20日至22日在北京国家会议中心隆重举行。在中国信息与通信研究院、发展与政策论坛和联盟的指导下，本次会议由中国国际数据中心行业年会组委会主办，中国国际数据中心圈主办，得到了众多媒体的大力支持。

作为中国云计算和数据中心领域最大、最具影响力的标志性事件，IDC中国行业年会已经成功举办了10次。本次会议的规格和规模都是“上一层楼”，吸引了全部现场人员，其影响力涵盖了数据中心、互联网、云计算等所有领域。

会上，互联网龙运计算架构师阮出席会议，并于当天在IDC上市公司大会上发表了“云计算架构下的企业运维治理”主题演讲。

阮，网络龙运的计算建筑师

以下是这次演讲的文字记录:

阮·:今天，它将分为三个部分。首先，我将讨论整个云计算场景中操作和维护的特性，包括如何处理它们。第二，我将谈论什么样的架构被用来适应云计算的操作和维护。第三，我将分享最佳实践。

让我们先看看传统操作和维护将面临的挑战。在过去，基础设施的运营和维护可能是一个相对昂贵的部门。现在我们每天都在谈论云计算。至于老板，在他被这些云计算的东西洗脑后，老板想看看投资是否可以逆转。云计算是要花费更少，做得更好，并且不可逆转。所以这可能就是场景。在云计算时代，交付速度越来越快，成本越来越低，质量越来越高，这是一种趋势。从传统的运行维护到整个链条的发展，最有可能遇到什么样的情况？当业务失败时，可用性、开发和运营的损失就是这种情况。事态发展表明，事情掌握在操作和维护人员手中。如果有问题，查找操作和维护。操作和维护人员说代码有问题。有一面操作和维护墙。运行维护墙的存在不仅在质量上难以提高，而且在速度上也难以提高。开发人员说我想开发更多的功能，我想交付更多的功能，我想发布得更快，而操作和维护人员说我想保持稳定，所以速度更慢，开发得更慢。为了协调开发和运行维护之间的矛盾，我们不得不在管理方面下很多功夫，包括一些管理方面的过程规范。这方面的成本非常昂贵。

近年来，越来越多的人呼吁DEVOPS发展媒体。这并不是说我们提到了DEVOPS。明天会有DEVOPS。让我们看看DEVOPS的整个过程是如何发生的。首先，我们把开发、操作和维护放在一个大的包里。他们两个都负责可用性指数，这在责任方面是统一的。当然，在DEVOPS的早期，运行和维护的贡献肯定更大。操作和维护说我做双重工作，我做储备。我做了一些计划来防止系统崩溃，然后有一些处理计划。这一次应用程序仍然很痛苦，因为应用程序无法连接到数据库。我们去了运行维护部门，说运行维护部门可以看到数据库是好的，网络是好的。什么意思?代码有问题吗？因此，代码必须被记录，下一次发生这种情况时，开发人员说没有办法做到，但是仍然看不到，所以我们必须预先输入。开发不能再继续下去了，我们应该在应用层制定一个计划。我们可以定义一些故障场景并在代码中分配一些错误代码吗？我们将再招募3000名服务人员，如果遇到一、二、三、四种错误情况，我们该怎么办？

在这一点上，每个人都应该有这样的经历，我们的家庭负担不起拨号和跳出院子。运营商已经这样做了很长时间。因为有了应用级计划，我们的可用性将得到提高。在未来，该计划运行相对稳定。我们可以把它存放到工具中，比如一键扩展，比如一键重启，当问题出现时点击这些按钮让机器运行，这样我们处理问题的时间会得到改善，可用性会得到提高，人肉会存放到工具中。这些工具将来会更加稳定。我们能把它们写进代码吗？杀死服务人员。遇到问题时，代码会自己解决问题。所以最后，我们会发现DEVOPS过程是一个人类继续成为工具和工具继续沉淀到架构中的过程，所以我们将在未来继续迭代。

这告诉我们，事实上，在云计算时代，开发和运营是整合的，并且它们在不断变化。同时，有一种感觉，我们已经在互联网上看到了许多cow的架构和中间件。事实上，它们都是逐渐叠加的。事实上，在开始的时候，每个人都很有人情味。

让我们看看下一个问题。云计算将基本上带来产品的分层。我们原本可能是一块铁板，但现在我们可以看到许多层面。从终端到云，每个操作和维护都将分散到每一层，中央操作和维护团队也将分散。每一层都有刚才提到的体系结构和操作维护两个部分，它们应该共同将服务级别协议和质量提交给下一层。这一边的每一层都应该根据下层提供的服务水平协议承诺和它自己的质量要求来决定如何进行架构和操作。什么意思?例如，我们中间层的服务API希望是可用的。他必须看到这个层能提供什么样的可用性，然后说它离承诺还有多远，然后决定是改进架构还是加强操作和维护。二语习得中有陷阱。事实上，企业内部开发的许多应用程序并不提供所谓的服务级别协议。对于一些公共云，比如一些众所周知的公共云，有很多情况。我们认为它提供的服务水平协议具有很高的可信度。我们需要在这一层面采取两项行动。首先，我们需要制定一些规则来做访问，其次，我们需要做质量控制。

让我们看看质量控制是如何进行的。起初，没有监控。这时候，人们冲了进来。美国石油学会认为没有问题。我们看了看集装箱。如果容器没有问题，我们查看了数据库。如果数据库没有问题，我们会查看网络。这种故障定位成本相对较高。如果我们走得更远，这是大多数企业都会做的。他们将提供第三方工具来监控每一层的服务。这种监测基本上会形成一些定量指标。我们可以得到刚才提到的整个云计算的每一层和服务的量化质量指标。我们必须走得更远。我们说，最好是我有一个SDK来捕捉用户的所有请求，收集他的结果，并计算他的质量。因此，工具沉淀到架构中的仍然是刚才提到的过程。我们相信真正的服务质量实际上是我们的用户从每个请求的结果中感受到的。我会去商店和大家一起卖。商店说他承诺如何做好人。我们什么时候去那里花钱就知道了。

更进一步，我们需要实现控制，对吗？前面对班长说，控制怎么办？例如，我们公司有一项上传和下载文件的特殊服务，它将为客户处理软件开发工具包。这项服务还引入了加速下载的CDN和加速上传的高速频道。该服务不了解业务。我们发现我们使用了中国最好的CDN供应商之一，并且发现在第三步中CDN的可用性只有99.4%，这是非常低的。因此，全国各地的许多人都会对我们的应用程序有反馈问题。我们引入了第二家CDN供应商。如果该供应商无法下载，我们将自动切换到另一个供应商。通过这种补偿，我们发现我们已经从样品中证明了我们可以要求100%的样品。实际运行次数可提高到99.95%的可用率。这是在可用性方面。我们的SDK可以通过前进来实现控制。我们在SDK上做算法。如果从这条路上传比较慢，转到另一条路，我们可以做到这一切。

一套完整的质量控制进化方法可以应用于云计算的每一个层面，不仅是在互联网的请求层面，也可以应用于云的每一个层面。

让我们再看两个案例。云计算的多层依赖将如何影响质量？这是企业中最常见的服务，即用户身份验证。企业中几乎所有的应用程序都依赖于这些API，所以让我们来看看登录API。假设这个负责人承诺三个九。该应用编程接口将依次请求四个数据库。这些数据库后面必须有一个服务器，而且服务器后面必须有一个网络。让我们假设这些数据库有三个9的可用性。我把登录API放在一边，它是内部代码，它的实际可用性只有99.6%，看起来只有0.3%，但是情况是每年不到1500分钟，而且它每个月损失两个小时的可用性。如果网络不稳定怎么办？因此，所有数据库的可用性都低于99.5%。事实上，这个API的可用性将下降到98%。这太可怕了。一个月要花14个小时，负责人不到三个月就会被解雇。因此，在整个云计算从多个层面切入后，其底层服务的质量对顶层服务的质量有很大的影响。如果直接投资服务质量如此之低呢？您想更改服务提供商吗？这么远的水不能解除附近的口渴。第二个找的是PK，但是没有答应赔偿。这个看起来不错，但不知何故它也买了一年的服务并签了合同。如果我不喜欢，我就做不到，所以我变得更强了。我应该做些什么来加强这个结构的运作？

假设Mysql的可用性只有99%，如果你遇到这么低的mysqi怎么办？用两个九mysqi发送请求，此时有什么改进？另外1%的故障率只有0.01%，故障概率为1%。可获得性立即提高了两个数量级，这似乎是一种特定的药物。然而，这种方法非常昂贵，因为有许多方法可以提高可用性。这里，我们只提到我们需要根据我们所依赖的服务来决定上层应该做什么。

让我们再来看看性能问题。假设我们有一个最外层的操作和维护API，它将有n个较低级别的API，每个较低级别的API都依赖于n个较低级别的API。假设对每个基础设施的最终请求的平均响应时间是10毫秒，当然，因为响应必须遵循分布，所以它必须有99%的间隔，并且它将在1秒内下降，这是非常合理的。如果减少到100个串行基础架构请求，这一假设不会扩展。理想情况下，对于100个基础架构请求，该业务应用编程接口的平均响应时间应为10毫秒1秒。然而，100个请求少于1秒的概率只有37%。什么大于2秒、2秒、3秒、4秒，我们将继续分析。如何分配63%的概率可以从整个计算中看出。假设100个请求，99个请求小于1秒，一个请求大于1秒，概率为37%，几乎有三个请求将被发出一次。有100个请求，98个请求小于1秒，两个请求大于1秒的概率为18.5%。如果我们五次提出一个请求，我们会说整个请求是非常长的尾巴。一些请求需要十到二十秒来完成一个请求。用户当然不能接受。当我们请求一个API时，我们发现它不能变老，也不能忍受它。因此，在整个云计算的多层次依赖下，底层基础设施做得很好，但是你仍然会影响上层应用的质量。如何解决这种问题？

在行业中，它将基本遵循负载平衡方法。像腾讯的L5或阿里的微服务框架，他们将使用一些负载平衡方法来消除一些热点。例如，如果某个服务请求排队等待了两三秒钟，它将对处理该请求的实例进行一些负载保护，以便可以恢复其负载。这些是行业中的一些实践，但是特定的技术将不再被使用。

这是另一个特点，即模块化库存采购。在公共云中，我们可以根据次数和使用情况购买不同配置的服务器、不同配置的硬盘容量、IOPS、数据库实例，甚至是API项目。它的特点是内部的专业化和模块化，以及标准化的需求进入。这是什么意思？我有这么多服务器规格，你可以自己买。你也不告诉我你想要什么特殊规格。我有如此多的规格，以至于用户只有很少的选择。它带来的好处之一是，制定容量规划决策的责任已经转移到用户而不是运营商身上。模块化列表中只能购买基本资源，这是真的吗？不，让我举个例子。这是我在公司的真实经历。当时，我的一个强大团队正在开发一个应用程序，并肯定会进行安全检查。我打电话给安全检查小组，让他们帮我做些检查。打了两次电话后，他们也累了。他们只是做了一个规范，如何做操作系统，如何做安卓，以及在Java后端做什么，所以很简单。这是一个专业的过程，够了吗？还不够。因为我的应用是明星和粉丝之间的互动，所以我说为什么每次我做这个应用的时候都要检查密码软件磁盘？他说这很安全。我说这不合理。否则，我们就这么做吧。你应该将金融应用、社交应用和媒体应用标准化。然后这统一了需求的入口。我们在NetDragon中有大约7800个应用程序。每个应用程序都被分配到自己的模块。今后，安全检查小组将在每个街区共同开展更详细的工作。无论是技术还是标准，更多的差异化，他都能做出服务。因此，当我写这篇PPT的时候，我可能在网上查过了。目前，在中国有一项应用程序检查服务，但这似乎仍是一项业务。

有一个结论，最好的操作和维护是面向服务的，最好的服务必须是面向产品的，最好的产品必须是标准化的。

让我们来谈谈整个云计算运行和维护的一些特点。让我们看看如何使用一些架构来处理它们。

首先，让我们看看运营和维护的业务架构。我在这里介绍了一个三维模型。让我们先看看需求门户。我们可能需要中间件、容器，甚至是持续集成和发布的系统。第二个维度是云计算级别，分为机房环境、服务器/网络、容器/实例，然后是应用编程接口/集群。另一个维度是操作和维护，这是一个专业领域，可以分为监控/响应/计划、可扩展性、安全性、数据管理等。这个业务架构是如何工作的？我们选择安全性并以安全性为例。这是我们的云计算平台，这是一个在AWS和亚马逊数据中心运行和维护的安全计划。

最左边的列是操作和维护的需求条目，最上面的是云计算的级别。我们已经跨越了安全和云计算的层面，提出了如此多的安全点。这些要点是标准化的做法，而且要点中有很多内容。这些点可以在不同的服务上实现，然后我们会发现，像Mangodb的服务一样，我们必须自己做这个实例，集群必须自己做。为什么MYSQL要这样做，因为我们使用MYSQL实例，所以我们看不到它后面的服务器，所以我们必须自己做。实例上方的集群仍然是我们的责任。为什么S3会这样长大？因为S3本身就是一个空气污染指数。我们不必担心集群后面的实例、实例后面的服务器以及服务器后面的计算机房。剩下的由我们来做。所以你会发现，在刚才使用矩阵来穿越网络之后，它会出现这样一种不同的责任分担。

当同一案例放在第三方的物理数据中心时，就会发生这种情况。这是一个结论。每个企业可以根据自己的不同需求，在刚才的矩形上定制自己的业务结构。然后根据业务结构进行总体规划。规划完成后，就可以组建团队，包括人员配备和技能。

在业务架构完成后，我们将看到实现它的应用架构。每个企业定制的业务架构模型是不同的，应用程序架构也必然不同。只提到了两点。第一点是网龙制造的云漂浮在不同的IAAS云上。为了实现这一点，我们有一个抽象云代理，而NetDragon引入Docker来做标准化封装，以解决互操作性问题。第二，平台本身为应用程序和开发人员提供了便利，因此我们也需要进行业务操作。

在最后一部分，我们看了最佳实践和供应商访问。以前，一个人告诉我有一个业务要做，这对公司非常重要，但我们必须部署到他的数据中心。我们看了之后，发现对方是一个只有四个机柜的云计算平台。我说我们的最小部署规模是20，我们不能给出。让我们来看看整个存储是否是隔离的，网络是否是隔离的，以及最外面的网段中使用的F5和F5是否可以隔离仍然未知。当时我告诉项目经理，8000万有点难，80万是不可能的。他说不行，这份合同已经签了，必须完成。这件事发生后，我们承认了。根据刚才的商业模式，把两个维度放进去。第一个是云计算维度，第二个是我们创建的操作和维护维度。我们设定了一些实施项目，我们制定了录取标准和良好标准，然后我们还列出了未能达到录取标准的风险，最后我们得分了。这有什么好处？首先，对于许多无法做出服务承诺和没有服务承诺的服务提供商，我们需要根据我们的要求为他们提供访问权限，这样我们就可以量化供应商的能力并找出潜在的风险。下次我可以把它写进合同里。如果你必须这样做，首先应该明确责任。第二，在我们建立了这个标准库之后，我们自己选择供应商将会很方便。第三个也是刚才提到的质量控制，因为使用SLA，至少我们已经确定了哪些地方符合我们的应用要求，哪些地方不符合。应用程序会知道，它可以根据这些标准进行自己的结构和操作调整。

左边的数字在网上很容易找到。我基本上增加了七个索引，并把它变成了云软件，适用于所有的云计算软件。提到了实现逻辑和物理隔离，比如第三个成熟度级别。如何使用这种成熟度？它主要用于识别我们云软件系统中每个软件的成熟度级别，成熟度级别取决于七个指标和存在问题的地方。最后，对于我们的业务软件，它依赖于这些底层，比如nginx在哪里，mysqi的主从集群在哪里。当它达到所谓的成熟时，它取决于我们仍然必须做这些事情的事实。这也很重要。

最后，我想谈谈整个运营和维护领域的职业发展。我基本上提到了云计算工程师的能力模型，我认为它将分为三个层次。一是信息技术项目管理能力，即传统信息技术工程师所具备的能力，即体系结构开发能力和运行维护能力。基本上，每个不同类型的企业对工程师的技能都有不同的要求。例如，在传统的信息技术企业中，大多数仍然用于集成和采购。项目管理能力仍然非常重要，但是他必须有一定的架构开发能力，因为需要集成。如果是对互联网初创公司而言，直接购买是好的，它不需要做任何整合，也没有那么多旧的系统来管理。它应该更加关注上面的一些事情，比如它自己的基于云的软件架构、操作和维护以及开发。对于像英美烟草这样的企业来说，也可能不存在整合问题。它所有的软件站都是自己开发的，服务器需要定制，芯片需要定制，所以它的架构开发能力非常高。

基本上，这个模型可以被每个人用来思考。企业可以根据自己的业务需求定制模型。在定制商业模式之后，当考虑团队人员配备时，我们可以考虑我们想要招聘什么样的工程师，以及如何分配他的全部技能。最后，我们将讨论工程师的职业发展。最好的课程是成为顶级技术架构师。然而，中国只有少数一线互联网公司。他们大多从事运维行业，云计算下仍有很多人从事运维行业。他们可以转向第二个方向，即信息技术规划、管理和实施咨询的方向。今天的PPT共享没有太多的技术方面。它更多的是关于如何使用新的思维模式，包括一些新的方法来计划整个云计算的运行和维护，以及如何管理它。事实上，这也是朝这个方向的一种分享。我认为这个领域仍然有很多空的房间，每个人都可以成长。今天的分享结束了，谢谢！

运维管理SDN在云数据中心架构中的应用 SDN的概念一直在全面展开。如果我们要谈论概念落地和大规模应用，就必须离不开SDN在云计算数据中心的实际应用。云数据中心对网络提出了灵活、按需、动态和隔离的要求，并对SDN进行集中控制