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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 428|回复: 0

浙江移动SRE转型实例给我们哪些启发

[复制链接]
发表于 2020-12-10 13:43:28 | 显示全部楼层 |阅读模式
本帖最后由 monicazhang 于 2020-12-10 13:43 编辑 ' U) H1 l) @! f
+ i( f$ q. l! w# z( v* [7 O

& A" X, w  f, Y

一、背景:我们是网络运维工程师

9 z- L, L% K6 H* O
我们维护的设备:厂家定制,专有软硬件的通信设备。
: K+ F$ b" S/ t- v+ j: S& d" ?
1.png

- |- v5 ]) v/ w# s# ?
我们眼中的世界:路由、协议、网元、信令、局数据…

  o! w# @5 J( K" |
2.png

3 W5 Y$ u4 R/ b! A. `
我们日常工作内容主要涉及以下三个方面:
; p  J7 y1 G' b' p# K
3.png

, {" c) L; g5 S& f" D* Q' ^
但是,我们的人员素质较高,100%的工科背景,都具备基础的编程技能,大部分人对运维开发转型充满兴趣。

7 h' [( P8 B- k- W
4.png
( z! F5 U5 k& }( L, d, j

二、我们遇到了点小麻烦


5 W; p1 X0 ^! |" B$ c2 n  E1 _
随着通信技术的发展,网络运维的压力和责任越来越大。
! D% O) h8 n/ B. D
5.png

* o7 Z5 J2 P7 R) y
与知名互联网公司对比,我们维手段较原始,大量工作处于人肉运维阶段;对标先进互联网公司,我们还有很长的路要走。

8 Y% D" Q' y! s9 L! u/ l
6.png
4 F  c4 x" }' c( v4 q* E+ _$ |
国企的人力成本存在红线,人力资源不足。即运维的设备越来越多,但是人不见多。2014到2019年,语音核心网元增加了80%,但是运维人员仅增加12%。

8 j" p! c2 A  N7 x; b
7.png

6 b/ q- F' Q7 U
虽然支撑系统平台手段众多,但日常维护中仍存在大量的手工冗余操作。支撑平台开发周期长、开放性差,是两个较大的问题。
: d4 ]+ O  o4 B4 h/ @6 B) T
8.png

9 B" l. W7 T  W; \3 R( G) E- H, P
网络设备正在向IT云化演进,网络运维人亟需转变传统思维,向IT化思维靠拢。
, e7 ]7 m! s' e5 @0 c  k6 m) M
9.png

+ T7 g# N( t. _7 v" }5 [& |! b) o1 X
复杂的云化架构有时发生故障根本无从查起,诡异的故障无法用科学解释。

5 q6 e, s9 `& o6 ~. ]4 H6 o' i
11.png
/ [; v8 g3 e" ]
无法用科学解释的时候,迷信就出现了。

: y% A' N2 t! I- N' C
12.png

: z, e7 Y0 A8 k7 Z

三、浙江移动的SRE转型之路

8 b9 A$ q8 }; y# R/ ^3 A, n9 S
1、转变思想; x: y$ Y) @( O
5 q" v4 y% R5 w% H$ R+ q' p
在转型过程中,我们吸收了谷歌的SRE运维思想。SRE是Google对DevOps的实践总结。

. O! l( h' H; k: @0 t
SRE的终极目标:保证业务连续性。

2 Z" r6 c5 A* ~4 g
SRE把运维问题变成了软件工程问题:
- u9 }0 c5 \: `- g. G# b2 B
  • 50%~60%软件工程师;
  • 其他具备85%~99%软件技能,且具备一定程度其他IT技能的工程师。

    - A) e/ d( M1 H( v
/ W; A; m" k  e( c2 [5 H
SRE模型的优势:
: ]$ f' `0 M. @4 P
  • 运维人数相对少;
  • 开发团队和运维团队的冲突焦点消除;
  • SRE团队和研发团队之间的成员可以自由流动。
    8 u8 a8 c& `/ s& `3 p
3 }7 d: o0 \5 C* V  B0 L9 ]
•SRE模型的问题:符合SRE的人才难招聘

' T( _) T$ u/ p+ |
SRE与DevOps的关系:SRE理念是DevOps的具体表现形式。DevOps和SRE是道,DevOps工具是术。
9 N3 Y/ x& x. ]& K* }0 Z; C2 P5 W
13.png

: a& o5 J2 T: Y( c
SRE做的是运维自动化,但自动化不是目的。

  t: w# }7 d. t% ~& {0 r
自动化有3种形式:

/ a$ y  w/ t+ P& ^
  • 外部自动化:即通过外部的工具和脚本,实现运维自动化功能。
  • 内部自动化:即将开发的脚本和工具部署在系统内部,实现自动化
  • 服务强化:在系统设计和开发阶段就考虑到运维手段,将运维自动化体系原生嵌入到系统中。

    # Z, P0 Y+ h1 V7 p& `! X' w8 c7 `
/ D5 _3 {9 a* r! B/ S) s
目前我们主要做外部自动化,冰箱内部自动化和服务强化迈进。

) K; Y( l5 u2 X) c
自动化后带来的好处:

