请选择 进入手机版 | 继续访问电脑版

IT运维管理,ITIL,ITSS,ITSM,ISO20000-ITIL先锋论坛

 找回密码
 点击获取邀请码 - 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

艾拓先锋
搜索
查看: 82|回复: 0

看公司实施DevOps案例

[复制链接]
来自- 广东广州

参加活动:0

组织活动:0

发表于 2018-8-22 17:11:33 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-8-22 17:14 编辑 # Y& b7 q, {8 j" ~! ~* i! k2 z1 N
+ ~/ G1 m6 N0 Q8 a! s+ m

我是做DevOps这个领域的创业者,跟一些中小互联网和传统IT公司都有过这方面的一些探讨。

现在对实施DevOps有想法的公司,多半都是业务发展还不错,在研发和运维上都比较大的压力的公司,希望通过引入DevOps来提升公司IT部门的总体运作效率,来支撑业务的发展速度。

关于DevOps对效率的提升,Puppet出过一份调研报告,算是比较成体系的。
4 N; W( E4 ~8 o+ ], ^中文版的报告链接在此:http://www.idcos.com/download/devops-report

工欲善其事,必先利其器,现在大家在DevOps领域最关注的还是在工具层面。9 E6 j5 A5 `8 u3 Z, x9 F3 B2 s
下面是我跟这么多公司接触下来,大家使用比较多的工具:
4 Y! x; r# `9 i- a7 g1、监控工具5 ?' K; u' J/ H- V( m7 ]
比较老牌的就是zabbix,nagios,用Zabbix的感觉是最多的。
  J5 w; M' D. Q& S! h- x! i国内的有小米开源的OpenFalcon。2 f* r$ @' N; I1 @" P, E) v
这类监控工具一般是对服务器、服务(中间件,数据库)做一些常用指标的监控。

