|
|
|
|
公众号矩阵

【廉环话】防疫一周年后的IT项目管理思考 --验收、监控、改进、变更

大家好,截至上期,我们已经在实质上将手头的IT项目发布出去了。但是,正如那些得以敲钟上市的公司往往担心会“破发”那样,我们也不希望自己好不容易完成的项目迅速成为了“月抛型”。为此,我们需要在服务系统发布之后,对其开展各项后期“保值”工作。

作者:陈峻来源:51CTO|2021-04-08 09:00

【51CTO.com原创稿件】大家好,截至上期,我们已经在实质上将手头的IT项目发布出去了。但是,正如那些得以敲钟上市的公司往往担心会“破发”那样,我们也不希望自己好不容易完成的项目迅速成为了“月抛型”。为此,我们需要在服务系统发布之后,对其开展各项后期“保值”工作。

本系列文章如下:

【廉环话】不要让数据安全成为“盲盒”里的那只猫 -- 浅谈咨询业数据安全体系建设

【廉环话】防疫一周年后的IT治理思考 --架构与服务目录

【廉环话】防疫一周年后的IT治理思考 --可用性、关系与财务管理

【廉环话】防疫一周年后的IT治理思考 --能力、知识、问题与请求管理

【廉环话】防疫一周年后的IT项目管理思考 -- 需求评估

【廉环话】防疫一周年后的IT项目管理思考 -- 设计、开发、安全

【廉环话】防疫一周年后的IT项目管理思考 --测试、部署、发布

验收确认

既然服务产品已经能够以一套正确的、被授权的、以及经过内部测试的软/硬件形式存在于实际生产环境中,那么我们就需要协同需求方、以及使用方,顺势开展项目的验收与确认工作。通常,我们可以将验收分为初验和终验两个阶段:

  • 初验,一般发生在系统部署完成之时,主要着眼于服务功能方面。那些在初验中发现的问题,应当以书面备忘录的形式被记录,由服务的开发方承诺解决的时限,并由验收双方签字予以确认和归档。
  • 终验,一般发生在系统完成发布、并已试运行一段时间之后,主要关注的是服务性能方面。我们既可以从实际使用方收集反馈意见,也可以邀请有资质的第三方予以评测与验收。

在完成初验与终验工作后,我们需要及时更新配置项数据库(CMDB)里的相关配置项(CI),以及已知错误知识库(KEDB)里的信息。通过运用易于使用方理解的语言,去描述错误的现象与特征,我们不但可以提前向用户传递和警示可能碰到的问题,还能够合理地控制他们在使用过程中的期望值和体验度。此外,提供相应的技术支持和用户培训,也是在服务发布后和验收确认前阶段,所必不可少的环节。

监控分析

新增的服务在被使用一段时间后,往往会出现加载时间、交付效率、以及运行性能等方面的变化;而那些变更的服务则可能逐渐对原有的系统产生流量、负载、出错了等方面的影响。为此,我们需要通过针对关键性衡量指标的监控,及时捕获和评估出流量的峰值、负载的瓶颈、甚至是逻辑上的调用错误。

显然,为了量化目标系统与服务的各方面表现,在着手进行相关指标的挖掘和分类之前,我们需要先确定待采集的关键点指标(也就是我们常说的“绘制仪表盘”),然后才能将这些关键点的表现状况与期望值进行比较。下面是针对常规系统与服务的两大类监控指标,以及参考依据:

  • 资源指标
  1. CPU使用率:是指进程使用CPU的时间百分比。通常,我们可以接受的使用率为85%以下。也就是说,如果CPU的空闲持续为0,或者运行的队列数远大于CPU的核数,则被视为CPU 出现了瓶颈。
  2. 内存利用率:如果空闲的内存过小,会出现系统频繁地调动磁盘页面文件的情况。因此通常我们应保证至少有10%可用的内存。也就是说,内存的使用率也不应达到或超过90%。
  3. 磁盘I/O:其中,写I/O操作是指将数据存入磁盘,读I/O操作则是指从磁盘读取数据。我们可以采用不同操作所占用的时间百分比来度量。当每个磁盘的I/O数超过其本身标注的I/O能力时,则会导致CPU的等待。也就是说,当磁盘需要长时间进行大数据量的读写操作时,就会产生磁盘I/O的瓶颈。
  4. 网络带宽:我们可以通过计算目标系统每秒发送和接收字节的速率,来和现有网络资源所承诺的速率作比较。例如,我们可以尝试性地减少网络出口处交换设备所提供的转发能力,来检查下列性能指标的受影响程度。
  • 性能指标
  1. 并发用户数:是在某个抽样时刻,同时向系统提交请求或接受数据的用户数。
  2. 在线用户数:是在某个时间段内,访问目标系统的用户总数。毕竟并非所有访问用户,都在同时与系统进行数据交换。也就是说,只要其会话处于活跃状态,即可算作在线用户。
  3. 平均响应时间:是指从用户提交访问请求,到其接收到系统响应所消耗的平均时间。随着软/硬件技术的发展,如今我们对于平均响应时间的期望往往要求在3秒之内。
  4. 事务成功率:是指在单位时间内,系统能够成功完成诸如:用户登录、提交订单、完成支付等操作(即,既定事务)的数量,占总体事务的比例。
  5. 超时错误率:是指那些由于超时或各种错误所导致的失败事务的占比。例如,页面上产生的HTTP 4XX和5XX等错误,以及由于线程中止所导致的应用重启等故障。

