大型企业适用的云平台账户体系

这些年来云计算技术突飞猛进，但我一直很怕和客户谈云平台的账户体系，因为客户有合理化需求，而（某客户说）云平台的账户设置就是在糊弄鬼。随着大部分云平台在完善账户体系，我们可以心平气和的谈一谈而非吐槽这个问题了。

 

云计算公司的技术班底大都是个人业务起家，他们最早接入的是中小企业和创业者，其账户体系并不适用于大型企业客户。大型客户上云之前都用过虚拟化、域管理、网管资源管理软件，肯定不适应这套功能单薄诡异的用户约束。本文的目的是为了让大客户有底气提出质疑，让云平台继续完善开发，最终提供符合企业级应用场景的账户体系。

 

第一.账户注册问题

 

首先我们看法务问题，如果注册时死抠法务问题，国内各大云平台会颗粒无收。

 

我随便摘取了几段账户注册的用户协议：

 

客户的云账户是唯一身份识别依据，就连交钱时也是只认账户不认人。

 

云平台有权限制客户账户下所有产品及全部功能，心情不好就不卖。

 

客户保证不会影响云平台关联公司的合法权益，其标准由云平台做权威判断。

 

这是不是有一种“客户你好，我是你大爷，爱买就买，不买就滚”的即视感？谁有资格代表公司去注册账户和同意条款，IT部私自注册云账户跟私签合同的区别大吗？

 

前文是说注册阶段的法务承诺，到使用过程中云平台又会有各种奇怪的“资格认证”“功能审核”等问题。云平台要规避自注册客户的政策法规问题和恶意欠费问题，但这和大客户有什么关系？供应商用“认证”“审核”这类词跟甲方说话就是态度不端正，这又是一句“客户你好，你要服从管理，爱审不审，不审就滚”。这类甲方的身份资料是公开的，也不会恶意赖账，这时应该由乙方主动记录合规信息，后台透明完成功能开通，设置消费和透支上限。

 

假设客户是成长型公司，以前CEO创建的账户让员工继续使用。某天CEO被老婆打了一顿，因为他的网购记录有给“丽丽”订花和开房；或者网警约谈该倒霉蛋，警告他不要用网盘传播非法视频；也可能CEO打开聊天工具，发现自己很多幼稚鸡汤文给投资商。不要误会是有人要整这个CEO，SSO单点登录多项服务，同事用混了账户也正常。

 

如果客户放弃使用某云之后，原账户不注销滚动欠费几千万怎么办？云巨头们都是横向一体化经营，搞不好会和客户有竞争，霸王注册条款下的法务风险确实存在。

 

一个企业服务的账户不应该由客户注册，而是供应商主动提供，像IDC和CDN就会主动给客户提供查带宽的账户。这个账户只是为了让客户低成本的获取服务，不包含客户给供应商的任何承诺，双方的权利义务要看商务合同。

 

第二.账户内资源隔离

 

企业客户尽量会将资源集中采购，在采购IDC/CDN这类简单服务时不用担心资源混淆。但套用过去管理虚拟机的经验，管理IaaS和PaaS服务时要有资源池隔离，不同部门和项目的主机资源要分别计费和管理。

 

一个很常见的场景是，人事部的OA系统申请了15万云主机费用，生产车间的ERP和销售部的CRM系统不设上限，外部客户A项目预算是50万，B项目是200万，等等等等。

 

如果没有资源池的概念，就是一个账户管所有资源的“大通铺”模式，客户要把脚趾头都掰完了才能算清各项目的消费金额；万一云平台调整了资源价格，较真的客户又要从头重算一次。

 

这个“大通铺”最尴尬的不是计费繁琐，而是一个账户下所有资源毫无权限隔离，客户或者只有一个人去登录云平台，或者将不同业务注册完全孤立的账户。互联网公司无法理解传统企业和自然人有关的流程是多沉重，客户选一个云平台管理员完成所有操作，客户的项目越多管理员员就越晕越累。将不同业务区分为不同账户也解决不了问题，因为客户和云平台都要将这批账户统一管理，但实际扣费进度总会超出意外，项目欠费停机或者追加预算，挨骂受累的都是平台管理员。

 

