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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 1352|回复: 0

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

[复制链接]
发表于 2018-11-5 09:11:17 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-11-5 09:16 编辑 5 o7 i; s. L9 D. h" T
) g. n1 J5 M/ f" q
DevOps产品差不多三年了,中间经历了诸多架构变迁、团队变动、业务目标调整,终于在七月下旬,正式发布了DevOps产品的 5.0 LA版本。这个版本从三月到七月,历经大概150天,每个阶段都面临着一些痛点,在此与大家简单分享。

4 e9 s% x8 X7 q3 r) L  b+ e- ?
目录:

! c. J/ R$ _( u+ a/ N
- {8 f% ~6 a- Z) j$ f
1. 写在前面:不满意随处可见
' b( |* x. a5 y# R& x' d% D
- A0 l5 L8 B- c" Z& r; _0 b3 W+ y
2. 三/四月:集成模型之痛

2 M$ O2 |+ j. S$ U1 `6 r
& B, P2 K: |" o4 B
3. 五/六月:MVP带来的变化

9 I. J: B# g& a. v

- K- K6 p6 g/ Q
4. 七月:规模驱动工程优化
% M: _, z. m* E' g4 Y9 p+ i2 K

* q# Q& Q7 b: e7 _
5. 后续:长期规划、短期见效

1 R  P  Z4 h  f* p' t5 P
, p% A) G7 A" J
先简单介绍下此版本的主要特性:

+ C5 s! q" [9 a7 _

) D; p) x4 Y- L/ }! Y
此版本覆盖了产品管理、项目管理、持续集成、自动部署、交付流水线、精益度量6个领域能力:

( z6 @- m  `- P

9 v1 W9 z7 I2 X# o
- ~: R! `. b. H* l, ^: e
1.png

+ `1 ], x7 [1 @
  • 平台对外提供全面的开发运维一体化方案,已经受过大规模生产验证。

    * ~5 C7 |" [3 C6 R, Z  c

' Q& z$ |6 T+ W  z8 p# D
  • 平台不强调全自动,更倾向于在企业流程体系下,通过持续运营,提升生产效率。
    % Y* L0 c: z% n9 _9 Z/ E0 e

5 S" E" `0 F( {% M  @
  • 平台与微服务、容器无缝融合,兼容不同基础设施,为开发、部署等能力要求提供支撑。
    * [4 S! P& x: q3 p9 Q1 V) {- T

    . M9 |+ q" U! ^, R9 v5 y2 a

3 j% ~5 t* l# f7 q( M
1.png
1 d; Q5 X& Z. W. m7 l
写在前面:不满意随处可见
0 d0 }! _+ X  J7 w
, H. q9 V2 B1 L  T8 U( H6 D+ p! }
每一次版本研发,看着前序版本,都特别不是滋味(一般开发同时会很通俗的讲:“每次看到以前自己写的代码都想抽自己”)。
! \2 z5 S$ K$ J+ ?

: t- l2 k- t- ]8 K- Y
比如,之前的版本中太强调项目管理的敏捷,却完全没有考虑企业版本火车式的敏捷,记得去某个银行时,客户上来就问版本火车在DevOps平台怎么支持?我承认,真的没细想过。
5 s+ v7 R) h' e. i1 \

6 d; [/ ~  @" n5 e" H* o; a
再比如,之前的版本太注重基础能力的建设,没有太考虑DevOps要千人千面,把概念模型简单粗暴的映射到界面设计中,是个很严重的错误。

: ~' c6 g. _' x/ u/ j  u

# j- K. _$ A' D3 ?2 ^" F
诸如此类的错误还是很多,暂且先不自我批评了,回到现在这个版本,我们在研发过程中遇到的一些挑战,是如何面对的。
; w2 r6 Q5 L' t( N
$ [' Z5 f! m- A' \+ I$ [9 E
三/四月:集成模型之痛

! h4 m, r% O+ _9 g! W$ C( t* S+ G) B2 y/ c4 W1 y% ^+ k% S
对于DevOps平台来说,核心价值在于将不同阶段、不同工具有机串联,数据打通(所谓横向打通部门墙,纵向打通工具链),所以势必要集成常用的一些工具链。

3 K7 U& K, @6 a1 L% q2 ~. c1 d

# M# L6 E& ?; F* C6 G
做集成类项目的同学都会比较清楚,集成类项目常常面临以下三个难点:
/ B* d5 ]% Y/ {# N
1.png

$ b" F" \* ~* I" K2 j7 s. p% p! i
  • 集成类项目最大的难点是模型适配,比如禅道和jira,都是项目管理工具,但底层模型区别很大,这就要求在集成时能够抽象出通用模型,甚至要做一定的能力取舍,形成标准模型。

    . a! F) R( u) U  {) @' E
    - q8 K0 d) Y' c5 s: b- X+ q( ~
+ y7 n+ l- Y) I, Q* |+ @4 s
  • 从技术来看,大部分三方工具都提供了rest接口或对应客户端,但对于一些长任务调用,需要考虑异步或者CQRS模式。比如Jenkins集成,通过api调用得到key,后续通过任务key获取pipeline状态,也可以通过pipeline对DevOps进行hook回调。

    4 W5 h% P) R: l" U
    ! J/ s1 r# O9 t% ~* b5 M
4 l4 B3 ?* ~& |( j4 d' b4 Y
  • 从数据流来看,DevOps平台现阶段的比较现实的目标,是支撑80%的日常工作,很多专业工作还是要到原有专业工具上进行,所以在集成时,需要分清数据流向(哪些以查询为主,哪些以操作变更为主等)。
      P! q+ b4 b* Q: K  @, }% h1 f

2 ^0 w) Q) z8 L7 O% E0 q# x6 d6 A
举个例子,对Jira的集成,DevOps模型是这样映射的:
+ x! Y! B" `$ R5 z# M4 D( f
1.png
  k# N% X, Q8 w5 L5 T
可以看出,DevOps做了不少取舍,同时引入了jira没有的产品概念,来统一管理需求。而对于数据流,DevOps在项目管理中更注重看板与项目报表(进度、效率、质量),日常工作还是建议在jira上去做,毕竟jira的工作流等能力非常强,不是某个新的项目管理平台能够覆盖到的。
3 Y& O" ?3 h) p8 R3 R' t- P

  K/ }/ x' e4 ?) k. P
