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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1913|回复: 0

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

[复制链接]
发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-11-5 09:16 编辑
3 W9 u7 v$ _$ J& O
( c/ ?) k+ ?) j0 p
ITILxf.com" target="_blank" class="relatedlink">DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。

2 K: l2 U. H  w
目录:

( q# l) Q( B0 R% K
* q6 m- t9 ~+ }+ P, ^
1. 写在前面:不满意随处可见

7 }! a# `8 Y- `7 i$ ]

, w$ _- G  z+ n1 T
2. 三/四月:集成模型之痛
/ b! |- R2 [* U* O& v* x) A+ n9 r9 ?# C

& b+ X5 Q! _8 W: w5 L8 R( ^% C3 Q
3. 五/六月:MVP带来的变化
3 t' c3 b. B! G  i2 `9 ~

, `( B/ c& I% w2 c- m; ]3 _
4. 七月:规模驱动工程优化

8 t, L) O: F: a" K! x7 P! C

/ S8 `$ v  C/ x" n$ U5 \2 i) J2 B
5. 后续:长期规划、短期见效

* C. S5 u7 J+ B* C% |1 K$ B1 g, F) K
先简单介绍下此版本的主要特性:

0 C8 J4 j) h! z- J

, n3 ^: W; u* `1 T  u
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:
9 Q1 K8 K+ v( z

5 r# H. Z7 [. _+ V" }, K! d9 w/ `

  v, C! h, d, k
1.png

3 a( N' e8 s+ X  P
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。

    * I+ X6 f& Y; i% D" B5 |# @

' {8 j. y$ q/ d) v0 j
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。
    : N- ~  g% K. r7 h' C; I/ F2 c

4 d9 j- a6 y8 b% H9 e+ @' I. ]0 E$ j
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。

    , W& K* J1 ]. @7 x; w4 S% Z

    6 g+ o, G* B* ^; E& @: D5 C2 K

7 L" Y: r4 g; H9 Z" e- q
1.png

