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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 600|回复: 0

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

[复制链接]
发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-11-5 09:16 编辑
* ]/ P% Q6 `7 ]" f9 r1 L  C4 x- P
DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。
. ?$ ~# c% I3 l9 B9 o
目录:

6 k: b8 j2 q' l: [, S1 M: W5 J

% W+ c7 J$ g# Z# H  l; K8 M1 D
1. 写在前面:不满意随处可见

' h# J3 D3 a/ E( {3 e/ z# q
6 e3 R6 [) v1 d3 w
2. 三/四月:集成模型之痛
5 ?0 ]5 H! ^* O( `
8 A0 a5 W& u8 [, Q% Q
3. 五/六月:MVP带来的变化
6 X5 m# }) t; V1 W% H/ j- A
* \! j. Y- U& l3 ]: y3 Z
4. 七月:规模驱动工程优化

9 d6 }, b; G9 `

' c) O. S  \* R3 G; A6 w* X
5. 后续:长期规划、短期见效
* G. B) Q; }0 Z% \- W" t0 T

9 M% r7 K+ A( }7 M
先简单介绍下此版本的主要特性:
! X! F& X8 ^; o9 _2 {
0 r  a' I7 _4 N! T+ I, q! ^
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:
* U+ ^" l  E6 d
4 C8 {/ Z' w5 G  R

* u) P  _/ @, m+ P5 Y' |1 [
1.png

/ r$ \& z( x- t$ w2 u
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。

    $ P8 j. g2 [* R2 B: P1 D

" ]: x" D- `* M8 s! U- T# I
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。

    & J; x2 E9 w/ Q/ g# N( _

# Z/ j7 g; _; Y) }- X; |) [
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。
    / W) g2 g. ]1 \8 Y: r: K
    ) G5 `; g4 o. d- }' r6 Z( _4 X
& h  S0 C5 l) v$ J: A) ^0 @6 _& t
1.png
+ t' H9 B  w* e3 C' F2 i( M
写在前面:不满意随处可见
) i  }, L' _+ |8 U* G7 ]
- T) ?* Z. u( u
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。

" Q% T. l6 j; K5 E# @# A

# }7 [3 L" D. @' D2 Y2 V- s
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。
/ e6 O. E  p+ o! R5 K

2 h9 N" v  v* r4 ^0 Z0 I* G
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。
, s" I6 W: P1 G; l/ C: A8 q: F
* d6 V3 ~3 f3 E+ v. |7 @( W2 t
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。
6 d- ?# ~! f: r
) e. }/ o& p; f" ?$ @
三/四月:集成模型之痛

. n# i0 k7 K( H$ }, p: B: Y$ [* R# {0 h8 a) t
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。
) g9 g+ @, h6 O! h. ~0 z7 q

/ W0 Y4 N: S0 P! s
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:
3 k2 {9 T) Q# F; P; t& q, X
1.png
" Y" [$ a: p/ {# l" M. {
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。

    8 i( l$ K- r* {% a' A) L

    8 e" E3 ^# q7 H$ T; O6 }( V
' O/ u1 z1 k' Z" {* ]' i" Z
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。

    & Z. L2 Z% \0 l# Y/ Y  M( ?, L0 M, B- {& C1 e

2 B2 S5 i% D0 ^( {
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。
    + g+ B8 i5 }  m: G& g

( E: V9 K! @% X( [9 A& j3 _
举个例子,对Jira的集成,DevOps模型是这样映射的:

# v% M1 U3 E5 x3 y9 o; E) ]
1.png
3 m( e$ i9 ~( C
可以看出,DevOps做了不少取舍,同时引入了jira没有的产品概念,来统一管理需求。而对于数据流,DevOps在项目管理中更注重看板与项目报表(进度、效率、质量),日常工作还是建议在jira上去做,毕竟jira的工作流等能力非常强,不是某个新的项目管理平台能够覆盖到的。

- W9 C4 _/ @: L! [, W, Y: J4 c( a

" k8 S( b9 Q% S" f
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:
5 o( Q% K9 B) N; Q% l5 z
1.png

0 R% j) M4 J8 P3 I  ]2 S/ g% E) r% \- a7 N! `4 H" H- [6 o

