巧用云原生能力和工具,提升云上运维效率

简介: 云上运维如何做到效率至上?本文告诉你答案!

虽然各大行业和企业都在畅谈拥抱云计算,或正在践行通过云计算完成业务的数字化转型,但在真正落地过程中,摆在开发者或运维人员面前的问题显得更直接和残酷。从上云 POC 测试、业务迁移、应用部署、日常运维、到后续的持续性优化,每个阶段都面临着不同的挑战。

与传统运维不同,云上运维人员完全接触不到物理设备,感知不到底层基础设施的细节,取而代之的是云服务器、云盘、VPC 网络等已经封装好的产品形态。上云已是趋势,但如何基于云上的产品形态和云原生的能力做好自动化运维却变得更具有挑战

举个例子 …
云服务器的选型标准化了却也复杂了,云服务器相关问题排查因底层资源的不透明导致难度变大了,按需使用的付费模式也推动资源是否合理使用的诉求变得更强烈…..云上如何更高效地运维也就成为了运维人员共同面临的难题。

云上运维如何做到效率至上?

《Google SRE 运维解密》一书中提到,SRE 人员需要把更多时间花费在项目研发上,而不是日常运维中,而做到这一点的关键就是减少琐事。琐事即运维服务中手动性的、重复性的、可以被自动化的、战术性、没有持久价值的工作。而他们提倡的解决琐事的方式就是自动化。

《一文读懂云上 DevOps 能力体系》中提到了云上运维的演进路径,其背后的主要推动力就是效率。从纯手工的运维模式到半自动半手工,其实就是把重复的人工操作变成自动化,再进一步就是智能化。不过,效率的提升一方面是自动化能力的提升,另一方面也要依赖于云服务平台服务模式的改变。

举个例子 …
最早我们去银行办业务,无论是最简单的查询余额或取钱存钱,还是复杂的办卡、理财业务等,都需要到柜台排队办理,而银行的营业时间与我们的工作时间一致,体验非常的不好。

后来,ATM 机出现了,我们找到 ATM 就可以办理最常见的查询、小额取钱存钱/转账业务,不用在上班期间跑银行柜台排队办理了;现在,随着银行自助服务机升级和手机 App 的普及,我们更愿意选择通过手机银行来自助办理业务,而银行的人工柜台服务逐渐变成了一个解决复杂业务的边缘路径。

当然,这些体验提升的背后,一方面是技术的更新迭代,另一方面也是服务提供商服务模式的改变,银行把常见的业务通过提供工具交给我们自助办理业务,提升使用体验的同时、还能释放了人工服务资源。

云上的服务也是类似的场景。云服务商基本都通过工单系统来解决运维人员的问题。运维人员提交工单就和去银行柜台办理业务是一样的,工单也是要在后台等待排队处理的,但如果一些常见问题能通过某种手段或工具来解决,工具解决不了再找人工服务,体验就会好很多。

所以,效率至上不仅意味着自动化的能力,也意味着云服务商的服务模式转变——为以用户为中心的自助服务为主,提供工具帮助用户自助解决问题。当前,AWS、阿里云等服务商在用户自助服务工具方面都有投入,提供了一系列的自助服务工具,使得运维人员在一定程度上提升云上运维的效率。

巧用自助服务工具,实现云上高效运维

当前,运维人员在云上运维常见问题主要有云服务器选型、云服务器排障和云服务器的持续优化三个方面,笔者就这三个方面介绍几个云上自助服务工具,希望对运维人员快速解决常见的高频问题有所参考和帮助,缩短问题时间、提升云上运维效率。

场景化选型工具,解决实例选型难题

虽然头部云厂商支持的实例规格族命名方式各异,但基本还是跟随 AWS 命名的模式,即根据 CPU 是否独占、CPU 内存的配比、是否包含本地磁盘、本地磁盘类型及性能以及其他额外能力等对实例规格族进行命名分类。然而,即使是面对主要参数相同的实例规格族,由于不同云服务商底层所使用的物理机型号、技术架构和技术能力的不同,生产出来的实例性能指标也不尽相同。

