服务韧性工程(SRE)论坛演讲实录 | 东信软件:基于 SRE 的智能运维建设
2023 年 12 月 15 日,2023 首届服务韧性工程(SRE)论坛在杭州成功举行,大会邀请了来自通信、金融、医疗、制造行业等 100 余位 SRE 领域专业人士参加,本次大会特别设立了主题为“SRE 的实践和应用”的分会场,分会场由中国移动通信集团浙江有限公司和 SRE 专委会联合出品。邀请来自通信、云计算、互联网、软件等行业的专家,就 SRE 实践与应用、智能运维建设、可观测性等热点内容的技术发展及应用实践展开讨论。东信软件 SRE 服务部架构师史高武带来《基于 SRE 的智能运维建设实践》的主题演讲。
东信软件 SRE 服务部架构师史高武,进行《基于 SRE 的智能运维建设实践》的演讲,史高武强调了 SRE 在运维领域的重要性,尤其是在面对大规模系统和复杂架构时。他分享了东信软件在 SRE 实践中的具体举措,通过建设统一、可观测的智能运维平台,CMDB 的强化,构建基于 SRE 的统一监控体系,实现集中告警监控。东信软件致力于提升服务软件质量感知,通过建设重要网管系统,实现多维监控和自动化运维。他还强调了数智一体化服务和搭建自动运维类机器人连队等创新做法,为大家提供了富有前瞻性的 SRE 实践经验。
以下为演讲实录:
一、基于 SRE 的智能运维建设思想
当前运营商的运维是面临着巨大的挑战的,电信行业云原生要求应用及系统设计开发初期就需要采用云的思维、云的架构、云的技术,将云的弹性伸缩、快速迭代、敏捷运维的原生特性带入到网络中,增加网络云化的灵活性和适应性,提高资源利用率,缩短部署周期,提升迭代开发效率。电信行业云原生可以基于微服务架构进行应用设计与开发,使用容器进行应用承载与编排,采用 DevOps 打造开发运维一体化管理体系。在这样的要求和建议下,云原生加速演进,使得我们的系统从传统的静态分布式架构向动态复杂的架构演变,从而系统的复杂性,易变性,未知性及模糊性都成倍增加!
面对云原生快速演讲所带来挑战,我们又该如何面对呢。
传统很多公司开发部和运维部是分属两个不同部门的,这种 Dev/Ops 分离的团队模型,无法避免的带来两类成本问题:
直接成本:随着系统复杂度的增加,部署规模的扩大,团队的大小基本与系统负载成线性关系,共同增长。
间接成本:研发团队和运维团队背景各异,技术能力和工具使用习惯上差距巨大,工作目标存在不可调和分歧点,而这些会严重影响产品的迭代。
但 SRE 团队的作为解决上分歧点被提出来,在快速迭代与系统稳定性直接做了平衡。SRE,即网站可靠性工程,是一种将软件开发与运维相结合的方法论。它强调的是在产品设计和开发过程中,从始至终都充分考虑系统的可靠性、稳定性及可维护性。通俗来讲采用软件工程方法论,用研发的方式来运维。SRE 团队的出现也大大节省了公司的开支。公司作为盈利性组织,任何能够节省公司开支的举措都会被大力支持的,这才是核心动力。
Google 建议琐事所占的比例不应超过 50%,这是一个非常重要的原则。在日常工作中,东信软件 SRE 团队非常注重平衡琐事的比重,以确保团队成员有足够的时间进行充电和学习。随着云原生技术的不断发展,新知识和新思想不断涌现,团队需要花费更多的时间和精力来学习。只有通过不断学习,团队才能更好地应对挑战,利用软件开发思维提高维护工作的效率,并促进团队的良性发展。这种持续学习的态度不仅有助于个人成长,也有助于整个团队的进步。
东信软件 SRE 团队每个角色都有其独特的技能要求和团队职责,以确保项目的整体质量和效率。
1. 项目经理:项目经理是团队的领导者,负责整个项目的需求设计,项目管控,客户沟通和资源协调。他们需要具备具备 PMP 资质,会使用项目管理工具;具备一定的 IT 和 CT 运维能力,确保项目按质完成。
2. 架构设计师:架构设计师负责设计合理的架构和分解计划,牵头带领项目开发实施人员进行具体方案落地和项目实施。需要具备丰富的架构设计和项目实施能力,具有一定的业务理解能力,具备资深的 IT 和 CT 运维能力,对云原生技术有深刻理解能够根据项目需求制定合理的技术方案和架构设计。
3. 开发实施工程师:开发实施工程师是具体的编码人员,负责按照设计文档和需求进行项目实施,负载项目落地和持续维护。他们需要熟练掌握熟悉 Linux,至少一门语言(python/go/groovy),数据库,软件方法论,编程思维,具备基础的 CT 知识,熟悉云原生技术,能够独立完成开发任务。
4. 测试人员:测试人员负责测试及相关文档交付,辅助项目实施落地,具备了解 Linux,了解编程基本思想,熟悉自动化接口测试方法,具备编写测试用例的能力。
以上是东信软件 SRE 团队的基本分工,每个角色都有其独特的职责和技能要求。在实际工作中,这些角色之间需要密切协作,共同完成 SRE 项目的开发和交付。
东信软件的 SRE 实践是一个全面而细致的过程,它涵盖了学习提升、研运一体化实践、智能运维实践和自动化测试四个关键方面。这四个方面紧密相连,形成了一个有机的整体,使运维和研发部门能够更好地协同工作,消除两者之间的隔阂,形成一个相互支持、相互赋能的平行组织。
首先,学习提升是整个 SRE 实践的基础。在这个阶段,团队成员需要不断提升自己的技能和知识,以适应快速变化的技术环境和业务需求。通过定期的培训、分享和交流,团队成员可以不断拓展自己的知识视野,提升个人的技能水平。
其次,研运一体化实践是 SRE 实践的核心。它强调研发和运维的紧密合作,打破两者之间的壁垒,实现无缝对接。通过一体化实践,研发和运维团队能够更好地理解彼此的工作内容和需求,共同制定出更合理、更高效的解决方案。
再次,智能运维实践是 SRE 实践的重要环节。随着技术的发展,智能运维已经成为提升运维效率和质量的重要手段。通过引入人工智能、大数据等技术,实现对运维数据的实时监测、分析和预警,提高运维的自动化水平和智能化程度。
最后,自动化测试是 SRE 实践的关键环节。通过自动化测试,可以大幅提高测试的效率和准确性,减少人工干预和错误率。同时,自动化测试还可以帮助团队更快地发现问题和缺陷,及时修复和优化软件产品。
总之,东信软件的 SRE 实践是一个系统性的工程,它通过四个方面的协同作用,实现了运维与研发部门之间的深度融合与相互赋能。这不仅可以提高软件产品的质量和稳定性,还可以提升团队的整体效能和竞争力。
SRE 通过关注四大黄金信号:延迟、流量、错误率和饱和度,为提升系统稳定性提供了有力的支持。这四个信号是评估和优化系统性能的关键指标,可以帮助我们及时发现和解决潜在的问题,从而提高系统的可靠性和稳定性。
首先,延迟是评估系统性能的重要指标之一。通过监测和分析延迟数据,我们可以了解系统的响应速度和效率,发现潜在的性能瓶颈,并采取相应的优化措施。SRE 团队通常会使用各种工具和技术来测量和降低延迟,例如负载均衡、缓存优化和网络调优等。
其次,流量是评估系统可伸缩性的关键因素。随着用户和业务的增长,系统需要能够承受不断增长的流量压力。SRE 团队会通过流量控制、流量调度和流量削峰填谷等技术手段,确保系统在高流量的情况下仍能保持稳定性和可靠性。
错误率是评估系统稳定性的重要指标之一。通过监测和分析错误数据,我们可以发现系统中的问题、漏洞和异常情况,并及时进行修复和优化。SRE 团队通常会使用各种错误检测、错误跟踪和错误恢复等技术手段,确保系统在出现错误时仍能提供高质量的服务。
最后,饱和度是评估系统资源使用情况的关键指标之一。通过监测和分析饱和度数据,我们可以了解系统的资源利用情况和瓶颈,及时进行扩容或优化。SRE 团队通常会使用各种资源管理和资源调度等技术手段,确保系统在高负载情况下仍能保持稳定性和可靠性。
总之,SRE 通过关注延迟、流量、错误率和饱和度这四大黄金信号,为我们提供了全面、有效的系统稳定性保障。在未来的发展中,随着技术的不断进步和应用场景的不断扩大,SRE 的理念和方法将继续发挥重要的作用。
海恩法则提到:每一起严重事故的背后,必然有 29 次轻微事故和 300 起未遂先兆以及 1000 起事故隐患。所以我们有必要通过主动监控、根因分析和容量规划三个主动措施,来有效地提升系统的稳定性。主动监控可以及时发现和解决潜在问题,防止故障发生。根因分析可以帮助团队找到问题的根源,从而更快地解决故障。容量规划则可以根据系统的负载情况提前进行规划和调整,避免因负载过大而导致的系统崩溃。通过这些措施的实施,可以有效地提高系统的稳定性和可靠性,为用户提供更好的服务体验。
要实现基于 SRE 的智能运维建设落地,我们需要从以下几个方面入手:
第一,建立统一的智能运维平台是基础。这个平台需要具备可观测性,能够全面监控和观测系统的各种指标,包括应用性能、系统资源、网络状态等,从而为后续的智能运维提供数据支撑。
第二,要建立统一的监控视角。这意味着我们需要对各种监控数据进行整合和关联,以便从宏观和微观两个层面全面了解系统的运行状态。这样,无论是 SRE 团队还是其他运维人员,都能够快速定位问题并采取相应的措施。
第三,面向业务的主动运维和高效处置是关键。通过利用智能运维平台的数据分析能力,我们可以提前预测和发现潜在的问题,并采取相应的措施进行预防和解决。此外,高效的处置机制也能够确保问题得到迅速解决,从而保证业务的连续性和稳定性。
第四,赋能 SRE 团队在实际场景中解决问题。SRE 团队是智能运维的核心力量,他们需要具备足够的技术能力和业务理解能力,以便在实际场景中快速定位和解决问题。因此,我们需要为他们提供足够的培训和支持,以确保他们能够充分发挥智能运维的优势。
最后,场景化观测业务状态和数据是保障。通过将业务状态和数据与实际场景相结合,我们可以更加深入地了解系统的运行状况和问题根源,从而更好地制定相应的解决方案和优化策略。
综上所述,基于 SRE 的智能运维建设落地需要从平台建设、监控视角、业务运维、团队赋能和场景化观测等多个方面入手,全面提升运维的智能化水平和业务连续性。
二、基于 SRE 的智能运维建设成效
中国移动某省公司网管智能运维平台是一个全面、高效的运维工具,旨在为用户提供简单、智能的运维体验。它通过统一底座支撑,实现了全流程、协同化、闭环式的监管模式,覆盖了业务、应用、组件、容器云、基础资源、网络等各个方面的数据采集、监控、告警、运维和安全等功能。这种新型的监管模式不仅提高了运维效率,还大大提升了服务的及时性和用户体验。通过智能化的监控和预警,该平台能够快速发现并解决问题,减少了故障发生和影响时间。同时,该平台还提供了强大的安全保障功能,确保了数据和系统的安全性。总言之,基于 SRE 建设的这套网管智能运维平台是一个功能强大、高效、安全的运维工具,能够为用户带来更好的服务体验和保障。
CMDB 在新一代智能运维系统中发挥着至关重要的作用。它不仅涵盖了 IAAS、PAAS 和 SAAS 等多层资源,还处理了这些资源之间的关联关系。通过记录资源的全生命周期状态,CMDB 能够提供关于资源配置和变化的实时信息。为了确保数据的准确性和完整性,它依赖于数据质量模块进行资源的自动维护、自动校验和变更管理。
此外,CMDB 的强大功能使其可以为多个平台提供服务,包括智能运维、多终端维护、DevOps、性能监控和日志分析等。这意味着无论是规划、工程还是运维阶段,CMDB 都可以帮助进行资源的配置管理,确保整个系统的顺利运行。
CMDB 是新一代智能运维系统的基石,它提供了强大的配置管理能力,并支持资源的全生命周期管理。需要秉持面向消费,数据权威,并要做到“问渠那得清如许,为有源头活水来”的思想来保证数据的可信;通过与各种平台的集成,它使组织能够更高效地进行资源配置和变更管理,从而提高了系统的可靠性和稳定性。
在监控方面,我们采用了多种手段进行整合,包括 Zabbix、CAT、NGINX 监控和指标自监控等。这些手段对网络/基础资源、组件/容器云、应用和业务进行全面的监控。我们的 SRE 团队和使用用户能够通过这些监控手段准确掌握各业务系统的运行情况,及时发现潜在问题,快速告警并进行定位,从而有效地进行优化。
为了更好地进行监控,我们规范了指标定义,以便更好地进行分析和管理。我们进行了指标数据清洗、聚合及归一化处理,为异常检测和分析算法提供了数据准备。此外,我们还提供了多种报警手段,如短信、邮件和电话等,以确保及时通知相关人员。我们还提供了动态阀值管理功能,可以进行预测监控,并自动生成工单和闭环解决流程,以支持快速响应和解决问题。
我们的监控系统不仅能够对现有问题进行监控和告警,还能够为未来的业务发展提供有力的支持。随着业务的不断扩展和变化,我们的监控系统也能够不断升级和调整,以满足不断变化的需求。我们的目标是确保各业务系统的稳定性和可用性,为用户提供更好的服务体验。
告警管理在现代 IT 运维中扮演着至关重要的角色。它主要依赖于传统的 syslog/snmp 协议和各种采集方式,如 zabbix,来实现对告警异常事件的实时收集。通过这些采集方式,告警管理能够有效地捕获系统中的异常情况,为后续的分析和处置提供必要的信息。
在收集到告警信息后,告警管理会根据预设的告警知识规则对这些信息进行分析和压缩。这一过程有助于过滤掉大量无用的信息,从而突出那些真正有价值的内容。通过这种方式,告警管理能够迅速地反映出现网的运行状况,为相关人员提供及时、准确的告警信息。
更重要的是,告警管理有助于避免误报和漏报的情况发生。在复杂的 IT 环境中,误报和漏报往往会给运维工作带来极大的困扰。而通过有效的告警管理,SRE 团队可以更加准确地判断系统的状态,从而采取适当的措施来保障系统的稳定运行。
总的来说,告警管理是保障 IT 系统稳定运行的重要手段之一。它通过对实时告警信息的收集、分析和压缩,为 SRE 团队提供了有力的支撑,有助于提高系统的可用性和可靠性。
我们结合了 CAT、ELK 和 NGINX 等开源工具,构建了一个全覆盖各级感知网络。这个网络不仅解决了“不及时、不到位、不好管”的监管难题,还通过海量数据融合,实现了数据可展示、可分析的一体化感知监控体系。
这个感知监控体系能够实时触达到各层级监管对象,对各被管理对象形成全面覆盖、上下贯通、运行高效的监管能力。无论是设备状态、网络流量还是应用性能,都能得到实时监控和预警。这不仅大大提高了故障发现和处理的效率,还降低了故障对业务的影响。
此外,这个感知监控体系还为 SRE 团队提供了强大的故障预防和定位能力。通过实时监控和预警,SRE 团队可以及时发现潜在的故障风险,并进行预防性维护。一旦发生故障,也能迅速定位问题所在,进行精准排障。这不仅降低了故障频次与时长,还提高了整个系统的稳定性和可用性。
我们所建设的某省公司网管系统具有强大的监控功能,从多个角度实时监测底层硬件、网络拓扑、数据库、进程、应用等各个方面。该系统不仅关注单个系统的运行状态,还从业务流和全业务系统的角度进行全面监控,确保系统质量和业务运行的稳定。
首先,从系统视角来看,该网管系统已经上线了 10 个以上的网管重点系统故障指挥看板,每个系统都从业务、资源、网络拓扑三个角度进行全面监控管理。这种多角度的监控方式可以更好地发现和解决系统故障,提高系统的稳定性和可靠性。
其次,从业务视角来看,该系统对涉及家集客业务的系统进行了全面监控。通过对 3 个重要节点和家宽 5.0 长流程端到端共计 30 多个接口 70 多个指标的监控,可以确保业务的顺畅运行。这种精细化的监控方式有助于及时发现和解决业务问题,提高客户满意度。
最后,从全景视角来看,该网管系统从 9 类网络设备、3 类核心资源、接口和差页率趋势共计 4 个维度来监控网管系统的全景情况。这种全方位的监控方式有助于全面了解网管系统的运行状况,及时发现和解决潜在问题。
通过串联之前说到的基于 SRE 的监控手段所建设的中国移动某省公司网管系统具有着强大的实时监控功能,从系统、业务和全景多个角度进行全面监控管理。该系统的应用有助于提高系统的稳定性和可靠性,确保业务的顺畅运行,为客户提供更好的服务体验。
在业务/应用方面,我们采用了组件/容器云技术,实现了基础资源/网络管理对象的自定义作业检查任务。通过自定义检查项脚本及检查指标项,我们可以全面地检测和评估系统的运行状态。此外,我们还提供了巡检结果汇总统计分析及通知功能,及时发现和解决潜在的问题,从源头上避免异常情况新增。
在日常工作中,运维场景全覆盖,运维工具和参数统一配置,可以自动执行重复和反复出现的任务。这大大减少了运维过程中出现的手动错误,提高了工作效率。同时,我们的系统还能实现运维的自动化和智能化,进一步提升系统的稳定性和可靠性。
我们基于 SRE 的自动化运维解决方案覆盖了从基础资源管理到应用层级的全方位运维需求,为网管的稳定运行提供了强有力的保障。
通过自动化运维的建设,我们成功地将人工的日常例行工作转变为自动化执行,大大提高了运维的效率和准确性。这不仅减少了人工错误的可能性,而且释放了运维人员,使他们能够专注于更高级的任务和创新工作。
在程序部署方面,自动化工具确保了所有应用程序都能在预定的时间内准确无误地部署到生产环境。这大大减少了部署过程中可能出现的错误,并确保了应用程序的一致性和稳定性。
在代理部署方面,自动化运维工具实现了快速、准确的代理部署。这使得网管系统能够迅速扩展其运维范围,而无需增加额外的运维人员。
至于故障快速恢复,自动化运维工具能够在检测到故障时立即启动恢复计划。这大大减少了故障对业务的影响,并确保了系统的高可用性。
此外,该自动化运维平台还支持 10 多套重点网管系统的日常系统巡检。这些系统涉及 1000 多台设备和近 10 个故障自愈场景。通过自动化工具,这些系统的巡检工作能够快速、准确地完成,从而确保了所有设备和系统的正常运行。
基于 SRE 的自动化运维建设提高了网管运维的效率和准确性,减少了人工错误的可能性,释放了运维人员,并确保了系统和应用程序的一致性、稳定性和高可用性。
随着数字化转型的深入推进,中国移动作为数字化建设推进的排头兵,而在数字化时代,网管系统成为了保障网络稳定运行的关键,也面临着诸多挑战和痛点,如业务流程复杂、问题跨系统定位困难、数量庞大、盯群困难等。为了解决这些问题,结合 SRE 实践,我们推出了数字员工“速答、督办、查询、发布”等业务场景的机器人。这些机器人可以替代原来一线运维人员规律且重复性强的工作,具有高效率、低成本等优势。数字员工的出现,不仅有助于重构运维人力体系,提升工作效能和服务及时性,还可以大幅降低运营成本。通过数字化生产力的形成,可以更好地应对数字化转型带来的挑战,实现更加高效、智能的业务运营。
目前,已有 20 多套网管系统接入使用,为连队提供了 7X24 小时的高效率、多任务稳定运行服务。这些系统不仅具备告警督办、工单督办、智能搜索和信息发布等功能,而且每月处理的告警督办高达 2000+次、工单督办 500+次、智能搜索 500+次、信息发布 700+次。
值得一提的是,为了提升 SRE 人员的战斗力,我们引入了页面质量感知机器人。该机器人能够通过无人值守的方式模拟用户操作,获取拨测数据并进行分析。这不仅减轻了人工负担,还提高了数据分析的准确性和效率。这些网管系统为连队提供了全方位的网络管理服务,确保了网络的稳定运行和高效运维。在未来,我们将继续探索新技术、新方法,不断提升网管系统的性能和功能,以满足连队日益增长的网络管理需求。
三、基于 SRE 的智能运维建设展望
接下来我们通过两个案例来分析一下现在还存在的问题以及对未来的展望
Case1:
故障现象:当某平台用户量增多时,OUTLINE 服务模块有概率性打开空白。这导致用户无法正常访问某些功能,严重影响了平台的可用性和用户体验。
故障定位:通过 APM 监控和平台给出的信息,我们确定问题出在 CAAS 平台的 A 平面服务 OUTLINE-A 上,它有概率性异常。
应用系统维护处理过程:
1.在定位问题后,我们首先尝试切换到无异常的 B 平面,以排除其他因素干扰。
2.观察 B 平面负载情况,如果出现异常升高,则进一步确认问题所在。
3.尝试切换回双平面模式,并扩展 OUTLINE-A 对应的 pod 副本数,以缓解负载压力。
4.如果负载恢复正常,但服务仍然异常,则考虑可能是 svc 到 pod 这段逻辑存在问题,或者是 caas 环境有问题。
当 caas 平台的维护面对置疑的时候,有点无语,但是好像又无力反驳。我们都知道 k8s 的网络还是比较复杂的,有很多转发类型,各种 cni 插件,想要都精通还是很难的。而面对置疑,svc 到 pod 又是 tcp 转发,不是七层,连日志都没。难搞。那么有没有一种好的手段来弥补这一块的可观测性呢。
为了解决上述问题,我深入挖掘了网络资源,发现了一篇来自浙江大学硕士论文,主要探讨了基于 eBPF 的容器网络可观测性方法与实践,大家有兴趣也可以去看一下。这篇论文详尽地阐述了在分布式容器网络环境中遇到的挑战,并介绍了解决这类问题的架构设计。其独特之处在于,整个过程无需侵入代码,既不需要像 cat 那样深入到每一行代码中,也不需要像 skywalking 那样在每个业务模块中注入代理。只需在 K8s 节点上运行 daemonset,即可实现对节点上应用容器的监控,这种方法简单而高效。
我们也尝试了基于 eBPF 扩展云监控及可观测性的实践,并结合 APM 技术,实现了对任意服务的全景视图、任意调用的分布式跟踪以及任意函数的性能剖析。这无疑为解决分布式网络问题提供了有力的支持。
Case2:
当收到用户报障反馈无法查询工单、工单回单失败、查询失败等异常提示时,需要采取一系列的步骤来定位故障。首先,需要查看错误日志,并使用 ELK 和 CAT 等工具来搜索相关的错误信息。这个过程需要专业的技术人员来完成,因为需要对日志文件进行分析,并结合异常调用链来确定问题的根源。然而,这个过程存在一些挑战。
首先,故障信息的获取依赖于用户的报障和人的判断,这可能导致报障信息不够及时,从而影响故障处理的时长。此外,定位故障的过程涉及到多个工具和页面的跳转,操作步骤较多,需要多次点击和搜索。这不仅增加了处理时间,还增加了出错的可能性。
另外,这个过程对专业技术人员的依赖性较高,因为每一步都需要专业的解读和分析。不同水平的技术人员的判断结果可能存在误差,导致故障定位不够精准。此外,处理建议也没有统一的标准,不同的技术人员可能会提出不同的建议,如重启服务或继续排查网络问题等。这些因素都可能影响故障处理的效率和效果。
传统故障处理方式通常面临着发现不够及时、定位过程复杂、依赖专家指挥等问题,导致故障全流程处理效率低下。为了解决这些问题,可以考虑以下几个方面:首先,可以建立一个自动化系统来监控和收集故障信息,减少对人的依赖和报障的延迟。其次,可以整合工具和页面,简化操作步骤,减少不必要的点击和搜索。最后,可以制定统一的处理标准和建议,提高故障处理的准确性和效率。并引入了大模型技术。通过 AI 大模型技术,可以实现问题内容的综合预判、热点类型的智能聚类以及分布地市的智能归类等功能,从而自动创建故障指挥单,在故障定位和恢复指引上也能提供智能推荐,极大地提高了故障处理的效率和准确性。
通过这些改进措施,可以更好地应对这些挑战,提高故障处理的能力和效率。
随着技术的发展和业务规模的扩大,我们相信基于 SRE 的智能运维建设将迎来更加广阔的发展空间。未来,我们将进一步深化 SRE 与智能运维的结合,推动运维的全面智能化。同时,我们也将持续探索新的技术和方法,提高智能运维的效率和准确性,为我们的数字化转型提供更加坚实的技术支撑。
版权声明: 本文为 InfoQ 作者【雅菲奥朗】的原创文章。
原文链接:【http://xie.infoq.cn/article/1584c257e12b7d9eeebad1dcc】。文章转载请联系作者。
评论