1、,云原生建设行业背景,保障稳定vs引领创新,转型方向,敏捷模式,云原生效能,?,保障信息系统安全稳定与引领创新、把握科技浪潮“两手抓，两手都要硬”,数字化和智能化着力点和方向在哪里构建什么样的运维体系,建设什么样的云计算架构充分发挥云原生效能,微服务及容器广泛应用快速迭代及持续交付敏捷开发模式,面临痛点,建设过程面临的痛点：资源交付周期长，交付效率较低，较多人工参与，重复劳动多，敏态业务要求基础设施快速交付、自助交付互联网类应用、证券类应用波峰、波谷差别显著，要求基础设施弹性扩展，能够应对突发业务量变化各类资源的平台各异，管理流程与界面也不尽相同，缺乏对基础设施的统一抽象与封装，给使用者带来困

2、惑目前仍以IaaS层的虚拟机交付为主，缺乏对存储、网络、容器、应用层面的支持部署标准化不足，仍存在大量手工部署的情况，易出错，重复量大，依赖个人操作习惯，打破标准化、幂等性等重要原则研发、测试、生产等多套环境经常因为配置不一致，造成问题没有测出来,02,推进路线,建设路线,容器云平台,03,关键挑战及建设,关键挑战,GitOPS实践,应用生命周期及云上工作模式,应用云化改造,应用与配置分离,中间件的选择,日志方式改造,健康检查接口,多应用的分离,优雅终止,安全的基础镜像,高可用设计,跨数据中心、多集群整体高可用,入口负载均衡高可用,单集群高可用,监控和日志高可用,建设-镜像部署方案,镜像仓库部

3、署方案多个Harbor实例共享后端存储,告警中心,Webhook 告警,ThanosSidecar,Masters,Workers,Workers,监控中心,ETCD,Kubernetes,Grafana,Thanos,Prometheus,Alertmanager,Grafana,Thanos,Prometheus,Alertmanager,平台项目,业务项目,容器云平台集群,企业微信,短 信,邮 件,Thanos,业务线,监控与告警,对象存储,监控数据统一存储方案,bucket,Store,Querier,Sidecar,Compactor,SSD,Prometheus,Sidecar,S

4、SD,Prometheus,1,1,2,4,3,5,Receiver,1”,1”,基于Prometheus的组件化、集群化，构建统一的数据存储方案将容器与非容器监控数据统一汇聚分析,日志与审计,业务应用,标准输出,filebeat,容器云平台日志中心ES+Kibana,审计日志,审计日志,Kafka 接口,业务日志,业务日志,日志中心,日志归集平台,高性能日志方案,不同日志速率下对Filebeat对接的外部kafka消息堆积情况、消费者消费延迟、日志是否丢失进行压力测试。,EFK,Elasticsearch、Filebeat、Kibana,Gitops 基本概念,GitOps 使用 Git 作

5、为声明性基础设施和应用程序的单一事实来源。其核心是Git 存储,包含对生产环境中当前需要的基础设施的声明性描述，以及一个自动流程，以使生产环境匹配Git存储中所描述的状态。,闭环控制,Gitops能做什么？,Gitops 方案,|_deployment.yaml（1.16.2）|_service.yaml|_route.yaml|_configmap-976cchk896.yaml(FZ),|_deployment.yaml（1.16.2）|_service.yaml|_route.yaml|_configmap-236cbhk239.yaml(SH),Sync,Gitops,通过门户可视化编

6、辑k8s yaml 定义保存提交,门 户,Commit 变更,容器云平台,容器云平台,|_base|_deployment.yaml（1.16.1）|_kustomization.yaml|_service.yaml|_route.yaml|_configmap.yaml|_dc-fz|_application.property|_kustomization.yaml|_dc-sh|_application.property|_kustomization.yaml,kustomization.yamlimages:-name:newTag:1.16.2,滚动升级nginx:1.16.1 ngi

