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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 375|回复: 0

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-11-5 09:16 编辑 9 s# D: m9 v0 P, `( F8 T
' ~$ O) K" @3 G
DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。
- e# U$ e$ v, K& C+ ~
目录:

- _- R# u. U3 x& ]. d2 C

' V. j0 V: R$ t+ a9 d
1. 写在前面:不满意随处可见
$ V( E0 g% S  a% ~
" N- q- t- N3 }. h- }* h
2. 三/四月:集成模型之痛
' h( {! K, C' q& u* J

" B$ E4 S2 A; e; A; y: j( s- Y
3. 五/六月:MVP带来的变化

9 G" Q( f- ?5 M4 \
; ~2 o1 a4 i& @+ }' [1 Q
4. 七月:规模驱动工程优化

" c( L' ]0 y. [$ j+ f

  S0 c' q7 D9 k5 p$ `5 n& U0 o; `
5. 后续:长期规划、短期见效
4 }  Z# L" J' K1 E8 W5 X, W+ X
" I8 b" s6 g+ _2 |; ?: L
先简单介绍下此版本的主要特性:

( D' P. ?, Y& f0 ~: L

) u9 d- J! b; E
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:

; W1 g7 ?9 f% q+ q) p

# s! j3 D  ^; d. s
0 L& I% @4 N! b7 ]
1.png
% d2 Q, N; f% L
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。

    5 l0 Q( y7 ^. `
# [. s- G9 {6 w
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。
    % I% p+ ^  `. n

2 V6 h; i: Z/ N8 v
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。
    * v- t; G" H( K
    5 R' Q  E" O$ m6 W8 T; G- [& c

! g, u/ r& `  B1 s1 O
1.png

9 K+ \9 d# t+ p
写在前面:不满意随处可见

6 ?1 C# z' @# c  Z1 R* e+ P1 _# D
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。
$ g- |8 s" q/ J$ k; [
7 S% z) c0 m/ e9 A8 u3 A
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。
3 i) d9 [. A  X: L- A" a" L, |4 H$ i) [
# ~0 j. V1 @  w: h! U0 g
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。

3 l& U; Z/ V6 E7 w: M  N3 d

+ K* N! \% M1 j% _
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。
* l' ~* N4 t" A

/ X3 Y/ V4 ?# h: o
三/四月:集成模型之痛

$ Y* \  W8 l, M9 E) {2 M: U3 f0 T. e3 u2 K2 q; m  g8 @
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。

3 E! E/ R3 `( K' C) @' o7 ~
6 Y& J8 @* t4 j6 r
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:
- F+ g% }7 X2 N1 ?2 a% F5 x% ^+ |
1.png

7 Y6 ?) ]3 a2 N2 d  t
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。
    2 d& o0 S0 q! A. o5 G* Q' K/ N# f

    + {$ G' p3 x) D% v) |
0 B3 ?/ Q' s' |  B! h: Q+ b
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。
    7 {+ Q, ~! q- O3 {# z0 R* M9 c$ ?8 f
    1 K; i) ]0 |# j9 p' N7 `' _. ]
6 `5 d; F- X8 a/ Q% m/ e
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。
    7 h6 q# c, v  Y: Y. S
' ~2 k" e8 e' x
举个例子,对Jira的集成,DevOps模型是这样映射的:

2 A! w* S. X' \; Z' P
1.png

; ~" r5 I! V" W( x
可以看出,DevOps做了不少取舍,同时引入了jira没有的产品概念,来统一管理需求。而对于数据流,DevOps在项目管理中更注重看板与项目报表(进度、效率、质量),日常工作还是建议在jira上去做,毕竟jira的工作流等能力非常强,不是某个新的项目管理平台能够覆盖到的。
  J) B2 r) b7 Y4 V# N; c8 \
8 h6 P, C# ^% W* I! A8 |8 ?
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:

/ g, k+ u3 G& V3 Y  ]
1.png
1 T0 j+ n+ D: k9 J- k
' {* |& P; q# a' U% I3 G
- W8 M( T$ i* `, i3 A

* b0 a4 U% C' s7 U' _. g0 }
五/六月:MVP带来的变化
! n9 S; x9 M6 v2 i6 v# E* x

% C7 j8 Q4 L3 N. M  N- B( t; e7 }5 p* D
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。

# Y- H6 J) v4 F! C9 N: p

4 X! a( z$ G8 R; a/ @0 ]
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。

  F4 t4 d+ i+ l) a. L
1.png

* o1 F# P" o4 Z. Q6 q( o  [% r
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。

