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

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

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

用DevOps 5.0版本的150天经验总结

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-11-5 09:16 编辑
6 C- [7 d( Z6 O+ H
) j; ]% \9 ]% }3 c: m' {8 p% t
DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。
! y$ J+ W. V5 |5 O$ Z
目录:
7 _, p0 {; y) J# V' d4 H" h

9 ]' }% K6 o9 U4 W3 S0 Q
1. 写在前面:不满意随处可见

+ U9 ~% F2 k6 ?$ P

' a% |9 S3 ?, u
2. 三/四月:集成模型之痛

# [1 q8 P& M# T( K! j

0 x1 B3 ?0 f$ G
3. 五/六月:MVP带来的变化

" ^* [6 P( i1 c5 L: S3 S
( N* G# U5 u( m% q
4. 七月:规模驱动工程优化
% ]- u  m4 z7 K$ Y# Q% W* w. G

* x/ _* I0 B  |2 x! N9 R" }
5. 后续:长期规划、短期见效
9 u0 R; V* u. x! j* B, \
& K7 V$ X; P) ^8 o
先简单介绍下此版本的主要特性:
. W6 S& V2 u% v3 I7 W5 ~

8 V4 D& _' g0 m
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:

0 N/ {7 D; {0 J8 {: k) ]& |
+ b6 f' n2 A7 V! V

' Q4 t6 `3 `. l5 @# I  s
1.png

* u- S7 r5 F8 f' p1 {  u0 ~
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。
    ( R/ K7 ?) @8 {* V& F1 e8 s
6 G( [% J& @( [$ ~( q* T, j3 m
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。

    2 a5 Q7 i% _/ W1 p( b: A; Q& T6 w
4 w9 A, X( _9 [; @, A
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。

    8 l% o( A! X7 b. p+ R# Y4 ~

    5 u# U* N5 R/ E* C! [- s# T6 v
% o5 e3 J3 X, E  u, L! ]) `6 {
1.png

% H: Z( t: `7 T& L- j
写在前面:不满意随处可见

7 n0 O/ d- j- Q/ t$ N) e! K& T# r- A, r& T
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。
! b" _4 r1 P1 `  W. R0 V. E

4 T' C8 c& `) h
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。

& H/ I" u5 D& `
3 F" r" T$ Y" u" z  Q
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。

+ b. `4 v5 @/ l
* s4 o1 Y; n6 l. s
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。
3 s5 `8 V7 }; o: }  o( P8 e
# J. E, m  }# Z3 \7 u
三/四月:集成模型之痛
0 C8 E0 W" N  z8 S
+ y. A6 p: c  a# K- Q$ I( s
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。
; k! |% P* \) u

  J! ?, t7 {+ o2 \" Q! v. V$ k! n
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:

5 T; a: h/ h1 y" G
1.png
) ?6 O/ [( y# p2 c: {9 i( W5 R7 S
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。
    % w* ^& L: ]( R4 ]8 a

    " M; H% _$ y  D2 ?9 \9 T

" ^, g2 h) Y' q
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。

    & ~9 ^# }4 ^1 m
    3 S! |2 Z+ N+ H" c3 E& a. \

; W+ J; M; X9 f  B
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。

    ' B  `+ J# X, n
- M2 u% i- M" X: c' K
举个例子,对Jira的集成,DevOps模型是这样映射的:

0 Y8 J7 C5 ]6 k7 W  V
1.png

, W8 k0 i3 ?0 z; [/ M: y
可以看出,DevOps做了不少取舍,同时引入了jira没有的产品概念,来统一管理需求。而对于数据流,DevOps在项目管理中更注重看板与项目报表(进度、效率、质量),日常工作还是建议在jira上去做,毕竟jira的工作流等能力非常强,不是某个新的项目管理平台能够覆盖到的。

3 O: S$ M$ S- U
* q9 v; W/ R) i' O& p$ G
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:
8 t5 R( s9 o* ?3 j
1.png
- a# }" U* V! |- K7 f) p6 u: g

& Z7 d( r! t$ v) _6 a5 C
/ f' O& a2 }$ L0 M

1 N5 B: w# C. ?- C& n
五/六月:MVP带来的变化
' o/ u, I% {# C. E. |
3 y/ `& b0 J) S$ [* n
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。
8 W! w! `, e- [# E- X
) W0 p* R3 b$ Y2 \
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。
; C, i( m) t% k
1.png
4 }& D; }9 N0 r, k3 n/ S9 R7 x. X
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。

/ `1 b9 u! z0 M: h, Z

0 H4 e. e- q1 I  X8 z7 K1 V; V
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:
+ ]3 k( g( h$ p! U9 ?" Y0 t
1.png

" G. e. j+ E- K" o0 S) e, o' x
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。
    5 F& O2 A6 S- o7 N& U  k

  R6 `: m' o* s& L* ~
  • 从竞争角度来看,业界都不易做的,往往价值更高。
    1 e+ }! V% o" X7 X  Z9 T7 @. }
& D6 G/ w3 {  M7 c4 T) ]2 I
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。
    1 u' x% e2 ?) j- @
    ' b6 _9 x' T7 H7 T
/ i$ H/ a; f; n- f' i5 v$ I
) W$ a$ R: N. B; }: U4 k7 o9 h( Q% U
当然,永远不能离开MVP的本质,要保证每个冲刺后交付的版本都是可用的,让大部分角色能参与进来。还有一句话,我觉得也很适合现在的大型产品研发模式:“think big, start small, do smart.”
5 C  _( R6 R8 h" v/ K, n/ Z& `, C; g

5 W! r7 w( F' ], D0 v' v
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:
1 P' t' ^- Z% I  j: d

& M& D4 v9 N; _5 @
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。

; K4 c2 p7 L: T$ T8 x
2 U- G) \6 K' B
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:
2 r# _, X1 m2 v' G
1.png
% o9 B4 C8 m$ \% P$ x
另一种是我们自认为有技术优势的,比如交付流水线:因为我们有流程引擎组件,使得面向不同的企业交付流程,可以做到动态可配。比如某个企业流水线上,是有预发这一步的,又或者上生产前是需要人工干预和多级审批的,对我们来说会比较容易实现,最终参考界面如下:

& W5 M) J! \: H+ [* c

5 d, G* h# ~2 [

( h: g$ v( o9 z9 c, D
1.png

" ]4 m& B' R& L; S9 t
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。

; Y/ G" o9 e5 X% h& J
- Y7 X+ W6 s+ p2 Z: A/ w! S! L6 k
七月:规模驱动工程优化

& S% Y* S( C$ V7 z
; T- o& ]  H  Z  S  ^8 H7 W
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?
- M% ^5 r8 l* U6 V. C3 |

* w) g2 e$ }  x
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。
2 u9 D: E) w1 R2 T8 v/ _
1.png

* Y6 q3 q+ [9 |5 b- ~
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。

" d5 e& K9 [' Z6 `0 V1 f

/ K2 \/ P% O: E5 c/ j
对于我们这么一家以产品为核心的公司来讲,如果产品线和产品线之间采用太多不同技术栈,产品部门与事业部(服务部门)不能一起往前演进的话,即使某个产品技术栈很先进,缺无法让公司所有人短期接受并掌控,就永远做不到全面推广。
4 c0 j& m1 h( o5 T

" C5 P2 S0 `. }( W
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。

1 K' O6 x2 i1 T+ J, Y4 ~0 f* K& f
0 _3 o7 c, U, u1 X2 Q3 l
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。
5 Q1 C' R* V4 i0 W2 C% u3 @( ?
' g3 W" v& v. b6 N

$ e2 B  H* ^) X% ]# x( y% U
我们的思路一直是,从BAPO角度来解决问题:

/ c) j6 j% y1 ?. i

* W! P5 E: A2 R3 g* q
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。
2 J2 K! j; q1 }9 ~8 Y/ S* [

" Y% G' x8 V7 _  N
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。
( F" p# x4 H0 K8 [0 V4 W; R

+ \8 f$ M. V* @1 e! }
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。
0 o" ~: z( \1 w" m3 B

7 ?8 X( U: J. H! z5 k# y: Y  Y  J" M
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。

2 J$ }# h6 q# x  Q" K' W& ^& e6 d% E
3 H1 n. M6 V1 Q7 {5 O) L+ f+ v) I
后续:长期规划、短期见效
5 c% L1 U5 |3 p- R( r4 n! y: {! e
6 ]0 w) ~' _3 D4 Y3 ?$ t) i
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:

$ B- _) g! |4 r. p  t: Y2 H
1.png
6 a& c  p$ l* V# C
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。
6 _0 G/ x  O* \! \! y: z
0 C8 C* z0 j: J* @
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。

! {+ T0 O$ B+ R2 ?, g
% Y. ^5 F. k- \  k3 d
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。
8 K- D% H7 \. d- h4 ]% e

; B7 y. ^0 F- d0 p+ \
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。
* |* n. I* d2 C

5 d7 i8 a$ i1 _% \6 W/ ~, k) l
0 S9 A3 B! u0 I3 j
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。

0 ?2 J* y4 e9 G0 L/ R, w' Z

  q' s% J) A; j$ E% N
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:

  s2 N4 }8 @7 ]( {5 H3 P5 F
1.png
- |! i, G+ j% ^7 H6 m5 l' G9 s1 g& J/ C
原创:顾伟

' z2 b) K2 L+ u0 }8 j7 F+ f

# p5 j9 |" D& R+ ?# }

本版积分规则

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

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1|网站地图

Baidu

GMT+8, 2018-12-15 19:59 , Processed in 0.263689 second(s), 31 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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