7、nx:1.16.2,为不同的集群创建各自的子目录或分支，可轻松地将该模式拓展到多集群环境,跨DC多副本部署,DC1被管理集群,DC2被管理集群,Gitops(ArgoCD),应用管理中心,镜像下载,镜像下载,管理应用,管理应用,管理门户,应用分发副本与配置多个集群状态管理Gitops安全策略,容器云平台,容器云平台,容器云安全,容器主机操作系统和多租户,容器内容(使用可信来源),安全性和构建流程,部署及控制可在集群中部署的内容,容器编排确保容器平台的安全,网络隔离,存储,单点登录(SSO)双因素认证,多集群的角色和访问管理,镜像仓库(安全访问容器镜像),容器云平台,04,总结展望,筑牢底座赋能

8、发展,合作共赢务实创新,容器云基建,价值,转型,数字化智能化,规范,标准统一覆盖推进,感谢您的观看！,主讲人：赵浩廷,企业云原生转型过程中的稳定性保障探索,01,02,03,云原生架构带来的复杂度,转型需要从复杂中探索稳定,我们如何做,04,红帽的平台与方法,01,02,03,云原生架构带来的复杂度,转型需要从复杂中探索稳定,我们如何做,04,红帽的平台与方法,“系统架构是塑造系统的最重要设计决策，我们通过未来变更成本来衡量其重要性。”,云原生平台的选择正正是这样的决策,https:/,云原生架构选择带来了复杂性,39,开发流程,基础设施,架构,瀑布,数据中心,单体,CICD设计,任何基础设施

9、（混合云）,（微）服务,精益化、协作性和完全自动化的软件交付生命周期,写一次，在任何计算资源上运行。按需规模，容错的设计和提前部署。,松散耦合的、模块化的应用程序更容易构建、测试、部署、更新和更改。,通过组织团队和他们的工作来管理变化云计算的自动化和架构，以提高创新速度,改变并不简单,40,规模导致的效率与复杂度问题是当前软件生产团队的主要挑战,演进和规模化生产的复杂性和未知问题,01,02,03,云原生架构带来的复杂度,转型需要从复杂中探索稳定,我们如何做,04,红帽的平台与方法,过去,“云”时代,管理服务器最小化意外事件长生命周期的基础设施手动检查列表支撑型部门,管理服务最小化 MTTR相

10、对短周期的基础设施强制执行自动化实现业务创新,信息部门工作对象的改变,组织形式的转型,43,云原生的“工业产品”,响应式创新,平台服务,无处不在的自动化,规范基建,差异化业务价值,固定或采购式应用程序,保护网关,每个项目基础设施,人力驱动的操作,脆弱的部署,异常事件的复杂性,启用约束,自服务创建,开发,运维,花更多的时间在什么是重要的事情上,44,构建高质量的产品,运营客户行为,度量成功,发布产品给客户,我们能建得很好吗？,我们能稳定高效地交付它吗？,它有效吗？,研发团队,基础设施团队,业务/管理团队,了解架构带来的影响,新技术带来的度量变化,云原生：不仅仅是迁移到云，而是充分利用云基础设施和

11、服务的独特性，快速交付业务价值.,云原生应用程序要实现的核心技术和业务目标：敏捷和生产力：实现以业务指标为导向的快速创新。降低维护风险并保持环境最新。弹性和可扩展性：环境自我修复和无停机的持续可用性。提供弹性扩展和无限容量的感知。优化和效率：优化基础设施和人力资源的成本。实现地点和提供商之间的自由切换与移动。,云原生基础设施：更高“内聚”的抽象,不可变部署例如基于容器镜像的部署（vs 虚拟化的模板仅提供了操作系统基线）声明式配置“基础设施即代码”提供了一个期望（未来）的状态（vs 需要详实的部署配置脚本或者文档）运行时不可知平台即组件（例如容器）视为黑匣子，无需了解其内容（vs 关注依赖的组件

12、部署和调用关系处理）组件编排通过通用声明性策略和配置实现管理：监控、扩展、可用性、路由等（vs 运维系统及监控与网络管理体系的支撑）。,|45,技术的转型,01,02,03,云原生架构带来的复杂度,转型需要从复杂中探索稳定,我们如何做,04,红帽的平台与方法,47,基础设施即代码。一体化的开发运维团队。卓越的运营。,产品所有者能力规划与匹配的管理制度自动化体系和运行保障持续的平台改进授权实验和创新与治理、风险、合规性概况相一致的安全性将该平台作为一个主要的业务公用资产提供资金赋能,平台用户群体云原生架构敏捷的方法和实践现代化应用编排云原生应用程序开发技能前端框架CI/CD工具现代测试方法,可靠

13、性层次结构,把基础平台视作为产品,技术债务,应用与部署的遗留问题,解决技术债务,49,在大多数情况下限制自己来解决问题，通过公司/团队特有的标准技术来实现解决方案，随着时间的推移，技术团队将成为这方面的专家。长期来说，技术团队将受益于它。技术能力从来不是购买所能获得,Problems,Technical Solutions,Problems,Technical Solutions,No Snowflake Stacks,选择有限的标准技术,自动化一切,Push,Pull,Pull Request,应用程序Git Repository,Image Registry,CI,配置Git Reposi

14、tory,部署,监控,检测偏移,执行,CD,GitOps 应用发布模型,OpenShift GitOps,Push,Pull,OpenShift GitOps,Push,Pull,配置Git Repository,集群内资源协调器控制器在集群上控制器发出通知并采取行动,外部资源协调器控制器在集群外部根据集群 CRD 和 Git CRD 比较的结果采取行动,Role Based Access Control(RBAC),Quotas,Namespaces,Operators,Applications(Dabases,Messaging.),Users/Groups,Kubernetes,应用为视

15、角的一切均用代码表示并实现自动化幂等原则是在各层面均适用的除了消除Toil（重复劳动工作量），更需要把故障恢复的能力加入到发布中发布能力与故障恢复能力等同看待消除人的失误,自愈能力,数据中心级的混沌 应用级混沌,应用故障服务故障管理中断.Cluster故障Cluster宕机Node故障Pod故障/Container故障服务/组件故障MW故障DB故障资源故障存储故障网络故障资源耗尽.,故障监测与告警,应急处理,恢复,52,在度量基础上探索平台的稳定性,应用运行状态异常计算、网络、存储资源云可用区故障平台集群停止测试边界的划定,SLO定义：Pod 延迟 5秒API 99th 延迟 1秒Etcd f

16、sync 延迟 50 毫秒关注组件的恢复时间（实际down time）route/ingress 健康状态,53,在场景上探索平台的稳定性,Etcd 延时、部分失败Api 失效SDN 中断pod 中断预算Node 资源压力DNS 异常、时间异常,大集群 VS 小集群场景定义 非预计的故障发现SRE、产品发布、CIKrkn+Cerberus,Chaos-mesh,Litmus,Arcaflow,应用发布标准化与自动化,项目管理、治理、合规及流程规范,平台运营支撑,业务及应用能力图谱,投产,Appn,生产,基础设施及治理(根基),项目(建筑),DevSecOps Dojo,应用现代化&迁移,企业软

17、件工厂,可信软件供应链,评估&开发计划,DevSecOps Dojo,DevSecOps Dojo,DevSecOps Dojo,从一到多,业务应用演进路线,应用投产,App3,从实验开始,01,02,03,云原生架构带来的复杂度,转型需要从复杂中探索稳定,我们如何做,04,红帽的平台与方法,开发人员生产力,集群服务自动化运维 空中升级 监控 镜像仓库 网络 路由 KubeVirt OLM Helm,Kubernetes,开发人员CLI VS Code扩展IDE 插件Code Ready Workspaces CodeReady Containers,Service Mesh Serverle

18、ss构建CI/CD Pipelines全栈日志计费,数据库 开发语言运行时 集成业务自动化 100+ISV服务,平台服务,应用服务,开发人员服务,物理机,虚拟化,私有云,公有云,OpenShift Kubernetes Engine,构建云原生应用,管理工作负载,多集群管理发现 策略 合规性 配置 工作负载,Advanced Cluster Management,OpenShift Container Platform,托管云(Azure,AWS,IBM,Red Hat),Red Hat Enterprise Linux&RHEL CoreOS,红帽混合云架构 OpenShift Hybrid

