运维管控&DevOps
1、自动扩容/缩容
前面提到在车联网行业中有个比较明显的行业特性就是早晚高峰是平时流量的3倍甚至更高，但是平常要应付这么高并发的流量意味着资源投入也要3倍以上。在传统IDC架构中，我们通常是按照平常最高峰流量的1.2倍（1.2倍是为应对特殊情况预留的buffer）来准备相应的服务器资源，在平时资源闲置比较明显，资源利用率不到30%，意味着平常可能120台应用服务器就足够了，但是为了应对高峰流量不出问题我们需要准备360台服务器应对6个小时的高峰流量，其余18小时可能只需要120台服务器。为了确保系统稳定，提升用户体验，当时我们只能投入比平时多几倍的服务器资源。
为了解决这一痛点，我们改用云上的弹性伸缩ESS服务，利用弹性伸缩ESS服务构建我们的自动扩容/缩容系统，在高峰流量来临前自动创建ECS服务器，自动部署应用，然后将启动好的应用自动接入负载均衡节点下。在高峰期结束后，自动释放这部分新增的ECS服务器资源。这期间的操作全程自动化，无需人工干预，而且这部分新增的资源按量付费，极大节约了成本。下面简单介绍下云上弹性伸缩服务以及我们是怎么实现系统自动扩容和缩容。
阿里云提供了弹性伸缩服务可以自动调整弹性计算资源大小，以满足业务需求的变化。它可以根据设置的伸缩策略，在业务需求增长时自动增加ECS实例以保证计算能力，在业务需求下降时自动减少ECS实例以节约成本。
弹性伸缩功能概述：
根据客户业务需求自动调整ECS实例数量。
自动向负载均衡的后端服务器组中添加或移除相应的ECS实例。
自动向RDS访问白名单中添加或移除ECS实例的IP。
弹性伸缩特点：
随需应变：
根据需求“恰到好处”地分配资源，无需提前预测需求变化，实时应对需求突增。
自动化：
无需人工干预，自动创建和释放ECS实例，自动配置负载均衡和RDS访问白名单。
伸缩模式丰富：
多模式兼容，可同时配置定时、动态、自定义、固定、健康模式，可通过API对接外在监控系统。
智能：智能调度云计算资源，应对各种复杂场景。
我们的应用场景：
应对固定早晚出行高峰：
每天早上7-9点和晚上的18点-20点间属于上下班高峰期，这种高峰流量比较固定，利用弹性伸缩服务进行定时在早上7点和下午18点进行自动扩容；
应对不固定的节假日出行高峰：
节假日出行高峰的特点是高峰流量变化难以预测，针对这部分不确定的高峰流量，利用弹性伸缩服务根据CPU利用率、应用负载、带宽利用率作为衡量指标进行弹性伸缩。我们在节假日来临的前一天和结束的前一天的下午16点进行定时自动扩容，应对出城和返城高峰。在节假日期间则根据CPU利用率和带宽利用率指标进行弹性扩容。
下面以登录应用为例，介绍配置弹性扩容的操作步骤：1） 开通服务：
- 登录 弹性伸缩控制台；
- 确认 开通服务；
- 前往 访问控制台RAM 授权使用弹性伸缩 API；
2） 创建伸缩组： - 登录 弹性伸缩控制台；
- 选择 地域，如华北2;
- 单击 创建伸缩组;
- 在创建伸缩组页面：
填入 伸缩组名称，如Applogin；
设置 伸缩最大实例数（台），如20；
设置 伸缩最小实例数（台），如20；
设置 默认冷却时间（秒），如600；
设置 移出策略，如先筛选最早创建的实例，在结果中再筛选 最早伸缩配置对应的实例；
设置 网络类型，如 专有网络；
配置负载均衡实例。指定的负载均衡实例所有的监听端口必须开启健康检查，否则无法加入伸缩组；
配置云数据库RDS实例。指将扩容的ECS IP 加入到对应数据库的白名单里；
单击 提交 完成创建；
伸缩组创建成功后，可以直接 创建伸缩配置 或者单击 稍后创建;
填入 伸缩配置名称，如Applogin-prod；
选择 计费方式，如 按量付费。更多详情，请参阅 ECS 按量付费 和 竞价实例；
选择 实例，如ecs.xn4.small。
选择 镜像，如CentOS 7.4 64位。如果需要实现自动启动Web服务器、自动下载代码和脚本等功能，请选择 自定义镜像；
选择 存储，如40GB高效云盘；
选择 公网带宽，如按使用流量1Mbit/s；
选择安全组；
单击 下一步；
3） 启用伸缩组：
- 进入弹性伸缩控制台；
- 选择对应的伸缩组，点击启用；
- 点击确定；
4） 创建定时任务：
- 进入弹性伸缩控制台；
- 点击自动触发任务管理，点击定时任务；
- 点击创建定时任务；
- 配置任务名称及执行时间等；
- 点击提交；
5） 检查
进入弹性伸缩控制台；
进入伸缩管理，选择对应的伸缩名称，点击管理；
点击基本信息，可查看弹性伸缩任务基本信息；
点击ECS实例列表，可以查看弹性伸缩任务是否创建成功；
这样自动弹性扩容接配置好了，搭配使用定制镜像可以实现服务器启动即可以提供应用服务。应用启动之后自动挂载到对应的负载均衡组下。全程无需人工介入即可实现高峰期自动扩容业务，然后高峰过后实现自动缩容，非常方便。即为公司节约了成本，又满足了业务的弹性高峰业务需求，关键还不用增加运维的工作量，全程自动化。云上弹性伸缩服务解决了我们一直以来的痛点。
2、自动发布
在传统IDC架构中我们大部分时间都是出于应用升级发布工作和解决故障中，每天发布次数50次左右，重大版本升级，可以高达100余次，我们当时大部分都是脚本运维，和人肉运维，能做这么高的发布频率已经很不错了，但是公司还是希望可以更快点。有人会问为什么这么多？公司处于高速发展期，为了适应市场变化，以最快速度满足市场的需求，所以需要研发团队以最快速度完成需求设计，产品研发，产品测试，产品上线工作。第一时间抢占市场，这也是一个互联网企业的核心竞争力体现。当时我们也慢慢接触Jenkins持续集成，并且在公司慢慢推广。此次搬到云上我们希望可以继续利用Jenkins做持续集成，阿里云专家给我们推荐了codepipeline 它完全兼容Jenkins的能力，是SAAS化产品，无需运维，集成多个代码管理平台。简单介绍下codepipeline：
CodePipeline：
阿里云CodePipeline是一款提供持续集成/持续交付能力，并完全兼容Jenkins的能力和使用习惯的SAAS化产品。通过使用阿里云CodePipeline，可以方便的在云端实现从代码到应用的持续集成和交付，方便快速的对产品进行功能迭代和演进。
产品功能
提供了多套源代码管理平台的集成，可以与GitHub、Bitbucket、阿里云Code等平台无缝集成获取源码。
提供了多种开发语言的编译及单元测试能力，目前包含Java，Node.js，Python2，Python3和PHP五种语言，以及通用文件打包模式，未来将集成更多的开发语言种类。
提供了容器化集成解决方案，可以独立支持Docker镜像编译，同时支持通过阿里云容器镜像服务 进行编译和安全检查，并与阿里云容器服务打通，目前支持蓝绿/灰度发布等多种发布方式。
提供了应用部署到ECS的能力，同时完全兼容开源自动化运维软件Salt，透明整个应用发布和部署能力。
前面有介绍利用codepipeline构建Java应用并发布到Kubuernetes，下面再介绍下如果发布到ECS，操作步骤如下：
1) 登录CodePipeline控制台
如果还未开通 CodePipeline 产品的需要先开通。
2) 同意RAM的CodePipeline的角色的授权
3) 新建项目
单击 新建，输入项目名称，选择 构建一个Java的软件项目, 并单击 下一步。
4) 配置 Repositories
添加 Git 的验证方式，比如用户名/密码。
5) 配置代码分支
6) 配置构建命令
7) 配置测试命令
如果我们不需要做单元测试，可以不填写测试命令。
8) 选择部署到ECS
-
上传构建物到 OSS
 - 部署构建物到 ECS
