Meetup北京报名开启|一起吹响Container+集结号

杨y 发表了文章 • 0 个评论 • 115 次浏览 • 2017-08-01 10:30 • 来自相关话题

Container技术在国内的落地实践,

已进阶Container+

8月阅兵仪式,一睹超强装备的风采,

技术圈也不落人后,

本次Meetup邀请到来自微软、当当、数人云的技术大牛以及一位神秘嘉宾,

共同来一场Container的大阅兵,

看Serverless、DevOps、微服务、CI/CD、分布式调度任务等技术,

在各个场景中与Container发生的碰撞与交互。

吹着空调唠唠嗑,一起开启夏日清凉模式!
 
 
往期实录传送门:
 
DevOps&SRE深圳站资料全收录:

1)数人云王璞:《SRE在传统企业中的落地实践》

2)优维王津银:《DevOps与传统的融合落地实践及案例分析》

3)腾讯大梁:《DevOps最后一棒,有效构建海量运营的持续反馈能力》

4)演讲视频回放:http://www.itdks.com/dakashuo/playback/404


DevOps&SRE北京站资料全收录:

1)数人云邱戈川:《不以敏捷开发为基础的DevOps都是耍流氓》

2)优维黄星玲:《教你如何打造易用DevOps工具链》

3)演讲视频回放:http://www.itdks.com/dakashuo/playback/908
 
分享嘉宾





林昭明/数人云技术总监
 
曾在亚信科技平台架构部、阿里巴巴B2B业务平台部,唯品会基础架构部,担任技术总监或技术专家角色。

主要技术研究方向是高并发、高性能的技术架构应用,微服务、大数据、云计算等。

15年IT老兵,长期负责电信级别支撑系统和互联网高并发行业的技术架构工作,具有丰富的大型软件系统技术架构和项目实施经验。


分享主题:《数人云分布式任务调度平台Octopus实践》
 





高洪涛/当当系统架构师
 
 
当当系统架构师,技术委员会成员,分布式存储技术专家,Oracle DBA OCP。有丰富的数据存储,管理经验。从2013年开始从事大规模分布式存储系统的设计与研发工作,参与大型云平台数据中间层建设工作,2015年加入当当。目前从事Elastic-Job-Cloud的设计,研发与运维工作。

分享主题:《当当基于Mesos的DevOps实践》

微软及神秘嘉宾持续更新中……
 
活动议程
 
13:30-14:00  签到
14:00-14:40   微软嘉宾分享
14:40-15:20  林昭明@数人云  《数人云分布式任务调度平台Octopus实践》
15:20-16:00   高洪涛@当当网  《当当基于Mesos的DevOps实践》
16:00-16:40  神秘嘉宾分享
16:40-17:00  自由交流
 
时间地点
 
8月19日(周六)下午14:00-17:00
北京海淀区中关村E世界A座B2 P2联合创业办公社
 
报名链接
点击报名
 
 

更多活动信息,欢迎关注数人云微信公众号




  查看全部
微信.jpg

Container技术在国内的落地实践,

已进阶Container+

8月阅兵仪式,一睹超强装备的风采,

技术圈也不落人后,

本次Meetup邀请到来自微软、当当、数人云的技术大牛以及一位神秘嘉宾,

共同来一场Container的大阅兵,

看Serverless、DevOps、微服务、CI/CD、分布式调度任务等技术,

在各个场景中与Container发生的碰撞与交互。

吹着空调唠唠嗑,一起开启夏日清凉模式!
 
 
往期实录传送门:
 
DevOps&SRE深圳站资料全收录:

1)数人云王璞:《SRE在传统企业中的落地实践》

2)优维王津银:《DevOps与传统的融合落地实践及案例分析》

3)腾讯大梁:《DevOps最后一棒,有效构建海量运营的持续反馈能力》

4)演讲视频回放:http://www.itdks.com/dakashuo/playback/404


DevOps&SRE北京站资料全收录:

1)数人云邱戈川:《不以敏捷开发为基础的DevOps都是耍流氓》

2)优维黄星玲:《教你如何打造易用DevOps工具链》

3)演讲视频回放:http://www.itdks.com/dakashuo/playback/908
 
分享嘉宾

SR.png

林昭明/数人云技术总监
 
曾在亚信科技平台架构部、阿里巴巴B2B业务平台部,唯品会基础架构部,担任技术总监或技术专家角色。

主要技术研究方向是高并发、高性能的技术架构应用,微服务、大数据、云计算等。

15年IT老兵,长期负责电信级别支撑系统和互联网高并发行业的技术架构工作,具有丰富的大型软件系统技术架构和项目实施经验。


分享主题:《数人云分布式任务调度平台Octopus实践》
 

DD.png

高洪涛/当当系统架构师
 
 
当当系统架构师,技术委员会成员,分布式存储技术专家,Oracle DBA OCP。有丰富的数据存储,管理经验。从2013年开始从事大规模分布式存储系统的设计与研发工作,参与大型云平台数据中间层建设工作,2015年加入当当。目前从事Elastic-Job-Cloud的设计,研发与运维工作。

分享主题:《当当基于Mesos的DevOps实践》

微软及神秘嘉宾持续更新中……
 
活动议程
 
13:30-14:00  签到
14:00-14:40   微软嘉宾分享
14:40-15:20  林昭明@数人云  《数人云分布式任务调度平台Octopus实践》
15:20-16:00   高洪涛@当当网  《当当基于Mesos的DevOps实践》
16:00-16:40  神秘嘉宾分享
16:40-17:00  自由交流
 
时间地点
 
8月19日(周六)下午14:00-17:00
北京海淀区中关村E世界A座B2 P2联合创业办公社
 
报名链接
点击报名
 
 

更多活动信息,欢迎关注数人云微信公众号
QQ图片20170801103212.png

 

有心了,他写了一份DevOps&SRE参会笔记分享给你 | 附PPT下载

杨y 发表了文章 • 0 个评论 • 149 次浏览 • 2017-07-28 12:38 • 来自相关话题

数人云微信公众号后台回复“715活动”获取PPT






△扫码关注数人云微信公众号

7.15 上海·37℃ ☼

DevOps&SRE超越传统运维之道

由于之前的场地旁边装修,为了让大家有更好的体验,我们临时更换了场地,非常感谢顶着酷暑来参加活动的小伙伴们,现场座无虚席,小数心里美美哒:)












参会的小伙伴认真地做着笔记,会后惊喜地发现任聪同学写了一篇会议纪要,征得作者同意,小数把内容分享出来共勉,手动给这位同学点赞! 以下是这份笔记的详细内容:

参加DevOps&SRE运维会议纪要
参会简介

本人主要工作是开发,偶尔也会兼职管理下运维发布之事,但是对现代化DevOps不是很熟悉,因此此次参会的主要目的是了解他人是如何做DevOps的以及获取一些技术与工具的信息和运用,以便应用于工作当中。此次会议讲述了一些工作流程与理念、包括自研自动化工具等,这些让我还是有一点似懂非懂的感觉,但是还是有一些收获的(纯属个人总结,若有偏差欢迎指正):

理念

人是没有程序靠谱的,大量重复性工作,对人来说可能会犯错和误操作,而验证后的程序基本上不会出现这种问题。

人不是机器,需要休息。正如世界上没有完全一样的两个人,不同的人做的同样的事结果也不会一样。

一般情况,人的效率比不上程序、机器人(人与车赛跑,与AI下棋,都是一批高智商的人和团队协作出来的结果,若人肉PK,没有意义)。

运维工作有据可循,或者说在开发的配合下是有一定流程,因此这件事才比较容易交给程序去做(有创造性的要看AI的发展),因此我觉得现代化DevOps中的几个核心点是:标准化、流程化、自动化、简单化。像传统制造行业中的流水线一样,开发与运维依据几个核心点的指导下去配合完成工作,因此优维科技的刘劲辉说:DevOps是一种文化和精神,是组织的一种方式,是持续的学习。

提到的工具、框架简单介绍

Jenkins

一款持续集成的工具,能够通过代码Push等事件触发编译发布动作,可以减轻部署发布的工作,减少分布周期提高发布次数,能够及早的发现问题,节省项目的时间和成本,保证代码质量。

RobotFramework

RobotFramework是一款自动化测试框架,优维科技的测试框架在此工具上进行了二次开发。其大概方法是,编写接口按照规范注解注释@Param接口方法,自动生成测试代码,测试用例的数据作为代码进行维护,并且能通过面板看到测试用例运行的情况,出现问题会进行邮件通知。

洋葱登录(https://www.yangcong.com/)

洋葱登录是一款管理用户员工身份验证的产品,能够帮助企业提升员工权限的安全度,京东无线运维中的权限管理就是根据洋葱登录的功能来重构的。

Git-Flow

基于Git的强大分支能力所构建的一套软件开发工作流,通过分支与标签来进行版本管理。

详细英文介绍:(https://www.atlassian.com/git/ ... flows)

中文资料:(http://blog.jobbole.com/76843/)

数人云分享监控系统图

对于自动化来说,日志查询、监控、告警是极其重要和合理的,人不需要参与到工程中,但要掌握情况以便出现突发问题能及时有效的处理,下面这张图是数人云讲师分享的基于实践序列数据的监控系统图。






总结

本次会议主要偏向运维工作中的一些实际内容,几位讲师尽心尽责地分享切身感受,虽然我站在开发的角度,但还是有所收获,因为理念和一些工具是通用的。

分享人:任聪@上海咯叽网络科技有限公司

原文链接:http://www.jianshu.com/p/7f7d591852b8

收获了知识才是最重要的,也欢迎各位小伙伴在后续的活动中将心得笔记通过小数分享给大家~

嘉宾分享
(微信后台回复“715活动”获取PPT)






 
△张保珠@数人云 《SRE之道下金融行业的落地实践过程》






△刘劲辉@优维科技 《优维科技,内部产品研发DevOps实践》






△于绮@京东 《从传统运维到DevOps的落地经验及思考》







△周炎@东方财富网 《传统行业-运维人员如何应对企业DevOps转型》

数人云、优维科技、中生代——

感谢大家参与《DevOps&SRE超越传统运维之道·上海站》,

数人云微信公众号后台回复“715活动”获取PPT,

注意尊重嘉宾原创内容,

切勿滥传播,

敬请期待文字和视频整理: )

Ps:因内部信息不方便分享,故东方财富网和优维科技的PPT暂不外放,敬请谅解。





  查看全部
1.png


数人云微信公众号后台回复“715活动”获取PPT

10.png


△扫码关注数人云微信公众号

7.15 上海·37℃ ☼

DevOps&SRE超越传统运维之道

由于之前的场地旁边装修,为了让大家有更好的体验,我们临时更换了场地,非常感谢顶着酷暑来参加活动的小伙伴们,现场座无虚席,小数心里美美哒:)

2.png


3.png



参会的小伙伴认真地做着笔记,会后惊喜地发现任聪同学写了一篇会议纪要,征得作者同意,小数把内容分享出来共勉,手动给这位同学点赞! 以下是这份笔记的详细内容:

参加DevOps&SRE运维会议纪要
参会简介


本人主要工作是开发,偶尔也会兼职管理下运维发布之事,但是对现代化DevOps不是很熟悉,因此此次参会的主要目的是了解他人是如何做DevOps的以及获取一些技术与工具的信息和运用,以便应用于工作当中。此次会议讲述了一些工作流程与理念、包括自研自动化工具等,这些让我还是有一点似懂非懂的感觉,但是还是有一些收获的(纯属个人总结,若有偏差欢迎指正):

理念

人是没有程序靠谱的,大量重复性工作,对人来说可能会犯错和误操作,而验证后的程序基本上不会出现这种问题。

人不是机器,需要休息。正如世界上没有完全一样的两个人,不同的人做的同样的事结果也不会一样。

一般情况,人的效率比不上程序、机器人(人与车赛跑,与AI下棋,都是一批高智商的人和团队协作出来的结果,若人肉PK,没有意义)。

运维工作有据可循,或者说在开发的配合下是有一定流程,因此这件事才比较容易交给程序去做(有创造性的要看AI的发展),因此我觉得现代化DevOps中的几个核心点是:标准化、流程化、自动化、简单化。像传统制造行业中的流水线一样,开发与运维依据几个核心点的指导下去配合完成工作,因此优维科技的刘劲辉说:DevOps是一种文化和精神,是组织的一种方式,是持续的学习。

提到的工具、框架简单介绍

Jenkins

一款持续集成的工具,能够通过代码Push等事件触发编译发布动作,可以减轻部署发布的工作,减少分布周期提高发布次数,能够及早的发现问题,节省项目的时间和成本,保证代码质量。

RobotFramework

RobotFramework是一款自动化测试框架,优维科技的测试框架在此工具上进行了二次开发。其大概方法是,编写接口按照规范注解注释@Param接口方法,自动生成测试代码,测试用例的数据作为代码进行维护,并且能通过面板看到测试用例运行的情况,出现问题会进行邮件通知。

洋葱登录(https://www.yangcong.com/

洋葱登录是一款管理用户员工身份验证的产品,能够帮助企业提升员工权限的安全度,京东无线运维中的权限管理就是根据洋葱登录的功能来重构的。

Git-Flow

基于Git的强大分支能力所构建的一套软件开发工作流,通过分支与标签来进行版本管理。

详细英文介绍:(https://www.atlassian.com/git/ ... flows

中文资料:(http://blog.jobbole.com/76843/

数人云分享监控系统图

对于自动化来说,日志查询、监控、告警是极其重要和合理的,人不需要参与到工程中,但要掌握情况以便出现突发问题能及时有效的处理,下面这张图是数人云讲师分享的基于实践序列数据的监控系统图。

4.png


总结

本次会议主要偏向运维工作中的一些实际内容,几位讲师尽心尽责地分享切身感受,虽然我站在开发的角度,但还是有所收获,因为理念和一些工具是通用的。

分享人:任聪@上海咯叽网络科技有限公司

原文链接:http://www.jianshu.com/p/7f7d591852b8

收获了知识才是最重要的,也欢迎各位小伙伴在后续的活动中将心得笔记通过小数分享给大家~

嘉宾分享
(微信后台回复“715活动”获取PPT)


5.png

 
△张保珠@数人云 《SRE之道下金融行业的落地实践过程》

6.png


△刘劲辉@优维科技 《优维科技,内部产品研发DevOps实践》

7.png


△于绮@京东 《从传统运维到DevOps的落地经验及思考》


8.png


△周炎@东方财富网 《传统行业-运维人员如何应对企业DevOps转型》

数人云、优维科技、中生代——

感谢大家参与《DevOps&SRE超越传统运维之道·上海站》,

数人云微信公众号后台回复“715活动”获取PPT,

注意尊重嘉宾原创内容,

切勿滥传播,

敬请期待文字和视频整理: )

Ps:因内部信息不方便分享,故东方财富网和优维科技的PPT暂不外放,敬请谅解。

9.png

 

实践|SRE遇上金融老干部,解决发布协调&监控告警两大难题

杨y 发表了文章 • 0 个评论 • 154 次浏览 • 2017-07-28 12:29 • 来自相关话题

7月15日上海的《DevOps&SRE超越传统运维之道》主题沙龙上,数人云工程师保珠从核心理念、金融行业ITSM特性、发布协调、监控告警、总结定位等方面详细地阐述了数人云在金融场景下的落地实践。






今天主要跟大家分享数人云SRE的落地实践,因为目标客户主要是金融行业,所以基于ITSM特性,介绍实际场景中的发布协调和监控告警。

SRE核心理念






SRE是谷歌十数年运维过程中演练出来的模式,在实践过程中积累了很多经验,跟传统运维有一些区别。是建立在DevOps的思想上的运维方面具体实践。






SRE岗位工作职责有:

应急相应
日常运维
工程研发

SRE跟传统运维的工作职责类似,但在工作方式上有很大区别: 1)应急响应主要落实在对监控、应急事件的处理以及事后总结。

2)日常运维包括容量规划、性能监控、并更管理。

3)工程研发方面跟传统运维的区别在于参与研发事件、SLO制定和保障以及自动化,自动化运维是长期目标,也是热点内容。






