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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-11-5 09:16 编辑
% t3 G# @+ B# x9 ?$ \
# E% C- a3 p2 O- y* ]
DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。

5 Q( Q" `3 m$ M+ Q
目录:
( n6 i3 m  A: |2 E  B% F" l
& L7 Y. z/ i6 M1 h$ b
1. 写在前面:不满意随处可见
9 R6 |2 b1 J) T8 {  t( a& I' v( I

0 P+ B! y& z% d2 Y0 C6 h7 O: K, u( v, b
2. 三/四月:集成模型之痛

$ d9 J6 z* x$ O$ k

4 C9 p5 _- h4 @4 u7 P" r% Q
3. 五/六月:MVP带来的变化
8 }& Q. s3 H3 K
8 I# K2 i* c( j- }
4. 七月:规模驱动工程优化

7 Q4 {$ ]" p0 d; P( I
% L. |7 X3 L5 Y
5. 后续:长期规划、短期见效

0 h* z9 @! a0 B
7 c7 X8 z/ {; I9 `* F9 q
先简单介绍下此版本的主要特性:
$ S* ]; d  _# t

" K, z: ]1 k, @* i& p7 m
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:

' }0 {! G% j( \; J! K

  I/ I1 F5 q( x5 v1 C
0 E. \3 Q5 a7 o4 ^; P3 O8 t% B! P
1.png
3 _6 T. |& X, m) h$ ~6 B* i: @
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。

    ! q' i7 W5 f  z8 u# w# a4 o

$ Z. ]1 r5 B* R3 P) W3 A
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。

    8 N2 p: V2 J) U3 Y5 B

. R" l  I- @+ M: D
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。
    % v9 ]  j* x/ @9 y

    / z) e& K) |) I

% d8 }! `! r9 M6 B3 O2 H
1.png
6 K; a" i8 {3 X) @9 w9 U7 {
写在前面:不满意随处可见
! U" w3 P0 u8 `( t7 }) A0 e

: t& ]1 G7 Q9 ~
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。
4 O# U& R3 m$ T/ S* s6 t3 a8 b! a

9 V8 J0 q# r9 v- H
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。
. z7 M1 \. J; ]  f' E. ^
0 Z6 u' `& g. e  }, x( J/ @4 g
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。

$ l( O, W- X; h' D, ^% {

- u$ U! V$ j  w/ W5 o+ C4 {
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。

9 {! X' `4 A% O& B9 j3 \
" Q& R+ x2 A! g) Z
三/四月:集成模型之痛
9 Q2 z, ^; T+ M" l; U3 Q4 G
3 _' `7 T5 o, K$ X& A
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。
. O0 D& \0 ~" ?; f2 A2 L6 W

3 F  ]$ J# Y- V  W. O; c
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:

7 c8 u8 v8 z7 U  h  ?  q* A& u
1.png

7 u+ Z. U! ~+ K! P) E
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。
    6 U7 h) P2 A5 Y$ _# k1 b* `4 v9 A
    ) B3 T1 D5 v1 p8 v

+ X( c% M+ c1 B2 A$ X9 @, [
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。
    5 Z" j! v1 L; Y) K# l
    + c; `- O. r" t: r% k

: C7 z! S9 w( M6 A
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。

    * m% |0 g% B3 i$ |
8 [# G% l4 S3 v) {0 h
举个例子,对Jira的集成,DevOps模型是这样映射的:

0 |; [; d; ?& }# [+ W4 z/ F5 ?
1.png

5 b. D7 M) h; `0 b1 B9 E( B$ t
可以看出,DevOps做了不少取舍,同时引入了jira没有的产品概念,来统一管理需求。而对于数据流,DevOps在项目管理中更注重看板与项目报表(进度、效率、质量),日常工作还是建议在jira上去做,毕竟jira的工作流等能力非常强,不是某个新的项目管理平台能够覆盖到的。
8 O: X& D5 ]& N  `' G

: G' ~& w& Q7 Q/ P
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:

& J: s- y! Q6 T  Z
1.png

9 {( X$ a, Z; w" p4 e/ x/ D, p5 t. u- K+ @
9 `5 }( F" A3 S2 y0 C
, J5 O3 Q# D( s2 Q! _% M
五/六月:MVP带来的变化
, Q6 e+ L+ y) x

0 P9 P. l8 _4 g. m" |# l
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。
7 s5 c* r( s5 e6 @
1 D3 J, q/ u6 y: c' \
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。
5 a& |# n  j7 Q+ G
1.png
: I0 c: X, i7 H# q# W" `0 x$ G. ]1 ]
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。
1 g3 x) [% H+ I' H- U8 U' K
! |$ p; K* _) k5 {
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:

% u, v' P5 F# t4 V" ~/ U5 @
1.png
& I& u2 S* R! G
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。
    4 M# v8 I5 [: x. L
2 s0 Z  W1 X2 m
  • 从竞争角度来看,业界都不易做的,往往价值更高。

    ; J" z: j0 r* W$ w
# V0 o! t# d% Z( d4 \+ V  b/ |
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。

    8 {2 V' l( j* W& p3 [- B
    ! d6 ~3 x: W  E4 |/ @

3 J" X: A2 g9 {( @+ b' H( j% b
9 i! ~2 R& A/ j  }
当然,永远不能离开MVP的本质,要保证每个冲刺后交付的版本都是可用的,让大部分角色能参与进来。还有一句话,我觉得也很适合现在的大型产品研发模式:“think big, start small, do smart.”

# j0 i' e7 H  Y* J( x3 w% s# n

( d* J7 x$ y/ n3 G/ R  Z. L
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:
& P# e- w+ @0 r: B0 `
2 {8 @  |+ n. Q) h( |; ?0 ^  f
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。

$ s: o8 A- w" o/ D- X
2 @  \3 t. R2 t- z# V, \' S1 a
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:

4 u" g% O8 M, d1 A$ b4 v! Z
1.png

( N- T: s% c" i# Z$ \2 F
另一种是我们自认为有技术优势的,比如交付流水线:因为我们有流程引擎组件,使得面向不同的企业交付流程,可以做到动态可配。比如某个企业流水线上,是有预发这一步的,又或者上生产前是需要人工干预和多级审批的,对我们来说会比较容易实现,最终参考界面如下:
2 O( x  S5 _, O/ a$ \

3 Z, p: C8 D+ @* J. l. p

- l9 P/ ]' l7 j6 ~1 O
1.png

. y' b9 H0 y! a2 Z: H
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。

! F2 |' ~  h0 `: K8 l5 ]
" A/ U! S; g2 y
七月:规模驱动工程优化
: W& a  F# ^  T! w6 T0 t# P
. j' O0 z$ x/ T. U
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?
% ]1 b+ a8 N& ]; w* _% k: B

! H, m& a3 P9 W2 W' Q4 D9 o" \
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。
& {$ n. c4 y1 }5 z  l1 E
1.png

' h1 v* z+ l- @( k: o
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。
4 A2 j" U- H+ D( z* p' Y& Y
& ~2 J/ Y0 P9 |9 P' |1 g2 h7 ~
对于我们这么一家以产品为核心的公司来讲,如果产品线和产品线之间采用太多不同技术栈,产品部门与事业部(服务部门)不能一起往前演进的话,即使某个产品技术栈很先进,缺无法让公司所有人短期接受并掌控,就永远做不到全面推广。

3 s& @  T9 G2 R2 d# }- u! |
1 o8 z1 J0 @5 V8 Q  ]
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。
; J4 ?" Z/ n+ [  n$ o+ w1 ?
4 t) S+ R2 A3 d
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。
3 j* C$ |, r$ V; i+ M# t
! g( Y" v5 h4 h3 u( X+ n! M' c

' V( ~, i+ d1 X0 G$ j
我们的思路一直是,从BAPO角度来解决问题:
  [( L4 p7 A" I/ V2 Q7 N, H  Y0 M: t
3 X0 \4 [2 A4 {4 x- m' J7 U8 m
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。

/ g' Y' X+ O* e  j' n
+ ]% B  a7 ^* y' L1 @
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。
: B- c3 j$ H8 w% t. S4 s1 c

! G5 \) J+ |4 A7 f8 o* E
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。
5 @3 H8 w4 W! t; m! y

8 f5 i0 s- m% w1 Y
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。

# b! B3 g7 m- H

0 x6 n2 C! P$ T0 q( f% n" ^
后续:长期规划、短期见效
. v$ N" X' N  i& H  l9 U

/ T- T6 s, ]; t/ ^( {4 l
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:
4 M* m$ B- S/ ~& ]
1.png
  \  w( K( g! j  T
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。
. b( Z- [4 |! ?/ Q0 n5 \
3 b' @; W: J- D1 n
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。

+ q4 ]% W: V1 F9 S! U
! |! ?3 s/ E( P" f
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。
6 u& a( F6 J6 l# u6 o1 r% f
$ L# M; R0 u) V2 w5 P# u0 w7 S( Z
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。

& {% `  `2 E3 H9 \3 x+ p

5 M) Z% m) y3 D6 e+ q) ^/ `* V) M& z+ A* P6 a* _1 W
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。
( c2 P! ?/ e# g5 S' V$ V

9 [; @9 t8 g2 @; I7 ^
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:
( B; ?* s% {  M
1.png

7 }  d8 S1 R$ ~- r  _
原创:顾伟

- h. T. }  ]+ S" b1 Y
. I- X. z; x* _

本版积分规则

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

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

Baidu

GMT+8, 2019-4-25 00:20 , Processed in 0.201089 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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