IT诞生以来，运维就扮演着重要的角色。在IT企业，尤其是互联网企业中，运维、开发和测试被称为驱动技术进步的三大支柱。驾马车。为了进行数字化转型，金融、政府、医疗、教育、制造、交通等其他行业也纷纷建立或大或小的数据中心。为了维护这些IT系统的正常运行，运营中心设立了大量维护岗位。可以说，信息技术已经改变并正在改变我们身边的所有行业，只要有IT系统，就会有运维同学的身影和贡献。但是近年来，云时代的到来让很多运维同学感到焦虑，“云计算就是未来”已经被大多数人所认同。2019年Q1，公有云IaaS市场同比增长74%。越来越多的企业开始将线下数据中心、机房迁移至公有云。而一旦企业放弃自建IT基础设施，甚至将员工办公电脑搬到云端（桌面云），由公有云厂商提供服务，企业还需要那么多运维人员吗？与此同时，DevOps思潮席卷全球，大家都在试图“组织变革”，打破开发-测试-运维的界限，由开发人员直接负责自动化测试和运维。更进一步，AIOps甚至NoOps从DevOps演化而来，人工智能开始在运维领域大显身手。云计算和DevOps是天作之合。云是DevOps最好的平台，DevOps是云上的最佳实践。在云计算和DevOps的双重压力下，运维的未来将何去何从？1、云时代的运维是什么？冲浪是一项非常刺激的极限运动。与海浪的力量相比，冲浪者个人的力量是微不足道的，每一次冲浪都是一次冒险。但聪明勇敢的冲浪者会仔细观察海浪的走向，调整冲浪板，使其与海浪的方向一致。当海浪来临时，冲浪者会站起来，在海浪的冲击下向前冲去，享受浪尖上的惊险刺激。冲浪者知道他们成功的关键是找到海浪的方向。我们技术人员也是如此。只有保持对新技术的敏感度，及时调整自己，才能借助浪潮快速进步。告诉你一个真实的故事。2009年，阿里云成立第二年，时任淘宝首席技术架构师邢典（现阿里云总裁）宣布淘宝将放弃甲骨文，转而采用自研云端数据库.80多名OracleDBA闻讯后，将时任DBA当家的侯毅围堵在会议室，“如果上级铁了心，那兄弟俩的前途如何？”幸好技术人讲道理，一场激战变成了几十个工程师坐在会议室里谈心。既然上云是一种策略，为什么不顺势而为呢？就这样，一群OracleDBA开始亲手拆解他们落脚的系统。2013年7月，淘宝最后一个Oracle数据库下线。如今，整个阿里集团的核心业务100%运行在公有云上。是的，既然上云势不可挡，我们何不顺势而为，看看运维上云是什么样子呢？首先，云运维的运营目标不同于传统运维。传统运维人员需要能够手动操作众多厂商的计算、网络、存储等硬件设备，而云端的运维人员根本无法接触到物理设备，取而代之的是云上的虚拟资源云，如云服务器、云盘、虚拟交换机等。云厂商将所有资源操作抽象成软件定义的API接口，用统一的SDK和命令行打包，提供给运维人员。云厂商提供的图形化运维控制台无非是API的封装。二是云上运维高度简化。传统的运维，需要去很多“大公司”学习认证。比如网络运维需要学习Cisco认证，数据库运维需要学习Oracle认证，系统运维需要学习IBM认证等等。在云端，虚拟专网产品统一简化网络设备的管理和运维，云数据库产品实现数据库智能化管理，云服务器实现动态扩容和热迁移。两者都大大降低了运维操作的门槛。云端的运维人员不再需要感知底层基础设施的细节，更不用说获得高难度的认证了。即使是初创阶段的小企业，也可以拥有与大企业同等的运维能力。但运维的简化并不意味着运维的重要性降低。相反，在云上，运维变得比以前更重要了。云时代运维的挑战为什么运维在云时代变得更加重要？主要有两个原因。一是云运维的范围比以前扩大了，二是云公司对稳定性的要求更高了。从范围上讲，云运维包括从蓝图规划，到云交付，再到云管理的全过程。如果具体到流程和阶段，包括设计选型、资源交付、系统交付、运维调优、扩缩容、资源运营、备份容灾、安全审计等。从稳定性上看，云厂商通常只负责基础设施的稳定性，上层应用仍由企业开发者自主开发。同时，云应用本身的稳定性也是企业自身运维人员的责任。具体来说，企业运维人员需要负责在持续发布过程中实现蓝绿发布、灰度发布、批量发布、自动回滚等，以及应用层的监控和构建事件报警系统。此外，云上基础设施的稳定性不能仅仅依靠云厂商，还需要企业运维人员的配合。例如，阿里云的云服务器单实例可用性达到99.975%，但10000次中仍有2.5次不可用。企业云运维人员可以采用监控、负载均衡、多机热备、两地三中心等常见的高可用设计，在并非100%可靠的基础设施上构建100%可靠的应用.具体来说，云上运维主要面临以下挑战：一是运维排障难度加大。由于云端“黑匣子”的存在，当突然出现故障时，运维人员只能看到服务异常，难以快速判断问题出在哪里。是云服务商的基础设施有问题，还是我自己的代码有bug？......即使查明是云服务商的某项服务的问题，一些运维人员也只能打电话求助客服，得到的客服回复是往往不尽如人意，从而延误了故障恢复时间。其次，难以有效处理云服务发送的消息、日志和事件。如果运维人员每天收到几千条短信或邮件，肯定无法及时处理，只能想也不想就忽略。但是你不能设置邮件规则把它们都扔进垃圾桶，因为你会担心错过重要的通知，比如服务器宕机通知。第三，资源的扩张带来了管理的复杂性。所有资源都是软件概念。对于大型企业来说，这些资源可能分布在全球十几个地区，分散在几十种云产品的控制台中，服务于数百种不同的负载或在线服务。更可怕的是，这些资源还在不断变化。如何有效跟踪、审核、创建、发布并确保无浪费？第四，云产品的频繁升级带来运维的频繁被动变更。云产品选择多，实例类型复杂，包括预付费、后付费、预留实例券、性能爆发型、计算型、通用型、GPU实例、专用主机、裸金属实例、容器服务、Kubernetes或者Swarm，弹性容器实例等等，更要命的是，这些云产品还在不断的发布升级。如何选择适合自己的产品？新功能如何帮助业务？...盲目跟随云供应商的脚步并不是一个好主意。2、如何调整适应云时代的运维？SRE可能就是答案。前面说了，企业上云之后，还有很多运维需求。但是此时的运维和传统的运维是完全不同的。企业上云后应如何进行结构调整以适应新形势？DevOps是现在提到的一个非常流行的概念。DevOps实践的整个生命周期是从规划-》编码-》构建-》测试-》发布-》部署-》运行-》监控，再回到规划，这是一个循环。其中，发布，部署，运维和监控（下图中黄色部分）属于运维领域，DevOps实践打破了开发和运维之间的壁垒，开发人员可以直接负责运维。与软件开发相结合，强调高度自动化，沉淀一系列运维工具和运维平台，并不断向AIOps和NoOps方向演进。反之，如果运维人员能够掌握开发技能，结合自动化工具的使用，是否可以做得更好？答案是肯定的。运维人员可以向站点稳定转型升级。y兼具开发能力和运维能力的工程师（SRE）。Google首先引入了SRE的概念，将SRE部门定为研发部门，承担运维职责。越来越多上云后的企业开始将运维部门转型升级为SRE部门。SRE听上去很美，但真正做到并不容易。以阿里云为例。早年间，阿里云也经历过人肉运维的痛苦阶段。尽管运维工程师7*24轮班随叫随到，但客户投诉不断，系统问题不断。后来，阿里云团队开始做稳定性，通过监控告警，将平均发现故障的时间从1小时缩短到10秒。同时，借助AI预测算法，在某些情况下，可以在故障发生前进行预警和行动。.现在阿里云每年都会发布上千个变更，难免会有变更导致的失败和异常。而SRE团队的蓝绿发布、灰度发布、批量发布、自动回滚、热迁移等技术实现了整个发布过程的无缝发布。值班的人。如何升级成为SRE？这三点建议或许对你有帮助：第一，学习DevOps的实践，掌握至少一种编程技能（如Python、Go、Java等），在思维和技术上保持工程师的先进性；学习云厂商提供的各种自动化运维工具，并灵活运用，力图帮助贵公司搭建高效的自动化运维平台；三是积极参与开源和云厂商生态建设，与运维生态共同成长。生产运维平台层面的解决方案产品，广泛应用于全行业，让个人价值和商业价值得到体现。3、一切自动化是云时代运维的首要任务。实现云上运维的平滑升级，首要任务是“一切自动化”。编码。监控自动化首先看监控，包括“监控”和“控制”两个方面。监控的“监控”与“监控”，从横向划分，包括事件（Event）、日志（Log）、指标（Metric）、告警（Alarm）四个维度；从纵向划分，分为底层基础设施的“监控”和上层应用的“监管者”。横向划分：事件、日志、指标和告警什么是事件？对于云服务商来说，一个事件其实就是一次资源变化，每一次资源变化都是一个事件，比如云服务器的每一次状态变化都是一个事件，包括启动（starting）、运行（running）、关闭（stopping）、停止（stopped）什么是日志日志是客户行为和云服务内部行为的过程记录，包括时间、操作者、内容、级别等元素，每个事件都可以转化为对应的日志记录在日志服务中。因此，日志的范围大于事件，日志服务提供的不仅仅是日志记录，更重要的是日志聚合和检索能力，比如运维人员可以查看历史记录过去某段时间某资源的绳索。什么是指标？指标是资源运行时的内部属性数据。最典型的指标就是Linux中top命令显示的数据，包括CPU、内存、IO数据等，这些数据不是事件，也没有必要记录成日志，但是实时性还是很重要的数据，是运维人员需要关心的系统健康指标数据。如果一切都健康，则可以忽略。什么是警报？报警可视为严重事件，需要立即进行手动或自动操作。运维人员可以根据指标设置阈值触发告警，也可以根据事件和日志设置告警规则触发告警。纵向：底层基础设施和上层应用底层基础设施的“监控”需要云服务商提供基础数据。云厂商的监控往往会为基础设施提供事件、日志、指标和告警。非常方便的配置和接入。对于上层应用的“监控”，有很多产品可以选择。例如阿里云的应用实时监控服务ARMS，为上层应用层提供事件、日志、指标、告警等。用户也可以选择开源的prometheus或者zabbix自己搭建。基础设施和上层应用的界限不是绝对的。其实我们需要的是自下而上的全程监控。监控中的“控制”和“监控”的目的在于“控制”。这里的控制特指事件和告警的处理。通过短信、电话、邮件等方式通知联系人是最简单、最直接的处理方式，但这种方式显然容易被忽视，延迟非常大。因此，SRE应该实现自动化的事件处理。运维操作如何编码实现事件自动化处理？程序员自然会想到写一个EventConsumer程序，从云端监控拉取事件，然后调用资源API进行处理。这种方法看起来很简单，但是实现起来真的那么容易吗？首先，可靠性对于运维自动化平台来说非常重要。如果EventConsumer只有一个单点，一旦发生故障，系统事件将不再处理。这时候有经验的程序员可能会说：“我可以引入消息队列服务，然后使用多进程的EventConsumer进行分布式消费，避免单点故障。”当然，这是一个解决方案，但是仍然会有一个问题，没有一个既不会重发又不会遗漏消息的分布式消息服务。我们只能选择不遗漏消息，接受可重复的消息。但是，重复的消息可能会导致重复操作，运维人员无法接受。那么，如何摆脱它呢？我们只能引入分布式KV数据库，比如Redis，作为基于EventID和Redis原子操作（比如incr）的消息去重的工具。另外，事件的处理只是调用API吗？不一定，你可能需要对多个资源进行多次API调用，这些调用之间存在依赖关系，有的甚至要序列化。为了保证多个操作的事务性，即要么全部成功，要么全部失败（需要回滚操作），这时候就需要分布式工作流引擎。什么？还需要定时任务吗？那么，只能引入一个分布式的定时任务框架。……这样看，是不是越来越复杂了？实现一个高可靠的分布式架构运维平台显然不是一件容易的事情。更何况运维开发不同于普通的软件开发。快速开发是第一要务，因为运维开发的需求变化更频繁，开发周期更短，人力更紧张。没有平台的支持，单靠运维人员从无到有搭建自动化运维系统，并保证高效、稳定、持续运行是非常困难和昂贵的。为了保证生产系统的稳定性，创建了运维系统。那么，谁来保证这个运维系统的稳定性呢？这是一个悖论。如何轻松实现“运维操作码”？两个建议，一是选择简洁的运维语言，可以快速开发，二是选择可靠的事件驱动运维平台，而不是重新发明轮子。在运维语言方面，脚本语言已经成为主流，比如YAML、JSON等，遇到复杂的逻辑可以使用Python、Shell、C、C++等语言，很容易供运维人员使用。有点重。对于开源运维平台，我们可以选择Ansible、Puppet、SaltStack等。以Ansible为例，其核心卖点之一就是“Agentless”。安装Ansible后，运维人员可以直接基于SSH编写YAML格式的Playbook来管理Linux集群。此外，各个主流云厂商也为Ansible编写了插件，运维人员可以使用Ansible来管理云端的运维动作。值得注意的是，云服务商也提供原生的运维平台，例如阿里云提供的OperationOrchestrationService（OOS）、AWS提供的SystemManagerAutomation服务或AzureAutomation服务。基础设施编码云基础设施包括云服务器、云存储、DNS、CDN等，但传统的云基础设施管理总是面临各种困难，如咨询和审批流程长、响应不及时、手动安装和配置速度相对较慢、难度大为了避免这些问题，我们提出“基础设施编码”，即通过代码管理基础设施，维护和管理其全生命周期，包括审计需求。代码成为审计的良好记录，代码变更也可以溯源到人和项目组，解决了变更、可追溯、变更历史等问题。基础设施编码后会给我们带来哪些实际好处？举个例子，假设一个经典的三层在线服务搭建在阿里云上：前面是SLB负载均衡，中间是若干台ECS作为一个服务集群，后面是一组RDS数据库。同时，我们为三层分别创建了一个VPC，通过安全组来设置安全规则。刚开始业务可能只需要2台ECS，但很快就会扩展到3台、4台，这个时候我们该怎么办呢？更直接的方式是在阿里云控制台上操作，今天创建一个，明天再创建一个。但这种方法显然很笨拙。我们可以使用“基础代码”方法吗？当然。我们在文本文件中定义资源，做配置项，保存在云端。比如有一个配置项叫ServersAmount，代表服务器的数量。我们把这个配置项从3改成5，ECS数量从3自动增加到5。再把ServersAmount从3改成2，其中一个ECS会自动释放。代码或配置具有更改历史记录。代码也可以清楚地审查。代码也可以轻松复制。如何实现“基础设施编码”？最重要的是需要一个平台。如果你选择从头开发，你就不再是在造轮子，而是在造船。那么什么样的平台值得选择呢？开源的Terraform是一个不错的选择。拥有各大主流云厂商的官方支持，用户可以直接使用。而Terraform需要运维人员自己准备服务器进行配置安装，自己维护平台。此外，云厂商还提供开箱即用的云服务，例如阿里云提供的资源编排服务（ROS）。4.云时代运维的未来发展如前所述，云时代的运维工作正在从人工操作向代码开发过渡，但是这些用于运维的代码形式多种多样。它们可以是配置文件或者是YAML或者JSON模板，也可以是Javascript/Python/Go等传统代码。那么，未来运维在云时代将如何发展？在我看来，云时代运维的发展很大程度上取决于云应用和基础设施的变化。我们可以大胆分析预测，未来云时代的运维会是这样的：目前主流的云应用架构是自建API网关+微服务+分布式RPC+消息队列等，需要的云基础通过该架构，设施有负载均衡+云服务器+虚拟专用网+云关系数据库等，其运维方式如上所述。未来几年相对确定的趋势是，云应用开发将越来越多地使用Reactive（反应式）编程，完全异步，事件驱动，相应的基础设施将被容器化以隐藏服务器层。这预示着越来越多的运维工作将围绕容器编排展开，比如Kubernetes。中长期来看，函数计算的Serverless开发模式将会流行起来，相应的基础设施也会精简到连容器都看不到的程度。用户不再为基础设施付费，而是为实际的计算量付费。云服务提供商将通过机器学习等手段确保函数计算所需的基础设施具有高可靠性和高灵活性。届时，运维人员将不再需要关心资源的安排，但仍需要对职能内业务的监控和运维动作的自动化。在更长远的未来，云计算、边缘计算、本地计算可能统一在一起，不再区分“在线”和“离线”，取而代之的是一种无处不在但潜移默化的计算力量。具体来说，应用开发者编写代码并保存后，业务更新就完成了。“基础设施”和“资源”这两个概念将彻底消失，只剩下数据本身，包括静态数据（代码+配置）和动态运行时数据。而运维不会消失，而是从面向资源的运维向面向数据的运维转变。
