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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-11-5 09:16 编辑
7 _5 v& e- E( Y- z7 y* F# \
7 E1 e# I. l! c- i* N1 i$ S: V" f/ ?
DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。

0 g6 M  g0 q! D' _
目录:

# J( B5 o( z% T$ R% x
+ [; h  k) Z0 U5 p+ X4 P4 ~
1. 写在前面:不满意随处可见

! t. F1 @2 t+ O/ f( D+ ~0 ^: F" h
, K* i2 m4 x4 I
2. 三/四月:集成模型之痛
5 }. A' q( B; `' s4 F7 ?" R6 \( X
, h% G/ B5 Q2 W! @7 ~5 h
3. 五/六月:MVP带来的变化
! y* ^% y6 m) r, R' I4 R$ S
. X% @/ N3 Z  @4 v( d& {5 E% j
4. 七月:规模驱动工程优化
% c9 O2 H2 x! D; V  j

$ C5 g6 [4 R$ t( s8 g4 M9 t
5. 后续:长期规划、短期见效
) }! D/ u7 B2 y) {; P+ c

3 {. A* Y8 }+ y
先简单介绍下此版本的主要特性:

7 N9 I3 w8 e4 h1 c' w% {
$ |9 `3 D; m5 \+ W/ R& t
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:
7 e6 P4 W5 J) S/ o
2 r$ m( ^4 j+ T1 A

0 d+ {* c2 F1 {: A$ F# k
1.png
9 c; W; I' E* t! ~6 d9 O
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。
    $ t% ?5 Z1 Z) |# U

2 L- {/ M9 j* E7 ?: v5 }. ^8 n6 h
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。
    + E. i8 U4 R5 `9 O; Y6 s$ w6 N. q

+ \# H% C8 m" l
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。
    4 ]8 u# c8 g# m

    8 ^! D0 e. K3 F" x0 @

$ H0 ~7 J+ w% Y  ^2 j$ X! Z
1.png

2 ~5 y4 s' k; F5 C9 a
写在前面:不满意随处可见

7 C5 s6 ]6 Q. F( k3 m1 |
7 \$ t, c: }% @6 f
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。

% O9 L. n8 ^, x; ?
9 n  X' M5 K; }& K4 e' @
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。

' c, J$ K& D2 I
2 {9 b7 y; I, k! s+ H/ `
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。
- e- S* o# E  W: q

8 `$ y1 V! u8 w* }1 i2 C3 W
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。

+ _( m2 U9 K) m+ y! N; T/ t8 M$ M. w
4 p0 q- |" O3 d; M7 Q, g6 x% p' n
三/四月:集成模型之痛
0 E# h  N& n; o$ Q! _$ c
. T$ y( r& F4 f! t3 m9 R0 y
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。

5 J' X$ @5 `! m# h: H

  g3 u7 }% }: k9 Z& j4 ^0 H3 C) u
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:

% f% M% ^! ]) l# E9 ^
1.png
) C  `+ ~+ j6 A6 u* o& G: U
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。
    - b5 z/ S* V. U5 a7 d7 S( ]

    " Q8 b& Z+ ]4 B

* N6 q# g! @" v; l% u+ p
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。

    % ]* u* M1 V) {; M! Q3 p+ y* J( q& X! u' j: _5 N9 a

% a9 b1 T2 ^7 {* L6 f+ P# M
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。
    * `6 D5 K/ I! @" j

: }- f$ S% c& B) J
举个例子,对Jira的集成,DevOps模型是这样映射的:

