阿里云上SRE

发表于 更新于 分类于 本文字数： 3.8k 阅读时长 ≈ 3 分钟

在云上的运维和自己物理机去机房部署有什么区别，这个笔者在这行20年还是深有感触的。

网段划分

首先我发现在云上运维我发现很多公司都不注重网段的划分，但是自己在IDC部署的时候没有人不重视这个，因为不然可能交换机都通不了，跨网段通信都会有问题。所以先说一下内网网段划分的事情。

我们知道公认的内网网段主要是如下3段：

网段 IP范围 IP总数
10.0.0.0/8 10.0.0.0 ～ 10.255.255.255 16777216
172.16.0.0/12 172.16.0.0 ～ 172.31.255.255 1048576
192.168.0.0/16 192.168.0.0 ～ 192.168.255.255 65536

不过现在很多同学对于这一块缺乏认知，很多时候一个vpc就把10.0.0.0/8 给用了，好了，后面公司别的业务要上云，要拆分，还得用172的那个网段去，这样一个是不规整，另外一个存在很大的浪费。

从我的一般见到的公司来看，一个vpc给一个B类/16的网段就足够了。比如公司第一个业务，我们就用 10.1.0.0/16 这个网段。

一个vpc划分好以后，那后面我们就要根据资源分网段了。因为我们要满足3az的部署方式，所以同样资源就必须要分3个不同的网段。

比如 slb， redis， rds 这些就每个可用区都分一个/24的网段。

ecs这个比较特别，因为阿里云terway的缘故，可能一个可用区里会超过256个容器同时启动，所以一般情况下我会分 /22， 这样有1024个容器可以同时启动，这个具体可以看，或者/21这样，那就2048个，一切需要根据业务的实际开发情况来。但是原则是宁愿前面少分点，别浪费，不然来新的资源可能就不够分。

这种网段划分好以后，我们就可以容易使用安全组进行内网隔离，设置非常高效的白名单策略。但是前提就是设计好整体网络。

一般情况下我们还会单独分一个运维管理的vpc，主要是方便资源隔离和访问控制。因为这个网段要访问其他业务vpc的相关监控端口，有些是主动请求过去，有些是业务直接上报过来的。同时还有一些jumpserver这些服务都需要单独做策略。

权限控制

第二个要注意的就是各个云产品的权限控制，这点阿里云就做的非常不好。比如ecs，rds，redis，oss这些产品都是需要使用ram来控制的。但是还有些产品都有自己的权限控制机制，比如ack，大数据相关的。而aws都非常统一。

但是阿里云ram里又区分了用户组和角色，然后用户组也可以添加权限策略。阿里云也默认给了一些权限策略，也可以使用编辑器来自由编写。

整体原则是无论是ram里还是产品里，我们只修改roles和用户组。千万不要单独给用户授权，这样的好处是比较直观，缺点是后期很难维护。而且方面我们后面实施sso管理。

合适的可用区

第三个注意点是要确定合适的可用区。但是阿里云比较坏，把很多资源都藏起来了，所以是企业客户，一定要勤快一点找找商务。

比如我这个个人账号，第八代amd全大宋只有深圳有。但是我登陆公司账号，那就太多了。而且不同公司账号能看到的可用区也不同，这也是难为这些阿里云研发兄弟了。

https://ecs-buy.aliyun.com/ecs#/instanceTypeByRegion

从个人角度来说，坚决不用一个地域里只有一个可用区的产品和型号，企业级应用必须防范整体可用区挂掉的事情。而且这个各大云厂商都是常有的事情。比如这次阿里云雅加达的B区又全挂了，结果贵司用了Hologres就是在这个区，而且雅加达就这一个可用区有，那这种影响业务了你都没地方切，责任算谁的？

还有一个不同的地域，云厂商的产品策略是不一样的，还是拿阿里云来说，北京，上海，杭州是它最核心的区域。所有产品基本上这些地方都是非常全的。而比如深圳，广州这些就未必了，海外也是一样的，新加坡什么的比较全，但是菲律宾什么的就会少很多东西。

同时这些厂商在做内部升级的时候也都是从非重点区域开始升级，最后再升级到核心区域。这个无论哪家云都是这样的，aws，google，腾讯云这些都是如此。这个你其实大概看一下az的数量和产品丰富度就可以大概猜出来。实在不放心就再问下对应的商务。

https://www.alibabacloud.com/zh/global-locations?_p_lc=1

这里阿里云有一个页面列的比较全。但是我一直记得原先还有一个地方列了每个产品在一个地域有多少个可用区的。不过实在是找不到地址了。

还有可用区和可用区之间的连接延迟是怎么样的。

