【51CTO.com原创稿件】大家好,截至上期,我们已经在实质上将手头的IT项目发布出去了。但是,正如那些得以敲钟上市的公司往往担心会“破发”那样,我们也不希望自己好不容易完成的项目迅速成为了“月抛型”。为此,我们需要在服务系统发布之后,对其开展各项后期“保值”工作。
本系列文章如下:
【廉环话】不要让数据安全成为“盲盒”里的那只猫 -- 浅谈咨询业数据安全体系建设
【廉环话】防疫一周年后的IT治理思考 --可用性、关系与财务管理
【廉环话】防疫一周年后的IT治理思考 --能力、知识、问题与请求管理
【廉环话】防疫一周年后的IT项目管理思考 -- 设计、开发、安全
【廉环话】防疫一周年后的IT项目管理思考 --测试、部署、发布
既然服务产品已经能够以一套正确的、被授权的、以及经过内部测试的软/硬件形式存在于实际生产环境中,那么我们就需要协同需求方、以及使用方,顺势开展项目的验收与确认工作。通常,我们可以将验收分为初验和终验两个阶段:
在完成初验与终验工作后,我们需要及时更新配置项数据库(CMDB)里的相关配置项(CI),以及已知错误知识库(KEDB)里的信息。通过运用易于使用方理解的语言,去描述错误的现象与特征,我们不但可以提前向用户传递和警示可能碰到的问题,还能够合理地控制他们在使用过程中的期望值和体验度。此外,提供相应的技术支持和用户培训,也是在服务发布后和验收确认前阶段,所必不可少的环节。
新增的服务在被使用一段时间后,往往会出现加载时间、交付效率、以及运行性能等方面的变化;而那些变更的服务则可能逐渐对原有的系统产生流量、负载、出错了等方面的影响。为此,我们需要通过针对关键性衡量指标的监控,及时捕获和评估出流量的峰值、负载的瓶颈、甚至是逻辑上的调用错误。
显然,为了量化目标系统与服务的各方面表现,在着手进行相关指标的挖掘和分类之前,我们需要先确定待采集的关键点指标(也就是我们常说的“绘制仪表盘”),然后才能将这些关键点的表现状况与期望值进行比较。下面是针对常规系统与服务的两大类监控指标,以及参考依据:
综上,我们需要监控的各项基本指标,可被归纳到下图之中。当然,您也可以根据实际情况对其进行增减。
就监控的频率而言,我们可以按天计、甚至按小时来采集。而评估的周期则一般可以按照每月或每季度为单位进行考核分析。当然,在实际应用中,上述各方面的指标会存在着互相依赖、或相互影响的关系,我们往往不能孤立地只从某个切面去排查与分析。这也就是为何我们需要用全面的报告,配上综合图表的形式呈现出,系统的当前状态与设计目标之间的差距,再利用上下文的关联分析,以及趋势判断,来顺藤摸瓜地找到瓶颈的症结,以便在下一个环节着手改进。
值得一提的是,随着企业对于云服务的使用和对于业务连续性的重视,项目运维团队应当花费更多的时间从RTO和RPO出发,去重点评估不同用户终端的可访问性、服务的高可用性、不同地域的响应时间、以及存储的频率和备份的深度等指标。据此,我们不但可以合理地按需分配和调整服务相关资源,还能够通过与云服务商的协作,来提高系统的服务水平与鲁棒性。
各种由使用方回馈来的缺陷、或是由运维人员通过监控环节发现的问题,最终都需要被转呈服务开发团队进行改进。通常,我们可以分为:被动式紧急整改和主动式稳健改进,这么两种方式。
对于被动式紧急整改而言,由于时间紧、任务急,我们需要注意如下两个方面:
虽然属于紧急整改,但是我们仍需秉承“由大到小,增量渐进,关注运营,及时调整”的构建原则,并在实现方式上适当地借鉴:通过云服务平台提高运能,引入微服务架构提高灵活性,采用模板化和自动化促进智能运维等方面。
而针对主动式稳健改进而言,随着软件技术和硬件设施的不断迭代与进步,许多企业都会通过设立技术创新委员会,来对各种有利于改进现有服务、和提高当前生产率的技术与产品予以持续关注,并伺机采用。同时,他们也应当以开放的心态,鼓励第三方与之分享和展示新的技术产品,并通过对外提供数据源与分析支持等方式,协同优化现有的服务质量与流程。
当然,在具体实操中,我们仍需要从整体性能、运营成本、以及服务产品的互操作性和延续性出发,进行“小步快跑”。特别是对于一些稳定的云端应用与业务,我们要事先做好如下两个方面的准备工作:
总之,持续改进既需要多方的协作,也需要全面的考虑。
在完成了整改或改进措施的准备工作后,我们最后通过一套正式的变更流程,将其部署到生产环境、或替换当前的服务。由于此类变更往往会引起不同时长的中断,因此在变更请求(Request for Change,RFC)的提交准备环节,我们需要围绕着:“变更什么?何时变更?有何影响?”,这三类问题展开。据此,变更请求的具体内容通常会包括:
在具体实践中,我们还需要根据请求的不同特征与细节,注意如下方面:
在规范的企业中,变更请求一定需要通过变更管理委员会(Change Control Board,CCB)的审查与批准。其中:
在具体审批过程中,委员会可借助如下风险矩阵表予以评估:
当然,为了避免频繁的变更请求打扰、甚至拖累委员会成员的日常工作,同时也为了避免重要的变更被长期积压,委员会可以分别在每周二、四的中午,进行审批例会。通过集思广益与讨论磋商,委员会最终应做出批准、还是拒绝的结论。
实施人员在开始变更之前,应完成如下三个方面:
而在完成变更后,实施人员既要及时更新配置项(CI),又要做好相应的文档记录,以备后期审计。
综上,我们应当遵从如下变更管理流程与推进顺序:
值得一提的是,那些针对虚拟化和云服务的调整,会与传统的变更有所不同之处。我们尤其应当注意如下两个方面:
结合前面三期对于IT项目不同阶段的讨论,我们实际上已经覆盖并形成了如下一个完整的生命周期。我将它们总结在下图中,以方便大家“挂图作战”。
还记得一首老歌曾唱道:“人生豪迈,只不过是从头再来!”我们做项目的技术人员虽然可以如此,但是IT项目本身却像“开弓没有回头箭”那样,需要步步为营地扎实推进。
常言道“兵无常态,水无常势”。这些只是我从自己的经历和经验角度,进行的思考与总结,难免会由于能力限制了我的想象力。不过,我真诚地希望本系列中提到的各种有关IT项目的管理与治理实践,能够帮助您避免“踩坑”。千言万语汇成一句话:“Let’s have a happy ending!”
【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】
Dubbo 起源于阿里巴巴,对于我们做电商开发的人来说,基本是首选的技术,那么为...
电子配线架,英文为E-panel或者Patch Panel,又称综合布线管理系统或者智能布线...
日前,记者从北京市发改委获悉,本市电子政务云平台项目采用PPP模式投资建设。北...
美国云主机哪个服务商好?提供的美国云主机怎么样?有关这个问题,相信对于正要...
近日,全球知名分析机构IDC发布了《2017 Q4 China SDSHCI Market Overview》报告...
在互联网应用中,数据爆发式的增长,实际上软件架构的本质就是对数据的维护。对...
总结一下这几年使用堡垒机的经验教训,和大家做一个分享,无论是使用自建堡垒机...
毫无疑问,美国互联网的发展最早,其互联网技术销售市场极大,是跨境电子商务不...
容器是对IT和网络应用程序开发有重大影响的新技术,容器采用的增加改变了基于软...
数据库服务器是提供给程序或计算机连接到数据库的一种客户端-服务器模型的计算机...