演讲人：知意，阿里云开放平台资源管理产品经理
大家好，我是阿里云开放平台，负责资源管理的PD知意。今天我将会为大家来分享在多账号的云环境下，消息联系人集中管理的解决方案。
首先我们还是再来回顾一下这个典型的客户案例。我们有这样一家集团企业。这家企业下属有十多家的子公司，企业基于业务隔离，风险分散、方便分账等等一些原因，会采用多账号的资源架构来部署云上的资源。所以这家公司在云上可能就会有几十个甚至上百个云账号。
公司的一些职能管理的团队。比如说之前系列视频介绍过的像安全、合规等等。这些职能团队通常是要为企业在云上的所有账号的安全，或者是审计，或者是一些运维操作来负责。随着账号的增加，这么多的账号如何进行集中化的管就给我们的公司的这些中心的职能团队带来了一些挑战。同样我们在消息联系人管理的场景也同样遇到这些问题。我们来看一下这些问题具体是什么。
首先我们先看一下单账号是怎么管理的，第一步，我们需要先把阿里云的消息厅控制台去创建消息的接收人。我们知道云上的一些消息通知，比如说像产品的生命周期通知，财务通知，财务相关的欠费预算告警或者是一些监控运维相关的通知，我们通常是要发送给企业内部这些对口的联系人接收并且做处理的。所以公司的一些消息管理员就负责去配这些消息管理规则的人员。就要到账号里面去把这些，比如说财务运维，安全相关的这些联系人的信息，先添加到效率中进中。所以第一步我们先去创建这些消息联系人。联系人创建之后，我们看到创建的时候，其实是会填写这个联系人的一些联系方式，包括手机号、邮箱。
第二步，就是我们这个被添加的联系人，他会收到相关的验证通知。他需要点击同意接收这个账号的消息。这是第二步完成验证。
第三步，消息管理员就是要给这些联系人去绑定他要接收的哪一类的消息。
比如说财务联系人，可能就给他配置去接收账户资金的通知。那如果是运维相关的人员，给他去配一些监控告警相关的接收这方面的通知。我们单个账号的管理其实是这样的，先添加联系人，验证，验证完了之后就绑定他接收的这个消息类型。
大家可以想一下，我一个账号我的这个管理员要这么配一遍，那我有十个账号就要每个账号都要去配一遍。
所以就会存在每一个账号里都会去添加这些财务运维安全这些联系人的信息，其实就是非常的低效率的重复粘贴的工作。
另外一方面比如说我们的财务人员他要接收这些账号的通知，他要去验证。每一个账号都会收到一份验证的消息，他都要去点一遍，有十个账号他就点10遍，有100个账号他也要点100遍。除了这种重复的劳动，重复的这个工作量比较大之外，其实他还会有一些风险。比如说我们后续这个联系人离职了没有及时的更新，他可能还在持续的接收这个组织相关的通知，或者说这个联系人的联系方式发生变更了。我要到每个账号里去更新，万一忘记更新其实他的新的联系方式就收不到通知，以及组织可能也会有一些新的业务账号创建出来。比如说某一个业务团队有新的业务上云，创建了一个新的账号。那这个联系人的管理员还要记得要给这个新账号再去配置一遍联系人。如果忘记配置，那这个账号相关的通知可能就没有通知给这个对口的人员去接收和处理。
比如说我们有一些云上的一些余额不足即将欠费的同志万一没有及时通知到位，那可能就会对这个账号内的资源产生欠费，释放从而对后续的一些业务上产生一些影响。
所以我们这个联系人的管理员可能就想，在云上虽然是多账号的架构，但是我不希望对每一个账号都单独的去做这个联系人的管理。能不能给我集中的管理？就像我一人是一个账号一样进行联系人的集中管理呢？那这就是今天要给大家分享的这个方案。
我们当前支持在资源目录这款产品中集中的去添加这个组织的消息联系人，在资源目录中只需要一次添加。添加之后相关的这些人就会收到这个通知，他同意接受收这个组织相关的消息，这也只是一次的验证。
验证之后，我们就可以给这个联系人去绑定他要接收哪些账号的消息通知。在绑定的时候，我们也可以给他绑定一定的范围，也不需要只绑定单个账号，可以绑定他接收整个组织的相关的所有账号的消息通知。
下面我们可以看一下这个账号的结构。之前的系列分享中其实也跟大家介绍过，我们在云上的多账号架构中，我们会有一些职能账号，会负责一些职能的集中管理。比如说我们在前面介绍日志集中收集视频中，介绍过会有专门的日账号来去负责所有账号的日志的统一收集，有专门的安全账号来负责安全的集中管控。
我们今天的这个消息的集中管理，这个功能其实属于账号的一些基础能力的管理，我们是使用企业的管理账号，也就是开通资源目录的那个账号。在企业管理账号登录到资源目录中去配置这个消息联系人的信息。
消息联系人的集中管理，我们看到是在资源目录中统一创建。创建之后我们把它绑定到要接收的账号范围上。绑定的这个范围内所有的账号都会自动的将这个消息联系人的信息进行同步。未来，不管是联系人的信息发生变更了，还是说绑定的这个范围内有新账号加入了，它都会自动的去同步相关的通知。好处也显然易见。
首先我们解决了联系人分散管理带来的这种重复的劳动成本。联系人集中管理，他的效率更高。同时我们每一个联系人也只需要去验证一次。不需要为每个账号都同意接收一遍。这样的话其实验证起来也是比较的简单。同时第三步，我们后续有新账号加入的时候，比如说我的财务要接收整个组织的财务通知，那我给这个财务联系人绑定的是整个资源目录组织这个范围。未来这个范围内有任何新账号加入的时候，都会把这个消息联系人自动同步到我们新的账号中，也避免了这个漏配的风险。
下面我就将为大家去控制台真实的演示一下我们具体怎么样去做配置管理。
当前已经登录到我们资源目录的控制台。大家可以看一下，我们这里有一个模拟的账号结构。这里面比如说这家公司，他在云上其实会有比较多的业务账号，比如说我们X公司这个目录下，我们会有11个账号。
整个公司他的账号我们可以看，一共可能会有18个账号。这个时候我们先进到某一个账号中。比如说我们有这个账号，我们先进去看一下他的消息联系人，当前我登录到这个账号内，然后我们到这个消息控制台，交易中心的控制台。我们看到其实这个账号当前消息接收人里面只有账号的一个默认联系人。
因为我们资源目录中的账号创建的时候是使用的一个虚拟邮箱，所以手机号也是没有的。那其实他默认是没有办法接收到运营商的消息通知的，也没有联系人。那相关的这些通知，也就没有办法有效的通知到我们公司的人员。这个时候我们去用资源目录的这个联系人集中管理的功能去做个配置。
当前再返回到我们的管理账号。以管理账号的身份登录进来。这个时候就进到联系人这个页面，这个时候我们其实已经创建了几个联系人，比如说这是我创建的这个联系人，他已经完成了手机号的验证。
当前我去验证一下他的邮箱，比如说我再次发送，那我去登录到我的邮箱里面去做一个验证。邮箱其实我已经有需要验证的这个消息通知了，比如说问他是否愿意接受这个资源目录组织的消息通知，我点击确认。
这个时候其实已经完成了验证。完成验证之后我们再到这个控制台，我们刷新一下页面这个联系人。比如说我创建了一个知意这个联系人，他的状态就已经是生效了。那生效之后我这边其实在创建的时候，已经给他设置了，他要接收的是产品消息，（是在去新增联系人的时候去做的设置。）
这个时候我就可以给已经生效的联系人去绑定他要接收哪些账号的消息通知那这个时候这个目录结构就拉出来了。
我可以选择接收整个root，就是整个资源目录中所有账号的相关的产品通知。也可以选择比如说我只接收这个application下面这个X公司相关的这个范围内账号的产品相关的通知。
当前比如说选择root，点确定，那这个时候这个联系人就已经绑到这个资源目录所有账号。
那这个时候我们去验证一下。比如说我刚才这个账号，我们现在再登进去看一下这个联系人是不是已经自动同步进去了。大家可以看一下这个消息，接收人里面我们已经同步了一个叫知意的消息联系人。他接收的是产品相关的通知。我们看到产品消息里面，这相关的通知已经把知意疑给同步进来了。
其实其他的是类似的，我们只需要在资源目录中再回到资源目录中，我们进行集中的管理去配置相关的这个联系人就好。未来，比如说知意的联系方式发生变更，也可以直接在这里面去更新他的手机号或邮箱，所有他绑定的这个范围内的联系人都会自动的去更新他的联系方式。
未来，比如说联系人离职了，只需要在这里集中的去清理，去删除。所有账号中这个联系人的信息也就会直接删除，能够非常高效的帮我们的联系人管理员去提高这种跨账号消息联系人管理的效率。那我的分享就到这里，谢谢大家。