https://nis.console.aliyun.com/performance/netana?type=inner_region

这个是阿里云自己的数据。比如这个北京地域，看看az和az之间差异都是2ms了。那意味着两个az之间差了大概200公里左右了。

云产品问题

第四点云产品有缺陷怎么办？

首先从运维角度来看宁愿自己加人手搭建维护也不用这种产品。比如阿里云有些区域都没有3az的kafka，这不是搞笑嘛，那我们就自己搭建来维护。这种相对比较成熟的开源组件维护起来也是会踩坑的。

另外就是自己无法维护的，比如前面说的hologres，那研发一定要用怎么办？除非业务方确认挂了也没事或者研发侧有明确和可执行的降级机制，不然宁愿不上。

成本控制

这个在阿里云上主要通过2个方面去统计成本。

一个是资源组，就是我们建一些资源的使用资源组去确定是哪些项目用的。资源组还有个功能是可以在人员授权的时候可以限定某些角色只能看到和操作某些资源组下的资源。

同时一定尽量避免某一组件公用，我为什么上面要划分单独的运维网段，就是为了这些考虑的，因为运维一般公司多个产品线都会共用一套基础设施的。

另外一个是在财务和账单里-成本分摊-财务单元。为什么还有财务单元呢，因为阿里云有个坑点就是有些产品不支持资源组设定的，但是在财务这边至少账单里是分的。所以大家要是做账单系统什么的，一定要从财务单元开始，其他的都没有统一的地方。

至于哪些产品有资源组设定，哪些没有，至少我是看不出规律来。有些是阿里云自己开发的，有些也是外面买的厂家的产品。比如quickbi，clickhouse这些都是都是外部供应商提供的，有些会做一些定制化的。

可用性

我曾经测算过如果自己的application可用性是100%的情况，那使用阿里云这些服务后整体可用性可以到多少，测算下来单az部署是99.62%（每月不可用时间是178分钟，将近3个小时），3az部署是99.86%（不可用时间为66分钟）。是不是觉得很不可思议。

https://help.aliyun.com/zh/document_detail/56773.html

这里可以查看所有产品的SLA

这里用到的阿里云产品为：

产品 单az可用性 3az可用性
ecs 99.975% 99.975%
vpc 99.95% 99.95%
rds 99.95% 99.995%
redis 99.90% 99.99%
mq 99.95% 99.99%
kafka 99.95% 99.99%
apigateway 99.95% 99.99%
load balance 99.95% 99.995%

这可是假设自己可用性是100%的情况下，但是实际上我们自己服务的可用性怎么可能是100%呢，所以我们在什么都不做的情况下不要对可用性报太大的预期。

因此这里核心的部分就3点：

  1. 减少对外部的依赖，不管是中间件还是外部接口。

  2. 如果有依赖，那必须考虑好限流，熔断，降级这3个怎么做。以保证在最差的情况下我们还能提供基础功能的服务。

  3. 在有客户端的情况需要跟客户端配合。

上面第二点的降级是必须要考虑的，因为这些云厂商的赔偿方式最多就是赔偿你这个产品当月产生的整体费用，他们肯定不会赔偿你业务损失的费用。那这个时候你如何取舍？当然你也可以跟云厂商索赔业务损失的费用，那云厂商也要愿意给，阿里云新加坡C区全挂的问题贵司索赔千万，这个问题把阿里云几任销售都熬走了也还没最终解决。

你看默认阿里云一定要低于95%才赔偿月度服务费的100%，也就是一个月宕机39个小时才赔100%的服务费，就问你能否接受吧。

说完技术上，那还有组织管理上的问题。就是这个SLA最终谁来负责，这个负责不是说出了问题就是一定是谁的责任，而是谁最关心这个事情。而这个谁来负责的人，他是否有一票否决权。有些公司业务繁忙，都是紧急上线，那SLA负责人认为有风险，是否可以否决上线。这些问题我们必须提前抛出来。我认为就是责权利三者统一，有责任没有权，那就把利给足了。

运维框架的统一。

我见过很多公司内部各个开发团队各用各的一套，这种对于业务开发是好了，但对于运维线的同学就太痛苦了，这个业务的prometheus端口是用的业务的端口，那个业务是业务端口+xxxx的端口，这个业务的接口是 /management/prometheus， 那个业务是 /api/prometheus， 这实在是让人困扰的。

所以一般比较规范的公司就是统一一个底层框架，这样大家都用这个框架的统一汇报接口。你也不用考虑哪些基础内容要汇报，除了可能有的业务汇报内容，其他都统一做了。

ci/cd的流程化。这个后面单独来写吧。核心点就是如何线上发布跟沙箱发布保持一致。