9 n3 A( j" U, C( o
写在前面:不满意随处可见
& D; v  R- z( W& d. p
0 C4 [& S. s" F9 v( G6 y5 o
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。
3 ^* B, f. O8 P* \5 K  a' ^
. t3 A( b0 b1 ^* G: m
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。

$ ~8 L- [$ A* s
/ ?' V$ [# W4 Q
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。

3 E( u  ?% t. v# y9 m

  A9 N( k- B  `6 a* I& \8 T2 ^
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。
/ S+ Q% r: Q9 q+ ~
# }( L: e0 ^$ V; M# Z
三/四月:集成模型之痛
8 x0 `9 Q$ r. i6 o0 {
" Q! R; d# ]8 E2 \3 }8 F
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。
7 |1 C5 E( g* e7 x) ?
5 @% q  t: H" R% ^$ f8 K+ A
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:

! v3 P6 z8 j5 D% H, d) Z
1.png

6 |2 \1 c) X2 L6 ]
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。
    / o3 h3 k/ O$ W9 R2 K: g
    : _& h2 M+ J3 {. t4 |( m" p: h
6 o4 P" p0 k+ g3 V& q( `* V+ V
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。
      P7 }3 C8 u- j2 g" b
      P- q4 E3 \' I+ o' r4 e

& N* a; W9 K% h6 k" j: S
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。

    $ {8 v. `9 B0 r: w; o( n
- c7 @. ?% B7 p9 k) }2 l
举个例子,对Jira的集成,DevOps模型是这样映射的:

: q( S1 Q7 I- V2 s8 B
1.png
# [  z2 ?' y! E* j6 r  m7 @
可以看出,DevOps做了不少取舍,同时引入了jira没有的产品概念,来统一管理需求。而对于数据流,DevOps在项目管理中更注重看板与项目报表(进度、效率、质量),日常工作还是建议在jira上去做,毕竟jira的工作流等能力非常强,不是某个新的项目管理平台能够覆盖到的。
9 O' C; c" V. u4 ~" A

2 o0 p: n$ G% z6 {* V
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:
9 |: S7 f& _/ ?8 e: f& v
1.png

0 w6 f* w( R0 K+ l0 g3 J* \6 Y4 F- h! s4 L) e0 V6 ?8 q& ]
% E( |9 N8 H6 h: ^

( o- A  N7 S. m' v$ d: D
五/六月:MVP带来的变化

  D8 s% h) J7 D  ?# a" w# A, u& k, d0 Z+ D0 }, d2 p
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。

7 B  \1 i1 t' r4 V5 F" Q. I
- v/ B, k3 M+ @
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。

6 s* F- D2 E* \$ C
1.png
2 d# A* ^0 y: r" ?4 W2 U: `4 `
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。

0 C' n7 e4 k) i2 y! e, Y" p
. ?4 |2 e" @9 C" s) `
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:

. N, a, n# @( x
1.png
, b( I; E5 c9 E& I# r- u
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。

    * Y; O2 N! `( y  B- R

& l6 U) q, I" ]' n  e" U" v- M
  • 从竞争角度来看,业界都不易做的,往往价值更高。

    $ D  A% x9 S7 c
) q5 _/ d$ z, k: t6 O% g" P  G' j
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。

    2 R2 N8 U8 U2 m7 x
    4 R$ C( D2 w3 i' o8 r" A  r/ ?0 o/ ]
5 y3 r1 Q& u  d0 m5 A9 @6 w
8 W1 {: ?! r/ k6 g! @3 x
当然,永远不能离开MVP的本质,要保证每个冲刺后交付的版本都是可用的,让大部分角色能参与进来。还有一句话,我觉得也很适合现在的大型产品研发模式:“think big, start small, do smart.”
5 |  q# N# u. |7 I! q/ ]# Y9 o+ u8 j
  |" ?$ G. m, Q
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:

' R/ |$ {9 p% c* ?

( l# h! }. L/ \  U  u+ m
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。
* g* f3 V* o6 f+ V

; |/ {$ K3 p0 Q
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:
, q  U2 ^5 ]  E% _
1.png
& i& Z9 _% J* s% u: d# h; `( ?
另一种是我们自认为有技术优势的,比如交付流水线:因为我们有流程引擎组件,使得面向不同的企业交付流程,可以做到动态可配。比如某个企业流水线上,是有预发这一步的,又或者上生产前是需要人工干预和多级审批的,对我们来说会比较容易实现,最终参考界面如下:
$ u( _& ^, l. X6 d; H* ]

1 ~3 b; H1 ~* \- ^0 F& |/ L
3 r* @. u3 o- \, |0 {
1.png

/ ^9 X3 c4 s3 T1 a0 J& ?' B1 W
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。

/ V1 n2 |! }, K" t9 }+ ?# ^6 R$ U6 e2 `, X3 i
七月:规模驱动工程优化

2 N0 Z1 l& _8 W5 v; ]3 x" I  i* \; C8 r) e- t$ B: B3 G4 a; O! ^
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?

* F, w* K% b7 }
$ U/ z  o8 N7 O3 ?4 ]
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。
% I7 a$ G( w1 e1 `% b* T# g, H- O$ d
1.png

. h4 ^# u9 r( H* `
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。
2 Q6 S: Y" t8 l
0 i- e3 f; i' M& X
对于我们这么一家以产品为核心的公司来讲,如果产品线和产品线之间采用太多不同技术栈,产品部门与事业部(服务部门)不能一起往前演进的话,即使某个产品技术栈很先进,缺无法让公司所有人短期接受并掌控,就永远做不到全面推广。
% U. b9 y& y; a$ r5 D. Z
- L  g2 J4 C7 i( i, y
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。
8 E7 b. k$ k, x$ p
4 k: ~* W/ B0 F; b6 ~' O7 W5 N
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。

" U8 j5 {7 z  V. O- c  g+ z- d
) i% v  m6 k8 {% H

, }3 t$ N. y+ p# Q+ X; i+ X  C1 @
我们的思路一直是,从BAPO角度来解决问题:
. Y3 _5 z% O$ ?" L/ r) n

8 N; h- j* d7 l% T8 m% z4 f
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。
6 Q0 _( R% R* J8 s! u6 C9 s0 g' g
9 d( ^' C  H2 t
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。

; `2 S- k  }9 k) z9 i% D% A) Y
9 S) |. {4 t" p+ b9 f: h" P
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。
' j$ X% L) C" F
/ Q8 ^1 k1 m, V+ K/ I0 l/ U
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。

0 f7 [4 z% Y% I/ n. b

* J# r  A( {1 K' V7 ~. D
后续:长期规划、短期见效

, K3 F8 ]. g6 K6 i3 `, k) D. n/ a. H1 b; V9 B7 `5 T
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:
$ I( W( r0 [2 |2 [3 {( v9 u
1.png
& q* o2 ^9 J. r, V7 [
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。

' U3 L. Y3 D- o# \# |- M" a) ^

! r+ A4 d5 G" Q) ~3 a) Q
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。

' W* Q+ G3 m) G( }: ?
$ X& \5 P& c; S# ]4 w+ V
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。
. ?  A5 `3 ]  h8 H( s( h
# l* ~* m  S' G4 w3 W
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。
+ t& O: J0 ~4 Y+ W! J/ W

, r' y& k$ [7 j9 c+ U% e, ~) y6 E& b
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。

4 l+ Q& H' R! w( ~5 j
' M- m5 S: {6 b: i' p
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:
& h! p& j/ _4 X
1.png
9 V9 w# C0 r& O; l" `; ^( b
原创:顾伟

8 J9 O, p0 x4 I0 j' S

5 z2 ?# n; e1 F




上一篇:DevOps实践:面向服务的全自动化测试体系分享
下一篇:DevOps 来了,如数据库变更速度跟不上该怎么办?
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-5-23 03:57 , Processed in 0.232924 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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