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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

DevOps:是全栈必备的一把双刃剑

[复制链接]
来自- 广东广州

参加活动:0

组织活动:0

发表于 2018-10-17 16:53:43 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-10-17 16:56 编辑 ! O9 d  |& X9 b( b/ s5 @& I

) p# k& [+ _5 o% y4 [0 ~7 ?
作为一名全栈工程师,不仅是一个研发多面手,而且必须要关注产品的最终交付,以及线上服务的稳定运行。工具化使开发、交付、运维紧密地联系在一起,于是DevOps 逐渐成为了全栈们手中的利器,但由于DevOps的复杂性,如果没有科学的人员、流程与工具相配合,DevOps根本无从谈起,因此,DevOps 更是一柄双刃剑。
2 l# E' v/ P8 z' I3 o0 H' g
& W3 L) y; ^# r$ `
1什么是DevOps呢?
  s* H- W' k( E1 ]6 ^/ a. X4 J% `
: }, C: w( ~' a# y# l
先看一下wiki百科给出的定义:

" F3 Z! k& d" F
& Z0 N& D" }4 _2 U' P$ K: A
DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.
简单地说,DevOps是一种开发、测试、运营、维护部门之间沟通、协作与整合的软件过程、方法与系统。

) M" d$ [3 k  F' S
DevOps是一种高度强调人与人间互动的工作方式,不能先入为主地认为参与者了解某方面技能,在完成高频率部署的同时,提高生产环境的可靠稳定和安全行。
5 ^2 T+ p# ]6 ]/ n7 `! P
& o( X! E# z7 Y( B/ s7 R
DevOps能够为团队提供一种极具凝聚力的文化氛围,DevOps不光是一个方法理念,而且是一个有力的技术手段,人员、文化、流程与工具这几大要素在DevOps中同样重要。

$ G  E3 j( o2 z' u& @

2 J" z* D+ S! X( C  k3 ^( b2 P: f

- f# |- v! P+ F: h5 z
2、为什么DevOps姗姗来迟?

7 \0 P0 x  G. c- t( K

+ G3 ^2 g9 R: z
DevOps 的概念在2009年就诞生了,但没有相关的技术支持,只是出现在教科书和论文里。然而,近年来所谓DevOps的最佳实践逐渐越来越多,原因何在?

" q1 A4 g/ q, i0 e) x' i

1 w' E6 y) Q9 A7 x# H+ |
  • 云服务的普遍使用,各种云服务成为IT基础设施中不可分隔的一部分。运维有一个很重要的概念就是Infrastructure as code。

    # \, T) X$ [! s( o

" i  N# ^8 O( D/ B
  • 容器技术开始成熟,特别是docker技术的大行其道。容器 Container是用来存储和组织其他对象的对象。Docker是一个开源的应用容器引擎。

    : i, v) C( d4 C2 ~0 @  h5 ~. P' e

  a. I% J& v' R% N; Q; c) W

/ d' Y8 L7 e' a8 ]9 X- h6 t
  • 微服务架构技术的广泛使用。
    $ O' U+ G  X2 n, C) _" N
* D$ Y0 ~: T# [" s6 P
6 Q/ S% H2 p7 F& J9 |
  • 微服务 MicroService是指一个单纯的小型有意义的功能。

    ) u" J; N+ _; T! L7 E& O/ Y+ r6 g5 s9 g
1 Q6 b3 L/ i4 r3 A6 K/ x- N
微服务,是支撑DevOps方法的手段,传统开发是在一个服务器里面,把各种元素装在一起组合成一个程序,但微服务是每一个服务是一个单独的单元,可以部署在不同的服务器上,通过SOA的方法,把它连接起来,再提供整个功能。

' J" K1 O) M) t  `0 k0 v; J
$ U' O+ _" [; V( }, W  q8 y- O& x

2 U0 p& N$ Q8 i微服务是由一个个团队组成,每团队有自己的服务,做好后,可以独立的进行测试、开发、部署,然后整个应用组合到一起。张侠表示,开发运维一体化、微服务和Container是同等的,把它们组合起来,加上云的手段才成为可能。
% v7 i! R' U9 l* \1 Z
) Q5 {' z' X- ~! l
3 f& d: u+ z# X! u2 c% t9 x/ `
敏捷开发流程的深入人心。
3 W8 _8 t3 G& e0 g9 ?* q( W
$ k* X3 B) {$ g. ]! H

% o8 ~/ F9 j/ |3 r- A" f2 w$ u
诸如Scrum, Agile, Kanban等敏捷方式被团队广泛使用,TDD、BDD、DDD这些测试驱动设计、行为驱动设计、域驱动设计等设计方式的采纳,CI和CD这些持续集成和持续部署等方式的实施,这些都是对DevOps的强烈需求。
7 H! _( `2 r' w6 s8 G. W
# R4 M2 {& y# f
3、DevOps中的技术栈与工具链

! i5 u0 v6 M2 t7 i  O
& e9 c. P3 u- n6 j
在全栈眼中,Everything is Code,所以DevOps 是通过技术工具链完成持续集成、持续交付、用户反馈和系统优化的整合,实现跨团队的无缝协作。
1 o9 l* R, D9 p( v3 ]* @0 P$ ^" h1 ~

5 p& g& I5 h/ W4 X/ ?& |- W; [4 j8 P
DevOps 中涉及的技术栈与工具链如下:
1 n8 x' g" Q" l

" D8 [$ Y1 G5 p2 m: ?; O
  • DevOps 流程门户: 这是统一操作的web网站,主要是进度看板,Sprint周期等。本着拿来主义,在一定条件下,可以采用类似Trello,worktile等工具代替。
    3 E4 `# p- K: y6 _
/ y. I8 I' I- D; t0 T! r
  • 身份及访问管理: 用户权限管理的重要组成,可以采用RABC的方式实现,也可以与LDAP服务对接

    4 ]! `( ?3 J7 J) I; |+ V% b
* p# P$ ~* M, B0 V! Q, Y
  • 产品管理: 产品的需求,定义,依赖,推广等产品线的全面管理,confluence 可能是个不错的选择,禅道也可以满足一部分的功能

    1 f. F. b6 L" |

( i" g8 k8 i, x1 V. X6 C; _
  • 配置管理: 提高产品的配置维护能力,zookeeper 大概是不二之选。
    , e: w& @; ?% i8 u. H1 f2 o

% R- i% X1 Z# b/ r3 y
  • 持续集成: 提供持续集成任务调度和执行的能力,Jenkins的用武之地,提供产品和组件自动编译、打包和部署的能力,支持编译和部署的流程编制,进度跟踪和日志查看
    4 a/ q, \* M$ l% B
' D1 M: i" Q" r) J
  • 环境管理: 提供资源配给和负载均衡的能力,需要配合云服务的资源管理能力。初级的负载均衡可以选择nginx或者Haproxy,生产环境的入口最好采用云服务的SLB负载均衡,以便简单地解决HA的问题。资源的调度采用云的弹性能力,辅助脚本实现。同时,微服务的容器化(docker)管理需要特别关注。

    ) M7 z% @1 P* ?5 X
! Q& w) o* A0 U
  • 质量反馈: 提供产品的质量管理和监控能力,包括测试用例,缺陷跟踪和质量监控。Jira 是个不错的选择,其他的开源工具例如禅道,bugzila,mantis等等,因团队而异。

    ( A* p% m9 x( t6 j8 I

* r# {1 V8 K6 `! ]
  • 版本控制: 代码库的创建和维护,分支管理等。Git 几乎是行业的标准,可以自建Git仓库的服务器,也可以使用github 或者bitbucket这样的第三方服务。

      @0 v/ X2 t. r1 V
