zoukankan      html  css  js  c++  java
  • 巧用云原生能力和工具,提升云上运维效率

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

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

    举个例子 …

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

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

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

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

    举个例子 …

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

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

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

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

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

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

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

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

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

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

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

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

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

    1. 总是推荐最高性价比的实例规格; 

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

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

    排障助手,快速诊断和修复

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

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

    最底层的云服务器服务状态:包括底层物理硬件设备、虚拟化服务是否存在异常。

    网络服务状态:包括底层网络设备、网卡驱动加载、网络连通性等是否存在异常。

    磁盘服务状态:即实例的云盘和本地磁盘,包括磁盘是否存在损坏、IO 读写是否异常或受限等。

    其他配套资源的服务状态:包括关联的安全组端口设置、实例所有组件的费用情况等。

    云服务器内部操作系统的状态:包括类似 ssh 进程所需文件、/etc/fstab 配置、管理员账号和密码是否缺少,防火墙状态、关键系统文件权限设置等。

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

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

     

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

    ECS 优化助手:资源报表与优化

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

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

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

     

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

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

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

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

    总结与展望

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

    作者介绍

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

  • 相关阅读:
    Ftp、Ftps与Sftp之间的区别
    Previous Workflow Versions in Nintex Workflow
    Span<T>
    .NET Core 2.0及.NET Standard 2.0 Description
    Announcing Windows Template Studio in UWP
    安装.Net Standard 2.0, Impressive
    SQL 给视图赋权限
    Visual Studio for Mac中的ASP.NET Core
    How the Microsoft Bot Framework Changed Where My Friends and I Eat: Part 1
    用于Azure功能的Visual Studio 2017工具
  • 原文地址:https://www.cnblogs.com/tanxingjisuan/p/14519526.html
Copyright © 2011-2022 走看看