- 博客(192)
- 资源 (3)
- 问答 (1)
- 收藏
- 关注
RSS订阅原创 仅靠别人教永远不够，要靠自己学；活到老学到老不是口号，是生活方式
<think>好的，用户要求根据给定的内容生成一篇不超过150字的文章摘要。内容核心是强调“自学”和“终身学习作为生活方式”，并从多个场景展开落地运用。 摘要需要高度概括原文的关键思想，同时控制字数在150字以内。需要覆盖的核心点有：别人教的局限性、自我学习内化的必要性、终身学习作为生活方式、以及具体场景下的实践要点，最后可以带上自检清单的核心精神。 字数上要精简，不能照搬原文结构，需要压缩成一段连贯的话。考虑到要求是“文章摘要”，风格可以适当体现出内容中的要点，但语气保持客观概括，不需要加入个人评论或额外
2026-09-07 21:55:43
233
原创 几乎所有的进步都 是在放弃部分安全感的情况才有可能获得的 这句话是主观阐述，还是客户陈述
几乎所有进步，都是在放弃部分安全感 的情况下才有可能获得 这句话需要辩证解读
2026-08-27 22:05:06
234
原创 如何解读”你的人生中最沉重的枷锁是什么“
人最大的枷锁，是追求 100% 安全感，害怕不确定，追求立刻确定的结果，放弃成长，把自己困在低风险但没有增量的牢笼里。很多人以为枷锁是贫穷、环境、别人的评价；真正枷锁是：过度追求安全，拒绝局部的不确定性，不愿承担小风险，放弃尝试新可能性。
2026-08-26 22:48:02
203
原创 如何解读《究竟是什么在决定你的价格(估值)》
摘要： 市场价格取决于需求而非努力。个人价值（能力积累）与市场估值（外部出价）可能短期偏离，但长期会趋同。关键行动原则：优先解决环境最需要的痛点，而非自我感动的付出。职场中，边缘业务再努力也难以溢价；个人成长/副业需区分兴趣与真实需求；人际关系价值取决于对方所需。警惕三大误区：混淆付出与回报、将短期低估值等同无能、只做擅长却非刚需的事。自检清单：当前工作核心度、能力痛点匹配性、需求真实性及估值偏差分析。
2026-08-18 22:36:27
198
原创 如何解读李笑来的 “你有没有想过究竟什么是落后”
【摘要】互联网和AI时代加剧了竞争的马太效应，落后的标准从过去的40%后提升到如今的20%后，未来可能1%之外都算落后。核心误区在于人们习惯用身边小圈子作参照（乌比冈湖效应），而实际已进入全球同赛道竞争。资源呈幂律分布，头部玩家通吃大部分收益。应对策略：①职场需在核心技能冲击行业前20%；②投资要建立长期认知体系；③学习须对标顶级成长率；④警惕"比下有余"心态，选择差异化赛道建立单点优势。关键要理解落后是客观统计结果，旨在校准目标而非制造焦虑，重点在特定领域突破而非全维度内卷。（149字）
2026-08-17 23:01:17
198
原创 稳定性质量建设-Logger 框架状态码与业务日志返回的状态码
摘要： 日志框架状态码（ERROR/WARN/INFO）与业务返回状态码（HTTP/自定义code）本质不同，需严格区分。常见误区包括：ERROR日志误判为业务失败、业务失败未触发告警等。规范要求：系统异常用log.error，可预知业务失败用log.warn；监控需同时覆盖日志错误量（系统异常）和业务失败率（核心SLO）。接口日志须包含traceId、状态码等关键信息，避免排查混淆。稳定性建设需双维度配置告警，区分日志级别与业务结果，提升故障定位效率。
2026-08-15 19:26:23
359
原创 稳定性质量建设-Logger 框架状态码与业务日志返回的状态码是否有一回事
本文阐述了日志框架与业务日志的关系及稳定性实践。日志框架（如Logback/Log4j2）作为技术工具提供日志输出能力，业务日志则是带有业务语义的具体内容。二者相互依赖但职责分离：框架负责输出方式，业务代码决定内容。常见问题包括同步日志阻塞线程、大对象打印增加GC压力等。在稳定性保障中，需将日志指标纳入SLO监控，压测验证性能，规范日志级别使用（error记录异常，info记录核心节点），禁止字符串拼接。最佳实践推荐异步日志、MDC埋点traceId、生产环境关闭debug日志，并通过变更管控降低风险。
2026-08-15 19:02:45
410
原创 稳定性质量系列——故障注入（混沌工程）的最佳实践三
本文档聚焦混沌工程高阶实践，旨在推动企业实现规模化、常态化故障注入演练。核心内容包括： 高阶实践前提：要求团队完成基础及进阶演练全覆盖，具备工具能力、闭环机制和全维度监控体系； 四大核心场景： 跨团队协同演练：通过多故障联动验证全链路容错与应急协同能力； 全流程嵌入型演练：将故障注入嵌入研发各环节（开发、测试、发布），提前暴露新功能风险； 智能化演练：基于AI动态识别高风险节点并自动生成故障方案，提升效率与精准度； 生产灰度演练：严格遵循“最小影响”原则，在非核心业务或低流量时段实施。 关键原则：新增“规模
2026-03-01 21:43:17
764
原创 稳定性质量系列——故障注入（混沌工程）的最佳实践二
摘要： 本文聚焦故障注入进阶实践，针对研发团队在复杂场景演练中的高频痛点，提出规范化解决方案。首先强调筑牢基础，规避五大误区：避免盲目追求复杂故障、忽视复盘闭环、监控不全、工具低效及团队协同不足。进阶实践需完成基础验证、监控完善、工具升级等前置准备。核心内容为四类复杂场景演练方案： 多故障叠加：分阶段注入Redis阻塞+接口超时+CPU负载，验证容错与应急能力； 多链路联动：模拟商品服务超时与支付MQ堆积，测试降级策略与防雪崩机制； 极端场景：结合实例宕机与注册中心延迟，验证负载均衡与边界容错； 云原生专项
2026-02-26 23:24:21
828
原创 稳定性质量系列-故障注入(混沌工程)的最佳实践一
摘要：分布式服务架构下的混沌工程实践通过系统化故障注入验证系统健壮性。核心流程包括稳态定义、假设建立、可控故障注入（如CPU满载、网络丢包）和结果验证。重点验证业务链路容错、基础设施弹性、流量治理和监控告警四大维度，需结合ChaosBlade等工具分阶段执行。实施需严格遵循测试环境规范，包括前置方案评审、分阶段故障注入、实时监控和应急恢复，并通过复盘会议持续优化系统架构与应急流程。金融级场景还需关注合规性，确保故障演练既能发现技术问题又能优化运维响应机制。
2026-02-23 23:03:36
872
原创 稳定性质量系列-高可用领域自动化保障体系建设方案二
摘要：本文提出一套轻量化高可用自动化保障体系，以“低成本、快落地”为原则，通过整合开源工具（如Jenkins、Prometheus、SonarQube）构建“1底座+3模块”极简框架，聚焦研发测试、线上运行和故障应急三大核心场景。方案摒弃复杂平台建设，采用脚本化自动处置（如服务重启、扩容熔断）和标准化流程（发布/故障/变更三流程），3-6个月内实现核心业务故障发现100%自动化、常见故障处置≥70%自动化，投入仅为传统方案的1/5。关键避坑点包括避免过度覆盖测试用例、精简监控告警、严格脚本测试等，后续可随业
2026-01-28 22:23:49
793
原创 稳定性质量系列-高可用领域自动化保障体系建设方案一
高可用自动化保障体系建设旨在实现全链路、全生命周期的自动化闭环管理。体系采用"一横三纵"框架，以自动化能力平台为横向底座，支撑研发测试、线上运行、故障管理三大业务域，覆盖稳定性、功能、容量等六大维度。建设分为基础搭建、核心能力建设等四个阶段，通过统一调度、执行引擎等七大核心能力，实现从故障预防到自动处置的完整闭环。体系最终目标是达成预测式保障和自迭代优化，使高可用能力随业务发展持续进化。落地实施采用分阶段推进策略，先核心后全域，确保建设成效。
2026-01-28 21:41:00
1034
原创 稳定性质量系列-高可用架构设计
本文从质量视角探讨系统高可用架构设计。首先指出高可用本质是控制风险，因为人、软件、硬件都非100%可靠，且故障可能带来客户、股东、社会层面的广泛影响。其次提出高可用设计原则：可监控、可灰度、可回滚、可演练、可应急，以及微服务中的少依赖和弱依赖原则。最后详细阐述四大架构设计原则：解耦（隔离核心业务）、冗余（多机房部署）、异构（避免同构故障）、异步（分离核心流程），同时强调避免过度设计，需在成本与可靠性间取得平衡。
2026-01-21 23:14:23
491
原创 稳定性质量系列-系统稳定性建设实践
稳定性建设关键点削峰限流 面对资源上限，做技术、业务层面的处理，达到流量削峰保障服务稳定性；缓存加速 利用缓存解决并发，有效提升系统的吞吐量，同时需注意避免热 Key、大 Key 问题；异步化处理（同步->异步），有效提升响应效率，保障数据的最终一致性。技术服务于业务技术还是要解决实际问题来落地。应用场景很关键，所有的优化工作不要单纯为了技术而技术，技术归根结底还是为应用场景和产业落地服务。可以尝试将业务视角目标做为最终目标，通过一切技术手段来保障目标的达成，从而实现技术价值最大化。
2026-01-14 22:59:39
927
原创 稳定性质量系列-灰度发布
摘要：为解决微服务架构下业务快速迭代与系统稳定性之间的矛盾，企业采用灰度发布方案，通过流量控制实现新版本服务的小范围验证。传统灰度发布存在业务代码侵入性强、调整策略复杂等问题。为此，本文提出基于Istio流量控制协议的灰度发布系统，将流量控制逻辑下沉至基础设施层，支持用户ID和百分比两种灰度规则，实现与运维系统的无缝对接。该系统通过动态路由策略（如5%流量灰度测试）和快速回滚机制，有效平衡了业务迭代效率与系统稳定性需求，显著降低了灰度发布的复杂度和业务影响。
2026-01-12 23:16:52
756
原创 稳定性质量系列-高可用架构设计
本文系统阐述了高可用(HA)架构的设计与实施框架。通过"架构设计-治理机制-风险防范-落地保障"四层体系，实现最小化故障影响、最大化系统可用性的目标。架构设计强调冗余、隔离、降级等核心原则；治理机制包含监控告警、容量管理等持续优化手段；风险防范通过故障演练、灾备建设等兜底措施；落地保障则从组织、工具、考核三方面确保执行。文章提供了可量化的指标体系和分阶段实施路径，强调"先预防后兜底"的实施策略，最终形成可闭环迭代的高可用解决方案。
2025-12-23 23:24:44
1125
原创 稳定性质量系列-架构梳理与治理
架构治理是通过系统性方法提升业务稳定性的质量保障体系。其核心流程包括：1）穿透式梳理业务、技术、资源维度的风险点；2）分层治理（业务降级、服务隔离、资源弹性、变更管控）；3）全流程保障（监控告警、故障演练、应急响应）；4）持续迭代优化。治理需结合组织分工、考核制度及工具支撑，构建"梳理→治理→保障"闭环，最终实现从被动救火到主动防御的转变，形成具备韧性的架构体系。（149字）
2025-12-21 17:05:01
968
原创 稳定性质量系列-强弱依赖识别与治理
摘要：系统稳定性建设中，依赖不合理是引发事故的核心诱因。本文提出强弱依赖治理方案：首先通过业务影响度和可替代性界定依赖类型；其次梳理全链路并形成依赖关系矩阵；然后针对强依赖采用高可用策略（冗余、容灾、隔离），对弱依赖实施灵活性方案（降级、熔断、异步化）；最后通过全链路监控和故障演练保障治理效果。治理需遵循"精准分类+差异化策略"原则，结合组织、制度和工具支撑，实现核心业务"零中断"目标。
2025-12-21 10:29:02
907
原创 性能压测系列五-为什么TPS上不去
摘要：本文针对性能压测中TPS未达预期的问题，提出系统化的排查与优化方法。首先分析TPS影响因素公式（并发用户数、单次事务耗时、系统承载能力），然后从5个维度详细阐述瓶颈排查方向：压测环境问题、业务系统资源瓶颈、应用架构瓶颈、数据层瓶颈和压测方案问题。通过"定位拐点-全链路监控-针对性验证"的三步法则，结合平台工具进行精准诊断。文中以商品下单链路为例，展示了如何通过耗时拆解、网络优化等具体措施，将TPS从12万提升至32万（目标103%）。后续将补充其他维度的案例解析。（150字）
2025-12-17 23:35:38
1200
原创 性能工程系列四-性能产研一体化建设
本文提出构建性能工程效能平台的系统化方案，通过四个关键步骤实现性能工程全流程落地：1）建立产研一体化执行标准，明确各阶段职责与交付物；2）建设集成化平台，整合性能工具与知识库，打通Jira/Grafana等工具链；3）开展场景化知识传播，针对开发、测试、运维不同角色设计实战培训；4）制定分阶段落地路径，从试点验证到全面推广。方案强调通过平台化手段打破部门壁垒，实现性能建模、指标看护和反模式知识的全流程贯通，最终形成"标准-工具-数据-知识"的闭环体系。落地过程注重实际场景验证和持续优化，
2025-12-08 22:33:46
915
原创 性能工程系列三-性能模型与常见反模式设计积累
推广机制的核心 ——“以人为本，以价值为纲”性能模型与反模式的知识化推广，不是 “强推文档”，而是 “围绕人的需求、业务的价值” 设计机制：用 “流程绑定” 解决 “初期不用” 的问题，这里的流程绑定一定不是通过文档来约束，需要达成共识后，通过持续集成平台，如质量保障平台进行初期不用的问题，针对过往项目，可以通过平台，用 “价值可视化” 解决 “中期不愿用” 的问题；
2025-12-03 23:35:31
664
原创 性能工程系列二-性能指标的持续维护模式及知识累积
本文探讨性能工程中监控指标的持续维护机制。通过建立"全生命周期管理+自动化运营+团队闭环"体系，解决监控部署后指标失效、告警麻木等问题。具体措施包括：指标自动化巡检与日报推送、告警优化迭代、数据反哺性能建模、明确团队责任分工与响应流程。最终形成机制化、自动化、闭环化的持续看护体系，确保性能目标长期达标。该方案以订单创建链路为例，实现"性能稳定、资源可控、问题可预见"的工程目标，为后续AI智能诊断提供数据基础。
2025-12-01 23:20:41
687
原创 性能工程系列一 性能压测介入时机(前置介入)
摘要 性能工程的前置介入策略研究指出，传统后置性能测试存在优化成本高、问题定位困难等弊端。通过性能建模和架构设计优化可提前规避风险，如在订单链路案例中，通过推导线程池、数据库连接池等关键配置需求，发现原设计无法满足30万QPS的业务目标。研究提出性能工程应左移至架构设计阶段，建立包含监控告警、快速定位等机制的前置验证体系，通过规则约束降低后期改造成本。核心在于将业务指标转化为技术指标，并验证资源配置合理性，实现从"事后补救"到"事前预防"的转变。
2025-11-23 12:20:28
1099
原创 性能压测系列六-性能测试、负载测试、压力测试关联和区别
第1章 软件性能测试基本概念1.1 什么是软件性能当我们提到软件性能测试的时候，有一点是很明确的：测试关注的重点是“性能”。那么，本书要解决的第一个问题就是：究竟什么是“软件性能”？一般来说，性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软件产品的一种特性，可以用时间来进行度量。性能的及时性用响应时间或者吞吐量来衡量。响应时间是对请求作出响应所需要的
2025-11-10 20:57:06
979
原创 性能压测系列七-聊聊缓存测试
摘要：Redis是一款高性能内存数据库，广泛用于缓存热点数据、分布式锁等场景。文章介绍了Redis的5种数据类型、缓存与DB的交互流程，并详细阐述了缓存设计规范与测试维度，包括功能测试、特殊场景验证（穿透/雪崩/击穿等）、读写并发测试及性能基准测试。最后强调了缓存监控的关键指标，如命中率、资源使用率等。全文系统性地总结了Redis缓存的应用要点与测试方法。
2025-11-10 20:50:16
575
原创 中年打球感受：思考 与 反省
中年球场的生命哲学 不惑之年的篮球场，成了人生的隐喻课堂。不再执着于身体对抗，学会以巧劲化解冲突；拿球停顿三秒的缓冲哲学，让决策更从容；看淡单次得失，明白成败只是人生长河中的涟漪；传球配合的智慧，教会我们共赢的价值；最终领悟到，真正的快乐不在记分牌上，而在奔跑与欢笑的瞬间。这些球场上磨砺出的智慧——不硬碰、多思考、重配合、淡得失，恰是应对人生赛场的最佳策略。
2025-11-09 22:21:43
435
原创 性能压测系列八-压测过程中的连续、递增
在性能工程中，想要明确知道当前业务在现有的生产环境，最高支撑的流量上限水平，就需要我们做如下几项工作：基准工程，容量工程，稳定工程，异常工程；其中基础工程在整个事项工程是最基本的且为必须要做的节点工作，因为在基准工程中，找到系统的BUG,系统配置缺陷，系统性能相关问题是核心目的之一，同时也为容量场景提供可对比的基准数据；
2025-10-26 21:38:14
800
原创 性能压测系列九-性能定位|线上问题定位|重现利器
本文介绍了Arthas工具的常用命令功能，重点讲解了dashboard和thread命令的使用。dashboard命令可以实时监控系统线程CPU使用率、内存状况（包括used、total、max等指标）、GC活动以及Java版本信息。thread命令能够排查高CPU占用的线程，通过示例展示了如何查看最繁忙的3个线程（thread -n 3）和指定线程的堆栈信息（thread [线程ID]）。这些命令为Java应用性能监控和问题诊断提供了有效手段。
2025-10-24 15:09:42
1010
原创 性能压测系列十-并发、在线、TPS
本文探讨了性能测试中并发用户数、在线用户数与TPS（每秒事务数）之间的关系，指出常见的并发用户数计算公式（并发用户数=TPS×RT）存在概念混淆问题。通过实际案例计算不同事务级别的TPS（请求级、业务操作级、用户级），分析了在线用户数与压力线程的转换关系，推导出并发度计算公式。文章强调应根据具体业务场景选择合适的事务级别进行性能评估，并澄清了RPS（每秒请求数）与TPS的争议，指出两者从不同角度反映系统性能且存在必然关联。最后提出性能测试应基于实际业务数据，通过日志分析获取关键参数以准确计算系统负载能力。
2025-10-23 00:02:03
1187
原创 rust 研究系列
rust 中的对象编程rust 不存在类或对象的概念，没有父子继承概念，在面和对象的编程中，如封装、多态、以及代码的复用rust是通过trait和泛型提供的参数化实现多态，其中封装 rust提供了结构体、枚举，使用pub关键字段定义权限访问 的控制文章目录rust 中的对象编程前言一、rust 中的结构体数据二、结构体的定义1.定义结构体2.结构体使用3.结构体对象编程总结前言趁空闲时间，熟悉一下rust语言一、rust 中的结构体数据示例：pandas 是基于NumPy 的一种工具，该工具
2025-10-21 23:42:17
667
1原创 混乱的IT职业生涯
毕业2001~2004年在一所三本专科学校读电子商务，电子商务在那个年代感觉一切都很新鲜，新鲜到这是干什么的，有什么用，学完之后能做什么完全不知道，大学三年的时间除了学习一些基础的电脑课程所占用的上课时间外，其它时间是如何混的现在回想之余朦胧到这么多年是怎么混到现在的地步，基本全是无脸面回忆；从各大博客、各路神仙看看现在的做IT的这些大神，毕业工作5年基本上都是技术大神。毕业参加工作，至今参加工...
2020-06-02 17:28:49
107
原创 质量保障技术要求
首先，可以用TDTIQ能力模型，对自己进行一个简单宏观的评估1.业务成绩(Test)初级：确保顺利上线，没有线上问题中级：控制项目节奏与风险，产品交互开发全面配合调动高级：业务方，产品方高度认可与表扬2.技术能力(Dev)初级：根据代码逻辑设计测试分析，没有遗漏中级：提交bug可以定位到代码，提高效能高级：开发方案提出建议，治未病3.团队贡献(Teamwork)...
2019-04-29 01:04:57
122
原创 垃极收集器监控（一）
一、为什么需要监控j垃极收集数据因为它对应用的吞吐量和延迟有很大影响；二、监控的手段：可以将每次gc的数量直接输出到一个文本文件，对此文件进行分析；成本小 使用gui监控工具进行监控；成本高；三、何时进行垃极收集四、哪些数据需要进行垃极收集？a.当前使用的垃极收集器 b.java堆的大小c.新生代 和 老年代 的大小d.永久代的大小e.minor gc 的持续时间f.minor gc的空间回收量
2016-09-27 00:08:18
1054
原创 Spring 第二天：ioc,di的概念,使用接口配合dj来编程
spring开发提倡接口编程，配合di接口编程，达到解耦;案例创建一个接口ChangeLetter两个类实现此接口把对象配置到spring容器中使用 接口package com.study.interpublic interface ChangeLetter{ private String str; public String change();}实现类UpperLe
2016-09-08 00:28:37
1301
原创 Spring 第一天:spring 概念及简单入门
Spring 第一天的学习spring是什么：是一种框架－》是一种容器框架－》用于配置bean，并维护bean之间的关系的框架什么是bean?* 是java中的任何对象，可以是javabean，也可以是action，也可以是数据源/dao,IOC(控制反转 inverse of control),DI(dependency injection依赖注入)*UML序列图和流程图“`sequ
2016-09-05 20:57:53
1424
原创 以集合思想编写SQL
sql是处理数据的集合，不是处理一行一行的数据，你所编写的SQL不需要你提供如何导航到数据的指令，因为这一项工作是由相关数据库中的后台进行透明地完成。
2015-11-12 15:57:58
1633
原创 性能压测系列十一-根据线程快照分析性能瓶颈四
在继上一节内容后，继续对快照进行分析如何根据快照分析应用中出现的性能瓶颈我们知道，一个项目在增大压力时，系统处理业务能力应是平稳上升，在这一过程中，一般服务器资源的使用率，比如CPU，内存的使用率是平稳上升的，这里的上升是指正常过程中在加压下的上升，排除异常情况下CPU过高或内内存使用率突然上升的情况，如果压力在增加，但系统处理业务的能力上不去，对应的资源使用率不升反而下降，常常对应就是系统处理业务
2015-11-10 11:16:43
7806
TA创建的收藏夹 TA关注的收藏夹
TA关注的人