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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1745|回复: 0

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

[复制链接]
发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-11-5 09:16 编辑
* Z9 T5 d$ b; `, I! p) ^- h/ m7 x. v5 J
DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。

$ l; |4 S) W- \* x' Z- n  s& P
目录:

# \: K( ~0 H: `

1 ]$ Z" a+ _% X3 N/ z: o
1. 写在前面:不满意随处可见

- k: J) C+ J* F( {" l. J: E
/ D- O3 {5 h; v6 F$ @6 D+ N
2. 三/四月:集成模型之痛

! B& w  |# r' l) m' u( A! [

3 a6 S- C) M& {- P. ?
3. 五/六月:MVP带来的变化
0 G( A/ n  ~9 i8 o! `
/ g$ V9 ~) w6 E) z) _. ^; c5 e) l5 O
4. 七月:规模驱动工程优化

% P  [2 ^6 ]. R
* ]3 _! a( Y2 Z. I9 F$ u
5. 后续:长期规划、短期见效

0 H- v  Y( E! l% E% {( X+ |5 Q( ]2 x* E7 @
先简单介绍下此版本的主要特性:
, @& Z/ ?# _( Q* z2 e
+ q6 T" j: \: N' T! a/ d
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:
/ l9 t! M, u( M, k4 B8 W- g

6 ?; m: @7 D5 `) v4 ]: ~) G6 l, h

: Y8 j3 z0 Q; w. V
1.png
4 M& d% l8 C" Y
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。

    8 k4 O$ w7 o6 T2 K: A) q* j2 m7 [' b

8 R0 |0 P) w4 \; G# c9 n1 p
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。
    % S2 S& W+ ?8 W4 @- V- s8 U8 }
