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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 538|回复: 0

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

[复制链接]
发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-11-5 09:16 编辑
; E  d1 j; m4 o
- h9 S6 Y, Y. Y) b! Q
DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。
/ x* E. l" K' u, e' P" O" I
目录:
+ t3 x, k! B: W* f5 L

  H: d* u' p3 }2 @; P  m
1. 写在前面:不满意随处可见

* I0 t* t9 k+ a. R* V! W& j
4 O1 I4 q5 T" H1 g# q& ~
2. 三/四月:集成模型之痛

5 Z! Q+ V) s0 D. B. h; J) ~8 }

- i6 ?7 [, y& U- ^1 Y
3. 五/六月:MVP带来的变化
$ F8 {8 G/ R8 q" W" d
# V" C6 v6 g7 B7 R% {
4. 七月:规模驱动工程优化
' \7 e: r9 @: a# n/ |- {

* M2 F  I1 f& T
5. 后续:长期规划、短期见效
8 e- e$ g! P' v. U# {+ S9 P: [
8 k$ B! }/ X7 d- d
先简单介绍下此版本的主要特性:
8 f/ ~: R8 q6 u* P* P0 N; y

7 D- N  H; c2 v  b
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:
. S/ o% Y7 o; W# r7 i
# ]; b  k# `) n$ K& H
' q& S" T- A3 x: N* I
1.png
$ k8 A) S. Y  L+ H% z' I3 S
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。
    . Y0 C, A, p- a* m
6 Y; a( ]: `  [
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。

    % W2 Q; l1 k! l0 I- q$ V  o
3 d  I; s0 Y, G5 d% k
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。
    - ~2 d5 r- y( L  j

    9 o! L7 Z' f  b4 i

2 y. W5 f2 ]' r9 y0 K" o/ o' B0 T
1.png
' ~. z' _; a7 G3 s8 D- a4 R1 f
写在前面:不满意随处可见
' O; X9 b/ ^4 M2 P4 r" D
' y+ }; n6 L- B) i; ^- M; s
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。
) i6 ]4 Y2 p. t- C
5 R+ k" t2 Z4 w; c$ l# A6 Z
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。

* o# \4 f) o& j6 z

2 H2 G! V# \" R  R& M
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。
# ?; q9 F- r7 `- P
. L$ a" O  b' h! P' K, c4 M) Z) o
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。
" N( `: w) `$ b( N5 k& l
! ^, M$ d) |/ P$ C$ z$ q: R
三/四月:集成模型之痛
0 R, Q% o+ k+ j

* `" Y5 q! _" s6 G& L- W9 b3 N+ s. ]
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。

/ _1 S7 ?3 ^- Y* j) b( T: y, {. n

0 U3 ~$ I: D2 l0 A' f6 ?: k4 A6 L
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:

; _$ @" V1 }: i* c& J# Q/ i
1.png
" o1 L- Z) |, k8 R/ M( v
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。
    6 t, j5 \1 C, H% F" B3 v6 o

    # e& \  Q* f) H! b
7 `$ r2 T1 V, i- G3 x/ a1 j( G! U
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。

    9 ^1 l8 Q4 a/ r4 n! z4 c
    9 X! D' e+ A( L& }

8 H" e! {1 i" O9 b
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。
    6 m9 Q' r( i- {- n: o5 g- L( ~1 ]
. j$ m% O) H; u' f' \
举个例子,对Jira的集成,DevOps模型是这样映射的:

$ ~/ R. a3 p) _6 C$ B
1.png
6 w, Z- _8 B% f2 z6 R5 o$ V
可以看出,DevOps做了不少取舍,同时引入了jira没有的产品概念,来统一管理需求。而对于数据流,DevOps在项目管理中更注重看板与项目报表(进度、效率、质量),日常工作还是建议在jira上去做,毕竟jira的工作流等能力非常强,不是某个新的项目管理平台能够覆盖到的。

+ B$ v* V  H. ^2 r% b' @9 z
) \  a* a8 I9 ]$ V# m- Q9 N
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:
3 h% }* D  P5 r/ Q' Y4 G( H
1.png

4 @2 f. {) y; q, ~9 b/ b/ c. M" }! B6 @+ f