SRE的工作原则: 拥抱变化:不担心付出风险而拒绝改变,通过不断的推演和演练发现并解决问题。

服务等级目标:将服务划分等级分配给不同的运维。

减少琐事:节省更多的时间用于开发。

自动化&简单化:开发的主要目的。

金融行业ITSM特性






金融行业在ITSM的特性主要是分级管理,工作模式上,运维和开发完全隔离,但这是DevOps思想尚未达成的表现。运维团队规模是线性增长的,如上线一个系统时都会分配1—2个运维人员进行跟进。不管从网络还是资源分配上,他们的职责更多在应急事件处理和常规变更上。

证监会和银监会有合规运维的要求,比如两地三个数据中心,这是金融行业比较明显的特性。






传统模式和SRE的区别—— 传统模式:易招聘,传统行业招聘的运维首先是会Shell,Python等脚本编写,在自动化运维工具上会有新要求,过往经验积累如曾解决的事故,应对的问题。

SRE:难招聘,相对新兴的岗位,很难找到完全匹配的人才;会有开发上的要求,强调自动化,包括在自动化工具里做编程性的内容,团队协作等等。






接下来分享SRE在两个客户实际场景的落地:某交易所、某商业银行信用卡中心。

SRE平台架构模型如上图,资源供给层是基于数人云的PaaS平台,以Docker容器化管理做资源调动,应用调度分别基于Mesos和Marathon,目前数人云也开源了名为Swan(Mesos调度器,Github地址:https://github.com/Dataman-Cloud/swan 欢迎Star&Fork)的应用调度系统,目标是把Marathon替换掉。而后是软件技术架构层,对应公司里的架构部门,包括采用RPC框架、缓存、消息中心选型等等。

主要分享的内容在DC SRE这一层。再往上包括产品线有TISRE,也有接近于用户数使用的APP SRE,所以个人理解这是长期的建设过程。

实践—发布协调






发布协调在日常的工作中应用很多,如应用上线、变更管理。在SRE指导下,某项目现场成立了类似于发布协调的团队。成立SRE团队与金融行业系统上线特点有关:

金融行业里系统较多,包括信贷、信审等等诸多应用,系统逻辑也比较复杂。开发测试环境如物理环境完全隔离,和互联网行业不同。互联网行业,都是在线发布,测试环境也许就是生产环境,采用灰度发布或者蓝绿发布模式去做。

上线协调需要同时面对多个外包团队,外包团队人员相对不可控,导致沟通成本较高。

规模大的系统发布上线周期长。

如何解决以上问题,达到发布进入可控,降低发布失败率,缩短发布时间周期?






上述问题,在SRE的思想中,首先要建立发布协调团队。目前SRE工程师只能自行培养。团队推荐构成:项目经理、架构师、运维工程师、开发工程师。沟通方式以发布上线会议为主,不断Check系统或者产品开展工作。






团队的职责包括:审核新产品和内部服务,确保预期的性能指标和非性能指标。根据发布的任务进度,负责发布过程中技术相关问题,以及协调外包公司的开发进度等等。

最重要的是要做到发布过程中的守门员,系统是否上线要由发布协调团队决定。






团队在整个服务生命周期过程中,不同阶段,都要进行会议审核才能继续开展工作。会议根据发布的检查列表包括三个方面:架构与依赖、容量规划、发布计划。

在架构与依赖方面的逻辑架构,部署架构,包括请求数据流的顺序,检查负载均衡,日志规范着重配合监控方面的要求。同时检查第三方监控调用时是否进行测试管理等等。

容量规划主要是根据压缩报告做容量预估,以及峰值,比如微信活动比较多,所以会根据预估峰值的公司预算出来需要的资源,再落实到容器上,制定详细计划保障发布的成功率。

制定发布计划,确保成功。






在SRE的指导中,每件事都要落实到工具当中,由工具去检查每个事项是否落实到位。当时做了发布平台,包括PipeLine、Jenkins,通过其调用负载均衡上的配置F5和配置中心,以及服务注册中心的机制。所有的发布事项基于容器云平台,功能模块包括变更管理、发布管理、流程模板及发布过程监控。






上图是发布平台项目大盘图,可以看到项目在发布流程中执行情况——成功率和失败率。没有发布平台前,整个上线过程管理人员不能实时看到发布具体情况,是卡在网络还是某一个服务上,因此进度不可控。

有了这样的运维大盘后,整个发布过程能进行可视化跟踪,关键节点需要人工审核。

具体的发布步骤:

第一,检查F5里面的配置
第二,人工检查
第三,上传程序包,配置项管理
最后,重启容器再进行人工检查

整体过程都体现了SRE思想,发布平台的每个步骤均可通过界面配置完成,中间关键点由人工参与,目的是保障产品上线的成功率,避免在上线过程中手动配置产生问题,导致回滚事件发生。






有了发布协调团队后,上线的成功率、自动化程度和发布效率明显提高,减少了人肉操作落实在Jenkins、PipeLine的配置项上,降低错误发生几率。

实践—监控告警






监控作为一个垂直系统,在数人云的产品体系中举足轻重。监控的重要性深有体会,我们在某金融公司SRE团队中有1—2名监控专员,专员主要职责是维护监控系统。一个是甲方内部人员,另一个是数人云的同事。

监控主要解决的问题: 首先要及时发现,时效性很重要,因此需建立监控系统。

为什么会出现故障,要多做事故总结以及后续的故障跟踪。






上图为监控系统架构图,基于Prometheus的时序数据库,红线为监控的数据流向,因是Mesos框架,所以左边会看到Mesos运算节点上的监控项。通过容器化的Cadvisor组件收集主机和该主机所有容器的CPU和内存以及磁盘信息。告警部分使用Prometheus的Altermanager组件,支持Webhook方式,通过短信、邮件形式告警。为了事后总结,需将一些告警事件存在数据库中。

绿线主要体现在日志收集和关键字告警,日志收集通过容器化的Logstash组件,首先收集容器内部的中间件,如Tomcat等Web中间件的日志,也能收集应用日志,根据需要会把一些信息丢到Kafka里面,通过大数据平台做在线日志分析。






日志关键字告警是通过自研组件在日志传输过程中过滤关键字进行事件告警。

容器服务的健康状况通过Marathon的事件Pushgateway推到Prometheus,最后在前台以自己开发的UI查看监控信息和告警上的配置。为方便使用Prometheus的查询做统一封装,减少API使用复杂度。






在SRE体系里很明确提到了监控的4大黄金指标:延迟、流量、错误、饱和度:

延迟:监控服务的API以及URL的访问时间,直接配置某一个服务的URL,后台不断去访问,包括访问时间的预值,超过时间发出告警。

流量:负载均衡请求的连接数。

错误:监控HTTP请求返回码和日志中异常关键字。

饱和度:根据不同的系统,如内存资源性系统监控内存使用率,IO读写使用比较高,监控资源IO情况。

以上指标要在运维的过程中不断优化,如一些告警可能是网络原因进而产生其他问题,如网络交换机出现问题,直接挂掉平台的Marathon组件,应用上很明显是第三方服务调用,接连会产生很多问题,要把共性问题聚合,减少误告警次数。但减少误告警也可能会把有效告警卡掉,也值得思考。






故障跟踪和事后总结类似,人工操作会延长恢复时间,告警发生时一般由一个人处理,随着时间延长而升级策略,如超过半个小时会逐级上报调用更多的资源处理故障。在故障跟踪上解决线上问题为主,处女座强迫症为辅,做好





事故总结非常重要,解决不意味着结束,要追溯原因,如交换机重启,导致Marathon的一些问题,总结后发现,最好的解决办法是交换机重启时通知运维,停掉相关组件,交换机恢复后,再启动,如此不影响业务的实际运行。

要从失败中学习,把告警的事件做记录建立知识库,发生问题时方便检索,快速找到解决方案,要总结解决某个事故时如何更快发现问题所在,建立反馈机制,在SRE监控过程中,不断跟产品做实时反馈,包括连接池的使用情况等,鼓励主动测试,平时运维不会发生的事,尽可能想办法去看结果。

目标定位






SRE目标定位内容很多,在各个行业落地时不尽相同,所以要基于现实,拥抱变化,为了更好应对事故,坚持做推演和演练,在事故总结方面对产品做建言,故此在工具的研发上也会有决策权。
 
更多精彩文章,欢迎关注数人云公众号:





 
  查看全部
1.png


7月15日上海的《DevOps&SRE超越传统运维之道》主题沙龙上,数人云工程师保珠从核心理念、金融行业ITSM特性、发布协调、监控告警、总结定位等方面详细地阐述了数人云在金融场景下的落地实践。

2.png


今天主要跟大家分享数人云SRE的落地实践,因为目标客户主要是金融行业,所以基于ITSM特性,介绍实际场景中的发布协调和监控告警。

SRE核心理念

3.png


SRE是谷歌十数年运维过程中演练出来的模式,在实践过程中积累了很多经验,跟传统运维有一些区别。是建立在DevOps的思想上的运维方面具体实践。

4.png


SRE岗位工作职责有:

应急相应
日常运维
工程研发

SRE跟传统运维的工作职责类似,但在工作方式上有很大区别: 1)应急响应主要落实在对监控、应急事件的处理以及事后总结。

2)日常运维包括容量规划、性能监控、并更管理。

3)工程研发方面跟传统运维的区别在于参与研发事件、SLO制定和保障以及自动化,自动化运维是长期目标,也是热点内容。

5.png


SRE的工作原则: 拥抱变化:不担心付出风险而拒绝改变,通过不断的推演和演练发现并解决问题。

服务等级目标:将服务划分等级分配给不同的运维。

减少琐事:节省更多的时间用于开发。

自动化&简单化:开发的主要目的。

金融行业ITSM特性

6.png


金融行业在ITSM的特性主要是分级管理,工作模式上,运维和开发完全隔离,但这是DevOps思想尚未达成的表现。运维团队规模是线性增长的,如上线一个系统时都会分配1—2个运维人员进行跟进。不管从网络还是资源分配上,他们的职责更多在应急事件处理和常规变更上。

证监会和银监会有合规运维的要求,比如两地三个数据中心,这是金融行业比较明显的特性。

7.png


传统模式和SRE的区别—— 传统模式:易招聘,传统行业招聘的运维首先是会Shell,Python等脚本编写,在自动化运维工具上会有新要求,过往经验积累如曾解决的事故,应对的问题。

SRE:难招聘,相对新兴的岗位,很难找到完全匹配的人才;会有开发上的要求,强调自动化,包括在自动化工具里做编程性的内容,团队协作等等。

8.png


接下来分享SRE在两个客户实际场景的落地:某交易所、某商业银行信用卡中心。