+ C( o. Y$ C& [/ f

; f1 k5 k; ]% P0 L
五/六月:MVP带来的变化
: H1 e3 R* a3 \/ y' G( {
8 I& n4 D# B6 M- x+ i
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。
1 J6 _( D% V3 I5 ?) W# {* c$ j6 _
1 O8 a$ A1 Y5 d- i
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。
: `; R, b5 l  K) D
1.png

) {4 A& C2 z( j- \) Z1 [
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。
' s& f  K9 ]$ Y- G! M8 |# i9 r! v
* H% T  d$ r4 Y( k5 T! n: f
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:

. z+ R( c+ G- x* Y6 }
1.png
5 X  Y0 o) }5 y1 N
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。
    5 D! m* D% Y. V- n( q
% k4 M+ v! d; M8 F' p8 B! ~, e
  • 从竞争角度来看,业界都不易做的,往往价值更高。

    6 _% v0 Q& |1 y- j, P
9 c: G7 x+ v4 w1 v4 N% ^
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。

    " S# Q, x" ~0 g/ w9 I) j

    - r* y' x  x! h7 t
" X7 H! x. {) _# }: V* g% u, \

) c' u7 K' s- c$ A
当然,永远不能离开MVP的本质,要保证每个冲刺后交付的版本都是可用的,让大部分角色能参与进来。还有一句话,我觉得也很适合现在的大型产品研发模式:“think big, start small, do smart.”

# }* r& R" g8 N

* i; b  c! k- H& J& I, @' A
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:
& ], d5 H" U, p. n+ ?4 K
" M1 g( ], T; }4 U+ d
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。
6 D% }+ d/ V; n/ B7 u) x& A4 t3 Y& G
! R: z& D" I/ w* Q& j
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:

" t" _5 z' f! C  y
1.png

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

& ^5 K2 Q' V, ^6 y6 R6 l
0 y$ d6 ^: r$ _2 p

3 }" L+ d- }8 i* H4 Q' m, z) f
1.png

9 X' v) Q/ g" {# t2 R
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。

6 B# H9 a: B4 [( |4 ^3 N* L- N3 d2 X: p+ f/ w* J) N$ b' e! t" u0 n
七月:规模驱动工程优化
, D" B) H, X6 W, }  q
) a/ i" W; x, J1 G
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?
' h7 [  g& i- N3 o6 p/ V9 K
" V* |4 i6 Y& v$ x1 ?# h: `$ @
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。
' [' G; T$ J$ }2 T, \
1.png
4 f9 y) }% q7 t1 H6 _/ \/ O1 w* G' I) h
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。

7 K: K& d) O3 Q2 T+ ?2 H

# w+ R$ G  c* I: E
对于我们这么一家以产品为核心的公司来讲,如果产品线和产品线之间采用太多不同技术栈,产品部门与事业部(服务部门)不能一起往前演进的话,即使某个产品技术栈很先进,缺无法让公司所有人短期接受并掌控,就永远做不到全面推广。
, B! }1 l0 ?+ c  `6 c7 D5 ?# _

5 L0 ?& j+ ~( S9 L4 z; x9 w. \& {
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。
: Z& S& X1 w/ c% V' t

0 D1 q* ^9 g8 R* y3 P* t  I3 c! m# `+ R
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。

1 {1 p4 u" V7 B- e! j
# U& d0 t/ a: y( t

) p0 M5 T8 o9 g! T4 {  ]6 q& J# T
我们的思路一直是,从BAPO角度来解决问题:
5 n1 S6 _: l. V4 F5 z4 s/ ?
5 q1 x- b* Z0 V# L( i, T
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。
, j+ R0 ]/ j0 X, r5 W

# e+ f8 X- e2 G6 S
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。
% s# Y2 S7 h0 X0 W9 [

5 _8 z+ \" A! N4 S. @5 \; {) W
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。

7 }5 J4 B% b! z

- _! x% |# ?% h" O9 W" b5 `, k
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。
; L% w7 n* ]  t/ w$ [

! \9 j3 C& d0 Q2 w0 Z! `
后续:长期规划、短期见效

% s& I, g8 T& O; D+ a# L7 X2 S1 ]6 I9 z
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:

: ~" I4 x& g$ z4 k" {
1.png

5 Y$ Y3 Z) z: y3 B( \
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。

; s, ]6 n! q8 j
7 _0 {4 c* d5 i3 f; I# y
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。

% R9 ^4 Y5 a5 n% t* }# |, }* H* F6 P
" Z2 }' a$ \- }+ N5 Z
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。
4 C3 p0 C! @5 U

/ u# n6 {8 M- g7 f8 C+ \
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。

4 ^/ N& ?* {/ p9 L* w% ?

0 y5 g7 l* z9 h' [, }6 b7 g2 G5 V3 \, ^' K5 Y$ O2 N
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。
5 J: V4 C3 ^' a% O" C

" P0 R' y! v* h2 n
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:
7 ]; o: G- y5 d4 r, ^
1.png

3 A7 j, ]' Y5 h4 v( p
原创:顾伟
5 A5 t8 Z# f  @* j# _& [
4 c7 N# f, F0 U( ?- ~

本版积分规则

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

Baidu

GMT+8, 2019-11-18 06:27 , Processed in 0.158757 second(s), 25 queries .

Powered by Discuz! X3.4 Licensed

© 2001-2017 Comsenz Inc.

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