MSP服务为客户交出满意答卷

云掣YunChe3个月前客户案例139

运维背景




浙江创创鱼信息科技有限公司与我们MSP运维团队已合作了三年以上,随着创创鱼业务系统的稳步发展,业务规模和数据量持续增长,对IT运维体系和能力的要求也不断提高。


在MSP技术团队和创创鱼研发团队的紧密合作和共同努力下,我们在运维能力和流程管理上取得了显著进展,成功保障了创创鱼云上系统的平稳运行。




MSP服务目标




01

整体的IT规划,实现自动化,实现云原生


我们致力于帮助客户制定并实施全面的IT规划,确保其IT战略与业务需求紧密结合。具体措施包括:


  • 自动化:通过引入和实施自动化工具和流程,减少手动操作,提高效率和准确性,实现无缝运维。


  • 云原生:帮助客户实现向云原生架构的转型,充分利用云计算的弹性、可扩展性和高可用性,增强业务灵活性和创新能力。

02

提供专业的IT技能,延伸企业的IT能力


我们的专业团队为客户提供全面的IT支持,扩展其内部IT能力,确保其在竞争激烈的市场中保持技术领先。具体服务包括:


  • 专业技能支持:提供专家级的技术支持和咨询服务,覆盖网络管理、网络安全、数据库管理、应用开发等多个领域。

  • 技能培训:为客户的IT团队提供定期的技能培训和知识更新,提升其技术水平和问题解决能力,使其能够应对快速变化的技术环境。


03

持续优化成本


通过精细化的成本管理和优化策略,我们帮助客户有效控制和降低IT支出,实现资源的最佳利用。具体措施包括:


  • 资源优化:通过全面的资源审计和优化,确保IT资源的高效利用,避免资源浪费。

  • 成本管理:实施严谨的成本管理策略,优化IT采购和运营成本,确保每一笔IT支出都物有所值。

  • 云成本优化:运用云成本管理工具和优化策略,帮助客户降低云服务费用,同时提升使用效率和效果。



MSP服务总结




在过去的一年中,我们的MSP运维团队为客户提供了卓越的服务,确保客户业务的稳定高效运行。以下是我们重点完成的事项总结:


01

专业团队配置


在整个运维服务周期内,我们为客户配备了3位专业的运维工程师,包括2名主力工程师和1名备份工程师,全天候为客户业务保驾护航。


02

服务领域覆盖


我们从多个关键方向展开工作,全面提升客户的IT环境:


  • 服务性能优化:通过系统调优和资源管理,提升系统性能和响应速度。

  • 成本优化:优化资源使用和成本管理,帮助客户有效降低IT支出。

  • 运维效能提升:引入自动化运维工具和流程,显著提高运维效率和响应速度。

  • 数据迁移:成功实施多次数据迁移,确保数据安全和业务连续性。

  • 数据恢复:提供快速数据恢复服务,保障客户在数据丢失或损坏时的业务连续性。

  • 数据备份:实施并管理可靠的数据备份策略,确保数据安全和可恢复性。

  • SQL优化:优化数据库查询和操作,提升数据库性能和稳定性。

03

重点案例成果展示


在过去一年中,我们累计完成了超过400+次的运维事件,涵盖了上述各个方向的具体工作内容,显著提升了客户的IT运营水平。


云资源成本优化

去年运维周期内协助客户完成若干次费用优化,已完成云资源降本20w+,具体如下:


在过去的一年中,我们通过一系列优化措施,帮助客户实现了显著的成本节约和性能提升。以下是几个具体案例:


ECS节点替换降本


阿里云发布实例规格大幅降价公告后,我们对客户现有实例规格进行了评估,确认了ECS成本优化方案。由于旧的k8s节点在不支持新规格的可用区,我们采购了新的节点并逐步替换。


服务配置优化降本


通过优化Java类微服务和Kafka服务配置,k8s集群负载大幅下降,节约了大量CPU资源。在确保资源健康的前提下,新增了约40个前后端应用,相当于节省了2台8C 64G配置的ECS服务器,实现了将近 2万元的成本节约。


审计日志调整降本


针对RDS数据库费用进行分析,发现审计占用较多费用。与客户运维团队沟通后,关闭了部分非必要的实例审计,服务周期内节省了20w+。优化前后费用对比如下:


图片

优化前


图片

优化后


服务性能优化

最近的Kafka版本升级后,虽然ECS资源使用率有所下降,但是我们注意到仍然存在负载过高、服务启动时间过长以及系统响应较慢等问题。经过深入排查和分析,我们发现了以下关键问题,并通过运维优化措施取得了显著的成效:


