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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-11-5 09:16 编辑
  i9 C& T( t& \# U/ t. C- U
7 l2 l/ a$ K: A# Q; n; {& ?0 D
DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。
0 V8 k, F( \7 r: S% k: E
目录:
2 ?6 c/ ?+ f  K* c
5 C; z5 s" E/ E! n
1. 写在前面:不满意随处可见
: |9 P: n5 r9 p& c
$ s5 C5 f2 T/ k1 K6 U" n
2. 三/四月:集成模型之痛
* \; c- W, Y6 X3 v0 D8 R1 E) w
; _' G; J, ^; N6 v% |9 X
3. 五/六月:MVP带来的变化
: _6 w" b) i8 l

5 C9 M; d) x. _  `
4. 七月:规模驱动工程优化

/ x% U: o: }) p& ]' l

  K- |. z+ L4 L  |5 X
5. 后续:长期规划、短期见效
( Q) ?& w1 x. d. c; p  e

: o$ U! X3 @1 N
先简单介绍下此版本的主要特性:

, p2 I8 J1 M( n6 i( w
1 o/ s! w: ^8 t$ b4 H
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:
" v; @- o  a' Z9 I

& B5 \) o$ C% w4 `1 i7 ?7 v( ]

9 B, n5 A3 ~+ b" t9 g& k8 F+ Q
1.png

) o3 g1 g3 V2 l8 ?
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。

    ; X; z. l5 X1 B
# E2 U! R4 ?8 b8 P5 {: |
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。

    " d( f) L$ V! D2 G% t
( M+ v2 H9 X  L( ^! R. m. c
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。

    $ p0 l1 i8 i7 d$ S9 T& U$ S! x

    " @; Q) K2 O3 a: Y( g% V

$ j4 i  O# ?9 U* l0 e
1.png

  ]/ k3 ?4 f! z* N( S5 F1 f6 ^
写在前面:不满意随处可见
# U. G% |; K$ S
2 l; c+ {; q0 n0 O0 V% L5 p7 ~
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。
& _1 W$ t/ L5 k" Y: o- x/ T. R. {

  ?4 H+ M# U2 {. g
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。

/ Q8 d+ ]  a! V5 C

# Y  l( w1 U/ R$ v/ @) u, {
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。
3 {0 j3 p& ~7 @

8 x* K% k1 b& g" w  f" I
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。

. F3 ]1 f, _* M# Y% b. h5 |2 k" s/ F+ I0 x6 B* H1 \) s
三/四月:集成模型之痛
( \) z% P) I# X, H' `0 ^2 K2 f
" T8 p. D( t( i5 Y# E+ T; z
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。

7 {5 q8 i: c6 P
8 `9 `$ q2 H9 E4 I$ X
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:

3 j8 y/ p, _+ J, B, l8 W. r+ f: O
1.png

" ]4 C; S4 P" Y- d- a* o6 F5 M; x
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。

    # g7 L  R$ Z" p. Y) Z% ?; Y

    " F8 l2 k& k% _

0 e; o/ Q( Z$ b' @2 ^
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。
    $ U9 `/ J7 ?2 ~8 f& [( L+ J
    / N2 w2 q8 c, ?' p  B
- `8 h3 T2 R0 e0 }! e
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。

    ) Q1 \; j/ c- b5 g  X3 s

. h1 @. W  O& j7 N% K/ ^9 }
举个例子,对Jira的集成,DevOps模型是这样映射的:
0 N) L& D+ H9 o& E5 H5 o: G
1.png

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

8 I2 @0 T7 D' _2 i8 m2 ~
+ S+ N) {" r1 I& P) ~0 ~
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:
/ `  Z4 m, N, T- _# H
1.png
( R6 c) k7 b! g+ B2 E* q
& D* ~! K6 f7 k" i9 G, k' x
4 ^; o0 V; A) [: n7 F# c5 ]; x
( I2 K7 x3 P7 W" [% ?. f
五/六月:MVP带来的变化
0 p! O! A/ I1 x3 c  i0 W

+ w! x! M  p* k/ z; Z
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。
  n( k9 l% ?6 T9 j% G) ?
  R4 z0 k& u; ^4 U  x
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。
. e! K3 w$ |/ Z. ?
1.png
# G* a8 v7 L' h3 S+ j; U
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。

2 `, O; S$ S6 N+ k' V' I0 U
9 a/ }$ S4 P2 E  y
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:

