阿里云ram账户权限设置,阿里云账户怎么切换

阿里云ram账号权限设置，如何切换阿里云账号提到，从事API技术的同学都很熟悉。无论是在操作系统上开发软件，还是构建分布式网络服务，都离不开调用各种API。对于应用开发者来说，他们会通过各种编程语言、系统调用、各种类库、编程框架来构建系统。为了提高开发效率和统一性，出现了各种API标准，比如POSIX。这些标准的实施保证了应用不需要太多的修改就可以在各种软硬件平台上运行，极大地促进了整个IT生态系统的发展。

但就云计算的API而言，目前还没有类似POSIX的API标准，基本上是各大厂商各自为政。当然，业界的一些主流标准，比如OAS，大部分云厂商都是支持的，但是云厂商本身的API由于历史原因和技术路线的原因，往往是百花齐放。比如AWS的OpenAPI是RPC风格，Azure是WebService风格，GCP是以gRPC为主流。有很多技术上的讨论，本文想从客户体验和研发的角度说明OpenAPI对云计算整体竞争力的重要性。效率。

如果将阿里云天妃操作系统与传统操作系统相比，它也是由内核层、接口层、操作界面和业务应用组成。计算、存储、网络等核心产品构成内核，API层负责内核的控制和数据通信，各种控制接口相当于操作系统的终端/Windows/mac OS UI。基于云计算的各种行业应用都是运行在这个操作系统上的应用。

图1天妃操作系统

阿里云不同于传统的操作系统，OpenAPI自然也不同于其他API系统，比如淘宝、b2b开放平台。开放平台输出基于业务数据的服务，以便整业务生态，阿里云开放平台输出云操作系统的管控能力、数据运营能力等企业级能力。前者侧重于服务商业模式，后者侧重于服务技术基础。因此，云计算的OpenAPI体系要以服务技术开发者和企业场景为核心，保证技术体系的健全性和稳定性，对外与行业技术体系(如开源工具、第三方厂商)紧密对接，对内推动众多云服务的协同管理。

阿里云的OpenAPI有以下特点：

以上特点决定了相比传统开放平台，云上的OpenAPI更应该注重技术能力的建设，同时兼顾客户的企业级场景，从而做好体验。

图2 OpenAPI用户需求层次结构

那么云计算客户在OpenAPI领域的核心体验是什么？以阿里云上的一个实际案例为例。具体要点包括：

综上所述，客户的核心需求是：客户的业务系统要能与云平台高度自动化集成。不仅是客户，云供应商也经常强调弹性和自我修复的概念，这是由高度自动化的架构支持的。

要实现高度自动化集成，OpenAPI系统是一个综要求。与POSIX相比，一套标准、完整、高质量的API可以促进操作系统之间的兼容性，保证上层应用程序的开发和移植成本。对于云计算来说，这样的规范应该在哪些方面满足客户的需求？在实践中，我们总结如下：

此外，云计算的内部系统也需要通过API实现高度自动化。一些典型的场景，比如私有云部署、新区域拓展、单品拓展，如果不能自动部署，不利于公司整体的人效。更重要的是，实施时间会延长，客户体验会变差。

要解决上述问题，主要困难在于如何统一标准，如何建立综支撑平台体系，如何衡量服务质量，如何持续推动服务达标，如何考核客户满意度

阿里云对外的OpenAPI都是基于HTTP协议的，restful规范提出了基于资源设计的概念。然而实际上，能坚持这一原则的API并不多。常见的问题是“什么样的东西应该定义为资源？”“没有资源设计我的API不好用吗？”“我设计的时候有资源的概念，但是客户没有这个需求？”。

然而，客户的困惑是真实的：

面对客户的需求，我们需要回答几个问题：

对于云计算场景，如果没有资源模型，内部R & ampd效率也会受到影响。原因是公司客户不同于个人客户，相对成熟的企业对人、财、物、权、法的监管需求强烈。面对内部管理、盈利和监管约束的挑战，一套成熟的IT治理体系高度依赖于资源的概念，如阿里云的RAM/action trail/Config/RD/Resource Manager等。没有资源模型，这些产品就不得不定义自己的资源，分别与云产品进行通信，实现进度和质量无法保证一致。开源软件也是如此，比如terraform，它是面向资源的。甚很多平台服务，比如计费，都需要资源的概念来更好的管理。

图3资源生产者和消费者

如果资源模型可以统一，就相当于客户和阿里云有了一套面向对象的Java类或者数据库表。所有依赖这种资源模型的产品都会从中受益，在沟通中会更容易理解和保持一致性。在研发中可以提供统一的技术方案，提高效率。

