开发者学堂课程【云原生架构实践：云原生场景的智能化运维演进和实践】学习笔记（二），与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1054/detail/15303
云原生场景的智能化运维演进和实践
内容分析：
一、云原生技术和架构
二、云原生基础设施演进
三、云原生“操作系统”涌现
四、云原生运维的痛点和挑战
五、云原生运维体系的演进
五、云原生运维体系的演进
⑥运行时安全-沙箱容器&机密计算
那除了内外防护之外，针对容器场景，还需要额外做什么？那这里来介绍两个场景，会发现在原来我们一台主机上可能就跑一个应用是特定的业务，但是在引入整个原生技术和容器之后，会发现有了另外一个挑战，就是可能在同一台机器上部署不同的这种企业或者是不同组织的这种应用。那两个业务之间它可能是非授信的。对于非授信的应用，那可能是说 A 应用被讨论，同台手机上 B 禁止。那这样会导致两个互相影响的，这样其实是不可接受的，那同时包括运营一些开源组件，那可能也会有一些潜在的问题，所以如果去保证。这种非授信的这种应用的一些保护这是一个场景。那另外一个场景是这个应用本身是授信的岗位，也是自己写的代码，它是有相对好的一个保证安全性。但存在问题就说如果部署在一个机器，有可能别的应用是非授信的或者说担心这个代码中的一些内存被一些三方或者是一些黑客所攻击，所以是不是能够把整个代码在一个可信的一个环境中去做运行。通过这样的方式能够防止整个授信应用的非法入侵。因为这两个场景的话，提供了不同的一些能力，然后通过这样一些实践提供更好的一个运营的安全保障。那首先来看就是针对这种非授信性的应用，如何来保证它。
首先来看就是提供了 ACK -安全沙箱能力，那安全沙箱其实相对于传统的这种，它是一个共享客户的一个架构。那对于安全沙箱来讲，它是以共享，它是可以做一个独享的一个内核。所以它天然是有更好的一个资源隔离性，但是其实有一个缺点，是因为有个独享内核，所以相对来讲它的资源开销会比 run c 会大很多。那针对这样的一个痛点的，其实在内部也作了一些处理。那它能够很好的去针对这些问题做一些优化。那目前来讲就是经过一些优化，可以做到就是说安全容器，它的这个性能做到 run c容器的90%~95。那此外也在一些技术提供的相应做一些大量的优化，可以在使用安全容器的时候，也能够更加友好的一个性能和弹性的这种体验。第二点就前面说，如果想让这种授信的用户为非法的这种访问。该怎么做呢？提供了一个叫做 ACKT 的一个能力,能使上我们整个这个应用在程序可以保证一个基于CPU的一个可信执行战略环境中，叫做一个 g 的一个环境。那针对这样的场景是可以无缝 sgx 进行的一个。能力，并且也是在开发社区中。提供 sgx 的一个方式。并且可以是说很方便一键不属于一个家庭计算节点时，这样的方式能够更加方便地去使用这个可信执行环境。那通过这样一个方式可以解决如何去面对一些非授信的或者通过比如说一些sv写一些代码，能够让它更好地在运营环境中运行。此外也是保证一些应用如何不被一些外部的入侵。
⑦打造全方位云原生安全
通过这样的方式来简单说一下，希望通过一个纵深防御能够构建从供应链到运营时一体化的安全流程。不管是在构建部署还是运行，都能通过一些自动化、配置化、声明式的方式能够做到一个最终的全面的一个保障。那除了这里以外，可以从应用安全和供应链角度解决一些风险，但实际上在整个底座，其实还有丰富的，比如像云平台本身的安全、还有容器基础设施的安全，这一块不是不是今天重点要介绍的地方。通过这样的一个立体的防御体系，能够打造一个全方位的云生安全的一个能力。也是希望通过这样的一个架构，去提供一个更好的一个功能。
⑧云原生安全成熟度和功防矩阵
其实原生安全就是非常复杂，那到底怎么样去在内部落地，有没有更好的一个竞争的方式，但实际上也有两种方式，那第一个是。其实最近信通院也是刚刚颁发的那个云原生安全成熟度 CNMM-TAS云原生安全成熟度模型。那它也是从5个领域很好地定义了如何去做这种云原生的模型。那最近的阿里云也是作为首个完成评估。那除此之外，就是说如果在内部想去真正地去验证模拟，如何去防范这一安全攻击，并且这些效果到底有没有生效。阿里云也在2020年的首次推出了一个攻防安全矩阵。那它也是可以从9个层面去来帮助更好地去验证整个的这种从构建到运营时到配制到全新的一个全方位的一个辩证。所以希望这里的一些方案能给大家一些建议。
除此之外，其实也可以关注一下，就是在最近也推出了一个叫 cn app 的一个云原生安全平台的一个定义。它也是从不同的角度去来建议整个云原生安全。可以说云原生安全是接下来落地云原生安全更好的运维其实是一个关键。
3、云原生成本
FinOps (云成本优化)是 Finance 和 DevOps 的协同，将财务问责制引入 IT 成本治理与优化的机制，通过多维度的成本洞察能力，实现数据驱动的 IT 成本优化与治理。
那讲完安全这一块，会发现除了安全之外，第二个痛点是如何去更好地管理这种原生的这种成本还有弹性能力。前面也提到，就是 FinOps 。那其实 FinOps 和前面的 DevSecOps 还不一样，它是其实最近两年刚刚提出来一个新的概念。但本质上它解决问题是什么呢？是如何去拥抱在云上去大规模去应用这些应用部署和运维时的一些挑战。那这里的一个重点是什么？就是说发现。当在云上使用资源，它其实带来好处也带来一些挑战，在云上其实可以更动态地申请资源。那这个在云上不管申请计算资源还是传统资源，其实很容易就申请到。那个成本其实也会逐渐的去增加，在刚上云的过程中会发现因为对于云的能力其实并不是特别了解。那可能在刚开始的时候有些错误的配置或者是说应用可能做了一些浪费，但在初期的时候会有很多的这种资源浪费。在随着这个运用云逐渐稳定，才知道如何去针对性的去换这个资源成本，再通过一个不断的一个运营手段才能持续的让这个用云成本不断增加。
⑴云原生成本优化的挑战
是否通过一些弹性等的一些调费已经解决成本问题了，实际上是可能并没有想象的那么简单，这是2021年做的一个报告。显示差不多有百分之六十几的客户，其实当他刚开始使用这种技术时，它的成本其实反而是增加的。那可能百分之二十几到30几，他成本增了20%。这样的一个结果，可能会觉得。跟自己预期完全不一样。但道理背后原因是什么？会发现，其实这个新技术的引用其实在早期确实会带来一些额外的学习成本，但需要通过逐渐的实践去把这个副作用再降下来。到底在使用原生技术时候遇到哪些难题。那这里提到有5个方面，第一个是说比如说在云上可能申请了一些都是以机器视角来去做一个资源的预算，但实际上，在云原生这个时代，可能一台机器好多应用多个容器，但如何做容器级别的拆分，其实这是一个难点，其次，就是说如果有一些账单，比如可能是按月或者按天做一些结算，但实际上这个资源是可能作分钟或者秒级的这种弹性，那这样来讲，整个最后的账单，其实不一定是完全能够及时响应。那除此之外的话会发现整个把企业的业务复杂度最终怎么和原生的这些概念模型的匹配起来。但这也是一些难点，包括如何去针对比如说云上和云下能够有一套统一的一个材质管理的一个平台，这也是一个挑战。
⑵云原生企业 IT 成本治理方案-加速企业 FinOps 进程
那接下来的话就是。在云上的一些实践，包括是说其实在内部也是通过这样的一套思想和一些能力来帮助自身的云应用平台的一些成本，做一些更好的治理。那也会从多个方面来做一些优化，也是希望能够加速企业在 FinOps 领域的一些进展，包括是说去怎么更好地去结合这种细粒度的时候，材质分摊模型包括时候更好的内置的应用方向的一些能力，包括是如何更好地提供一些常见的一个成本优化，像这种多云多积分的一个统一的材质处理能力。
那接下来会从几个方面来重新来做一些介绍：
①多维度的成本洞察和趋势预测
那首先来看，针对这种原生或者在应用是怎么样去解决这个问题，那首先的话就是说，要去把整个这种组织的视角和底层的这种物理视角作为一个映射，比如从这种运维视角去怎么解决这种集群，然后通过集群和节点池的一些能力去定义。包括比如说从部门视角，从业务部门视角来讲，就是说光从有集群的拆分其实并不够，因为并不知道到底哪个业务部门绩效比较多。那么如何去从资源组和 k 8 s 空间的视角去更好的去做一个映射。对于更新应用，是可以基于一些 labour ，包括是说针对云上的一些资源组，做到一个应用视图的一个能力。
然后在一些除了刚才学习的怎么通过不同的视角去看这些成本的一些聚合，有更好的一个能力的一个体现，那在最终的一个成本的一个模型分担上，其实也是做了一些实践，包括是说会结合整个这种原生的这个集群，除了比如说对于节点之外，还有很多比如说负载均衡设备，然后存储的设备还有一些日志，那会基于标签来做一个统一的一个治理。那对于更细度的这种容器层面，也是可以做到一个好的资源分摊。比如一台机器上有10个不同的 POD ，可以根据 POD 的这种请求Request的一些流量，来做到一个整体的累加，然后再算出单个 POD 在其中占多少比例，通过这样的一个请求分摊的方式来做一个借助人力资源的一个结合。
所以就是，遇到一个挑战，就是在整个可能在云上的一些订单，它是一些相对理性的一个情况，可能有些包月的一种场景，那可能是按月做一个结算，那对于这种场景其实很难去做到一个更加准实施的一个成本的一个结算。那针对这种场景的话也是打通了云资源的这种计量和它的这个资源消耗的一个能力，通过用实实在在的模拟，能够帮助企业能够准时的去拿到这样的一个成本的能力，能够更好地提前做一些比如今天和昨天、这个月和上个月的对比，能够帮助做一些成本上的一个规划和一些优化。
②资源画像推荐
当有这样的一个多维度的成本动态和成本的一个趋势预测之后，就可以做到一些进一步的一个资源画像推荐，可以通过不同的方式能够提供这些应用的优化建议，比如可以根据资源成本的这个使用情况来判断到底是具体哪一个业务部门有更多的资源消耗。或者是的这个机器的这个水位和调度的这个水位其实有很大的这个区别，那可能需要做一个 Memory ，应用的所有 memory ，一个请求输了一个调整，包括说如果有一些触发的一些请求，比如说是脉冲，那可能建议是说可能是需要进一步的去使用一些弹性能力。通过这样的方式，希望给企业在云上使用一些原来就有一些更多的一些工具支撑。那这样的能力就在自身企业也是有很多的一些实践。
③成本优化实践之弹性
那这样来介绍一下，就是当有了这些建议之后的话，如何从多方面去做一些实操的一些能力，那第一个来讲就是，如果发现应用，比如有一些周期性的一些变化，比如每天早上8点可能会有一个峰值。或者有一个比如说最近618，在昨天晚上可能是有巨大的峰值。那所以建议是说可以去提供一些基于一些节点弹性或者是说对于一些 POD 的一些。自动化的弹性伸缩能力。那这里值得一提的话是说在云上提供了一个叫做虚拟节点的一个容器实验能力，它可以让你免于作容器节点的一个运维，然后完全是提供了一个容器分装，那它的好处是他在一些极限的场景有非常好的弹性，比如像之前是和微博有一些合作，就是在微博有些时候，也是可以快速的去通过弹性的 ECI ，这种一些能快速地拉起应用，解决一些热点问题的资源的困境。那现在，是能做到在30秒内可以启动3000个 bot 。那这样的一个容量可以满足一定的这种突发需求。之外，对于常态的比如说对于一个节点的扩容，也是做了非常多的一些从管控到底层镜像优化，然后做到一些先进的扩容到60秒之内，做一个很好的一个节点拉起。那此外，尤其在云上环境我们可以结合实例然后做到很好的一个镜架的一个调配，可以减少50%以上的资源成本。这是在做一些典型的场景的一些实践。
说到专业化，发现如果在机器比如是个在线应用。还有非常多的一个资源的浪费或者会发现大部分的这个在线应用，这个技术设备可能只有百分之二三十，那这个时候，建议能不能把一些 Java 类型的或者离线的任务和在线应用作用但实际上就是在内部。已经有接近 10年左右的这种原生经验，并且其实也是大量的去落地的这种能力，可以把一些现在这种电商业务，还有一些树推广的业务，包括离线计算业务，做一个定时，通过这样的方式能够提供一个资源的一个充分利用。现在最近应该是在两个月之前，也是对外开源的一个新的开源项目，那它是把在内部的这种综合管理的部署能力也开放，是希望给大家更好的一个能力。那比如，可以让在线应用跟 spark 教法能做一个很好的一个符合管理，也是针对这种不同这种任务，做了非常多的，比如说定义这个应用是不是一个 sentence 的一个敏感应用，还是一个 best effort 的应用，可以去结合一些内核技术可以让不同的级的这个 CPU 更好地调度策略然后包括在内存上也可以做到一个现在比如说那种回收，在一些全区类似于回收顺序优化，包括是说有一些容器级别内存的自动化回收的一个策略。通过这样的方式能够更好地去帮助做一个混合故事。那这块其实有兴趣也可以来看一下一些开源在线能力。
④成本优化实践之智能化
那除了这两块之后，比如前面就是其实也在落地很多智能化能力。那最近也是推出了一个叫做基于预测的智能产业 AHPA ，如果对 K 8 s 比较熟悉在，会发现 K 8 s 也提供了一个基于预测的一个学习能力，就是它可以给予 POD 做一个当资源不够的时候，做到一个快速弹性。但它其实有两个痛点，第一个是比如说到8月份的时候，要做一个弹性。遇到一个问题， POD 准备往外弹但是，它可能启动还需要一段时间，然后启动完之后，硬盘还要做预热。那这个时间可能有分级或更少，在这个时候可能对你的在线业务支撑，可能已经有点比较慢了，那这是第一个痛点，就是叫做能启动的一个问题。
那第二点是怎么样去更好地去配置 AHPA 这个策略，比如到底是70%去扩还是80%扩，这个其实是难点。因为配多了，是资源浪费，配少又不够灵敏。那所以理解是这样的，这两个痛点，其实也是和达摩院做基于预测的，因为它的好处是说能自动的去帮你去识别你这个应用是不是有周期性，然后自动的去增加一些周期性的一些主动的一个弹性。那好处就是可以帮你提前把你的应用在你真正要的时候弹出来。那在最近其实也是跟很多企业包括组织合作，在达摩院的智能语音交互和菜鸟也做了一些落地。还可以比如举个例，比如说可以在这些智能语音交互中可以解决90%的实例在这个业务高峰时间就应该ready了。那只有很小的一点是说做了一些用云的方式，能优化在原来这种被动的这种弹性的这种不足。此外通过这样的一个主动的这种弹性和成本管理，但不仅是说解决这种难题，还能够在原来弹性的基础上，再额外能节省20%的资源成本，CPU利用率提高10%。这个其实是一个增量的红利。对于大规模企业来讲，其实是一个非常值得注意的能力。
⑤ AlOps
AIOps :不局限于 AI ，而是 AlgorithmicIT Operations ，将数据化智能化能力融入 IT 运营，加强 IT 运维自动化能力。
那前面讲完就是在成本这块的一些实践，那最后来讲一下，就是在整个质量和稳定性的一些实践。那这里就第三个关键词就是AlOps 。那这里会发现就是说那什么是 AlOps ，会把 AlOps 到底是不是说一定要用一些人工智能的新的生物学技术，但实际上就是说，你如何能够帮你的整个运维的这个 it 云，然后把这些数据化智能化能力引入，这就是一个很好的一个 AlOps 落地。但是也会了解，就是AlOps 到底能不能在企业落地，其实也是很多坎坷。
这个点先讨论就是在原生场景为什么要讲这个概念，那它的一个挑战是什么。看左边这个图会发现就是整个相对于原来的这种应用架构，其多做了非常复杂度。比如引入了 Mesh 、容器之后，它多了好多个比如说从微服务到这种 Sidecar 的应用到 Kubernetes 的角度，再到那个容器网络、容器 OS，再到操作系统和底层网络，再到虚拟化和硬件。那整个其实这个站，任何一个地方出问题，其实非常难定位。而且就是两个痛点，就是第一个就是更多的不确定性，就是正常的环境可能都会出问题，然后很多人开源组件，包括镜像肯定是从外部仓库里拿过来。然后可能不同环境又不一样，然后，在云上比如尽量做弹性，弹完之后在现场也找不到，那这个其实是很大的痛点。另外一个就是它规模也更大，比如说原来有一个大公司有1万台机器是，但是在这个原生时代，因为容器利用率更高，可能一台机跑10个100吨。那这时候整个这个业务规模是100倍的提升，所以对于整个的业务规模来讲是不大。另外来讲就是可观测指标，就这两个就是痛点，那到底如何去解决这些问题。
这里是抽了几个点去解决问题。如何去降低系统复杂度，从三个方面，第一个是说当这个系统复杂度非常高，非常爆炸的时候，希望能不能把复杂度降低，然后做到一个抑制，希望通过声明式和不可变架构去避免这些问题的这种不确定性。那其实来讲就是说如何去在每个层面能够更好的做一些新的定位，能够帮助通过一些知识库的能力去更好地。更快去解决定位问题。另外是做一个 Ops ，能够通过一个异常自愈和预测能做到的一些能力。
⑥声明式和不可变架构
接下来介绍一下在这三个领域的一些实践，首先就是第一个要讲，就是什么叫做声明式和不可变架构，其实对有个词应该比较熟悉就叫做 infrastructure code 。如何去通过，比如类似于 former 等。通过这个方式去描述这个应用的部署和架构。但是好处就是说在不同环境其实可以适用，出问题的时候也知道哪个出问题，而不是说线上连续去改。这个其实是已经是一个比较好的方式。但在云原生这个时代，这个层次变太多了，就是每个层次都会出问题。所以希望是在每一个环节都能真正做到这种声明式和不可变架构。在多个层次都能达到这样一个效果。那比如在操作层面，也希望能够做到一个声明式和不可变的一个系统。而不是说在操作系统就随意的去做一些一个升级。然后在应用层面。希望是能通过统一的这种 helm ，或者是 customer 去做一个这种应用的一个定义，包括是之前合作项目如何去通过一些应用模型，通过 chance 通过 composer 定义日志还有一些监控的组件环境的能力，那其实来讲就是如何去通过这种可观测层面，是通过前面说的一些标准化协议，去跟企业内部的这种不同组之间的这种可观测采集的这个指标它的规范也是统一起来。那在上层比如说对于经验层面，希望是前面提到怎么通过这种不可变镜像，然后包括是说通过验证之后的 promotion 的一个动作能够让整个的这个镜像可不变，所以每一层做到一个声明式和不可变架构，那它能达到一个就加速问题定位减少排查入境，让每个问题都是可追溯。通过这样的方式能够很好的去把复杂度降低。
声明式和不可变架构-容器优化 OS LifseaOS
那接下来针对操作进程做一个介绍，这也是在前一阵也是发布了一个叫做 LifseaOS ，它也是一个叫做 OS 的一个理念。怎么理解，就是说 LifseaOS 在内部也是基于一个叫做原子化的一个更新能力，就是每一次的这个更新不能说在已有的这个进项、运营去做变更，每次的一个功能增加或者发展，需要重新的去打一个新的镜像出来，通过这样的方式，能够保证每次修复都是有一个记录，并且也是做一个 Readonly roofs ，保证是真的修了，那其实来讲也是用一个用 API ，包括是说怎么样去精简的安全的能力去把一些非必要的，在运用场景中用不到的一些库作为裁剪，能够进一步的去减少一些比如软件包的这个大小，然后也让整个性能提升。通过这样的方式，在 OS 里面做一个很好的不可变的保证。
⑦根因定位
那接下来介绍一下，在云原生它的成分是非常多的，从 Mesh 到容器到内核非常多层面。所以在内部实现了一个针对全场景的全面的诊断。会针对比如节点本身的一些异常，或者网络异常等，包括升级想做非常多的一些知识能力的基点，然后在内部也是有一些规则引擎，包括一些智能 AI 的能力去做一些主动和被动的一些预测，然后通过内部的一些指标、一些能力去做完整的一个分析，到目前的话就是说通过线上大量的这种积累，也提供了100多个诊断线。那比如说前一阵子奥运会的支持，也是通过这些能力快速的去降低遇到一些。容器等的这种排查问题的实践，也是有非常大的一个帮助。
根因定位-基于 ebpf 的一体化可观测
那此外的话是会发现就是容器本身那个监控也是非常复杂，所以在 MS 用监控中也提供了一个基于天赋的观测能力。能够做到一个无切入的采集，能够把这些能力快速的去做在各个端的突破的一个聚合，然后也能做一个智能分析。然后针对做一个网络协议的，也是做了一个观点，不仅是在容器层面，在应用层面、微服层面，可以做一个端到端的一个全面的分析，便于进一步地去定位问题到底在哪里，然后再整体的网络服务上，可以做到一个观点分析，帮助更好的去做一些支撑。
根因定位-容器网络安全问题
这里来介绍一下，就是具体在一个场景，在网络是如何去解决这些问题。那如果对容器网络表示，就发现挑战是什么，就是原来在云上，比如已经有虚拟化网络，然后虚拟化网络还会有一些涉及到底层这种物理网络，然后这样它内容比较长，但实际上，就是有容器之后，在处理云之上还有一个容器网络的一个概念，所以由两层变三层，对于就是从一个云内部的市场来看，所以当出现问题的时候，要定位，到底问题是在比如是在上的问题还是数据质量问题，还是在内部的问题，甚至是一个内核的问题。
所以对于每次排查问题，可能需要几个小时甚至更久。那针对这样的问题，在云上开发了一套叫做 Skoop 的一个网络，整个工具它能够很好的去模拟不同的网络协议，比如说针对云上的一些网络协议，然后做到自身的一个自动化的构建，包括模拟转化图然后可以根据这种模拟的标准化图去在统计内部节点做一个注入，然后根据通过一些不同节点当中去采集，能够做到一个内部的一个规划，然后通过这样的方式，会去遍历不同的路径，之后可以做到一个快速的去定位出到底在哪个环节出问题，再通过这样的方式，希望能够快速的去定位问题。那除了在内部定位之外，也是走动一下，做了非常多的一些工具的支持。
根因定位-故障注入
除此之外，会发现在在云上这种问题其实非常多，有各种层面问题，所以也是支持了一个叫做 ChaosBlade 的一个混沌工程的一个工具，能够自动化地去做各种一个故障演练的场景的一个注入，然后这也是完全自动化的流程。也可以去搜一下，然后可以在自己的环境做一些验证，到目前已经是支持超过200个不同场景的定义，能够很好的去帮助验证不同问题的识别。
⑧异常自愈和预测-托管节点池
最后还来讲一下，就是除了诊断和一些能力之外，也是提供了更多的一些自愈和预测内容。自愈，就是会希望是在云上或者说在开发区院中有非常多的这种比如容器组件的一些异常，包括看到的异常，还有一些硬件的异常等。那这些异常，希望是说能够通过一个尽量在当下进程去解决它的问题，能够做到一个主动的自愈。那目前来讲，也是针对不同的这种层面，比如在系统硬件层面，然后在 docker 这种节点池层面包括在操作系统层面，做了多层次的一个自动化的自愈的能力，然后持续去增加更多的技术场景，能够帮助不需要关注到底哪一层出了问题。除了在这种自愈能力之外，也是结合前面提到就是说对于 USB 的修复，可以比如说选择到底。比如高危的 cbu 还是中危的，可以做到一个全自动化的后台在一个自动的升级，通过这样的方式，需要是能够让应用更加关注于应用，而不需要去持续地去在一些边界模糊地带去做处理，然后通过这样的方式也能够做到很好的一个责任移清，同时的话，就是对于一些组件的应用自动升级能力，也是提供了持续的这个能力。
异常自愈和预测-定时巡检
然后除了在自愈能力之外，其实也是在多个层面做定时的一个巡检，包括主动风险的一个预测。目前已经在比如说在一些云资源的一些配合，比如说一些请求守卫，包括节点守卫，包括是一些关键组件的版本是不是和稳定版本或者安全门有较大差异。然后也会在这里进行一些风险，能够做到一些进一步的一个识别。通过这样的方式，希望是说能够结合自愈加上巡检的方式，能够更好的去写入企业能够更好地落地，在原生技术的一个支撑。然后基本上这里就是介绍在质量稳定性的领域的一些建设。
⑨云原生场景的智能化运维演进
那最后简单总结就是会发现整个云原生场景其实在不管是说这种风险的引入，在这种动态性，在这种弹性上，其实是有非常大的一个演进。对已有的这种运维习惯其实有巨大的冲击，所以希望是能在第一天就能够提供非常好的一个默认安全。然后第一天做好针对这种动态的这种应用部署的这种成本的规划和治理，然后第一天能够针对面向so的一个驱动来做好一个设计，所以需要对于一些已有的这种运维组织，其实需要有更多的这种心智上的这种变化，再其次来讲的话，就是说当很多系统复杂度，不是说通过单维的升级，需要让多个层次的这种阀度，能够逐渐降维，在每个层次尽量去减低复杂度，然后让去抵抗这些带来的额外的风险，希望是在操作层面，在客观的层面，在各种层面，都能通过一些声明式，是面向生态的方式自动化一些的方式，能够提供更好的这种运维能力的支撑。那最后是说如何去更好地结合数据智能的采集，建立更好的，比如现在来讲就是说对于云原生，视频上如何做到视频的一个知识图谱。包括说一个制品。到底包含哪些组件，然后有什么样的一个依赖关系，做更好的一个治理。其次是说在整个的这种业务运行时，然后做更好的这种可观测，包括是说一些诊断能力的一些数据的一个汇集，能够做到一个自动的一个多指标、多数据维度的一个聚合，能够提供更好的一个智能化能力。通过这样的方式。相信也是希望企业能够在整个落地云原生过程中能够走得更快更稳。