, r" V6 ^7 A2 H7 J/ \1 F
2 i7 F9 R0 Y3 T
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:
+ U% l8 o+ A! X) t- R# w& h2 n
1.png
$ N7 i6 [4 ^/ S- i
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。
    . B. }& B# _& W4 e
* k; l1 D+ [# ^( C
  • 从竞争角度来看,业界都不易做的,往往价值更高。

    1 {! N; T$ S+ Q. J$ g
0 ~8 {) `5 M0 N' c
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。

    + O! W6 D4 g3 A" z

    5 e; J: q3 U' `: v. _5 b; d& t

1 k# z, g. R1 z
( q! Y# _' Q6 C& z9 k% ]
当然,永远不能离开MVP的本质,要保证每个冲刺后交付的版本都是可用的,让大部分角色能参与进来。还有一句话,我觉得也很适合现在的大型产品研发模式:“think big, start small, do smart.”

, W- R' {) Y( s% \8 i

; f# F3 `- ?5 T7 g6 a; ?
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:

7 Y( C* a6 f, _  }

0 X( d' G: k  F, c& f
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。
! Y7 X; h5 B7 l% J7 ^4 g/ b

/ h2 A7 S. x& N1 |8 A/ ?
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:
: E5 y# T- M* ~& W$ a
1.png

# ^( F' Y5 r: `, ]
另一种是我们自认为有技术优势的,比如交付流水线:因为我们有流程引擎组件,使得面向不同的企业交付流程,可以做到动态可配。比如某个企业流水线上,是有预发这一步的,又或者上生产前是需要人工干预和多级审批的,对我们来说会比较容易实现,最终参考界面如下:

) z- c. G. g5 y! V6 y

+ g# j; _2 u4 x7 J

4 r& x! I+ C/ \0 e1 b$ a" u5 E
1.png
: @- _" A, H1 O! [, \
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。
+ [- f7 }& O9 k) G) ^

, {2 U- i9 L" X' n4 o
七月:规模驱动工程优化
5 _9 L& [8 A1 X

3 g; i- n1 J/ O$ S% o/ M) z
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?

8 I* j/ E! A7 T- `+ v5 V9 ?+ k
' B5 `5 I0 E+ K, S* u6 k) w
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。

& O# M# x( f. U0 k0 s/ F) v4 G* U
1.png

" a5 Q. w& @$ X. Q" N
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。
6 D) s- }; l2 `# W( B5 J

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

% n1 L" P$ X, n& q$ n! l
4 N( K  |+ ^- O
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。

: |: \6 Z( d  B( ?! ^: i; F# m
: Q) `8 r. l0 ]* v0 {" l5 a
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。
8 P5 Z) G) r% |: [! m5 Q
% y& C# b+ K- v# n) R

/ D* w% b; K+ u: j, A# o6 [5 b3 T- W
我们的思路一直是,从BAPO角度来解决问题:
3 _8 |& c$ T" L9 Y4 x4 ~( X
+ c3 P) `( Z# T- v3 @3 ?, F
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。

2 H9 y2 U+ w, X- ?/ B
) h3 {+ [6 U0 |2 X% h
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。
$ {0 G, ~  o9 [& b! W

1 G; Z- \0 e( F, e5 C- z# [( T
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。

( {) U/ h8 x4 M0 l

' _$ j2 X( z, @- ~( x# ]& r
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。

/ D! e2 b+ a3 l; J

) x% s. O7 ]9 A9 U
后续:长期规划、短期见效
/ E" P% k0 a5 f% s+ J$ J3 }8 L

+ H; \2 Q. o& B
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:

/ S9 a) D) m, R- C9 o) b
1.png

9 b( f6 E5 q! G: d/ s) R) t7 q
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。
# b# T( {' k! Y8 O" O
: G, w+ H" u5 g( i
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。

, u" F3 l! a1 `( N
( c1 Z5 h9 U6 W8 M( ?
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。
: Z& ~2 x" @. C( t- T" v/ V

7 a% `* w" {! t, r9 ?' q- n
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。
0 e8 N( Z$ V# n, R( S# U

8 N/ y( e) V4 Z1 o. Y( P) ~4 B1 r1 o) {7 Q; U6 B5 N1 V
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。
5 \8 o' w' P3 D. R( a" j! z

, x; s$ _7 f/ f( ?# S* p
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:
8 [3 \& K; y; K) h: U6 V
1.png

: A* o1 Q9 q# m7 n$ n
原创:顾伟

& s% p# m/ Z& W
6 @9 A0 Q' [' R$ n7 S

本版积分规则

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

Baidu

GMT+8, 2019-6-17 23:07 , Processed in 0.218338 second(s), 31 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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