前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >DOIS大会参会总结和思考

DOIS大会参会总结和思考

作者头像
赵成
发布2018-08-09 10:14:48
4320
发布2018-08-09 10:14:48
举报
文章被收录于专栏:Forrest随想录Forrest随想录

上周去参加DOIS(DevOps International Summit,缩写:DOIS)会议。除了自己的分享外,也看了一些其他公司当前在做的事情,谈谈个人的看法:

一、对于DevOps的理解

目前来看大家都在推行DevOps相关的事情,不同的公司,不同的阶段,不同的行业,都会从不同的维度去入手。

1、ThoughtWorks林冰玉微服务测试的思考与实践

分享中,提到了传统的通过TDD(测试驱动开发)模式向GDS(目标驱动策略)转变,既定目标和度量结果的差异带来的改进手段问题。

在我们日常测试过程中也看出测试同学对测试环境的不够用的诉求,这块恰好和我们的多项目环境最初的诉求一致。

所以,在独立部署的情况下,底层平台对CI/CD的支持,以及遵守契约测试,我们自己Demeter开发阶段也是用过这种方式,提高团队之间协作效率。

注:CDC,消费者驱动的测试,分为服务Provider和服务Consumer端,那原始数据的格式和交互细节定义是由Consumer端定义契约文件,然后Provider根据契约文件来实现。

2、京东的模块化运维体系建设实践

本次和京东运营专家何永成同一个专场,京东在推进DevOps的过程中,是通过Kit工具集合来驱动的,也就是说提供制作和管理Kit的“商店”。

然后,把大家日常用到的工具集合起来,通过Agent下发执行,当然对于一些通用的Kit工具其实是可以被广大用户申请授权使用的。

其次,京东的运维也在做故障模拟相关的系统“响尾蛇系统”,类似我们现在做的故障模拟平台,可以去做场景化的模拟单机,应用,网络,机房级别的故障演练。

同时,在压测系统和容量系统的结合下,实现集容灾,资源,性能于一体的资源管控平台,一方面验证容量符合预期,另一方面在容量符合的前提下能够支持容灾能力

当然,随着机器的增加,同等宕机率的情况下,故障机器数量必然会增加,所以在这种量变带来质变的情况下,对于故障自动报修能力也是他们迫切需要的。

鉴于此,结合日常的故障发现(主机层面),故障分析,然后结合分析结果自动提交报修单,来释放运维的这种简单的繁琐工作

以上是京东分享出来的内容,当然会后沟通,还聊到了包括我们正在做的全生命周期管理平台,涉及到容量,资源,运维能力平台化的思考。

交流下来,上述内容在我们Demeter的规划中都有体现,当然好的产品还是需要持续打磨,需要时间,更需要贴近用户的使用。

二、对AIOPS的一些探索

1、百度曲显平分享的AIOps实践:

百度对AIOPS的探索主要在监控整个体系上面的尝试,比如故障管理中的发现,变更管理的监控,监控体系中的告警。

然后,基于现有数据,通过算法来驱动,按照策略,类型,业务,机房,人的维度去合并,当然对于一些特殊的场景其实并能不能适配,还需要个性化定制。

对于故障自愈方面结合业务场景去收集全局信息,然后通过算法去帮助快速决策,而在所有的能够故障自愈的场景中,不只是底层的公共设施,业务自身也需要具备自愈能力,所以这部分是底层技术和业务共同实现的。

无人值守变更管理,这块其实对于自助化服务来说其实是一个非常重要的环节,百度的整体方案还是结合DevOps自动化流水线的方式来驱动,其中涉及到流量调度,变更多次,信息通知,当然在整个变更过程中,把时间,任务,可用性影响,用户影响,上下游的影响涵盖了。

这块在我们Demeter的CD环节也可以做一定尝试,毕竟未来是开发自助式运维,那么变更是否合理,是否符合预期,出了认为判断,系统是否也能支持自我诊断能力。

不过,就目前AIOPS的探索中,绝大多数公司还都是在尝试,就目前来看大家做的停留在算法中,像BAT等大公司因为在体量和资源上的优势,无疑是走在最前列的。

2、阿里子昊-阿里集团网络的自动化推进

分享中仅提到的对历史的埋坑,一个人用了三个月把集团近5万行的无效配置清理掉,解决了历史坑向自动化标准化的改变。

其实,这块我想说的是我们在系统建设中难免会有各种各样的老数据,甚至是一些非常不标准的,而且是低ROI的事情。

但是,我们还是希望能够在迁移整理过程中,把这部分凌乱的数据规范化,做平台不仅仅是支撑业务,更是让业务在平台的约束能力下做规范,为后续工具平台能够方便、快速的支撑。

3、华为消费者BG张燕斌-云服务自动化运维平台开发实践

整个分享中其实主要谈到的是自动化平台的建设,其中更多的倾向于自动化系统的部署,配置,作业执行,以及基础的CMDB,监控系统,运维管理系统的思考。

这块其实算整个工具平台的场景化下面的原子化操作,这块就不做详细描述了。

监控体系采用的Prometheus和Grafana整合,当然对于小集群还是可以的,规模增加后其实一样会面临着数据压力的问题。

最后

以上是我参加的一些分享主题的思考,对于DevOps,大家都很清楚,它是提高开发的运维能力,必须需要工具平台支撑。

对于AIOps,绝大多数情况下,主要还停留在补数据+跑场景化验证,多数都是结合监控现有的丰富数据去尝试,聚合报警,关联诊断,故障自愈等。未来的AIOps,我想会更加趋于务实的方向逐步发展。


罗伟,花名清泉,蘑菇街工具平台技术专家,目前在主要负责蘑菇街的运维工具平台开发,支撑研发,运维,日常运维相关的服务,致力于提供简单、高效、快速的基础运营运维平台。加入蘑菇街之前曾在就职阿里巴巴,负责手淘整体运维工作,后转型运维开发,负责运维工具平台开发,支持无线,合一,闲鱼,阿里体育等业务。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-07-03,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Forrest随想录 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
CODING DevOps
CODING DevOps 一站式研发管理平台,包括代码托管、项目管理、测试管理、持续集成、制品库等多款产品和服务,涵盖软件开发从构想到交付的一切所需,使研发团队在云端高效协同,实践敏捷开发与 DevOps,提升软件交付质量与速度。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档