一、冗余方案
硬件冗余:在业务集群中,关键设备如服务器、存储设备等应采用双机热备或集群技术,确保在某台设备出现故障时,其他设备能够自动接管工作,保证业务的连续性。
软件冗余:在软件层面,可以采用负载均衡技术将业务请求分发到多个服务器上,避免单点故障。同时,可以使用分布式数据库、缓存等技术提高系统的可用性。
网络冗余:在网络层面,可以采用多链路负载均衡技术,确保在某个链路出现故障时,其他链路能够正常传输数据。此外,还可以部署异地多活数据中心,实现数据的实时同步和备份。
二、备份方案
数据备份:定期对业务集群中的关键数据进行备份,包括数据库、配置文件等。备份数据应存储在安全可靠的地方,如离线存储介质或云存储服务。同时,需要制定数据恢复计划,确保在发生数据丢失或损坏时能够及时恢复。
系统备份:对业务集群的操作系统、应用程序等进行定期备份,以便在系统出现故障时能够快速恢复。
快照备份:利用虚拟机管理平台(如VMware、OpenStack等)提供的快照功能,定期对虚拟机进行快照备份,以便在发生故障时能够快速恢复到某个时间点的状态。
三、监控方案
系统监控:对业务集群中的服务器、存储设备、网络设备等进行实时监控,包括CPU使用率、内存使用率、磁盘空间、网络流量等指标。当监控指标超过预设阈值时,发出报警通知运维人员进行处理。
应用监控:对业务集群中的应用程序进行实时监控,包括响应时间、错误率、吞吐量等指标。通过监控应用的性能状况,及时发现并解决潜在问题。
日志监控:收集业务集群中的系统日志和应用日志,进行实时分析,以便发现异常情况并进行处理。同时,可以将日志信息存储在集中的日志管理系统中,方便后续分析和审计。
实现业务集群的高可用性,需要采取一些关键策略和方法。首先,高可用集群的设置是至关重要的,它可以在当前服务器出现故障时,将该服务器中的服务、资源、IP等转移到另外一台服务器上,以保障业务的持续性。
进一步地,实现自动侦测(Auto-Detect)故障、自动切换/故障转移(FailOver)和自动恢复 (FailBack)也是不可或缺的环节。通过集群各节点间心跳信息,可以判断节点是否出现故障;当有节点(一个或多个)和另外节点互相接收不到对方心跳信息时,就会启动故障转移机制。
此外,为了减少停机时间和服务中断,建立稳健的生产系统是首要任务。对于基础架构来说,实现高可用性是降低系统出现问题的影响的有用策略。而在设计架构时,我们一般会采用分层的思想将一个庞大的 IT 系统拆分成为应用层,中间件,数据存储层等独立的层,每一层再拆分成为更细粒度的组件,让每个组件对外提供服务。要保证架构的高可用,就要保证架构中所有组件以及其对外暴露服务都要做高可用设计。
最后,根据搭建的方式和集群的特性,选择合适的集群模式也是实现高可用性的重要手段。例如,Redis集群的哨兵模式和Cluster模式,都可以在节点发生故障时,自动进行故障转移,保证服务的持续可用。
实现业务集群的高可用性,主要有以下一些方法:
负载均衡:将请求分发到多个服务器上,避免单一服务器的过载和崩溃,保证服务的持续运行。
集群:在多台服务器上运行相同的应用程序,形成一个集群。当一台服务器出现故障时,其他服务器可以接管其工作,确保业务的正常进行。
Session共享:通过使用像terracotta或memcached这样的工具,实现session的共享,防止单点故障影响整个应用。
主从切换:当一台机器服务宕机后,能够迅速切换到其他可用服务器,从而满足业务的持续性。
自动侦测、故障转移和恢复:通过设置集群各节点间的心跳机制,实现自动侦测故障、自动切换/故障转移和自动恢复。
监视和扩展:设置监控系统实时监控整个集群的性能和健康状况。根据负载情况和性能指标,可以动态地扩展集群规模,增加服务器节点数量。
实现业务集群的负载均衡,通常需要依赖于一些特定的技术和工具。目前最常见的负载均衡技术方案主要有三种:基于DNS负载均衡、基于硬件负载均衡和基于软件负载均衡。
基于DNS负载均衡是一种非常直观的实现方案,用户在访问域名时,会向DNS服务器解析域名对应的IP地址,这时可以让DNS服务器根据不同地理位置的用户返回不同的IP,以此实现地域上的流量均衡。
硬件负载均衡性能优越,功能全面,但价格昂贵,一般适合初期或者资金充足的公司长期使用。而基于软件的负载均衡如Nginx、LVS、HaProxy等,由于其价格相对较低且功能强大,因此在互联网领域得到了广泛的应用。它们都是通过在多台服务器之间分配任务,以达到负载均衡的目的。
另外,从应用场景上来说,常见的负载均衡模型有全局负载均衡和集群内负载均衡。全局负载均衡一般通过DNS实现,通过将一个域名解析到不同VIP,来实现不同的Region调度能力。
总的来说,每种负载均衡方法都有其适用的场景和优势,需要根据实际情况进行选择和使用。
业务集群的容灾备份,是通过在异地建立和维护一个备份存储系统,利用地理上的分离来保证系统和数据对灾难性事件的抵御能力。容灾是为了在遭遇灾害时能保证信息系统能正常运行,帮助企业实现业务7*24小时连续性的目标,而备份则是为了应对灾难来临时造成的数据丢失问题。
根据备份系统的地理位置,可以分为本地备份异地保存、远程磁带库与光盘库、远程关键数据+定期备份、远程数据库复制、网络数据镜像、远程镜像磁盘等六种方式。例如,混合云灾备解决方案,可以为客户提供多云以及跨云的容灾备份能力,满足企业业务部署、数据保护和管理的综合策略,实现“多云备份,云上容灾”的多重基础保障,有效提高企业业务连续性,保障关键数据安全可靠。
另外,从灾难恢复的角度来看,灾难恢复是一个在发生计算机系统灾难后,在远离灾难现场的地方重新组织系统运行和恢复营业的过程。灾难恢复的目标一是保护数据的完整性,使业务数据损失最少甚至没有业务数据损失;二是快速恢复营业,使业务停顿时间最短甚至不中断业务。
实现业务集群的性能监控,需要使用专门的工具和技术对集群的软硬件设施、网络通信、应用程序等进行全方位和实时的监测和管理。以下是一些常用的工具和技术:
Prometheus:这是一个开源的系统监控和报警工具,可以收集各种指标数据,并通过可视化的方式展示出来。Prometheus的主要特点包括多维数据模型、灵活的查询语言以及不依赖分布式存储等特点。
Grafana:这是一款开源的数据可视化和监控工具,常与Prometheus搭配使用,用于将收集到的各种指标数据以图表的形式展现出来,方便管理员进行性能分析和决策。
Alertmanager:这是Prometheus中的一个组件,主要用于处理告警信息。当收集到的指标数据超过预设的阈值时,Alertmanager会发送告警通知,帮助管理员及时发现并解决问题。
自建 Flask exporter:这是一种自定义的工具,可以从Cloudera Manager的API中取出各种需要监控的Metrics,然后通过Alertmanager对需要的metrics进行告警。
腾讯云 TDMQ(Tencent Distributed Message Queue):这是一种分布式消息中间件,具有高性能、高可靠、高可扩展的特点,适用于大数据、流计算、在线游戏等多种场景。
Zabbix:这是一种企业级的开源监控软件,支持多种监控方式和数据采集方式,可以满足不同企业的监控需求。
通过这些工具和技术的综合应用,可以有效地对业务集群的性能进行监控和管理,确保业务的稳定运行。
实现业务集群的日志监控,需要使用专门的工具和技术对集群中各种应用程序、系统和服务的日志进行全方位和实时的收集、分析和报警。以下是一些常用的工具和技术:
ELK Stack:这是一套开源的日志管理解决方案,由Elasticsearch、Logstash和Kibana三个组件组成。Elasticsearch负责数据的搜索和分析,Logstash用于数据的采集和处理,Kibana则用于数据可视化。ELK Stack提供了强大的日志管理和分析能力,可以满足不同规模的日志监控需求。
Fluentd:这是一种开源的数据收集器,支持多种数据源和输出插件。Fluentd可以与各种应用程序、系统和服务集成,用于收集、处理和传输日志数据。Fluentd具有良好的扩展性和灵活性,可以根据实际需求进行配置和定制。
Prometheus:除了作为监控系统,Prometheus也可以用于日志监控。通过自定义Exporter,Prometheus可以收集各种格式的日志数据,然后通过Alertmanager对需要的日志进行告警。这种方法可以实现对业务集群日志的实时监控和异常检测。
Sidecar方式部署日志agent:为了提高日志的采集效率和灵活性,可以在每个POD(Kubernetes中的最小部署单元)旁边单独部署一个日志agent。这个agent只负责一个业务应用的日志采集。虽然这种方式相对资源占用较多,但灵活性以及多租户隔离性较强,适合大型的K8S集群或作为PAAS平台为多个业务方服务的集群使用。
OpenObserve:这是一种开源的日志管理工具,可以为在生产环境中有效管理日志数据提供灵活且经济有效的解决方案。
实现业务集群的安全监控,需要使用专门的工具和技术对集群中的各种安全威胁进行全方位和实时的监测和管理。以下是一些常用的工具和技术:
Zabbix:这是一款强大的网络监控工具,可以监控各种网络参数以及服务器的健康性和完整性,包括硬件和软件的安全状态。Zabbix提供了灵活的通知机制,可以在检测到安全问题时立即通知管理员。
Prometheus:除了作为通用监控系统,Prometheus也可以用于安全监控。通过自定义Exporter,Prometheus可以收集各种安全相关的指标数据,然后通过Alertmanager对重要的安全事件进行告警。这种方法可以实现对业务集群安全威胁的实时监控和快速响应。
ELK Stack:这是一套开源的日志管理解决方案,由Elasticsearch、Logstash和Kibana三个组件组成。Elasticsearch负责数据的搜索和分析,Logstash用于数据的采集和处理,Kibana则用于数据可视化。ELK Stack可以用于监控和分析安全事件,帮助管理员及时发现并应对安全问题。
Nagios:这是一种开源的网络监控工具,可以监控服务器、路由器、交换机等网络设备的状态和性能。Nagios具有强大的扩展性,可以通过安装各种插件来监控各种不同的设备和服务。
Grafana:这是一款开源的数据可视化和监控工具,常与Prometheus搭配使用,用于将收集到的各种指标数据以图表的形式展现出来,方便管理员进行性能分析和决策。
通过这些工具和技术的综合应用,可以有效地对业务集群的安全状况进行实时监控和管理,确保业务的稳定运行。
实现业务集群的自动化运维,需要使用专门的工具和技术对集群的安装、部署、监控、发布、升级、安全管控、优化和数据备份等环节进行全方位和实时的自动化管理。以下是一些常用的工具和技术:
自动化运维平台:这是一种集成了多种自动化运维工具的平台,可以满足业务增长需求,实现降本增效、高效管理的目标。常见的自动化运维平台有Ansible、Puppet、Chef等。
容器编排工具:Kubernetes是一种开源的容器编排工具,可以实现业务的自动化部署、扩展和管理。蚂蚁金服分享了他们如何自动化运维大规模的Kubernetes集群的实践。
自动化测试工具:Jenkins是一种开源的持续集成工具,可以实现代码的自动构建、自动测试和自动部署。与自动化运维平台结合使用,可以实现全流程的自动化运维。
自动化监控工具:Prometheus是一种开源的监控系统,可以收集各种指标数据,并通过Alertmanager对重要的事件进行告警。这种方法可以实现对业务集群状态的实时监控和快速响应。
自动化发布工具:Jenkins与GitLab CI/CD可以结合使用,实现代码的自动构建、自动测试和自动部署,形成一套完整的自动化发布流程。
通过这些工具和技术的综合应用,可以有效地提高业务集群的运维效率和质量,降低运维成本和风险。然而,需要注意的是,自动化运维是一个复杂的体系,涉及到从开始的需求分析、设计到落地以及后续的运营整个过程。因此,在进行自动化运维时,需要根据具体的业务需求和技术条件,合理选择和使用各种工具和技术。
评估业务集群的冗余、备份和监控方案的效果,需要使用一系列的指标和方法。以下是一些常用的指标和方法:
RPO(Recovery Point Objective):RPO是指业务系统所允许的灾难过程中的最大数据丢失量,这是一个灾备系统所选用的数据复制技术有密切关系的指标,用以衡量灾备方案的数据冗余备份能力。
RTO(Recovery Time Objective):RTO表示业务系统从灾难中恢复到正常运行所需的最长时间,这是衡量业务恢复速度的重要指标。
计算资源占用率:评估集群需要执行多少任务,包括实时任务、离线任务、算法模型等,一般实时任务占用的资源都是固定的,可以根据业务个数估算。离线任务可以根据ETL任务数和任务资源配置情况估算,计算资源离线和实时同时启用的时候不能超过资源90%。
性能指标:可以通过监控Kubernetes集群来深入了解集群的运行状况和性能指标、资源计数以及集群内部情况的顶级概览。
容灾级别:按照容灾系统对应用系统的保护程度可以分为数据级容灾、应用级容灾和业务级容灾。数据级容灾仅将生产中心的数据复制到容灾中心,在生产中心出现故障时,仅能实现存储系统的接管或是数据的恢复。容灾中心的数据可以是本地生产数据的完全复制,也可以比生产数据略微落后,但必定是可用的。基于数据容灾实现业务恢复的速度较慢,通常情况下RTO超过24小时,但是这种级别的容灾系统运行维护成本较低。
处理业务集群的故障和异常情况,需要遵循一些特定的方法和流程。首先,一旦发现故障,要迅速确认并把上下游用户及项目负责人、部门负责人都加入进来,简要整理下内容,告知用户当前情况及解决预案或方案,不要给用户感觉突然或带来惊讶,让用户有心理准备,留好buffer时间做好应对措施。
其次,定位故障来源是解决问题的关键步骤。收集调用异常或错误信息 (如接口请求响应时间、接口调用QPS、返回错误内容或code) 从错误信息确认边界,是用户使用问题,还是集群服务运行异常。此外,对数据库的负载、慢查询、连接数等进行监控;对缓存的连接数、占用内存、吞吐量、响应时间等进行监控;对消息队列的生产/消费时间、吞吐量、负载、堆积情况等进行监控;对存储的写入时间、TPS、读取QPS等进行监控,这些都可以帮助我们更好地定位和解决故障。
然后,根据问题的严重程度和紧急程度,制定相应的解决方案和优化措施。例如,可以通过监控“拎大头”,找出消耗资源巨大的任务,通过业务,计算引擎,参数调优来优化集群资源使用,提高集群算力。若涉及到Dockerd的问题,可以检查Dockerd的状态、日志、配置等是否存在异常,并进行相应的处理。
最后,在解决问题后,需要总结经验教训,对故障处理过程进行复盘和反思,以便在未来遇到类似问题时能够更加迅速和有效地解决。
实现业务集群的高可用性,需要借助一系列的策略和技术。首先,可以通过冗余设计来实现,即通过增加服务器、网络和存储设备等资源,以确保在某个组件出现故障时,其他组件可以接管其工作,从而保证业务的连续性和可靠性。
其次,负载均衡技术也是非常重要的一环。它可以根据实际的负载情况,将流量分配到不同的服务器上,以避免某台服务器过载而影响整体性能。这有助于提高集群的可扩展性和容错能力。
此外,数据备份和恢复机制同样不能忽视。定期对数据进行备份,可以在发生数据丢失或损坏时,迅速恢复数据,减少损失。同时,也需要建立完善的监控体系,实时监控系统的运行状态和性能指标,及时发现并处理潜在的问题。
在虚拟化技术方面,例如使用VMware提供的虚拟基础架构解决方案,可以使服务器不再需要随着业务增加而添加,只有当整体资源出现不足的时候,才需要增加服务器。这样不仅使IT基础架构能得到有效控制并可充分发挥效能,同时也极大地简化了系统资源的添加过程。
业务集群的备份策略主要有以下几种:
即时备份:面对数据频繁变动的情形,“即时备份”能够迅速地提供保护,确保关键数据在关键时间点的完整性得以保持。
定期备份:这是一种按照预定的时间间隔进行的备份方式,无论数据是否发生变化,都会进行备份。这种策略有利于保证数据的完整性和一致性,但可能会消耗较多的存储资源。
实时备份:在数据发生变化时立即进行备份,可以最大程度地保护数据的完整性,但同时也会增加系统的负载。
增量备份:只备份自上次备份以来发生变化的数据,相比全量备份,可以节省存储空间和网络带宽。
差异备份:备份自上次全量备份以来发生变化的数据,相比于增量备份,恢复速度更快。
对于Kubernetes集群来说,定期备份集群配置也是十分重要的一环,这有助于保证数据持久性和业务连续性。同时,velero等工具提供了强大的备份和恢复功能,如通过命令行指定恢复指定备份或恢复备份中的所有资源。此外,一些专业的备份管理工具如ManageOne还提供了包括备份配置、备份策略和任务列表等功能。
监控业务集群的运行状态是确保其稳定和高效运行的重要环节。目前,市面上有多种优秀的开源和商业工具可供选择,如Prometheus、Zabbix、KubeSphere等。
Prometheus是一个由SoundCloud构建的开源系统监控和报警工具,它的主要特点包括多维度数据模型、强大的查询语言以及灵活的规则引擎。通过Prometheus,我们可以获取到各种详细的性能指标,如CPU用量、内存用量、磁盘用量等,从而对集群的运行状况有全面深入的了解。
Zabbix是一款能够监控各种网络参数以及服务器健康性和完整性的软件,它使用灵活的通知机制,允许用户为几乎任何事件配置基于邮件的告警。此外,Zabbix还提供了出色的报告和数据可视化功能,帮助我们更好地理解系统的运行状况。
对于Kubernetes集群来说,我们还可以通过KubeSphere来监控集群中各种服务组件的健康状态。当关键组件发生故障时,KubeSphere的监控机制会将所有问题通知租户,以便快速定位问题并采取相应的措施。
除此之外,对于特定的应用集群,如elasticsearch集群,我们还可以查看主分片和副本分片的分配情况来确定其健康状态。
总的来说,选择哪种工具进行业务集群监控主要取决于具体的业务需求和技术背景。无论选择哪种工具,定期检查和分析监控数据都是保证业务集群稳定运行的重要步骤。
处理业务集群故障的流程一般包括以下几个步骤:
故障发现:用户部门主动反馈,使用集群服务超时或接口调用报错;或者服务负责部门自行发现,通过系统报警发现大数据服务出现异常。
故障确认:收到报警信息后,我们需要进一步验证集群是否正常提供服务,确认的同时通知用户我们正在跟踪处理,让用户放心。确认故障的过程中,可以通过检查各项系统监控指标以及集群监控指标来进行。
故障处理:在服务离线后,进行重启、维修操作,并轮询机器状态,直至重启成功或维修完成。然后执行环境初始化,保证机器环境符合业务需求。最后恢复服务,检查服务达到可服务状态。
故障预防:针对常见的问题和痛点进行优化和改进,例如定期对机器进行“摸底排查”,减少过保和无人跟进处理的机器,避免资源浪费严重。同时,需要建立完善的监控系统和报警机制,及时发现和处理潜在的问题。
保障业务集群的数据安全,需要采取多层次、全方位的保护措施。首先,加强访问控制是至关重要的一步,确保只有经过授权的人员能够访问和操作数据。这可以通过使用强密码、多因素认证等方法来实现。
其次,数据备份也是保持数据完整性和安全性的基础。在开始集群迁移之前,务必先对数据进行备份。同时,在迁移过程中,确保源集群和目标集群中的数据保持同步。
此外,应用密码技术对影响业务运营的核心重要数据进行保护,实施资源级细粒度的身份认证和访问控制,防止外部黑客攻击以及内部的非授权人员访问带来的业务数据安全风险问题。
在分布式集群中,由于数据和资源分布在不同的机器上,因此需要采取特殊的措施来保证线程安全。例如,可以使用锁机制,它是分布式系统中常用的同步机制,能够保证在并发环境中数据的正确性和安全性。
最后,我们还需要从合规要求和技术手段两个方面来保障整个数据的安全。一方面,要检查数据的采集和保护是否符合相关规定;另一方面,需要具备检测和监测能力,以实时掌握数据安全状况并预警潜在的风险。
优化业务集群的性能需要从多个方面进行考虑和操作。首先,硬件层面的优化是基础,包括采用高性能的服务器、存储设备和网络设备等。同时,软件层面的优化也至关重要,比如对 Kubernetes 集群的一些关键组件进行调优。
例如,对于 Kubernetes 集群来说,我们可以对 etcd、apiserver 等核心组件进行优化。具体来说,对于 etcd,可以采用本地 SSD 盘作为后端存储,独立部署在非 k8s node 上,以及将快照 (snap)与预写式日志 (wal)分盘存储。对于 apiserver,可以调整其参数 --max-mutating-requests-inflight 和 --max-requests-inflight,以达到流控的效果。
此外,我们还可以进行业务层面的优化。例如,如果业务涉及到大量的数据删除操作,我们可以考虑将这些操作放入夜间进行,以减少对系统性能的影响。
最后,我们还可以通过使用负载均衡技术来提高集群的处理能力。通过将请求分发到多个节点上,可以有效地分散系统的压力,从而提高整体的服务效率和可用性。
业务集群的容量规划是一个综合性的过程,需要根据业务需求和系统性能,包括用户量、数据量、并发量等指标,合理规划和配置系统资源。这个过程主要包括三个子流程:业务容量管理,服务容量管理,以及IT组件资源容量管理。
在业务容量管理中,我们需要侧重于组织未来业务对IT服务的需求,让业务需求在制定容量规划时得到充分考虑。服务容量管理则侧重于现有的IT服务品质能否达到服务级别目标。而IT组件资源容量管理则侧重于IT基础架构中每个组件的能力和使用情况,并确保IT基础架构的能力足以支持服务级别目标的实现。
对于集群中产生的数据,可以按照业务中间数据、临时数据、集群的系统日志、集群的预留空间安全系数等来进行规划。例如,业务中间数据和临时数据会分配一定的空间比例,对于集群的预留空间安全系数可以按照当集群的总体规模使用达到80%就需要进行横向扩展。
在进行容量规划时,我们还需要关注系统的最大负载状态,比如服务器CPU使用率达到100%,内存使用达到最大值,磁盘IO延时超过所能接受的最大时延,磁盘使用率超过最大限制等。只有通过这样的方式,我们才能确保系统的处理能力能够满足业务的需求。
业务集群的容灾和迁移是两个相互关联的重要环节。首先,我们需要明确容灾是以业务为中心,多采用单元化架构,基于单元间的两两互备实现,根据单元的部署位置可以实现异地多活。例如,最为稳固的、保护等级最高,也是成本最高的容灾方案,即“两地三中心”:本地的生产中心和灾备中心相距100km以上,进行应用级或业务级容灾保护,且在 300km 以外的异地建立灾备中心,进行数据级或应用级容灾保护。
其次,对于数据迁移来说,跨集群数据迁移是一个常见的需求。例如,一个运行了较长时间的ES集群,因为物理设备老化,需要把数据迁移到一个使用新机器搭建的ES集群中。
在进行业务集群的容灾和迁移时,我们需要注意以下事项:
业务集群的管理和维护是一个复杂的过程,需要关注硬件、软件、网络等多个方面。在硬件层面,可以通过CRT, xshell等批量连接主机,发送命令到所有窗口执行脚本,或者自己编写自动化脚本实现ssh免密钥登陆,根据主机名匹配批量执行管理。此外,还可以使用ansible, saltstack等批量管理工具。
在软件部分,维护工作主要涉及到任务调度和资源调度。任务调度是指根据任务的优先级和资源需求进行任务分配,而资源调度则是根据各节点的负载情况合理分配资源。同时,需要进行资源管理和成本效率管理,以确保资源的最大化利用并降低成本。
对于网络,我们需要对网络设备进行定期检查和维护,以确保网络的稳定性和安全性。另外,我们也需要制定有效的网络安全策略,以防范各种网络攻击。
除此之外,针对每个集群,需要采集的主要指标类别包括:OS指标(例如节点资源如CPU, 内存,磁盘等的水位以及网络吞吐);元集群以及用户集群K8s master指标(例如kube-apiserver, kube-controller-manager, kube-scheduler等指标);K8s组件(kubernetes-state-metrics,cadvisor)采集的指标。
最后,每个项目都应该有管理流程,保持各个项目之间的流程一致性,并明确了对责任和治理的分配。项目的治理与项目群的治理需要正式地整合起来,确保项目始终与项目群的目标保持一致。
评估业务集群的稳定性和可靠性需要综合考虑多个因素。首先,稳定性是通过一系列手段提前发现问题,力求将问题扼杀在襁褓中;当问题发生时,先于业务感知问题,处理问题,进而将问题影响面降至最小;最后,问题发生后要有复盘,复盘哪里可以改进,以避免再次发生此类事情。
具体来说,可以从以下几个方面进行: