不知道的 主动性 被动性 监控 可观察 健康检查 告警 指标 日志 追踪 问题和根因 预警 监控&稳定性 分析&追踪&排错&探索 • 从稳定性目标出发，首先需要有提示应用出问题的手段 • 当提示出现问题后，就需要有定位问题位置的手段，进 一步要有能够指出问题根因、甚至提前就预警的手段。 拓扑流量图：是不是按预期运行 分布式跟踪:哪些调用 故障或者拖慢了系统 监控与告警： 主动告诉我 问题发生了！ 等工具进一步从微观帮助研发人员定位和解决问 题，这是这里在业务上的价值-稳定性赋能。 标准化能力-微服务PAAS-从监控到可观测-研发人员的第五感-2 可观察性是云原生特别关注的运维支撑能力，因为它的主动性，正符合云原生对碎片变化的稳定性保障的思想 数据的全面采集 数据的关联分析 统一监控视图与展现 Metric 是指在多个连 续的时间周期 内用于度量的 KPI数值 Tracing 通过TraceId来 传统交付方式的不足之处 手册文档 配置参数 应用 应用 配置参数 应用 应用 软件环境 硬件环境 遗留系统 安装配置点 安装配置点 安装配置点 集成点 集成点 集成点 1. 交付人员学习手册文档，需要在客户 环境做“安装配置”和“与遗留系统集成” 两方面工作。 2. 安装配置：在硬件上安装软件，不乏 针对硬件特性的适配、还需要安装OS 等，最后还要在OS上安装应用，并且 还要保证应用软件依赖拓扑结构不会

外部依赖变化：ERP可用性变化 带来的不稳定因素 5 人员变化：没有知识沉淀导致的 不稳定因素 4 环境变化：因安全、流量、故障、环境崩 溃、底层IT变更而变带来的不稳定因素 非云原生：无法对应变 化=稳定性无法保证 云原生：主动对应变化= 稳定性保证 什么是云原生(Cloud Native Computing)->为云而生 只有为云而生的应用才 是云原生应用 2 0 1 9 年 云 原 生 爆 发 成 为 主 攻 方 第二个困难已经被Mesh技术架构解决了 • 第一个困难就需要为研发用户提供高级抽象-IaC 抽象成虚拟服务和目标规则这两种声明性API(Yaml),使得配置非 常形象易懂，并且彻底将左侧需要了解的细节进行了屏蔽和简化， 只需要学习规则，而不需要了解下面很多种实现，大大降低了使 用者的难度，并实现了版本化能力 ServiceMesh-3-新发展-多运行时Mesh架构(机甲) Bilgin Ibryam 分析并总结了分布式应用的四大需求

需要进行大量的安全特征以及资产库的建设或者 三方集成。（涉及业务能力） RASP(运行时安全应 用程序自我保护) 可以看做是IAST的兄弟，RASP通过程序上下文和敏感函数检查行为方式 来阻止攻击，属于一种主动的态势感知和风险隔离技术手段 可以自动化的对非预计风险进行识别和风险隔离 对系统性能有一定影响 可信计算 核心目标是保证系统和应用的完整性，从而保证系统按照设计预期所规 定的安全状态。尤其是像边缘计 行环境TEE（比如IntelSGX，蚂蚁的KubeTEE等）可以保护运行中的数据和 代码，完成了安全闭环。 依赖于硬件和更高阶密码学，可以彻底阻断物理 设备以及软件的攻击，是高级的安全保障技术。 TEE是运行态主动防护的高级手段，对高安全生产 环境建议使用。 成本较高，所以要视业务场景要求取舍。 Mesh零信任 mTLS服务间访问授权，主要针对Pod层WorkLod的访问控制 应用透明，全局管理视角，细粒度安全策略

为什么混沌测试 通用指标 阶段性进阶衡量 标准 指标 量化 什么是混沌测试 什么是混沌测试 混沌工程旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。通过主动制 造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。 混沌工程将预想的事情和实际发生的事情进行对比，通过“有意识搞破坏”来提升系统稳定性。 鲁棒性 故障注入 如何选择混沌测试工具

进程 网络连接 系统调用 文件 配置 安全容器模型 在业务上线后，容器安全工具基于内置检测规则+行为学习+自定义策略，多维度保障容器运行时的安全。 已知威胁方面，通过丰富的内置安全策略，对业务容器行为进行实时监测，及时发现风险。 未知威胁方面，通过对业务容器行为进行学习建模，感知业务行为偏离，发现未知风险。并提供隔离、暂停、重启等处置能力。 DevSecOps安全防护流程 从源

（4）API 安全审计工具 该工具通过对 API 资产的流量上下文及敏感数据的持续分析，可以实时发 现 API 资产的授权类、认证类、数据暴露类、配置及设计不合理等各类逻辑漏 洞，通过外部情报和机器学习模型来感知针对 API 的低频慢速的攻击风险，使 用账号、IP、访问时间、访问 API、访问敏感数据等多重维度建设的 UEBA 模 型来感知账号共用、借用、盗用等行为导致数据泄露的攻击风险。 4 特征匹配的模式下，可能对风险有所遗漏。所以可对业务行为建立模型，在一定 周期内，形成业务行为基线，从而发现模型外的异常行为，进一步发现未知漏洞 攻击等行为。并可将行为模型关联业务镜像，使得模型可复用，减少容器多副本 时学习的多余资源开销。 （5）历史数据留存 事后溯源是安全的重要组成部分，但容器在消逝后，未做持久化的数据将会 丢失，且容器在运行过程中的行为也不会被记录，使得溯源极为困难。基于此， 组织需建立对

可灵活扩展的其 他能力 • 一个完整的应用描述文件（以 应用为中心） • 灵活的“schema”（参数由 能力模板自由组合） • 放置于应用代码库中（gitops 友好） • 无需学习 K8s 细节（ 完整的 用户侧抽象 ） • 可自动适配任意 k8s 集群与部 署环境（环境无关） 查看“能力模板”的用法 1. 能力模板注册时，KubeVela 控制器会 自动生成 OpenAPI

vesoft-inc/nebula 上⼿ GraphDB on K8s 应⽤场景 - Nebula on Kubsphere - Demo 图数据库的应⽤场景 典型场景 社交⽹络 ⻛险控制 公共安全 知识图谱 机器学习 ⽣化制药 物联⽹ 区块链 数据⾎缘 智能运维 tech.meituan.com/2021/04/01/nebula-graph-practice-in-meituan.html KubeSphere