1)资源调度优化


首先,我们发现order服务和share-stock服务占用了大量的CPU资源。为了有效分散负载,我们通过k8s的反亲和性调度功能,将这两个服务分别调度到不同的k8s节点上。这一步骤显著降低了资源的集中使用,有效提升了系统的稳定性和性能。


2)心跳探针配置修正


进一步分析中,我们发现Java类微服务与kafka服务之间的心跳探针配置存在异常。原本配置的心跳间隔为7秒,但由于参数命名转换失误,实际生效的却是7毫秒,这导致了不必要的CPU资源浪费。针对这一问题,我们及时修正了配置,将心跳间隔调整为正确的7秒。此举大幅度降低了k8s集群的负载,并显著减少了CPU资源的消耗。


本次优化效果对比图如下:


图片


通过以上优化措施,我们不仅有效解决了系统性能问题,还提升了服务的响应效率。这些措施不仅改善了用户体验,也展示了我们在运维管理和系统优化方面的专业能力和价值。


系统稳定性优化

我们在协助客户上线小程序业务时,遇到了CI/CD流程中断退出频繁的问题,严重影响了开发效率和系统稳定性。以下是我们解决问题的过程和取得的成效:

1)问题诊断与定位


初始阶段,我们发现在小程序后端应用进行CI/CD流程发布时,经常出现流程中断退出的情况。通过详细的排查和分析,我们初步定位到并发执行ossutil cp操作导致的bug。这一操作不支持并发执行,导致了流程的不稳定性。

2)Bug修复过程


针对ossutil cp并发执行的问题,我们迅速编写了修复工具,确保操作在不同任务间串行执行,避免了并发导致的流程中断。

3)新问题发现与处理


尽管修复了ossutil cp问题,随后又出现了另一个bug,这次是由Helm在并发处理方面存在问题所致。经过进一步的排查和测试,我们成功解决了Helm的并发问题,确保了CI/CD流程的稳定性和可靠性。

经过以上优化措施的实施,我们的CI/CD发布系统已经稳定运行了约两个月。在此期间,我们不仅解决了流程中断退出的问题,还显著提升了开发发布的效率和可靠性。开发团队可以更专注地进行代码开发和发布,而不再受到频繁的系统问题干扰。

K8S监控系统优化

在为客户自建Kubernetes监控系统的过程中,我们不仅考虑了技术选型和部署实施,还注重了系统的可扩展性和应用的全面覆盖,以下是进一步的详细内容:

1)技术选型与系统部署


我们深入分析客户的需求和现有基础设施,选择了Prometheus作为监控系统的核心组件。通过Prometheus Operator的部署,我们实现了监控规则的自动化管理和资源的动态发现,大大简化了系统的运维管理流程。

2)数据集成与可视化展示


为了确保监控数据的全面性和实时性,我们将多个K8S集群的监控数据整合至VictoriaMetrics中心化存储,并通过Grafana进行统一的可视化展示。客户可以通过Grafana仪表盘轻松查看各个集群的资源利用情况、应用性能指标和系统健康状态。

3)完善监控覆盖和应用


除了基础资源监控外,我们还实施了针对JVM、数据库、网络流量等多个方面的深度监控。通过定制化的监控指标和警报策略,我们帮助客户及时发现和解决潜在的性能瓶颈和安全隐患,提高了系统的稳定性和可靠性。

经过系统的完善和优化,客户的监控能力得到了显著增强,监控系统不仅提升了运维效率,还大幅降低了故障处理的时间和成本。这种持续监控和优化实践,为客户的数字化转型和业务发展提供了可靠的技术支持和保障。

运维效能提升

针对客户小程序相关系统需要根据活动情况进行灵活扩容的需求,我们采取了以下措施,显著提升了运维效能和操作的便捷性:

1)手动计算扩容节点数优化


最初阶段,我们根据监控数据和活动需求,手动计算扩容所需的POD数量和节点数。这种方法虽然有效,但存在一定的人工计算误差和时间成本。

2)制作Excel模板自动化计算


为了优化这一过程,我们开发了一个Excel模板,根据输入的POD数量自动计算出需要扩容的节点数量。这一改进不仅减少了人工计算的错误率,还提高了操作的效率和准确性。

3)编写脚本实现自动化扩容


为了进一步简化操作,我们编写了脚本,实现了程序集群的自动化扩容。这个脚本能够根据Excel模板计算的结果,自动调整集群中的POD数量,确保系统在高负载期间能够快速响应和调整资源。

4)提供详细的操作步骤和文档