所以资源编程的API设计对于客户和云平台本身都是非常重要的。如果前期不考虑，后期成本更大，肯定会影响阿里云的整体服务质量。

元数据是关于数据的数据，描述了数据组织、数据字段及其关系的信息。元数据平台并不新鲜。比如大数据领域就有很多应用。由于阿里云有上百个产品，上万个OpenAPI，资源数量肯定是巨大的。这时候就需要有一个统一的平台来管理资源信息。资源只是一个抽象，它也依赖于OpenAPI的元数据。两者结起来才是正确的。

那么统一OpenAPI/资源元数据能带来哪些价值呢：

1.促进产品体验一致性：阿里云各个产品线独立发展，但是会面临此资源非彼资源的尴尬境地，每个产品都有自己的认识，非常不利于统一客户体验。

2.沟通效率：统一的模型就像一个标准的数据库schema，能够让相关的业务方都能够在一个语境中沟通。

3.研发效率：结构化的标准模型，能够让程序代替人来处理模式化的数据；以Terraform为例，有了资源元数据，可以直接编写自动化脚本生成terraform模块，将云产品的接入效率了50%左右，过程中就节省了go语言研发资源和联调成本。

图4 基于API元数据无代码自动化生成

4.业务质量持续保障：软件研发有个痛点是云产品初次发布后，如果随着业务迭代，如何保障过往的功能正确性。以阿里云的RAM产品为例，如果我们能够将资源元数据、API访问日志、RAM的Policy与云产品实际鉴权日志放在一起，通过对比元数据声明内容与实际发生的动作，就可以检查云产品的鉴权行为是否符预期。相比于人治，基于数据和代码的自动化平台检查机制会更高效、更准确。

5.更多的业务场景赋能：Azure有一个产品叫Resource Graph Explorer，它能够按照资源维度管理平台上所有的资源，跨地域也不是问题，有点类似于windows的资源管理器。完善的元数据管理，将使得这类产品的研发变得可能。可能有人会有疑问，没有元数据就不能做吗？理论上可以，但是一定是事倍功半，因为它需要与各产品反复协调沟通，成本极高，而不是用一套平台来承载着标准化的生产流程，且不好复用，不可同日而语。

所以统一的阿里云OpenAPI/资源元数据管理，对内价值是许多围绕资源的业务开发都将变得更加轻松，甚无代码化，业务效能，对外客户将能得到与内部一致的业务模型，用户体验，更加方便地集成。

云操作系统想服务好客户，经过优良设计的API是必需品，否则用户很难快速高效地基于API层来开发和部署应用服务，会对商业竞争力造成严重影响，一个各种理念能力都是但却难以管理的操作系统谁愿意使用呢？

因此，OpenAPI不止是技术问题，也是产品问题，是产品体验的重要组成部分，需要慎重对待。

那么OpenAPI的客户体验能不能被度量？阿里云开放平台刚开始发力OpenAPI时面临的问题是：客户和内部都有人吐槽阿里云API不好用，都是点状问题抛出和客户需求驱动，没有一个体系化的方法来衡量客户体验指标，且不能规模化解决问题。

阿里云的 OpenAPI数量1万多个，点状的、模糊的反馈对解决全局问题没有帮助，且用户其实是对具体产品有概念，但针对OpenAPI概念性不强调研主观偏差更大。

阿里云的OpenAPI体验是一个全链路问题，如下图：

图5 典型OpenAPI用户使用路径

长长的链路，任何一个环节没做好都有可能导致用户体验不好，反馈的信息也是五花八门，难以抽取有效信息。因此有几个核心问题需要依次解决：

我们的做法是这样的：

1 Step1 量化

通过上述动作，我们能够自动化分析出OpenAPI用户的主要痛点，并建立数字化趋势图去跟踪。

2 Step 2：治理

上述能力，都沉淀在内部管理平台上，内部云产品可以一站式管理API及流程化参与API治理过程。

3 Step3 产品化

目标是收口外部用户的产品体验。以前OpenAPI的各项功能是分散割裂的，FY21我们将所有与OpenAPI相关的功能集成正在一个产品中，即过OpenAPI开发者门户 ，除了通过集中的产品建设用户体验外，还针对使用链路增加了troubleshooting、搜索、codesample等模块。

通过以上三步，我们整体OpenAPI体验治理大图如下：

图6 用户体验管理闭环示意图

通过这套体系运转中发现的问题，都会通过API管理平台和API开发者门户的功能上不断的完善，去逐步用户体验，从2020年的工单情况看，有比较明显的下降。

参考文献：

本文为阿里云原创内容，未经允许不得转载。

阿里账户阿里巴巴