平台运维标准化难以同步，运维体系建设缓慢，RD运维室技术走不通...近年来，传统运维的发展困境越来越明显。随着云原生时代的到来，这些困境会让运维陷入危机还是迎来转机？
显然，这不是仅仅两句话就能得出的结论。我们首先需要认识到:最初的云时代，基础设施发生了哪些变化？可以解决哪些问题？运维人员应该重点关注什么？传统运维如何向云原生运维转型？如何选择和学习容器、DevOps、AIOps、微服务、混沌工程等新兴技术？
为此，dbaplus社区邀请了JD.COM科技数据库团队负责人高新刚、美图SRE负责人师鹏、腾讯游戏混沌项目负责人武照军，希望通过收集三位运维专家的研究成果和实践经验，为运维人员的转型发展和企业运维体系建设提供参考和启发。
三位嘉宾对云原生时代的运维转型有以下独到见解:
高新港
“传统运维要转向运营运维”
我的观点主要是关于传统运维的比较思维。
观点:从传统运维到云原生运维是一个不断迭代进化的过程。我们的运维已经从传统的手动运维，发展到脚本、DevOps，再到现在的数据、AIOps。
传统的运维是各个环节的作用，从专注于代码构建、应用测试、集成部署实施、在线性能故障排除，到后期的集群扩容收缩。在云原生时代，我们的运维流程更加规范高效，自动化和智能化程度高于传统运维。以RD微服务架构的形式开发应用功能，以敏捷的方式完成持续交付和集成。后期运维和RD可以通过DevOps实现一体化协同。最后，我们所有的应用程序都可以在容器上运行。
观点:从传统运维到云原生运维，整个运维技术栈发生了很多变化。我们过去运营和维护操作系统和多组件工具。现在需要转型，专注于统一的、云原生的、k8s-通用的云资源管控层面的自动化运维。
过去我们关注的是操作系统、存储、网络、数据库的技术栈，包括各种中间件。云原生运维基本是用dorckerun或者podman的命令一键部署和操作；然后K8s帮我们解决集装箱排列的问题；最后通过服务mesh，让云原生应用运行起来，这是这个云原生应用的载体。
观点:运维重心虽已转移，但核心能力仍是稳定、安全、容灾的保障和应急处理。
基于云的资源提供资源的容灾和扩展能力，运维的中心是以应用为中心，业务指标可视化和应用链接分析。服务网格可以帮助运维，实现服务注册、发现和负载均衡、分布式跟踪、认证和授权、加密通信和审计、多服务版本、分段服务等特性。
师鹏“拥抱新技术，关注核心技术能力的输出”
我的观点分为以下三点:
1.拥抱变化，追随潮流:
你没有办法拒绝或阻止已经成为大势所趋、风起云涌的云生浪潮。我们能做的就是尽可能地调整自己去适应它。
以美图为例。我们从19年开始做云项目，花了半年时间把所有业务从IDC搬到了云上。这带来了很多变化:以前很多基础设施和IDC硬件需要你的关注，现在可能不需要了；以前有很多基础服务需要你自己搭建，但是上了云之后，我们可能会优先使用云上的Pass甚至SasS来解决，这就意味着你维护的对象发生了变化。由此而来的是对你工作内容范畴的重新定义。
19年5月，Gartner指出，全球企业对基础设施的选择已经到了一个拐点。企业将更倾向于选择云，而不是构建自己的IDC。综上所述，云已成大势所趋，我们要调整心态去拥抱它。
2.思维转变和重新定位:
我们的思维需要改变，同时工作职责的边界也要重新定位。
今天的话题其实是:看SRE的稳定运行，而不是运维。和运维，但意义不一样。当你从运营的角度来看你的运维工作，你的边界其实是在扩大的。建议工作内容“左移”“上移”。
“左移”是指在一个业务的生命周期中，从设计、开发、测试，到交付、部署，以及后期对其稳定性的保障，这是一条从左到右的流水线。当我们把视角转为运营视角时，可能不仅需要关注服务上线后的稳定性保障，还需要提前介入，在服务设计阶段更早做一些工作。做一些服务稳定性的设计，比如保险丝和灵活的策略，在设计阶段，配合RD去做。
而“上移”是指我们上了云之后，基础设施发生了变化，你关注的可能不仅仅是底层基础设施，还有上层业务。这就是我说的“上移”。
关于这个我想再说一点。谷歌最近向外界分享了SRE如何与研发协作，随着你能力的边际扩张，你会发现你所做的不仅仅是服务稳定性的传统保障。换句话说，保证服务的稳定性，不仅仅是你一个运维团队就能做到的，还需要其他团队的支持。
如上所述，当你做一些高可用的解决方案，比如柔性设计，可能会在代码层面实现，需要研发的支持，现在工作变了，大家在理念上应该是一致的。
3.注重价值输出，提升核心技术能力:
早些时候，我们去了云，基础设施改变了，工作范围扩大了。现在各种云原生、微服务、服务治理、AIOps等新鲜名词。层出不穷，这也在一定程度上造成了大家的恐慌，或者说“滚入”。
你可能会想:这份工作不需要我，因为它已经在云上了？因为你的很多工作已经被云工厂覆盖了，这个时候我们要做什么？
我的观点是回归价值，我们邮政出口的核心价值。按照我的理解，稳定、效率、支持、成本，包括一些安全方面，只要能明确自己岗位的核心价值，持续、高效、高质量的产出价值，在一些必要的技术点上保持新鲜的能力，其他问题都可以忽略。因为只要能守住自己的价值，就能面对汹涌的浪潮，坦然处之。
武照军“在云诞生的时代，运维大有可为”
服务云端的大趋势不可逆转，不可阻挡。差不多从19年前我们就把服务从IDC转到腾讯云了。我们现在网络中的所有服务现在都运行在腾讯云上，微服务运行在腾讯云的TKE上，也就是腾讯云的K8S。
当初我们上云的时候，听到了一些声音:上云以后，运维就要淘汰了。上云后，服务可以灵活扩展，可以代替运维通过流水线在机器上做发布工作。运维没活干，可能面临下岗。
但是从19年到现在我们已经做了两年多了。从实际的角度来看，我们的运维其实大有可为，在云原生的浪潮下可以大有作为。包括一开始我们想说，有了K8S，能不能直接让开发给K8S部署服务？
答案是否定的，因为我们发现云原生使用是有一定门槛的，而要学习K8S的知识，他还得学习如何编写Dockerfile，如何整理YAML文件等等，这可能要花很多钱。所以我们在运维上主动出击，尽量降低门槛。我们做了一个云管道平台，在这个平台上开发，通过拖拽的方式做了一个发布管道，包括自动构建图片、生成Dockerfile、推送图片到腾讯云仓库、生成YAML文件、部署服务等。
这个过程很顺利，学习门槛很低，开发生上手很快。虽然云诞生了，但是我们的运维并没有被淘汰，而是通过平台的建设提高了开发运营效率。同时，我们的运维团队也享受到了上云的红利，现在的服务已经具备了灵活扩展的能力。如果有一天，机器挂了，或者机房挂了，整个可用区都挂了，我们的服务也可以实现自动漂移，获得故障自愈的能力。
这些是我们从云计算中获得的技术红利。所以主动拥抱这种变化，只会让运维获得更好的利润和更大的价值，而不是被淘汰。
同时我们也在做一些其他的工具建设。下面是我们现在正在做的几个平台:
可观测性平台。我们以前的日志、指标、跟踪、所有这些指标、日志等。散落在各处。通过可观测性平台的建设，所有业务指标、日志、跟踪数据等。串联在一个平台上。这样一旦服务出现问题，可以通过可观测性平台快速定位根本原因。
在运维没有做这个平台之前，现有网络遇到问题的时候，定位问题是非常困难的。但是有了这个可观测性平台，定位和查看的效率大大提高，这就是我们运维价值的体现。而这些点必须是运维主动想到的，因为开发主要负责业务逻辑的开发和版本的迭代，不可能有心思和精力去想这些问题。
混沌工程平台。混沌工程平台建设的出发点是提高业务的可用性。众所周知，上了云之后，服务管理会非常方便，用户一般会根据自己的模块需求拆分自己的服务。单个服务会被拆分成更多的微服务，一旦微服务多了，服务的拓扑链接就会变得非常复杂。
所以我们主动注入故障，通过混沌工程发现隐患，比如发现服务之间不合理的强弱依赖点，让这个非常复杂的服务变得更有弹性。
全链路电压测量。传统的压力测量工具只是用来发出请求，充当压力源。我们的全链路测压平台会在测压的同时描述链路拓扑，同时计算业务之间的放大倍数。比如门户服务是一万的QPS，到了DB就可能变成十万的QPS，也就是说放大10倍。全链路电压测量平台可以自动计算全链路微服务之间的放大系数，帮助我们更高效、更准确地评估容量。
通过这些平台的建设，我们运维的天地会越来越广阔，不仅不会被淘汰，我们能做的事情也会越来越多。
如何适应云原生时代？你一定看过三位老师的经历和观点，你也有自己的答案。也欢迎大家在评论区留下自己的看法。云原生时代被重塑的运营商需要哪些技能？答案明天同一时间揭晓！
关于我们
DBA社区是一个围绕数据库、大数据和AIOps的企业级专业社区。资深大咖，技术干货，每日原创文章推送，每周线上技术分享，每月线下技术沙龙，每季GdevopsDAMS行业会议。
关注微信官方账号【dbaplus社区】更多原创技术文章和精选工具下载。