现在越来越多的云平台会让客户账户下创建多个权限和访问隔离的资源组，不同的资源组会各自做用量统计和配额上限，逐步解决了管理员侧的资源隔离和计费问题。

 

##有的平台会把这些资源组叫做“资源子账户”，但这和下文的权限子账户会有名称混淆，本文是将其称为资源池或者资源组。

 

第三.多账户权限隔离

 

相关用户在云平台要有自己的子账户，这样才好记录操作日志和做权限控制。

 

首先要保证这些子账户不能用于登陆到公司的其他业务线，特别是个人业务线，这也是子账户研发一直滞后的重要原因。

 

最简单的子账户是管理员手动创建账户密码，但这有弱密码和员工离职问题；简洁方案就是管理员手工创建子账户，但密码验证由客户的企业AD做Keberos认证来完成；最复杂对接即将AD的账户体系（含用户注释和分组信息）完整引入云平台，但云平台管理是小众需求，AD管理员一般不是合适的云平台管理员，这个功能要斟酌。

 

创建和打通子账户以后就可以给客户设置各个资源组的权限，很多客户不需要高权限，低权限也是对操作者的保护。每个资源组大约有如下权限分组：

 

a.管理角色，即可以对该资源组不受限的执行全部动作，还可以做二级授权，减少云平台管理员的工作压力。但很多客户怕自己配置错误不想要这个权限，比如怕自己手滑删了CDN域名设置导致业务中断，所以干脆就有什么操作都让供应商和管理员帮配，这就引出了其他低阶权限。

 

b.操作角色，操作类角色只能完成各类可逆性云资源变更，比如说不可以释放RDS但可以备份RDS，不可以释放“核心必要”云主机但可以创建和删除“临时扩展”云主机。只有云平台精通产品的真实使用场景，才可能定义好各类资源的管理和操作的权限；开放给DevOPS的“低风险日常操作API权限”也集中在这个角色上。

 

c.查看角色，对不想或不能承担操作责任的客户可以给与查看权限；有些大公司有线上变更流程，事件发起方、业主审核方、业务执行方是分离的，事件发起和审核方都只要查看资源权限就可以了。

 

d.财务角色，有些财务人员要上云平台做截图和导出账单，这就需要财务角色。

 

e.平台代操作授权角色，这不是一个恒定的角色，而是前文查看型客户没有操作能力，那就需要进行临时操作授权。

 

以上各个角色的登陆和操作过程都要有详细的步骤日志记录。

 

第四.平台通知和管理机制

 

前文将各种资源和权限进行了区分，那接下来要区分的就是平台通知机制。

 

单账户大通铺模式下，所有的平台短信和邮件都往一个账户发就行了，但现在要重新设计。我的一线技术工作经历并不依赖第三方（如云平台）通知机制，对通知功能的研究较少，所以我只能提出通用性设计建议：

 

a.别把平台维护通知当做甩锅通知，大客户会因此忙到鸡飞狗跳。

 

b.员工正常操作不要通知到管理员，自然人收到的信息太多会麻木。

 

c.员工执行摧毁核心资源等高危的操作要及时通知管理员。

 

d.这些操作日志可以通过API等方式对接到企业自身的平台。

 

e.合规和安全风险发送平台管理员和资源池管理员。

 

云平台有通知机制就要有管理权限，比如说某IP存在合规隐患，管理员要能查看和操作该IP；否则平台管理员只能组织各部门领导开会，平台的管理员一般不是公司高管，其处理速度和处理效果就很慢也很扰民了。

 

第五.其他随笔说明

 

a.过去云管平台做计费和权限开发很繁琐，云平台支持精细控制后云管平台的对接成本会瞬间降低，那些功能缺失又不是行业标杆的云平台会云管平台被逐渐放弃接入。

 

b.有客户想给不同资源组做不同资源单价，这是个弱需求，该需求技术实现繁琐且有客户可接受的变通方法，比如子账户登陆只计量不计价，价格在心中。

 

c.这套账户体系从对接AD改为手动生成，同时调整其扣费账户设置，即可以将其改造成一个代理商用的操控界面。