• 前言

• 美图公司是如何使用阿里云的

• 我们是如何做成本优化的

• 我们在阿里云上遇到了哪些坑

• 我们如何做自动化运维的

前言

本篇文章可能更多的是文字表述，没啥高深的用词，都是大白话，需要各位朋友有耐性的阅读下去，也希望各位朋友能够提出宝贵建议。

美图公司是如何使用阿里云的

关于使用方面，我想从以下几个点简单叙述一下，

• 权限规划
• 区域规划
• 网络规划
• 型号规划
• 统一登录规划
• 命名规划

权限规划

权限规划只要是在账号权限规划上，一般是主账号+子账号，然后通过ram来进行对应授权，为什么要做这个，因为主账号一般控制在运维手上，子账号可能会存在其他运维手上以及某些开发手上，那么就需要做严格的权限控制。目前阿里云ram有几个点：用户，群组，角色，策略等功能，目前角色和策略都支持自定义，然后可以应用到用户上，群组上。角色可以附加到ecs上，可以用高权限获取一些云上资源信息。

区域规划

做区域规划需要考虑几点：

• 第一、你的业务架构，比如我有idc机房在北京，那么我们上云的话一般会考虑北京region，又比如我的业务用户主要分布在江浙一带，那么我们一般就考虑上海或者杭州region。
• 第二、一定要找阿里云技术问到当前region的最新可用区是哪个，机器储备量级是多少，因为新可用区一般会有新机器，新型号，一般来说带来的好处就是性能高还便宜；另外老可用区机器型号非常少，经常会遇到售馨的问题。
• 第三、当我们定好了区域之后，后续再改变会非常麻烦，所以前期的调研准备一定要完善，考虑要全面。

网络规划

关于网络规划，主要有以下几点需要考虑下：

• 第一、vpc规划，可以按照你的业务架构划分vpc，不同vpc之间可以做一些安全组也隔离流量。例如我有大数据业务，普通业务，运维业务，那么我可以简单创建几个vpc：大数据vpc，生产业务vpc，测试业务vpc，运维vpc。
• 第二、子网划分，每一个vpc划分多个子网，比如我拿生产业务vpc来举例子，可以划分为：容器子网，mysql子网，redis子网等。(注意：子网在阿里云就是交换机的概念)
• 第三、子网的ip数量，这个的定义需要提前规划和统计业务量级，vpc本身是一个大的网段，单个子网的网段要合适，太大浪费，太小扩展麻烦。

我们内部的子网划分：

型号规划和命名规划

把这两个放一起讲，一般来说公司会选择一款型号来作为自己的主力机型，这个配置比较贴近自己的业务形态，另外这个机型也要跟阿里云备案，让他们提供足够大的节点池。命名规划的话，我们可以按照业务提供能力来做不同的命名方式：

k8s节点: aly-k8snode-10-10-10-1.meitu.commysql: aly-mysql-A-10-10-10-2.meitu.comredis: aly-redis-B-10-10-10-3.meitu.com

做好这个，第一能更好区分不同节点功能，第二能更好的去做自动化运维工作。

统一登录规划

做统一登录就是要做跳板机、做权限管理。有以下几点要考虑：

• 第一、用户登录虚机需求，运维侧需要做一个公共跳板机，所有的登录操作都需要通过该机器跳转。
• 第二、开发用户对于线上的机器不能有永久权限，开放的一般是临时权限，所以我们需要有一套授权，回收权限的平台。
• 第三、做好操作追踪，防止一些 高危人员做一些非法操作。

我们内部的工单平台：

我们是如何做成本优化的

关于成本优化，是一个非常重要并且也非常头疼的一件事情，当服务趋于稳定后，一定要慢慢去优化成本。那么关于成本优化的事项，我们做了这些事情：

• 容器化
• 弹性伸缩的深入使用
• 做好资源开通记录和监控
• 架构规划(内网和公网)
• 增加混布实例
• 定时巡检，删除无用资源
• 最低实例实行包年包月

容器化

