“管理理念”其实我也在学习，关于我们人才的梯队建设到底是T字型还是什么型？我觉得，在团队里面，怎么划分大家要钻研的方向？如何制定这方面的计划？这些问题可能会比较关键。要让大家有方向感，再去确定具体做的事情、要去钻研的东西。像高老师说的，在一个团队中，如果每个小伙伴都有一个精专的方向，最终大家组合起来，才能形成比较好的战斗力。这是关于整个团队对外交付能力的建设。

关于管理还有一个点比较重要：我们怎么去掌握整个团队的前进方向？我觉得比较好用的工具之一是OKR。我们要真正地把它用起来，因为现在可能有好多团队会把OKR用成KPI。但在我们内部的话，"O"是非常明确的，我们会把日常所有的工作都对应到"O"上，基本上你做的所有事情，像是监控、业务支撑等，最终它都会对应到我的稳定性的 "O"上，对应到我的支撑、效率"O"上。

这样会让大家有非常明确的目标感，并且如果你真的去用的话，不管你之前是什么样，你都会尽可能地把它做到可以量化，这样就容易在团队内部形成一种公开的、透明的文化：你的工作是什么样子，大家其实都可以看到。因为OKR是公开的，你的"O"是什么样？你达成得怎么样？

前面有讲到，我们现在在做一个jira看板，jira看板其实也秉承着同样的理念，每位同学当前手头有什么任务？他的任务队列里面是什么？在做哪些事情？这些其实都可以被大家看到。这样的话就能形成一个非常良性的循环，比如说在团队里，如果某位同学的任务排得比较紧，那其他同学是不是就可以cover一下？相互协作去共同完成一件事情，这样就会逐步建立起来。

我想站在一个员工的角度来试图回答这个问题。支撑能力在云原生场景下应该怎么去转换？我自己作为一个运维，在传统运维方式下主要工作是发布、扩容、缩容、处理故障这些工作。

在云原生的场景下，以我现在的工作为例，这种支撑的服务转变为建设云原生上云平台、可观测性平台、混沌工程平台、全链路压测平台等工具，使用这些平台提升研运效能。同时，日常的运维工作“左移”，比如交付能力，开始的交付是开发给了一个版本，然后我们去上线部署。但现在这是不够的，我们需要跟开发团队一起承担服务稳定性KPI。我们会一起去做架构上的评审，做服务可用性上的架构设计，我们运维对云IaaS、云PasS产品的特性非常熟悉，在架构设计、选型阶段我们可以提出非常好的方案，提前避坑。

在这一点上我也想跟大家分享一下我的体会，因为在今年年初的时候，京东内部进行了一次组织架构的调整，以前的京东数科和京东云进行了合并。我们以前是京东数科的，那么在合并后，就会面临从传统运维到云原生运维的转变。合并之后，有很多小伙伴因为不适应而离开，也有一些在短时间内比较迷茫。

在这个时候，作为管理者，我们经常会跟小伙伴进行一些思想上的传递。像刚才石老师在发表自己的三个观点时也说到：通过从思想和认识上，让大家意识到，云原生的相关技术在这个时代能给我们带来什么样的好处？它的变化对我们的未来有多么好的帮助。

还有一个点就是，要从整个公司的战略层面，传递给大家我们这么做的原因。我们要做的不仅仅是云原生，还有多云的管理，以及很多的服务，像“上移”“左移”这些具体的事情。通过这种观念或者说理念上的传递，让大家能够寻找到自己的方向，得到战略上的认同。

这样我们的小伙伴才能够从传统运维到云原生运维的转变过程中，寻找到自己的方向，在未来的工作中更好地去发力，去建设未来的云原生！

是的，我们从19年开始上云，上云之后就意味着一些传统的基础运维的人员，像是管服务器的、管网络的，这些同学可能就没有或者说少有应用场景。当时我们的团队里新进了几位之前做基础运维的同学，在这个过程中，我们结合其优势以及目前的兴趣点去做规划和建议：上云之后你应该去做什么？

在这个过程中，我觉得比较好的一点是：上云之后，我们团队没有任何一位小伙伴是因为上云后工作和基础运维有差异、不适应而流失的（当然我们团队本身也不大），而且现在我们运行得还不错。当然，这里面有这些同学自身的原因，因为有些小伙伴可能本身就会有一定的危机感，会提前做一些储备。