5 m% T2 A$ f$ v( |
  • 自动化测试: 包括客户端与服务器端的自动化测试框架,例如Appium,Selenium 以及各种Mock技术和xUnit
    3 u! i$ J* x2 A9 z3 X4 R9 O
0 d! T& r! L0 l. o
  • 文档管理:各种开发、运维、部署文档的统一管理,同样最好放到git上,同时指出文档的自动化生成
    % K9 D* w$ A! l; r% o- c) |+ ~
% @7 R' r/ n: R) U! T
; \# s5 e( g3 w* L' K" @- X
  • 运营管理:这就是传说中的OAM 中心,这是广义的运营,其中还包括运维的部分。OAM 不但提供了业务系统的运营操作,还提供了面向运维的统一Monitor,alarm,fault handling等能力,以及产品的资源使用和运行状况等,涉及的技术很多,尽量采用云监控+脚本的方式,规模较小时可以尝zzabbix 实现部分功能。

    , y5 x3 t! o# |* K% w6 _. g
$ U4 h+ }( u) h8 B& l- h3 r" ~/ a
  • 沟通管理: 敏捷的一个原则就是沟通优于文档,IM是团队必备,微信和QQ可以满足大部分的需求,但是Slack 因为其强大的web hook 功能显得更加出色。
    6 r! e' i' k" B# P  A

