本篇是探索DevOps的世界系列的最后一篇，所以就对DevOps如何在企业中进行落地这个议题再继续做下个人观点的讨论。
其实DevOps中涉及的议题还有很多，比如分支管理的策略、混沌工程、产品经理如何去迭代每一个大小需求、灰度/蓝绿发布等，这十篇文章也无法去一一讨论，所以我只能通过一些特定的案例去阐述一些比较重要的议题，对这些议题感兴趣的可以去看相关的资料。
今天我们来讨论一下DevOps产品设计和逐步推进落地的方式。 在产品设计体验中经常会从高到低讨论五个层级，分别是战略存在层、能力适应层、资源结构层、角色框架层以及感知层，这五个层面其实也是指导着某个产品逐步由上至下去落地的步骤。正常作为产品经理应该也都知道这五个层面所代表的意思。我今天可能会从另外几个层面来讨论。
前段时间读过一本描述以色列闪存盘之父的书，叫做《机遇之门》，当然整本书其实是着重描述整个创业心路的，但其实有很多作者的观点与产品设计体验的五个层面不谋而合。
首先是战略层面。
按照书中作者的观点，战略层面的内容其实就是定义一个产品或者公司近期的发展基调，而且这些基调往往在一段时间之内是不会变化。 那对于DevOps来说，有哪些东西是能够作为战略层面的基调呢？我这里想到了几个。
第一，敏捷与效率。正如前面几篇文章所描述的，引入DevOps的目的其实就是为了解决我们在传统研发交付流程中所出现的影响效率的痛点，从而能够提高整个研发交付流程的效率；
第二，质量量化。光有效率还不行，我们还要去思考怎么在有效率的同时，也能够让质量进行量化，从而通过多次迭代来找出一个团队中到底有哪些技术债是需要去解决的，以及这些技术债产生的真正原因；
第三，生产力解放。这一点其实和第一点有点类似，但这点其实想说明的是，怎样通过效率的提升，从而能够让一些角色的生产力得到释放，从而将充分的精力放到更有意义更有价值的事情上；
第四，落地成本。这块是需要重点考虑的一个点，因为DevOps会涉及到组织中方方面面，除了带来一些新的理念，同时也会同步带来很多新的技术栈和技术平台；另外，是否有相应的团队去长期支持迭代优化，也是一个成本考量的事情。
光有战略层面的基调，肯定还不行，哪怕这个战略目标是全世界仅有的一个。所以匹配以相应的战术层面的支持也是很有必要。
谈到战术层面的支持，其实就引申到组织内能力范围的事情了。 首先，DevOps的推广肯定不是一口吃一个胖子，是一个长期迭代的过程，会需要根据组织架构的形式去稳态推进与变化。所以我们就可以考虑是不是可以使用一些试点的方式进行，也就是目前谈的比较火的传统企业双模态发展。
另外，关于质量，因为历史的长期原因，所以也不可能一下子就把质量设定得老高。这个时候就需要按照每个团队业务系统的形态、问题现状等，动态地进行质量阈值的控制。
当然，还会涉及到成本的问题。纵使DevOps有多好，我个人觉得组织也不可能直接创建一个地表最强人数最多的战队来进行DevOps的落地，因为比起业务发展来说，DevOps是属于一种长效机制的投入。所以我们可以考虑先从某几个熟悉的人组建一个小的团队入手。
除了人的问题，我们也会考虑技术的投入，有点预算实力的公司，可以考虑从外部引入成熟产品；有技术实力的，可以让一些人研究开源的产品，从而定制出适合公司现状的DevOps；没预算没技术实力的公司其实也不用愁，现在社区其实有很多成熟的开源产品使用，可以先进行试水，后面等推广的不错再进行平铺，一些开源产品我在前面几篇也做了不少的介绍。
到这个时候，我们就可以去进行DevOps产品的调研、分析、设计以及各种拉会讨论了。
我们知道了要干什么以及怎么干之后，接下来我们可能就要考虑实施路径以及资源投入问题了。
正如我在机遇之门中所看到的，在实施层面，我们是采取艰难的短跑还是轻松的长跑，又或者我们是否可以做一个『厚脸皮的模仿者』等。每一种思维方式所带来的实施路径和资源投入都不一样。
我们就拿是否做一个『厚脸皮的模仿者』来说，有些时候我们对于一款产品的实施因为自己工作经历的问题可能是没有很好的思路的，这个时候我们就可以去模仿别人的产品，比如别人产品的设计方式、所采用的技术栈等，站在巨人的肩膀上往往除了让我们看得更远外，可能也能让我们少走一点弯路。
因为DevOps所涉及的很多内容我并不觉得都是新的领域，只是将很多以前分散的领域通过一定的方式定制到整个流水线中。另外，我个人觉得做一个『厚脸皮的模仿者』并不是坏事，因为在有限的成本和资源下，如何快速地去实施一个产品往往也是我们该思考的一个问题，只是不能做一个拙劣的模仿者，所谓拙劣的模仿者就是并未去深度地思考别人产品的设计与思考逻辑就开始按照表层模仿的那类。
谈好了实施后，我们可能就要去思考用户的问题。
就像机遇之门的主人公当年创造DiskOnKey一样，其实就是一个思考用户的问题。
那DevOps会涉及到哪些有关用户的问题呢？这里我列举几个。
比如在整个流水线中我们该如何将企业中的组织架构数字化到系统中，是缩减还是定义新的角色用户，所实施的是否去与真实组织架构中的成员去沟通过；比如，在一些传统的企业，往往可能一个月才会发一个大的版本，那假如采用了DevOps的流水线，我们是否需要去满足这一类的发布诉求，还是可以通过新的方式去规避掉；再比如，我看到一些发布平台很多基础的信息都暴露给研发同学，比如环境信息、K8S资源文件信息等，这些信息是否需要放开给研发线还是说与企业中的框架等去统筹，或者研发线有实力去Hold住这些内容，也是用户的一种思考逻辑。 所以我们发现，DevOps一些平台所设定的用户主要还是以组织架构中的成员相吻合，做好充分的沟通交流以及体验收集也是DevOps得以推进的保障之一。
最后一部分其实就是信息流这一部分，也就是所谓的界面架构。
页面是离系统使用者最近的一层，所以多去思考页面的编排逻辑肯定是百利无一害的。做过移动端架构的同学应该都知道，一个APP或者H5的响应速度除了与后端的性能有关系，也与页面端的元素编排有关，页面端的元素编排影响了页面的渲染方式与速度。 另外，页面中元素的布局影响了用户的操作体验。比如我举几个例子。 往往通过容器化部署的应用我们最终都要暴露svc的地址供给研发同学接入使用，那就带来一个问题，研发同学怎么能够快速地获取到这个地址？ 我们在做服务编排的时候总会需要去调整一些资源配置等信息，那么在服务编排中是否包含了些许需要研发同学去思考咨询才能懂的内容？因为平台毕竟是提升效率，而不是无形中去增加使用屏障。 比如当应用发布失败的时候是否能够及时告知研发同学的异常信息以及解决方式。 ……
以上的这些问题其实都是在进行落地过程中需要不断去思考打磨的点，而且很多点与企业内整体的研发运维现状有关系。所以DevOps系列平台的落地，对团队成员的要求比价高，除了理念相合外，在技术和产品设计上也需要有一定的能力。而这些也仅仅是DevOps整个体系落地的一部分内容。
DevOps落地非一朝一夕的事情，其首先是一个基本认知的问题，有了相同的认知后，才是逐步落地的一个过程。
所以，任重而道远。
完。
—————–EOF——————