|
|
|
|
公众号矩阵

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

常言道:人们真正需要的不是“钻头”,而是由它钻出的“孔”。同理,我们在工作中需要管理的不是IT项目本身,而是由它交付出的产品服务。

作者:陈峻来源:51CTO|2021-03-17 09:00

【51CTO.com原创稿件】常言道:人们真正需要的不是“钻头”,而是由它钻出的“孔”。同理,我们在工作中需要管理的不是IT项目本身,而是由它交付出的产品服务。在上一期中,我们讨论了IT项目的需求和评估管理,给出了各种可选用的“钻头”,以及可参考的“钻孔”方法。下面,我们从项目的设计阶段开始,继续探讨有关项目开展与治理的各项实践。

本系列文章如下:

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

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

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

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

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

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

服务设计

首先,在着手设计之前,我们有必要综合考虑整体环境、现有资源、规定时间、内外风险、以及维护成本等因素。在此基础上,针对业务功能、容量性能、安全与可用性、参数指标、技术实现、模型架构、冗余排障、以及维护升级等方面,进行详尽的服务设计。而且,为了保证能够交付出用户满意的服务,我们应当在设计中重点关注:

  • 设定不同用户角色在使用过程中,对服务进行的各项操作步骤(或称故事线,playbook),以及业务数据在后台不同模块之间的流转过程。
  • 只有好用,才会被多用。客户体验(Customer Experience,CX)和用户体验(User Experience,UX)是不可忽略的方面。应充分考虑到各种使用场景中可能出现的错误。
  • 为待设计的产品和服务定义好相应的服务级别,以引起相关方的足够重视,而不是在事后再进行添加或调整。
  • 避免出现“项目未半,已花光预算”,以及逾期交付等项目失败的风险。
  • 减少项目进行中和交付的服务使用中,各方可能出现的责任界定不清、甚至是摩擦推诿等现象。

其次,我们需要对IT项目按照如下两个维度进行分类:

  • 对近期、乃至中长期的业务需求设计新的服务。如:新增云端业务,启用安全管控措施,转型为DevOps交付模式等。
  • 对现有的服务进行调整与改进。如:更新现有的技术实现方式,替换某个应用或模块,以及打造内网在线提交与派单系统等。

据此,我们在实际设计中,可以将待开发的新服务划分为如下三个层面:

  • 基本功能。即:某个产品或系统向用户提供的最基本、最低的服务。例如:应用服务的相关页面是否能被打开,以及业务申请按钮是否在点击后提供响应等。这类主要是一些“必点”的功能。也就是说,每个用户只要访问该系统、或使用该服务,就会与此类基本功能互动,因此这也是新产品或服务推出的根本所在。
  • 特定功能。即:区别于其他或现有产品或系统,满足特定需求的服务。例如:IT支持服务的在线派单系统,以及业务组件的秒级切换与容灾功能等。也就是说,这类主要是通过“人无我有”的途径,来满足差异化需求。
  • 增值功能。即:让用户更流畅、更满意地使用某项功能。例如:通过双活数据库保障业务数据的实时可用,以及根据错误代码与关键信息,自动生成问题解决方案等。也就是说,此类主要是通过“人有我优”的方式,增加用户的粘性与满意度。

显然,上述三个层面的参考标准主要是针对新建服务的。而对于现有服务的调整与改进,我们则需要全面考虑到:与其他当前产品或服务、与相关方、与既有架构、与可用技术、与现有管理实践之间的各种关系。

在设计的过程中,我们应当通过采用:绘制模块关联图、创建用户接口原型、分析可行性、确定实现优先级、编写数据字典等方法,来对项目在时间、成本、资源、以及风险等维度予以管控。