在要部署到的 ECS 机器上执行下面的命令
单击下图中的 刷新 按钮，选择目标 ECS，移动到已选部署目标中，并单击 下一步。
- 确认配置项并单击提交
如果需要修改某些配置，可以在这个页面进行修改。
9) 执行构建
完成项目的任务配置后，可以单击左侧导航栏中的 立即构建，开始执行配置中的构建及部署命令。
我们可以在构建队列及构建历史中查看构建状态。
进入构建，单击 控制台输出，可以查看日志。
构建完成后，可以通过访问 ECS 的 IP 查看部署的服务。
当然除了可以代码部署到ECS上，CodePipeline还可以支持将代码部署到Kubernetes以及Swarm等阿里云容器服务之中。详细操作方式请查看阿里云官方文档。
3、监控报警
传统IDC架构中我们的监控系统是自建的zabbix监控系统，随着公司业务快速发展，监控项也急剧增加，由最初的1000个监控项增加到3w个监控项，监控系统数据库性能跟不上，查询很慢，告警延迟和误报的现象逐渐增多，监控需求越来越多样化，定制化。传统监控系统已经不能满足未来业务高速发展。监控报警系统就是运维同学的眼睛监控是否全面，报警是否灵活，处理是否及时直接关系到系统的稳定性。所以我们改用阿里云的云监控是一项针对阿里云资源和互联网应用进行监控的服务。云监控服务可用于收集获取阿里云资源的监控指标，探测互联网服务的可用性以及针对指标设置灵活的报警。以下是云监控特点：
1）天然集成
云监控服务无需特意购买和开通，注册好阿里云账号后，便自动为开通了云监控服务，方便在购买和使用阿里云产品后直接到云监控查看产品运行状态并设置报警规则。
2）数据可视化
云监控通过Dashboard为用户提供丰富的图表展现形式，并支持全屏展示和数据自动刷新。满足各种场景下的监控数据可视化需求。
3）监控数据处理
云监控支持用户通过Dashboard对监控数据进行时间维度和空间维度的聚合处理。
4）灵活报警
云监控还为提供了监控项的报警服务。在为监控项设置好合理的报警规则和通知方式后，一旦发生异常便会立刻为发出报警通知，让及时知晓服务异常并处理异常，从而提高用户产品的可用性。
分享一个报警模板配置技巧：
当账号下服务器和其他云产品实例非常多时，首先建议按照业务视角为资源创建不同的应用分组，然后通过应用分组来批量管理资源。
报警模板是如何提升配置报警规则的效率的？
1) 先解释一下报警规则配置在应用分组和配置在单实例上有什么不同。
创建报警规则时资源范围可以选择“实例”或者“应用分组”，如果选择“应用分组”，那么报警规则的作用范围就是整个应用分组内的所有资源。业务需要扩容或者缩容时，只需要将相应资源移入或移出应用分组，而不需要增加或删除报警规则。如果需要修改报警规则，也只需要修改这一条报警规则，就生效在组内所有实例上。
如果选择将报警规则创建在实例上，那么该规则只对单一实例有效。修改报警规则时也只对单一实例生效。当实例增多时报警规则会变得难以管理。
2) 报警模板如何提升配置规则的效率？
ECS、RDS、SLB等基础服务在配置报警时，监控项和报警阈值相对固定，为这些需要报警的指标建立模板后，新增业务时，创建好应用分组后直接将模板应用在分组上，即可一键创建报警规则。
当需要批量新增、修改、删除报警规则时，也可以修改模板后，将模板统一应用在分组上，极大的节省操作时间。
操作步骤
下面我们以车联网平台车队管理为例讲解如何创建应用分组和使用报警模板，快速将业务的云上监控报警体系搭建起来。
1) 车联网平台的后台通常包含车队管理、sms卡管理，车机管理等模块。首选我们创建一个名为“车队管理线上环境”的应用分组。
进入应用分组页面，单击页面右上角的“创建组”按钮，进入创建应用分组页面。
为分组填写名称，并且选择车队管理这块业务使用的云资源，我们以最常见的服务器+数据库+负载均衡资源组合为例。
选择通知对象，当应用分组内的报警规则发生报警时，会发送给这里的通知对象。
点击确认后完成分组的创建。
2) 创建报警模板
进入报警服务的报警模板页面，点击页面右上角的“创建报警模板”按钮，进入创建模板页面。
填写模板基本信息。
添加报警策略，将业务模块需要的报警策略添加到报警模板中。
点击确认保存模板配置。
3) 将模板应用在分组上
在模板列表中选择上一步创建好的模板，应用在“车队管理线上环境”这个应用分组上。并且选择通知策略。
下面是通过阿里云的云监控一键生成的监控大盘。云监控Dashboard 支持全屏展示和自动刷新，可以将各类产品指标添加到监控大盘后在运维大屏上全屏展示。
4、日志服务
在我们车联网平台架构中，日志系统是一个非常重要的功能组成部分。它可以记录下应用或者系统所产生的的所有行为，并按照某种规范表达出来。这些日志数据也是非常宝贵的。为此我们需要将应用日志，系统日志，操作日志等所有日志收集起来，然后利用大数据分析技术对其进行安全审计，故障定位，数据分析等等。在传统的IDC架构中我们自建一套开源日志系统（简称ELK，是内比较流行的日志系统），我们的当的所有业务系统一天的日志量在500GB左右，当时我们自建的ELK系统用10台服务器，分别由1台Kibana服务器（做前端展示）+3台logstash服务器（做日志搬运和日志index）+3台kafka服务器（做日志队列）+6台Elasticsearch服务器做日志存储和搜索。其中6台Elasticsearch服务器为物理机，ES配置低了会影响日志写入性能和搜索性能。所以这样一套ELK成本不低，而且仅能满足1个月日志存储。并且ES的优化和维护难度还是挺高的，需要专业的运维人员维护。基于这些因素，我们改用云上日志服务。阿里云的日志服务费用很低，远远低于自己的ELK系统。不仅成本低，还无需运维，功能也很丰富，支持的开源组件非常多。是一款非常简单易用，功能丰富，价格低廉的日志系统。下面简单介绍下云上日志服务特点以及我们是怎么使用的。
阿里云日志服务产品特点：
1）全托管服务
易用性强，5分钟即可接入服务进行使用，Agent支持任意网络下数据采集。
LogHub覆盖Kafka 100%功能，并提供完整监控、报警等功能数据，弹性伸缩等（可支持PB/Day规模），使用成本为自建50%以下。
LogSearch/Analytics 提供保存查询、仪表盘和报警功能、使用成本为自建 20%以下。
30+ 接入方式，与云产品 （OSS/E-MapReduce/MaxCompute/Table Store/MNS/CDN/ARMS等）、开源软件（Storm、Spark）无缝对接。
2）生态丰富
LogHub 支持30+采集端，包括Logstash、Fluent等，无论是从嵌入式设备，网页，服务器，程序等都能轻松接入。在消费端，支持与Spark Streaming、Storm、云监控、ARMS等对接。
LogShipper 支持丰富数据格式（TextFile、SequenceFile、Parquet等），支持自定义Partition，数据可以直接对接Presto、Hive、Spark、Hadoop、E-MapReduce、MaxCompute、HybridDB等存储引擎。
LogSearch/Analytics 查询分析语法完整，兼容SQL92，支持通过JDBC协议与Grafana对接。
3）实时性强
LogHub：写入即可消费；Logtail（采集Agent）实时采集传输，1秒内到服务端（99.9%情况）。
LogSearch/Analytics：写入即可查询分析，在多个查询条件下1秒可查询10亿级数据，多个聚合条件下1秒可分析1亿级数据。
4）完整API/SDK
轻松支持自定义管理及二次开发。
所有功能均可通过API/SDK实现，提供多种语言SDK，可轻松管理服务和百万级设备。
查询分析语法简单便捷（兼容SQL92），接口友好适合与生态软件对接（支持Grafana对接方案）。
Nginx日志分析案例：
我们公司有许多自建Nginx反向代理服务器，主要用于车联网App用户以及车队web用户的web请求转发，做为HTTP流量的统一入口，因为Nginx在处理web请求上拥有强大模块和正则表达式支持，可以帮助我们实行丰富的功能，同时在对网站，APP应用访问情况进行分析时，需要对Nginx访问日志统计分析，从中获取App、网站的访问量、访问时段等访问情况。下面介绍下我们是如何利用日志服务做的Nginx日志分析。
操作步骤如下：
定义nginx日志格式
首先配置下nginx的日志格式，编辑nginx.conf配置文件，修改如下log_format配置。
log_format main '$remote_addr - $remote_user [$time_local] "$request" $http_host '
'$status $request_length $body_bytes_sent "$http_referer" '
'"$http_user_agent" $request_time $upstream_response_time'; 配置日志服务
1) 数据接入向导
日志服务提供数据接入向导快速接入各类数据源，将Nginx访问日志采集到日志服务可以采用如下两种方式进入数据接入向导。
新建项目在创建项目和创建日志库后，根据页面提示点击数据接入向导。
对于已存在的Logstore，点击列表中数据接入向导图标进入。
2) 选择数据类型
日志服务提供多种数据类型接入（云产品、自建软件、API、SDK等），分析NGINX访问日志请选择 自建软件 > NGINX访问日志。
3) 数据源设置
按照实际情况填写配置名称和日志路径，并将推荐的log_format信息填写到NGINX日志格式中。
日志服务会自动提取出相应的键名称。
注意：其中$request会被提取为request_method和request_uri两个键。
应用到机器组
如果之前没有创建过机器组，请先根据页面提示创建机器组。注意：Logtail配置推送生效时间最长需要3分钟，请耐心等待。
4) 查询分析和可视化
确保日志机器组心跳正常的情况下，可以通过点击右侧预览按钮获取到采集上来的数据。
日志服务提供预设的数据键名称以便分析使用，可以选择实际数据键名称（根据预览数据生成）和默认数据键名称形成映射关系。
点击下一步，日志服务会为设置好索引属性并创建nginx-dashboard仪表盘以供分析使用。
5) 分析访问日志
如下图所示，开启索引后，默认生成仪表盘页面可以快速看到各个指标的分析情况。关于如何使用仪表盘。
PV/UV统计(pv_uv)
统计最近一天的PV数和UV数。
统计语句：
访问地域分析(ip_distribution)
统计访问ip来源情况。
统计语句：
访问前十地址(top_page)
统计最近一天访问PV前十的地址。
统计语句：
请求方法占比(http_method_percentage)
统计最近一天各种请求方法的占比。
统计语句：
请求状态占比(http_status_percentage)
统计最近一天各种http状态码的占比。
统计语句：
请求UA占比(user_agent)
统计最近一天各种浏览器的占比。
统计语句：
前十访问来源(top_10_referer)
统计最近一天访问前十的来源信息。
统计语句：
6) 访问诊断及优化
除了一些默认的访问指标外，站长常常还需要对一些访问请求进行诊断，查看一下处理请求的延时如何，有哪些比较大的延时，哪些页面的延时比较大。此时可以进入查询页面进行快速分析。
统计平均延时和最大延时
通过每5分钟的平均延时和最大延时，从整体上了解延时情况。
统计语句：
统计最大延时对应的请求页面
知道了最大延时之后，需要明确最大延时对应的请求页面是，以方便进一步优化页面响应。
统计语句：
统计请求延时的分布
统计网站的所有请求的延时的分布，把延时分布在十个桶里面，看每个延时区间的请求个数。
统计语句：
统计最大的十个延时
除最大的延时之外，还需要统计最大的十个延时及其对应值。
统计语句：
对延时最大的页面调优
假如/url2这个页面的访问延时最大，为了对/url2页面进行调优，接下来需要统计/url2这个页面的访问PV、UV、各种method次数、各种status次数、各种浏览器次数、平均延时和最大延时。
统计语句：
成本优势
最后分析一下阿里云日志服务日产品在日志处理的三种场景下具有哪些成本优势： LogHub：
- 以购买云主机 + 云磁盘搭建 Kafka 相比，对于 98% 场景下用户价格有优势。对小型网站而言，成本为 kafka 的30% 以下。
- 提供 RESTful API，可以直接针对移动设备提供数据收集功能，节省了日志收集网关服务器的费用。
- 免运维，随时随地弹性扩容使用。
LogShipper： - 无需任何代码/机器资源，灵活配置与丰富监控数据。
- 规模线性扩展 （PB级/Day），功能当前免费。
LogSearch/Analytics：
- 以购买云主机 + 自建 ELK 相比，成本为自建的 15% 以下，并且查询能力与数据规模有极大提升。
- 与以上日志管理软件相比，能无缝各种流行支持流计算 + 离线计算框架，日志流动畅通无阻。
5、数据大屏
公司经常会有交通部有关领导来我司视察工作，为了配合视察工作我们需要将车辆网平台各个业务系统的运行状态，业务指标等通出大屏展示出来，例如在线车辆统计，在线App用户统计，车辆告警统计，当日新增用户统计，各城市车辆统计，交通拥堵状况等等。通常将这一过程称之为数据可视化，数据可视化致力于用更生动、友好的形式，即时呈现隐藏在瞬息万变且庞杂数据背后的业务洞察。当时我们公司的设计师对于复杂数据的展现经验不足，设计出来的很多图表与特效比较简单，导致最终效果不是很好，间接影响了视察工作的整体效果。在云上我们改用了阿里云DataV数据可视化产品，它提供了各项数据图表展示组件，通过阿里云DataV数据可视化产品可以让运维人员也可以设计出各种高大上的炫酷大屏，而且简单易上手。借助于DataV数据可视化我们完美生动的展示出智能车联网平台各项实时业务指标以及车联网在交通领域的应用。下面简单介绍下DataV数据可视化介绍：
DataV功能特性有哪些呢？
1) 多种场景模板，解决设计难题
数据可视化的设计难点不在于图表类型的多，而在于如何能在简单的一页之内让人读懂数据之间的层次与关联，这就关系到色彩、布局、图表的综合运用。DataV 提供指挥中心、地理分析、实时监控、汇报展示等多种场景模版，即便没有设计师，可视化作品也有显现出高设计水准。
2) 多种图表组件，支撑多种数据类型的分析展示
除针对业务展示优化过的常规图表外，还能够绘制包括海量数据的地理轨迹、地理飞线、热力分布、地域区块、3D 地图、3D 地球，地理数据的多层叠加。此外还有拓扑关系、树图等异形图表供自由搭配。
3) 多种数据源接入，充分发挥阿里云大数据计算的能力
能够接入包括阿里云分析型数据库，关系型数据库，本地 CSV 上传和在线 API 的接入，且支持动态请求。满足各类大数据实时计算、监控的需求，充分发挥大数据计算的能力。
4) 图形化的搭建工具，无需专业编程人员也可快速实现
提供多种的业务模块级而非图表组件的 Widget，所见即所得式的配置方式，无需编程能力，只需要通过拖曳，即可创造出专业的可视化应用。
5) 多分辨率适配与发布方式，满足不同场合下的使用
特别针对拼接大屏端的展示做了分辨率优化，能够适配非常规拼接分辨率做适配优化。创建的可视化应用能够发布分享，没有购买 DataV 产品的用户也可以访问到应用，作为对外数据业务展示的窗口。
6、企业运维管理
我们公司运维团队规模26人，其中应用运维10人，数据库运维3人，系统运维2人，网络运维2人，运维开发3人，运维监控人员6人。做好企业运维管理的第一件事就是做好权限管理，其次是安全审计。例如DBA的权限和应用运维的权限应该怎么区别?怎样审查运维人员的操作是否合规？等等。在这些情况下企业如何应对账号管理风险，权限管理风险，安全管理风险以及效率提升都是挑战。在传统IDC架构中我们也只是通过简单的sudo授权体系去做权限控制，但是配置相当复杂，权限更新不及时，管理颗粒的比较粗，在实践中发现综合效果不是很好。在云上我们改用阿里云访问控制RAM、操作审计等产品，下面简单介绍下RAM和操作审计：
1) 访问控制RAM
RAM (Resource Access Management) 是阿里云提供的资源访问控制服务。通过RAM，可以集中管理用户（比如员工、系统或应用程序），以及控制用户可以访问名下哪些资源的权限。
RAM包括下列功能：
集中控制RAM用户及其密钥 —— 可以管理每个用户及其访问密钥，为用户绑定/解绑多因素认证设备
集中控制RAM用户的访问权限 —— 可以控制每个用户可以访问名下哪些资源的操作权限
集中控制RAM用户的资源访问方式 ——可以确保用户必须使用安全信道（如SSL）、在指定时间、以及在指定的网络环境下请求访问特定的云服务
集中控制云资源 —— 可以对用户创建的实例或数据进行集中控制。当用户离开组织时，这些实例或数据不会丢失
统一账单 ——账户将收到包括所有用户的资源操作所发生的费用的单一账单
下面从登录验证、账号授权、权限分配 三方面介绍我们在 RAM 的操作：
a) 登录验证
为根账户和 RAM 用户启用 MFA
为根账户绑定 MFA（Multi-factor authentication，多因素认证），每次使用根账户时都强制使用多因素认证。
创建 RAM 用户，并且给高级工程师用户授予高风险操作权限（比如，停止虚拟机，删除存储桶），并且给 RAM 用户绑定 MFA。
为用户登录配置强密码策略
允许子用户更改登录密码，要求他们创建强密码并且定期轮换。
通过 RAM 控制台设置密码策略，最短长度最少8个字符、密码复杂性必须较高。
定期轮转用户登录密码和访问密钥
通过RAM控制台为RAM 用户设置3个月轮换登录密码或访问密钥。 这样在不知情的时候，如果出现凭证泄露，那么凭证的使用期限也是受限制的。
可以通过设置密码策略来强制RAM用户轮换登录密码或访问密钥的周期。
b) 账号授权
遵循最小授权原则
最小授权原则是安全设计的基本原则。我们给 RAM 用户授权 时，会授予刚好满足他工作所需的权限，而不要过度授权。
比如，在组织中，如果 Developers 组员（或者一个应用系统）的工作职责只需要读取 OSS 存储桶里的数据，那么就只给这个组（或应用系统）授予 OSS 资源的只读权限，而不要授权 OSS 资源的所有权限，更不要授予对所有产品资源的访问权限。
使用策略限制条件来增强安全性
给用户授权时设置策略限制条件，这样可以增强安全性。
比如授权用户Jason可以关停 ECS 实例，限制条件是Jason必须在9点-18点、并且公司网络中执行该操作。
及时撤销用户不再需要的权限
当用户由于工作职责变更而不再使用权限时，需要及时将用户的权限撤销。
c) 权限分配
不要为根账户创建访问密钥
不要创建根账号访问密钥并使用该密钥进行日常工作，由于根账户对名下资源有完全控制权限，所以为了避免因访问密钥泄露所带来的灾难性损失。
使用群组给 RAM 用户分配权限
创建与人员工作职责相关的 群组（如admins、developers、dba、accounting等），为每个群组绑定合适的授权策略，然后把用户加入这些群组。群组内的所有用户共享相同的权限。这样，如果需要修改群组内所有人的权限，只需在一处修改即可。当组织人员发生调动时，只需更改用户所属的群组即可。
将用户管理、权限管理与资源管理分离
创建不同的 RAM 用户，其职责分别是 RAM 用户管理、RAM 权限分配，以及各产品的资源操作管理。一个好的分权体系应该支持权力制衡，尽可能地降低安全风险。
将控制台用户与 API 用户分离
只给员工创建密码登录，给系统或应用程序只创建访问密钥。不给一个RAM 用户同时创建用于控制台操作的登录密码和用于 API 操作的访问密钥。
2) 操作审计
操作审计(ActionTrail)会记录云账户资源操作，提供操作记录查询，并可以将记录文件保存到指定的OSS存储空间。利用 ActionTrail保存的所有操作记录，可以实现安全分析、资源变更追踪以及合规性审计。
功能描述
记录操作事件
可以使用管理控制台或API为账户创建ActionTrail，给ActionTrail指定事件记录的OSS存储空间，然后通过ActionTrail控制台或者指定的存储空间中查看日志。
自主管理事件
ActionTrail 将事件记录保存在指定的OSS存储空间中，可以使用OSS数据加密以及权限管理功能来确保事件记录的数据安全。
多维查询事件
ActionTrail支持从操作时段、用户名、资源类型、资源名称、操作名称等维度来查询操作事件，可以帮助用户快速诊断问题或追踪安全事故。
3) 云盾堡垒机
在传统IDC架构中我们是利用开源Jumpserver系统自建的一套运维堡垒机。开源的堡垒机系统本来就比较少，更何况还是国产的，所以对之前用的那套过程堡垒机还是比较认可的。但就是功能还是不能完全满足我们的需求，是不是的暴露出一些产品bug，加上官网修复bug的速度太慢，可能是因为官方主要维护人员不多，忙不过来导致的。开源堡垒机在安全回归上也无法满足监管机构的要求。所以云上我们改用云盾堡垒机产品，它集中了运维身份鉴别、账号管控、系统操作审计等多种功能。基于协议正向代理实现，通过正向代理的方式实现对 SSH 、Windows 远程桌面、及 SFTP 等常见运维协议的数据流进行全程记录，并通过协议数据流重组的方式进行录像回放，达到运维审计的目的。相比开源堡垒机它多些安全方面的功能，例如账号双因子认证，满足更高的安全回归要求。
堡垒机实现价值如下：
实现技术层统一
统一运维入口
统一自然人与主机帐号间的权限关系
统一运维操作审计管控点
满足法规要求
政府： 满足《等级保护》系列文件中的技术审计要求
金融： 满足金融监管部门系列文件中的技术审计要求
企业： 满足《ISO27000》系列文件中的技术审计要求
云盾堡垒机功能特性有：
a) 操作审计
多面记录运维人员的操作行为，作为事件追溯的保障和事故分析的依据。
运维操作记录： 操作失误、恶意操作、越权操作详细记录
Linux命令审计： 可提取命令符审计，支持命令定点回放
Windows操作录像： 远程桌面的操作，支持全程录像，包括键盘操作、鼠标操作、窗口打开等
文件传输审计： 支持远程桌面文件传输、FTP/SFTP的原文件审计
b) 职权管控
通过账号管控和权限组管理，实现分职权进行人员和资产的管理。
账号管控： 运维账号唯一，解决共享账号、临时账号、滥用权限等问题
权组管理： 按照人员、部门组织、资源组，建立人员职责与资源分配的授权管理
c) 安全认证
引入双因子认证机制，防止运维人员身份冒用和复用。
账号双因子认证： 支持多种双因子认证机制，通过短信认证、动态令牌等技术，控制账号密码泄露风险
d) 高效运维
从架构、工具、ECS接入等多方面提升运维效率。
C/S架构运维接入： 支持SSH、RDP、TELNET、SFTP协议
支持各种运维工具： 支持PuTTY、SecureCRT、Xshell、WinSCP、mstsc等工具
ECS高效接入： 支持一键同步并导入ECS云服务器
4) 标签管理
我们在传统IDC架构中对管理服务器资源的时候通常是用的EXCEL来管理，没有专门CMDB系统，在管理主机的时候经常遇到主机各种问题，例如这台主机的owner是谁，哪个部门在用，什么环境的，装的什么系统，部署的什么应用。这些我们当时只能是用最古老的办法Execl来管理，所以信息更新不及时，数据容易丢失等确定。云上我们改用标签管理来解决这些痛点，标签管理可以实现对资源的分类和统一管理。有了标签，我们可以为每台云主机定义多个标签，以后在管理云主机的时候可以根据不同的标签来查找想要的主机了，非常方便。下面介绍如果使用标签管理：
标签使用有以下限制：
每个标签都由一对键值对（Key-Value Pair）组成。
每个实例最多可以绑定 10 个标签，每次最多绑定或解绑 5 个标签。
每个资源的任一标签的标签键（Key）必须唯一，相同标签键（Key）的标签会被覆盖。
每个地域中的标签信息不互通，例如在华东 1 地域创建的标签在华东 2 地域不可见。
解绑标签时，如果解绑之后该标签已经没有绑定的资源，则该标签会自动被删除。
绑定标签：
- 登录 云服务器管理控制台。
- 在左侧导航栏中，选择需要添加标签的资源，如 实例、云盘、共享块存储、快照列表、镜像 或 安全组。
- 选择地域。
- 在资源列表中，选中一个或多个需要绑定标签的资源。
- 单击列表底部的 编辑标签。如果资源是 实例，选择列表底部的 更多 > 编辑标签。
- 在 编辑标签 对话框里，
如果选中的资源已创建过标签，单击 已有标签，并选择可用的标签。
如果选中的资源没有创建过标签，单击 新建标签，并输入 键 和对应的 值。输入时应注意：
键 是必需的，而 值 是可选的，可以不填写。
键 不能是 aliyun、http:// 、https:// 开头的字符串，不区分大小写，最多 64 个字符。
值 不能是 http:// 或 https://，可以为空，不区分大小写，最多 128 个字符。
同一个资源，标签键不能重复，相同标签键（Key）的标签会被覆盖。
如果一个资源已经绑定了 10 个标签，已有标签 和 新建标签 会失效，需要解绑部分标签后才能再绑定新的标签。
- 单击 确定，完成标签绑定。
完成标签绑定后，可以使用这个资源的 编辑标签 功能或 ECS 管理控制台左侧导航栏的 标签管理 查看标签是否绑定成功，也可以单击资源列表上方的 标签 按钮筛选资源。
根据标签筛选资源：
- 登录 云服务器管理控制台。
- 在左侧导航栏中，单击 标签管理。
- 选择地域。
- 在搜索框里输入某个标签键（Key），并单击 搜索。
解绑标签：
如果某个标签已经不再适用于资源管理，可以解绑标签与资源。解绑后，如果标签已经不再绑定其他资源，标签会自动删除。
可以使用 删除标签 功能单个或批量解绑标签与实例。
阿里云目前仅为实例提供了这个功能。其他类型的资源没有这个功能。
可以使用 编辑标签 功能逐个解绑标签与资源。
一次最多只能解绑 5 个标签。
解绑标签详细操作步骤参见官网操作文档。
5) 企业控制台
在以前我们公司没到年终的时候内部经常需要盘点资源使用情况，研发部用了多少资源，测试部用多少资源，每个部门的费用是多少？哪个部门费用开销最大？在以前传统IDC架构中，这些都没有专门系统来管理，只能是一个部门一个部门进行盘点，excel各种统计费时费力，还经常出错。云上我们通过企业控制台就轻松搞定这一问题。企业控制台提供面向企业客户的云上资源管理、人员管理、财务管理等企业上云综合管理服务。区别于经典管理控制台独立操控、配置云产品的方式，企业控制台以统筹管理为出发点，帮助企业以公司、部门、项目等组织关系，规范企业操作流程，帮助企业管理企业上云的人、财、物。企业控制台主要包含运维管理和财务管理两个重点功能。
运维管理：
集中的用户管理（支持Member与Guest两类用户）
集中的权限管理
资源组管理
资源组内部用户权限管理
资源分组运维操作
财务管理：
多个独立云账号的财务关联（支付账号、资源管理账号）
多账号信用额度划拨
多账号现金额度划拨
财务主账号优惠额度共享
发票开具管理
分组财务对账
当前版本支持的云产品包括ECS、RDS、SLB、CDN四款基础云产品，据了解更多云产品陆续接入中。
主要业务场景
按照企业组织架构划分场景：
企业可以根据组织架构，按组织划分资源组，每个资源组配置独立的云资源，同时给每资源组设置不同的资源管理员。同时，企业主账号可以管理所有的资源实例。例如：我们企业，下设财务部，研发部，测试部，运营部。在资源组设置中，可以设置对应的财务部资源组，研发部资源组，测试部资源组，运营部资源组。此场景中，企业、云资源、人员权限管理架构图如下：
按照组织架构+业务项目划分场景：
企业中某个部门可能有多个项目，多个项目的资源需要分开结算，且分属不同管理员进行管理，那么可以针对某个部门或企业中的多个项目，建立多个资源组，针对不同的资源组，设置不同的管理员进行管理。同时，企业主账号可以管理所有的资源实例。假设企业A，下设财务部，研发部，运营部，在资源组设置中，可以设置对应的财务部资源组，研发部资源组，同时，针对研发部的两个不同项目，可以设置项目一资源组，项目二资源组。此场景中，企业、云资源、人员权限管理架构图如下：
资源组报表
企业控制台提供了将资源进行分组能力，这里将提供对应的报表查询。
资源组报表根据资源组管理中的分组资源，进行财务对账的拆分，数据展示在报表中。
可以切换账期区间查看趋势，也可点击资源组查看实例明细，如下图
注：资源组报表中，针对账号下设置的资源组，仅显示该资源组中包含的产品的信息。