* f; J( X7 w: ~
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。
    7 y' G' S% v0 s: i$ Y  o( K

    0 ^2 N3 X4 Z: m5 D5 Y3 Y( z

# B) b9 t) ?$ s$ h' u
1.png
# q! v' e# t/ e- D
写在前面:不满意随处可见

; d1 e2 J6 E8 S( l: U- B8 D( B
% i2 i" `  `% r) e: Z4 y' Z
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。
$ q) T$ t2 E- T9 L, T4 A
0 X- E( V5 a5 ~+ @2 Q( Z
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。
- ^& W* q" c' U- F
0 `/ ^6 o5 b  B  W: Q
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。

; Z. O  O; N6 Y- W- u7 q0 Z
, z" @% t& W6 Y/ E- K8 Z3 j
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。
" ~* S4 S# B; n3 v0 s
5 _/ E3 E3 C8 J7 w! [
三/四月:集成模型之痛

# ]  |/ u+ q- B2 K! j
# U2 {. D1 q1 r! u4 @4 d1 A
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。
' d3 Y8 S4 h, Y9 B' |+ m+ q
% O; |5 X2 ^! k$ I
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:
0 [6 F, R6 e$ ^: l# o% H: U/ Z3 W* {& |
1.png

2 G* H! K3 Z( l) m
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。
    0 ]5 c9 V$ B' Y+ U4 W" u! m

    4 U  {' |/ ^. j7 G+ t  ]
& C  T' T: d: M5 S! x7 l
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。

    1 N/ I) B+ @  [/ V
    / N) r9 ^) h6 \/ h' o5 @. G& [- U3 k; i2 m2 @
. B; ~: y, e3 d: r
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。
    " n( _) b- n2 Q/ z8 a, e( R% ~8 k% A
7 a0 u: W! t- |( j
举个例子,对Jira的集成,DevOps模型是这样映射的:

" n0 b3 p! ]# ^6 X
1.png
, o- M( W5 O/ h" j( K! a  w
可以看出,DevOps做了不少取舍,同时引入了jira没有的产品概念,来统一管理需求。而对于数据流,DevOps在项目管理中更注重看板与项目报表(进度、效率、质量),日常工作还是建议在jira上去做,毕竟jira的工作流等能力非常强,不是某个新的项目管理平台能够覆盖到的。

, l' t# M8 C% L+ o& h! R/ o
5 t- s& [$ \, f" Y/ K! Z
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:
( U! Y  b1 I9 L, Q: U
1.png
- g" I# ?* g  ~3 P5 n

- j( Q% b$ |0 e5 c6 ^

. \- }2 y; b9 ^: b$ X- D3 L# a$ |, v4 E

' m" u  l# `6 @. ]& |1 R5 @
五/六月:MVP带来的变化
3 p  h& V0 g7 T1 l/ l
$ v) m& A6 o: z, M2 k  M7 K
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。

8 r7 p6 ]* j! \) a9 n$ f- J% N
( s4 E% U) r. O! e- H. q4 n3 b
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。
* o( e' V6 @% p. f# G
1.png

+ W- ^3 a2 Z+ m& N/ a6 G
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。
$ r' _- o9 |# \/ O

' Q3 g: t7 z6 _* w( t2 D3 D
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:

  c/ |0 ^2 v0 J
1.png

( E2 Y3 d& D, O; ]# Y. Y- [8 b
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。
    4 g! }% p- G: O

9 N5 M/ z( p+ Y' w2 J2 D; t' `( f
  • 从竞争角度来看,业界都不易做的,往往价值更高。
    ( \+ m% x/ f3 O; t! W# p

7 ~" E1 X" @3 T' E
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。
    % R( M# D6 G! S( t3 v

    ; ]2 _! ~. R& l% |, ]

1 {' d, e) g1 e

1 t; n5 ]' k9 Y, ?( m4 ~" `
当然,永远不能离开MVP的本质,要保证每个冲刺后交付的版本都是可用的,让大部分角色能参与进来。还有一句话,我觉得也很适合现在的大型产品研发模式:“think big, start small, do smart.”
. s) F' _! V* P( V5 F
* B; _6 n6 R' I/ I8 e$ T5 O
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:

# v7 I. s/ B& K

* ]  d+ \/ D0 t4 L  O3 q. e
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。
# [: P, K2 d$ d" D( {1 \0 t4 t
/ h1 ?# Y1 N# m# U+ ]
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:

1 |3 J9 j6 n- F5 w( C9 V  J
1.png
6 o4 Q6 ]# R& f" K! ^
另一种是我们自认为有技术优势的,比如交付流水线:因为我们有流程引擎组件,使得面向不同的企业交付流程,可以做到动态可配。比如某个企业流水线上,是有预发这一步的,又或者上生产前是需要人工干预和多级审批的,对我们来说会比较容易实现,最终参考界面如下:

0 g, D7 I+ q- ~, {* g+ _: M

( H) @* V- @: Q9 t0 g
5 H2 @! ?8 S; q% h  r/ c
1.png

! R) ~6 I- p2 z% z
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。
/ B! e4 J- E% x  i

& w  E5 k( e0 z. Q" |+ ?: ~/ X* c
七月:规模驱动工程优化
+ N7 S% H: i, G7 v( K7 h+ C
- g, Q/ p) M$ j1 T* p  e+ c5 c
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?
) a0 b* y0 f( z' ]5 q9 U
9 w5 U& m  Q% t( A, W
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。
  S( a4 V) ]8 x+ n0 i" ]
1.png
; C# v+ W8 l3 ?7 T6 [) k; f$ {
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。

2 r0 u3 Z+ l3 n. Y

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

/ q+ O' _- `/ M0 h+ Z: ~& x
8 `; {+ e- |2 z3 c4 R5 A8 `
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。
: Q: t1 S$ h" j, @" W

+ d' _- ~0 u3 y3 U* c( c9 K
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。

( b1 m" a' |: H
# r- b; x* |" t! L- m8 l
  ]; V: n% q* ?; d7 b
我们的思路一直是,从BAPO角度来解决问题:
# _1 w5 m  e7 B" T; n' Y6 s

6 e: x! A3 s$ |; f" \
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。
2 r) [" O9 U' i, \2 x% e
2 g3 O% I8 y: f
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。
+ X9 I, u) o$ W' }8 A8 x) j1 x4 E
9 _* f' V) a2 ~7 `$ g& q, B
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。
- Z' ^  w& t! i
' m8 a; Q2 y* g& f. t+ ?
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。

: o* s+ j2 B; H5 ]
  j  }8 d- s  [4 g# ]
后续:长期规划、短期见效
2 I: q2 s6 s5 B  s2 R5 [/ ~

/ i* l' s' @% [8 @* z" {) g7 v; M, `
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:

  r3 _7 B6 K% k6 b. E+ k( P
1.png
6 t1 b4 y7 w# S
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。
% G& L, ~2 Z0 s; s
6 O- M$ s8 f! p! ~7 i* B$ t
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。

4 ^2 m* A  k6 t, Q! w* a  [5 ^2 |9 w
$ F' r& W* W  C: q" Y. r* B' [7 t
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。
& c: x6 ^# T( u/ U# P4 Q. v

, x6 p1 k( I8 ~& e' r6 Z
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。

# Z7 |; B& x  m* H) ^& F

: O* w9 T* m% Q& Q. I" K" e  S. j9 F, s$ z
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。

! _2 s& l- Q) p( p
6 A& P8 H! o2 V6 O
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:
: y% _4 ]0 ~+ I% c
1.png
4 J2 \- L1 v  P4 t5 @/ S
原创:顾伟
! k& ^# T! B- Y* O  ?
2 k: Y- Z% t% a  d" K" p# O




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

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、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, 2021-10-20 17:53 , Processed in 0.109020 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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