5 X: }% z$ L8 r6 {; i, E
1.png
$ h; r$ m- H  \6 u" G
可以看出,DevOps做了不少取舍,同时引入了jira没有的产品概念,来统一管理需求。而对于数据流,DevOps在项目管理中更注重看板与项目报表(进度、效率、质量),日常工作还是建议在jira上去做,毕竟jira的工作流等能力非常强,不是某个新的项目管理平台能够覆盖到的。
; Q" J/ q- g5 z6 k
  H  h3 n+ j% v, b& @* |! t# K# M3 v
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:
* o, y4 [$ O! z
1.png

( V. T4 L) T- d. }- f( i- V# H
$ N2 C# X$ d7 ^4 }, `

& w# r6 [8 f3 M+ O: r
, s  H( f* M, r4 p8 C( d) M
五/六月:MVP带来的变化
6 d' e2 Y$ p# A6 C$ F( U

! E' O  m! k- A) ^* L
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。

5 a( t" t2 W/ T9 Z! z4 ~" m6 g
( I. p/ F1 N3 Z8 S9 r9 Y
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。
' F6 d0 @0 J0 M/ G  x, r" f
1.png

. p5 i' w* n; x. v+ Y6 n+ a
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。

) y% c1 X1 m4 D4 k
* b( }% C: K$ m1 b# Q+ T  E
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:

" M' W( \; H  `
1.png

+ h0 N. c; R0 L8 F
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。
      d( _8 I  }! ]7 C

5 d  s/ U) [+ e0 [2 P9 ~$ B5 _
  • 从竞争角度来看,业界都不易做的,往往价值更高。
    , z( k$ N* s/ O- |
3 S% ?+ w$ i: L+ V) l# u
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。

    : J6 d7 z6 u+ @( ?% ]5 z
    2 W5 H# M" c1 e6 B( Z8 }

4 a* T) U6 M+ V7 h8 S
! N9 c; {/ e7 Y% Y0 C0 p+ Z9 z
当然,永远不能离开MVP的本质,要保证每个冲刺后交付的版本都是可用的,让大部分角色能参与进来。还有一句话,我觉得也很适合现在的大型产品研发模式:“think big, start small, do smart.”
& g8 a% b+ I! [: z4 o2 y* d
) L  E& G' ?7 Q: f
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:
8 \5 h  J7 B1 {) b, P

: `! p" X( J5 s  I1 m" u, o9 N
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。

8 |/ u1 y8 P$ ^

, Z3 }5 ^6 |( B
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:
  r9 Q( U+ T7 x7 D: F' q
1.png
! o- t' ]" I  Z. a# d& d, H/ y* ~( z( X
另一种是我们自认为有技术优势的,比如交付流水线:因为我们有流程引擎组件,使得面向不同的企业交付流程,可以做到动态可配。比如某个企业流水线上,是有预发这一步的,又或者上生产前是需要人工干预和多级审批的,对我们来说会比较容易实现,最终参考界面如下:

1 z& I" x- z! ]) ?/ K+ {. g
8 y6 D3 Q, G, S" f' ]0 P6 g# r. J
# W$ r# Z# i. [' G. r; `
1.png
9 w& \6 h0 H- y, _
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。
5 K% a$ y& D. p& H4 W" @) t
9 l4 C8 `1 F) p1 m* h
七月:规模驱动工程优化
! ?/ e/ M- L7 g" Z. v7 t
2 a6 c( s3 S5 F5 w/ `$ B3 q
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?
- a/ ?2 O7 {% L1 D

1 [$ }& e# w( U1 T# l
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。

" {0 k: I% I; c( O
1.png
( E8 A2 \7 ]3 H& ?$ f
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。

0 i& P9 w+ N$ J- a/ W9 K) E! g/ t

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

8 {( @- p' y9 w8 \" b) s
$ E8 _( |  Z; R; Q0 w0 {/ O
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。
1 `$ B! h0 T0 ^. M* j
) G* n) q; S: p2 d1 W
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。

1 k. C' q& {) K. X3 n" k
0 {2 J& P3 b2 f1 _

: z% K% G0 p2 _6 k+ {
我们的思路一直是,从BAPO角度来解决问题:

6 H4 Z" k# p$ \# `. I( F
% V. V1 ?3 b& Y/ T' s
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。
/ |: T0 }  `0 V9 P
" W! {2 G! v# m& l% N2 E$ R
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。

/ f; H: u: P: D, A4 D- j
3 ?" J$ V+ z0 j* a# x) T: o
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。

" |" ?+ h( {0 z
0 z. b$ a5 y7 I3 a9 s6 d3 q
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。
- W! R+ g0 Q' z& |! w  S
0 A( C1 m+ \, g) s! |$ z) I
后续:长期规划、短期见效

' v( a- U+ h* R" j* U
" [: s/ }  c3 Z1 L, {- T( f
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:

, Z- ~1 G. G) F
1.png
  r" h7 y% ~/ V. D% O- A' I+ T
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。
6 v; h1 L  A! E) a% N0 x
& A% t' s7 D. z1 d2 r. s( s! R! q
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。

" ?9 L7 Q0 K6 A- A
0 ^4 r( _- N9 k& c
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。

0 S: \/ Z1 b# x
! ]/ g, T2 l/ ^6 w4 k, d% E
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。

4 \$ w- d" v9 S9 Y, j9 ]

' a% K% r! j3 N/ N" _. Q9 W- ^0 ^( L+ p9 Q' ]
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。
3 M" s% m' ~  F4 p0 L" L# v- a/ j
) `1 E* H: D9 B
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:

& e2 E3 a( T  C) @7 a& ]
1.png
6 x; R/ a% R- m3 r# x" o) N
原创:顾伟
; a8 C) n! z; H% Z8 @
5 {" O1 e: h- B. ~

本版积分规则

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

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

Baidu

GMT+8, 2018-11-20 04:23 , Processed in 0.233967 second(s), 33 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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