为了保证操作的持续性和可维护性,我们提供了详细的扩容操作步骤和文档,让其他团队成员能够轻松理解和执行扩容过程。这些文档涵盖了从Excel模板的使用到脚本的调用,确保了操作的标准化和规范化。

通过以上措施的实施,我们显著提升了客户系统的灵活性和响应能力,尤其是在高活动期间的资源管理效率。自动化计算和执行扩容操作不仅节省了人力成本,还大大缩短了响应时间,确保了系统稳定性和良好用户体验。

数据库恢复演练

我们对DRDS实例进行了恢复演练,这次演练不仅是为了验证数据的安全性,还强化了我们在数据恢复和业务连续性方面的应急响应能力。以下是详细步骤及主动性增强的内容:

1)确定恢复类型和时间点


我们首先确定了恢复的类型,包括全量恢复和部分恢复,以及具体的恢复时间点。这些决策基于我们对系统备份策略和业务需求的深入理解。

2)预演练和预检测


在正式演练之前,我们进行了预演练和预检测,评估并验证了备份数据的完整性和可用性。这些步骤帮助我们提前发现潜在的问题并进行修复,以确保演练的顺利进行。

3)新实例开通和恢复操作


我们启动了新的DRDS实例,模拟实际灾难恢复情境。这次演练强调了快速响应和决策的重要性,确保在紧急情况下能够迅速启动恢复流程。

4)模拟灾难场景


为了增强演练的主动性,我们在演练中模拟了不同的灾难场景和数据丢失情形,以检验我们的恢复策略和流程。这种主动性的练习帮助我们识别和解决潜在的问题,提升了团队在应急情况下的反应能力。

5)业务验证和总结


最后,我们进行了业务数据的验证,确认恢复后系统的正常运行和数据的完整性。同时,我们总结了演练中的经验教训,并调整了备份策略和恢复流程,以进一步优化我们的应急响应能力。

数据库异构迁移

针对客户的需求,我们成功完成了从SQL Server到MySQL的数据库异构迁移,具体步骤和优化如下:

1)需求分析与规划


我们深入了解客户的业务需求,确认了从SQL Server到MySQL的数据库迁移计划。根据客户的项目结构和数据量,制定了详细的迁移方案和时间表。

2)全量数据迁移


我们利用阿里云的DTS(数据传输服务)进行了全量数据迁移。通过DTS的高效传输能力,确保了数据在迁移过程中的完整性和准确性,避免了数据丢失和损坏。

3)自研开发脚本优化


为了进一步优化迁移效率和适应性,我们开发了自动化脚本。该脚本实现了以下功能:


    • 对迁移的表名进行驼峰转换为下划线命名规范,提高了数据库结构的统一性和可读性。

    • 修改表字段的默认值,将原先的NOT NULL修改为NULL,符合目标数据库的设计和业务需求。

我们通过成功的数据库异构迁移案例,为客户的业务运作和数据管理提供了可靠的技术支持和保障,展示了我们在数据库迁移和自动化脚本开发方面的专业能力和创新优势。




来自客户的声音




image.png

相关文章

可观测运维作战实践-ACOS全链路监控案例

可观测运维作战实践-ACOS全链路监控案例

在时间十分紧迫前提下为客户建设一套监控体系实践就是一次作战!下面问题怎么解呢?1、客户现状痛点?2、适合客户全链路监控怎么搭建?3、故障突袭应急筹备方案?4、acos团队面临内外夹击挑战?5、作战结果...

CK集群迁云实施方案

背景与需求某企业大数据业务需迁至阿里云环境,其中涉及多套CK集群,业务要求停机切换时间尽可能短,需对数据进行增量迁移;需迁移的业务,有多个CK集群,总共几百多张表,最大的表占用空间10T左右,另外源端...

​Archery DBpass→NineData,数据库审计工具升级换代最佳实践(1)

​Archery DBpass→NineData,数据库审计工具升级换代最佳实践(1)

在 2022 年 4 月至 2023 年 3 月期间,经过DevOPS、DBA以及研发团队的密切协作与不懈努力,云掣为某电商行业客户实施了一系列数据库架构升级和深度优化策略,显著将每月数据库的告警事件...

图片

首先将腾讯云的ES集群全量快照备份至腾讯云COS中,待全量快照备份完成后,再使用阿里云的在线迁移服务功能,将腾讯云COS中的快照数据在线迁移至阿里云OSS。快照数据迁移完毕后,登录阿里云ES集群进行快照恢复操作即可,当所有的索引健康状态变为green,就表明快照恢复任务完成。
增量快照的备份恢复流程与全量快照的备份流程一致,区别仅在于,增量快照的备份恢复流程进行到最后一步快照恢复操作时,需要提前将阿里云ES集群中的索引状态修改为close,待快照数据全部恢复完成后,索引的健康状态会默认变为green。


 建设内容

