作者：李宏喜 IDCF研发效能（DevOps）工程师（中级）认证学员
在软件研发效能（DevOps）的学习过程中，我认识到诸位老师从软件全生命周期的不同角度，讲述着研发效能的提升。
敏捷宣言从2001年诞生到现在，已经有很多年了。敏捷逐渐地融合精益等思想发展延续至DevOps，而DevOps又在和软件领域的多个方面融合，产生着不同的分支。在这个发展的过程中，数据产业也在不断地发展之中，人们开始从数据的角度思考生活之中的方方面面。那么是否可以从数据的角度思考系统，进而思考数据系统在软件研发效能（DevOps）提升过程中的变化和发展呢？本文将对此做一个初步的思考。
我认为DevOps是一个基于广义流水线的以价值流交付为特征的理念、方法、工具的系统性的结构。而数据价值通过迭代式的构建、通过系统性的持续交付不断得到体现。
在课程的【开发与交付】这一章中，徐磊老师讲到：广义流水线的起点是一个idea。让我想起了《持续交付2.0 业务引领的DevOps精要》（作者：乔梁）这本书中讲的：“持续交付2.0双环模型涉及企业内多个部门与角色的合作，而且其目标是缩短端对端（即从idea到idea）的闭环周期，这必然会影响到内部合作方式与流程”，而在吴军的《数学之美》中讲到：“信息是消除系统不确定性的唯一办法”。彼得•德鲁克也说：“成果存在于企业的外部，在企业的内部只有成本”。我个人认为软件研发的过程是一个从提出假设到验证假设的过程，也就是假设驱动的过程。而信息可以看作是数据的业务概念。我个人的理解，如下图所示：
01过程
徐磊老师在讲【开发与交付】时讲到了“研发过程全景图”，其中设计的过程是由架构模型树和条目化需求，在持续交互中形成不同版本的开发任务而体现的,如下图所示：
研发过程全景图局部
这也让我想起问题域和方案域的概念，在问题域和方案域之间，通过联想、特征的触发，在交互之中，不断地认识。
问题和方案的交互
在学习杜伟忠老师的【产品设计】的课程中，我认识到：“整体的体验交互设计是软件开发中的非常重要的一环。整体的概念一致性是一个重要的原则。在与用户的迭代式的交互过程中，原型逐渐明确,概念一致性得到体现”。我也想到通过设计树和原型设计的连接，又使得设计具体化，为迭代式开发的进行做出准备。而这个具体的过程可以通过Scrum中的PBL的梳理会这类的会议来达成。
在【测试与安全】这一章中，陈晓鹏老师讲到了三种测试服务器托管网用例的设计技术：错误猜测法、等价类分析法、边界值分析法。其中MECE原则是指相互独立、完全穷尽。这使我想起了数据分类的思维模型，进而对于数据的系统，有了一个认识。我们的软件系统可以看作是一个数据的系统，这让我可以从数据的不同的视角，去看系统、去理解系统。在实践中, 结合三种测试技术，去设计测试用例，从不同的视角去思考系统的行为，而测试的过程就像是解一个方程式。当然，我们可以不仅仅在测试这一个角度，去理解数据系统这个概念。
赵舜东老师在讲解【运维与监控】这一章时，讲到了微服务的拆分：“应先基于数据库隔离维度进行拆分，再基于服务关联和耦合维度进行拆分”。而KentBeck在《实现模式》中讲到4个原则，节选如下：
1. Local Consequences
Itcan be understood gradually without first having to assemble an understanding of the whole.
2. Minimize Repetition
Duplication isn’t evil, it just raises the cost of making changes
3. Logic and Data together
To make a change, the logic and data are likely to have to change at the same time.
4 Symmery
If a similar thought exists in several places in the code, making them symmetrical to each other is a good first step towards unifying them.
我认为这四个原则与“应先基于数据库隔离维度进行拆分，再基于服务关联和耦合维度进行拆分”在原理上是相通的。而这种拆分的方式也减少了出错的可能。数据总是与逻辑在一起，构成着系统。这也和《持续交付2.0 业务引领的DevOps精要》（作者：乔梁）中讲到的“大系统小做”的原则一致。
我在《实现模式》（作者：KentBeck）这本书中，看到这样的代码:
voidprocess(){input();tally();output();}
我有了一个新的认识，下图所示：
DevOps所倡导的迭代式开发过程，将原有的瀑布式的过程，拆分成多个迭代的过程，将复杂问题的管理简单化。
反之，数据系统的一个个的端到端的对称，在DevOps这个迭代的过程中持续得到体现，犹如图1所示的价值交付的过程。
徐磊老师在【开发与交付】这一章中，讲到“微服务立方体”这个概念，在单体架构向微服务架构逐步演进的动态过程中，在三维交互的过程中，数据的一致性是否可以理解为数据系统的对称呢？
也因为数据在三维空间中的位置的确定性，是否可以通过数据来反向思考系统在某一个位置上的特征呢？从而对于价值交付的过程，做出反向的思考，做出整体的结构化的优化呢？这里的整体是否可以涵盖软件的系统和组织的结构呢？徐磊老师说:“管理属性和工程属性的衔接点就是版本管理”，这又与系统在三维空间中的位置，又有什么样的关系呢？我初步的理解，如下图所示：
正如《奇特的一生》（作者：格拉宁）这本书中所讲：“复活”要容易、准确，因为数据很多，空间和时间坐标都可以复制。
在软件研发过程中，在空间中复盘、复制，我的认识，如下图所示：
从数据系统的角度去思考微服务的构建或者拆分、思考敏捷测试之中的测试用例的设计、思考“大系统小做”的原则、思考KentBeck的实现模式四个原则、思考“微服务立方体”的概念。多角度的思考带来了认识的提升。
02实施
在项目的实施过程中，通过迭代式的过程管理，使风险可控、使团队能够迅速学习和改进。而在这个过程中， 采用正确的诸如scrum的方法则是关键。
在自组织的团队中，应发挥每一位团队成员的特长，根据具体的开发工作，组合不同特点的团队成员，考虑团队成员的工作状态，合理分配工作。
敏捷开发中倡导代码集体所有制，我个人认为团队的核心技术人员应对架构的合理及稳定负责，也应对版本的发布和功能的交付负责。而开发人员在协作和讨论中可以做局部和细节的设计做出调整。我认为基于Git的版本管理策略是符合代码集体所有制这一原则的。
在课程中，王立杰老师也讲到“如何有效地落地DevOps”，讲述了以用户为中心，坚持自动化、协作化的概念。彼得•德鲁克在《卓有成效的管理者》中讲到“唯有从事对的工作，才能使工作有效”。价值是由用户决定的。我个人认为：在软件的实施过程中，通过Show case的这种形式向用户展示可以运行的、关键的、简单的业务功能，得到用户的反馈，并且在持续的迭代中使用户的 idea得到持续实现，这是做“对的事情”的过程。而这个过程离不开自动化和协作化，通过快速、稳定地部署正确的版本，用户和开发团队都将会得到积极的反馈，这是行之有效，这是正确地做事的过程。这个过程离不开理念、方法、工具的组合。
在实施的过程中，如何处理团队间、客户之间的协作的问题呢？我个人认为，应建立组织级的沟通机制。在实践中，广义流水线的建立离不开组织之间的信任与沟通，离不开思想的转变。
《数学之美》(作者：吴军) “信息是消除系统不确定性的唯一办法”。在迭代式的开发过程中，用清单等形式采集产品研发所需要的信息，持续消除需求的不确定性。通过假设驱动的方式得到反馈，持续系统化地消除系统的不确定性，拥抱变化。数据系统在不确定到确定中，持续地变化着。
在实施的过程中，正如陈晓鹏老师所讲敏服务器托管网捷测试有自身的特点，需要和迭代式的敏捷开发相结合，拥抱变化。我认为：敏捷测试不应该是瀑布式的，先设计完成所有的测试用例，再来测试。而应该在PBL之后，根据实际的情况，运用错误猜测法、等价类分析法、边界值分析法等不同的测试技术，快速设计迭代开发所需要的测试用例，在适应变化中，正确地做事。
通过学习庄俊乾老师的【安全领域】的课程中，我认识到价值的交付，不可避免地会面对安全的问题，数据的安全是一个不能忽视的问题，而DevSecOps则是DevOps在安全领域的发展。
最后，在动态的迭代中，持续地不断认识数据系统的变化，认识价值的交付。从数据系统的这一角度，对研发效能（DevOps）的这个process，做初步的思考和学习。我也认识到，在数据的时代，DevOps将会得到更加广泛的应用。
参考文献：
《持续交付2.0 业务引领的DevOps精要》 （作者：乔梁）
《数学之美》(作者：吴军)
《暗时间》 （作者：刘未鹏）
《Implementation Patterns》 (作者：[美] KentBeck)
《卓有成效的管理者》（作者：[美] 彼得•德鲁克）
《奇特的一生》（作者：[俄] 格拉宁）
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
相关推荐: ACL/IP-PREFIX +ROUTE-POLICY
1、实验拓扑图 2、实验目的 测试“全允许则允许，有拒绝则拒绝” 3、实验步骤 3.1 访问控制列表 acl number 2000 rule 5 permit source 3.3.3.3 0.0.0.0 3.2 配置路由策略 route-policy p1…