, k, W6 M* p* v2 W( Z, [6 P
4、DevOps 的双刃剑
/ a3 W5 r# G# v, `# m5 `

+ r0 [5 R# A3 O" J$ ^; l
DevOps 的成功与技术、流程和组织的全面支撑是密不可分的。技术栈和工具链只是DevOps的一个前提和基础,技术方面的实践相对容易,流程较难,组织变革最为艰难。DevOps还是以工程实践为主,管理实践这块,像Scrum成体系的还比较少。DevOps玩得好,可以提高团队的生产力。若是玩不好,可能还不如传统的生产模式有效率。
8 j. A, |, N9 }/ {9 Z1 t
/ c6 ]0 `4 A) s# {5 d( l
狭义上看,DevOps主要困难点在于开发和运维是两种完全不同性质的技术工作。很多开发的同事,看着运维人员整天就是玩几个工具,写几个脚本,觉得蛮简单,实际上,很多东西要在生产环境下快速稳定应用,并没有看上去那么容易。生产系统少出问题(软件本身bug除外)是运维的绩效,多实现业务需求是开发的绩效,这一少一多,体现了两种技术角色的根本性区别。

& W9 u' y, O/ I

; {) z0 I. @7 p3 x+ P6 b7 f
业务部门压力往往导致技术部门的任务主要是求“快”,在这种情况下,DevOps必然失衡,因为只追求快,就不需要ops了,只需要dev加班加点即可,不重视ops,结果必然是可悲的,往往业务上线后鸡飞狗跳,各种问题不断。在激烈竞争环境中,出几次事故就可能对产品形象的伤害很大。

1 j# P9 o% {8 ]: A

, V) ^( r9 u/ S9 k& P" m
对全栈来说,业务初期到底要不要考虑高可用?从Dev角度看,简洁明快的实现就行了,从Ops的角度看,高可用、监控、报表这些东西在业务正式上线前就是必须要考虑的。

, X% t! A( k% g' s( m

" U0 t- q' Y. d
因此,DevOps实施成功的关键,涉及到团队管理,项目管理,技术管理等诸多方面。DevOps并非治病良药,如果团队正能量大,实施起来就相对容易,否则引入DevOps可能也无法改变什么。对于一个全栈而言,DevOps是一柄必备的双刃剑。
. q: o1 d, m4 I# ]( _) a& Z: r

) g0 p6 A0 A: }# g
原创:abel_cao
' R% M+ ^+ |6 s9 k6 D( e4 e  l) Z

6 N) U  Q  Y* o5 P0 a

本版积分规则

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

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

Baidu

GMT+8, 2019-1-23 22:54 , Processed in 0.223732 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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