笔者所在的阿里云,目前推出的实例规格数量已多达几百种,并随着物理硬件和系统架构的不断升级,每年还会推出十几款、甚至几十款新的实例规格。新涌现的实例规格会不断缩小之前实例规格族的差异。所以,在不同云平台购买云服务器实例时,如何从上百种实例规格中选择与业务匹配度最高,且性价比最高的实例规格,对大多数运维人员而言都是一个难题。

实际上,虽然企业的业务形态千差万别,但业务底层的架构不外乎以下几大类,包括前端 Web 应用、缓存、数据库应用、大数据集群,有些可能还会涉及到 AI 机器学习或者超算集群等。所以,从开发运维人们面临的是场景化的选择—“我要为 XX 业务或应用购买计算资源”,通用机型已不能够满足他们的需求了。在这个大前提下,场景化选型工具无疑能大大提升研发运维人员的选项效率

以阿里云为例,阿里云云服务器 ECS 基于十多年平台用户的运营经验将平台上几十、上百种实例规格的选择按照业务场景简化为 2-3 种实例规格,覆盖了十多种主流业务场景,包括前端服务、中间件、分布式缓存、重载数据库、ElasticSearch、人工智能训练、计算节点、图片转码和高性能计算等场景,并给出了各业务场景下实例推荐的理由,运维人员可以根据自己的业务场景来进行选择,再也不用迷失在实例海洋里苦苦比较。

图01.jpg

从阿里云给出的推荐理由可以看出,每个业务场景主要遵从两个策略:

  1. 总是推荐最高性价比的实例规格;
  2. 默认搭配与业务更匹配的块存储,即针对不同的实例规格和业务场景,推荐的块存储类型也不尽相同。

从这两个策略看,总体来说运维人员可以从中获得整体最高性价比的推荐。

排障助手,快速诊断和修复
大多数情况下,当一个运维人员遇到云服务器使用问题时,通常是通过工单系统提交工单、等待人工客服来解决问题。但使用过工单系统的运维人员应该都深有体会,一般性问题的响应周期一般为 1~24 小时,而解决周期则有很大概率取决于客服人员的能力,如果问题稍微复杂,该工单会被上升至研发侧进行分析,这样问题的解决周期至少为 2 个小时。下图列举了云服务器使用过程中遇到 80% 的常见问题。

图02.jpg

实际上,云服务器是 CPU 内存、云盘、网卡、VPC 等组件构成的,所以开发运维人员遇的问题归根结底可以拆解为以下 5 个方面:

  • 最底层的云服务器服务状态:包括底层物理硬件设备、虚拟化服务是否存在异常。
  • 网络服务状态:包括底层网络设备、网卡驱动加载、网络连通性等是否存在异常。
  • 磁盘服务状态:即实例的云盘和本地磁盘,包括磁盘是否存在损坏、IO 读写是否异常或受限等。
  • 其他配套资源的服务状态:包括关联的安全组端口设置、实例所有组件的费用情况等。
  • 云服务器内部操作系统的状态:包括类似 ssh 进程所需文件、/etc/fstab 配置、管理员账号和密码是否缺少,防火墙状态、关键系统文件权限设置等。

目前,部分头部的云服务商已经就这些问题封装了自助诊断和修复工具,所以建议运维人员可以先使用云平台的自助诊断和修复工具来解决问题,因为常见的问题基本都可以自助解决。

以阿里云提供的自助诊断和修复工具来看,因为是基于平台百万 ECS 相关问题的工单进行分析、归纳并总结的,覆盖了运维人员使用云服务器过程中 80% 的问题了,包括无法远程连接、无法启动或无法停止、服务/网络不通、CPU/带宽跑满货跑高和性能不符合预期等问题。

图03.jpg

