行业动态

一、写在上面

最近被多次问到：“随着云原生的逐步建立和深入应用，NoOps（零运维）时代真的要来了吗？作为运维人员，我们应该如何应对这些趋势？ ？”。云原生架构不断融入数字化转型应用后，IT运维真的没了吗？仁者见仁，智者见智。但我个人认为，如果我们能先充分理解“云原生”，再思考“在云原生下，是不是真的不需要运维”，会更准确一些。

二、什么是云原生？

Cloud () 是一个复合词，Cloud+。云意味着应用程序位于云端，而不是传统的数据中心；这意味着应用程序的设计从一开始就考虑到了云环境。弹性+分布式优势。

三、云原生的主要特点？

该公司的 Matt Stine 在 2013 年首次提出云原生，他定义了云原生的四个关键点：微服务 + 容器 + 持续交付 +。

微服务：几乎所有云原生的定义都包含微服务。与微服务相比，它是一个单体应用程序。微服务有一个理论基础，即康威定理，它指导如何分割服务。决定产品形态的是组织结构。微服务架构的用处是切割后服务是前馈的，内聚力更强，变更更容易；另一种定义服务的方法似乎是基于 DDD。

容器化：是应用最广泛的容器引擎。容器化为微服务提供实现保障，起到应用隔离的作用。K8S 是一个容器编排系统，用于容器管理、容器之间的负载均衡，K8S 是用 Go 编写的。

：这是一个组合词，Dev+Ops，就是开发和运维的组合。与开发和产品不同的是，它们经常相遇。事实上，它还应该包括测试。它是一种敏捷思维、一种沟通文化和一种组织方法。为云原生提供持续交付能力。

持续交付：持续交付是开发不延迟，更新不停机，小步逃走，是一种反传统的瀑布式开发模式，需要开发版本和稳定版本并存，虽然需要很多流程和工具的支持。

在实际实现中，符合云原生架构的应用特点是：使用开源栈（K8S+）进行容器化，基于微服务架构提高灵活性和可维护性，采用敏捷方法，支持持续迭代和人工运维，借助云平台设施，可以实现弹性伸缩，动态调度，优化资源利用率。

四、为什么会出现云原生，解决了哪些痛点？

让我们从云估计开始。在云计算普及之前，如果一个应用要发布，企业需要购买几台服务器，安装在IDC机房。连接是安装Linux系统和部署应用程序。我们假设我们已经用 Java 编写了一个 Web 应用程序，如何部署它？先配置服务器，将编译好的war包上传到服务器，使用FTP，对安全意识稍有了解的选择SCP，然后配置Nginx和MySQL等服务，然后调试最后一关运行应用，甚至如果它还活着。这些化工机器有很多缺点，但主要痛点如下：

扩展和维护困难。由于是化工机，所以需要先购买，再安装到机房。当业务量激增时，再扩容已经来不及了。就术语而言，这意味着估计的资源是不灵活的；治安太差了。熟悉Linux的运维工程师很少服务器运维，精通的也很少。但系统安全只是一方面，应用部署的权限和流程会导致更大的安全漏洞；需求无法快速响应。开发、测试和运维是矛盾的，缺乏手动测试和部署。应用系统的上线部署是一个重大的变化，涉及大量的规划和多轮测试，

解决方案是上云。上云并不能解决所有痛点，而是部分解决了前两个痛点：

与化工机相比，虚拟机的创建、维护和销毁都比化工机简单得多，并且可以随时扩展容量，很大程度上解决了“弹性估计”的问题。至于弹性程度，取决于应用。建筑和设计水平；与绝大多数中小企业相比，云服务商在网络和服务器安全方面要强几个数量级。只要选择合适的官方镜像，并配合使用防火墙规则，系统层面的安全问题就大大减少，重点可以放在应用本身的安全上。

所以第三个痛点“无法快速响应业务需求”云测算不能很好的解决。要实现持续交付和快速迭代，需要改变应用架构和软件开发方式。这时候，云原生“微服务、容器”等特点的优势就凸显出来了。

五、使用云原生后会给应用系统开发带来哪些变化？