比如我们有一位做网络的同学，他是资深的网络工程师，做了很多年网络，以前是在运营商那边工作，后来加入了我们团队。他自己就有主动提前去学习K8s的知识。还有另外一位是应届毕业加入我们团队的同学，一开始做的也是网络，但他自己也在学习运维开发的事情，在学编程语言，这样一来，上云之后的转型就会顺畅很多。

在这个过程中，结合他们以前的兴趣、已经在做的能力提升去进行规划，可能会比较好，所以我觉得理念真的是很重要的。

在管理方式方面我可能没有什么话语权，但也有一些感悟。上云之前，业务运维要做的事情是非常多的，要同时负责IaaS层和应用层工作。到了云原生时代， IaaS、PaaS托管给云厂商了，产品开箱即用，少了很多部署、管理工作，效率提高了。

运维职能也发生了变化，往往会朝两个走向去走，一个是做上云平台的规划和落地，让开发同学能平滑的将服务上云，负责平台易用性和可用性。另外一批同学还是负责业务运维，但业务服务是往微服务的方向去发展的，每个微服务的开发他只负责它开发的那一块服务的可用性。但一个服务要真正上线需要把各种各样的微服务串联起来，这个串联的工作，就是转给业务运维同学来负责的，也需要建设工具来提升效能，比如快速梳理清楚服务间的拓扑结构，确认服务间的调用关系是否合理，检验服务的容错能力等。

我再补充一个点，其实从管理上来说，学习也是非常重要的。对于我们团队来说，从传统运维到云原生运维，有些同学在刚来到这个部门的时候，他对云原生的很多技术栈其实都不是很了解。有时候会找不到自己的方向，目标不明确。

那这个时候就需要管理者组织大家有针对性地去学习，这是一个非常重要的点。

在知识体系建设上，我们团队的氛围很好，大家都很乐意去分享。在我们团队内部是这么运作的：每周一次微分享，大概30分钟左右。这个微分享选题是自由的，每次的微分享，一般来说是同学先准备，学习了一段时间之后，再把这个知识点分享给大家，分享的同学是先把知识内化吸收了，再讲给大家听，印象会非常深刻，很多年前我分享的内容，到现在记忆还很清晰，这对个人的总结、表达能力来说都是非常好的提升。

具体的内容上，从我的经验来看，我先会把云原生的知识图谱打开，因为云原生其实有一个很大的版图，像K8S，服务网格、可观测性、混沌工程等。根据版图，从我们的业务实际需要出发来钻研技术。判断这项技术有没有可能在我们实际的业务落地中产生一些收益。

比如，我发现服务故障率很高。于是想：能不能通过提前注入故障，将问题提前发现解决，所以我就去研究混沌工程的一些技术，包括Chaos Mesh等。在实践过程中，我们发现了它确实能产生一定的效果和收益，这样一来，我们知识体系建立起来了，人才团队也有了，业务也获得了收益。

基本上我看到的所有公司都非常重视技术的分享和人才的培养，通过分享，分享者能够有一定的提高，对整个知识体系的认识会更加全面、系统；而受众可能会觉得这些知识对他来说非常新鲜，也会有学习的动力。最主要的是，你可以随时随地地在公司的内网里学习，这样就营造了一个很好的学习气氛。

我们公司其实除了这些技术分享之外，我们整个大部门，尤其是数据库的研发部门，可能更多地会去关注文档的建设。比如说，每一个人所做的事情，都要去整理出这一部分的文档，把整个实施过程中遇到的困难、经验，包括测试数据都写在文档里。这样一来，部门里的其他的同事可以不定期地去查看这些文档。这些文档可能就是一些琐碎的日常工作，但拿出来分享给大家之后，大家的经验会不断得到提升，这也是整个知识体系的一部分。

智能和效率其实是相辅相成的，我们做云原生上云后，服务获得了弹性伸缩等能力，提升了运营效率，这点无需赘述。

但具体到协同这块，我有些感触。通过云原生上云之后，我们去落地DevOps这个理念，让开发同学参与软件全生命周期的管理，这个理念最开始去推广落地时，我们的开发同学是非常不认可的。

之前在传统运维时代，开发同学把代码开发好之后交给运维，他的工作就结束了，但现在在云原生时代，他要负责去配置发布流水线等工作，这样一来他的工作量其实增加了很多，所以最开始我们DevOps的落地阻力很大。