19、Cloud Platform,云原生应用策略客户指南,您在这里,产出构建支持业务的应用程序业务需要的速度。敏捷+稳定,技术调整Agile,CICD and DevOps容器化，Kubernetes微服务,APIs,Events and FunctionsServiceMesh and Serverless,现有应用,新应用,Retain or RetireNo Action Req.,Replace w/New AppsGoto New Apps,Refactor(Decompose into Svc&publish APIs),Replatform(Lift&Fit)or Rehost(Li

20、ft&Shift),Build Cloud Native Apps(CICD,Containers,Svcs),Buy SaaS/COTS(Integrate to automate biz processes),Core:Points of differentiation,Context:Points of parity,动态性为变化和规模化设计采用模块化、事件驱动、松耦合架构,连接性通过数字渠道和物联网与边缘集成扩大市场范围,智能化通过业务流程自动化和 AI/ML 优化客户使用体验,业务驱动力为数字经济振兴业务。提高客户价值和体验。使用软件交付作为竞争优势。,IT 痛点 无法及时满足业务对

21、新应用和新功能的需求。新应用和现有应用之间集成的复杂性。缺乏现代开发、开发和运营技术和实践的技能。,现化化目标敏捷交付降低成本获得云效率提高可用性增强功能,从一个项目开始 单体到微服务的转型 事件驱动的应用集成 将 AI/ML 与智能应用程序一起使用采用云原生开发构建正确的应用程序正确构建应用程序建立团队协作提高软件交付性能 变更前置时间 部署频率 平均恢复时间 变改故障率OpenShift Applications&Services Bundle,业务调整从为什么开始，以终为始工作价值流和流程图事件风暴和影响图服务蓝图,IT 仅在 IT 支持业务的情况下才有价值,-Value Stream

22、Mapping-Parking Lot,Open Practices in Mobius Loop,58,产品探索,产品交付,基础,可选的解决方案,-Target Outcomes-Priority Sliders-Lean Canvas-Impact Mapping-Event Storming,-Scrum-Kanban-Showcase-Retrospectives-Software&DevOps engineering-Automation-Cloud,-Icebreak-Team formation-Social contract,-Definition of Ready(DoR)-

23、Definition of Done(DoD)-Visualization of Work,-User Story Mapping-MVP,Open Practice Library:https:/,开源的文化推动了开放的创新,我们相信什么,避免长期路线图计划得足够开始,打破大的事情成小块逐步工作,瞬间的反馈周期,自动TDD，CI/CD,建立新的技能通过结对和指导,实验学习策略小故障是学习机会,Just Start尽快开始,感谢您的观看！,数字化韧性与混沌工程,主讲人：同创永益 韩立峰,01,02,03,数字韧性,混沌工程,未来展望,一、数字韧性概述,“韧性”到“数字韧性”,Gartner对数

24、字韧性发展的转变,2016年：定义IT Resilience可以帮助基础设施和运营领导提高业务恢复效率，降低恢复成本2020年：客户的期望已经超出了“连续服务”，越来越多的组织开始将注意力转向业务的韧性建设,IDC对企业数字化韧性解读,数字化韧性是组织利用数字化能力迅速适应业务中断，不仅能恢复业务运营，还能从变化中找到新的机会。IDC首席分析师武连峰2022年IDC发布打造企业数字化韧性的战略与举措研究报告：“根据IDC的调研，超过80%的企业处于数字化韧性的中高风险;在金融与财务方面处于中高风险的企业数量达到90%；在客户与生态方面，处于中高风险的企业数量达到87%”,数字韧性的定义,数字韧

25、性 是指组织的数字化系统在面对故障、灾难或人为攻击、破坏等各类事件时的抵抗、吸收、适应和恢复能力。各类组织数字韧性体系的构建，需要结合人员、流程和技术，通过一系列主动和被动措施来保持数字化系统持续运作，并尽可能减少中断对组织关键业务和运营流程的影响。,数字韧性成为衡量企业数字化运营能力的重要指标,数字韧性的目标,数字韧性的目标：实现数字化系统在设计目标状况下的持续有效运行。数字韧性包含了信息系统灾备管理、应急管理和混沌工程等内容，但其强调了数字化系统面对各类事件时抵抗、吸收、适应和恢复的能力，同时还需考虑对业务的最小化影响和组织内外部数字化系统的整体性。,发现阶段,响应阶段,恢复阶段,验证阶段

