w

您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
为什么说持续交付将拯救IT运维?
 
来源:网络  发布于  2017-4-14
388 次浏览     评价:      
 

一、前言

在深入探讨持续交付之前,我们先来看一个典型的场景:

A 公司最近很苦恼。

A 是一个传统行业的公司,物流运输为主营业务,IT部门作为支撑部门辅助业务发展。但是随着业务的快速发展,IT 部门开始感觉到有点力不从心了:

频繁的业务版本迭代(扩容、缩容、迁移、升级、回滚等等),全靠人工变更操作,操作单调重复,却又风险很高;

研发同学只关注代码编写,很少考虑线上部署的规范和设计,全靠运维同学自己把关,结果各个系统的维护自成一套;

新旧系统越来越多,系统调用和接口关联复杂,一个看似简单的问题都要捣弄半天,甚至还查不出原因,更别提性能优化;

……

长久以往,业务部门对IT部门的印象直线下降,认为IT部门是一个成本部门的同时表现还让人失望,而 IT 部门则哑巴吃黄连,有苦吐不出。

A 公司遇到的问题,相信很多传统企业都会有同样的困扰。其实,知道问题在哪里,就是最好的开始,我把帮助类似A公司解决这些问题的方案整理出来,希望对大家有所帮助。

二、无规则,不成方圆,标准化一切!

2.1 什么是标准化?

在讨论标准化是什么之前,我们先来思考这些问题:

业务维护:手工模式可以维护一套系统的开发、测试和部署,如果是十套,一百套,甚至更多呢?

业务交接:业务交接代价太高了,能不能让新来的人几分钟就能理解整套系统的维护逻辑?

服务部署:手工部署很麻烦,搭建环境很痛苦。我可以一键部署,剩下的时间去喝咖啡吗?

标准化可以帮助我们解决以上的这些问题,我对标准化的定义就是:

针对企业内部的业务系统技术栈进行梳理,规划出一套开发和部署规范,并且在各个环境(Dev/Test/Prod)严格执行。

标准化对可变部署模式最为有效,通过标准化,企业内部的每一套系统,每一个环境,都保持一致,然后把规范化后的部署方案整理好,落实到自动化平台,就可以实现自动化部署而无需过多的人工干预。

试想一下,如果是一百套不同的系统,自动化平台根本做不起来,业务维护、交接和部署的成本简直不可想象。

那么问题就来了,如何做标准化?

PS:什么是部署模式?

实际环境中,部署模式分为2种,一种是可变部署模式,一种是不可变部署模式。

可变部署模式:

是指任何的版本变更操作,都会在原来的版本上进行,例如升级、回滚、卸载、安装,这些变更操作会直接影响到原来的版本的服务,技术术语中把使用了可变部署模式的服务器称之为:Mutable Monster Server(随之时间推移逐渐变成不可控的怪物服务器)。

例如:ver1.0 发布之后,更新至ver2.0时,需要把服务器上的ver1.0的服务停止,删除版本文件,然后把 ver2.0的版本文件安装上去,再启动服务;

因此,如果版本回滚的时候,也是同样的操作,把 ver1.0 的安装回去。

不可变部署模式:

不可变部署模式,和可变部署模式相反,一旦当前的版本发布后,就不能再对该版本做任何的操作,如果要进行版本变更操作,就需要重新发布一个新的不可变版本,这些变更操作不会影响原来的版本的服务,不可变部署模式的目前代表是 Docker 镜像发布模式。

例如:ver1.0 的镜像发布后,更新至 ver2.0时,只需要把 ver2.0 的镜像发布出去,运行起来,然后把流量切换到 ver2.0 的容器实例上即可;

因此,如果版本回滚的时候,就把流量切换回去 ver1.0 的容器实例上;

2.2 如何做标准化?

我把标准化的实践思想总结为XY轴对象模型,从开发、测试、运维3个角度着手。

例如,以运维的角度来梳理:

梳理Y轴(实体)

所谓的 Y 轴,是指企业IT系统所遵循的技术栈,从企业的技术栈入手,从宏观上把需要标准化的实体梳理清楚。

以A公司为例,A公司他们使用了JBOSS作为开发平台,我梳理的Y轴的实体如下:

基础层

基础层一般指技术栈最为底层依赖的环境,例如:

A 公司使用了 JBOSS-EAP,因此底层依赖的环境是 OS + JDK:

Java 项目,基础层:OS + JDK;

Python 项目,基础层:OS + Python;

Rails 项目,基础层:OS + Ruby;

……

框架层

框架层一般指技术栈所使用的项目开发框架,可以是开源方案,也可以是自研发框架,例如:

A 公司使用了 JBOSS-EAP 作为开发框架:

Java 项目,框架层:JBOSS-EAP、Play Framework、Struts 2、Spring等;

Python 项目,框架层:Django、Flask、Falcon、Tornado 等;

自研发框架;

….

公共组件层(不一定有)

公共组件层一般存放多个组件共享的代码、配置、驱动等,需要按照实际场景进行分析,因此不一定需要。

业务组件层

业务组件层,就是研发同学开发的业务组件,业务组件一般会有:

代码包;

配置包;

运行时数据;

运行时日志;

梳理X轴(属性)

所谓的 X 轴,是指企业IT系统每一层技术栈应该遵循的标准,对每一层的技术栈进行深度分析,构建出实体应该具有的属性,例如:部署目录、运行属主、目录/文件属主、目录/文件权限、日志、数据等等。

结合 X 轴,可以得到以下需要标准化的实体/属性表:

例如,A公司针对部署目录这个属性,定制的标准化如下:

可以看看业务组件层的设计细节:

部署标准化执行准则

结合个人经验,在构建标准化对象模型时,以下的准则是应该遵守的:

启动脚本:应该构建统一的启动脚本,通过传入参数来匹配不同的业务组件;

实体隔离:梳理出来的实体,在部署上必须隔离;

代码包:代码包无状态,一次打包,多环境流转;

配置包:配置包环境相关,和代码包分离,甚至可以实现配置中心来实现统一存取;

数据隔离:数据需要写到数据目录或者数据卷上;

日志实践:日志写到数据或者日志卷上,规范的输出级别、内容格式、日志种类、轮替周期和定期清理。

综上所述,通过不同的角度来梳理XY的执行规范即可,例如研发也可以根据以下的规则来梳理:

同样,在测试方面也可以提供业务测试的定制化规范,比如功能测试用例的编写、规划的测试流程(黑盒测试、白盒测试、回归测试以及性能测试)等等,不知道大家是否理解了:-D?

   
 订阅
  捐助
相关文章

DevOps转型融入到企业文化
DevOps 能力模型、演进及案例剖析
基于 DevOps 理念的私有 PaaS 平台实践
微软开发团队的DevOps实践启示
相关文档

DevOps驱动应用运维变革与创新
运维管理规划
如何实现企业应用部署自动化
运维自动化实践之路
相关课程

自动化运维工具(基于DevOps)
互联网运维与DevOps
MySQL性能优化及运维培训
IT系统运维管理
 

itil五大流程图
ITIL流程管理六步走
使用ITIL V3作SOA治理的基石
IT服务管理的实践与总结
借鉴ITIL架构理念提升信息化
ITIL流程总结
更多...   


基于ITIL的IT服务管理
ITIL认证
ITSM/ITIL基础
IT规划管理
IT外包管理
IT成本管理

中国移动通信 网络规划与管理
某航空公司 IT规划与企业架构
某金融公司 IT服务管理(ITIL V3)
中国联通集团 IT前沿知识概述
中海油 企业IT架构设计
更多...   
 
 
 

 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号