2022年，站酷建立基础架构部门，将 站酷云 作为公司统一的工程系统、业务系统的权限管理和运维中心；

以下是对站酷云的思考

在登录、资源申请、扩缩容等基础技术能力问题上，站酷云 应该屏蔽阿里云的技术细节；如：

扩缩容应该可以在 站酷云 上完成，起码也需要给出扩缩容功能的链接，而不需要用户去阿里云上自己寻找扩缩容的方案；

但不应该粒度过细，一些业务系统的流程变更等，和 站酷云 解耦开。

一、账号管理

入职即创建 LDAP 账号。

站酷云 应该与 LDAP 打通。  

o   LDAP 账号的用户名和密码可以用来登录各种内部系统；LDAP 应当提供 SSO（单点登录） 功能。

• 各种内部系统包括：
• 企业后台：如站酷后台，海洛后台等；
• Git 仓库/Artifact 管理系统/CI/CD 等工程资源库；
• OA 系统；

o   LDAP 账号与阿里云 RAM 账号打通。意味着一个 LDAP 账号对应一个 RAM 账号；

• 初始的阿里云 RAM 账号拥有最小权限（某些资源如 QuickBI 的只读权限）； 如果需要其他的权限，用户可以在 站酷云 上申请开通。
• 可以针对不同角色（管理人员/工程师/产品经理/数据分析师/运营等），在阿里云上创建不同的用户组，定义不同组的最小权限单元；
• 定义和实现阿里云工单审批流程；
• 申请理由，审批节点，申请通过后自动开通；

o   LDAP 账号拥有哪些权限可以被方便地查到。权限申请和赋权功能应该在系统中实现，并且有日志记录；

• 对企业内部系统的赋权，仅区分用户是否有该平台权限即可。没有平台权限的，内部系统 Owner 可以通过 SSO 查询并拒绝访问（不是踢出登录）；拥有平台权限的，内部系统可以定义自己内部的赋权粒度和赋权流程，在平台内部自己实现。但内部系统账号应该和 LDAP 打通。
• 对阿里云的授权，通过阿里云 openAPI 进行。站酷云 及时通过阿里云 openAPI 拉取用户权限配置并展示即可。考虑到阿里云的权限非常多且不可控地增加，阿里云部分权限可保存一个非结构化的数据。

Public Key 管理功能  

o   用户申请堡垒机及资源

工单通过后，自动添加用户及用户组

o   工程师可以在 站酷云 上实现 Public Key 的上传，管理和更新，Key （通过工单手动）同步到堡垒机；

o   用户组可以通过工单增删改申请的服务器

 

o   工程师申请对应的资源权限并成功后，public Key 应该能够进行及时的同步到对应的系统中，自动获得对应的资源；对应地，被取消相关权限后，public key 也无需要从对应系统上清除；

二、工程资源及应用管理

工程资源管理

工程资源标准化

被管理、可使用、可申请的工程资源，应该仅包含云厂商采购名录（以框架协议为准）和公司级的内部系统中的标准资源；    

o   公司级的内部系统指基础研发部发布的、云厂商不提供的服务；例如 gitlab，LDAP，基于成本/技术选型等考量，自己构建的内部云服务；  

o   基础架构与业务研发分离：基础架构只保证基础资源的 SLA 不低于云厂商标定 SLA；搭建在基础资源上的 application，其 SLA 由 application 的 owner 负责；

• 如：A 申请了两台 ECS 机器，搭建了 redis 集群；则该 redis 集群在基础研发只保证该 ECS 可用，redis 属于搭建在 ECS 上的 application。出现集群增加/减少机器时或者 redis 自身出现问题时，A 需要自己负责处理；
• 如果 A 申请了「云上 redis 集群」，则该 redis 集群出现延迟增加等问题时，基础架构组应响应对 redis 的运维需求。
• 如果业务需要采购其他类型的资源，需要经过流程审批，由基础研发部门统一采购；

计费