我们持续不断降低平台使用门槛，开发和运维通过平台实现了标准化对接，减少了非常多的沟通成本，大幅提升了效率。开发同学获得收益之后，DevOps这种方式才慢慢得到认可。所以在协同过程中，我们这边确实花了很多时间和精力，但最后还是取得了想要看到的收益。

那我来说一下我们这边，首先智能化，刚刚其实有聊到 AIOps，目前我们这边也有这样的一个中长期的规划。按照目前的情况，你要想做智能化，前面还有很多路要走。像腾讯、京东这样的大厂可能做的比较前沿，但广大的一些中小企业，像美图这种公司，虽然他们也都有意识在尝试做一些探索。但在目前，以美图为例，我们需要先把前面自动化、标准化这些东西做好，先做好该有的流程体系，再逐步去做智能化，所以要有一个大的规划。

至于现在，当然我们也有一些点有待探索，包括刚才提到的弹性伸缩。我们现在在做的一个成本优化的点是自动调优。你的资源分配到底合理不合理？然后自动去进行调优。这也是用算法，根据历史的资源利用率和申请情况自动调优。

首先做这件事情可以回归到价值，另外，这个点你既可以说它是自动化也可以说它是智能，因为它比一般的自动化多带了一些决策的东西，这也是带着智能的。目前我们整体是要先回归到具体的业务场景，解决比较突出的问题，然后以点及面，先把各个痛点解决掉。

因为现在AIOps也在发展，而且发展得很快，后面我们也在持续关注，等有好的这种应用的这种东西了我们也可以再切进来。

我非常认同石老师的观点，刚才石老师有说到一个词：以点及面。其实我们内部在做智能化运维的时候，是有一个理念的演变的，就是从精细化运维到智能运维。

就是说，不管是传统运维或者云原生运维，都要做到精细化。当你精细化到一定程度的时候，你就知道，你的运维的逻辑能不能被替代、被模仿，能不能被整个智能化的体系替代。通过这种精细化的梳理，再到智能化的替代，这个过程其实是一点点逐个场景去替换的，而不是说一下子能把所有的运维场景覆盖掉。

再一个就是协同方面，其实大家也公认：智能化并不能完全解决所有运维场景的问题。那么，在有了智能化之后，我们运维的协同要如何去展开？这也是一个非常好的点。目前我们是通过一些自动化和智能化相结合的方式，去保证我们现在的运维体系，后面可能会逐渐替换。而在整个替换的过程中，包括运维人员角色、职能的转变，可能都会发生新的一轮的变化。

从我的理解来讲，运营和运维其实就是你能力边界的扩充。或者你可以理解为：用传统的方式去做传统的事情，可能并不能再持续地优化我的工作。

比如说，我只关注服务的告警和解决这个问题，这可能并不能从根本上提升服务的质量。你可能需要在更早的时候就要去做自动化测试；再往前，你在代码设计、架构评审的时候可能就需要去介入，在更早的阶段去考虑这些点，这也是我们目前在做的事情，这就是刚才讲的“左移”。

再就是“上移”，你要看到你的业务价值，然后去思考，要怎么做才能更好地去支撑这个价值输出。用这样的思路去思考问题时，其实你的角色已经由运维转向了运营，这是我的理解。

我的看法是，传统运维是被动的，运营应该是主动的。传统运维收到开发的一个版本，然后要去部署、线上发布、处理故障、监控告警等，整个过程是被动的，是别人安排的任务。而运营是主动出击，可能在一个版本还没有开发、还在讨论阶段的时候就去输出他关于选型的一些建议。

选型阶段运维去介入，在架构评审阶段就能够发现里面的风险点。传统运维方式下，在架构设计阶段一般都是由开发团队自己内部来完成。但是在云原生这种主动运营的场景下，我们的运维同学是要参与到这个过程当中的，我们团队跟开发团队协同非常紧密，迭代会一起开，架构一起评审，最后，线上出了问题也一起来扛，这个过程是一种非常主动的转变。

我也有相同的认可。云基础资源提供了资源的容灾能力和扩展能力，运维重心偏向以应用为中心，注重业务运营，业务指标可视化和应用链路分析成为关键。服务网格可以帮助运维，实现服务注册、发现和负载均衡，分布式追踪，认证授权，加密通信和审计，以及多服务版本，分段服务等特性。

我认为，其实从运维到运营，更多的是从用户的需求出发去做运维，从用户的需求中寻找最佳的运维方式。只有这种方式，才能达到运营的这种效果。