软件开发生产线 CODEARTS-交付在云端-全云DevOps实践:观察：研发全云，境清奇？
下载软件开发生产线 CODEARTS用户手册完整版
观察：研发全云，境清奇？
进行企业DevOps能力自检之后，可能发现很多问题。
决定上云本身就是一个创新性的决定，很多企业对上云都是顾虑重重，为什么？首先，它是一个打破思想枷锁的过程，因为云上一切意味着不确定性、不安全性、不可知、风险，同时意味着大量的机会。在这个过程之中，我们首先要知道用全云端的工具意味着什么。
上图中左边有全云端的沙盘，从需求管理开始，紧接着要做实施和交付，开发、测试服务、构建、发布、部署、监控。后续还有一些基础服务，这些基础服务的实现实际上是为了衬托上层服务，如果没有代码托管、资源自动化、仓库服务，实施DevOps也只能是无水之田。右边是云化或者服务化的能力模型，下面三行是重中之重。大多数人做云化软件交付的时候可能不是云化，而是服务化。第一是自动化管理，管理流程不再有那么多人工过程了。第二是弹性扩展，不管是交付的软件也好，或者使用的工具也好，要有一个自动适应弹性扩展的能力，很方便的依托于现在公有云提供的能力，这种弹性扩展的能力并不难实现。第三要有一个足够的资源池，一般来说，公有云的服务商已经为大家打造了这样的平台，金字塔里面都满足了，可以说是云化服务，已经从服务化上升到云化的交付能力了。
然而实际做云化转型的时候是困难重重的。
从资源的角度来说，一般软件云化有三步：
- 第一是虚拟化，从实体服务器逐步转化成虚拟机。
- 第二是资源池化，有一个大的资源池可以实现动态的分配
- 第三步是自助服务，云端自助服务是能够实现快速运转的条件。
此外还有流程。如果线上发布过程和生产环境之间网络不通，应该怎么做呢？答案是工具并不能解决这个问题，因为这是流程问题。众所周知，华为公司有各种各样的安全红线，在做内部的云化服务化工具链落地实施的时候，最大的工作量集中在如何打破枷锁上，怎么把内网的一段代码或者一段测试用例或者二进制的安全文件快速传递到外网仓库，这一问题花了很长时间。举一个简单的例子，有一个流水线，其他步骤执行只需10分钟，最后会在发布审核的环节整整卡七个小时或者一周。我们做到提前审批到事后追查的能力，是做了最大的公关，等于说这是一个关键阻塞点的破除。一定要注意，当你准备做一个流程或者工具实施的时候，阻塞点不一定来自于技术和工具，很有可能是来自于流程。
部署方面，是否具备独立部署的能力，是否能够合理的使用资源组、容器镜像，类似于这种资源池进行管理的能力，都是限制我们服务的能力。经过很长时间的实践，我们发现很多产品线声称他们已经实现微服务架构，已经实现解耦，但是最后的结果是众多的微服务打包部署上线。这实际上还是要回到源头上去看一下整个服务架构是否做到了解耦，是否做到了微服务所要求的九大特征。
后面是编码问题，现在编码工具非常多，但是实现全云化的时候，实际上是要求我们把一种编码的能力移到云端去做。这件事情想起来很简单，做起来很困难。包括要实现后台运行、运维、测试、调试能力的支持，同时还希望和DevOps工具链打通。
再者是安全性，上云本身是一种思想的变革，没有绝对的安全，只要暴露在公众的眼光下，就有泄露的一天，就有被攻击的可能性。很多用户在使用我们的软件服务的时候，最大的问题是：“我们很关注安全性，请问你们有特别好的解决方案吗？”两条路，第一通过特殊化的定制、阉割、裁减一些本来应该很开放的能力来适应安全性，但是后果也显而易见，关在笼子里面的狮子怎么可能是强壮健康的呢？第二是说服用户，看他是否我的菜。举个典型的例子，我们从来没办法说服华为的海思来使用我们的服务，因为海思在华为内部是绝密。