+ u( p1 A1 k& a# @
  • 高度的一致性:无论新手还是专家,作出的判断和操作完全一致
  • 问题快速反应:发生故障快速反应
  • 完成任务省时:完成报表取数、优化分析等任务省时省力
  • 固化经验:将运维人员的经验和教训固化到代码中流传下去

    : z$ u& W! g1 K1 {
% w" ~9 \5 c, [4 q/ L
2、确立目标% n$ u2 z5 S: P5 f
. Y' I# V7 q2 h: l
SRE团队的目标:提倡主动运维思维,以运维开发为手段,依托SRE运维模式,提升运维人员ICT技能, 支撑各专业高效运维。
; k* K9 k( _2 d
但是只有当团队目标与个人目标相一致时,团队才是可持续发展的。
! N' x$ \- z5 p! P
让我们来看看SRE运维开发转型如何实现运维工程师们的个人目标:
6 R3 k7 S8 F# K5 R
14.png
+ J; B4 h" Q1 {' h3 }& w7 s
3、建立良好的生态圈
5 `7 e# ~. X$ m
2 \/ D% o; [$ p& \* E" G# j/ z
1)建立组织架构
0 v3 c! {# H9 C, k7 E8 I
建立议事会负责制的半刚性组织架构制度:
2 W1 o- V9 [% R: F/ s  L. k
15.png
8 t- T. ~5 @) y) J/ ^3 Q% W
  • 议事会:负责组织架构设计、管理模式探索、人员IT转型等。
  • 技术支持团队:负责技术演进、技术支持、人员技能培养、开发平台搭建和维护等。
  • 工作小组:聚焦应用开发、服务开发和平台开放性探索。

    * _- F8 m* H/ r* X! g8 l* l: w
$ {* X' p. k, ?8 v0 Q
2)建立OKR导向的正向激励制度
- ?7 h# r; ?8 Y$ l0 F2 L
16.png
+ c) O3 y2 o; Z1 V, g3 X
除了行政架构的激励外,还存在横向的SRE OKR激励。
" d3 N! y1 v! H2 U" h5 \) l
3)探索人员分工

1 J8 q5 B3 O# b% N
17.png
- p8 H# h5 a( q
人员角色介绍:
/ G. |2 p- R5 ?) K
  • Enbedded SRE:嵌入式SRE,活跃于运维团队中,主要实现自身的自动化需求,有日常负责运维的设备,需要参与on-call值班。我们大部分成员均属于此种类型。
  • Platform SRE:平台开发型的SRE,主要对平台负责,开发新平台或对存量平台进行开放性改造,以使其它SRE成员可以方便的在其上开发。无日常运维设备或on-call值班的要求。
  • Consulting SRE:顾问型SRE,技能较高的成员,平时负责为SRE其它成员答疑解惑,解决问题,或是参与到其它成员的具体项目中进行开发指导或牵头开发,项目进入正轨后即退出项目组。平时无运维设备或on-call值班的要求。
    ' d2 Z( P5 J3 s/ t$ \& y4 G

: h: B! J# M' i& j3 G8 U
4)专注人员培养

3 T8 P/ i' I* J, u4 i- F' [  _
技能培养:依托IT和CT能力培养体系,针对SRE人员、存量运维人员、新员工、协维人员制定不同的人员培养体系。
3 y$ y: Q8 z( R! u
18.png
  W) l( n7 ]; I9 ?9 M
人员成长后评估:从5个方面,21个评分项对人员进行画像,完成人员的培养后评估。
6 Y' h  O4 l) i' j1 W; Y
19.png

3 B7 V; T$ P8 ^% F7 s7 y
5)完善日常工作框架

- _) X( l/ e5 Q& @% l4 l
建立SRE日常工作框架,确定技术规范,避免技术债务。
4 ]% I0 h2 V% r* b* x: U# [
20.png 21.png
6 ]* V0 N" J0 x: D
6)搭建开发支撑平台

% o4 E* Y! x, k0 t0 t8 f# I
通过建平台、解耦合两部分工作来搭建SRE的开发支撑环境。
+ e2 M. g! Q- ^8 j9 x, H7 q

2 X; u8 G% h2 S5 i7 v/ |
服务原子化,新增开发区,积木式开发,提升效率,降低开发难度。

5 w, f/ b3 m7 \. _
25.png

: V! e/ O" S/ g0 E0 G2 ]
平台开放化,依托平台进行功能增强,不需考虑底层和前端,大大降低难度。

, `; w( L2 t, H/ b- k0 R/ `8 ~2 k6 v

四、阶段工作成果


& P+ k& \0 v: h& U5 r- X7 d7 N8 z
团队经过2年多的建设已经初具成果,共培养SRE团队成员97人,完成开发需求200余个,具有如下的优势:

5 h7 t% B/ U3 c$ k% J  j& b, V* K
  • 需求实现快:基于开放解耦的平台进行搭积木式二次开发,单个功能点开发平均仅需2个小时,需求到上线时间缩短551倍。
  • 痛点切入准:运维专家转型开发人员,网络痛点了然于心。
  • 人力大解放:机器换人,大量运维工作自动化,值班人员减少70%。
  • 压力大释放:逐步接受与信任系统,具体的运维工作逐步转交给自动化系统完成,释放运维人员压力。

    ) ?: l! E% K3 v# J8 d- A3 j

5 P5 w, h5 Q& H( Y% [>>>>
Q&A

6 P, Z! `& h( E3 i: W
Q1:请问如何说服领导组成sre团队的?毕竟是垂直管理的企业。

( R, L1 b0 K+ `% r3 q) ^7 q* i
A:转型肯定是自上而下的,自下而上那叫革命,如果得不到领导的支持,那么转型肯定不会成功。随着通信网络技术的演进,语音、短信这类传统业务的收入大幅下降,后续的技术和人员架构会怎么样,我们之前也是迷茫的,不知道路在何方,但是通信网络IT化这个趋势是明确的,这个就需要我们去转型。
4 p" b& y! \9 D' I( I
对于如何进行转型,领导层面的考虑肯定比我们多,而且更深入。这时我们了解到了Google的SRE理念,觉得很符合我们的诉求,就跟领导一拍即合,把这个作为我们转型的方向了。
# D% U0 w  [9 E  F+ T
Q2:请问贵公司的自动运维是自研的吗?用了哪些开源的技术或产品呢?

4 b& A' ~' n% D, m! ]' |$ ^
A:公司层面我不太好回答,但是在我们部门,大部分是的。我们使用了很多的开源技术和产品,比如Hadoop、Flink、zabbix、Ansible、Jenkins等等。不过虽然使用了那么多开源的软件,但是我们还是非常注意开源软件的引入安全的。

% t: `) E) U; N
Q3:如何让外购系统厂家帮忙解耦他们的系统?
4 v: Q/ Y; l9 @6 Z  @, T
A:之前外购系统都是一个一个独立的烟囱,我们有新的需求提给厂家实现都很慢,厂家不懂业务,我们不懂开发,需求沟通存在较大的成本,而且开发出来的功能往往与我们需要的相差甚大。这种情况下我们与厂家存在比较大的矛盾,我们说他们开发慢,难沟通,开发出来的东西不好用;他们说我们需求奇怪,需求变更太频繁,对完成时间点要求太高。
2 a- q# k. ?+ O6 j
如果外购系统解耦之后呢,系统厂家只需要维护他们系统框架和开放出来的接口,一些业务功能由我们自己来开发实现,搭在他们的平台上,这样需求实现快,功能上可以完全满足我们的需求,而我们又省去了平台维护的工作,对平台厂家来说又不会受到频繁的需求变更单,也不需要去深入的了解我们的业务需求,对两方来说都省事多了,完全是双赢的局面。
& a; r& N9 ^/ H- f2 K" V8 v
我们把以上这些有利之处跟厂家说清楚,厂家都是比较愿意接受的,后面我们就把需要开放解耦的地方敲定,作为需求提给他们就可以了。
1 l, a+ X& v) B# ], t, h/ R
Q4:SRE日常工作里面,提到的需求归口管理,是指业务需求?
  d$ N% g# d. y% G& @/ M( r
A:是的,对于我们来说,运维需要的功能就是我们的业务需求。
8 H8 z! k' d* p7 w, C3 d
Q5:此外开发的开发规范,是约定到所有业务系统开发厂家的代码开发规范,一套标准么?还有API调用规范等,如何进行约束?因为涉及厂家非常多,管控难度非常大。

: x) {9 ]. N! O5 Z
A:开发规范是针对我们SRE的,并不是针对业务系统开发厂家的。这是为了规范代码格式和代码行为,形成良好的代码风格,便于运维经验固话在代码中后的回溯。因为都是基于SRE团队的,也不存在厂家多管控难度大的问题了。
) @; H- N* t) J$ V. l
22.png




上一篇:在SRE的位置上如何看待推荐和搜索
下一篇:SRE应该具备的能力和素质

本版积分规则

本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

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

Baidu

GMT+8, 2021-3-7 10:37 , Processed in 0.161207 second(s), 33 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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