常言道:有项目就会有风险。而设计环节的风险主要来源于:对需求解读的缺乏,架构与定义的不清,实现方式与技术的误用,以及干系人与需求方的参与不足、或过多的干扰。因此,为了避免在项目的后期,以及在产品服务的交付与发布之时,面临被动的整改,甚至是重大的调整,我们可以采用如下流程,来提高设计的质量:

  • 确定各个组件的优先级->定义实体与属性->绘制逻辑关系图->梳理输入/输出流向->设计服务模型或产品原型等。

反过来,为了考核服务设计的绩效,我们也可以增加后续跟踪环节,从交付使用后的成本、效果、用户使用率、以及变更请求次数等维度,进行全面衡量。

需要注意的是,不只是新增的产品服务需要设计,那些针对现有服务的变更、迭代与退出,也需要通过流程的设计,以避免产生任何意外或负面影响。

设计阶段的最终成果交付包括:

  • 用户级:采用需求方容易理解的语言和图表,描述所需提供的服务,以及操作的规范,并最终获得需求方的确认。如果即将交付的是软件,这有时也被称为软件需求规范(Software Requirement Specification,SRS)。
  • 系统级:概要/详细设计说明(具体解释如下)、数据库设计说明、代码设计说明。
  1. 概要设计:有时也称高级设计(High-Level Design,HLD),交付的是产品服务的体系结构。
  2. 详细设计:有时也称低级设计(Low-Level Design,LLD),描述的是产品服务的每一项功能。

服务开发

总体而言,待开发的产品服务既可以是单个程序(如:程序套件、进程或工作流程),又可以是较大的系统(如:操作系统、环境或数据库),甚至不限于桌面应用程序、移动应用、嵌入式软件、以及各类网站。

目前,业界有两种普遍接受的软件开发方法,即:瀑布式和敏捷方法。而一直以来,大多数企业都持续运用传统的瀑布式开发模型。他们通过可预测的静态工作流,来确保开发团队能够根据预估的成本和截止日期,交付出高质量的软件。也就是说,此类开发模式通常会遵循如下软件开发生命周期(Software Development Life Cycle,SDLC):

  • 设计:包括用户界面、客户体验、服务设计等。前文已有讨论,此处不再赘述。
  • 开发:开发人员着手编写并构建软件的相关代码。
  • 测试:对可能出现的缺陷进行全面测试。测试人员通常会根据对于被测项目内部结构、以及实现原理的掌握情况,开展黑盒(完全不知)、白盒(全面知晓)、灰盒(部分了解)三种测试方法。测试内容包括:单元测试、集成测试、回归测试、信息安全测试、以及用户验收测试等。
  • 部署:将产品服务部署并发布到生产环境中,以供最终用户使用。
  • 运营:在使用产品服务的过程中,持续及时地解决用户碰到的任何实际问题;有效地管理代码存储库,并维护其完整性;执行版本控制,持续迭代并管理各个代码块。

在上述流程中,每一个阶段的输出都是下一个阶段的输入,显然,这样的线性固定模型,不但给可能出现的变更带来了巨大风险与成本,而且使得最终用户无法参与到开发的过程中,只能被动地等到最终“见证奇迹”。此外,由于测试人员只有在开发阶段结束后才能接触到代码,进而开展测试工作,因此该开发模型会使得开发人员与测试人员、需求方都缺乏协作。因此,近年来,不少企业都采用了一种新的、非固定线性路径式的敏捷方法(Agile method)。作为遵循迭代式开发的方法,它并不会为项目的全部过程创建各种固定任务,而是将开发分为多个迭代周期(Sprint)阶段。相比瀑布式开发,该方法具有如下的优点:

  • 由于将单个大项目切割成了多个小任务,因此具有较短的开发周期,能够使得项目具有较强的适应性。项目组能够随时响应需求方提出的任何重大或微小的变更。
  • 由于每个Sprint都有一个测试阶段,因此在开发人员每次发布新的功能后,测试人员都能立即开展回归测试(regression testing)。而且,需求方也能够及时做出接受或要求变更的决定。可见,三方都能够持续交流,并通力协同。

