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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1493|回复: 0

运维自动化的定义就是数据-事件-流程

[复制链接]
发表于 2017-9-13 11:40:30 | 显示全部楼层 |阅读模式
本帖最后由 monicazhang 于 2018-8-27 11:07 编辑
, q4 S5 u5 W7 s. N  {/ X/ i. G- J' L8 g# e% [4 G; a6 y+ n- s; H8 V( a- n

随着互联网发展迅猛,不同的公司IT基础设施面临的增长和快速发展。从人肉维护,建设到半自动,全自动,由此产生的自动化体系/运维工具越来越多,目前大多数运维IT环境架构主要分为3种技术体系:


  Y4 L3 J. e1 L* |: d1 c

1)开源工具

$ o" j7 o- h; ^- t7 \- r

& c5 H7 Q' V* j2 d: K

2)自研发工具(更多的是包含和利用开源软件优秀的特性进行定制化开发)

4 H3 M  Q. F- B

7 H9 w! u' _. w

3)从0自主研发,底层改造到应用层开发


! [5 F- d" L6 H
) P3 u$ t4 l4 }3 T! f+ @! F, {+ i1 A( \: U

开源的代表作有很多,比如:puppet,saltstack,Ansible,ITILxf.com" target="_blank" class="relatedlink">nagios,zabbix,Docker,KVM,Openstack等主流开源软件。

自研:资产管理系统,发布系统,监控系统,配管系统,工单系统等。


0 e  G) O) D" E

总结:运维自动化已经是成熟的代名词了,无论从网上搜索,还是各大技术分享,都有很多不错的案例和实施过程。但也很多朋友觉得实施起来很困难,复杂,但是看似很简单。困难和复杂:想不通如何把重复性,不可规整/聚合,业务连接成一线枢纽。看似简单:因为有人/其他互联网运维团队实施出来了,实现的还不错,看似近在迟尺。先定义后实施,这个是关键点,想明白才去做,没想明白千万别去做,否则只有推翻重来或者坑越来越多。


  @$ }4 T! R, c; e0 Q. F

定义分为三个层面:1.数据的定义2.事件的定义3.流程的定义

2 O2 H# p/ Z0 F& ~6 g' \0 x# L2 d

: L5 L1 [9 l# O9 x& A$ F9 o

; _1 _, x7 d( U' |2 K1 R

1.数据的定义:

3 ]2 G* F- w6 G4 c6 C
, T* E0 Y. j6 O' \+ a% H2 {3 ^
' U' u- v  F) c: K/ M" a/ }; w8 ^

, W. v1 w  g. V: y: A* m; z% z, L

一切的基石基于数据,第一步数据的纬度要设计好:

4 j3 J6 _2 i( ]2 w

①.机房的定义:比如北京机房,上海机房,香港机房等

6 o% ?1 C, C2 ], c

②.机器类型定义:私有云,公有云,物理机,公有云:ali,aws等细化纬度。


1 W/ H- E+ B3 f

③.业务定义:比如官网业务,订单业务等纬度细化。


  P+ @' o& p9 M0 V# h" j

④.存储的定义:比如根据自家公司的业务和技术体系来设计:

$ Q5 d! C5 m# r- z7 }( E' f

比如哪些基础信息是需要的,哪些信息看似可要/可不要的,要做好取舍。


3 n5 }( k) ~) M9 n) m% a& \; ?: c

数据存储的信息一定要是展现出来有实际意义的,数据存储不在于多,而是在于价值,繁重的数据越来越多,如果定义很多可有/可无的数据存储,对于一个IT基础资产库来说,也是种负担。


+ q' ^7 M7 ]6 H& R6 x) C- Q4 ^  d

数据的存储考量:唯一的,有价值的,可维护,可扩展的四个原则。


. h5 L( O1 C% E

⑤.协同的定义:当拥有一份完整的IT基础资产库的时候,只是一份基石,基石铺垫好了,才有上升的扩建空间,数据的标准接入协同分为二部分:

& X3 H) H! O( c# Y/ n

1)内部的系统/资源(运维内部的系统)

, \& G- X; X, Y% I# u

2)外部的系统/资源  (业务,安全的系统)


1 I) O7 E) S/ S* D! K/ R

内部系统/资源和外部系统/资源对资产信息库的对接关系策略纬度:


& ~- S1 k6 c$ g: R

1.可增加/删除的,初始化类型数据系统/可移除的资源数据系统,比如:自动化装机系统

