云原生不是一个产品，而是一套技术体系和方法论
云原生的概念在最早由 Pivotal 的 Matt Stine 于2013年首次提出，尽管他提到的不太明确，但内容含义很丰富，也全新定义了计算机技术发展至今的一种新形式。
笔者认可云原生技术层分为：容器化，微服务，DevOps，持续交付。细分为微服务框架，API框架，Service Mesh，Serveless on Kubernetes、Kubernetes软件包管理等。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。但云原生更像是一种技术体系下的方法论，它的表现形式是摈弃之前的传统的运维开发框架，通过容器化和 DevOps，微服务架构实现应用弹性伸缩和自动化部署，充分利用云计算资源实现最少投入做最大的事情。
云原生架构体系自研成本很高，因此购买成型的云原生架构并投入使用是很多非技术型企业的首选。在成型的云原生下，应用运维更多的应该是贴近业务，为业务系统的架构实现优化做出成绩，更聚焦需要解决的问题是传统单体应用如何转成云上的服务。
精益思想理论与云原生的方法论关系
精益思想的关键出发点是价值，而价值只能由最终客户来确定。重要的三个过程需充分思考：
① 从概念到投产的设计过程;
② 从最初提出要求到产品送货的信息流动的订货过程;
③ 从原材料到客户手上的物质产品的整个生产过程?
每一步的参与运维都在做什么?运维在云原生后要做的事情是更少了还是更多了?IT服务产品-从IT需求、研发、测试、应用运维、数据库运维、基础运维最后到上架产品的全套服务，这整个过程中需要摈弃的环节太多了，每个环节都会存在一定形式的浪费。若加了部门墙，那更大的人力和物力浪费就是可见的，对最终的用户来说，他们并不愿意为 IT 的细化分工买单，他们要的只是产品能快速稳定的被购买到。IT部门的细化是否代表着专业度的细分，从精益思想的价值体系分析，并从实际业务的技术支持角度来看，尤其庞大的金融机构，此类的细化反而影响了效率，一定程度上阻碍了云原生下的运维变革之路。
在外购项目逐渐增加而自制项目逐渐减少的年代里，真正需要的是有共同利益的各方自愿组成的联合，一起查看被割裂开来的价值流才能做好IT的全局服务。因此一切不合理的存在诸如最大的障碍：组织架构的不合理，是首当其冲应该改革和调整去适应市场的变化，才能发挥运维的价值，“知道什么是真正需要做的事则是必要的，否则价值的定义肯定会被曲解。”
运维管理变革开始
ITIL 运维体系仍是运维管理的经典最佳实践。恰恰因为专业，所以必须联合发挥作用。购买来的云原生(已经打包了基础设施的一切)能否顺利在公司现有的平台环境上做好业务的支撑，取决于运维的专业度，运维的专业度更多的是需要平台化的运维支持能力，平台化的运维能力建设需要创建运维专家团队，必须是懂业务、熟悉中间件、且对数据库精通的运维且熟悉声明式 API 的联合运维体才能更好的在云平台上发挥最大效能。
因此运维管理的原则应从帮助业务模块实现基于服务流量(而非网络流量)的策略去提供服务，而无须关注这些服务是基于何种编程语言开发的。业务上线之后，在运行期的大部分时间里，可能还会遇到各种应用的不确定性和不稳定的情况。当这些非正常场景出现时，业务需要尽可能地保证服务质量，而运维管理为该目标所提供IT技术支持。这样的团队能快速全方面的诊断系统并做出判断，为业务提供最佳解决方案。
总之，适合企业发展的技术才是最好的，标准化是必不可少，但个性化也必须强调，就像业务系统的分核心和非核心系统一样，服务从来都是多样化的。所谓的标准化一定是规划化相对容易实现的部分且能产生价值的部分，比如依赖工具形成固有的流程等，其余个性化运维部分就是价值最大的亮点，一定是最难实现的那部分。