云会“杀死”运维吗

云时代的运维是怎么样的？

冲浪是一个非常刺激的极限运动。相比海浪的力量，冲浪者的个体力量是渺小的，每一次冲浪都是一次冒险。但智慧并且勇敢的冲浪者会仔细观察海浪的方向并调整冲浪板与海浪方向一致，当海浪抵达时，冲浪者会站起来，在海浪的冲击下急速前进，享受浪尖上的快感。

冲浪者很清楚，自己成功的关键在于找准海浪的方向。我们技术人员也一样，只有保持对新技术的敏感性，并及时调整自己，才能借助浪潮的力量快速进步。

给大家讲一个真实的故事。2009 年，阿里云刚刚成立的第二年，时任淘宝技术总架构师行癫（现任阿里云总裁）宣布淘宝网将抛弃 Oracle，转投云上的自研数据库。获知此消息后，八十多个 Oracle DBA 把当时的 DBA 负责人后羿堵在会议室里，“如果上边铁了心要干，兄弟们的前途在哪里？”还好，技术人是讲理的，一场恶斗转化成了几十个工程师坐在会议室促膝谈心。既然上云是战略，为何不顺势而为？就这样，一群 Oracle DBA，开始亲手拆毁自己安身立命的系统。2013 年 7 月，淘宝最后一个 Oracle 数据库下线。时至今日，整个阿里集团，所有的核心业务 100% 跑在公共云上。

是啊，既然上云势不可挡，我们何不顺势而为，看看云上运维是什么样子的？

首先，云上运维和传统的运维，操作的目标是不一样的。传统的运维人员，需要能够熟练的手动操作来自众多厂家的计算、网络、存储等硬件设备，而云上的运维人员完全接触不到物理设备，取而代之的是云上的虚拟资源，例如云服务器，云盘，虚拟交换机等。云厂商将对资源的操作全部抽象成了软件定义的 API 接口，并用统一风格的 SDK、命令行进行封装，提供给运维人员使用。云厂商提供的图形化的运维控制台，也不过是 API 的封装而已。

其次，云上运维是高度简化的。传统的运维，需要学习来自众多“大厂”的认证，例如，网络运维要学思科的认证，数据库运维要学 Oracle 的认证，系统运维要学 IBM 的认证，等等。而在云上，虚拟专有网络产品将网络设备的管理和运维变得统一和简单，云上数据库产品实现了智能化的数据库管理，云服务器实现了动态的扩缩容和热迁移，这些都大幅降低了运维操作的门槛。云上的运维人员不再需要感知底层基础设施的细节，更不需要考取高难度的认证。即使是创业阶段的小企业也可以拥有和大企业同等的运维能力。

但是运维简化，并不意味着运维的重要性降低，相反，在云上，运维变得比以前更加重要了。
------------------------------------------------------------------------------------------------------

2020年纵横数据年中促销活动
限购2台特价
韩国服务器 美国站群服务器
CN2线路 优选配置 首月半价
更有国内高防服务器超值特价
100G-200G防御
年付更优惠
数量有限 售完为止
欢迎在线客服 艾娜QQ 3164055976 482986990

云时代运维面临的挑战

为什么在云时代，运维变得更重要了呢？主要有两个原因，一是云上运维的范畴比以往扩大了，二是云上企业对于稳定性的要求更高了。

从范畴上看，云上运维包含了从蓝图规划，到上云交付，再到云上管理的全过程。如果我们具体到流程和阶段，包括了设计选型、资源交付、系统交付、运维调优、扩缩容、资源运营、备份容灾，安全 & 审计等等。

从稳定性方面看，通常云厂商只负责基础设施的稳定，上层应用仍由企业开发人员自主开发，同时云上应用本身的稳定性也由企业自己的运维人员负责。如果具体来说的话，企业运维人员需要负责持续发布过程中的蓝绿发布、灰度发布、分批发布、自动回滚等的实现，以及应用层的监控、事件告警体系的建设。另外，云上基础设施的稳定性不能单纯依靠云厂商，也需要企业运维人员的相互配合。例如阿里云的云服务器单台实例的可用性达到 99.975%，但仍然存在着万分之 2.5 的不可用时间。企业的云运维人员可以采用监控、负载均衡、多机热备、两地三中心等常用的高可用设计，在不是百分百可靠的基础设施上，搭建百分百可靠的应用。

具体来说，云上运维主要面临着以下挑战：

首先，运维排查问题的难度增加了。由于云上“黑盒子”的存在，当故障突然发生时，运维人员往往只能看到服务出现异常了，很难快速判定问题出在哪里？是云服务商的基础设施出问题了，还是我自己的代码出 bug 了？…… 甚至就算排查出是云服务商某个服务的问题，部分运维人员也只能打电话给客服寻求帮助，而从客服得到的回复往往难以令人满意，从而耽误了故障恢复时间。