5 J4 U# G( r7 n0 X0 d
1.png
! o2 u+ {5 P: A* Y; o8 Y, ~2 S
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。

    8 i5 V% e/ j+ v9 X+ {
% a% h! A" Q# S, ~6 F3 @6 U* p' t' L7 {
  • 从竞争角度来看,业界都不易做的,往往价值更高。
    ) P3 d: c* q8 A% W2 L, L* f7 K& b
, p* |8 d. d* d
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。
    2 _0 b. Q5 z( T: v7 P  |* y

    # Q3 n$ d2 t4 l9 q/ g; {7 t
3 Q& |: ]0 g1 j, z% H' d! `

% s' ?; b! |" o$ H, |
当然,永远不能离开MVP的本质,要保证每个冲刺后交付的版本都是可用的,让大部分角色能参与进来。还有一句话,我觉得也很适合现在的大型产品研发模式:“think big, start small, do smart.”
; C: J+ _& O' M" N' @
, q# r) p7 G: k" \( L
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:

- X+ f: K. q1 Q; O5 H0 e4 s
, Q: R8 ]4 k! m& M/ ?5 j: p9 x, s
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。

8 t& {. [$ f9 w5 ?5 l; v+ ~4 {

5 A7 D0 ]( h% J7 [3 m6 a" H, \
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:
4 J6 B0 B( n; D8 \' }2 J3 X
1.png
4 I% P6 b( x5 l: y% e) @# B
另一种是我们自认为有技术优势的,比如交付流水线:因为我们有流程引擎组件,使得面向不同的企业交付流程,可以做到动态可配。比如某个企业流水线上,是有预发这一步的,又或者上生产前是需要人工干预和多级审批的,对我们来说会比较容易实现,最终参考界面如下:
& m  y# s& O/ y$ K0 ~% u! {
4 s5 L: @* O4 v8 M0 k  t! k4 [/ W( K

  h- d; _, w; X0 W* u  s
1.png

  d6 g1 _3 ~! {( a
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。

) L) I! Q0 B- k' ]* ^0 J* A, h/ U; u% v9 q% S( k$ S
七月:规模驱动工程优化

" e4 S/ F2 S; h3 p% Q. ]: i2 \' [! D
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?
( D- ]( k9 q3 P* [# g6 e3 n1 V) u

8 Q9 ~0 S- e: }- {. v5 b1 a, w
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。
  H1 @/ t6 K6 o6 M9 X, m5 R
1.png
% w4 t! r; w2 p6 ^  z
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。

' j' N+ }7 ?( S0 @" ?7 i5 v# R
+ R8 B% x) U2 D
对于我们这么一家以产品为核心的公司来讲,如果产品线和产品线之间采用太多不同技术栈,产品部门与事业部(服务部门)不能一起往前演进的话,即使某个产品技术栈很先进,缺无法让公司所有人短期接受并掌控,就永远做不到全面推广。

& R( x& |4 y+ N* U/ w8 O; Y
( R7 B9 C$ p, j  c
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。

! }  P0 E4 P  c. u: u( a
# S) @$ ]9 a/ l: Z! V4 {) y
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。

* O. n3 c5 W& g: g- T2 v
6 s" U$ p  ^: r1 O8 u  P# e# U

% `' h! f; D# X
我们的思路一直是,从BAPO角度来解决问题:
. \' b2 [$ F& ]5 {/ X, H5 \
8 W$ o! {7 S! I
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。

! o. L% q7 X& R/ Y: o
8 V: p& O  U$ S# y& q
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。

3 V4 R* n( C* `$ h' Z

: m. k0 _* R. E& k  ?5 Y, G
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。
0 N! \# `' G' O- K& q- Z. e
& v( e2 P& F  |/ @" Q+ o0 E
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。

' e) J7 A0 n4 h$ z2 A6 g9 M3 ?4 p' C

" k# v5 L# F0 _$ `4 P
后续:长期规划、短期见效

1 x, x8 `. P7 N- `* `1 r) W9 w5 e- G& H/ K& C
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:

  W  c$ c; L/ r) l! ]2 w; W1 J7 `* Y0 ~
1.png

- R' J+ B) P0 e0 t, G
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。
% F7 Z; h. i' O, N: p! U' ]

; K$ F8 H  x) T( y- m: Y3 n
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。
+ j! E" `) g& }0 ]. n

  U: u: s' w$ I" P9 s
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。

) l7 e- p; y# r% o# X
0 n$ b! W$ _3 f  p0 u
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。
" r2 m! c7 A5 ?+ g9 }! R6 ^

+ E# k8 K& ^/ b" X7 V
2 v  l( ?1 @7 c4 }2 ?/ e  I& {
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。

& y6 @( \) \) Y; L8 `
# P7 T) E0 K; h* p6 n5 b
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:

3 W. Y$ U; H% d8 H& E" Z7 I
1.png
$ c8 h! q" u: o  y7 u2 |% _& b
原创:顾伟
! p4 K% L" r0 u% s

1 v3 Z# Q* O! Q7 J9 C, d

本版积分规则

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

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

Baidu

GMT+8, 2019-3-24 07:13 , Processed in 0.210566 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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