Step1:环境准备


预先在阿里云购买可1:1安装的集群,即资源规格、集群插件与当前腾讯云ES集群一致的阿里云6.7.0版本ES集群,然后提前将腾讯云中全量的ES集群数据通过快照迁移的方式迁移到阿里云ES集群中。


Step2:代码验证


客户公司的研发人员对迁移后的集群数据进行灰度测试,包括客户端连接、写入、读取等功能的代码测试。


Step3:割接前的流程梳理确认

  1. 确定写入的链路,并读取业务方负责人信息;
  2. 准备好防止数据丢失和保障数据一致的预案;
  3. 明确回滚方案。

Step4:割接前的数据迁移

  1. 关闭阿里云ES集群的白名单,禁止研发测试的数据写入,保障集群环境单一可靠;
  2. 清空阿里云ES集群的脏数据、数据验证、历史快照的恢复和同步记录;
  3. 进行增量快照的恢复和同步,并保持验证,直至割接前;
  4. 如果第2步和第4步有重合的部分,为了防止数据污染,需要在阿里云ES集群中再进行一次历史数据清空和增全量恢复的动作。

Step5:割接开始

  1. 研发人员提前将配置文件的地址修改为阿里云ES集群连接内网的地址,并设置业务不上线生效;
  2. 关闭腾讯云ES集群的业务数据写入;
  3. 最后一次进行增量数据快照和恢复动作,将数据补齐;
  4. 开启阿里云ES集群的白名单;
  5. 设置切换配置生效,并进行上线动作,完成读写业务后,再切换到阿里云ES集群;
  6. 进行读写验证;
  7. 关闭腾讯云ES集群的白名单;
  8. 测试工程师进行回归测试

Step6:回滚

  1. 将阿里云ES集群的白名单关闭,停止写入数据;
  2. 恢复腾讯云ES集群的白名单,并将配置文件的地址改回腾讯云ES集群生效;
  3. 回滚方案生效,业务数据(kafka、mysql)重新消费写入腾讯云ES集群。



 知识拓展

 快照备份


ES集群基于快照的迁移方式
需通过 snapshot api 接口进行迁移,基本原理是从源ES集群创建索引快照,然后在目标ES集群中进行快照恢复。通过snapshot api方式进行数据迁移时,特别需要注意ES集群的版本,目标ES集群的主版本号要大于等于源ES集群的主版本号。
例如:6.x中的6为主版本号,那么此集群所创建的快照就不能在7.x版本的集群中恢复。
快照迁移支持索引数据的增量备份和恢复迁移
由于二次快照是在前一次快照的索引数据基础之上,再增加新数据的快照,包括了索引数据的增、删、改等新变动。那么在二次快照之后,新的ES集群实例恢复后,新数据与源ES集群实例数据将保持一致。
二次快照备份恢复的时长
由于二次快照的数据量低于首次快照,所以耗时会比首次快照备份的时间短。


 logstash迁移同步


logstash的版本
应与目标ES集群的主版本号相同。例如:目标ES集群为6.8.2版本,则logstash也需要使用6.8版本。
索引type的问题
不同版本的ES集群对索引type的约束也不同,所以在跨大版本迁移ES集群时,可能会出现因为索引type而导致目标集群写入失败等情况。这是因为logstash的增量数据同步基于时间字段,所以要求字段类型为@timetamp时,才能按照时间同步数据。若时间字段为long、text等非标准的类型,则无法按照时间同步数据。
硬件和网络配置要求
logstash对网络带宽和服务器CPU、内存、磁盘的要求较高,如果想实时同步大量数据,就必须提升硬件和网络配置。


 总结


此次迁云方案效率实现了业务停机时间的最小化,迅速响应了客户公司的需求,并确保了迁移前后数据的一致性。


从腾讯云到阿里云,ES集群跨云迁移技术原理及最佳实践

本文旨在通过一次腾讯云ES集群在线迁移至阿里云ES集群的成功客户案例,结合云掣在多次客户数据迁移过程中总结出的宝贵经验,与大家详细地分享快照迁移ES集群的技术原理和最佳实践,有助于满足各行业领域客户跨...

知名房企数据化可观测运维实践

知名房企数据化可观测运维实践

项目背景    伴随着“云+”时代的到来,通过上云实现企业数字化转型已经成为众多行业的共识。工信部发布的《推动企业上云实施指南(2018—2020年)》一文中提出了企业上云的工作目...

发表评论    

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。