当然,文档是敏捷开发方法的短板。由于开发过程中的频繁变更和持续迭代,因此文档往往无法及时跟进和到位。这给复杂的大型项目带来了一定的不确定因素。因此,项目团队应当及时更新和完善相关文档。

开发安全

如今,随着信息安全人员已经成为了企业IT团队里的标配角色,他们该如何在IT项目的推进过程中发挥作用呢?这就要提到由敏捷开发模式所发展而来的DevSecOps了。

DevSecOps旨在将安全性尽量“左移”到各个开发子周期的初始阶段,以协助研发人员尽早获悉应用代码中可能存在的威胁与漏洞。对此,我们可以采用如下四种实践模式:

  • 未雨绸缪式:分割应用程序之间依赖性,以便隔离各个组件,将来漏洞和威胁限制在单个组件中,进而保证其他组件持续运行。该模式的典型场景是微服务应用。
  • 一票否定式:通过代码逻辑和用户场景的构建,在用户出现恶意行为时,中断其所有进程。例如:如果有用户在访问某个网站时,试图进行跨站点脚本注入攻击,那么其任何操作行为与会话就应当被直接阻止。
  • 他山之石式:在缺乏安全专家的团队中,可以通过业界常用的威胁模型与管控模型,来提前识别应用组件可能面临的潜在风险,并选取最佳防护措施;同时,也能够保证安全人员与研发部门的沟通,更加顺畅,更有说服力,更容易达成共识。
  • 川流不息式:利用自动化监控手段和提供多种输入参数,将对于运行环境与用例的风险评估,集成到产品服务的设计、直至实施环节中,涵括整个项目的生命周期。

此外,在项目实践中,我们也会重点实施如下方面:

  • 针对不同的应用服务,设置不同的用户职能组别。
  • 防止在应用数据的传输过程中,泄漏任何密码、口令、证书或私钥信息。
  • 将多种应用程序的登录方式统一为单点登录(SSO),以实现用户账号权限的自动匹配。
  • 使用成熟的产品来检查证书并管理密钥,及时发现过期与注销等情况。
  • 检查程序代码,及时发现无效或过时的依赖项与代码库,潜在的内存泄漏、无限循环、以及程序漏洞。

小结

综上所述,我们从设计、开发、以及开发中的安全,三个方面讨论了在IT项目推进与实施过程中的各项要点。值得一提的是,由于项目组的团队成员既可能是其他职能部门临时借调过来,又可能按需从外部引进和组建而成,因此为了保证大家“比较能打”的战斗力,项目组内成员之间的沟通与协作是必不可少的。为此,我们需要通过完善的规划、委派、协作和协调流程,既激发人员的积极性,又能够实现产品服务的成功交付。

P.S.,给大家的系列“思想汇报”进行至此,我突然想到了著名的坎宁安定律(Cunningham's Law),也意识到在前面的各类治理思考中可能存在着不少不成熟、不完善、甚至不尽正确的地方。希望读者您能够不吝留言,及时帮我指出。本人在此谢过。

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

【编辑推荐】

  1. Go语言设计模式与追妹子
  2. 聊聊Ocelot网关使用IdentityServer4认证
  3. 如何找到优秀的服务器虚拟化管理软件
  4. 《数据持久化与鸿蒙的分布式数据管理能力》直播课答疑和PPT分享
  5. 阿里终面:如何设计一个高性能网关?
【责任编辑:华轩 TEL:(010)68476606】

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

订阅专栏+更多

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

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

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

7人订阅学习

云原生架构实践

云原生架构实践

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

36人订阅学习

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

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

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

228人订阅学习

读 书 +更多

公钥基础设施PKI及其应用

公钥基础设施PKI(Public Key Infrastructure)是利用公钥概念和加密技术为网上通信提供的符合标准的一整套安全基础平台。公钥基础设施能为...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微