综上,我们需要监控的各项基本指标,可被归纳到下图之中。当然,您也可以根据实际情况对其进行增减。

就监控的频率而言,我们可以按天计、甚至按小时来采集。而评估的周期则一般可以按照每月或每季度为单位进行考核分析。当然,在实际应用中,上述各方面的指标会存在着互相依赖、或相互影响的关系,我们往往不能孤立地只从某个切面去排查与分析。这也就是为何我们需要用全面的报告,配上综合图表的形式呈现出,系统的当前状态与设计目标之间的差距,再利用上下文的关联分析,以及趋势判断,来顺藤摸瓜地找到瓶颈的症结,以便在下一个环节着手改进。

值得一提的是,随着企业对于云服务的使用和对于业务连续性的重视,项目运维团队应当花费更多的时间从RTO和RPO出发,去重点评估不同用户终端的可访问性、服务的高可用性、不同地域的响应时间、以及存储的频率和备份的深度等指标。据此,我们不但可以合理地按需分配和调整服务相关资源,还能够通过与云服务商的协作,来提高系统的服务水平与鲁棒性。

持续改进

各种由使用方回馈来的缺陷、或是由运维人员通过监控环节发现的问题,最终都需要被转呈服务开发团队进行改进。通常,我们可以分为:被动式紧急整改和主动式稳健改进,这么两种方式。

对于被动式紧急整改而言,由于时间紧、任务急,我们需要注意如下两个方面:

  • 圈定范围:由于当前系统服务往往存在着功能繁杂、代码量大、依赖关系错综等特点,会导致整改起来难度较大,且成本较高。因此,我们的首要任务是要缩小、明确待整改的具体范围。在实践中,如果能选择的话,我们可以从一些功能性单一、且非关键性的组件开始。
  • 解耦功能与数据:为了将某些功能、及其数据从原有的系统中剥离出去,并保证持续提供既有的服务,我们可以适当地使用前端代理、或后端转发的机制,来临时构建和提供组合式系统。

虽然属于紧急整改,但是我们仍需秉承“由大到小,增量渐进,关注运营,及时调整”的构建原则,并在实现方式上适当地借鉴:通过云服务平台提高运能,引入微服务架构提高灵活性,采用模板化和自动化促进智能运维等方面。

而针对主动式稳健改进而言,随着软件技术和硬件设施的不断迭代与进步,许多企业都会通过设立技术创新委员会,来对各种有利于改进现有服务、和提高当前生产率的技术与产品予以持续关注,并伺机采用。同时,他们也应当以开放的心态,鼓励第三方与之分享和展示新的技术产品,并通过对外提供数据源与分析支持等方式,协同优化现有的服务质量与流程。

当然,在具体实操中,我们仍需要从整体性能、运营成本、以及服务产品的互操作性和延续性出发,进行“小步快跑”。特别是对于一些稳定的云端应用与业务,我们要事先做好如下两个方面的准备工作:

  • 摸清现有云平台所用到的API、数据格式、标准与支持文档、业务定制部分、平台依赖性、以及与新技术可能出现的不兼容性等问题。
  • 做好现有数据的备份、导出切换、顺序导入、以及详尽的回滚方案。

总之,持续改进既需要多方的协作,也需要全面的考虑。

变更控制

在完成了整改或改进措施的准备工作后,我们最后通过一套正式的变更流程,将其部署到生产环境、或替换当前的服务。由于此类变更往往会引起不同时长的中断,因此在变更请求(Request for Change,RFC)的提交准备环节,我们需要围绕着:“变更什么?何时变更?有何影响?”,这三类问题展开。据此,变更请求的具体内容通常会包括:

  • 需求程度:属于标准、一般还是紧急。其中:
  1. 标准变更,是低风险、且预授权的变更,易于被理解与记录。初创此类变更时,应全面评估风险并完成授权,之后不必重复。
  2. 一般变更,应根据类型与既定的模型,来确定需要评估和授权的角色。可由手动创建请求,也可由CI/CD管道进行自动化加速。
  3. 紧急变更,包括解决事故或部署热补丁等需求。应尽可能地经历与一般变更相同的测试、评估和授权环节。在实施前,酌情允许缺少相关文件。由于时间受限,测试较少,因此需要了解业务风险的高级管理人员予以人工授权。
  • 变更类型:操作系统、应用软件、硬件设备、网络组件、通信线路、文档目录、配置项、以及安全相关。
  • 风险预判:低、中、高。
  • 影响预判:单个应用系统、部分用户群、职能部门范围、多分支站点、整个企业。
  • 变更时间:提议开始时间、目标完成时间与耗时。
  • 变更内容:当前状态、更改内容、预期目标。
  • 回滚计划、变更前后的测试方案等。