2、性能分析/APM工具
& S; e; l& F+ L4 n: `APM很多时候被认为是监控的一个细分领域。5 G: H! \, j( X. \2 a9 }$ D
但在现代复杂分布式系统架构下,APM工具往往更能准确、直接的帮助用户定位到性能瓶颈,比如哪一个URL访问慢、哪一个方法执行慢、哪一个SQL执行慢。

在以往要想拿到这些数据,往往得需要比较资深的架构师、DBA一起合作才能拿到这些数据,而定位瓶颈的效率往往还不太高。
; }. b' t+ r4 D- [现在通过APM工具能让普通技能的运维人员,也很高效的定位到这些深层的问题。

现在商用的APM工具不少,国外的有Newrelic,国内知名的就有听云、Oneapm、透视宝这些。
( \* X* `4 L( k# H开源的也有Pinpoint(naver开源)、Zipkin(twitter开源)、CAT(大众点评开源).

3、批量+自动化运维工具; e/ O, O- ^7 |
这里就比较多了,知名的有Puppet、Ansible、Chef、Saltstack这些。1 p0 H4 `7 p+ i! o  U  Z5 T0 K7 B
这些在网上的资料也比较多,找比较新版本的官方文档看就行了。

Puppet和chef是比较早期的工具,受众面也很大,不过这两个工具基于ruby实现,现在要找到熟悉ruby的人来做这块的二次开发可不容易。
8 f1 D' Q9 M$ Y8 x' }而ansible和saltstack则相对新生代一些,目前用户基数增长很快,基于python实现,要找做二次开发的人也相对容易的多。

4、集中日志分析工具
5 c( M! G8 T) g, N在一个服务器比较多的环境下,如何集中的管理和分析、查询日志,已经变成一个比较强的需求了。
" z- D$ H' g2 w/ @# y: k# V+ B想象一下,如果发生了某个错误,你还得一台台机器去翻日志文件,是不是很蛋疼。
$ W5 D3 v. Q; h" p在这个需求驱动下,就诞生了一些集中日志分析工具。

在开源领域,比较知名的就是ELK这一套工具了,涵盖了日志采集、上报、搜索、展现这一类基本需求,现在比较多的上规模的企业都用这个,网上资料也大把。/ Z: E7 p/ w( K6 a: x; j
核心实现机制都是通过一些日志采集代理(类似Filebeat)去爬日志文件,将最新的部分提交到采集服务端,后端再对接搜索引擎,能支持很快速、准确的搜索即可。

有一个国内不怎么知名的Sentry日志收集服务,比较轻量级,本身是Python做的,与各种语言的日志框架做了非常好的集成,可以很方便的集中收集异常日志,并分配给对应的开发人员。
1 ]9 m4 `1 _% Z& B1 R9 q. w! t它在github上有10000多个star了,这在DevOps相关的软件里,都是排名非常靠前的了。
2 k2 v/ A+ U+ m9 `! a& Ngit的地址:GitHub - getsentry/sentry: Sentry is cross-platform crash reporting built with love

5、持续集成/发布工具' m" @- g9 T8 P
我接触的人都是用Jenkins的,没有用其他的,可能跟我所在的技术圈子有关。

集成打包的过程其实一般都比较简单,配好版本库和打包脚本就行。
8 C/ N  y  J- T( f0 o但发布的过程就比较复杂,有些是全量发布,但也有非常多的IT团队采用增量发布。6 C/ a1 Y# I$ @% A
这个方面如果想用工具,还是得先分析清楚现有的发布流程,手工情况下怎么做,哪些能通过自动化工具来完成。

6、IaaS集成7 n8 i" b9 `) h# T) {! U
最近两年的公有云推广比较迅速,很多新的服务器采购都被导入到云上去了。
* ]5 I$ L& R$ [( |% `现在主流的公有云都提供了比较完备的API,基于这些API也可以做一些针对基础资源的自动化操作,比如游戏行业的快速开服。( A, {2 X! t4 \1 j' h4 c: _4 F. r

, p* x1 K. v- ]. ]4 J' b! m
3 x7 |& }0 ?5 d: n( Q
6 ^; K1 o" f; n: h, B4 c! j; v+ w- K' I! a- b' B

6 N$ s- U$ G" L" o% k/ Z8 F作者:卖鱼的小白菜
4 q4 n! o" v3 ~: Q9 F+ L: C链接:https://www.zhihu.com/question/24413538/answer/145048082- f6 V& E" w% i6 L
来源:知乎
8 R: R0 F0 F$ E5 o著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。. m: r- H8 @$ X4 O
# S) |  G' S- q; b8 u( |

DevOps在移动应用开发中的应用,以 iOS 开发为例

DevOps 是什么呢?

我们先来看一张图

<img src="" data-rawwidth="1300" data-rawheight="1268" class="origin_image zh-lightbox-thumb" width="1300" data-original="">

Dev, QA, Ops 的交汇处我们认为就是 DevOps。 实际上说白了,DevOps 就是把产品开发过程中各部门交汇处的活给干了,让各部门都专注于干他们自己的活儿。

依稀记得,刚进公司的时候,每天工作的大头就是给 QA, TA, PM, Boss编译各种版本的包,真正写代码的时间寥寥无几

<img src="" data-rawwidth="252" data-rawheight="220" class="content_image" width="252">

实际上,做过移动应用开发的都知道,iOS 需要很多版本,inHouse, Adhoc, AppStore, 以及QA还需要各种不同的环境来测试相对应的功能,TA(自动化测试)也要各种版本,每个开发还需要自己独立的分支版本交付QA测试等。

尤其是我们团队采用的是 scrum 开发模式,基本每两星期就是一个迭代,上述的工作非常繁琐,重复性又大,Dev基本上每天都在被逼着给build,QA,TA,PM又在着急的等着build,每个人都怨气满满。

<img src="" data-rawwidth="264" data-rawheight="220" class="content_image" width="264">

为了防止各方互相扔屎 :), 我们很快购买了一台 Mac Pro 作为编译服务器,在上面部署了Jenkins2.0。

V1.0 Jenkins Job只有几种类型,Inhouse,Adhoc,AppStore等几种最基本的Job

因为iOS不同的编译类型需要不同的证书,为了方便,我们把不同的证书打包成 diff 文件,

下图中这些不同后缀的Job 的配置中,会apply相对应的diff文件

<img src="" data-rawwidth="690" data-rawheight="396" class="origin_image zh-lightbox-thumb" width="690" data-original="">
/ @- T/ i( v: y# i  F+ d6 g

此时虽然各方已经不互相扔 shit 了,但还在互喷,主要问题在于Jenkins经常挂掉,而开发又没有及时去fixed。原因是在于我们的 App 集成了crash监控服务crittercism,它可以做到实时监控crash数据,汇报新的crash。但是开发每次都需要手动上传DSYM文件,很是麻烦。虽然我们用了Jenkins插件自动集成,不过Jenkins插件的支持很不好,经常在上传DSYM的时候GG。到了后面我们自己也忍不了了,就自己写了上传DSYM的脚本。

考虑到TA还需要自定义产品环境,App动态的版本号和 git commit 号等,我们就直接将所有的配置都用 python,shell 脚本实现,实现了基于Jenkins Job名字的自动化配置。

App编译结束后,我们会自动将生成的 IPA 包发布到所需要的渠道,我们使用HockeyApp自动发布和自动推送,而针对国内的网速,则是使用了http://fir.im .

还有针对Adhoc/App Store的上传TestFlight的神器,叫fastlane,其中Gym和Deliver两大神器结合使用最牛逼。可以全自动上传App Store,不仅傻瓜化好用,而且还带push notification功能。(该功能慎用,至于为什么自己去搜咯 :)


4 a' ^# y9 E2 U) n, i

放出小部分脚本代码

#jenkins environment variablejenkinsJOB_NAME = os.environ.get('JOB_NAME', '') ## MEANS This is running in jenkins ,not localif jenkinsJOB_NAME:#os.system("git reset --hard HEAD") #need run this in jenkins shell, otherwise will discard user's committed code   isInhouse = jenkinsJOB_NAME.lower().find("inhouse")   isHockeyApp = jenkinsJOB_NAME.lower().find("hockeyapp")   isAdhoc = jenkinsJOB_NAME.lower().find("adhoc")   isDevelopment = jenkinsJOB_NAME.lower().find("development")   isAppStore = jenkinsJOB_NAME.lower().find("appstore")   isTaXMN = jenkinsJOB_NAME.lower().find("ta-xmnlab")! O' A2 I; T' q+ q' O" m4 X+ T3 e
+ A9 }" y0 R: u" q1 S4 O

经过好几次的升级之后,现在Jenkins Job基本都比较稳定了,如果某个开发需要提供自己所开发功能的build, 只需要 copy一份相对应的Job 配置, 改掉代码指向,就可以了,前后花费时间不超过 30s,甚至QA在需要的时候也可以自己手动触发Job编译自己需要的Build。从那以后,我明显能够感觉到漂亮的 QA妹子花在 Dev 单身狗身上的时间更少了,说好的天天喊我给Build的呢。


* b; F! {8 Q4 q. v4 J( X9 K, _% Y% T

我们在Job的name 中加了一个 LED 的关键字,如果Job 编译成功了,绿灯,啥事也没有,但是,要是Job挂了,这个就会滴滴滴地响,你可以想象一下,在Jenkins上建几十个Job,然后让每个Job都挂掉,那真是蛙声一片。

不过这个还是得看个人需要吧,我们目前只有两个Job配置了这种高端货,并且只有失败的第一次会响三声。

来,赞一下:)


, A6 g6 f) w  H( [
% E8 u6 Z, T  [$ g. u& O2 _* Y9 U2 b  D# w" |
# _- q' }7 J1 W+ j
==============================================================/ w% X. s+ I8 w. l' v

. Y; e8 }' k  E( L/ s作者:陈小霖 Kelly
" x5 M& x- o& T+ F" q; `( j+ d链接:https://www.zhihu.com/question/24413538/answer/139454464
3 f0 e5 ^' P' e% u5 i2 W3 E9 X来源:知乎
! D3 [- m! t% N9 e! T; L! n著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
/ `  N. }+ r$ C) D* c$ `9 p4 x

DevOps一种概念、一种思想,很难界定说DevOps该做什么,不该做什么。

在工作的过程中,我从来没有向团队同事提起过“DevOps”这个单词。这个新型英语单词的发音/devɒps/,就算发音准确了,你还得跟别人再拼读一次D.E.V.O.P.S ;拼读完了,还得介绍它是Development Operations的简称;接下来还要跟他们介绍什么含义。这不但显得自己装逼,还卖概念卖理论搞得别人晕头转向,让别人不知道怎么回事。

日常中,一般沟通时,更多是用“自动化”这个词,自动化编译、自动化部署、自动化发布等等。对普通非技术类人员来说(比如游戏项目里的策划和美术),虽然还没听过DevOps这个概念,但其实已经应用在自己的日常工作中了。


; o" i3 r$ |  q8 F% [$ f# z" a实施

我对效率工具热爱,在开发的工具中处处追求自动化来提高生产力,这是前Unity游戏项目(2014-2015年)的一个DevOps工具链的尝试:

: S0 N. Q# D0 ?" P  a8 D- W: I
<img src="" class="content_image">

查看大图:https://pic1.zhimg.com/v2-3670fc84c0a1c3215c7f8a1540c308cc.png


" ~! Y$ K2 J  q. b

简单说下日常自动化流水线,

Redmine:任务的管理,工作的分配;由项目经历、游戏策划进行工作调度,在工作完成后,为任务标记上“待测试”,进入测试状态;在测试完成后,标记“已测试”,以维持基本的日常任务进度。

Subversion(SVN):作为团队开发的基础,各人的工作按照规范往上进行提交;包括程序、策划和美术工作成果,都往SVN版本库上传。

Jenkins:当SVN提交完成后,触发钩子,进行编译工作;(另有每晚凌晨定时)除编译工作以外,Jenkins还会承担各种有自动化需求的工作,如测试环境的部署。 它是开发、运维连接的核心桥梁。

私有云虚拟机:当Jenkins完成编译工作后,立刻在内网部署服务器并启动;

软件仓库:到这里已经验证提交的结果能正常运行了,将产物放到软件仓库归档;本质上它其实就是一个简单的http文件服务器,可以通过浏览器(如h5ai等插件)来查看和管理文件。

Supervisord:启动的服务器的进程管理;它有监控功能,能监视进程的健康状况。

ELK:ElasticSearch+LogStack+Kibana,日志的收集和查询;所有的游戏客户端日志,都会通过UDP的方式,上传到ELK日志系统。在日常第三方出现问题是,能通过该日志系统快速定位问题。

测试验收:回到Redmine,根据任务的内容,把它当做测试用例来测试;

Ansible:自动化配置、运维,从软件仓库获取软件,对多台机器进行批量部署;

FIR.im:部署外网,外网也可以体验到最新Demo;

( q( Q' q2 }. i6 ]% M* d

至此一次成功的发布完成了,这种发布,每天都会进行无数次。任意环节失败了,会发送邮件进行预警,看是谁的锅。

老实说,其实最初使用Jenkins+Redmine+Ansible等工具链的时候,我们还不知道“DevOps”这个名堂,是后来才了解这个概念的。可以说,当时推行“自动化”这个出发点开始使用各种自动化工具的时候,已经逐渐的走上DevOps的路了。


7 x5 R; {/ X" R" {$ F3 w9 L6 [改变

DevOps带给开发团队怎样的改变? 举一些刚入行的经历:

一个游戏项目里,有程序、策划、美术的分工。那时候,一个美术完成他们的场景编辑后,会用Unity打包一个Package,发给某一个策划;策划同学,收到这个Package,导入到Unity,然后整理场景格式,之后进行Asset Bundle导出,并进行SVN的提交。这时候程序同学,更新到SVN下来,发现Asset Bundle资源是错的,跟策划同学说;策划同学跑去跟美术同学说,美术同学修复;美术修复完了,再打Package,又给策划同学........(循环,一天过去了)。
% C( i8 b. [  w2 ?0 H0 u6 u
经过一个月的开发,我们要发布新版本的IPA程序了,已经有一个月的时间,没有编译过最终产品了,不知道编译是否顺利。这时候,老大一声下令,把SVN锁了,然后打开Unity,手工编译Xcode工程; 但是发现有一个依赖库问题,修复,再手工编译,又发现一个BUG,再重新来...........(循环,一天过去了)

: z5 J/ `( y) j) G5 v+ q0 c
要发布一个DEMO给外网的合作,一个熟悉Linux负责测试的同学,开始在Linux上手工进行编译,然后SSH上去服务器,上传服务器文件,执行各种命令,进行服务器的启动、停止。 哦,发现一个BUG,要马上改,改完了,重复之前说的步骤..........(循环,一天过去了)

如今看起来啼笑皆非的重复劳动力,当时是确确实实的存在的。入行之初我就对这些现象非常的震惊,我万万没想到做程序员的人居然是这个样子的。 这也是后来在主导的项目中引入了这些工具链,也算是DevOps的实施尝试吧。

是否引入DevOps思想或DevOps相关工具链,这对一个开发团队的影响是十分的深的,这不光体现在编译、运维,甚至还会影响开发人员的编程风格 —— DevOps思想强调自动化,而编程的过程中,一些重复累赘的代码也是应该通过自动化来解决的。

/ Z; C7 y8 s5 H* _
未来

在我看来,引入DevOps工具链可以节省成吨的成本:包括时间成本,人力成本。 实施DevOps前,从上面的案例中可以看到,其实每个工具,都可能需要一个特定的人来完成的,工作量分布下去,可不是一件小事情了,很容易就让人在坑中度过漫长岁月。


* |' a% F5 {; p. W" n

跟之前相比,现阶段所整合实施工具就更多了,比如:

Docker、Zabbix、Sentry、Rundeck等等等。

4 F% U" O% W/ I' ]3 t

在我看来,这个领域还有一个杀手级的应用程序可以发展,可以把这一切整合一起的,它应该是一个类似Jenkins这种任务流的产品,并比它更好用,更完善的GUI。个人之力无法实现,只能期待未来有这样的产品出现——也许,这个产品,就是人工智能的催化产物。

原创:刀把五


1 c* v0 C  F3 T# q2 S; k+ U3 |
. @2 s. E. J" d: L& w2 T3 q* U# ]. p
9 z$ ~7 [( F# l! V7 Y0 ?% y

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?点击获取邀请码 - 立即注册

x

本版积分规则

选择云运维时代的王牌讲师-长河老师,助你轻松入门ITIL Foundation培训课程

QQ|小黑屋|手机版|Archiver|ITIL先锋论坛五万运维人社区 ( 粤ICP备17056641号|网站地图

Baidu

GMT+8, 2018-9-21 00:45 , Processed in 1.351725 second(s), 34 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表