26、,发生时间,发现时间,强制决策点,时间（min）,事前：备战能力故障预防,事后：改进能力故障复盘与改进,事中：作战能力统一指挥，恢复优先,MTTF平均无故障时间,MTTR 平均故障修复时间,MTBF 平均故障间隔时间,混沌工程助力企业数字韧性体系构建,IT价值链,平时,战时,云原生备份和恢复,监控告警,业务状态感知,应用发布管理/DevOps,自动化/智能调度,混沌工程,业务连续性管理,预案管理,辅助决策,应急管理,灾备管理,指标输入,传统备份和恢复,感知优化,规划风险预案,提供决策,验证预案,演练+实战,应急处置,提供处置方案,决策数据输入,应用容灾,定义策略,瓶颈改进,验证,业务影响分析、

27、风险评估,防患于未然,然则有备,全链路压测,容量管理,提供容量规划,容量分析预警,容量评估,二、混沌工程,混沌工程概述,混沌工程的定义,混沌工程是一门新兴的技术学科，它的初衷是通过实验性的方法，让人们建立复杂分布式系统能够在生产中抵御突发事件能力的信心。Principles of Chaos Engineering,混沌工程和测试的区别,故障越来越难定位，故障越来越不可预知复杂的云化系统里如何生存下去？现在，一个很好的答案就是-Chaos Engineering，中文里面叫做混沌工程,常规测试，测试场景和结果已知混沌工程，验证尚未明确结果的场景,混沌工程的起源,08年Netflix决定把它的业

28、务迁移到AWS上，从自身运维的角度考虑，它有很多担忧的地方很长时间内有两套系统在同时运行，运维的复杂度更高了Netflix的用户量已经达到了1亿，对应用稳定性依赖很高，如果出现故障对用户的影响非常大，甚至是致命的业务不断复杂，引入微服务架构，对应用的高可用性要求越来越高生产环境非常复杂，是多样性的，很难在测试环境中完全模拟生产的状态Netflix决心探索一种在生产环境验证应用高可用性的一种方法，这就是现在大家所熟知的混沌工程,通过主动在生产环境或准生产环境引入故障因子，验证系统应对故障的能力,混沌工程核心思想,混沌工程五大原则,在生产环境中进行实验可能会引发真实的故障发生，所以在执行试验时需要

29、确保影响范围最小化且可控,最小化爆炸半径,Minimize Blast Radius,稳态假说,真实事件,生产环境,关注可测量输出，而不是系统内部属性建立一个围绕稳定状态行为的假说短时间内的度量结果，代表了系统的稳定状态验证系统是否工作，而不是如何工作,通过潜在影响或预估频率确定事件的优先级任何能够破坏稳态的事件都是混沌实验的一个潜在变量,系统的行为会根据环境和流量模式而变化为了保证系统行为的真实性与当前部署系统的相关性，混沌工程强烈推荐在生产环境中进行实验,自动运行试验,手工运行实验是不可持续的工作，所以需要把实验变为自动化且持续的执行。,Build a Hypothesis around

30、Steady State Behavior,Vary Real-world Events,Run Experiments in Production,Automate Experiments to Run Continuously,混沌工程应用领域,混沌工程是一种实践活动，可以应用在现有IT管理体系的多个领域中，作为该领域环节中的技术手段，提升特定环节性能。实践范围可以逐步从单一领域扩展到多重领域。,混沌工程体系化建设目标,1.控制混沌工程带来的风险,2.有效组织混沌工程实施,4.增加丰富混沌工程的价值,3.落实混沌工程产生的结论,投产前,投产后,去除架构设计单点验证系统容错能力评估系统弹性,

31、延长平均无故障时间,缩短平均修复时间,确保达成RPO、RTO目标,极限场景测试平台韧性测试生产故障回归测试验证分布式架构设计（强弱依赖分析）,投产前质量门禁验证监控的发现能力及告警系统的有效性探索风险场景，验证应急预案有效性,验证灾备切换预案的适用性和可用性数据保护定级真切实练，提升业务连续性级别,混沌工程应用场景示例,混沌工程建设路径,预案演练,红蓝攻防,历史故障重演,测试环境,准生产环境,灾备环境,强弱依赖实践场景,生产环境,奇袭攻击,实践环境,实践模式,应用,架构,基础设施,实践场景,级联实践场景,数据一致性实践场景,云原生架构实践场景,传统架构实践场景,高可用实践场景,弹性伸缩实践场景