容器化趋势，他也是作为成本优化最好的方案之一，目前我们公司95%的业务已经容器化。我们在云上使用的是托管的k8s集群，另外我们自己有一套自研的k8s管理工具，来做日常的业务发布，迭代等操作。

弹性伸缩的深入应用

我认为云服务和自建IDC最大的差距就是弹性伸缩的应用，我个人也是非常喜欢弹性伸缩这一个服务，因为他能很好的提升资源利用率，并且显著的降低成本。我们在以下几个场景用了弹性伸缩服务：

• 第一、托管k8s服务的容器节点。
• 第二、普通虚机业务开通弹性伸缩。
• 第三、容器业务服务开通HPA。
• 第四、共享带宽的弹性。

结合这些弹性伸缩的场景，我们做了一些工具，主要是观察全局的一个情况。阿里云弹性伸缩控制台总览：

容器单个业务伸缩策略详情：

做好资源开通记录和监控

这个非常重要，因为我们经常会遇到一个情况是：业务临时有个需求，需要开一台测试机器来做业务验证，我们开通完交付。他们测试完成之后并不会通知你是否需还需要这台机器，导致慢慢被遗忘，所以增加了额外的费用。另外一点我们也可以根据记录去做一些下线工作：当一个业务需要下线时候，我们可以根据他们的资源申请单去下线相关的服务，避免漏下或者错下。

架构规划(内网和公网)

这个点涉及到的一般就是流量费用，公网带宽费用，我们遇到过一些情况是：业务调用能走内网的他不走内网，非要走公网，甚至他根本就不知道有内网地址。所以基于这个我们做了以下几点：

• 第一、服务上线评审，新服务上线一定要拉上运维，开发一起做一个评审，因为开发不懂线上网络结构，他们认为只要服务能够正常通就是没问题的，所以他们忽略了非常多的细节，比如内网调用等。
• 第二、服务提供内网域名，公司业务越多，那么存在互相依赖的地方就越多，这些内部依赖的动作能通过内网的一定要通过内网，不要从公网绕一圈。比如我在阿里云上下载oss图片，明显有内部的oss地址可用。
• 第三、服务部署规划，当有A的子服务B需要上线，且B是完全给A调用的，那么该服务上线的区域一定是A所在区域，不要存在跨可用区，跨region，跨专线等操作，这些都会带来额外的流量费用。

增加混布实例

混布一般是针对非容器化业务的，虽然混布不建议，但是也是不能缺少的。公司肯定会有类似的业务，并且年代久远，无人维护，像这类业务就可以统一丢到一两台机器上部署即可。

定时巡检，删除无用资源

这一步也是运维日常，我们会跑一些自动化的脚本去删除一些无用的服务，并且列出一些无主资源去让业务方确认是否释放。

• 镜像。阿里云的镜像可以只留最新的几个，删除老的镜像。
• 快照。跟镜像类似。
• 磁盘。删除无挂载，也无需保留的磁盘。
• OSS。清理oss空间，业务方会保留非常多的静态资源，他们也不会删除，也不会去管，所以需要我们来推动他们来确认清理。
• ECS。删除临时测试机器，删除业务已经下线的机器。
• ......

虽然这些都是比较便宜，不过积少成多，成本优化本身就是一个漫长的过程，所以一点点的优化才是王道。

最低实例实行包年包月

这个方案主要是针对弹性伸缩来说的，我们会观察每一个弹性伸缩组一天的监控数据，包括cpu利用率，实例数量。然后观察几周的数据，发现最低的一个实例数量，把这部分实例转成包年包月。

如下图，我们可以拿2-3台进行转包月操作：

我们在阿里云上遇到了哪些坑

其实阿里云在国内市场已经做的非常好了，遇到的坑也大多比较贴近自身业务，有些坑他们也已经做了架构调整规避了。

• 区域资源配额问题
• NAT 带宽问题
• 实例售馨问题
• 可用区交换机网段过大

其实坑还有很多，只不过有些都是小坑，有些可能我自己也有点忘记了。

下面简单解释下这些坑：

区域资源配额问题