1.本地部署的传统应用往往是用c/c++和企业级java编写的，而云原生应用则需要用以网络为中心的go、node.js等新兴语言编写，而不是Java不能用，只说GO语言更适合云原生适配。2.本地部署的传统应用程序可能需要停机更新服务器运维，而云原生应用程序应该仍然是最新的，需要支持频繁的更改、持续交付和蓝绿部署。3.传统部署在本地的应用无法动态扩展，往往需要冗余资源来抵御流量高峰，而云原生应用则利用云的弹性来手动扩展和共享，降低成本，提高效率。4. 部署在本地的传统应用对网络资源有依赖，比如ip、端口等，甚至是硬编码，而云原生应用对网络和存储则没有这些限制。5.传统的本地部署的应用一般都是手动运维的，而云原生的应用都是手动操作的。6.本地部署的传统应用一般依赖系统环境，而云原生应用不硬连接任何系统环境，而是依赖具体的基础设施，从而实现了良好的可移植性。7.本地部署的一些传统应用是单体（）应用或者是强依赖，

那么，在云原生应用之后，似乎今天面临的所有运维的棘手问题都消失了？

六、云原生使用现状如何？

之前看过国外大中型企业的调查报告，显示“60%以上的用户在生产环境中应用了容器技术，1000节点规模的容器集群可以满足生产需求近 80% 的用户。” 作为容器的主要应用场景，80% 的用户已经使用或计划使用微服务。与此同时，该技术明显升温，近 30% 的用户已经将其应用到生产环境中，但用户在部署过程中仍面临诸多挑战。甚至预测“到2025年，95%的数字化运维将得到云原生平台的支持”。这个数据和我目前接触过的客户的申请情况差不多，无论是ToB还是ToC，无论是标准化产品还是多元化。产品在云原生改进方面取得了长足的进步，最重要的原因是：“快速迭代和持续交付”。

七、使用云原生后会给IT运维带来哪些变化？

云原生运维需要解决几个关键问题： 1.标准化：标准化可以促进开发团队和运维团队的沟通协作。标准化也有助于生态分工，促进更多手工工具的出现。2.手动：只有手动运维才能支撑互联网规模的挑战，才能持续支撑业务的快速迭代和稳定性。3.数字化智能：人工运维，数据提升，人工智能化已成为未来发展的必然趋势

上述问题对运维人员的变化是：

原本标准化的工作流程是用来协调人高效完成工作的，通过标准化流程转化为人工化；

传统上，通过开发人工处理模型来训练AI，将知识积累以提高团队能力转化为运维能力的提升；

在微服务、多云环境和 IaaS 下，应用系统和基础设施都被划分为足够小的业务服务，以实现持续交付和迭代。这种传统的人工运维方式，早已难以管理这么多的对象。运维工程师无论是软件运维、服务器运维、操作系统运维还是网络运维，都必须能够在原维护对象专有技能的基础上进行人工运维。也未能推动运维工具的标准化。为此，运维工程师必须具备一定的开发能力。至于过程，传统业务由人工协同完成，而在云源旗下，每只蓝筹股的工作都由相应的人工工具完成。这样，在原有流程能力的基础上，运维流程主管必须具备安排不同自动化组件的能力，以实现从资源规划、软件部署、自动化业务验证（测试）等一系列工作。事实上，运维的工作不会消失，只是运维工程师在云原生环境下没有编程和开发能力是很难做到的。在原有流程能力的基础上，运维流程总监必须具备安排不同自动化组件的能力，以实现从资源规划、软件部署、自动化业务验证（测试）等一系列工作。事实上，运维的工作不会消失，只是运维工程师在云原生环境下没有编程和开发能力是很难做到的。在原有流程能力的基础上，运维流程总监必须具备安排不同自动化组件的能力，以实现从资源规划、软件部署、自动化业务验证（测试）等一系列工作。事实上，运维的工作不会消失，只是运维工程师在云原生环境下没有编程和开发能力是很难做到的。

传统的运维工具，无论是监控还是运维流程，都以保证业务稳定性和保证快速响应为核心的标准化产品。差异也使得自愈处理的流程不统一，必须通过二次开发完成。这样，运维工具的二次开发能力将决定该工具能否落地。

八、写在最后

数字化转型时代已经临近，扫码加入我们，以全新的思维方式学习ITIL4，数字化转型时代必须掌握的新技能。

更多课程和服务

我们首次提出“咨询式培训”的培训理念，指出“在培训学校学习方法，在专题研讨中解决问题，在研讨课和辅导课中答疑解惑”。

如果您想使用ITIL4的理论来设计和优化IT部门的业务流程，建议您点击以下链接：

如果您想利用外部专家的经验和实力对IT部门的业务进行重组和重新设计，我们建议您点击以下链接：