影响系统稳定性的架构设计有哪些？什么是可持续的研发运维流程机制？如何培养团队技术人员的意识和能力？一个技术要素，一个业务要素，分享稳定性建设的实践思考和简要思路。希望对同学们有所启发。1.概况我和我带领的团队负责过很多不同类型的互联网服务系统，比如拥有数十万个应用和数亿流量的云计算平台，年收入近千亿的广告系统，和数亿用户。日火钉钉工作台系统、亿级交易量钉钉行情交易系统、算法线上线下工程系统等相关系统或子系统整体无重大故障，故障次数达到分级级别很小。在适当的水位下可以保证稳定性。以团队技术负责人的角度总结自己的实践思路和稳定性建设的简要思路，为感兴趣的技术同学提供实践指导。我的团队稳定性建设思路包括三大技术要素：良好的系统架构和实现、完善的团队研发运维流程机制、良好的技术同学意识和能力，以及一个业务要素：良好的研发项目管理。2良好的系统架构与实现1架构设计根据不同的系统业务特点、不同的开发阶段（系统规模、团队规模）、不同的系统指标侧重要求等，有很多不同的架构思路和折衷考虑，如存储选择、面向服务的治理、中间件选择、中台系统抽象等。本文简要介绍一些会影响系统稳定性的架构设计要点，以供参考。设计注意事项的具体内容可以自行搜索。消除单点从请求发起端到服务处理返回调用全链路（一个链路只由单个服务器完成）的所有链路都避免单点，使得每个链路使用多个独立的服务器进行分发这样，不同的服务器应根据不同的稳定性要求和成本能力进行规模分布，避免单台服务器挂掉造成单点故障，导致整体服务挂掉的风险。可能涉及的环节包括端到端动态获取资源服务（html&js&小程序包等）、域名解析、多服务商、多区域多机房IP入口、静态资源服务、访问路由层、服务逻辑层、任务调度执行层、依赖微服务、数据库、消息中间件。消除单点策略：在业务逻辑层，多运营商多IP入口、多站点&同站点多机房部署、同机房多机部署、分布式任务调度等策略被采用。在数据存储层，采用数据库分库分表、数据库主从备份集群、KV存储&消息等分布式系统集群多副本策略。具备分布式处理能力，需要考虑单台服务器故障后的自动检测和移除，服务器增删自动同步给依赖方等问题，这里需要引入一些分布式中控系统，比如服务注册和发现系统，配置变更系统等。比如zookeeper就是一个经典应用到这个场景的分布式组件。数据一致性经过分布式处理和微服务后，关联的数据会存在于不同的系统中，关联的数据库表、数据存储、缓存等数据会因为架构设计或子系统抖动故障而失效，导致彼此的数据不一致，这也是稳定性失效的一种。最简单的一致性就是关系数据库中更新同一个数据库关联的多个数据表的一致性，可以通过数据库事务和不同的事务级别来保证。从架构层面，数据一致性也会根据业务特点，选择强一致性和最终一致性的架构选择。根据CAP理论，不同的选择也会在可用性和分区容忍度上带来一些折衷。在做好高SLA的基础系统选择、分布式事务中间件的使用、幂等性设计，提升微服务自身的SLA后，根据不同数据一致性级别的要求，考虑触发多系统对账通过消息、Scheduled调度对账、主动消息传递延迟子流程失败后重试、消息消费失败后roundabout重试、scheduled调度扫描失败后数据库记录进程记录状态、离线全对账。不合理的缓存更新机制也很容易导致缓存和数据库之间的数据不一致。一般在更新数据时，考虑缓存删除优先级或者并发更新时采用固定的单线程串行更新策略。在复杂的分布式业务系统或微服务治理之后，基于消息中间件的解耦是一种常用的方法。这时候选择一个保证不重不丢，SLA高的消息中间件就显得非常重要了。迂回重试基本可以保证较高的最终一致性。对于更高的数据一致性要求，可以结合不同层次的协调机制。强弱依赖的梳理和降级当一个服务依赖各种微服务时，避免强依赖（依赖服务挂掉会导致自己的服务挂掉），尽量自动降级对应的服务（弱依赖）或者手动降级对应服务出现问题时，降级后，部分移除依赖的服务功能或进行适当的本地提示，部分体验降级，但不会暂停主要环节和整体功能。对于稳定性要求较好的关键系统，以可接受的成本，维护一套保证主链路可用性的备份系统和架构，如果核心依赖的服务（如如mysql故障、阶段性使用KV数据库等），例如钉钉IM消息核心系统针对一定时期内的数据库核心依赖实现了一套弱依赖记录，可以保证消息收发的可用性在核心依赖数据库出现故障后的一段时间内。强依赖服务越少，系统整体的基础稳定性就越高。部分特殊数据更多地依赖于依赖逻辑的系统。设计去依赖架构也是一个思路。将依赖的服务数据集成到自身服务的数据存储中，通过消息或定时更新的方式进行更新，实现无依赖或少依赖。依赖其他系统可以提高稳定性，但也有副作用：数据冗余可能会导致某个时间窗口内不同程度的数据不一致。热点或极值处理业务规模和部分系统数据规模大、数据热点、数据极度倾斜、少量大客户超限门槛等极端场景会出现在系统中，比如超大的广告物料客户，广告点击显示数据，API调用频率远高于普通客户。如果按客户维度分库分表，物料更新、查询、报表查看等一系列场景可能会造成单库抖动。这不仅会影响到大客户本身。它会影响分布在分库分表上的所有普通客户。电商中的极品爆款和闪购，企业IM中的大型组织群&大型组织涉及全员关注更新行为，微博等订阅明星大V信息发布等是少数可能出现的极端场景造成系统整体稳定性问题。因此，在架构设计时，需要分析系统中是否存在极端场景，并设计相应的解决方案来应对。在极端场景下，不同类型的场景处理架构方案是不同的。可能的方式：将大客户与普通客户分库分表，隔离数据库表，隔离享受独享资源和独立数据库表，拆分路由逻辑，隔离服务逻辑计算资源；大客户特定限额数据计算预留计算预加载，可在非高峰期提前预留或优化；秒杀系统的限值可以考虑核心逻辑精简+消息解耦，拆分同一商品库存的独立交易，部分查询或处理KV存储代替关系存储，数据提前预热加载，队列，限流策略和其他策略；针对大型组织IM场景设计合适的readdiffusion或writediffusion策略，同时针对业务特点（不同的人有不同的延迟）实现不同人员的流畅体验，或者提供专用的计算和存储资源或者专用的查询更新大型组织或大V的逻辑。在无法满足特定限值系统架构和资源的情况下，产品方和技术方必须明确采用最高门槛调用限额。资本交易系统应仔细考虑资本损失的风险。交易系统对数据的准确性、一致性和资金损失非常敏感。这个区域关注的是是否使用缓存，事务一致性的考虑，数据的延迟，数据不丢失。重新复制和准确的数据验证和恢复需要额外的架构设计考虑。仔细评估交易和营销环节的各个环节，评估资金流失的可能性并做好应对设计，如增加多级对账、债券总额度控制、异常额度限额和报警等。资金流失的考量防控等等。不同层次、不同维度、不同时延的对账和预案，是及时感知资金损失、止血的重要有效途径。整个链路的过程数据应尽可能持久和冗余，以方便后续基于过程数据进行验证和数据修复。并根据幂等性原则进行二次消费）。离线数据流是基于数据的搜索推荐、机器学习算法系统、数据产品等，核心功能依赖离线输出或增量输出数据。这类数据可能规模大、来源广、生产环节长。在传输环节，容易出现少量数据丢失，部分环节出现故障，延迟数据生产。最终消费者在线系统也很难感知到少量的数据错误而导致故障。对于离线数据流，需要增加不同传输环节的数据完整性校验、不同生产环节的数据正确性校验、数据延时监控、数据生产故障监控、端到端的数据正确性规则校验、数据错误或延时预案、数据回滚重新刷新工具等机制。机器学习系统还需要考虑离线特征与在线特征数据的一致性，以保证离线训练的模型与在线预测应用效果一致。因此，在模型上线时，定期检查离线和在线特征数据的一致性。其他异常情况处理整个系统架构。除了积极的逻辑、性能、扩展性设计外，还需要加入异常设计视角，详尽思考各种异常情况并设计应对策略。2.容量评估与设计整体系统设计至少要考虑应对5~10倍或近1~3年的系统规模增长。需要通过增加机器资源等快速方式保证系统的横向扩展。例如，分库分表的规模提前设计，避免因临时分库容量不足而临时改造扩容（增加分库分表、修改路由、迁移数据）；服务逻辑层设计持有数据状态，不能添加机器做服务层扩展。互联网产品的发展变化很快，可能不会如期爆发。在容量架构的设计上，也要注意不要提前过度设计，避免提前复杂化带来的研发效率和机器成本等问题。对于在线流量高峰，建议系统正常保持3倍于近期峰值的容量余量。上线前后，要定期进行压测，测高。写流量可通过影子表等方式进行压测，结合线上流量分发和压测，根据压测结果优化架构或扩容，持续保持容量过剩。对于可能超过系统现有容量的突发峰值，限流策略为在线配置的策略。Ingress侧的入口流量调用，不同通道服务的依赖调用，依赖服务的调用，必须评估限额调查的上限，使用中间件等适当的方法限制超过阈值的调用，避免触发雪崩效应。针对具体的业务系统，可以通过消息架构，针对超过峰值的流量进行适当的体验设计，进行削峰填谷。对于恶意攻击流量，还需要考虑部署流量清洗层，在入口层防止DDOS攻击。部分系统峰值变化较大，需要尽可能持续保证负载。可以考虑引入弹性伸缩策略，根据流量变化进行预留或触发系统自动扩缩容，确保以尽可能低的成本自动满足变化的高峰。3运维方案设计系统要考虑持续迭代的发布变更和线上运维需求，做到调光、监控、回滚。灰度可以保证在小流量情况下能及时发现问题，避免造成大范围故障。因此，在对系统进行任何更改时，都必须考虑灰度解决方案，尤其是对于用户流量较大的系统。灰度方法可以包括白名单用户、按用户ID固定划分后的不同流量比例、机器分批发布、业务概念相关的分组比例（如某行业、某产品、某类产品）等.灰度周期必须并且结合系统风险和流量进行适当的设计，重要系统的灰度周期可能会持续一周以上或更长时间。应系统确认监测项目是否完备并及时更新。可能的监控项：错误日志前端js错误、用户体验性能及白屏率、接口成功率、依赖服务成功率、机器基础负载相关监控（CPU利用率、cpuLoad、内存、IO、网络等）)、服务基础监控（端口、进程、状态检测、JVMfullgc、OOM等）、数据库负载监控、数据库请求缓慢、流量同比急剧变化。监控项的告警策略也要根据业务系统和监控项的特点进行设计，如秒级&分钟级告警、错误率告警、错误日志条数告警、连续错误告警等。核心监控可以总结出一个监控面板，一个面板可以快速判断服务的稳定性。回滚：新功能增加配置开关。在线出现问题时，可以通过关闭功能开关快速下线最新升级或一些有问题的功能。针对不同的错误场景，有配置驱动的方案，比如降低对某项服务的依赖，提供适当的功能维护公告，切换到备份服务等。当出现特定问题时，可以快速进行在线止损和恢复。关注release功能提前考虑出现问题时的快速回滚步骤，对于一些频繁release关注回滚步骤。4安全设计数据和应用安全问题一旦出现就可能是致命的，必须加以考虑。安全是一个比较专业的领域。在考虑业务系统经典安全场景的同时，尽量引入专业的安全技术专业的同学来评估。所有资源访问都需要进行适当的身份验证，以避免未经授权的访问；防止Sql注入等攻击，并进行参数合法性校验；资源消耗频率控制，如短信资源等；用户防骚扰，设置用户通知、弹屏等触摸阈值和频率；敏感信息过滤或脱敏等。5高质量的代码实现合适的实现和经典的实践是保证代码质量非常重要的途径。大量的线上问题还是由于少数代码细节考虑不周和经验不足造成的。从这方面考虑，不同的语言会有自己的最佳实践，比如Java，可以参考《Java开发手册》。比较通用的保障手段是分支覆盖完整的单元测试、在线引流回归测试、完整的回归测试用例等测试质量保证措施。三。团队研发运维流程机制的稳定性，涉及所有不同层级的学员，所有系统，研发的所有环节，全天候在线。单个学生无法得到保障，必须建立团队流程机制，确保可持续保障。主要流程机制如下：TechnicalReview：对不同体量设计安排经验较多的同学进行评审，架构师、监理、外聘架构师评审，定期系统整体评审等CodeCodeReview：建立规范和标准，并通过CR认证为合格的学生执行代码审查操作。单测：不同风险的系统设定尽可能高的线路覆盖和分支覆盖标准，复杂逻辑类追求100%分支覆盖。回归测试：持续积累回归用例，上线前后进行回归动作；上线前的引流测试也是一种模拟测试的方式，终端类型的系统也可以使用monkey工具进行随机测试。发布机制：设计发布访问和审批流程，确保每一次在线发布都经过精心设计和审查。线上流程必须分批，灰度，支持快速回滚，线上批量观察（日志确认），在线回归等核心动作。建立发布红线等机制，针对不同系统设计合适的发布周期和发布灰度观察周期。团队告警值班响应机制（告警群、短信、电话）：为确保告警第一时间得到相应人员响应，团队层级可定期进行统计报表，同时建立主管或架构师机制.定期排查上网隐患：定期进行上网排查、错误日志管理、告警管理，确保上网小隐患及时发现并系统修复。例如，钉钉针对企业用户早晚高峰时段的特点，设计了早晚值班机制，用于高峰期第一时间应急响应，专职人员每天抽出一定时间步行通过在线检查。该机制经过钉钉技术团队多年实践，有效发现和处理了钉钉各种线上系统的隐患。用户问题处理机制：VocNissin、周清等。钉钉也经历了从VocZhouqing到Nissin的不断机制改进。在线问题审核机制：在几天和几周内及时审核问题，确保系统和团队针对每个在线问题进行改进。代码质量抽查和审查：定期抽查团队成员的代码，进行评估和审查，鼓励好的代码，帮助改进不好的代码。设立维稳管理专题：适合学生每周做好维稳流程和细化工作。定期压测机制：定期制度化执行，检查线上容量。日常演练机制：预案演练、模拟线上故障的突击演练，提高团队应对线上问题的能力。流程机制应与团队成员共同创建达成共识，并配合主题负责人机制的建立。对流程机制的执行程度和执行效果进行良好的监控和沟通，建立清晰的数字化标准和衡量机制（如钉钉技术团队针对在线问题设置1-5-10标准，在1分钟，5分钟内定位，10分钟内恢复），并建立相应的奖惩机制。流程机制也应根据系统状态进行精简或细化，确保流程机制的可执行性和生命力。4、技术生的自觉和人的自觉最重要，专业能力是可以培养的。如果意识不够、懈怠，再好的能力和机制流程也无用武之地。永远敬畏在线和客户体验。线上化的稳定性和战术可以建立在训练后的专业性和自信上，但在战略上和思想上，还要继续如履薄冰，不断审视自己。在线稳定的保障是作为技术人员对专业的追求，必须保持初心，始终保持敬畏。不因业务繁忙、个人心情、团队是否重视而改变。只要有责任，就必须守着。技术主管和系统负责人要不断感知安全隐患和风险，保持敏锐度、专注力，系统查漏补缺。1团队尊重线路的一些具体表现和要求。每一次报警都不能放过，每一次报警都要及时响应。快速定位、快速恢复是个人和团队专业能力的积累，而快速报警响应则是每个在线用户的恐惧。有经验的技术同学可以做到。在完整持续监控的前提下，及时处理每一个告警，可以缩小故障影响范围，持续减少小隐患。报警的一些实用小技巧：报警根据方向汇聚报警组，建立报警日级值班机制，将报警短信手机设置为振动模式（如果不打扰家人的话）或者同空间的朋友，你会第一时间察觉到），supervisor必须订阅告警作为团队的整体告警处理者，对告警反应好的同学和反应不好的同学在数据。从团队的角度来说，报警的及时响应必须要配合报警管理，否则过多的无效报警也会让负责的同学麻木。因此，必须控制无效告警的数量。例如单个应用（不需要在线问题定位和修复的）无效告警次数不超过5次，个人维度每天无效告警级别不超过10次。在线问题需要审核，不管是不是分级故障，不管问题大小，在线问题一定要审核。复审的准备度可以低于分级故障，但需要思考和反思并实施优化动作。小的在线问题是未来在线故障的前兆。我们每周的团队会议中会有一个链接。如果上周出现线上问题，我们会安排触发人复查。错误日志要注意定期分析在线错误日志，隐藏的问题都隐藏在错误日志中。我们现在的技术团队会有提前值班机制。每个方向都有一个技术生每天走线。以在线发现隐患为导向，走遍监控市场、错误日志、用户反馈。通过这种套路机制，可以很好的防止错误的开发。每一个用户反馈都要重视，一定要定位根源。一个用户反馈背后肯定存在多个实际线上问题，但用户不能忍受，知道反馈路径，对这个产品有喜爱或强烈依赖，才选择反馈。彻底定位一个voc，就是解决一类线上问题。而从用户反馈来看，这个线上问题已经在一定程度上影响了用户体验。我们的技术团队现在有一个voc日清机制，可以在一天之内响应用户在线voc问题，这也是这种意识的一个很好的数字衡量。2.培养个体技术生的个人技能和稳定性保障能力，是团队各项稳定性任务取得成果的执行者和基础。因此，技术主管非常重视识别不同学生的个体优势和劣势，有针对性地进行工作安排和培养锻炼。只要足够重视网络意识，大多数技术类学生的能力是可以培养的。由于入职时间、历史经历等多方面原因，团队中的同学在保障当前系统稳定性的能力上各有优劣。这对于个人来说是正常的，但是对于团队来说，不能因为团队中个别同学的能力不足而引入团队层面的稳定性保障风险。导师需要熟悉和判断学生的能力水平，在责任体系和模块、过程机制约束、导师等方面进行差异化安排。比如学校招收学生X个月不在线发布，前X个月有师兄师姐协同发布机制。高并发或资金交易的系统等高风险的系统，更有经验的负责。同时设计培训机制。目前没有能力但有潜力的同学，可以安排有经验的同学指导，提供一些进阶实践路径，按照由易到难的节奏，逐步承担风险较高的系统职责。能力培养方式包括技术审查、代码CR和辅导，参与团队稳定保障机制，过程中安排合适的资深导师、主管指导，逐步承担更高的职责。在代码层面，对于Java同学来说，《Java开发手册》是很好的实践指南。它超越了代码风格，提供了多种提高代码质量的方法，例如日志、异常处理、集合和其他库的使用、数据库设计和分层设计。在实践中，我们自己团队的所有Java研发同学都将100%通过阿里云上的阿里巴巴代码认证考试。同时团队内部有新的人格代码机制，同时在钉钉技术团队层面有代码会议机制。这是训练学生编写好的代码的好方法。很多小团队、大团队、公司都有很多很好的稳定性提升机制和案例。积极参考学习，结合自己的业务系统思考和实践，是自我提升的重要路径。在架构的高可用和架构相关经典书籍的自学方面，也需要在理论上做系统的认知。网上有很多相关书籍的推荐，例如?、《大型网站系统与Java中间件实践》等，小部分同学在导师和团队的帮助下，在稳保意识和能力方面不断达不到标准并尽可能多地指导。此类同学一定要做好阶段性高危系统隔离和坚定置换工作。负责业务、客户体验、团队其他同学，及时更换他，降低这种稳定性风险。5.良好的研发项目管理从经验来看，线上系统的故障大多是由新的变化引入和触发的。变更是业务和产品的迭代演化，不可能没有变更，但是我们可以对变更的项目进行适当的变更。质量管理，从而有效提高在线稳定性。项目管理的四大要素：工作范围（需求）、时间（交货时间）、质量、成本（人力&机器资源等），简称STQC，这四大要素相互关联又相互制约，形成了项目管理质量管理在铁三角中，一个要素的变化会影响其他要素。因此，要保证良好的质量，就要考虑如何管理其他三个要素。此外，我们可以进一步了解项目成功的要素，关注如何提高真正影响成功的质量。一个成功的项目不仅取决于项目本身从开始到结束的执行过程，还取决于结束前后的过程。努力。一个成功的项目要靠三个阶段的努力：在项目开始之前，要“知道什么是客户成功”，只有客户成功了，项目才能成功；-了解客户的真正需求。能够在项目执行中“为客户的成功负责”，按要求完成承诺的工作。项目结束后，可以“帮助客户实现价值”。只有客户说项目成功了，才是真正的成功。——帮助客户实现商业目标、用户价值目标、商业价值目标。质量管理铁三角互联网产品迭代速度非常快，推崇快速上线、快速试错、快速市场机会。快速交付时间是互联网产品和商科学生对研发团队的显性要求，而交付质量和在线持续稳定是隐性要求。产品业务默认研发团队应该做，但在时间、成本等方面往往没有给出明确的考虑，这就需要研发项目管理的同学主动去评估考虑，有自己的专业判断和坚持。.了解真正的客户需求和交付后客户价值的实现，有助于在四要素冲突时做出适当的选择，确保时间和质量，并以客户价值实现为基础，为业务产品和客户赢得时间和资源，确保质量。从项目管理的角度来看，稳定性保障的基本动作包括：确定并充分了解帮助客户成功的需求范围、控制需求变更、预留质量保证时间、动态控制预期交付时间、争取充足的成本资源比如人力和机器。超前行动：在提前了解、了解甚至参与制定业务战略和战略的基础上，提前规划需求范围和研发节奏&人员构成&结构布局，协助需求选择和优化深入了解业务的基础。