所以,通过诊断工具进行诊断,如果发现问题,运维人员可以根据诊断工具提供的修复方案进行操作、一般几分钟就能解决问题,大大提升问题解决效率,缩短业务影响时间。

ECS 优化助手:资源报表与优化
上云初期阶段,企业需要对云的能力和稳定性做一些前期测试和验证,一般较少会把全部业务流量切至云上,这是非常合理的风险规避措施。随着云上业务逐渐稳定,企业会逐步将业务全部切换至云上,并随着业务的发展,云上业务量的占比会越来越重,直到 100% 全面上云。但完全上云后就意味着结束么?当然不是。如何持续做好云上的运维和治理,才是重中之重。

云上持续运维和管理的核心在于:业务架构和资源配置必须跟上业务发展的节奏,不能让底层资源成为业务发展的瓶颈。业务架构层面的事情,涉及到业务改造成本和周期,笔者暂不展开阐述,不过评估资源是否成为业务风险点或瓶颈,则是业务和运维层面能快速识别并解决的问题。

对于资源层面的风险,可以对资源的历史数据和报表进行分析来识别,但这些资源报表数据也要依赖云平台来提供。笔者知道的,阿里云提供了 ECS 资源报表与优化服务,可以对云服务器 ECS、云盘 EBS、网络带宽等在内的 IaaS 层资源数据进行实时或 T+1 历史数据的分析,从资源使用率、安全性和资源容量变化三个维度帮助运维人员识别资源的潜在风险。

04.jpg

资源使用率:从六个维度对 ECS 过去 14 天的历史使用数据进行分析,包括 CPU 使用率、CPU 增长率、内存使用率、内存增长率、磁盘 IOPS 增长率、网络带宽吞吐增长率,从而区分出高中低三种不同的资源使用率。

安全性:对实例和安全组进行安全扫描,快速识别存在高危安全漏洞的实例,或绑定了过多资源的高危安全组,提醒运维人员及时进行修复,避免业务受到潜在风险影响;

资源容量变化:对实例的新建、释放和保有量进行跟踪记录,不仅能方便对账和审计,还能洞察异常的资源变动,比如因账号的 AK/SK 泄露导致资损。

利用资源报表与优化服务,运维人员可以获得 IaaS 层资源不同维度的数据,以及云平台提供的专业和及时的修复建议,以此作为优化参考,可以更好地保障业务平稳地运行。

总结与展望

为了实现云上高效运维,笔者看到运维人员和云服务平台都在不断演化,云平台在不断改变服务模式,从工单系统到自服务模式;运维人员也开始借助云平台提供的一系列工具来高效运维,本文提到的自助服务只是其中一环,还有更多的自动化工具,比如资源编排、运维编排等门槛较高的工具,这些都是效率驱动下出现的。人类与动物的区别在于会制作和使用工具,建议运维人员合理利用云上云原生能力和工具,云上运维工作就可以做到事半功倍。

作者介绍
马小婷,阿里云智能产品专家,专注于打造 ECS 为中心的服务管理能力产品规划与设计工作,包括弹性伸缩、运维编排,ECS 生命周期管理套件等,致力于完善 ECS 全生命周期的场景支撑,为用户提供完整高效的服务能力与自助智能的服务体验。曾先后服务于滴滴云、VMware,拥有 8 年以上云行业相关经验。