通过不断的抽象和调整,最终在这个版本里,集成了如下工具链:

/ r/ F3 a& h5 H0 @4 c9 H/ E
1.png

: h: V" `! Y9 T: D% i8 E5 K* i1 k$ G& M. S
8 E( ]" _3 n2 s. `: l8 {

2 h) m, f) T  q4 M2 E/ o; [
五/六月:MVP带来的变化
4 t- r$ N8 u: J- Y" Z7 Y$ I

1 r3 {7 ?) X( J! G' |9 y0 v6 r* |
这个版本属于实施带动研发,客户要求月迭代上线,这对我们的计划安排、研发质量等要求都很高,遵循MVP的交付尤为重要。
- k  H. m# B. m  x- B5 {

* F  Q6 P' V8 X5 |. S
先说说何为MVP,如下图,要让每个阶段都能有可用的产品,全称“最小可行性产品”。

' H% r; h9 u7 ]& e' D3 j# V- p
1.png
$ ]. B' k' r4 h$ Y  R' }0 M
但顺着上图不难看出来,其实从可重复利用的角度来看,MVP的方式反而有一定浪费。毕竟造出的滑板车,在汽车产品上是完全没用的。所以,如果是低质量的MVP,后续耗费在迭代改进上的精力反而要更加恐怖(毕竟不是每个版本都是一刀切的)。
* H# w2 {  n; I: t3 ^/ `4 e1 c5 }
$ ^* {, H) f8 e$ J- ^4 b
而对于大型产品来说,使用MVP交付最重要的一点在于故事的合理分配(大小、优先级等),回归产品经理的本质,在“人人都是产品经理”中,会告诉大家如何找到最有价值故事,优先交付:
3 G) B0 Z1 f, d$ ]# W7 Q5 W# C* Y
1.png
3 v' G, m% [) q6 T
  • 从意愿角度来看,要做的故事往往是非常多的,在有限的时间里都完成是不现实的。

      I1 j) i: C) c( H

8 T7 ]. K& Z2 {( {
  • 从竞争角度来看,业界都不易做的,往往价值更高。

    1 Y4 B/ D7 W( z
; j6 M* q; s1 |/ ^) o
  • 从自身能力来看,不要一味的盯着那些还没有太好方案的需求,快速完成能做的。
      z" r% `1 z6 f$ g9 y1 x0 S

      L% c7 Y7 K' L8 v7 j- S7 R

  w8 m' p8 Y; \& [: X2 h

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

  X/ ]3 ?; g* g4 x( ~
2 D0 G! F3 @: G! ^7 I% L  C/ @
结合上面的思路,在迭代过程中,我们对故事进行严格甄选,有机会大家看到我们产品时,会发现有些特性,在上面明显花了不少精力,而一些比较普遍的特性,可能反而没有做的很完善:

  V# Q& `* b( @- Y2 L" u/ T1 b( t# |

' X& J$ u$ f4 I. |" C& h7 S+ O1 C
一种是我们认为理解较好的,我们会优先并花更多精力去做,比如自动化部署:参考了oneops设计,将逻辑部署与物理部署架构分离,通过在线部署架构的设计,再将其与目标环境或资源、以及具体部署策略等关联。

' j' H. j5 C1 t9 r

8 N; X5 p6 |( ]( O
拿标准的三层架构举例,nginx+tomcat+mysql,开发环境中tomact部署单点,生产环境中tomcat部署集群,其实就可以做到一套设计,多次转换形成最终的可执行脚本,完成整体应用的多环境部署。设计思路如下:

6 c2 X5 _' o0 b  x) E: M
1.png

0 _  D% k. m9 k; G/ c( p: o
另一种是我们自认为有技术优势的,比如交付流水线:因为我们有流程引擎组件,使得面向不同的企业交付流程,可以做到动态可配。比如某个企业流水线上,是有预发这一步的,又或者上生产前是需要人工干预和多级审批的,对我们来说会比较容易实现,最终参考界面如下:
/ P" @# b7 T! ]; E' \/ N8 {

+ ^# g1 ^. ^- V( Y6 u4 V7 {

7 C% ?: y2 e& }+ q5 J5 y0 G
1.png
2 y- ^: z% P' t" j" |0 ^; p
正是在这么一个个“有取舍“的迭代中,我们才能在有限的时间里,完成了近30W行代码的版本交付,并在每个月完成从测试环境到生产环境的发布。

. a8 D0 K0 N5 j, E
; K) H% s: X, g5 v
七月:规模驱动工程优化

5 H& I: M  y8 v+ l! t+ |* Z" X9 ~5 R2 t- a
一直有客户在问,你们的DevOps有没有使用微服务架构?业务和技术上究竟是怎么拆分的?
6 t1 |4 b8 n0 s: w- [

5 o2 E/ \0 |* r7 [# @% [1 }  V/ y
我的回答是:早在1.0版本我们采用过微服务架构,将其拆成了十多个领域系统,但在这个版本我们合了。

7 F, c' D6 ]) s
1.png
/ `% F. D' B! u
做事要有激情,但切勿激进。同样是造车梦,马斯克和贾跃亭,至少从现阶段来看,结果是不一样的。
- J4 Y) m) J" d; j+ ^

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

  J' B2 Y2 G" @

% D% F- m* k% L2 K! C8 O- |' d, b( v
话说回来也许有人觉得我们还是太保守,但事实确实如此,这没法和互联网或创业公司去比,传统企业在技术演进路上肯定是相对慢一些的,更追求工程化和稳定性。

# A/ C1 g( \7 F' o! j6 ?; ~3 }* q

/ E6 m  }0 C1 r. }4 c4 f6 [' W
在7月,随着外部项目的增多,DevOps的实施面临着更多工程化管理的压力。如何从单一团队负责交付,发展到多团队配合?如何从孤立产品迭代,发展到企业版本火车交付?这些都是工程化要解决的问题。

0 g/ P. k. V2 m9 T8 q+ u0 H
# u3 R9 Z( K4 T7 n9 d! S
7 p& B5 l  J& Y) F; F
我们的思路一直是,从BAPO角度来解决问题:
+ A; D' y- x& w+ B4 v. X
0 Y% W' M) G8 Z' c
业务角度:多产品形态,往往不同客户的需求从大块上来看就是不一样的,有客户要CI,有客户要CD,有客户要项目管理,所以面向不同的业务目标,产品需形成对外多形态、插件化。
( r5 a! |4 j0 @- O7 q# i6 Z

6 v7 A% U' }6 k" w3 C( p
架构角度:微服务、容器等生态逐渐完善,前端技术也变成了react与vue等少数之争,这个时候我们对架构逐步升级,面临的风险会更小。

* P0 Q# S0 T* b* ^  R5 B! ?+ N
1 g0 {9 A6 l! |1 C5 O" W
流程角度:DevOps强调持续迭代、持续交付,面对不同企业,细节流程虽有不同,但开发流水线,测试流水线,发布流水线这些却都是必需品,所以可以通过流程梳理,形成落地实施规范。

4 ?0 u! d4 c! P% z. N

5 O' H+ [" G. O' Q4 s4 Z7 S. E/ T
组织角度:团队加强配合和学习,比如与事业部部门的代码共享,我们推荐使用fork模式,事业部逐步掌控,并能将一些实施过程中的优秀特性pull request过来,反向帮助提升产品。

$ I7 A) E( R1 }8 h3 v1 Q/ {  ?% E7 n

5 d0 `! G6 z& Y8 c
后续:长期规划、短期见效

" S6 J7 {# a  _) }0 _
  L/ ~9 d& }$ e
如何让DevOps平台保持生命力,我觉得最重要的是以下四点:
$ r; z  @  K1 e2 A! D- ?
1.png
6 \5 D) n/ E! B) u0 Q# A( _
易扩展,平台作为企业产线的一部分,需要与大量的工具、平台交互,像拦截机制、hook机制都必不可少,尽可能让平台与更多能力串接,才能形成一条全周期的生产线。

9 T1 W" F# O' I  p

: f5 F4 X% _  L0 u# E0 t4 ^
可度量,MVP强调快速推出,通过有效的反馈机制,为后续优化方向提供参考。DevOps面向的部门和角色较多,千人千面的需求更为明显,所以快速收集反馈,持续度量尤为重要。

8 b" |3 r! l* Z% l
" {# W( @% S  [$ J# H1 V$ \; I
连通性,这里更强调数据的连通性,是否知道jira上的某个task,花费了多少行代码?是否知道jira上的某个story,现在运行在哪台server上?这些都是数据联通的例子,也是DevOps设计中最重要的一环。
# I, a( A  B) A+ t$ |. C+ ~

2 @3 L/ n  x! N+ O6 }/ a
标准化,或者我们也可称为”最佳实践“,也许现在还很难标准化客户流程与规范,但在某些细分行业里,总会有一些榜样企业或标准,平台更应该将这些标准作为规范落地,通过模板配置、流程配置,帮助客户形成最佳实践。

6 h; W2 v, ^* h3 {
; ^6 W" G& T8 e2 @
  @4 q* n; h% P
目前我们的DevOps还无法覆盖全能力,比如测试管理与自动化,比如监控预警,都还需要逐步建立完善,从产品发展角度,我们更希望业务目标要大而全,但实现要快速见效(实现大而全,说实话确实也投入不起)。
  h( j4 R# O: D  g
  Q9 {2 p2 K1 D# D' V3 `: S
最后分享下这个版本的主要功能矩阵,望大家对我们的一些经验和产品能力给予建议或指正:
# U6 h) k7 z9 ?( L
1.png

& c. O# u7 i1 j& W8 x! k& h
原创:顾伟
' l: v& i& ~; `5 W" Z" Q. Z( n1 x5 k

0 N* w3 T7 N6 F6 A




上一篇:DevOps实践:面向服务的全自动化测试体系分享
下一篇:DevOps 来了,如数据库变更速度跟不上该怎么办?

本版积分规则

参加 ITIL 4 Foundation和中级过渡MPT认证、DevOps专家认证、ITSS服务经理认证报名

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

Baidu

GMT+8, 2020-7-6 19:45 , Processed in 0.175962 second(s), 27 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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