SRE平台架构模型如上图,资源供给层是基于数人云的PaaS平台,以Docker容器化管理做资源调动,应用调度分别基于Mesos和Marathon,目前数人云也开源了名为Swan(Mesos调度器,Github地址:https://github.com/Dataman-Cloud/swan 欢迎Star&Fork)的应用调度系统,目标是把Marathon替换掉。而后是软件技术架构层,对应公司里的架构部门,包括采用RPC框架、缓存、消息中心选型等等。

主要分享的内容在DC SRE这一层。再往上包括产品线有TISRE,也有接近于用户数使用的APP SRE,所以个人理解这是长期的建设过程。

实践—发布协调

9.png


发布协调在日常的工作中应用很多,如应用上线、变更管理。在SRE指导下,某项目现场成立了类似于发布协调的团队。成立SRE团队与金融行业系统上线特点有关:

金融行业里系统较多,包括信贷、信审等等诸多应用,系统逻辑也比较复杂。开发测试环境如物理环境完全隔离,和互联网行业不同。互联网行业,都是在线发布,测试环境也许就是生产环境,采用灰度发布或者蓝绿发布模式去做。

上线协调需要同时面对多个外包团队,外包团队人员相对不可控,导致沟通成本较高。

规模大的系统发布上线周期长。

如何解决以上问题,达到发布进入可控,降低发布失败率,缩短发布时间周期?

10.png


上述问题,在SRE的思想中,首先要建立发布协调团队。目前SRE工程师只能自行培养。团队推荐构成:项目经理、架构师、运维工程师、开发工程师。沟通方式以发布上线会议为主,不断Check系统或者产品开展工作。

11.png


团队的职责包括:审核新产品和内部服务,确保预期的性能指标和非性能指标。根据发布的任务进度,负责发布过程中技术相关问题,以及协调外包公司的开发进度等等。

最重要的是要做到发布过程中的守门员,系统是否上线要由发布协调团队决定。

12.png


团队在整个服务生命周期过程中,不同阶段,都要进行会议审核才能继续开展工作。会议根据发布的检查列表包括三个方面:架构与依赖、容量规划、发布计划。

在架构与依赖方面的逻辑架构,部署架构,包括请求数据流的顺序,检查负载均衡,日志规范着重配合监控方面的要求。同时检查第三方监控调用时是否进行测试管理等等。

容量规划主要是根据压缩报告做容量预估,以及峰值,比如微信活动比较多,所以会根据预估峰值的公司预算出来需要的资源,再落实到容器上,制定详细计划保障发布的成功率。

制定发布计划,确保成功。

13.png


在SRE的指导中,每件事都要落实到工具当中,由工具去检查每个事项是否落实到位。当时做了发布平台,包括PipeLine、Jenkins,通过其调用负载均衡上的配置F5和配置中心,以及服务注册中心的机制。所有的发布事项基于容器云平台,功能模块包括变更管理、发布管理、流程模板及发布过程监控。

14.png


上图是发布平台项目大盘图,可以看到项目在发布流程中执行情况——成功率和失败率。没有发布平台前,整个上线过程管理人员不能实时看到发布具体情况,是卡在网络还是某一个服务上,因此进度不可控。

有了这样的运维大盘后,整个发布过程能进行可视化跟踪,关键节点需要人工审核。

具体的发布步骤:

第一,检查F5里面的配置
第二,人工检查
第三,上传程序包,配置项管理
最后,重启容器再进行人工检查

整体过程都体现了SRE思想,发布平台的每个步骤均可通过界面配置完成,中间关键点由人工参与,目的是保障产品上线的成功率,避免在上线过程中手动配置产生问题,导致回滚事件发生。

15.png


有了发布协调团队后,上线的成功率、自动化程度和发布效率明显提高,减少了人肉操作落实在Jenkins、PipeLine的配置项上,降低错误发生几率。

实践—监控告警

16.png


监控作为一个垂直系统,在数人云的产品体系中举足轻重。监控的重要性深有体会,我们在某金融公司SRE团队中有1—2名监控专员,专员主要职责是维护监控系统。一个是甲方内部人员,另一个是数人云的同事。

监控主要解决的问题: 首先要及时发现,时效性很重要,因此需建立监控系统。

为什么会出现故障,要多做事故总结以及后续的故障跟踪。

17.png


上图为监控系统架构图,基于Prometheus的时序数据库,红线为监控的数据流向,因是Mesos框架,所以左边会看到Mesos运算节点上的监控项。通过容器化的Cadvisor组件收集主机和该主机所有容器的CPU和内存以及磁盘信息。告警部分使用Prometheus的Altermanager组件,支持Webhook方式,通过短信、邮件形式告警。为了事后总结,需将一些告警事件存在数据库中。

绿线主要体现在日志收集和关键字告警,日志收集通过容器化的Logstash组件,首先收集容器内部的中间件,如Tomcat等Web中间件的日志,也能收集应用日志,根据需要会把一些信息丢到Kafka里面,通过大数据平台做在线日志分析。

18.png


日志关键字告警是通过自研组件在日志传输过程中过滤关键字进行事件告警。

容器服务的健康状况通过Marathon的事件Pushgateway推到Prometheus,最后在前台以自己开发的UI查看监控信息和告警上的配置。为方便使用Prometheus的查询做统一封装,减少API使用复杂度。

19.png


在SRE体系里很明确提到了监控的4大黄金指标:延迟、流量、错误、饱和度:

延迟:监控服务的API以及URL的访问时间,直接配置某一个服务的URL,后台不断去访问,包括访问时间的预值,超过时间发出告警。

流量:负载均衡请求的连接数。

错误:监控HTTP请求返回码和日志中异常关键字。

饱和度:根据不同的系统,如内存资源性系统监控内存使用率,IO读写使用比较高,监控资源IO情况。

以上指标要在运维的过程中不断优化,如一些告警可能是网络原因进而产生其他问题,如网络交换机出现问题,直接挂掉平台的Marathon组件,应用上很明显是第三方服务调用,接连会产生很多问题,要把共性问题聚合,减少误告警次数。但减少误告警也可能会把有效告警卡掉,也值得思考。

20.png


故障跟踪和事后总结类似,人工操作会延长恢复时间,告警发生时一般由一个人处理,随着时间延长而升级策略,如超过半个小时会逐级上报调用更多的资源处理故障。在故障跟踪上解决线上问题为主,处女座强迫症为辅,做好
21.png


事故总结非常重要,解决不意味着结束,要追溯原因,如交换机重启,导致Marathon的一些问题,总结后发现,最好的解决办法是交换机重启时通知运维,停掉相关组件,交换机恢复后,再启动,如此不影响业务的实际运行。

要从失败中学习,把告警的事件做记录建立知识库,发生问题时方便检索,快速找到解决方案,要总结解决某个事故时如何更快发现问题所在,建立反馈机制,在SRE监控过程中,不断跟产品做实时反馈,包括连接池的使用情况等,鼓励主动测试,平时运维不会发生的事,尽可能想办法去看结果。

目标定位

22.png


SRE目标定位内容很多,在各个行业落地时不尽相同,所以要基于现实,拥抱变化,为了更好应对事故,坚持做推演和演练,在事故总结方面对产品做建言,故此在工具的研发上也会有决策权。
 
更多精彩文章,欢迎关注数人云公众号:

9.png

 
 

程序员工作中绕不开的9大问题,你遇到过几个?

杨y 发表了文章 • 0 个评论 • 111 次浏览 • 2017-07-28 12:23 • 来自相关话题

 
 
最近朋友圈被《北京,有2000万人在假装生活》刷屏了,特大妹昨天的文章里说,作为一个程序猿,有了BUG就没有了生活。在工作中难免会遇到各种各样的问题,今天小数就列举程序员常见的9个问题,及解题思路,我们程序员从来不假装,哼!


1以用户为中心







在开发过程中,以用户为中心不是一个选项,而是要最优先考虑的事情,要知道水能载舟亦能覆舟,如果你不以甲方粑粑为中心,那么TA可能根本不Care你开发出来的产品,所以必须以用户为中心了解他们的需求。

解决办法:

与直面用户的人交谈:想要理解用户,就需与运营人员、用户体验师、设计师去交流,他们的洞察会给你的代码指明方向。

测试版本:如苹果这样的巨头公司在正式版上线之前,通常会发布Bata版本,观察用户的反应,通过反馈完善用户体验及修复BUG。


2调试








你以为你的应用会按照你以为的那样运行吗?NO!测试童鞋拿出一长串的BUG表单在你美梦的尽头等着你:Web表单上的取消按钮无法点击、错误消息上的语法不对等等,都会导致用户体验上的问题,有些BUG很容易调试,有些则不然,会减少开发工作的时间而且让人沮丧不已。

解决办法:

重写:在此过程中,理解它们为什么发生,进而解决问题。

得到帮助:当项目的工期将尽,很多程序员往往先恐慌后才去思考,如果没时间重写,可以让测试人员帮助一起调试。


3掌握最IN技术







俗话说:“落后就要挨打”,技术在不断发展,现有框架、工具、库等可能会很快过时,如前端框架通常1—2年就会更新迭代,从某种意义上说,新版本更高效使工作更容易,但也需要时间去适应。


解决办法:

花时间学习新系统:每天挤出20—30分钟的时间学习新工具的工作方式,如果认为新版本(工具)可以更好地工作,那么在业余时间去学习如何使用以改进工作流程。

跟上最新的趋势:将阅读作为每天必做的事情,哪怕工作繁忙,新趋势带来的帮助意义非凡,可以开发出更多的创新产品。


4沟通







程序员们大都是Shy Boy,换了新的工作和环境后和周遭同事不熟,会犹豫是否要与他们进行沟通,从代码到公司等等,很多程序员在某个时刻都面临着这个问题,不要觉得只要把自己的任务完成就没问题了,它可能会引发一些冲突。


解决办法:

积极主动:不要害怕向同事提问,尤其是在工作中遇到的任何问题,当向别人敞开心扉,也会更快地适应公司的文化,如果十分内向,那么提升自信是必须要做的事情。

提炼语言:有时候表达的不够准确直接,进而无法阐述问题,要从中吸取经验,练习话术,争取下次做的更好。

学习&分享:目前技术类型的线下活动越来越多,曾经很多害羞的程序员小伙伴都走上台分享技术经验同时也有不少善于总结的人开通了技术专栏,粉丝无数,惊不惊喜?开不开心?不如行动吧。

5时间预估






作为报价和项目时间表的基础,预估在开发中非常重要,程序员会被要求提供如调试代码在Sprint中完成某些特性工作所需的时间。你想获得更多的时间完成一项任务,给老板留下好印象,同时也提升了应用质量,不过你的团队可能会是另外一种看法,因为这样会拖慢进度。

解决办法:

分解任务:将任务进行拆分,是更容易和更好的管理办法,测试只在你工作中发现了十几个错误吗?将每个BUG看做一个迷你的任务,并预估完成每项任务可能需要花费的时间。

预留时间:给每个任务设定完成的时间框架,不过也要给自己一个缓冲,如任务通常需要20分钟,那么在将时间框架设定为30分钟。


6持续久坐






在开发过程中,长时间坐着也是工作的一部分,腰酸背痛腿抽筋这些毛病可能会来找你的麻烦,研究表明,每天坐5个小时以上会产生严重的健康风险,如心脑血管疾病和肥胖症(不禁摸了摸小肚腩),同时也会让人在白天感到更困倦。

解决办法:

站起来:站着工作可以减轻背部压力,改善血液循环,让人有效地进行工作,一些企业甚至投资于高度可调的办公桌,让员工更容易站着工作。

做运动:程序员会经常感到疲倦,没有动力,为了缓解压力,让身体接受一些锻炼,即便是工作前30分钟的散步或慢跑也能让人一整天工作得更好,如果没有时间,那就散散步,吃点东西或喝杯咖啡。


7安全问题







数据的价值极高,很多人愿意为数据花费很高的代价,(小数已经天天被推销、骚扰电话烦死惹。)而且竞争对手想窥探正在开发的秘密项目(如市场营销或企业软件)。

作为程序员,是保证客户信息不受威胁的依靠,但很多程序员将关注点放在代码的正确性而不是安全性上,黑客知道这一弱点,并一直在寻找渗透方式。

解决办法:

为SQL注入参数化查询:攻击者可以使用SQL注入来窃取数据,如用户的登录信息,为防止这种攻击,应在编程语言中使用参数化查询。

保持工作站安全:有威胁者未必在网上,如被解雇的员工可能会通过系统窃取或修改一个项目的数据报复老板,所以在使用完应用后,要从软件中注销。


8善用代码






程序员在某些时候不得不为别人创造的项目工作,如在开发时中需要编写另外一个开发人员编写的代码。

之前的程序员没向任何人交接工作就拍拍屁股走人离职了,或者虽然在职但忙的焦头烂额无法回答任何问题,最坏的情况是办公室政治,他们不愿意帮你弄清楚代码。


解决办法:

善用遗留代码:需要转变态度,如果有人将代码留下来,那么这些代码就是你的工作了。

花更多的时间阅读代码:花一些时间了解其他开发人员的工作、方法和风格,一旦完成这一操作,将会更容易适应。


9学会规划代码







得到新工作,想证明自己获得良好的第一印象,所以急于地找键盘,敲代码,但那些代码在你脑海里可能是有意义的,却与实际方向背道而驰。

解决办法:

从一个想法开始:每个应用都以一个想法开始,如你想要开发的应用可以提醒用户的约会时间,如此,可以让你更专注地写所要代码。

使用思维导图找出用户问题:有了想法后将它画出来,从产品将要解决的问题开始,把想法写在纸上,并为它创建子主题,如想法是用于提醒约会的应用,那么子主题可能就是用户需要它的原因(如:用户有太多的约会要留意。)
 
 
更多精彩文章:欢迎关注数人云公众号





  查看全部
 
 
最近朋友圈被《北京,有2000万人在假装生活》刷屏了,特大妹昨天的文章里说,作为一个程序猿,有了BUG就没有了生活。在工作中难免会遇到各种各样的问题,今天小数就列举程序员常见的9个问题,及解题思路,我们程序员从来不假装,哼!


1以用户为中心

1.jpg



在开发过程中,以用户为中心不是一个选项,而是要最优先考虑的事情,要知道水能载舟亦能覆舟,如果你不以甲方粑粑为中心,那么TA可能根本不Care你开发出来的产品,所以必须以用户为中心了解他们的需求。

解决办法:

与直面用户的人交谈:想要理解用户,就需与运营人员、用户体验师、设计师去交流,他们的洞察会给你的代码指明方向。

测试版本:如苹果这样的巨头公司在正式版上线之前,通常会发布Bata版本,观察用户的反应,通过反馈完善用户体验及修复BUG。


2调试


2.jpg



你以为你的应用会按照你以为的那样运行吗?NO!测试童鞋拿出一长串的BUG表单在你美梦的尽头等着你:Web表单上的取消按钮无法点击、错误消息上的语法不对等等,都会导致用户体验上的问题,有些BUG很容易调试,有些则不然,会减少开发工作的时间而且让人沮丧不已。

解决办法:

重写:在此过程中,理解它们为什么发生,进而解决问题。

得到帮助:当项目的工期将尽,很多程序员往往先恐慌后才去思考,如果没时间重写,可以让测试人员帮助一起调试。


3掌握最IN技术


3.jpg


俗话说:“落后就要挨打”,技术在不断发展,现有框架、工具、库等可能会很快过时,如前端框架通常1—2年就会更新迭代,从某种意义上说,新版本更高效使工作更容易,但也需要时间去适应。


解决办法:

花时间学习新系统:每天挤出20—30分钟的时间学习新工具的工作方式,如果认为新版本(工具)可以更好地工作,那么在业余时间去学习如何使用以改进工作流程。

跟上最新的趋势:将阅读作为每天必做的事情,哪怕工作繁忙,新趋势带来的帮助意义非凡,可以开发出更多的创新产品。


4沟通


4.jpg


程序员们大都是Shy Boy,换了新的工作和环境后和周遭同事不熟,会犹豫是否要与他们进行沟通,从代码到公司等等,很多程序员在某个时刻都面临着这个问题,不要觉得只要把自己的任务完成就没问题了,它可能会引发一些冲突。


解决办法:

积极主动:不要害怕向同事提问,尤其是在工作中遇到的任何问题,当向别人敞开心扉,也会更快地适应公司的文化,如果十分内向,那么提升自信是必须要做的事情。

提炼语言:有时候表达的不够准确直接,进而无法阐述问题,要从中吸取经验,练习话术,争取下次做的更好。

学习&分享:目前技术类型的线下活动越来越多,曾经很多害羞的程序员小伙伴都走上台分享技术经验同时也有不少善于总结的人开通了技术专栏,粉丝无数,惊不惊喜?开不开心?不如行动吧。

5时间预估

5.jpg


作为报价和项目时间表的基础,预估在开发中非常重要,程序员会被要求提供如调试代码在Sprint中完成某些特性工作所需的时间。你想获得更多的时间完成一项任务,给老板留下好印象,同时也提升了应用质量,不过你的团队可能会是另外一种看法,因为这样会拖慢进度。

解决办法:

分解任务:将任务进行拆分,是更容易和更好的管理办法,测试只在你工作中发现了十几个错误吗?将每个BUG看做一个迷你的任务,并预估完成每项任务可能需要花费的时间。

预留时间:给每个任务设定完成的时间框架,不过也要给自己一个缓冲,如任务通常需要20分钟,那么在将时间框架设定为30分钟。


6持续久坐

6.jpg


在开发过程中,长时间坐着也是工作的一部分,腰酸背痛腿抽筋这些毛病可能会来找你的麻烦,研究表明,每天坐5个小时以上会产生严重的健康风险,如心脑血管疾病和肥胖症(不禁摸了摸小肚腩),同时也会让人在白天感到更困倦。

解决办法:

站起来:站着工作可以减轻背部压力,改善血液循环,让人有效地进行工作,一些企业甚至投资于高度可调的办公桌,让员工更容易站着工作。

做运动:程序员会经常感到疲倦,没有动力,为了缓解压力,让身体接受一些锻炼,即便是工作前30分钟的散步或慢跑也能让人一整天工作得更好,如果没有时间,那就散散步,吃点东西或喝杯咖啡。


7安全问题


7.jpg


数据的价值极高,很多人愿意为数据花费很高的代价,(小数已经天天被推销、骚扰电话烦死惹。)而且竞争对手想窥探正在开发的秘密项目(如市场营销或企业软件)。

作为程序员,是保证客户信息不受威胁的依靠,但很多程序员将关注点放在代码的正确性而不是安全性上,黑客知道这一弱点,并一直在寻找渗透方式。

解决办法:

为SQL注入参数化查询:攻击者可以使用SQL注入来窃取数据,如用户的登录信息,为防止这种攻击,应在编程语言中使用参数化查询。

保持工作站安全:有威胁者未必在网上,如被解雇的员工可能会通过系统窃取或修改一个项目的数据报复老板,所以在使用完应用后,要从软件中注销。


8善用代码

8.jpg


程序员在某些时候不得不为别人创造的项目工作,如在开发时中需要编写另外一个开发人员编写的代码。

之前的程序员没向任何人交接工作就拍拍屁股走人离职了,或者虽然在职但忙的焦头烂额无法回答任何问题,最坏的情况是办公室政治,他们不愿意帮你弄清楚代码。


解决办法:

善用遗留代码:需要转变态度,如果有人将代码留下来,那么这些代码就是你的工作了。

花更多的时间阅读代码:花一些时间了解其他开发人员的工作、方法和风格,一旦完成这一操作,将会更容易适应。


9学会规划代码


9.jpg


得到新工作,想证明自己获得良好的第一印象,所以急于地找键盘,敲代码,但那些代码在你脑海里可能是有意义的,却与实际方向背道而驰。

解决办法:

从一个想法开始:每个应用都以一个想法开始,如你想要开发的应用可以提醒用户的约会时间,如此,可以让你更专注地写所要代码。

使用思维导图找出用户问题:有了想法后将它画出来,从产品将要解决的问题开始,把想法写在纸上,并为它创建子主题,如想法是用于提醒约会的应用,那么子主题可能就是用户需要它的原因(如:用户有太多的约会要留意。)
 
 
更多精彩文章:欢迎关注数人云公众号

9.png

 

从0到1,打造DevOps易用工具链(精挑细选27种)

杨y 发表了文章 • 0 个评论 • 130 次浏览 • 2017-07-28 12:17 • 来自相关话题

数人云:DevOps是一种文化,但创立或改变文化技术和工具必不可少,今天小数就和大家分享下覆盖整个生命周期的易用工具链。

DevOps操作上越来越成熟不是一蹴而就的,而是使用了一些新的工具,在团队内不仅改变了文化,同时也打破了沟通上的壁垒,进而开发出更好的应用,虽然仅靠工具还不够,但通过应用自动化,在提高了交付效率和质量的同时也促进了成员之间的协作。

对于如何构建DevOps工具链,没有标准的答案,而是要取决于团队规模和具体需求,这里从Netflix、Etsy,Dropbox等公司汲取了相关经验,分享一些在应用交付生命周期的每个阶段,一些受欢迎的工具。






构建工具
〓 项目管理

瀑布式开发要规划出所有的工作和每个版本的依赖关系,这与DevOps理念背道而驰,而敏捷开发,可以通过构建、测试应用收集用户反馈来降低风险提高可见性,这也是许多团队在Sprint(敏捷开发的四种会议)提出构建到发布用2—4周的时间。

当团队在每个Sprint时分享想法和计划时,要考虑之前Sprint的回顾反馈,不断优化方案。此后将这些构思上传到一些工具当中,可以跟踪项目的整体和每日进度。推荐的工具有:

Active Collab:基于Web、开源的协作开发与项目管理工具,可以利用它轻松地搭建一个包括团队和项目客户能够 在同一个项目上实现相互协作的环境

VersionOne:支持SaaS模式和本地安装模式,web客户端,支持Scrum, Extreme Programming, DSDM and Agile UP等多种敏捷开发方法。 Jira:被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

Trello:由著名的软件工程师 Joel Spolsky 开发工作围绕“木板(board)”进行,同一小组的用户可以在这里创建待办事项列表(to do list)、创建任务,并分配给同事。

〓 代码&SCM系统

所有的构建都可以用代码来表示,在上线之前,需要测试和复查,并将其合并到一个版本控制库中的主分支当中,并在可以进行任何本地测试,推荐工具有:

GitHub:GitHub是一个基于web的Git或版本控制库。

Gitlab:提供了Git仓库管理、代码审查、问题跟踪、活动反馈和wiki。

Bitbucket:源代码托管网站,采用Mercurial和Git作为分布式版本控制系统。

〓 CI平台

持续集成(CI)是现代软件开发的最佳实践,通过建立有效的持续集成环境可以减少集成问题、提高代码质量、改善团队成员之间的沟通和协作、快速迭代等,推荐的工具和平台有:

Jenkins:基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。

CodeShip:部署快,易损耗、成本低。易用性比肩Travis,而更胜一筹的是集成了相当数量的选项,可以根据自身的工作流程和开发工具定制化CI/CD工作流。

Bamboo:具有开箱即用的特性,可在硬件上运营。Bamboo是一个聚焦企业级的解决方案,并且包含具有极强竞争力的特性、定价和技术支持等。可以部署在大规模生产环境中。

CodeFresh:虽然CodeFresh不是典型的CI/CD平台,但它提供了一种有趣的应用场景,在容器上使用CI/CD从而促进Docker,Kubernetes和云原生的发展前景。

〓 测试

为了实现DevOps所需的业务目标,为确保将代码推向生产是安全的,需要进行大量测试:单元测试、集成测试、验收测试等,测试完成后,还有大量开源和付费工具可以做一些其他事情,推荐的工具有:

JUnit:一个用于编写可重复测试的简单框架。

Mocha:简单、灵活有趣的JavaScript测试框架。

CircleCi:Web应用程序开发测试平台。

发布工具
〓 自动化部署

发布自动化工具应具备例如自动回滚等功能,在开始部署之前将模块复制到主机,如果企业规模较大,可以轻松地安装代理并将防火墙配置到服务器实例中。

许多团队还使用基于聊天的部署工作流,让机器人部署简单的命令。推荐的工具有:

Bamboo:采用自动化管理的构建代理模式,运行在各种专用服务器或云服务器上的代理实现了构建能力的即时动态扩展。通过与Jira集成可以实现完整的发布流程

Puppet:一个开源的软件自动化配置和部署工具,基于C/S架构的。服务器端保存着所有对客户端服务器的配置代码,在Puppet里面叫Manifest,客户端下载Manifest之后,可以根据Manifest对服务器进行配置,例如软件包管理,用户管理和文件管理等等。

Superviso:一个客户/服务器系统,允许用户监控和控制类似Unix的操作系统上的许多进程。

Forever:简单的CLI工具,用于确保给定的脚本连续运行。

监控工具
〓 部署监控

部署监控让高级别的发布进入和需求状态可视化,是理解服务健康与否的关键,确保CI服务器上发生的关键事件并及时告警。推荐的工具有:

Datadog:专门针对 DevOps 团队,从APP或者其他各种工具获取数据并提供数据可视化功能。将从基础设备和应用采集的数据统一处理并存储。

ElasticStack:一系列开源产品的合集,包括 Elasticsearch、Kibana、Logstash以及 Beats 等等,提供了很多数据分析领域的功能,如 Pipeline Aggregation。

〓 服务器监控

服务器监控提供了一个基础结构级别的视图,许多团队还使用日志聚合来深入研究特定问题,可以聚合及度量如:内存、CPU、负载均衡等,使工程师能在问题发生时迅速做出响应。推荐的工具有:

PagerDuty:能够在服务器出问题时发送提醒的软件。在发生问题时,提醒的方式包括屏幕显示、电话呼叫、短信通知、电邮通知等,而且在无人应答时还会自动将提醒级别提高。

Nagios:是一款开源的免费网络监视工具,能有效监控Windows、Linux和Unix的主机状态,交换机路由器等网络设备,打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员

Solarwinds:主要提供企业的网络管理和监控,可以帮助网管进行配置,监控和管理日趋复杂的系统和构建网络基础构架的流程。

〓 应用性能监控

应用性能监控为应用和业务服务的性能及可用性提供了代码级的可见性,让快速理解性能指标和满足服务SLA更加轻松。推荐的工具有:

DynaTrace:在整个生命周期过程中会对Web和非Web业务关键应用程序的监控、管理和优化方式进行转换。可快速解析性能问题并将问题范围隔离定位到确切的代码行。

AppDynamics:能提供端到端的、可视化驱动管理的的平台。核心理念是SEE可视化、ACT快速解决还有KNOW实时分析。

终极工具
〓 云

云计算目前的主要厂商是亚马逊的AWS、微软的Azure、Google的(GCP)。在PaaS层,可以访问和创建如数据库和分析之类的应用服务且不用考虑如操作系统、防火墙配置或存储之类的基础设施。

〓 Docker

Docker是一个开放的平台,将开发、传输和运行在容器这种隔离的环境中。容器封装了专用的文件系统、存储、CPU、RAM和其他需求的应用,保证这些应用在不虚拟化硬件的情况下持续运行且保持一致。Docker是可移植的、轻量级的,很容易进行安装。

〓 Swan

数人云Swan是基于Mesos实现的开源应用调度框架,帮助用户轻松发布应用,实现应用的滚动更新,并根据用户指定的策略做应用的健康检测和故障转移。

Swan Github地址 欢迎Star&Fork 查看全部
数人云:DevOps是一种文化,但创立或改变文化技术和工具必不可少,今天小数就和大家分享下覆盖整个生命周期的易用工具链。

DevOps操作上越来越成熟不是一蹴而就的,而是使用了一些新的工具,在团队内不仅改变了文化,同时也打破了沟通上的壁垒,进而开发出更好的应用,虽然仅靠工具还不够,但通过应用自动化,在提高了交付效率和质量的同时也促进了成员之间的协作。

对于如何构建DevOps工具链,没有标准的答案,而是要取决于团队规模和具体需求,这里从Netflix、Etsy,Dropbox等公司汲取了相关经验,分享一些在应用交付生命周期的每个阶段,一些受欢迎的工具。

1.png


构建工具
〓 项目管理

瀑布式开发要规划出所有的工作和每个版本的依赖关系,这与DevOps理念背道而驰,而敏捷开发,可以通过构建、测试应用收集用户反馈来降低风险提高可见性,这也是许多团队在Sprint(敏捷开发的四种会议)提出构建到发布用2—4周的时间。

当团队在每个Sprint时分享想法和计划时,要考虑之前Sprint的回顾反馈,不断优化方案。此后将这些构思上传到一些工具当中,可以跟踪项目的整体和每日进度。推荐的工具有:

Active Collab:基于Web、开源的协作开发与项目管理工具,可以利用它轻松地搭建一个包括团队和项目客户能够 在同一个项目上实现相互协作的环境

VersionOne:支持SaaS模式和本地安装模式,web客户端,支持Scrum, Extreme Programming, DSDM and Agile UP等多种敏捷开发方法。 Jira:被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

Trello:由著名的软件工程师 Joel Spolsky 开发工作围绕“木板(board)”进行,同一小组的用户可以在这里创建待办事项列表(to do list)、创建任务,并分配给同事。

〓 代码&SCM系统

所有的构建都可以用代码来表示,在上线之前,需要测试和复查,并将其合并到一个版本控制库中的主分支当中,并在可以进行任何本地测试,推荐工具有:

GitHub:GitHub是一个基于web的Git或版本控制库。

Gitlab:提供了Git仓库管理、代码审查、问题跟踪、活动反馈和wiki。

Bitbucket:源代码托管网站,采用Mercurial和Git作为分布式版本控制系统。

〓 CI平台

持续集成(CI)是现代软件开发的最佳实践,通过建立有效的持续集成环境可以减少集成问题、提高代码质量、改善团队成员之间的沟通和协作、快速迭代等,推荐的工具和平台有:

Jenkins:基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。

CodeShip:部署快,易损耗、成本低。易用性比肩Travis,而更胜一筹的是集成了相当数量的选项,可以根据自身的工作流程和开发工具定制化CI/CD工作流。

Bamboo:具有开箱即用的特性,可在硬件上运营。Bamboo是一个聚焦企业级的解决方案,并且包含具有极强竞争力的特性、定价和技术支持等。可以部署在大规模生产环境中。

CodeFresh:虽然CodeFresh不是典型的CI/CD平台,但它提供了一种有趣的应用场景,在容器上使用CI/CD从而促进Docker,Kubernetes和云原生的发展前景。

〓 测试

为了实现DevOps所需的业务目标,为确保将代码推向生产是安全的,需要进行大量测试:单元测试、集成测试、验收测试等,测试完成后,还有大量开源和付费工具可以做一些其他事情,推荐的工具有:

JUnit:一个用于编写可重复测试的简单框架。

Mocha:简单、灵活有趣的JavaScript测试框架。

CircleCi:Web应用程序开发测试平台。

发布工具
〓 自动化部署

发布自动化工具应具备例如自动回滚等功能,在开始部署之前将模块复制到主机,如果企业规模较大,可以轻松地安装代理并将防火墙配置到服务器实例中。

许多团队还使用基于聊天的部署工作流,让机器人部署简单的命令。推荐的工具有:

Bamboo:采用自动化管理的构建代理模式,运行在各种专用服务器或云服务器上的代理实现了构建能力的即时动态扩展。通过与Jira集成可以实现完整的发布流程

Puppet:一个开源的软件自动化配置和部署工具,基于C/S架构的。服务器端保存着所有对客户端服务器的配置代码,在Puppet里面叫Manifest,客户端下载Manifest之后,可以根据Manifest对服务器进行配置,例如软件包管理,用户管理和文件管理等等。

Superviso:一个客户/服务器系统,允许用户监控和控制类似Unix的操作系统上的许多进程。

Forever:简单的CLI工具,用于确保给定的脚本连续运行。

监控工具
〓 部署监控

部署监控让高级别的发布进入和需求状态可视化,是理解服务健康与否的关键,确保CI服务器上发生的关键事件并及时告警。推荐的工具有:

Datadog:专门针对 DevOps 团队,从APP或者其他各种工具获取数据并提供数据可视化功能。将从基础设备和应用采集的数据统一处理并存储。

ElasticStack:一系列开源产品的合集,包括 Elasticsearch、Kibana、Logstash以及 Beats 等等,提供了很多数据分析领域的功能,如 Pipeline Aggregation。

〓 服务器监控

服务器监控提供了一个基础结构级别的视图,许多团队还使用日志聚合来深入研究特定问题,可以聚合及度量如:内存、CPU、负载均衡等,使工程师能在问题发生时迅速做出响应。推荐的工具有:

PagerDuty:能够在服务器出问题时发送提醒的软件。在发生问题时,提醒的方式包括屏幕显示、电话呼叫、短信通知、电邮通知等,而且在无人应答时还会自动将提醒级别提高。

Nagios:是一款开源的免费网络监视工具,能有效监控Windows、Linux和Unix的主机状态,交换机路由器等网络设备,打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员

Solarwinds:主要提供企业的网络管理和监控,可以帮助网管进行配置,监控和管理日趋复杂的系统和构建网络基础构架的流程。

〓 应用性能监控

应用性能监控为应用和业务服务的性能及可用性提供了代码级的可见性,让快速理解性能指标和满足服务SLA更加轻松。推荐的工具有:

DynaTrace:在整个生命周期过程中会对Web和非Web业务关键应用程序的监控、管理和优化方式进行转换。可快速解析性能问题并将问题范围隔离定位到确切的代码行。

AppDynamics:能提供端到端的、可视化驱动管理的的平台。核心理念是SEE可视化、ACT快速解决还有KNOW实时分析。

终极工具
〓 云

云计算目前的主要厂商是亚马逊的AWS、微软的Azure、Google的(GCP)。在PaaS层,可以访问和创建如数据库和分析之类的应用服务且不用考虑如操作系统、防火墙配置或存储之类的基础设施。

〓 Docker

Docker是一个开放的平台,将开发、传输和运行在容器这种隔离的环境中。容器封装了专用的文件系统、存储、CPU、RAM和其他需求的应用,保证这些应用在不虚拟化硬件的情况下持续运行且保持一致。Docker是可移植的、轻量级的,很容易进行安装。

〓 Swan

数人云Swan是基于Mesos实现的开源应用调度框架,帮助用户轻松发布应用,实现应用的滚动更新,并根据用户指定的策略做应用的健康检测和故障转移。

Swan Github地址 欢迎Star&Fork

关于CI的服务器与最佳实践,这里有一些思考

杨y 发表了文章 • 0 个评论 • 130 次浏览 • 2017-07-25 19:12 • 来自相关话题

CI是敏捷和DevOps关键性的一步,数人云最近给大家分享了《致:正在选择CI平台的你(10大要素需把控)》今天的文章将讨论如何使用CI服务器创建高质量产品以及相关扩展插件和指标度量。最后针对业内标准规则进行了自我思考。

CI服务器

拥有自动化的构建系统,是实现CI唯一强制性要求。但在实践中,除了自动化构建系统外,还可以安装和配置“CI服务器”。

概述

CI服务器是大脑,在幕后工作,无缝地将各种行业标准实践整合到CI实现过程中。

下图是个典型的CI工作流,包含6个阶段,从代码检入开始,直到向企业内不同的人员提供反馈信息。







启动过程

通常,开发人员将代码签入源存储库时,CI流程就会启动。

CI工作流也可以通过其他方式触发,下面列举几个方法——
手动:用户通过CI服务器管理控制台或脚本手动执行时。
计划:预先配置的时间表,如某个夜间构建。
触发:每次提交到源代码版本控制系统。
夜间构建通常会对代码执行更大检查和更久时间。

获取最新代码

流程的第二步,CI服务器从源控件获取最新代码,可以通过轮询或推送机制实现。
在轮询机制中,CI服务器配置为源控制服务器,不断地在固定时间间隔内对给定的位置进行轮询,检测任何新的代码更改,一旦检测到,会从源控制服务器下载最新的代码副本到磁盘上。

推送机制中,源控制系统由一个:“钩子”提供给CI服务器,当开发者向提交更改时,调用“钩子”,并让CI服务器了解更改是可用的。
构建
源代码一般独立于构建,即必要的构建脚本与源代码共存,最新的代码在前面步骤中被详细地获取,绑定的脚本会触发构建。

对于Java项目,通常构建自动化脚本使用Maven或分级。使用不支持内置依赖管理的构建系统并不常见,在不需要依赖管理的情况下,Make 使用了在Unix系统中广泛使用的构建机制。
有很多构建工具可以使用,Wiki列出了一些:(https://en.wikipedia.org/wiki/ ... tware)

执行测试

在此过程中执行单元测试和集成测试,这些测试和代码一般捆绑在一起。

基于Java的系统,测试使用类似于Junit的测试框架执行,允许对测试依赖项进行简单的模拟。

某些编程技术自带测试运行器框架,如Spring的Spring Junit运行器、Java EE中的Arquillian等。

在CI服务器上运行测试有以下几点:
曾经遇到过测试在一台机器上传递,但在另一台上失效的情况吗?通过在集中的服务器上运行测试,消除了测试环境的问题。

测试会立即执行每个更改,若有代码破坏预期行为能被快速发现。

很多团队并行处理特性,甚至团队成员在全球范围内分布,每次开发者向存储库提交代码,任何故障都能即刻识别和修复。
结果
CI过程的最后有两种结果:构建和测试失败或通过。

每个嵌入都是经过验证的,并且确保不会破坏现有的代码,代码被合并到主干中,会被构建和测试,允许减少主线代码被破坏的时间。

一般情况下,CI服务器失败会发送电子邮件(给整体团队或只负责以前签入的人),可以快速看到失败的状况,并且尽快采取纠正措施。

CI服务器还凸显了最近构建的状态,以及最近几个构建在红-绿-琥珀光指示器上的状态,例如,Jenkins使用了下面的构建指示器:







CI服务器插件

上一节介绍了CI的基本工作流程,但大多数企业会使用它完成更多任务,通过安装各种插件扩展CI服务器,开拓行为,下面介绍一些常用的扩展:

技术债务与代码质量

在应用中引入的任何变化都会增加系统复杂和无序性被称之为“技术债务”,当新代码引入系统时会增加技术债务,如果被忽视太久,越来越多的新功能被紧凑的最后期限所填满,此时想要在可控范围内几乎不可能,这将对应用的生产效率和可维护性造成负面影响。

迭代开发、自动化检测、和CI的使用来监控每个签入技术债务是控制技术债务的唯一方法。

如SonarQube工具,采用识别代码质量和跟踪技术债务的开源平台,可以轻松地集成到任何CI服务器中,为技术债务提供实时数据。

其不仅仅衡量技术债务,也度量并涵盖了代码质量的7个核心:







SonarQube在简单的WEB中展现分析结果,是非常有用的工具,不仅是开发者,对于管理其他非技术的人也是如此。 













了解更多请参考:
管理技术债务:http://softwareyoga.com/managing-technical-debt/
Sonarqube:https://www.sonarqube.org/
Codacy:https://www.codacy.com/
语义

对于开发者来说,引入CI在另一个重要的方面非常具有价值——可以衡量代码质量——语义及常见的反模式。

静态代码工具可以作为CI过程的一部分,以深入了解代码的健康度,历史数据也可以存储,从而在一段时间内提供质量度量。可以为两个提交作比较,确定每个提交的债务度量标准。

很多工具可以静态地分析代码并计算质量度量的多样性,同时可以被集成到CI服务器中自动运行,例如:
CheckstyleFindbugsSonar
更详尽地工具请参考:https://en.wikipedia.org/wiki/ ... lysis

代码评审

开发者在特性分支上工作,并尽可能频繁地提交代码。

代码分析工具(如:Sonar)可以在CI服务器中执行自动代码检测,然后每个开发者负责处理提交时生成的评论注释。

自动代码审查基于一组预定义的规则,是发现潜在技术问题很好的方法,这些规则可以从主流的开发语言中下载。

解决了自动化评审意见,会进行同行代码评审,捕捉那些不能用自动化审查的问题,如验证业务需求、体系结构问题、代码易读性、扩展性等。

如果有一定数量的人没对代码进行审查,CI服务器可以配置成阻止对主线分支任何的提交,常见办法是在主线分支中强制要求每个提交至少2个审核员,Java的项目中,常见工具是Gerrit。

更多代码审核工具请参考:https://en.wikipedia.org/wiki/ ... eview

Headless Testing

若想在CI服务器上运行UI测试,必须依赖于Headless(Headless:在缺少显示屏、键盘或者鼠标时的系统配置)测试,因为浏览器没有显示,这意味着要在没有图形用户界面的情况下运行UI测试,需要类似于流行WEB浏览器的Headless浏览器,通过命令行界面执行,并具有UI元素的内存模式。内存中的模型用于模拟UI交互,如,在UI中单击一个按钮即可模拟内存中的模型对象。

Selenium测试工具可以用于无头测试,如Phantom JS的Headless浏览器也被广泛应用,在构建中引入这些测试,CI服务器能够验证失败的UI。

安装CI服务器

CI服务器主要有三种:
独立托管私有云
独立的CI服务器安装在一台机器上进行,通常用于小型项目或少于10人的开发团队。

托管的CI服务器可以在公有云上使用,大多数情况下,都与CI服务器可以访问的基于云的源控制系统相连接。这些公司都不希望维护CI或无法维护的公司使用,对于中等规模的团队,是非常可行的选择。

私有云是想要完全控制和基于安全考虑的大公司使用的,多个CI服务器代理配置在高性能服务器的集合中,以支持数百个开发者繁重工作负载。

一些被广泛使用的CI服务器:
JenkinsTravis CITeamCityCruiseControl
更多CI服务器请参考:https://en.wikipedia.org/wiki/ ... tware

CI最佳实践

Martin Fowler(国际著名面向对象分析设计、UML、模式等方面的专家,敏捷开发方法的创始人之一)在他关于CI的白皮书中提到了为任何CI设置的一些关键实践。这些建议已经成为多年来CI的最佳实践。

这里将根据文章作者的见解来审视每一种最佳实践。

维护单个源存储库

“提倡使用版本控制系统实现项目的源代码,所有与构建项目相关的都应存放在存储库中,在此实践中,约定系统应该从一个新的签出中构建,不需要额外依赖项,极限开发倡导者Martin Fowler提到,在使用工具支持分支的情况下,应尽量减少分支的使用,更倾向于进行集成而不是同时维护多个版本的应用,主线(或主干),应该是应用的工作版本。”

提示

原则并非一定按照字面上只需一个单一的存储库,关键是拥有在存储库中构建项目所需的所有相关工件,该项目应该从一个新的签出中进行构建,而不需要额外的依赖项或手动步骤。

“项目”的定义取决于自身,如果代码库很小,或者代码所构建的逻辑模块组件,那么就意味着是完整可交付的产品。

观点

实践中建议不要在版本控制系统中使用分支,相反,建议只开发项目的某个分支,且让其一直处于开发阶段。

本文作者不同意这种说法,在多数企业中,有许多分支需要同时并行开发,企业需要支持产品的前一个版本,修复BUG,而其他团队成员则开始着手下一个版本的工作,所以需要在代码库中使用多个分支。

自动化构建

“单个命令应该具备构建系统的能力,许多构建工具如Make,已经存在多年,其他近期的工具经常用于CI环境中,构建的自动化应该包括自动化集成,包括部署到类似产品的环境中,在许多情况下构建本本不仅编译二进制文件,还生成文档、网站页面、统计信息和分发介质(如Debian DEB、Red Hat RPM或Windows MSI文件)”

提示

构建的自动化应该包括:编译代码、执行单元测试和集成测试,以及许多工具——代码质量检测、语义检测、测量技术债务等,多数现代构建工具都支持这些额外集成,并且用于开发CI环境。

在实际项目中,不同的团队负责开发系统不同部分,都有自己的存储库,因此这种情况几乎不可能发生,将整个产品进行自动化构建没有必要,为系统单独部分开发构建自动化就足够。

观点

定义CI的目的除了自动化构建过程外,是否还有投资CI的意思?作为CI的一部分,打算度量哪些标准?很多人将CI设置看做开发者的工具。

CI不是敏捷或DevOps,只是整体过程的工具之一,敏捷或DevOps已经超越了开发技术层面,升华成一种文化。

构建自测

“构建代码后,所有测试都应运行以确认它如开发者的预期一样。”

提示

代码至少要包含单元测试,如Junit框架可以模拟依赖关系。

特定组件与其他模块是不应该交互的,要确保独立运行。

观点

单元测试应该测试行为,而不是实现细节,例如,不要去在乎如何计算汽车的速度,只要使用的方法和工具是正确的即可。

许多测试框架允许断言模拟对象,如测试模拟对象是否被调用,是否在特定的参数中传递等,除非测试实现本身是主要关注点,否则应将其弱化。

保持快速构建

“构建需要快速完成,因此如果集成有问题,会很快被识别。”








提示

应该以更快地执行测试为目标,所以需要做比其他类型更多的单元测试。

避免在单元测试中使用数据库,如果可以,也要必满在集成测试中使用。通常需要集成测试使用另一种数据源,指向内存中的数据库。如果不可避免,每次测试前都需刷新数据库,确保数据处于已知状态,并且测试会以一致的数据开始。

注意

不要依赖大量的UI测试,其非常脆弱,需要大量维护,建议使用如Selenium类似的UI测试框架来缓解UI测试的一些问题,如屏幕上更改UI元素的位置、处理UI事件等。

自动化部署

“很多CI系统允许在构建完成后运行脚本,可以编写一个脚本将应用部署到每个人都可以查看的实时测试服务器上,此种思维方式进一步发展是CD(持续部署),要求将应用直接部署到生产中,需要额外的自动化防止BUG和回滚。”

观点

不是所有的项目都需要自动化部署,如果生产站点是由同一家公司托管,那么在CD中投资更加有利,CD是CI的下一个逻辑步骤。

不是所有提交的结果都是可交付的产品,在敏捷社区中每个构建都是可交付的产品是常见的误解,可交付的产品与工作应用是不同的概念。

原文作者:Deepak Karanth 
原文链接:https://dzone.com/articles/con ... tices 查看全部


头图.jpg



CI是敏捷和DevOps关键性的一步,数人云最近给大家分享了《致:正在选择CI平台的你(10大要素需把控)》今天的文章将讨论如何使用CI服务器创建高质量产品以及相关扩展插件和指标度量。最后针对业内标准规则进行了自我思考。

CI服务器

拥有自动化的构建系统,是实现CI唯一强制性要求。但在实践中,除了自动化构建系统外,还可以安装和配置“CI服务器”。

概述

CI服务器是大脑,在幕后工作,无缝地将各种行业标准实践整合到CI实现过程中。

下图是个典型的CI工作流,包含6个阶段,从代码检入开始,直到向企业内不同的人员提供反馈信息。

1.jpg



启动过程

通常,开发人员将代码签入源存储库时,CI流程就会启动。

CI工作流也可以通过其他方式触发,下面列举几个方法——
手动:用户通过CI服务器管理控制台或脚本手动执行时。
计划:预先配置的时间表,如某个夜间构建。
触发:每次提交到源代码版本控制系统。
夜间构建通常会对代码执行更大检查和更久时间。

获取最新代码

流程的第二步,CI服务器从源控件获取最新代码,可以通过轮询或推送机制实现。
在轮询机制中,CI服务器配置为源控制服务器,不断地在固定时间间隔内对给定的位置进行轮询,检测任何新的代码更改,一旦检测到,会从源控制服务器下载最新的代码副本到磁盘上。

推送机制中,源控制系统由一个:“钩子”提供给CI服务器,当开发者向提交更改时,调用“钩子”,并让CI服务器了解更改是可用的。
构建
源代码一般独立于构建,即必要的构建脚本与源代码共存,最新的代码在前面步骤中被详细地获取,绑定的脚本会触发构建。

对于Java项目,通常构建自动化脚本使用Maven或分级。使用不支持内置依赖管理的构建系统并不常见,在不需要依赖管理的情况下,Make 使用了在Unix系统中广泛使用的构建机制。
有很多构建工具可以使用,Wiki列出了一些:(https://en.wikipedia.org/wiki/ ... tware

执行测试

在此过程中执行单元测试和集成测试,这些测试和代码一般捆绑在一起。

基于Java的系统,测试使用类似于Junit的测试框架执行,允许对测试依赖项进行简单的模拟。

某些编程技术自带测试运行器框架,如Spring的Spring Junit运行器、Java EE中的Arquillian等。

在CI服务器上运行测试有以下几点:
曾经遇到过测试在一台机器上传递,但在另一台上失效的情况吗?通过在集中的服务器上运行测试,消除了测试环境的问题。

测试会立即执行每个更改,若有代码破坏预期行为能被快速发现。

很多团队并行处理特性,甚至团队成员在全球范围内分布,每次开发者向存储库提交代码,任何故障都能即刻识别和修复。
结果
CI过程的最后有两种结果:构建和测试失败或通过。

每个嵌入都是经过验证的,并且确保不会破坏现有的代码,代码被合并到主干中,会被构建和测试,允许减少主线代码被破坏的时间。

一般情况下,CI服务器失败会发送电子邮件(给整体团队或只负责以前签入的人),可以快速看到失败的状况,并且尽快采取纠正措施。

CI服务器还凸显了最近构建的状态,以及最近几个构建在红-绿-琥珀光指示器上的状态,例如,Jenkins使用了下面的构建指示器:

2.jpg



CI服务器插件

上一节介绍了CI的基本工作流程,但大多数企业会使用它完成更多任务,通过安装各种插件扩展CI服务器,开拓行为,下面介绍一些常用的扩展:

技术债务与代码质量

在应用中引入的任何变化都会增加系统复杂和无序性被称之为“技术债务”,当新代码引入系统时会增加技术债务,如果被忽视太久,越来越多的新功能被紧凑的最后期限所填满,此时想要在可控范围内几乎不可能,这将对应用的生产效率和可维护性造成负面影响。

迭代开发、自动化检测、和CI的使用来监控每个签入技术债务是控制技术债务的唯一方法。

如SonarQube工具,采用识别代码质量和跟踪技术债务的开源平台,可以轻松地集成到任何CI服务器中,为技术债务提供实时数据。

其不仅仅衡量技术债务,也度量并涵盖了代码质量的7个核心:

3.jpg



SonarQube在简单的WEB中展现分析结果,是非常有用的工具,不仅是开发者,对于管理其他非技术的人也是如此。 


4.jpg


5.jpg



了解更多请参考:
管理技术债务:http://softwareyoga.com/managing-technical-debt/
Sonarqube:https://www.sonarqube.org/
Codacy:https://www.codacy.com/
语义

对于开发者来说,引入CI在另一个重要的方面非常具有价值——可以衡量代码质量——语义及常见的反模式。

静态代码工具可以作为CI过程的一部分,以深入了解代码的健康度,历史数据也可以存储,从而在一段时间内提供质量度量。可以为两个提交作比较,确定每个提交的债务度量标准。

很多工具可以静态地分析代码并计算质量度量的多样性,同时可以被集成到CI服务器中自动运行,例如:
  • Checkstyle
  • Findbugs
  • Sonar

更详尽地工具请参考:https://en.wikipedia.org/wiki/ ... lysis

代码评审

开发者在特性分支上工作,并尽可能频繁地提交代码。

代码分析工具(如:Sonar)可以在CI服务器中执行自动代码检测,然后每个开发者负责处理提交时生成的评论注释。

自动代码审查基于一组预定义的规则,是发现潜在技术问题很好的方法,这些规则可以从主流的开发语言中下载。

解决了自动化评审意见,会进行同行代码评审,捕捉那些不能用自动化审查的问题,如验证业务需求、体系结构问题、代码易读性、扩展性等。

如果有一定数量的人没对代码进行审查,CI服务器可以配置成阻止对主线分支任何的提交,常见办法是在主线分支中强制要求每个提交至少2个审核员,Java的项目中,常见工具是Gerrit。

更多代码审核工具请参考:https://en.wikipedia.org/wiki/ ... eview

Headless Testing

若想在CI服务器上运行UI测试,必须依赖于Headless(Headless:在缺少显示屏、键盘或者鼠标时的系统配置)测试,因为浏览器没有显示,这意味着要在没有图形用户界面的情况下运行UI测试,需要类似于流行WEB浏览器的Headless浏览器,通过命令行界面执行,并具有UI元素的内存模式。内存中的模型用于模拟UI交互,如,在UI中单击一个按钮即可模拟内存中的模型对象。

Selenium测试工具可以用于无头测试,如Phantom JS的Headless浏览器也被广泛应用,在构建中引入这些测试,CI服务器能够验证失败的UI。

安装CI服务器

CI服务器主要有三种:
  • 独立
  • 托管
  • 私有云

独立的CI服务器安装在一台机器上进行,通常用于小型项目或少于10人的开发团队。

托管的CI服务器可以在公有云上使用,大多数情况下,都与CI服务器可以访问的基于云的源控制系统相连接。这些公司都不希望维护CI或无法维护的公司使用,对于中等规模的团队,是非常可行的选择。

私有云是想要完全控制和基于安全考虑的大公司使用的,多个CI服务器代理配置在高性能服务器的集合中,以支持数百个开发者繁重工作负载。

一些被广泛使用的CI服务器:
  • Jenkins
  • Travis CI
  • TeamCity
  • CruiseControl

更多CI服务器请参考:https://en.wikipedia.org/wiki/ ... tware

CI最佳实践

Martin Fowler(国际著名面向对象分析设计、UML、模式等方面的专家,敏捷开发方法的创始人之一)在他关于CI的白皮书中提到了为任何CI设置的一些关键实践。这些建议已经成为多年来CI的最佳实践。

这里将根据文章作者的见解来审视每一种最佳实践。

维护单个源存储库

“提倡使用版本控制系统实现项目的源代码,所有与构建项目相关的都应存放在存储库中,在此实践中,约定系统应该从一个新的签出中构建,不需要额外依赖项,极限开发倡导者Martin Fowler提到,在使用工具支持分支的情况下,应尽量减少分支的使用,更倾向于进行集成而不是同时维护多个版本的应用,主线(或主干),应该是应用的工作版本。”

提示

原则并非一定按照字面上只需一个单一的存储库,关键是拥有在存储库中构建项目所需的所有相关工件,该项目应该从一个新的签出中进行构建,而不需要额外的依赖项或手动步骤。

“项目”的定义取决于自身,如果代码库很小,或者代码所构建的逻辑模块组件,那么就意味着是完整可交付的产品。

观点

实践中建议不要在版本控制系统中使用分支,相反,建议只开发项目的某个分支,且让其一直处于开发阶段。

本文作者不同意这种说法,在多数企业中,有许多分支需要同时并行开发,企业需要支持产品的前一个版本,修复BUG,而其他团队成员则开始着手下一个版本的工作,所以需要在代码库中使用多个分支。

自动化构建

“单个命令应该具备构建系统的能力,许多构建工具如Make,已经存在多年,其他近期的工具经常用于CI环境中,构建的自动化应该包括自动化集成,包括部署到类似产品的环境中,在许多情况下构建本本不仅编译二进制文件,还生成文档、网站页面、统计信息和分发介质(如Debian DEB、Red Hat RPM或Windows MSI文件)”

提示

构建的自动化应该包括:编译代码、执行单元测试和集成测试,以及许多工具——代码质量检测、语义检测、测量技术债务等,多数现代构建工具都支持这些额外集成,并且用于开发CI环境。

在实际项目中,不同的团队负责开发系统不同部分,都有自己的存储库,因此这种情况几乎不可能发生,将整个产品进行自动化构建没有必要,为系统单独部分开发构建自动化就足够。

观点

定义CI的目的除了自动化构建过程外,是否还有投资CI的意思?作为CI的一部分,打算度量哪些标准?很多人将CI设置看做开发者的工具。

CI不是敏捷或DevOps,只是整体过程的工具之一,敏捷或DevOps已经超越了开发技术层面,升华成一种文化。

构建自测

“构建代码后,所有测试都应运行以确认它如开发者的预期一样。”

提示

代码至少要包含单元测试,如Junit框架可以模拟依赖关系。

特定组件与其他模块是不应该交互的,要确保独立运行。

观点

单元测试应该测试行为,而不是实现细节,例如,不要去在乎如何计算汽车的速度,只要使用的方法和工具是正确的即可。

许多测试框架允许断言模拟对象,如测试模拟对象是否被调用,是否在特定的参数中传递等,除非测试实现本身是主要关注点,否则应将其弱化。

保持快速构建

“构建需要快速完成,因此如果集成有问题,会很快被识别。”


6.jpg



提示

应该以更快地执行测试为目标,所以需要做比其他类型更多的单元测试。

避免在单元测试中使用数据库,如果可以,也要必满在集成测试中使用。通常需要集成测试使用另一种数据源,指向内存中的数据库。如果不可避免,每次测试前都需刷新数据库,确保数据处于已知状态,并且测试会以一致的数据开始。

注意

不要依赖大量的UI测试,其非常脆弱,需要大量维护,建议使用如Selenium类似的UI测试框架来缓解UI测试的一些问题,如屏幕上更改UI元素的位置、处理UI事件等。

自动化部署

“很多CI系统允许在构建完成后运行脚本,可以编写一个脚本将应用部署到每个人都可以查看的实时测试服务器上,此种思维方式进一步发展是CD(持续部署),要求将应用直接部署到生产中,需要额外的自动化防止BUG和回滚。”

观点

不是所有的项目都需要自动化部署,如果生产站点是由同一家公司托管,那么在CD中投资更加有利,CD是CI的下一个逻辑步骤。

不是所有提交的结果都是可交付的产品,在敏捷社区中每个构建都是可交付的产品是常见的误解,可交付的产品与工作应用是不同的概念。

原文作者:Deepak Karanth 
原文链接:https://dzone.com/articles/con ... tices

中国开源云联盟第二次全会7月26日在北京召开

杨y 发表了文章 • 0 个评论 • 99 次浏览 • 2017-07-25 17:50 • 来自相关话题

由工业和信息化部信息化和软件服务业司指导,中国开源云联盟第二次全体成员会议(以下简称“二次全会”)将于2017年7月26日在北京召开。

2016年4月,中国开源云联盟(COSCL)正式挂靠于中国电子技术标准化研究院,在工信部的领导下,在全体联盟成员单位的共同支持下,联盟已形成多项工作成果,包括发布团体标准一项、技术白皮书两份、组织开展第三届OpenStack开源技术黑客松活动以及组织开展2016年中国优秀开源案例评选活动等。

此次联盟全会将聚焦云计算变革与创新,深度探讨开源技术为IT领域带来的全局性持续转变,工业和信息化部 信息化和软件服务司领导将出席会议,与100余家联盟单位共同规划中国开源云联盟下一步工作,会上也将有多项联盟成果进行发布。

中国开源云联盟第二次全会会议议程

2017年第1次(总第2次)


指导单位:中华人民共和国工业和信息化部信息化和软件服务业司

主办单位:中国开源云联盟、中国电子技术标准化研究院

协办单位:华为、中标软件、X·SKY、数人云、九州云、去哪儿网

会议时间:2017年7月26日

会议地点:北京万寿宾馆






(注:议程以当天发布为准)



关于数人云


数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。


数人云重点聚焦打造基于容器的最轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析,提升企业的IT工业化程度,构建灵动新IT。


2016年数人云加入中国开源云联盟,2017年成为Linux基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。


关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。


2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。 查看全部

924663e96e42fc508f69f4359ba852ef.jpg


由工业和信息化部信息化和软件服务业司指导,中国开源云联盟第二次全体成员会议(以下简称“二次全会”)将于2017年7月26日在北京召开。

2016年4月,中国开源云联盟(COSCL)正式挂靠于中国电子技术标准化研究院,在工信部的领导下,在全体联盟成员单位的共同支持下,联盟已形成多项工作成果,包括发布团体标准一项、技术白皮书两份、组织开展第三届OpenStack开源技术黑客松活动以及组织开展2016年中国优秀开源案例评选活动等。

此次联盟全会将聚焦云计算变革与创新,深度探讨开源技术为IT领域带来的全局性持续转变,工业和信息化部 信息化和软件服务司领导将出席会议,与100余家联盟单位共同规划中国开源云联盟下一步工作,会上也将有多项联盟成果进行发布。

中国开源云联盟第二次全会会议议程

2017年第1次(总第2次)



指导单位:中华人民共和国工业和信息化部信息化和软件服务业司

主办单位:中国开源云联盟、中国电子技术标准化研究院

协办单位:华为、中标软件、X·SKY、数人云、九州云、去哪儿网

会议时间:2017年7月26日

会议地点:北京万寿宾馆

1111.png


(注:议程以当天发布为准)



关于数人云


数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。


数人云重点聚焦打造基于容器的最轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析,提升企业的IT工业化程度,构建灵动新IT。


2016年数人云加入中国开源云联盟,2017年成为Linux基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。


关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。


2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。

致:正在选择CI平台的你(10大要素需把控)

杨y 发表了文章 • 0 个评论 • 107 次浏览 • 2017-07-21 18:58 • 来自相关话题

对于程序员来说,最纠结的恐怕是如何在众多工具和应用中选取合适的那个,小数之前给大家分享了8种CI/CD工具,用以提高交付效率和质量,今天再和谈谈选择CI平台要考虑的10大要素,前人栽树后人乘凉~

持续集成(CI)是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

CI是采用DevOps的关键性一步,所以选择正确的平台无比重要。

以下是选择平台需要评估的10大要素:

NO.1 快速构建

CI平台的主要目标是为开发者提供代码检测的快速反馈,如:有一个存储库,每天进行2次更新,每年大约有500次更新,如果此存储库的构建速度快5分钟,将节省(5 * 500)/(60 * 8) = 5.2 个工作日,因此若有多个存储库就会发现,即使在构建时加快几分钟,也能大大提高生产率。

NO.2 集成

应该与构建所需的语言和第三方工具相结合,支持源代码管理系统以及编程语言、测试工具、打包工具和推送应用程序包的存储库及部署端点。CI平台应轻松地将这些集成起来并开始工作,一般情况下,建议使用具有规模大的平台,以便后续不受限制地采用不同工具。

NO.3 免费方案

免费方案或试用期是选择CI平台的关键因素,若没有免费方案,无法确切了解原理,也很难与有竞争力的产品进行比较做出决策。智能CI平台应说服潜在客户试用免费方案或无限制免费试用,用户一旦了解了高级功能的价值,即会做出明智选择。

NO.4 快速简便设置

CI服务需要快速方便地安装使用,若发现自己问了太多关于如何使用平台来实现简单场景的问题,这意味着服务太复杂,操作不便。如果优秀的使用文档和案例最好,且可以通过在线聊天系统即时询问。

NO.5 容器的支撑

Docker逐渐成为主流,应该选择具有支持Docker的平台,即便尚未使用容器,也应未雨绸缪。提前进行部署,如此CI平台才不会成为迁移到Docker的瓶颈。

NO.6 多点运行、版本、环境

支持多点运行,这样可以确保应用在不同场景中正常使用,同时也帮助测试语言的环境,并在采用新语言版本之前发现潜在问题。

NO.7 代码覆盖率、测试结果可视化

能在不使用任何其他工具的情况下,显示代码覆盖率和测试结果的信息,充分实现可视化。

NO.8 Build-as-Code

可以通过命令行的通用语法(如YAML文件)进行简单的配置,该文件可以与命令行一起使用并进行版本控制。UI配置相对比较笨重,使用命令行可以改善。

NO.9 灵活的基础设施选择

支持基础设施处理和满足安全要求。如果是资源密集型构建,要可以购买更大的节点。如果是严谨的金融技术型公司,建议应用开发放在内网,则CI平台要有企业版。

NO.10 客户支持团队

最后,询问CI平台是否有客户支持团队,并允许开发人员不需要太繁琐的手续或操作即可对其进行询问,因为传统的客服对产品或客户场景无法很好理解,只是提供了表面的支持。如果CI平台组建了客户支持团队,表明愿意采取主动的方式来帮助客户解决问题。

原文作者: Pavan Belagatti 原文链接:https://dzone.com/articles/10- ... tform 查看全部

QQ图片20170721185708.png


对于程序员来说,最纠结的恐怕是如何在众多工具和应用中选取合适的那个,小数之前给大家分享了8种CI/CD工具,用以提高交付效率和质量,今天再和谈谈选择CI平台要考虑的10大要素,前人栽树后人乘凉~

持续集成(CI)是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

CI是采用DevOps的关键性一步,所以选择正确的平台无比重要。

以下是选择平台需要评估的10大要素:

NO.1 快速构建

CI平台的主要目标是为开发者提供代码检测的快速反馈,如:有一个存储库,每天进行2次更新,每年大约有500次更新,如果此存储库的构建速度快5分钟,将节省(5 * 500)/(60 * 8) = 5.2 个工作日,因此若有多个存储库就会发现,即使在构建时加快几分钟,也能大大提高生产率。

NO.2 集成

应该与构建所需的语言和第三方工具相结合,支持源代码管理系统以及编程语言、测试工具、打包工具和推送应用程序包的存储库及部署端点。CI平台应轻松地将这些集成起来并开始工作,一般情况下,建议使用具有规模大的平台,以便后续不受限制地采用不同工具。

NO.3 免费方案

免费方案或试用期是选择CI平台的关键因素,若没有免费方案,无法确切了解原理,也很难与有竞争力的产品进行比较做出决策。智能CI平台应说服潜在客户试用免费方案或无限制免费试用,用户一旦了解了高级功能的价值,即会做出明智选择。

NO.4 快速简便设置

CI服务需要快速方便地安装使用,若发现自己问了太多关于如何使用平台来实现简单场景的问题,这意味着服务太复杂,操作不便。如果优秀的使用文档和案例最好,且可以通过在线聊天系统即时询问。

NO.5 容器的支撑

Docker逐渐成为主流,应该选择具有支持Docker的平台,即便尚未使用容器,也应未雨绸缪。提前进行部署,如此CI平台才不会成为迁移到Docker的瓶颈。

NO.6 多点运行、版本、环境

支持多点运行,这样可以确保应用在不同场景中正常使用,同时也帮助测试语言的环境,并在采用新语言版本之前发现潜在问题。

NO.7 代码覆盖率、测试结果可视化

能在不使用任何其他工具的情况下,显示代码覆盖率和测试结果的信息,充分实现可视化。

NO.8 Build-as-Code

可以通过命令行的通用语法(如YAML文件)进行简单的配置,该文件可以与命令行一起使用并进行版本控制。UI配置相对比较笨重,使用命令行可以改善。

NO.9 灵活的基础设施选择

支持基础设施处理和满足安全要求。如果是资源密集型构建,要可以购买更大的节点。如果是严谨的金融技术型公司,建议应用开发放在内网,则CI平台要有企业版。

NO.10 客户支持团队

最后,询问CI平台是否有客户支持团队,并允许开发人员不需要太繁琐的手续或操作即可对其进行询问,因为传统的客服对产品或客户场景无法很好理解,只是提供了表面的支持。如果CI平台组建了客户支持团队,表明愿意采取主动的方式来帮助客户解决问题。

原文作者: Pavan Belagatti 原文链接:https://dzone.com/articles/10- ... tform

DevOps、敏捷开发、云计算,三剑客的小时代

杨y 发表了文章 • 0 个评论 • 107 次浏览 • 2017-07-21 18:52 • 来自相关话题

前言

在开发和创新领域中,DevOps、敏捷开发以及云计算终于突破了布道阶段逐步成为主流,本篇文章讲述将三种模式结合在一起所带来的巨大收益。

随着数字化的快速发展,整个世界都在全方位转型,过去的十年中,个人和职业生活都受到了技术的深刻影响,这一切可能要归功于DevOps。

DevOps出现前

2013年,敏捷开发受到很多开发者的青睐,这让开发和其他合作团队在部署上线方面出现瓶颈,从而产生了一些矛盾。

开发急于交付应用,运维难以同样的速度维护业务流程,两个团队都被和整体业务无关的自身需求束缚住。

DevOps出现后

在此背景下,DevOps应运而生,强调通过敏捷方法使软件交付和部署自动化,让两个团队一起工作。这种模式下的应用生命周期如:构建、测试、交付等都出现了重大转变。

应用可以算得上是创新的代名词,用户可以随时收到更新的应用,DevOps转变运营和管理工具链,让越来越多的公司获得成功。

技术上的优势:

持续交付
降低复杂度
快速解决问题

文化上的好处:

工作增加趣味
提高员工敬业度
职业发展机会增加

商业利益:

快速交付应用
稳定的操作环境
改善沟通和协作
更多时间用于创新

DevOps与敏捷开发

许多公司相信,敏捷开发可以极大改善用户体验,DevOps可以从这些新来源增加收入。敏捷开发是应用反映体系,如:应用必须反映业务需求,在快速的基础上进行测试。简而言之,应用必须更好的反应业务所面临的的挑战和现实状况。

DevOps像另一种系统——技术、方法和规则。它是一种端对端应用开发周期更全面的方法,不仅扩展了敏捷开发实践,同时只需简单的通过持续交付、测试、反馈和协作等概念简化软件变更过程。

不同的策略为应用开发带来了价值,若将DevOps和敏捷开发结合在一起,会将价值最大化:

员工满意度:两种策略相结合,可以提高员工满意度,为其创造更有发挥空间的环境,不会轻易离职。

用户满意度:越来越多的企业利用DevOps和敏捷开发在竞争中保持领先地位,因为轻松关键会让开发团队提高参与度,从而做到高品质的产出,提升用户的忠诚度,吸引新用户。

DevOps与云计算

基础设施、应用的部署、更新是开发生命周期的重要瓶颈,云计算永久地改变了IT基础设施,使用AWS和Azure等即可启用云端基础设施。云计算已经成为了实用场景,广泛应用于开发中。DevOps非常适用于云计算的开发方式。

DevOps和云计算被称为天作之合的原因:

首先,云计算的集中化特性为DevOps提供了标准且自动化的平台,用于测试、部署和生产。因分布式的特性,企业系统不能很好地与集中式软件部署匹配,但在云平台的帮助下,很多问题迎刃而解。

其次,DevOps自动化正逐步以云计算为中心,许多服务商已经开始在平台上支持DevOps。集成使本地自动化技术成本降低,通过云端控制要比各个部分控制更容易。

最后,可以帮助用户监控应用、开发、用户数据等的资源使用度,传统系统无法提供此类服务,基于云计算的DevOps减少了资源利用需求和开发成本,并能根据需求进行调整。

结语

DevOps、云计算、敏捷开发正在各个领域的企业中证明价值:支持灵活定价和快速提供服务;降低了管理开发及运行时基础设施的总成本;无需自行开发的企业,只要有基础设施即可采用云计算和DevOps实践。

DevOps、云计算、敏捷开发是重塑整个IT行业的三剑客,若云计算是一种乐器,DevOps就是演奏家。它们一起帮助行业转移重心,无需再担心宕机、交付时间和快速部署之类的问题。

原文作者:Dhrumit Shukla 原文链接:https://dzone.com/articles/dev ... three 查看全部
前言

在开发和创新领域中,DevOps、敏捷开发以及云计算终于突破了布道阶段逐步成为主流,本篇文章讲述将三种模式结合在一起所带来的巨大收益。

随着数字化的快速发展,整个世界都在全方位转型,过去的十年中,个人和职业生活都受到了技术的深刻影响,这一切可能要归功于DevOps。

DevOps出现前

2013年,敏捷开发受到很多开发者的青睐,这让开发和其他合作团队在部署上线方面出现瓶颈,从而产生了一些矛盾。

开发急于交付应用,运维难以同样的速度维护业务流程,两个团队都被和整体业务无关的自身需求束缚住。

DevOps出现后

在此背景下,DevOps应运而生,强调通过敏捷方法使软件交付和部署自动化,让两个团队一起工作。这种模式下的应用生命周期如:构建、测试、交付等都出现了重大转变。

应用可以算得上是创新的代名词,用户可以随时收到更新的应用,DevOps转变运营和管理工具链,让越来越多的公司获得成功。

技术上的优势:

持续交付
降低复杂度
快速解决问题

文化上的好处:

工作增加趣味
提高员工敬业度
职业发展机会增加

商业利益:

快速交付应用
稳定的操作环境
改善沟通和协作
更多时间用于创新

DevOps与敏捷开发

许多公司相信,敏捷开发可以极大改善用户体验,DevOps可以从这些新来源增加收入。敏捷开发是应用反映体系,如:应用必须反映业务需求,在快速的基础上进行测试。简而言之,应用必须更好的反应业务所面临的的挑战和现实状况。

DevOps像另一种系统——技术、方法和规则。它是一种端对端应用开发周期更全面的方法,不仅扩展了敏捷开发实践,同时只需简单的通过持续交付、测试、反馈和协作等概念简化软件变更过程。

不同的策略为应用开发带来了价值,若将DevOps和敏捷开发结合在一起,会将价值最大化:

员工满意度:两种策略相结合,可以提高员工满意度,为其创造更有发挥空间的环境,不会轻易离职。

用户满意度:越来越多的企业利用DevOps和敏捷开发在竞争中保持领先地位,因为轻松关键会让开发团队提高参与度,从而做到高品质的产出,提升用户的忠诚度,吸引新用户。

DevOps与云计算

基础设施、应用的部署、更新是开发生命周期的重要瓶颈,云计算永久地改变了IT基础设施,使用AWS和Azure等即可启用云端基础设施。云计算已经成为了实用场景,广泛应用于开发中。DevOps非常适用于云计算的开发方式。

DevOps和云计算被称为天作之合的原因:

首先,云计算的集中化特性为DevOps提供了标准且自动化的平台,用于测试、部署和生产。因分布式的特性,企业系统不能很好地与集中式软件部署匹配,但在云平台的帮助下,很多问题迎刃而解。

其次,DevOps自动化正逐步以云计算为中心,许多服务商已经开始在平台上支持DevOps。集成使本地自动化技术成本降低,通过云端控制要比各个部分控制更容易。

最后,可以帮助用户监控应用、开发、用户数据等的资源使用度,传统系统无法提供此类服务,基于云计算的DevOps减少了资源利用需求和开发成本,并能根据需求进行调整。

结语

DevOps、云计算、敏捷开发正在各个领域的企业中证明价值:支持灵活定价和快速提供服务;降低了管理开发及运行时基础设施的总成本;无需自行开发的企业,只要有基础设施即可采用云计算和DevOps实践。

DevOps、云计算、敏捷开发是重塑整个IT行业的三剑客,若云计算是一种乐器,DevOps就是演奏家。它们一起帮助行业转移重心,无需再担心宕机、交付时间和快速部署之类的问题。

原文作者:Dhrumit Shukla 原文链接:https://dzone.com/articles/dev ... three

Serverless架构用这5大优势,挽救了后来7亿用户的Instagram

杨y 发表了文章 • 0 个评论 • 163 次浏览 • 2017-07-06 14:20 • 来自相关话题

数人云之前分享的文章:《关于Serverless架构及平台选择,你知道多少?》详细地讲述了发展历史和公有云的Serverless服务平台,今天小数再讲讲它的5大优势,在如缩短交付周期等功能上与DevOps&SRE不谋而合。

图片社交巨头Instagram面对流量爆增,通过Serverless完成自救。果然创业艰辛,而这也恰恰证明了Serveless架构逐渐成为主流技术是有道理的。

Instagram&Serverless

Serverless架构在IT行业蓄势待发,并非没有道理。尽管这是一个相对较新的技术,但已引起了广泛的关注,许多新技术专家指出,Serverless架构具有缩短交付时间,改善操作和安全实践等功能,以及创造出一种革命性的付费模式——按资源消耗付费。

2010年Instagram发布时,差点因其准备不足而无法成为下一个白手起家的社交媒体公司。

在短短的6个小时之内,暴增的流量超过了其在洛杉矶服务器所能承受的负载。

联合创始人Mike Krieger和Kevin Systrom被迫将本地服务器紧急迁移到Amazon的E2C云服务上,他们称之为心脏手术。也正是这个举措挽救了Instagram。

经过六年的快速发展,Serverless架构取得了巨大的成果,不止简单的将现有服务器迁移到云端帮助扩展和操作,还采用弹性计算这种新的方法来简化开发过程。为Uber、口袋妖怪GO、部落冲突、Airbnb和其他具有大量基数的应用及实时数据提供了必要的保障。

在苹果或者谷歌的游戏应用商店里,有超过400万个应想供用户选择,开发人员为了寻求竞争优势,逐步转向Serverless架构。游戏应用的开发成本很容易就到达6位数,但90%的付费应用每天收入不到1250美元。通过降低成本和内部复杂性,Serverless架构帮助开发者应对激烈竞争的市场,以及提供良好的用户体验。

例如,利用全球网络数据流,无需繁琐构建架构和维护服务器,为什么不这样做呢?

Serverless架构的秘密 对于开发者来说,Serverless架构可以将其服务器端应用程序分解成多个执行不同任务的函数,整个应用分为几个独立、松散耦合的组件,这些组件可以在任何规模上运行。

Serverless需要这些功能运行在并行的容器上,分别监控和缩放。这种新的体系结构提供了几个关键点,并解决了其他软件挑战性和伸缩性问题。

举个例子:实时过滤聊天评论。许多聊天应用的业务需求大都是每条信息必须经过过滤、解析或在交付给收件人之前进行管理。

通常的方法是每条消息首先会发送到服务器,解析并重新发布到聊天室,对于少量的同步用户可能有用,但若有100万用户的话,简单的聊天过滤问题就会变成分布式计算的噩梦。

同样的问题对于Serverless架构来说简直是无痛的,开发人员写一个过滤聊天信息的函数。Serverless将函数封装到容器中,可以在任意数量的服务器上监控、备份和分发。开发人员将所有聊天信息路由到程序,只需运行更多容器即可确保逻辑能在任何规模上运行。

Serverless架构的优势

无论是正在开发一个聊天应用,还是想成为下一个口袋妖怪GO,Serverless架构都是最好的选择。

〓 缩短交付时间

Serverless架构允许开发人员在极短时间内(数天、数小时)交付新的应用程序,而不是像以前一样需要几个星期或数月。在新的应用程序中,依赖于第三方API提供服务的例子很多,如认证(OAuth)、社交(Twitter)、地图(Mapbox)、人工智能(IBM的Watson)等等。

〓 增强可伸缩性

所有人都希望自己开发的应用成为下一个Facebook,但若梦想成真,它能够负载吗?当成功降临却没有准备好就更加令人遗憾。Serverless架构的体系不用有上述担忧,如某个在线培训APP,6个月内获取了4万用户,但一个服务器都没有用。

〓 降低成本

Serverless架构模式可以降低计算能力和人力资源方面的成本,如果不需要服务器,就不用花费时间重新造轮子、风险监测、图像处理、以及基础设施管理,操作成本更会直线下降。

〓 改善用户体验

用户不太关心基础设施,更注重的是功能和用户体验。Serverless架构允许团队将资源集中在用户体验上。例如:气象公司利用Serverless架构给种植者提供了丰富的界面去操作农场设备,并会提示相关操作改进。

〓 减少延迟及优化地理位置信息

应用规模能力取决于三个方面:用户数量、所在位置及网络延迟。现在应用要面向全球受众,因而产生延迟降低体验。在Serverless架构下,供应商在每个用户附近都有节点,大幅度降低了延迟,因此对每个用户都适用。如:Gett在全球范围内提供按需服务,因此它选择了Serverless架构来降低延迟,即时消息连接司机和乘客,以及流媒体的地理位置更新。

结语

从照片分享应用到农业数据仪表盘再到连接引擎,Serverless架构可以满足开发者的广泛需求。

随着数据负载的持续增长,期待Serverless架构通过降低成本、延迟、交付时间和复杂性,成为应用开发领域的主要技术。

关于Serverless架构,你还知道哪些其他的优势吗? 查看全部

微信图片_20170705144139.jpg


数人云之前分享的文章:《关于Serverless架构及平台选择,你知道多少?》详细地讲述了发展历史和公有云的Serverless服务平台,今天小数再讲讲它的5大优势,在如缩短交付周期等功能上与DevOps&SRE不谋而合。

图片社交巨头Instagram面对流量爆增,通过Serverless完成自救。果然创业艰辛,而这也恰恰证明了Serveless架构逐渐成为主流技术是有道理的。

Instagram&Serverless

Serverless架构在IT行业蓄势待发,并非没有道理。尽管这是一个相对较新的技术,但已引起了广泛的关注,许多新技术专家指出,Serverless架构具有缩短交付时间,改善操作和安全实践等功能,以及创造出一种革命性的付费模式——按资源消耗付费。

2010年Instagram发布时,差点因其准备不足而无法成为下一个白手起家的社交媒体公司。

在短短的6个小时之内,暴增的流量超过了其在洛杉矶服务器所能承受的负载。

联合创始人Mike Krieger和Kevin Systrom被迫将本地服务器紧急迁移到Amazon的E2C云服务上,他们称之为心脏手术。也正是这个举措挽救了Instagram。

经过六年的快速发展,Serverless架构取得了巨大的成果,不止简单的将现有服务器迁移到云端帮助扩展和操作,还采用弹性计算这种新的方法来简化开发过程。为Uber、口袋妖怪GO、部落冲突、Airbnb和其他具有大量基数的应用及实时数据提供了必要的保障。

在苹果或者谷歌的游戏应用商店里,有超过400万个应想供用户选择,开发人员为了寻求竞争优势,逐步转向Serverless架构。游戏应用的开发成本很容易就到达6位数,但90%的付费应用每天收入不到1250美元。通过降低成本和内部复杂性,Serverless架构帮助开发者应对激烈竞争的市场,以及提供良好的用户体验。

例如,利用全球网络数据流,无需繁琐构建架构和维护服务器,为什么不这样做呢?

Serverless架构的秘密 对于开发者来说,Serverless架构可以将其服务器端应用程序分解成多个执行不同任务的函数,整个应用分为几个独立、松散耦合的组件,这些组件可以在任何规模上运行。

Serverless需要这些功能运行在并行的容器上,分别监控和缩放。这种新的体系结构提供了几个关键点,并解决了其他软件挑战性和伸缩性问题。

举个例子:实时过滤聊天评论。许多聊天应用的业务需求大都是每条信息必须经过过滤、解析或在交付给收件人之前进行管理。

通常的方法是每条消息首先会发送到服务器,解析并重新发布到聊天室,对于少量的同步用户可能有用,但若有100万用户的话,简单的聊天过滤问题就会变成分布式计算的噩梦。

同样的问题对于Serverless架构来说简直是无痛的,开发人员写一个过滤聊天信息的函数。Serverless将函数封装到容器中,可以在任意数量的服务器上监控、备份和分发。开发人员将所有聊天信息路由到程序,只需运行更多容器即可确保逻辑能在任何规模上运行。

Serverless架构的优势

无论是正在开发一个聊天应用,还是想成为下一个口袋妖怪GO,Serverless架构都是最好的选择。

〓 缩短交付时间

Serverless架构允许开发人员在极短时间内(数天、数小时)交付新的应用程序,而不是像以前一样需要几个星期或数月。在新的应用程序中,依赖于第三方API提供服务的例子很多,如认证(OAuth)、社交(Twitter)、地图(Mapbox)、人工智能(IBM的Watson)等等。

〓 增强可伸缩性

所有人都希望自己开发的应用成为下一个Facebook,但若梦想成真,它能够负载吗?当成功降临却没有准备好就更加令人遗憾。Serverless架构的体系不用有上述担忧,如某个在线培训APP,6个月内获取了4万用户,但一个服务器都没有用。

〓 降低成本

Serverless架构模式可以降低计算能力和人力资源方面的成本,如果不需要服务器,就不用花费时间重新造轮子、风险监测、图像处理、以及基础设施管理,操作成本更会直线下降。

〓 改善用户体验

用户不太关心基础设施,更注重的是功能和用户体验。Serverless架构允许团队将资源集中在用户体验上。例如:气象公司利用Serverless架构给种植者提供了丰富的界面去操作农场设备,并会提示相关操作改进。

〓 减少延迟及优化地理位置信息

应用规模能力取决于三个方面:用户数量、所在位置及网络延迟。现在应用要面向全球受众,因而产生延迟降低体验。在Serverless架构下,供应商在每个用户附近都有节点,大幅度降低了延迟,因此对每个用户都适用。如:Gett在全球范围内提供按需服务,因此它选择了Serverless架构来降低延迟,即时消息连接司机和乘客,以及流媒体的地理位置更新。

结语

从照片分享应用到农业数据仪表盘再到连接引擎,Serverless架构可以满足开发者的广泛需求。

随着数据负载的持续增长,期待Serverless架构通过降低成本、延迟、交付时间和复杂性,成为应用开发领域的主要技术。

关于Serverless架构,你还知道哪些其他的优势吗?