32、,安全防护实践场景,信创环境实践场景,服务器高负载实践场景,链路异常实践场景,灾备切换实践场景,多活容灾实践场景,故障复盘实践场景,角色扮演实践场景,高负载实践场景,肥皂剧实践场景,错误探索实践场景,混沌工程价值体现,基于混沌工程对业务系统进行平台、中间件、应用等层次的故障注入演练，帮助企业发现更多未知的影响业务稳定性的隐患与问题。,告警时效性验证,容灾可用性验证,全链路稳定性实验,监控覆盖度验证,故障复盘模式,强弱依赖分析,经验库与持续改进,奇袭攻击演练,MTTR,平均修复时间,MTTF,MTBF,平均故障间隔时间,数据丢失,业务中断,DRP,平均无故障时间,实施混沌工程,缩短平均修复时间,

33、延长平均无故障时间,确保达成容灾与应急目标,同创永益混沌工程管理平台,IStorM Chaos是一套完整的混沌工程体系化实践工具平台，提供成熟的实践场景和丰富的故障注入手段，通过对基础设施、平台、中间件、应用等维度进行故障注入实验，帮助信息科技团队发现更多未知的业务稳定性隐患，有效的提升业务和系统稳定性。,通过“混沌工程平台能力”,商用平台先进级,混沌工程相关专利,一种云原生混沌工程实验的爆炸半径控制系统及方法申请号：CN202111228466.3,一种兼容云原生和传统环境的可扩展的混沌工程实验架构 申请号：CN202111002602.7,一种云原生混沌工程实验的靶场环境构建方法,使用FM

34、EA评估混沌工程测试,通过中国软件测评中心信息系统安全测评,混沌工程建设方法,30+实践场景,500+专家经验库,300+故障注入手段,1套 体系化建设方法,核心诉求,输出,交付模式,人员角色,安全生产文化建设战略、制度,实施路径（流程、工具、规范）ROI创新,实践模式与流程规范稳定性指标体系实施收益评估模型,混沌工程实施工程师,混沌工程教练（SRE专家）,解决系统稳定性的实际问题快速上手，不增加太多学习成本,混沌工程普及与实施必要性行业内实践与趋势体系化建设实施路径,体系化落地,混沌工程布道师,规模化落地,常态化落地,基础平台故障库场景库,混沌场景设计实验与优化建议共研&定制化,咨询,轻咨询

35、,产品,服务,混沌工程体系化建设,混沌工程体实践方法,混沌工程平台,混沌工程实施服务,1套 体系化建设方法,三、未来展望,混沌工程作为提升数字韧性的一种创新模式，学术和产业各界在理论研究和工程实践方面积极探索，期待混沌工程的应用为企业数字韧性管理贡献一份中国智慧和力量。,混沌工程助力构建企业数字韧性体系,同创永益是面向未来的数字韧性服务提供商，专注于提供业务连续性、灾难恢复、IT应急、容量管理和混沌工程相关产品、解决方案及服务的国家级高新技术企业，致力于帮助客户建设好数字化系统的全领域韧性体系。,同创永益伴随中国企业数字韧性领域成长,赛道龙头企业，行业积累深厚且客户基础扎实国家级高新技术企业、

36、国家级专精特新“小巨人”企业独一无二的中国人民银行及直属单位示范效应（人行清算中心、征信中心、黄金交易所、银联数据）五大行中，第一家由国内第三方公司承建的灾备管控平台（建行总行）在国内最大的城商行落地第一个混沌工程商业环境案例 技术壁垒深厚，业务能力扎实，国产化尖兵信创工委会灾备管理领域唯一会员单位华为灾备管理领域全球唯一战略合作伙伴证券基金行业信息技术应用创新联盟成员单位混沌工程平台获得可信云能力评估最高级 行业标准制定者，权威合作伙伴认可国家信息技术服务标准工作组、金融信创生态实验室、软件融合应用与测试验证工业和信息化部重点实验室、混沌工程实验室、双态IT联盟成员单位参与编写中国计算机用户协会金融机构业务连续性管理能力模型与评估，ITSS数据中心业务连续性等级评价准则，工信部混沌工程平台能力要求等十余项标准的编写工作,以全面的数字韧性管理应对乌卡时代的来临,通过构建全面的数字韧性管理体系，优雅应对乌卡时代,感谢您的观看！,