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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-11-5 09:16 编辑
) K* H% H  A) J) A& p% P( n# X( x3 `
DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。

( q! ^! B% |8 Q$ Z# I: h
目录:

0 j0 s+ o! Q( o. @, [- I' j' c; q+ D
9 R; o' Q' Q9 D" t# m+ Y
1. 写在前面:不满意随处可见

! \3 g+ e! D7 Y7 j% @# A

. U! K9 u% R1 }3 k
2. 三/四月:集成模型之痛

. W7 b* G. {6 p
( V  I) }$ v' ^
3. 五/六月:MVP带来的变化

+ T7 d$ ~* i7 |' U# a; c
4 A' u* ~7 M4 w# K8 C: K- M2 L8 ?" d
4. 七月:规模驱动工程优化

/ [! @2 p. T1 D/ R% d
! q- c( X, b3 N
5. 后续:长期规划、短期见效
: V8 x3 _1 I+ n+ w% L' m
: V8 x. b7 ]+ Y9 ~* `' @4 M
先简单介绍下此版本的主要特性:
" f1 l7 @- c+ _

5 r& ~7 w; {8 }7 v
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:

3 M# ]8 C9 o( L$ d$ e8 I" i" J3 c

6 j( X7 k+ n4 e# p9 i) Q
7 P9 T9 E* r% a; N8 }' l' i" d
1.png
9 B4 [# p6 l2 D/ W
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。
    1 {; f% l$ k8 d, O$ h0 e9 g; w  O
6 |! f3 x; t" B9 G# A/ P5 Y3 l
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。

    6 c8 a' i3 K; J/ Q5 q+ U0 b2 ]  L
" M! d9 ~+ S$ Q, B  H
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。

    & m& q9 y" S0 Y# {- J/ D; T+ y
    3 Z* B1 H  ?9 I( N0 L% ]

1 c$ A3 {! ]" u/ K
1.png

- p3 c3 o; \5 @9 \1 S
写在前面:不满意随处可见

! u$ N- \; c- e7 T+ H7 i
5 ^5 a* s5 R! p* }& e
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。

. P( K0 P5 G, l% w; C

: `( ?* Q6 C2 Y5 I- v- q  Z
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。

& M" ~+ F1 z: |' i+ C
1 ]2 _( h- Q6 Z  @  I
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。
$ O/ z, z$ j8 b6 W( F
: u8 M1 \( K+ o, _9 y
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。
7 ~; X: Y5 m  w% W* t3 Z) W& A
, q. F+ i0 _! b; A1 M
三/四月:集成模型之痛
2 ]: y+ J: l3 |* \  q

7 v$ b5 C8 [7 Q
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。

2 Y- p/ l7 W( Y5 v

. m4 m, E, T3 }7 ?, u, C( F/ C$ p
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:
8 ~! \! @# k6 r
1.png
5 t5 Z7 ?: q% H" Z1 K9 a
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。
    % g, t* `( r; j6 e7 @' @

    , n) b& U' O+ {, z3 g1 X- D  m5 D

/ {9 l! h0 d5 W4 j
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。

    ( p7 h  w: H6 l- d) }# a% c+ I$ T" F: D( z$ b7 n
( E# K+ }3 c* p' I$ z/ |
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。
    3 J5 r4 X$ k/ [" M- p2 n, V9 o) \

9 c' J4 L! d& W9 H# q2 ?( t% l
举个例子,对Jira的集成,DevOps模型是这样映射的:

1 ~" w9 X& h; M+ Q! r/ F! @
1.png
0 }) u8 h' C0 `8 c# R2 |& v
可以看出,DevOps做了不少取舍,同时引入了jira没有的产品概念,来统一管理需求。而对于数据流,DevOps在项目管理中更注重看板与项目报表(进度、效率、质量),日常工作还是建议在jira上去做,毕竟jira的工作流等能力非常强,不是某个新的项目管理平台能够覆盖到的。
$ z% l( U1 l  a! a

- b) A. F, K2 F& s- E. M- _
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:
' ?9 u6 W  }0 c
1.png

: u4 G$ I4 b" D8 @5 S! s2 |/ S  [& s' @' Q0 y4 W
0 [5 E6 [9 G% {! A1 C
4 C8 N1 a: Z' o! W4 T8 F
五/六月:MVP带来的变化
' B+ y# Q# i1 e; P/ O/ c

# Y# x$ d5 g( ?, U% Q+ M' Y' M6 q
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。

1 j. t0 Q7 b1 e5 f9 ^: n

- t8 Y7 Z& N2 z6 O$ ]& e5 N6 W3 l
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。
3 v8 \- O) q. w/ Y6 Y) Z5 W( ^
1.png
$ H9 }+ b: D* V2 {+ R$ T& O# l1 w* X
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。

- p" N" m4 ]" N* |( A7 x

  Y& a9 c9 w% v+ u# i) P% }
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:

6 a. B, M0 U  e4 G7 A4 z/ G
1.png
8 O2 F8 w- J1 G7 Q- B5 O" w" ]
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。
    2 e9 G! u" ^" @9 v
) N$ y8 B, t% X
  • 从竞争角度来看,业界都不易做的,往往价值更高。
    - C$ p, o. D8 [; b6 Y! l
" O' E* ^' E6 m( U0 \/ e$ p
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。
    " V. x, L, i& y7 g

    3 {7 a( [% h" d# p5 A

3 |* F8 X, m7 j

+ S  w/ J. a' y5 l3 G; H
当然,永远不能离开MVP的本质,要保证每个冲刺后交付的版本都是可用的,让大部分角色能参与进来。还有一句话,我觉得也很适合现在的大型产品研发模式:“think big, start small, do smart.”

: H+ w2 x+ X& I1 C* U* U
8 R) X) ]1 Y& j  M$ m8 s: F3 B
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:
: B/ ^5 F, f# D( b- g6 V

- Q3 `8 d3 \/ S, q4 B
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。
' n! Q) \4 O+ l  Z5 u; X

  H4 x* C# S& `/ u7 ?: m% }4 Y8 r
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:
8 b' S' m5 ], z# Z
1.png
1 N* I: F7 l% ]
另一种是我们自认为有技术优势的,比如交付流水线:因为我们有流程引擎组件,使得面向不同的企业交付流程,可以做到动态可配。比如某个企业流水线上,是有预发这一步的,又或者上生产前是需要人工干预和多级审批的,对我们来说会比较容易实现,最终参考界面如下:
8 s+ s( t2 z5 y" x! [- `

- V) Q. r( U3 H% p

3 B0 X: ~3 r5 F" u9 I$ k
1.png

# o8 B2 E. [1 I
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。
8 i( K6 ~4 J5 I6 o7 N. k! ?# _

- S7 X9 y! W0 m3 g
七月:规模驱动工程优化

4 h8 j6 Q9 y4 t8 K9 x# j, g
; d# U8 T' |# w+ Z* o. d
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?
( V3 k% J6 l7 x& w

" }3 ?: |. ~8 Z. E4 A3 @
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。

( |9 O8 X' {  v3 m6 D( k8 @+ x
1.png
! j( d$ y9 u/ X8 h' k1 x2 [
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。

/ j6 ?: c0 u( Y/ w
# t! `) H8 i) ~( _
对于我们这么一家以产品为核心的公司来讲,如果产品线和产品线之间采用太多不同技术栈,产品部门与事业部(服务部门)不能一起往前演进的话,即使某个产品技术栈很先进,缺无法让公司所有人短期接受并掌控,就永远做不到全面推广。
4 ?; W$ I) y5 p+ \

- a* k7 K% X! Y0 [% t! a0 p8 X0 g
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。

4 _3 b& R. j7 u4 C) @9 ]
/ l; B- W7 X# @( W: k* \
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。
' V3 Y  z6 T8 g8 B' O. ^

* W5 S# g6 F) a( }$ ]: b
- _& N$ J& x" {' x& b
我们的思路一直是,从BAPO角度来解决问题:

" x$ e7 U4 [- S! a' }& L

& S+ P9 B4 j  i- y& j6 G) X' g6 V+ Z
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。
7 o0 U9 f6 h1 T$ I$ ^
0 x+ Q( U* |3 f1 w
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。

% D$ c2 G1 l  e  O  z

! G6 i* t' Y0 P5 G
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。

. Z! j4 @1 ]# j9 k

6 ?$ q' v' i( H
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。
7 G5 L4 O, c0 u' o
( o1 K4 a7 F; s
后续:长期规划、短期见效
4 }( s! q+ }; K/ M* B7 s

( @8 q: K- V1 r8 \& b2 ?  L" L8 D
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:
: Y/ F, J9 S7 F: R. G- G- D$ T# v; {
1.png
+ t4 |8 Z1 L; n5 j2 ~& u& h
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。

$ H% ~9 u& Y$ ?5 b/ c' N
% H$ T2 N6 d3 }$ k2 O
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。

& ?5 S7 p1 Q% A! u0 l2 X3 A6 v- z5 U
  g# ~! e; g/ G% [- I
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。

" f, x8 m! h% z, G* |% C

5 N! X, z& ~. D8 n( D& h8 t0 I' v
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。
) A2 z: _) l# g) G
" b* R$ e. |% x1 e7 h- X
: R+ [' A2 T/ U# @
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。

. P0 G2 p  B; {5 w+ l5 ]3 x

1 j+ t: K8 H* Y+ c# e
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:
& O) \; g+ L2 x2 ]& d9 O
1.png

3 ?' M9 q$ i) B4 Y! x
原创:顾伟
# A  g) A1 c4 w# @

# t& A6 T( K& A  S2 d7 x4 R

本版积分规则

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

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

Baidu

GMT+8, 2019-2-24 13:44 , Processed in 0.204736 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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