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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-11-5 09:16 编辑
9 S0 t1 K5 X' `* P1 d0 {2 S( `8 H" n" Q6 D3 [( i
DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。

0 n% ?' V4 O: F( a
目录:

* }2 K# ^" B, s$ l  |) D: _7 S

9 k" k- G8 ~" N2 _$ ]
1. 写在前面:不满意随处可见

! p1 o& f; W! c5 B( d$ L2 Z

# x. B4 A) o' R4 E3 ]' n) v
2. 三/四月:集成模型之痛
- m) g; r* }0 J7 K
+ s+ ^# [4 x% p8 `* ^7 q
3. 五/六月:MVP带来的变化

+ ~( l  k  ~8 i* I4 v

. r1 w5 e. g: O" `% W
4. 七月:规模驱动工程优化

% z* M! r$ D& E& a, H5 t  x
4 O* p8 ?; s* V" z4 n: R
5. 后续:长期规划、短期见效
: d7 _( X! q1 Y1 N

/ ~# {$ d: |% D$ z( L) G
先简单介绍下此版本的主要特性:

5 M3 ?& M1 B+ f( l1 |3 ]! ?

/ r" t: W* ~1 X6 f% G
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:
' @  T' D6 ?  H: h- }- K* p' `

& l! x+ ?) ?, |6 P! Y# R2 l1 s
6 z% E8 Z% s4 F8 X3 K1 _; }
1.png
& d3 X) R9 X; L2 L6 o/ K) u8 R
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。
    6 \% i' ?! E3 W! b% w
6 T# D+ u! K2 J5 B! i
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。
    8 `7 j( W; j( n5 Q, W

0 R! M& Z; _7 e; [5 l* @: a0 J' L
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。
    ; ]" \) [+ u8 D& [: Z+ x

    ( n& z; M/ u- ~  B& p
7 d0 ?) N& \: t- M8 }
1.png
/ M: |+ ~  U) a* P! r- p
写在前面:不满意随处可见
' b8 S1 d% n( H, a# k% F, P% Z

& W: C( ^7 H& u* _+ y
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。

+ \$ }  N3 D3 M- ?

. M& c  N/ a+ p( m" O4 o' D6 B
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。

3 u+ B5 {$ D3 U( R& q, y) k( n
5 C; {& U  q# f: A
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。
' q0 p! N: n, s7 K$ i2 ?5 t. k

7 E2 R! R" c0 V- p
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。

: X0 t; ]( o9 X& F. i+ Q4 y# o& Z2 y/ |5 B( w- C: |
三/四月:集成模型之痛
( K9 n  T" R* b

: L6 n4 P2 K. A! ]/ d
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。

2 a: ?' ?4 M  a. \) k9 z8 G& y! v7 e

0 |; g3 v: c) V) a! r/ X7 @4 n& h
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:

7 G  ]4 B2 n- Z: F. D# a
1.png
* r: j6 B4 ^. s$ H# C
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。

    . D% X8 S* i' G, T

    2 {- w* q( F6 f2 y$ X

- p. {" G! i1 a  Y0 I2 I
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。
    % b! Y7 D+ ]) H0 l5 m" o

    + y8 Z. f. P, O
/ v% p( Q+ @# ^5 [
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。
    # V. f6 {- R( t% |: O6 C  C# `

$ X* @, t! I2 c" C% R3 M
举个例子,对Jira的集成,DevOps模型是这样映射的:
0 f) P- J* V: {/ g7 X; Q+ v4 b
1.png
* [5 V6 H( x" b3 _& [" }
可以看出,DevOps做了不少取舍,同时引入了jira没有的产品概念,来统一管理需求。而对于数据流,DevOps在项目管理中更注重看板与项目报表(进度、效率、质量),日常工作还是建议在jira上去做,毕竟jira的工作流等能力非常强,不是某个新的项目管理平台能够覆盖到的。

9 d  N" g( o; f) O

% Y2 K' o- Z. R, j
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:

. i2 I+ M9 p3 u" T- z) w
1.png
0 T. o% ?7 a3 P0 E
$ x( ]& e3 f- m0 ]

4 x4 T% k: u4 q7 b

1 k& }5 h" l% H, r+ ?# ^' w  j
五/六月:MVP带来的变化

! H$ u+ O6 K. `* T  O% K1 i1 E3 Q$ R# y+ @+ s" h
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。
4 k2 p6 e( {2 [) {0 B0 D

3 p0 M. [, n# @7 f  I
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。

# B2 J7 D' M  M& L% P( ~
1.png

0 N2 Z. r; k9 ~* u( t$ x
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。
0 q4 B5 H( E& L- F5 w& H
8 b( r% v, i: Y9 j/ F* k
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:

: ?: Z+ }' f7 k4 h5 i
1.png
6 Y, r7 \5 B) ^$ m; e$ f6 X
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。
    : ]- }% W6 J& ~7 Q2 B% ^; `