在具体实践中,我们还需要根据请求的不同特征与细节,注意如下方面:

  • 分清变更发起人与实施人。有时候发起变更请求方不一定是真正实施的人员。
  • 根据波及范围与紧急程度的不同,应事先规定好不同的颜色代码,以便审批人员能够从庞复的记录中,一眼认出或筛选出重大的变更需求;同时也能够引起相关技术人员与受影响用户的注意。
  • 可以附上必要的截图、邮件或文档,让审批人员更为深入且全面地了解变更产生的来龙去脉。而且,如果涉及到比较复杂或大型的变更,我们还应适当地配上能够体现变更步骤的流程图,以提审批人员参考。

在规范的企业中,变更请求一定需要通过变更管理委员会(Change Control Board,CCB)的审查与批准。其中:

  • 该委员会的成员通常包括:企业业务部门、IT管理层、技术专业职能部门、以及外包/供应商等代表。当然,除了固定的人员角色之外,也可根据实际变更请求的特点,动态进行调整。
  • 审批与检查的主要内容包括:提出人员的角色、变更的合理性、预期收益、时间安排、所需资源、以及对其他产品与服务的影响等方面。
  • 委员会成员之间应共享一张“事件汇总日历”,以便根据请求的时间,全盘考虑变更时段的忙闲程度,按需调整计划,并最终将其加入总日历表中。

在具体审批过程中,委员会可借助如下风险矩阵表予以评估:

当然,为了避免频繁的变更请求打扰、甚至拖累委员会成员的日常工作,同时也为了避免重要的变更被长期积压,委员会可以分别在每周二、四的中午,进行审批例会。通过集思广益与讨论磋商,委员会最终应做出批准、还是拒绝的结论。

实施人员在开始变更之前,应完成如下三个方面:

  • 在独立的系统上执行并完成基本测试与演练。
  • 使用事先规定好不同颜色代码的通知模板,向相关人群发送服务中断与变更实施的相关通知。
  • 为目标系统建立基准线,也就是俗称的:给系统的当前状态“拍快照”。该基线既可以作为变更后参考比对的依据,又能够成为回滚操作的目标。

而在完成变更后,实施人员既要及时更新配置项(CI),又要做好相应的文档记录,以备后期审计。

综上,我们应当遵从如下变更管理流程与推进顺序:

值得一提的是,那些针对虚拟化和云服务的调整,会与传统的变更有所不同之处。我们尤其应当注意如下两个方面:

  • 应充分计划与记录各种对于镜像与配置模板的修改、云存储空间的配额、以及虚拟CPU/内存资源的增减等操作。
  • 对于前面提到的被动式紧急整改,应当根据既定的协议,与云服务提供商事先明确好各自的职责。例如:在何种情况下云服务商有权先采取必要的变更、再通知租户;在何种情况下租户的自行变更需要备案、甚至要得到服务商的批准,以免影响到其他业务租户。

总结

结合前面三期对于IT项目不同阶段的讨论,我们实际上已经覆盖并形成了如下一个完整的生命周期。我将它们总结在下图中,以方便大家“挂图作战”。

还记得一首老歌曾唱道:“人生豪迈,只不过是从头再来!”我们做项目的技术人员虽然可以如此,但是IT项目本身却像“开弓没有回头箭”那样,需要步步为营地扎实推进。

常言道“兵无常态,水无常势”。这些只是我从自己的经历和经验角度,进行的思考与总结,难免会由于能力限制了我的想象力。不过,我真诚地希望本系列中提到的各种有关IT项目的管理与治理实践,能够帮助您避免“踩坑”。千言万语汇成一句话:“Let’s have a happy ending!”

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

【编辑推荐】

  1. 疫情的启示:让IT架构“与时俱进”,这5个技巧你知道吗?
  2. Veritas增加横向扩展功能,助力企业驾驭多云环境的复杂性
  3. 拥挤的云赛道,运营商开始加速
  4. MIT:这双AI袜子,暴露了你的行动丨Nature子刊
  5. reddit热议:机器学习也内卷,25岁的我该怎么转行计算机?
【责任编辑:华轩 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

数据湖与数据仓库的分析实践攻略

数据湖与数据仓库的分析实践攻略

助力现代化数据管理:数据湖与数据仓库的分析实践攻略
共3章 | 创世达人

7人订阅学习

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

37人订阅学习

数据中心和VPDN网络建设案例

数据中心和VPDN网络建设案例

漫画+案例
共20章 | 捷哥CCIE

230人订阅学习

读 书 +更多

Silverlight范例导学

本书介绍跨平台与跨浏览器的客户端技术Silverlight的使用方法。主要内容包括Silverlight功能概述与实践、探讨Silverlight插件、事件与交互...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微