摘要：2019阿里云峰会上海专场，阿里云高级技术专家张鹏程带来题为“云上新时代，IaaS新姿势”的演讲。本文关于如何提升云上用户的安全感和幸福感，以及从架构设计到资源编排的规划部署进行了详细地分享，最后通过资源编排实际应用场景，讲述了如何将效率使用提升起来。
直播视频回放
IT基础设施云化专场PPT下载
以下是精彩视频内容整理：
云上管理基础架构的常见痛点
在实际运维过程中会有很多的痛点和经历，不管是在线下的IT基础设施管理，或者使用云上的服务，大家仍都会遇到各种问题。这源于许多日常习惯的管理方式或者受限的约束条件导致的。阿里云列举了以下六个常见痛点：
第一，通常在构建基础架构之初时，缺少最佳实践的指导，很多时候会为了满足某些紧急的需求，未做充分设计就把整个架构搭建起来。在此之后，通常需求变化会很快，这个过程容易埋下很多“坑”，后期随着基础架构的不断改造，很容易重复踩“坑”，这是最典型的痛点。
第二，在搭建基础架构过程中，在云上跨云产品使用会遇到第二个痛点。举例来说，经典的三层架构是靠哪些云服务支撑起来的呢？前端有SLB的负载均衡，中间有ECS实例做Web服务、应用服务，后端有基于ECS自建的数据库，或使用RDS云数据库。最基础的三层架构，需要跨越云上多个控制台去做很多操作，频繁跳转和配置的过程都比较繁琐，这对于运维工程师来说体验也是较差的。
第三，互联网公司人员更替比较快，在人员更替情况下，许多经验在当时操作同学的记忆中，而没有落在文档或者流程里，这个过程往往很难追溯，甚至会出现系统运行一年半载后信任不敢动的情况，因为完全不知道系统设置和集成接口，系统黑盒化运行，这时面对新的需求往往只能选择“重构系统”了。
第四，当IT系统规模越来越大，运维人员的人数是不可能与被管理服务器规模线性增长的，所以挑战都会落在运维或SRE工程师的肩上，比如从最初每个人管理二三十台，慢慢增长到管理五十台甚至上百台的实例节点，如何高效的进行批量巡检和运维操作，也是很常见的痛点。
第五，在运维团队内部，当日常运维和异常处理的过程没有流程、方法以及标准化的沉淀时，整个过程就很难复制和传承下去，在整个团队里也缺少积累和演进的过程，这对于团队和个人发展都是非常不利的。
第六，在云上更为明显的是，从线下IDC到云上之后，没有利用云上的访问控制能力，对云上基础设施的管理没有跟云上的帐号对接起来，大家习惯于使用主帐号做各类操作，而这个过程会存在很多无法规避的风险，一旦发生安全问题后果不堪设想。
面对这么多的常见痛点，如何提高在云上管理基础架构的安全感和幸福感呢？
从安全感到幸福感
上图做了一个类比，图左是选购一台自己的爱车，在用车过程中车的安全系数对生命的保障是相当关键的，每天用车的过程可以提升生活的安全感和幸福感；图右是选择适合的云服务，业务系统运行在云上对很多的公司而言，也是身家性命的保障。那么在上云到用云这个过程中，需求层次从基础的稳定可靠的安全保障，逐步到自动化智能化管理运维，整个过程都得到了幸福感的提升。
这个过程很好理解，比如在买车的时候，大家会选择一款各方面指标过硬、可靠性和稳定性出众的品牌和车型，上云的过程亦如此，客户根据业务负载类型、对稳定性、性能的预期选择好对应的规格，满足自己的需求。
一旦车辆和云服务运行起来，最基本的都是要确保每时每刻服务状态是否在可接受的正常范围之内。在云上有全面可靠的监控保障和事件通知，类似车上的仪表盘，可以发觉任何异常，无论是实例内部的异常，还是阿里云底层的异常，一旦发现都会进行反馈，提醒用户及时对系统和云服务进行检查并采取应对措施。
在运行过程中，驾驶员和运维SRE人员都希望整个过程是可控的。很多用户的反馈也证明了这一点，他们希望在云上的每一步操作，每一个对资源属性的改动都是有一个原子操作，满足控制要求还可以自动拼装组合，达到可控的状态。
满足这些基础需求之后，会出现常见需求的叠加场景，在用车过程中就出现了自动驾驶、车道保持、乃至智能驾驶的情况；而在云上，面对上面提到的那些痛点就可以将批量的或重复的运维操作变成自动化操作，当我们把一些场景、属性以及事件的应对方式沉淀下来，还可以靠编排的方式把它们串联起来，那么面对可预见的各类问题，就可以更主动的应对，不再需要面对临危授命的挑战，而是平滑地处理，更从容地保障业务连续性。
规划部署
安全感基石——设计高可用系统架构
安全感的基石，首先需要有一个高可用、稳定的系统架构。以经典的三层架构为例，从前端的入口到应用服务器，一直到后端的数据库或者其他的访问，尽可能避免单点的存在，并利用多可用区的机制。单可用区的高可用，可以规避由节点异常导致整个服务不可用的问题，多可用区的高可用可以规避当某个可用区出现概率极低的可用区级别的故障时，仍然可以保证业务应用稳定运行。当然，无论是在单可用区做成高可用，还是跨可用区或者跨地域的高可用设计，每一个可用性级别的提升，都需要更多的投资支撑，而对于具体需要什么级别的高可用设计，可以通过业务的连续性和可用性需求进行判断，选择最适合自己、性价比最高的架构设计。
对ECS服务来说，在单可用区的可使用级别中，每个月的SLA都是不低于99.95%，换算到一个月的使用时长，不可用时间是少于22分钟。如果实例在一个月内超过22分钟，阿里云有对应的赔付级别提供补偿。对于单地域多可用区而言，服务可以做到99.99%，单月不可用时长低于4.4分钟。
面临挑战
但仅仅靠高可用架构还支撑不了整个基础设施部署过程。APP使用寿命越来越短，尤其是在很多互联网上使用的会更加明显，信息系统的生命周期相对长一些，但仍然需要持续的架构演进，面对灵活多变的需求保持架构连续性，是巨大挑战。在云上基础设施涉及到众多资源类型，跨云服务的操作和配置也是一个严重影响效率的问题。越来越多的运维开发人员、SRE工程师都会有这样的疑问：是否可以像管理代码一样管理云上基础设施，随需而变的同时还能高效管理？
针对这样的需求场景，阿里云提供了资源编排（ROS）服务， ROS实现基础设施代码化（Infrastructure as Code），首先是用模板的方式把基础设施管理起来，基础架构在资源编排服务中是一段json/yaml文件，后续有架构上的任何更新，都可以在维护模板过程中保持更新。其次要素是编排引擎，这是服务后端的引擎，职责是根据定义的模板通过编排引擎发起对云服务的操作，创建资源栈，这样每个模板就可以通过编排引擎创建出一个对应的资源栈。最后是对资源栈的管理，对于架构地演进、节点地增加、新的VPC子网划分、或者环境的复制，这些都可以通过模板和资源栈来控制，从而实现对基础设施部署过程进行全生命周期的管理。
资源编排的优势
通过资源编排可以做到三个典型的优势：
所有资源的管理部署都可以通过一键管理模板来实现。有一个经典的例子，就是SAP上云，在线下部署SAP是非常耗时耗力的，从服务器、数据库到应用软件的安装配置，整个过程往往需要几天的时间才能把系统配置起来。而在云上，通过SAP一键部署模板，在完成简单的参数配置后，一键执行就可以将SAP部署过程从几天的时间压缩成不到一个小时。
自动化编排资源，通过模板编排的方式，整个交付部署过程都可以自动化实现。通常在集团化公司内部会有一个Central IT团队负责响应各BU提出的IT需求，例如申请资源部署一个PoC环境，或者申请复制生产环境做开发测试等，如果使用资源编排，就可以预制一些模板，模板对应的就是不同系统架构，BU用户可以在IT门户申请模板调用，实现自动化交付的效果。
灵活组合多种云产品及服务。常用的云资源都在资源编排覆盖范围之内。如果在阿里云上跨云服务部署资源，可以通过资源编排快速灵活地管理起来。
资源编排典型应用场景
列举几个常见资源编排的应用场景：
第一个是组网和划分VPC网络，可以通过资源编排模板完成VPC网络划分、网段设计、虚拟交换机设置、自定义路由等操作。
第二个是ECS、SLB、RDS三层架构的经典组合，在前面已经接受就不再赘述。
第三个是ECS克隆，例如某实例是作为生产环境在运行的，我们需要一个跟生产环境类似的环境做测试，可以通过资源编排将正在运行的环境快速形成一个对应的模板将其描述出来，在云上把对等环境构建起来，就可以在里面快速的进行开发测试的项目。
第四个是对云上帐号的管理，通过资源编排快速的构建子帐号，实现子帐号的授权、登录，帮助我们在云上做更好的分权，满足企业SOD分权的权限管理要求。
丰富的模板，最佳实践的沉淀
说到编辑模板，可能觉得会有较大的使用门槛或者学习成本，阿里云尽可能降低大家使用的门槛，在资源编排上提供公共模板，每个模板都对应一类系统架构的最佳实践，用户使用模板时，可以基于最佳实践快速地将系统构建起来。
资源编排操作概览
在使用资源编排时，有一些常见的操作方式。有开发能力或者有使用模板习惯的用户，可以使用图中左边的方式去维护基础架构，上图中的例子是要创建一组VPC环境和ECS实例，后续在这个基础上的变更，同样可以使用代码迭代进行管理。另外一种可视化的操作，对于所有的资源栈，都可以在资源编排控制台上管理，页面上完成创建、查询、删除、更新等操作。上图中右侧的是比较易用的方式，如果感觉使用代码的方式仍然有一定的门槛，那么可以在资源编排提供的可视化编辑器中，通过简单的拖拽构建系统架构图，如上图，通过模板的编辑，也可以创建出来所需要的系统架构，所见即所得，非常的方便实用。
主动运维
在部署完成之后，一旦系统运行起来，就需要全生命周期的跟进管理。在日常运维中，提倡“上医治未病”，要把运维的风险前置，主动地运维，才能把各类异常风险有效管理起来。要想让运维具有安全感，基础是及时的了解各种异常，在安全感基础之上，像管理代码一样管理运维，把运维自动化编排起来，实现幸福感的体验。
安全感基石
安全感的基石是了解云上常见异常的故障和影响，虽然要做好保障措施，但各种各样的异常还是会有一定的概率出现。例如在云上使用ECS，有可能经历上述这些异常情况，无论是性能的抖动，还是实例的夯机或非预期的宕机，阿里云会根据智能诊断和监控结果向用户发送对应的系统事件。这个系统事件不仅可以通过短信、电话的方式及时通知运维人员了解发生了何种问题，还可以通过API轮询或云监控订阅让程序知道所运行的系统发生了何种问题。如今在阿里云上有越来越多的企业用户开始通过程序接入系统事件，做自动化的故障诊断和自愈，比如某个节点出现不可用情况后，可以直接切换流量到备机实现故障转移。
在这个安全感基础之上，还是会遇到一些问题，比如如何批量的巡检，做批量更新的操作，如何变成用户可复制的标准化的流程，这是在很多实际的工作环境下所遇到的挑战。与此前的思路相同，是否可以能像管理代码一样，把云上基础设施运维工作高效管理起来？
带着这些问题，与大家分享一个阿里云刚刚发布，在云上提供公测的服务，称为运维编排（OOS，Operation Orchestration Service）。它的概念与资源编排如出一辙，也是通过模板方式管理，如果将所有运维的动作都通过模板描述下来，这些模板文件就成为了标准化流程文档，在通过编排引擎的控制，实现一系列批量、周期性的动作，大大减轻运维人员的负担和手工操作带来的各种风险。
使用编排引擎在使用过程中有几个显著优势：
一是可视化的执行过程，所有的脚本，所有的模板在运行过程中处在哪个节点，是不是得到预期的效果，或者出现异常，在可视化面板上可以看到即时的状态。
二是免费全托管自动化，即无服务器（Serverless）的自动化执行过程。当用户在线下环境使用一些运维工具时，这些工具通常是客户端服务端的系统架构。用户需要自己维护运维自动化工具的服务端，但是在云上可以变成无服务化的模式，只需要管理自己运维的场景即可，执行过程无需消耗自己的计算资源。
三是高效的批量管理，在传统场景下，执行批量任务相比单一任务的管理复杂度大幅增加，通过运维编排可以进行实时的进度管理、运行状态统计和快速的错误定位，实现高效的管理效果。
四是完备的健全和审计，运维编排云云上访问控制和权限管理原生集成，无论是运维编排自身的操作，还是通过运维编排执行的对云产品的操作，都支持鉴权和审计，保障客户安全。
五是快速模板构建能力，通过丰富的公共模板库，您无需从零开始编写模板，在公共模板中找到场景的运维场景，可以快速地复制和修改，进而满足个性化运维需求。
六是跨地域运维能力，普通的运维操作只能在一个地域内完成，如果您使用了多个地域的资源，可以利用运维编排的任务循环，快速地覆盖多个地域。
典型应用场景
简单介绍四个常用场景：
第一个是批量的巡检，对于成百上千的实例检查它的资源利用率，以及做一些扩容的操作，可以通过简单的编排来实现。
二是更新镜像，这对于很多运维人员都是常用的操作，不论是安装最新的补丁，还是更新组件和服务，通常都需要进行一系列重复性操作，而使用运维编排的更新镜像模板，可以在模板中定义需要更新的配置内容，然后一键执行完成镜像的更新。
三是需要审批或事件驱动的复杂运维场景，如果运维过程中需要二次确认，比如有时一个人操作生产环境风险很大，这时可以通过运维模板的二次确认的机制保障生产安全；或者面对基于某种条件触发才会执行的场景，利用运维编排的事件触发器，更好实现事件驱动的自动化运维。
四是定时任务，比如需要每天零点做一些清理的操作，也可以设定定时周期性的任务去执行。
最后，上图中的操作概览与资源编排相类似，所有的运维转化为代码脚本的方式，把运维的标准化操作沉淀下来，更新可以在模板的版本管理中完成。在控制台页面上可以定义不同的模板，有公共模板，自定义模板，在执行过程中可以看到执行过程是不是符合预期，或者针对执行错误进行必要的操作。
编排服务助力云上DevOps闭环管理
综上所述，资源编排和运维编排帮助我们更轻松、更高效地管理云上基础设施，也帮助我们在云上更顺畅地运行DevOps体系。在DevOps体系中，包括从计划、编码、构建、持续测试、发布、部署、运维、监控的全过程，在基础设施部署和运维阶段，资源编排和运维编排可以很好的组合起来支撑DevOps体系，在此基础上，通过与云上其他开发运维服务的有机结合，帮助用户最终达到完全自动化闭环的效果。
上云实现了IT基础设施云化，在云化的环境中标准化、自动化、智能化是必然的趋势，希望资源编排和运维编排能够成为大家管理云上基础设施的利器，提升整体的部署运维效率，让更多的用户在云上获得安全幸福的体验。
