在介绍自动化三剑客之前，滕圣波为我们讲述了阿里的上云路和智能运维的发展策略。
以双十一为例，阿里集团的业务量往年只有60%～70%承载在阿里云上，而今年将百分之百跑在公有云上。这意味着阿里云就是整个阿里集团的运维——将创建机器、计算力、存储、网络和管理机器及数据库这些本质上都是运维的要做的事进行代码化和自动化。
由此可见，阿里云已经成为阿里集团的技术底座。滕圣波还表示，未来阿里云集团的技术输出只通过阿里云，并且技术全面开放，从而达到集团和生态共享，促进互联网生态发展。
既然阿里云担当了整个集团的运维一角色，那传统运维人员又该何去何从？这本质上也是DevOps的问题。滕圣波以这么一个场景为例给出答案：半夜有一个严重告警，目前的机制是系统一旦出现异常，就会把相关开发或负责人叫起来。这意味着，截至目前，人工职守无可避免。但是阿里云的目标是无人职守，毕竟一周连续四次都被凌晨叫起来去处理告警身体是吃不消的。想象一下一个运维人员半夜起来看日志、采取动作；动作是什么？无非就是机器不够用了、代码多了、负载多了，如果加机器加资源解决不了就回滚代码。这些肯定都是可以自动化的，顺势而为，人工智能必成发展突破口。
我们都知道阿里云有SLA，而所有都是从架构出发的，但是架构不仅仅是阿里云的事情，也是客户的事情。一个架构是针对容量规划的，针对１万人的架构和针对１亿人的架构一定是不一样的。众所周知，企业都不是一开始就走到１亿人这个步骤，而是从１万人慢慢成长起来的。企业成长过程中需要不断调整自己的架构和运维。所以无人职守并不只是阿里云的职责，也是客户的职责。
简言之，“从运维到SRE，无人值守是目的，自动化是无人值守的手段，而人工智能又是自动化的手段之一。其中，无人值守的最后一公里由客户侧运维开发。”
而后滕圣波为我们重点介绍了自动化三剑客。
第一便是弹性伸缩——即基于AI预测的弹性伸缩。原有监控指标模式，监控指标变化敏感，引起实例数量震荡，扩、缩容操作和业务变化存在延迟；智能预测模式可以做到预测业务变化智能调整实例数量，结合目标追踪模式完美贴合业务变化，能够最大程度地节省成本。
我们知道大多数公司的业务都是有流量曲线的，有高峰、有低谷，那对应的业务承载能力如何得知？好比双十一，阿里云在双十一有庞大体量，它所承载的业务量一定是在双十一之前按照顶峰就计算好的。但是这有什么问题？比如双十一之前阿里云有预估，通过全链路的压力测试知道需要准备多少资源，但是问题也来了，我们要提取多久准备这个资源？这是个成本的问题，资源是很贵的，如果我们提前１个月准备资源可能就多几亿元的成本负担在上面；如果我们能够提前１小时准备这个资源，那我就可能节省出来很多资源。越能够灵活地准备自己的资源，就越能够省钱，省钱极致到什么程度？最多能省多少钱？如图所示，容量上限和曲线之间的面积是我们最多能省的钱，这是弹性伸缩最大的价值。可惜，理想很丰满，现实很骨感。弹性伸缩很难把所有的成本都省出来。
弹性伸缩具体是怎么应用的？以下用两个例子来说明。
先看上面这张图，从技术角度分析为什么会出这个问题。首先发生的事情是一大堆狂点赞，这两个人的粉丝量加起来是巨大的。如果这些粉丝只狂点赞还好，赞就是数据库里多一条消息，多一条数据记录。赞并不难，难的是转发。转发这个事情太恐怖了，它不仅仅是克隆，在数据库里多几条记录。转发造成了更多消息流推送，消息量瞬间几何倍增。比如一开始100万人看到这个消息，里面有10万人转发，迅速在整个网络里造成了大量消息，挤占了大量网络，造成了大量数据库写操作。
读不可怕，因为读的话可以做分级、可以做CDN，但写这个东西太夸张了，写是必须真实的往数据库里做操作的。而且数据库当时有大量的缓存，而写不是缓存的特点，所以一下子就被打穿，接着就成为数据库的累赘了。在疯狂写数据的时候，数据库突然崩了，那么服务就会限流。但限流对于很多用户来讲是不可接受的，他会认为是服务宕掉了。这时候我们就可以用弹性伸缩去解决。有两个思路，一个是一定要快，快是什么概念？
大家看看基于监控逐步转化的预测，有很多都是基于监控指标的算法。当你的曲线已经开始往上走时，监控一定是第一时间能发现的，这时候我们能做的是赶紧扩充自己的计算资源、存储资源、数据库、缓存，可是实际上我们资源扩充的真实情况是滞后的。为什么？监控指标出现动作时意味着流量已经来了，这时候弹指标已经迟了、跟不上了。阿里云上弹一个指标大概十几秒，这个十几秒对一个突发的新闻事件来说是不够快的，有可能它涨了１倍了，资源才涨了30％。所以弹性计算、弹性伸缩最核心的就是要做到快。
推荐阅读：叶紫