; Y" A2 D% Y/ H: {8 U# l
  • 从竞争角度来看,业界都不易做的,往往价值更高。

    ; j4 u" U: K' f  c4 N* K4 H/ |5 b% y

3 Q2 g+ t$ k; E9 M7 r
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。

      V" M6 y8 m4 n% J* F

    : g- o/ F( W1 q  b, c; m$ C3 F

+ t0 f( J. Q3 X

. y  Z# c$ _: H9 F+ T$ r9 c  U: W4 W
当然,永远不能离开MVP的本质,要保证每个冲刺后交付的版本都是可用的,让大部分角色能参与进来。还有一句话,我觉得也很适合现在的大型产品研发模式:“think big, start small, do smart.”

6 E: F5 ]4 p" ~# B: C7 K

2 U" ^9 [3 j) T0 G  c. Q0 i0 x
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:
. {( U: S( E% Z- W

; U/ ?8 w( S# {' \1 R) P( K7 {
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。
$ ^  ?; h* C+ Y. O% L
" Z5 e- I  E$ Z0 L$ J% u( M
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:
# u; S: P" r6 `( t. O% Q
1.png
. ^9 O* b5 u1 t+ D
另一种是我们自认为有技术优势的,比如交付流水线:因为我们有流程引擎组件,使得面向不同的企业交付流程,可以做到动态可配。比如某个企业流水线上,是有预发这一步的,又或者上生产前是需要人工干预和多级审批的,对我们来说会比较容易实现,最终参考界面如下:

; j2 t2 H8 N+ U1 H5 }9 K* P  ?+ A

0 n! X- G  U6 g% p5 |* G& r

" Q2 z6 Y5 |; B9 Q2 `
1.png

3 ]3 m- E( E' C2 g+ [# p/ n
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。
/ B* W" p& {) m& I' w
. j' G" n# r( [7 L: b3 M  t
七月:规模驱动工程优化
& \6 {: R  W" d9 K
" v2 J4 z: n) U8 r* s) z, o, A
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?
# _- e) o/ Q+ c, [* m3 H

4 i- D% w: D2 m5 ~/ ~1 o
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。

8 ^+ ]7 I) b  u; q- p( p# }
1.png
' G& Q) N- p/ d; E5 [
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。

+ e7 j+ `! B$ X  Z  P) {

  H5 g: [+ G3 }4 h4 Z
对于我们这么一家以产品为核心的公司来讲,如果产品线和产品线之间采用太多不同技术栈,产品部门与事业部(服务部门)不能一起往前演进的话,即使某个产品技术栈很先进,缺无法让公司所有人短期接受并掌控,就永远做不到全面推广。

3 m2 Z- t, r: b  l) T9 ~- S' L2 Q3 G  N
8 a# R0 }  _: w
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。
8 P; J5 T1 J5 N. i  x' E  O

& k5 p+ q, q4 f( P6 M
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。

/ |' {9 a* I: s% J% y

7 |: Q7 k0 g7 O* q% G3 m  |
, H, L1 p$ ~+ Z( X# V, y6 Q# [; ~
我们的思路一直是,从BAPO角度来解决问题:
/ i- t& {# y! k& G

3 g3 Z" W9 H) _# [
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。
0 h$ M4 a3 b- [2 U- u, X9 G

) d; U  B- I; q( I+ b  I7 L
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。
+ ^5 @: e/ J" [/ q

2 N" R+ ?; N" e
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。

7 _! J  H* O) Y. o0 a% q
# |: ]) I" F- L4 C$ q
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。

; K4 L* n5 @& E) c8 n

) D( `2 s/ o$ }6 R. h; J' w
后续:长期规划、短期见效
' d  I, ^: o) f0 h- n

2 f* g( j9 H5 Q' L; B- e9 c
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:
; q. q$ I/ l* D, p
1.png

' ?3 c) R7 w9 [6 Z+ m% i- ~
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。

! N( j6 K) B" {4 b. Z* L
8 T0 g. @$ Y- }
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。

* D, g4 o. U# J+ ]) C) N
9 A8 g$ e, {4 k% G7 I8 u" W8 D
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。

5 J. @4 |1 P$ j
; F5 I" J" g" L2 A' g1 y
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。

$ X1 M- w% U1 L. _7 u+ b

8 q  |5 e8 n9 m, s5 ^7 l( m3 X
* L* w& D# y6 ^; B' o+ s
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。

, x2 [& k% }, p% @0 n+ h
2 }( @. ^. ]+ C9 d+ x7 _
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:

4 r$ ~; F' T& @# Q% w6 N: ?2 J
1.png
" ]# Z0 s4 e/ `- I9 r% R# J( L
原创:顾伟

9 W) S3 n" I) I' d% m: J
5 U/ r$ }" Z( B  L( N) G+ M# N

本版积分规则

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

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

Baidu

GMT+8, 2019-1-17 11:16 , Processed in 0.282348 second(s), 31 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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