开发者学堂课程【企业运维之弹性计算原理与实践：【视频】-《OOS 与总结》】学习笔记（一），与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1039/detail/15320
【视频】-《OOS 与总结》
内容介绍：
一、云上运维的挑战
二、OOS 基本概念
三、OOS 模板
四、OOS 案例
五、总结
OOS 做一些运维编排上的一个动作。是因为其实有很多这种企业级的客户，或者是做运维的同学好，其实都是想要通过一些这种比较快速的方式，能够对于云上的资源进行一个比较迅速或者说比较自动化的一些运维的方法。如果是在这种情况下呢，每个云厂商它的一个做法是不同的，有的可能会这种批量调用 API ，有的可能会通过一些写一些这种脚本，比如说阿里的一个 cra 这些方式来去做，本身阿里云它其实也是提供了一个方式去让你统一的去编排，或者统一的去对云上的实例做一些操作，然后我其实也不光是ecs甚至是其他的产品，比如 rds 和 slb 这些其实都会用到批量去做一些运维的操作。 OOS 这样的一个产品。然后第二个说对于 0os 跟 0ss 可能不是特别清楚，因为个 OOS 它其实它的概念叫 observation of service 。做的是运维的一些编排。 oss 其实是针对云存储的一个概念，我们讲一些什么云盘或者oSSBucket 上面做的一些东西。所以其实是不太一样的，第三个说有的同学反馈说是希望加入一些技术编程的知识。最后技术编程这些知识其实这样的，OOS 地方会涉及到一些语法的编写。包括之前可能还没有讲到的一些，比如可以用一些 share 之类的，但是因为这堂整个体系针对的是企业运维的一个基础课程，针对的客户更多的是比如说刚刚接触到 eCS 或者接触到弹性计算的这一部分运维同学，以及对于运维比较了解，想要知道一些大型企业客户或者是中宝的时候，需要注意哪些地方的这些最佳实践的一些同学。在这些方面编程其实是没有涉及到的。如果对于技术编程有一定要求的一些同学，或者说想要了解更多的知识，可以多多去关注开发者学堂的一些其他的课程，我们其他课程也会涉及到，比如说 DEVOPS 类似于这样的一些服务。当这些课程可能会介绍一些编程的部分。
一、云上运维的挑战
今天就正式进入话题， OOS 运维编排，今天会从4个大点的去讲，第一个目前为什么 OOS 会出来，它的一个背景，以及他目前云上运维面临哪些挑战。第二块其实更多的是对于 OOS 基本概念的一个介绍，到底它有哪些部分组成？模板里面需要填一些哪些东西，因为我们常常会接到一些客户反馈的一些问题，或者运维同学过来问就说你们 OOS 该怎么写我知道说就我想达成目的，我需要填哪些参数，我要定义哪些角色。会介绍一下 OOS 的基本概念，第三个 OOS 的一些模板，我们常见的有哪些模板在上面供客户可以直接一键去使用，如果有别的需要的话，其实可以去通过改它的一个模板。更好的去把问题或者说你的定制化需求解决掉。第4个 OOS 真正在企业当中用的些案例，说在哪些场景下 OOS 会被使用。
1、行业发展趋势
然后第一块儿其实主要讲一下现在的行业发展趋势。
（1）纯手工阶段
因为自动化的运维编排发展的程度是不一样，最早的这种纯手工的模式也非常依赖用最基础的这种 gui ，控制台去完成所有的任务，对运维同学的要求比较低，可以直接通过一些这种带截图的一些步骤去发给客户，然后或者发给运维同学，运维同学只要是按照步骤一步一步走，其实问题不大就可以完成最基本的运维动作。但是到后面自动化的要求越来越高，因为不可能人力每天都通过这种 gui 的方式去一个一个点，这样其实效率很低的。
（2）半手工半自动化阶段
所以就有了这种半手工半自动的一些形式，比如日常会用到的一些有一些需要脚本去运维写一些指令，比如记起来的一些这种盈利的一些文件，或者是我想要对云上做一些批量的操作，可以调用一些 API 。时候对运维人员的一个挑战是不一样的，它可能更多的去会有一些脚本编程些能力，然后熟悉一些命令行的操作，但是有很多的复杂的操作，还是需要纯手工的去配置，因为这种情况下可能遇到这些情况会较为复杂，可能还是需要人工记录。
（3）高度自动化阶段
再到后面比较高级的一些自动化的阶段，它其实有一个自动运维的一些运维编排的一些系统。无论是通过以前的 drinkings 表现在开源的一些今天是一些 puppet answer ball 这些自动运维的一些环境或者系统,还是说不同云厂上他可能给提供的一些现有的一些 saas 化的一些能力，这些其实都是比较高度自动化的一个情况集成了所需要的一些操作系统，它 answer ball 什么 puppy 的，其实可以针对于各种各样的，无论是云厂环境还是普通的线下操作，都可以去做适配的这样的一些操作。
（4）标准化运维阶段
整体来讲到现在阶段，更多的一些企业级的用户对于运维的一个要求会越来越高，以前可能只是单纯 OPS 。现在更多的概念，无论是从 Google 个时候提出 DEVOPS 概念，还是现在各个厂商或者互联网的大公司，他们对于 DEVOPS 全占公司的一些定义。会越来越广泛，你需要不仅要了解说产品的一些能力，写代码能力，产品能力更要对一些运维的一些知识，包括云上的一些知识有一定了解，所以在DEVOPS的概念是越来越来越演进职能越大。然后功能越强，并且他所需要掌握的基本上就越来越多，在阶段其实需要知道一些 cACd 的流程。
（5）AI OPS 阶段
到最后其实讲到的一个最厉害的一个状态叫做 AI OPS 。自动化的最终目标，现在其实很少能够达到 AI OPS 的概念，比如有一些场景其实是可以实现的，比如说大数据自动预测一些故障的发生，其实在阿里云是有这套东西的，并不是说通过真正出问题。比如说主认为这些情况包括前两节课修，主动运维情况是不是真正等到了硬件出问题了。我才去告警，需要客户再去做一些响应，主动运维动作做一些迁移其实并不是这样的，我们有很多情况下都是预测到硬件会有相应的一些故障。包括一些大数据的积累，一些日志的判断等等，通过这些 AI 的方式来去预测到，可能在接下来的3~5天甚至一天之内。大概率事件它会发生档期的一个情况或者硬件受损的情况，在这种情况下我们会推送相应的主动运维的一些事件，然后让客户进行一个重启。
所以是这样的一种情况刚才少 role 了一点，对于我们的整体的一个主动运维的一个动作不是特别了解，这里稍微再拓展一下。本身主动运维动作除了刚才讲到的 AI OPS 的一个能力，其实它中间里面还涉及到各种各样的一些技术特点，包括相应的后台的一些能力，包括主动运维它的首先第一项如果发现诊断可能会存在风险，它第一可能会去做的事热线。如果热线出问题之后才会去发运维事件，比如说对应的一些型号没有库存。或者是热迁移我们会分各种各样的版本，比如说他是不是在对应的版本下找不到对应的一些这种无论训化组件，他并没有符合要求的一个手机或者是一个空间给到你。然后它的运维或者说热线已失败，还有一种情况说不满足热线的条件他现在其实在一个流量高峰期，比如举一些大客：快手，字节，他们其实对于无论是 tCp 的 session ，还是说内存使用率或者是 CPU 多核的一个使用情况都是非常高的，在日常的业务高峰期，所以在这种情况下热迁移他是做一些内存的预拷贝以及真正的数据迁移。
如果对于 tcp session 比较多，以及内存使用量比较高的情况下，其实热迁移是很难在预期之内完成了，就有可能会造成内存上的数据有些丢失。这样的风险为了规避就会导致热迁移我们制定的某些条件导致热迁移已失败。才会推到冷迁移，给客户推主动运维事件的这样的一个过程，说你可能觉得热迁移或者说推主动运维事件可能在体感上会比较多，尤其是像一些大客户，他可能用的实例是几万台甚至十几万台。在这种情况下，更多的是我们前期做了足够多的一些操作，包括一些运维热迁移等等，但是因为各种各样的一些限制，然后没办法最后才给客户去推需要客户响应事件去做一些重启等等，这里查看一下让他知道宕机，或者我们主动运维的这些事件其实都是经过了层层技术 AI OPS 或者是一些热迁移，包括一些资源上的一些轮转，然后包括版本的一些更替迭代等等这些操作，最后才能够保障现在的稳定性并且没办法给客户在推宕机事件。
AI OPS 是最终的一个形态，但是最终自动化的形态在特定场景下才能够使用。并不是所有的情况下都可以使用，其实整体来看，欧美它对于自动化的一个程度是会特别高的，因为人也少，然后包括 IT 的发展的进程来讲，无论是运维，包括使用一些因为编排的一个工具。其实都是相对来说比较领先的。所以在这方面海外的一些客户，他们对于这种自动化运维包括对阿里云，现在用一些请求，或者说他们的需求会越来越多。而现在国内相对来说除了一些大课之外，他们对于自动化的一些要求要求比较高，很多的这种中小型的客户，更多的还是通过 GUI 的方式，或者是通过一些初级的一些脚本进行自动化的一些运维。其实包括有些客户可能他可能对于阿里云的 api 包括 SDK 都不是很了解，然后用也只是处于初级的一些调试的一个阶段。在这种情况下其实我觉得大家对于后续就建议大家都可以用起来，无论是使用你熟悉的一些编程的语言，来去做一些 API 调用或者是简单的先尝试一下怎么去使用，比如说 API explorer 或者用
postman 去调用一些API的操作来对基本的一些云资源进行一些创建，或者说 ecs 的停止关闭或者是 describe 这些操作，其实都是对于 API 的一个体感会更明显。
2、云上运维的挑战
（1）效率难以满足敏捷需要
回到刚才的话题对于云上的一个运维有这么多的一个需求，包括海外他们这种外企，他们可能对于这种多元的一些管控包括运维有要求，才促使了他们更多的去用一些用于运维编排的一些能力或者有一些 DEVOPS 的能力，第一点其实对于效率会比较低，比如去做一些 CACD 操作。其实无论是说从操作的一个效率来讲，还是说从做运维的时间窗口来讲，其实都是比较对于运维员都是不太好的。
（2）日常管理和安全生产难度加大
第二个说对日常的管理来讲。难度会增大，因为我们没有一套标准的发布流程，可能每个人都有对于控制台些权限，我都可以去做一些操作，但是流程以及工具都非规范化造成出现人工失误的情况会很多，包括一些操作审计，包括一些权限管理，都会有各种各样的问题。
（3）告警处理效率低
然后第三点讲到的在日常生活当中，或者在做运维的同学，体感说无论是电话告警，短信告警或者是一些这种钉钉一些告警，如果真的遇到问题了，我们需要立马上线处理。在这种情况下第一是对于告警级别的一个判断，包括一些配置，第二说对于这类问题能否自动化的去做一些处理和预设一些规则，能够自动化去解决，对于运维来说其实也是一个很好的事情。所以说在此时上我们就有一些运维编排的一个产品，通过产品来去自动化的这样一些运维的一些事件，包括运维的一些能力能够进行可编排，然后编排好之后，可以让运维在云上的一些资源挑战会越来越小。
3、运维编排实现 OPS 即自动化代码
举一些例子，可以用多样化的一个模块，比如说用 JSON用
YAML 来去把资源以及我需要定义的一些对象进行代码化。其次我们对于云产品的知识覆盖面是非常广的，刚才不仅仅提到 eCS ，也提到一些 SRDBS 一些常见的一些云产品。其次可视化跟模块的克隆，你一旦做写好的模板你是可以复制并且应用到其他场景下的，如果有比较好的模板，也会被云平台所采用。然后第4个说模板
的开园，都可以贡献自己的代码，像在 get up 上一样把一些自己写的比较好的，有创意的一些运维编排的能力，能够赋能给其他的一些同学来保证说越来越多的人能够更高效地使用到运维编排的一个能力，来保证说运维的自动化能力，最后一个云上它的一个健全的一个能力，是我们刚才提到的，如果今天我给了你控制台所有的权限，我怎么保证你能够不去碰其它的一些资源，比如说我不小心误操作，不管是有没有意义，误操作删除了一个 oSS 的 bucket 。在这种情况下其实是你没办法去保障的，而在云上的运维编排，我其实是可以通过授权一些 RAM 的权限，包
括给它赋予一些 service 的 role 。通过这些赋权的授权的方式来保障他对于我的模板。对于云上资源可能只有 ecs 的一些权限甚至 ecs 很小的一部分，比如只有更镜像的一个能力，或者只有启动没有停止 ecs 能力，避免无关其他的机器其次说在此基础上我们会有自动化的一些事件编排，比如说我们会可以做一些 depend on 的一些操作，比如遇到了一些监控告警，遇到这些事件，我可以去做出一些响应。其次它的一个模板的资源，现在在官网上已经会有很多的这样一些模板了，然后第三个免费全都管，也说本身产品它是免费的。并且可以通过像我们之前说的完全自动化的一些运维的一些服务的动作。本身产品其实完完全全为了云上运维所使用的。讲完了云上运维为什么有 oSS 以及整体运维的它的一个演变。
二、OOS 基本概念
1、基本概念
接下来就看一下运维编排服务他的一个基础的一个概念，基础概念里面。它主要是用于做一些运维任务的一些管理以及执行，比如说一些典型的场景，这些场景在日常生活中，要么你是用控制台去做的，要么你是用一些批量的一些脚本去或者 api 去做的。基本基础以上批量操作运维，比如我定期会去做重启，比如 windows update 每个月的17号18号我会打新的一波补丁，打完补丁之后要做重启。定时运维比如今天我有一个为我有一个运维的操作，我可能是完全部署在杭州的。我接下来我会上同样的一套业务系统在北京，我以同样的方式，我只需要在 JSON 和 YAML 的地方，把地域变一下，最后事件跟驱动告警。如果遇到了一些云监控上的，或者说个云监控上的事件，或者说系统报出来的一个事件，我会去可以自动化去编排一些运维的动作，比如我遇到了 Cpu 的一个告警,然后 CPU 的连续超过90%超过5分钟，我会去做相应的无论是重启或者做空。这些可以做到告警或者故障的一个自愈能力。最后也有一些这种在一些运维场景下，比如可以去做一些打标把一些 ecs 比如这一批生产出来一些都打好 tag 都做好资源组的一个整理，举个例子，比如说7月7号这一天创建出来的实例他都适用于金融部门，可以把它放到金融部门的资源补位里面。然后接下来他的一些好处。
2、带来的好处
（1）省力
第一个省力，省力其实我们典型的一些场景，能够帮你更好地去对于一些 eCS 的常见用于编排的一些场景，运维场景能够做提效。
① 第一个场景
典型的场景比如,批量跟定时的操作实例，在客户这边其实有很多情况下，根据不同的一个环境或者不同的应用，都要做操作，每个系统还要看一下。它是什么业务的，业务每个月我可能在 OOS 内部，再去做一些停止之前，需要做一些比如系统，它对于数据库的应用比较敏感。需要首先保证所有的线程使用数据库的内存。些数据能够 FLASH 到 disk 。然后会有这些操作，如果有一些应用对于业务进程比较敏感的我是不是还要做一些相应的进程推出的一些操作，是不是直接这种非预期的一些官员直接进行一个关机，所以不同的业务情况不同的应用系统是不一样的。怎么去更好地识别，避免人工操作导致的一些问题，就可以通过一些。给不同的实例做达标，然后去针对不同的业务场景，去做相应的一些定期的运维，会定时运维等等。
② 第二个场景
第二种情况。如果大批量去做一些操作，比如说同时作业操作，因为之前遇到一些客户出现过一些情况，当时问题还很紧急，就比如说他在操作的时候不小心把一些可能他自己写的脚本，他可能把 TAG 弄错了导致他去重启，比如说我在对于 TAG 来去做控制台上的一个批量的充气操作，结果发现他 TAG 人为的弄错了，导致它重启错了所有的这种业务系统的一个 ECs 。就会出现非常大的一个故障的问题，所以说在这种情况下对于脚本的一个使用或者说运行编排对他来说其实是更方便的一个操作，因为代码是不会说谎的，或者说至今有问题，第二种场景是更多是用于更新镜像或者轮转升级。比如无论我去打一些 container 一些容器的一些镜像，还是说我对于这一批的实例，我需要做一些内核的升级一些 windows 补丁发布。在这种情况下，其实我是需要说能够有一套比较完整的一个规则或者是批量的一个操作来去做。如果使用到了运维其实是更省力的。
③ 第三个场景
接下来场景三，这第三点更多的我们刚才讲到的一些利用云平台的告警，比如云监控一些这种主观认为的一些操作。指定发起一些运维动作实现故障的一个自愈，比如之前提到的，比如说半夜可能2点你要爬起来。去处理一个监控的一个告警或者说一个运维事件。在这种情况下你是可以用设置好运维比如说主动运维如果在时间段内，比如说2:00~5:00之间我有主动运维事件推出。可以在时间内去进行一 ecs 的重启等等。这些其实是我首先可以去配的，其次说如果去自行的去做一些，比如我的业务方我看到了告警，我该做什么，其实有的时候业务方不清楚了，因为它更多地关注的是业务系统，而我们运维其实更了解，说在这种情况下。需要对它做哪些操作的？对于云资源的了解程度，运维部门其实更熟悉。所以这块如果能够做到自动运维这些操作，其实对于部分的一些业务业务系统或者业务部门的一些客户，他们其实是也是节省了很大的一部分人力的投入，包括一些关注度等等。
（2）省钱
然后接下来的一块刚才讲到省力第二块说省钱，省钱其实更多的在云上的一个成本的一个节约。
①第一个场景
有很多客户现在讲说云其实并不一定会节约的成本，因为云上它的资源即开即用。有可能我开了之后，突然忘记释放，或者说我们并没有对云资源进行很好的一个整理，就会导致有些机器，比如空完之后没有来得及缩容，或者说我机器长时间开着可能它的一个成本比起你在线下 ADC 用起来更高，运维编排其实有这样的一个能力，通过一些定时开关机。一些定时的去做一些停机这里应该叫做是省钱模式的一些停机，来去把一些没必要的 cost 能够给省下来。
②第二个场景
然后其次一些针对一些业务场景对于带宽的临时升配和降配能够保证说对于低峰期我的带宽能够降到比较低来满足我的业务需求。高峰期也同时可以去之前提前升级好我的带宽来保证业务的成本，弹性的能力其实在这里面是有很好体现的。这样的操作在这种自动化运维的场景下更方便并且对于日常的使用场景其实是效率来说是更高的。底下有几个比较经典的例子，比如刚才讲到的省钱模式以及电视开关机。把一些这种现实的一些机器给及时的关掉。然后如果是操作开关机的时候，可能在云平台可能需要自己去写一些脚本什么的比较麻烦，其实我们有现成的模板可以直接用的。第二个刚才讲到了周期性的去带宽升级的降级。就有一些成本。
③第三个场景
第三垂直变配。垂直变配接到一些告警。能够自动做升降配，也是为了提高运维的效率。然后整体的这一块讲到的主要两点一点提效。然后第二个说可以通过。提效的一些手段，包括运维编排手段能够保障，说我在云上资源能够及时的去释放，或者说能够降配保证说。这也是极致的利用弹性的一些能力。
三、OOS 模板
接下来 0os 一些模板， 0os 的模板其实还是非常重要的，因为在客户运维册收到的一些问题或者一些咨询，其实很多都是针对于模板怎么去写。比如模板执行失败的原因是什么？然后怎么去通过现有的模板去做一些改造首先它的整体的一个逻辑是这样。
1、使用步骤
就我需要去创建模板，或者是你利用现有的一个模板。然后接下来创建一个可视化的流程图，当我就执行了，在满足什么条件下我会执行。这样的一些操作，操作最后可以达到什么结果，我会有一个叫 SQL ID 执行的一个结果，可以 ID 是你针对于这次操作的唯一的一个 Id ，通过 ID 可以去做一些排问题的排查，或者拿 id 去找到售后的一些同学去查看到底动作的失败的原因在哪儿。首先 OOS 模板他主要支持，其实三种一种是控台。一种是自己去编写呀， YAML ,JSON。 本身分为公共模板跟自定义的模板。本身的公共模板其实可以去直接使用的，有使用的一个场景。看一下 OOS 本身的一些模板。现有的一些公共模板都有什么类型。然后应该会符合到你的日常运维环境，比如会按照执行热度去分。
2、模板的大致结构
（1）FormateVersion 和 Description
然后具体的一些模板的名称之类也有比较常见的，比如说发送远程指令更多的，可以去通过云助手的方式来去配置相应的一些运行的指令，然后它的一个 format ，比如在里面我会有相应的一些实际信息，这些信息其实应该都清楚，第一个本身版本的一个 version ，你可能在什么时候创建了。
然后接下来他的一个描述描述更多的对它的一个定义。它相当于我对他的一个态度。
（2）parameter
接下来是比较重要的 parameter ， parameter 其实我们有很多定义的一些环节，包括 region 因为 OOS 是有地域的概念，对于不同的 region ，我是需要去指定 region 的 ID 的。然后接下来一些 targets 执行的针对的一些对象，我会去标一些目标实例的一些 INSTANCE ID 然后对应的一些相应的一些数据。接下来 command type 到底执行什么样的一个脚本。
脚本其实会有很多类型在这里面，我可以去选指定的一些类型，比如说我可以指定是跑 shell，
runpython,runper,runbat,runpowershell 通过这些方式来去把输入的命令来去做一些定义，到底是哪个选项，接下来去执行些内容。包括里面它会定义用内容的一个格式，他 strain 还是其他的一些 char 等等，有一个最大范围。最后会有一些相应的一些 description ，其实也是去对应他执行的一些描述。比如 runshell, runpython ， 类似于这样会去指定一些时间。最后还有我要以一种角色去执行，比如说我是以里面的 root 去执行，它是一个单独的一个用户来去做执行。执行的时候是单独用户，username password。最后我对于执行的病发率，可以做一个相应的一个调控。
比如可能对于任务的同时执行不超过10个，因为我可能会对于runcommend 会做相应的控制。比如说我有4~5个相应的运维的一个操作和运维的一个指令，这里可以去控制，避免说任务执行太多导致一些问题，还有其实本身越位编排他也会有一些使用的限制，包括每天执行的次数，或者说同时执行些次数，对于 OOS 的官方文档的说明其实都有了，然后如果真的超过限制，其实在个执行之后的结果都会有相应的一个报错，比如说报考 concurrency 或者说超出了 rate limit ，类似这样的一些抱错都会有，然后说权限。
OOS 它其实是一个扮演的身份去替你执行操作，正常来讲是一个 user 的身份去做相应的动作。对于编排的动作来说，它是由 OOS 去扮演一个角色来去执行，到底扮演一个什么角色就取决于我给他营造一个 ram 角色， ram 角色有什么权限我就可以去执行什么样的动作，其实有很多情况下就接到客户的一些问题，都是跟相应地报错，操作被禁止了,原因是你没有给他设置足够的权限，比如说我想给客户跑 command 权限。默认 OOS service rolerole 它可能只有 ecs 的赋权限，当需要去执行，对于 slp 操作它其实是没有权限的，你可能就会去抱一个执行的指令是 forbidden 。所以在权限地方可以去做相应的一些把控，比如针对于 OOS 的脚本。只允许他用几个编辑的选项，而不是会去越界，比如不小心去更新错配置的一些动作，比如说颜色突然加了一个 delete 操作，但是其实我在这里并没有权限，操作其实是不会成功。
接下来 tasks。tasks 真正想要去执行些动作，这些动作其实都是 api 原子化的一些操作，比如首先会去 get instance ，它是拿到现有的 eCS 的。然后会做一些相应的一些 filter 。把要去跑 command 的过滤出来，然后接下来真正去执行 ecs runcommend 的一些权限。权限里面都需要包含比如说我 ecs 在什么 region 。然后包括 ecs id 它的跑的到底是 shell 还是 python 还是 power shell ？他是在哪个路径下面，它其实是通过前面讲过的一些云助手的这样的工具:阿里云 assistant 进程来去跑的.它是作用在哪个目录下面，在哪目下面去跑，他会有相应的一些结果，然后指令跑些他们的时间。然后是否有一些 parameter 用谁来跑，然后输出一些相应的一个比如说我脚本我需要赋变量。比如这里是一个 dollar ，比如需要打印时间之类的，其实这里面是一个变量，我在变量我会赋到相应的一些需要脚本里面，然后其次如果是 windows 的话我需要有一些这种具体跑的一些权限等等。
举个例子会有哪些内容来这里面跑。包括可以实现的一些动作呢，其实类似于 runcommand 的操作，可以在实例创建之后，去运行这样的一些脚本，给他做一些自定义化，比如下载一些通用的一些工具，比如说装一些相应的一些 server role ，或者说做一些yamL 的操作都是可以的。很多的这种使用场景我在做一些批量的运维的一些操作。在数字化实例的时候会使用到是其中举了一个例子，用的比较多的常见的场景，都会在公共模块下面。接下来就把刚才动作做完大体都会分为哪几个所定义的一个模板的一个结构，刚才讲到的是 format ，说版本 OOS 目前比较版本其实也没怎么更新过， OOS 的2019-6-01是一个我调用 api 的一个 api 的版本。然后第二个一个打的 tag 。第三个 parameter ， parameter 除了刚才说的些还有其他的一些操作，针对各种使用场景还有不同的一个参数可以使用，比如说我可以指定触发的时间或者说触发个阈值，比如每天的凌晨2:00~5:00我会做一些批量重启，或者是我触发到 CPU 的连续5分钟超过90%，类似于这样的一些条件都是可以通过 parameter 定义的。
（3）RamRole
ramrole 来讲是 OOS service role ，可以看自己的空行，还可以看一下OOS service role现在都有哪些权限，默认的话有 eccs 的权限，还有一些其他类型，但是如果想要加别的权限，比如自己创建一个 run 的一个权限，包括创建一个账号，然后添加相应权限的。
（4）task
接下来 task ， 你要指定从上而下的之前的动作，原子化的一些 api 的一些操作，比如说我是先去 getinstance 。刚才讲了先先拿到实例先 get instance ，然后再去跑 run command ，我对于针对实例或者针对这一批实例，我去 runcommend 跑一些云助手的一些指令。这都是具体的一些动作。然后如果写得比较复杂，她是一个 loop 的任务的话，任务可能会存在一些并发的一些子执行，我在写 task 的时候，可能会要更复杂一点。都是有一些现成的模板还可以通过模板去做下些调用。
（5）outputs
然后接下来一点 outputs 。 outputs 更多的是把一些像执行下来的结果做相应的记录，你可以把记录再输出到一些资源属性等，或者在做相应些导到别的地方， OOS 这些都是可以的。当 outputs 出来之后，可以再做相应的连续的其他几个，比如针对上一个场景我拿到的是 true 或者 false 。可以再继续进行一些 cacd 一些操作。比如批量执行一个动作，如果是 true ，可以再进入到下一个循环。比如说输入某个文件，然后我用其他程序,捕捉文件的一个里面的脚本之后，我可能再回去做其他的，比如一些数据报表的一个判断，到底整体的这几套运维的动作有没有成功？
3、模板更新镜像
然后接下来讲一下 OOS 的一个模板：模板更新镜像。
它的最主要的一个过程从 user 它去调用相应的一个镜像发布的一个模板。最开始去编辑并且去执行相应的一个公众模板，然后会输入一些参数，这些参数是比如可以输入到一些 security group id ，然后我去跑。我的 image ID 和我更新的动作。然后最后还有一些执行的指令等等这些操作。 OOS 拿到指令之后他会去更新镜像给予语言镜像创建一个临时的一个实例。然后实例他会去在 OOS 内部通过云助手去执行相应的一个动作。
比如他去装一些软件，对于问题来说，他是去装一个 nfs 的插件。或者叫 nfs 一个工具用来比如说梦或然后我会接下来去关闭实例再生成新的镜像。一整套的操作，我们最后拿到的一个结果，结果对于日常用语比较重要的是这样子，就比如有一个执行 id 。执行 id 是作为最基本的针对这次动作的一个唯一标识，然后如果有什么问题可以通过 exe c 杠的这段字符串来去找到无论是我们售后团队好还是运维团队，来去做排查。其次执行的一个开始跟结束的时间，如果你有 timeout 的话可能已经超过时间之后会导致 timeout 然后整体的执行状态失败的。然后里面就有一些具体的输入参数，是你在去写脚本或者说写模板的时候需要输入一些东西。然后最后的执行结果会告诉你，最后会给你一个，如果定义有一个输出，我这里面的书我新生成的执行好 nfs install 的操作之后形成了一个新的镜像。然后我会有相应的一些认识。到地方会打一些点。