相关文章
|
1月前
|
运维 Linux Apache
Puppet 作为一款强大的自动化运维工具,被广泛应用于配置管理领域。通过定义资源的状态和关系,Puppet 能够确保系统始终处于期望的配置状态。
Puppet 作为一款强大的自动化运维工具,被广泛应用于配置管理领域。通过定义资源的状态和关系,Puppet 能够确保系统始终处于期望的配置状态。
56 3
|
1月前
|
运维 Linux Apache
Puppet这一强大的自动化运维工具,涵盖其基本概念、安装配置及使用示例
【10月更文挑战第8天】本文介绍了Puppet这一强大的自动化运维工具,涵盖其基本概念、安装配置及使用示例。Puppet通过定义资源状态和关系,确保系统配置始终如一,支持高效管理基础设施。文章详细讲解了Puppet的安装步骤、配置方法及DSL语言示例,帮助读者快速掌握Puppet的使用技巧。
65 2
|
11天前
|
运维 Ubuntu 应用服务中间件
自动化运维工具Ansible的实战应用
【10月更文挑战第36天】在现代IT基础设施管理中,自动化运维已成为提升效率、减少人为错误的关键手段。本文通过介绍Ansible这一流行的自动化工具,旨在揭示其在简化日常运维任务中的实际应用价值。文章将围绕Ansible的核心概念、安装配置以及具体使用案例展开,帮助读者构建起自动化运维的初步认识,并激发对更深入内容的学习兴趣。
33 4
|
13天前
|
运维 监控 数据安全/隐私保护
自动化运维工具的设计与实现
【10月更文挑战第34天】在现代IT基础设施管理中,自动化运维工具扮演着至关重要的角色。它们不仅提高了运维效率,还确保了服务的连续性和稳定性。本文将深入探讨如何设计并实现一个自动化运维工具,从需求分析到功能实现,再到最终的测试与部署。我们将通过一个简单的代码示例来展示如何自动执行常见的运维任务,如日志清理和性能监控。文章旨在为读者提供一套完整的方法论,以便他们能够构建自己的自动化运维解决方案。
|
1月前
|
运维 关系型数据库 MySQL
自动化运维工具Ansible的实战应用
【10月更文挑战第9天】在现代IT运维领域,效率和可靠性是衡量一个系统是否健康的重要指标。自动化运维工具Ansible因其简洁、易用的特性,成为了众多企业和开发者的首选。本文将通过实际案例,展示如何利用Ansible进行日常的运维任务,包括配置管理、软件部署以及批量操作等,帮助读者深入理解Ansible的应用场景及其带来的效益。
|
1月前
|
人工智能 运维 监控
自动化运维:从脚本到工具的演变之路
【10月更文挑战第8天】在数字化时代的浪潮中,运维不再是简单的硬件维护,它已经演变成一场关于效率、稳定性和创新的技术革命。本文将带您领略自动化运维的魅力,从最初的脚本编写到现代复杂的自动化工具,我们将一探究竟,看看这些工具如何帮助运维人员简化日常任务,提升工作效率,并最终推动业务发展。
|
1月前
|
Kubernetes 安全 Cloud Native
云上攻防-云原生篇&K8s安全-Kubelet未授权访问、API Server未授权访问
本文介绍了云原生环境下Kubernetes集群的安全问题及攻击方法。首先概述了云环境下的新型攻击路径,如通过虚拟机攻击云管理平台、容器逃逸控制宿主机等。接着详细解释了Kubernetes集群架构,并列举了常见组件的默认端口及其安全隐患。文章通过具体案例演示了API Server 8080和6443端口未授权访问的攻击过程,以及Kubelet 10250端口未授权访问的利用方法,展示了如何通过这些漏洞实现权限提升和横向渗透。
154 0
云上攻防-云原生篇&K8s安全-Kubelet未授权访问、API Server未授权访问
|
1月前
|
安全 Cloud Native Shell
云上攻防:云原生篇&Docker容器逃逸
本文介绍了Docker的基本概念及其对渗透测试的影响,重点讲解了容器逃逸的方法。Docker是一种轻量级的容器技术,与虚拟机相比,具有更高的便携性和资源利用率。然而,这也带来了安全风险,特别是容器逃逸问题。文章详细描述了三种常见的容器逃逸方法:不安全的配置、相关程序漏洞和内核漏洞,并提供了具体的检测和利用方法。此外,还介绍了几种特定的漏洞(如CVE-2019-5736和CVE-2020-15257)及其复现步骤,帮助读者更好地理解和应对这些安全威胁。
云上攻防:云原生篇&Docker容器逃逸
|
8天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
10天前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
下一篇
无影云桌面