第二，云服务发出的消息、日志、事件等难以有效处理。如果运维人员每天收到几千条短信或者邮件，一定是无法及时处理的，只能无脑忽略。但是又不能设置邮件规则将它们全部扔到垃圾箱里，因为会担心漏掉重要的通知，比如服务器宕机的通知。

第三，资源的膨胀带来了管理的复杂性。所有的资源都是软件概念，对于一个大企业来说，这些资源可能分布在全球的十几个 region，分散在几十个云产品的控制台，服务于几百种不同的负载或者在线服务。更可怕的是，这些资源一直在变化。如何有效的跟踪、审计、创建、释放并保证无浪费？

第四，云产品的频繁升级带来了运维的频繁被动变化。云产品的选择非常多，实例类型纷繁复杂，包括预付费、后付费、预留实例券，什么性能突发型、计算型、通用型、GPU 实例、专有宿主机、裸金属实例，容器服务、Kubernetes 或者 Swarm、弹性容器实例，等等。更要命的是，这些云产品还在不停地发布升级，如何选择适合自己的产品？新功能如何才能帮助到业务？…… 盲目追随云厂商的脚步不是良策。

如何调整才能适应云时代的运维？SRE 可能是答案

如前面所说，企业上云之后，仍然有大量的运维需求。但此时的运维，却又与传统的运维截然不同。企业应该如何进行结构调整以适应上云后的新形势呢？

DevOps 是现在提到的很火的概念，DevOps 实践的整个生命周期是从计划 -》编码 -》构建 -》测试 -》发布 -》部署 -》操作 -》监控，再回到计划，是一个循环。其中发布、部署、操作和监控（下图的黄色部分）是属于运维领域的。

DevOps 实践打破了开发和运维之间的壁垒，开发人员可以直接负责运维。云上的运维已经和软件开发融为一体，强调高度的自动化，沉淀了一系列的运维工具和运维平台，并朝着 AIOps 和 NoOps 的方向持续演进。

而反过来，运维人员如果能掌握开发技能，结合自动化工具的使用，是否能够做的更好呢？答案是肯定的。运维人员可以转型升级为兼具开发技能和运维技能的站点稳定性工程师（SRE）。Google 最早推出了 SRE 这一概念，并使得 SRE 部门成为其承担运维职责的一个研发部门。越来越多的上云后的企业，开始把自己的运维部门改造升级为 SRE 部门。

SRE 听上去很美，但真正要做到并不容易。以阿里云为例，早年阿里云也走过人肉运维的痛苦阶段，尽管运维工程师 7*24 轮班 on call 待命，但客户仍然投诉不断，系统问题不断。后来，阿里云团队开始建设稳定性，通过监控报警将故障的平均发现时间从 1 小时缩短到 10 秒钟，同时借助 AI 预测算法，在某些情况下可以在故障发生前，提前预警并采取行动。现在阿里云每年发布上千次变更，难免会出现变更导致的故障和异常，但是 SRE 团队蓝绿发布、灰度发布、分批发布、自动回滚、热迁移等技术，实现了发布全过程无人值守。

目前主流的云上应用架构是自建 API 网关 + 微服务 + 分布式 RPC+ 消息队列等，这种架构需要的云上基础设施是负载均衡 + 云服务器 + 虚拟专用网络 + 云关系数据库等，其运维方式如前面介绍的。未来几年比较确定的趋势是云上应用开发会越来越多的使用 Reactive 响应式 (反应式) 编程，全异步、事件驱动，对应的基础设施则会容器化，隐藏掉服务器这一层，这预示着运维工作会越来越多的围绕容器编排，比如 Kubernetes 展开。中远期的未来，函数计算这种 Serverless 的开发模式将会流行起来，对应的基础设施则会简化到连容器都看不见了。用户不再为基础设施而付费，而是为实际的计算次数付费。云服务商会利用机器学习等手段，来保证函数计算所需的基础设施是高可靠的和高度灵活的。到时，运维人员已经不需要关心资源的编排了，但是函数内业务的监控和运维动作的自动化还是需要的。更长远的未来，云计算，边缘计算，本地计算，可能会统一到一起，不再区分“线上”和“线下”，取而代之的是一种无处不在，但又不被人感知的计算力。具体来说，应用开发者写完代码，保存起来，就完成了业务的更新。“基础设施”和“资源”这两个概念，将彻底消失，只留下数据本身，包括静态数据（代码 + 配置）以及动态运行时数据。而运维，并不会消失，但会从面向资源的运维，变成面向数据的运维。