5 @! Z) F) @  ]5 `8 O* L5 p8 P

2.可获取的,获取的信息纬度哪些类型,比如:发布系统,监控系统(拿到资产信息库的业务类型,组,主机/IP信息等。


1 B- W8 L( ^7 c& C0 ?; r

3.可查询的,单条件查询,多条件查询,连同条件查询,比如:安全审计系统,业务类型系统,对外/对内访问IP区分等。

7 h; v7 i' L6 D7 a

5 u9 f) L* o# |2 ~7 a

2.事件的定义:

; U% b; D* e8 q  f6 l* ^
. z! n% e0 [5 \1 g

% X# C, E9 c( \" R& ^6 Z5 w9 g/ U( R2 w6 o* k- s, x

第一要点的数据定义已经设计好,有了完整规范的数据格式,来定义围绕基础信息库基石上扩展事件。

% ~' t  m; I! C+ a" E

事件定义的逻辑方法论:事件设计-事件构建-事件交付-事件数据汇总


8 H/ L: O) f$ k/ s( G( s; X) O' K

每个自动化操作都依据某个事件场景来实施,实施的策略很多,也需要平衡好优缺点。


) s' Q$ t; e8 I) T6 b; m


6 N3 ~2 q1 H& z  q) W. E$ B# G# |8 i

1)数据的初始化录入系统,俗称:自动化装机系统


2 N/ S" O. n/ o- P

' \1 q8 N; I0 c3 D) ~

自动化装机系统初衷:

5 W. M8 b5 W( v! ?! N! n

1.需要人工重复性操作

: N% }/ z7 n  j

2.快速交付时间周期慢

$ W# I' S5 e4 r9 w  o9 |

3.技术提升优势不大

. G/ }2 x1 M/ ?" Z8 b2 S

4.用事件根据场景来优化

; y+ r( a1 W4 S1 v; G


/ W7 e6 n) M7 y$ w' z

自动化装机系统交付要点(根据不同主机类型来构建事件场景):

0 I- e7 p- f1 t2 l9 u) @

1.物理机类型(硬件层面:不同硬件厂商的类型,比如远程卡,BIOS初始化,RAID阵列自动划分,软件层面:cobbler)

6 F6 H0 @" ]6 C9 i( Y! f

2.公有云类型  (服务商的Api或者SDK接口)


6 e$ |7 T. y* Q

3.私有云类型 (Openstack,Docker,KVM私有云规范的Api接口或者自己构造一份标准的接口).

- ?; [5 k/ }' t" n

4.从类型选择初始化配置-内部DNS数据接入-获取主机信息资源-启动新主机。

3 Z4 l; S* N# u3 J; T; i2 d

5.数据完整保存,方便以后分析和进一步优化。比如:成本的使用/扩展,业务方机器资源使用率,分析对该事件场景构建优化提升之处。

% O  J+ i. S, D8 U% N


- w* S9 e0 Z6 E

发布系统,运维日常支持工作占到百分之50%或者更多。代码发布也是运维考核的和支持最重要的一项日常工作。

& x$ J3 ]" Y9 U- c+ o+ }7 J

发布环境常用的包含:local,beta,demo,gray,online等

" f2 O# J$ e& P

发布的代码类型:混合型居多。


/ ]- ~2 o  [$ z) l! C0 _/ p

通常情况下,人肉支撑的耗时,重复性,自检成功/失败发布,排查故障周期很长。尤其是对于重要业务平滑,耗时的情况更多。

而发布系统满足重要的三个因素:

8 {) {3 l! O! R. ~! T0 g

1.自动无损平滑发布(支持多种负载均衡策略,发布代码不重启服务策略,环境组主机流量自动切换)和可视化实时过程/结果查看。

2 [' Z& F, U9 v3 j* N- K

2.稳定,并行的构造多环境/多业务发布,即使某个业务出问题,对于整个发布平台/其他业务发布也是无感知,无影响。


0 O5 L* [. k3 }

3.权限,安全隔离,完整的审计功能,让研发自助的发布。

) [- X' E' @6 t7 P% \3 M- L

4.数据的完整保存,分析目前业务发布测试/迭代,资源调度率,发布时间点,全年发布优化指标等。


6 g* q9 ], J. n. z- S# ]

总结:以上就举2个事件场景构建的案例,一切事件构建皆为场景,场景的价值在于数据是否帮助/量化,改进业务层面/运维层面的持续增长/交付。


/ Z. t* T" Y: `

* g/ ^8 G8 X+ {: {' l

3.流程的定义(一切入口,规范,从流程抓起)


' T' I9 ~; u. k7 [5 C
' E" U* n4 k' D$ ~) C3 F
8 V; t- V6 B* c/ E* E) a; L
6 u2 ~, N3 Z- y& Z4 [4 M8 G

为什么最后才是流程,因为在没有数据做基础铺垫,事件场景构建,一切谈流程都是空话,虚拟的。


/ k' W9 u( l) V4 g2 }' k, b+ l

流程基于实施的要素:

$ r* y: |  P9 Q3 K- i9 `

1)基于一切数据+事件的入口配置

" B$ {! N  K  @+ d& G# t

2)流程不在于复杂,在于易用,快捷,可塑造。

- _& g- m+ F$ x. C% m+ f

3)源地址-目的地址全部过程保存,可追踪。

0 T  l% L3 S( q' v+ U  G( V


  S5 o& X4 b8 o- x* L  D

自动化价值:


0 M  e0 f: T: x9 v$ G% b2 `. D. Q

1)价值性产出:站在业务/团队角度去思考,不追从完美产品方案,只选择合适的产品方案,同时在一定程度上做好取舍。


/ |0 t. Z3 x* ]0 V2 R

2)从小而做到细,从细扩展到大,才是本质。


! f' ^: g% Y- C5 R4 D

3)  自动化产出一切为数据,对数据定义要设计好,宁愿设计周期长些,也不要盲目实施。

) ^3 n1 ?$ j% Z- X

原创:符杰超

! O4 d6 C. R" C" v8 }% M




上一篇:你知道云中的 DevOps吗?
下一篇:要纠正的几种错误运维认知
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-5-23 03:25 , Processed in 0.111316 second(s), 28 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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