交付|创造价值，持续交付：B端产品经理的方法论(11) 交付|互联网产品|持续|产品经

两种方法各有优劣，而且随着企业业务发展需求和具体软件产品的使用情况而变化；产品经理需要知晓这个领域的知识，参与和推动对应的决策和管理影响。
3）系统架构
跳出具体的开发事项的关注，在更高层面来看，无论是已有产品模块改进优化还是新的产品模块的引入，首先要做的分析就是其对现有系统架构的影响和适配性。
好比一栋20年的老房子，房屋结构单一，工艺落后；现在突然一家新的住户搬家进来，决定要加盖新风系统和电梯；这个时候就需要考虑已有的建筑结构是否能支撑这些新的建筑模块。
同样，如果新的产品模块需要通过新的技术来实现，或者需要采用新的语言来开发，都需要考虑适配性；例如，在移动APP的开发中，新的产品功能时使用最新的Flutter还是原生系统开发，以及开发的产品模块是否可以适配老的系统框架，和如何使用。
这些技术上的细节决定和讨论不是产品经理的专长，但是需要产品经理有对应的敏感度和基本认知，了解这些问题是需要覆盖的事项。这个对整个产品项目落地和交付范围规划都有影响。
4）DevOps 基础
以上是介绍了基本开发过程可能涉及的基本元素，无论是技术、流程还是参与人员的职能分工；如之前提到的，产品经理对于开发技术需要有一定的敏感度，了解最流行和广泛的行业实践，这样可以与开发团队有相通的语境和概念框架来沟通。
软件工程或者软件开发的方法和理念的不断演进，与之匹配交付方式和理论也随之产生；在过去很长一段时间，软件产品的开发周期较长，每次发布时间之间的间隔也比较远；因此，周期中的主要矛盾是在需求变更和研发效率上，而发布部署的时间成本和资源占用的成本相比起来不是那么突出。
但是随着敏捷开发的理念的广泛推广实施，和商业环境对产品快速发布部署的要求越来越高，开发和运维一体化，从而达到运维工程师和开发工程师参与整个服务生命周期的一系列实践被积极提倡。
在维基百科里DevOps被定义为：“DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维；DevOps运动的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）经行全面的自动化和监控；DevOps的目标是缩短开发周期，提高部署频率和更可靠的发布，与业务目标保持一致”。
从核心上来看，DevOps是敏捷开发的延续，将敏捷思想和精益的原则在运维领域来实践应用。
虽然狭义上DevOps只涉及到软件生命周期，但是它也是一种 IT组织管理的发展趋势；力图通过各种方式打破原有IT职能部门之间的壁垒和合作模式，使之行动更加紧密，从而适配和促进业务迭代速度，解决业务痛点。
如下图所示，DevOps希望做到的是软件产品交付过程中IT工具链的打通，形成良好闭环，使得各个团队减少时间损耗，更加高效地协同工作，增加整体的产出。

文章插图
在这里也有一些DevOps经常被使用的工具需要基本了解：

文章插图
DevOps 被业界快速接受，内涵和概念也不断延伸。
在各方专业人士的分析和解读下，DevOps 概念涉及到的知识内容正变得越来越庞大，模型也变得愈加丰富、深入和细分；与理论并行的就是新的架构范式和工具的出现，来支持DevOps的落地和实践。其中最为火热和流行的就是“云原生”Cloud-Native。
2015年，Google联合其他20家公司宣布成立了开源组织 Cloud Native Computing Foundation (CNCF)，并且给出了云原生的定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用；云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术；我们通过将最前沿的模式民主化，让这些创新为大众所用。
这么绕口难懂的定义，简单概括为4个要素：持续交付、DevOps、微服务、容器。

文章插图
云原生是一个概念集合，既包含微服务、容器，也包含更多的管理方法，比如持续交付、DevOps和重组等。