我们在重要节日推广，需要大量的机器储备，某年春节的时候遇到了区域资源配额瓶颈问题，即这个账号默认可以使用多少的vcpu(这个主要是按需的，包年包月的不会计算进来)。当时推广的时候，我们机器完全扩不上来了，最终排查到是资源配额上限了，也是紧急通知阿里云帮忙调整。

NAT 带宽问题

最早阿里云的 NAT 还是有单独的带宽配置的，当时我们有一个服务推广效果比较好，直接把 NAT 打满了，导致我们整个vpc内的网络都非常慢，严重影响了我们服务质量。目前阿里云刚把 NAT 带宽调整成共享带宽包，带宽和 NAT 实现了分离，另外带宽也可以动态调整，非常的方便。

实例售馨问题

如前面所说的，一个企业一般会选用一个主力型号，当时是弹性的机器过多，导致该型号实例售馨，新机器无法创建。针对这个问题，我们做了如下两个解决方式：

• 设置多实例弹性，弹性伸缩可以配置弹多个实例型号，并且也有优先级。
• 替换大规格机器，简单来说就是用一台大规格实例顶替多台小规格实例。

可用区交换机网段过大

遇到这个坑的背景也是我们想使用新可用区，因为我们IDC跟阿里云是默认专线打通的，所以会存在网段分配的问题，当初分配给阿里云的网段已经用完了，所以我想开新区，必须释放老的交换机或者拆分它。分配的网段用完了的根本原因还是：当初规划不合理，交换机设置过大，然后根本用不到这么多。

我们如何做自动化运维的

• 弹性伸缩服务更新
• 统一登录权限申请
• 云上资源数据统计
• 自定义资源监控告警
• 定时弹性伸缩控制成本
• 重要业务推广通知
• 移动端运维

关于自动化运维这一块，其实需要紧密贴近公司的业务来做。只要你平时感觉哪个操作经常做，又非常繁琐，那么他就可以用工具替代，所以下面的东西都是我平时经常操作而抽象出来的。

弹性伸缩服务更新

弹性伸缩服务，一个非常重要的操作就是更新，我们每个弹性伸缩组都有上百个实例，不可能去一个一个更新，肯定是创建一个镜像后，然后按照这个镜像进行滚动更新。我们有100个左右的弹性伸缩组，所以这个更新操作是经常需要的，所以我做了自动更新操作，并集成到了移动端和web端。

统一登录权限申请

我们有自己的一套权限申请平台，相应的人员可以申请线上的机器，申请可以是临时的，也可以是拥有的。

云上资源数据统计

这个统计信息会统计我们当前阿里云使用了多少机器，多少cpu，多少内存。这个信息会发给我们老大，同时开发老大也会关注这个，因为涉及到成本。

自定义资源监控告警

其实阿里云集成的监控告警已经比较全面了，他可以通过邮件、短信、钉钉等方式发送出来。不过涉及到业务层面的，或者更贴合我们自己需求的，一般都会自定义通知，大家可以看我这篇chat，《美图分享：适用于中小型企业自研的监控告警通知系统（附源码）》，我平时自定义告警都是通过这个项目进行发送的，种类繁多。

定时弹性伸缩控制成本

我们完全按照阿里云弹性伸缩设置默认的伸缩规则有时候可能还不能满足，借此我们可能还会设置一些定时伸缩，比如我晚上2点就让它维持两台机器。这个也是控制服务稳定性的一个操作，因为在某些时刻，服务是1台机器扛不住，两台机器会缩容的状态。我们开发了一个工具展示定时任务的列表(由于业务迁移了，所以这里没数据了，嘿嘿)

重要业务推广通知

一般我们的业务在重要节日中，都会有推广。那么推广前，我们一定需要保障该服务的稳定性，该扩容的扩容，该加配置的加配置，所以我们做了重要推广通知的平台，来重点保障春节，五一，国庆等重要节日业务推广。

移动端运维

移动端运维也是今年我们新引入的，因为我们已经厌烦了天天背着电脑了，能在手机上操作就在手机上操作了。其实上面的很多服务都是移动端的界面。由于自己开发能力有限，所以只开发了 IOS 客户端，后端就是python写的。(有兴趣的朋友，可以一起交流一下！)