• 对于服务使用的资源，计费以 APP 为单位，APP 费用汇总到业务部分；
• 对于平台型/SaaS 能力型的资源，如 MaxCompute/AI 能力接口调用，如果暂时不能按照部门拆分，则计费到数据智能中心、基础架构部等中台部门；
• 开发机/测试机，以部门为单位进行申请，计费到对应的部门；

新增工程资源类型

不要求过度配置化，但要求能够迅速响应变更需求。除了在阿里云上接入新的资源类型、内部接入新的系统外，要保持兼容性，能够迅速切换云厂商，直至管理多云上的资源；

应用管理

所有前/后端服务均被抽象为应用（APP）；一个应用为一组遵循单一原则的服务，面向用户提供一个独立、完整的功能，并持有一组独立的资源；注意，此处「用户」可以为外部用户也可以为内部用户；

APP 之间存在相互调用关系，即调用链；

层次关系：

·      

APP：

• 一组前/后端服务为一个 APP；它提供了一组可被调用的接口；
• 一个 APP 从属于一条业务线；
• 一个 APP 持有一组 IaaS 工程资源，如计算资源 ECI/ECS，存储资源云盘，数据库资源 RDS/redis/...，中间件资源 Kafka 等；
• 对 PaaS 和 SaaS 资源（如接口调用，短信下发等），原则上可以通过 APP 进行划分，如果不能划分，应该统一归口；
• APP 的切分遵从高内聚、低耦合原则：for a single purpose；
• APP 下包含多个 unit，每个 unit 对应一个前/后端服务；每个 unit 为一个通过 CI/CD 部署的单元；
• APP 下可以包含除在线服务外，一些定时/离线的调度任务（Task）；
• APP 下角色划分为：
• Owner：APP 的最终责任人；项目 Owner；
• Maintainer：APP 的维护者；该 APP 下的核心开发人员；
• Developer：参与开发，提供部分贡献物；或者是其他团队的协作开发；

 

 

Unit：

• 每个 unit 对应一个前/后端服务；每个 unit 为一个通过 CI/CD 部署的单元；
• 每个 unit 包含一组容器单元，每个 unit 的容器单元具有一样的运行环境和一样的代码及配置；
• 最佳实践为：一个 APP 对应 git 上的一个代码仓库；通过 docker 打包为 POD（但 git 上的一个代码仓库不一定有对应的 APP，例如，base library 对应的是 nexus 上的 artifact，而不是一个 APP），每个 POD 对应一个 unit；
• 以上两点不做强制要求，「按照业务目标划分代码仓」和「按照技术栈划分代码仓」可以考虑在不同的场景使用。
• Unit 不需要特定的权限结构；
• 每个 Unit 对应一种编程语言。我们支持的编程语言包括：Java/Scala，PHP，Python（需要在 Unit 上标定编程语言）；

Task：

• 一个 Task 为一个离线任务，承担数据处理、自动运维相关的工作；
• Task 消耗的 IaaS 和 PaaS 资源按照 APP 进行 billing；如 A 服务的定时任务，则由 A 服务承担费用；
• 任务 1：每天 10 点将数据库中数据同步到离线环境；
• 任务 2：当出现某个事件时触发数据库重建任务；

APP SHELL：

• 按照统一规范，自动部署的基础组件。包括基础安全组件（例如，每个具有外网访问接口的 APP 都需要部署 WAF 和网络加速、需要进行漏洞扫描），基础架构组件（例如，自动扩缩容、熔断能力、监控与告警等）；

监控与告警：

• 提供面向 APP 和 Unit 的双重资源监控；
• 支持报警功能：
• 支持基础报警：资源水位线（cores，memories，存储，数据库等）；

三、日志与审计功能

所有用户可以被审计：

o   用户可以在权限中心看到自己所拥有的所有权限；

o   汇报上级可以看到下级所拥有的所有权限；

所有的变更可以被审计：

o   权限变更，记录谁，在什么时间对谁赋予/撤销了权限，并有上下文信息如对应的工单和理由；

o   发布变更：以 APP/Unit 为单位组织，支持汇总统计，如统计一个业务线下当月发布了多少变更；