5 H& F% P. O3 A7 z
. ^* e- E" W( v/ X8 I
五/六月:MVP带来的变化
( |( x; C' [6 L7 L! b4 S1 s

) w* S+ Q6 n/ z* D  C" d: ?
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。

/ X2 E; i6 k: u* f2 ?" r' t
* f( n/ b& {  \+ t0 ?, e
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。

7 b4 `  F$ b% S! b0 f* E7 E" K0 Z
1.png
7 b9 x" |: X7 z, s: W
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。
3 }  T- o3 A% k, ^6 F5 z0 c$ D7 ?

6 T( a: h" J' B8 v# n
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:
, j6 I- h, j9 Q* i
1.png

9 Z2 W. A/ B0 C
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。

    ' B. z  w  l$ H2 C6 S+ X; e

  X4 A$ l$ z1 |! @, k
  • 从竞争角度来看,业界都不易做的,往往价值更高。

    & D' c/ F. T2 r# \+ D; m4 _9 x

  }4 h# E& l8 s) _0 T: c2 q5 R5 m
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。
    / S" w1 W' V% e( |3 ^

    4 S7 b) n% }, W) R
9 H. M( m5 X- r' S+ p

+ v# ^) h. \  P3 C2 C
当然,永远不能离开MVP的本质,要保证每个冲刺后交付的版本都是可用的,让大部分角色能参与进来。还有一句话,我觉得也很适合现在的大型产品研发模式:“think big, start small, do smart.”

% `: c: I4 G5 }9 M  `
# a& i6 |& D8 m. p# D
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:
+ D. d* r# j+ X
& _5 W) D4 H  D
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。

1 X+ V+ \- |- n$ F4 z- Z
  I( i- l9 W0 f$ r
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:
, x" f1 n" ~  J2 q! M" x
1.png
8 B; U5 H; m" N: \; J
另一种是我们自认为有技术优势的,比如交付流水线:因为我们有流程引擎组件,使得面向不同的企业交付流程,可以做到动态可配。比如某个企业流水线上,是有预发这一步的,又或者上生产前是需要人工干预和多级审批的,对我们来说会比较容易实现,最终参考界面如下:

5 v: c: g9 B' Q  V. r+ ?

$ n  l1 V; R0 R! |" e/ d

. H8 b' |& ^& C+ i# F' u" Z" X
1.png

$ G' A+ b% q2 P- t+ C2 ]# K
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。

2 u8 L( T* A  B0 f" Z/ Y
# t/ x$ B% Y5 o" a
七月:规模驱动工程优化

% x% U% w4 d" w
% w2 N/ C5 s+ U/ g, k
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?
! e4 a" S' J) l) B
( J, z) b3 ]* F+ @% y) T0 m! M1 M
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。
6 R/ e/ c& o: O% o( F
1.png
( p7 ]- q; O8 I0 `
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。

. N# ]: y" U: @( e# c$ b0 [
5 F! W4 g( E# m- n, R) j: h
对于我们这么一家以产品为核心的公司来讲,如果产品线和产品线之间采用太多不同技术栈,产品部门与事业部(服务部门)不能一起往前演进的话,即使某个产品技术栈很先进,缺无法让公司所有人短期接受并掌控,就永远做不到全面推广。

1 x$ W' K9 b# K$ C
- {6 i1 `( A3 C9 k$ n" s  p
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。
) D7 M8 ~# I/ O

* G9 p. b6 ~) I4 c; D4 ], i$ `
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。

8 s, P" O& w) D. ]$ f% K1 V+ n, `

; e* n/ C# q3 q1 B, y
7 L9 E0 J/ C6 \2 K$ C5 B: N# _
我们的思路一直是,从BAPO角度来解决问题:

, K8 E# }& ~! [& y2 D4 g- b

8 n5 i# a$ D% Q+ G7 e. g
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。

$ T+ m. i9 ^1 O1 x) o; o9 G
9 f3 U  F' B$ ]
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。
4 D% Z9 o* b! ]2 `' F7 `6 E
& G8 ~2 U9 K9 I6 ?5 d  S; m
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。

9 C& L) Q9 u3 S4 z4 A

+ i" l  D7 z8 W/ h* V% P. s
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。

1 S: p( m' v- y) k* }* m
/ T* q% Y; U. @
后续:长期规划、短期见效
/ g0 p; q# H7 y- \7 V+ w$ f) K

' z% S5 ]. {: v( X0 _4 P3 T
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:
: V% M5 O. H" ]* J4 M( [) u
1.png
# p2 H$ Y6 i- t2 p
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。
- O( P7 W: J* _" X0 |
- _- ?: W5 Q! e( y5 u- S( ?
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。

  e* y; t9 `& s. k. z8 b* N5 p
5 M- @* |- M. r$ _* l" I1 Z3 C
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。

* a9 d  C% O- u0 H2 A

3 H, |3 g! j# X, L+ T
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。
0 P6 Q3 N$ r) y0 f7 c0 T
/ d$ u" N3 f' M6 O
, c9 \* m4 x& h; a
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。
7 A  w1 w1 K2 c

. W% e2 @6 Q1 R# I5 P( m
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:
- I  I& p& r/ y
1.png
0 |; a! A/ D$ S) q. e/ e$ g  l
原创:顾伟

3 P' T  @; n1 r+ M, ?7 R
! M+ [5 Z9 j3 ^1 M8 M) U% [9 Z+ P

本版积分规则

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

Baidu

GMT+8, 2019-9-23 06:57 , Processed in 0.153755 second(s), 24 queries .

Powered by Discuz! X3.4 Licensed

© 2001-2017 Comsenz Inc.

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