云原生发展到这阶段，DevOps其实得开始认真想想这几个关键策略了

最近在网上看到一些技术圈里的资深人士在讨论,说云原生技术发展到今天这个地步，很多东西已经变得非常成熟和普及了，以前我们觉得很高大上的容器、微服务、Kubernetes，现在都快成了很多公司的标配了，问题也跟着来了，这就好比一家餐厅，以前用的是普通的灶台，现在一下子换成了全自动的智能厨房设备，设备是高级了，但如果你还用原来那套管理后厨的老办法，那不仅效率提不上去，可能还会搞得一团糟，甚至更容易出问题，有观点认为（来源：部分业界专家在技术社区中的讨论），现在这个节点，搞DevOps的同学们是时候停下来认真想想了，不能光埋头跟着工具和平台跑，得重新审视几个关键策略了。

第一个关键策略,得从“自动化一切”转向“智能化的可观测性”，以前DevOps老讲自动化，脚本写得飞起，CI/CD流水线建得老长，目标是让人尽可能少插手，这没错，在过去是巨大的进步，但现在系统太复杂了，微服务一堆，相互调用关系像蜘蛛网一样，光是自动化部署和发布已经不够了，很多时候出了问题，你都不知道是哪个环节先坏的，就像一栋大楼的电路短路了，你只知道跳闸了，但要从几十层楼里找出是哪根电线出的问题，太难了，现在更关键的是要让系统变得“可观测”，这不只是简单的监控，报个CPU高了、内存满了那种，而是要能像给系统做“全身CT扫描”一样，能追踪一个请求从最前端的用户点击开始，经过了哪些服务、每个服务花了多长时间、有没有报错，所有细节都能看得一清二楚。（来源：源于对可观测性理念倡导者如Cindy Sridharan等人观点的归纳）当问题发生时，你才能快速定位，甚至预测问题，DevOps要和SRE（站点可靠性工程）的思路更紧密地结合，不光是把服务跑起来，更要保证它跑得健康、跑得稳定。

第二个关键策略,是安全不能再是最后一道关卡，得彻底融进每一步里，这就是常说的“Shift Left”，就是安全左移，以前的做法往往是开发、测试都搞完了，在上线前让安全团队来做一次扫描和检查，那时候发现问题成本就非常高了，可能要返工重做，在云原生环境下，这种模式更行不通了，因为现在的应用是由很多个来自不同地方的开源组件、镜像拼装起来的，漏洞可能隐藏在任何一层，安全必须变成开发流程里每个角色都关心的事。（来源：这一理念广泛出现于DevSecOps的相关论述中）开发人员在写代码时用的IDE工具里，就应该集成基础的安全代码检查；镜像构建的时候，就要自动扫描基础镜像和依赖包里有没有已知的安全漏洞；在CI流水线里，安全测试要作为一个必过的关卡，不让有严重安全隐患的代码合并进去，这要求DevOps工程师不仅要懂开发和运维，还得具备基本的安全知识和意识，能够选择合适的工具把安全流程自动化地嵌进去。

第三个关键策略,是平台工程思维变得非常重要，随着云原生技术栈越来越复杂，让每个应用开发团队都去深入学习Kubernetes的各种复杂概念和配置，是不现实也是低效的，这会导致学习成本巨高，而且容易因为配置不当出各种奇怪的问题，现在一个很明显的趋势是，公司内部需要有一个专门的平台团队，这个团队由资深的DevOps工程师或基础设施专家组成。（来源：这一概念由业界领先的科技公司如Google等实践并推广开来）他们的任务不是直接开发业务应用，而是把底层的云原生基础设施（比如Kubernetes集群）、常用的中间件、CI/CD工具链等，打包成一个简单易用、自助服务的“内部开发者平台”，对应用开发者来说，他可能只需要关心自己的代码，然后通过这个平台提供的简单界面或标准模板，就能轻松地部署应用、扩容缩容、查看日志，而不需要去直接面对底层复杂的配置，平台工程的目标是提升整个研发团队的效率和体验，同时由专家团队来保证底层平台的稳定性和最佳实践，这对于规模化应用云原生技术至关重要。

第四个关键策略,要更加关注成本管控，也就是“FinOps”，用云的好处是弹性灵活，随用随付，但坏处是也容易造成浪费，可能一不小心某个测试环境忘记关了，或者某个服务配置的资源远远超过它实际需要的，钱就在不知不觉中流走了，在云原生环境下，因为微服务多、实例动态变化，成本管理变得更复杂，DevOps团队需要把成本也作为一个重要的运维指标来看待。（来源：FinOps基金会及其倡导的实践框架）要和财务部门、业务部门更紧密地合作，建立起成本可见性文化，给每个团队提供他们资源消耗和成本的清晰报表，让他们自己能看清钱花在哪了；设置预算预警，快超支了自动提醒；甚至可以把成本优化做成自动化策略，比如晚上自动降低非核心环境的资源配置，省钱也是生产力，而且省下来的就是利润。

云原生技术的成熟,其实是对DevOps提出了更高的要求，它不再是简单的开发部和运维部之间打通就行了，而是需要把安全、质量、成本、用户体验等方方面面都统筹考虑进来，并且通过平台化的方式把这些能力沉淀下来，赋能给所有的开发团队，如果还是抱着几年前DevOps刚兴起时的那种观念，可能就会发现自己虽然用着最时髦的技术，却陷入了新的混乱和困境，现在确实是时候认真想想这些更深入的策略了。