2022年1 月 4 日9 时，西安一码通又崩溃了。这是半个月内，一码通第二次出现故障。 一方面，软件开发方有责任，开发的系统可用性太差。而另一方面，软件的需求方也需写清楚要求，这也往往是产品经理的工作，具体而言就是定义清楚产品需求、验收标准、违约责任。 否则研发只需一句话——“是产品经理没有定义清楚需求，所以责任不在我”，这就可将责任推掉。而我们如做好这些工作，就能分清责任，明确义务，避免背锅。 这些工作涉及面很广，本文仅探讨其中的非功能需求的部分，也就是产品经理如何定义清楚一码通的非功能需求。 一码通
这本书一直在我的待读列表，但是一直没有机会拜读，直到最近 2021 年已经快要过去，感觉需要在年末提升一下自己。边读边做一下笔记，留待后用。
故障可能发生在网络连接级别（进程之间的消息丢失或传递缓慢），也可能发生在进程级别（进程崩溃或运行缓慢），并且延迟始终不能与故障区分开。这意味着在错误地将活动过程怀疑为已死（产生假阳性）与延迟将无响应过程标记为已死之间进行权衡，这给了它怀疑的好处并期望它最终做出响应（产生假阴性）。
中数据意味着数据体积已经超越单服务器处理的上限，但也无需使用数千台节点组成的集群——通常是TB级，而不是PB级的。这里，我们不妨走进Bloomberg的用例，着眼时间序列数据处理上的数据和体积挑战。 以下为译文 在Bloomberg，我们并不存在大数据挑战。取而代之，系统正在遭遇“中数据（Medium data）”的威胁，而当下许多行业的机构基本上都面临着这种威胁。对Bloomberg来说，在企业级低延时场景下，Hadoop和Spark这样的系统既没有效率，也难以维护。时至今日，高核心数、SSD以及海量内存
首先我接受了一个观点：性能测试是所有性能相关的测试的集合，而压力测试和负载测试就是性能测试的子集。
机器之心报道 机器之心编辑部 登顶 TPC-C 不是靠数据库数量的堆叠，而是一系列技术的创新。 近年来中国数据库蓬勃发展，各种排行榜单不一而足，云原生、Sharding、混合负载等新名词层出不穷。 但盛景之下，各家数据库的技术实力究竟如何？ 日前，OceanBase 研究成果论文《OceanBase: A 707 Million tpmC Distributed Relational Database System》，被数据库国际顶会 VLDB 2022 接收。VLDB 与SIGMOD、ICDE 并称为全球
Hystrix是Netflix开源的一款延迟和容错库，它主要用于处理分布式系统中服务之间的故障和延迟问题。Hystrix的目标是通过提供一种容错机制，以保证分布式系统的可用性和稳定性。Hystrix采用了熔断器模式和隔离模式，使得系统能够在面对高负载、故障和异常情况时能够自适应地进行优化和调整。
TakinTalks稳定性社区发起人。参编《信息系统稳定性保障能力建设指南1.0》和《稳定性保障服务商能力要求》。2017年联合创立数列科技，专注于高可用性领域，为企业提供稳定性解决方案，帮助快速稳定地应对技术挑战。
时间（Response Time）、并发数（Concurrency）和每秒事务数（Transactions Per Second，TPS）都是非常重要的指标。这三个指标为我们提供了系统在特定负载下表现的深入理解。那么，这些指标是什么意思，又如何影响我们的系统呢？我们将在这篇文章中进行深入探讨。
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。
网络安全的工作中自然逃不开应急响应这一茬，很多大型企业、政府、教育、医疗等单位不定期都会出现一些安全风险问题，这时候需要专业的安全服务工程师对系统网站进行安全事件分析及应急处置,对所发现的安全问题提供处理建议。
混沌工程的核心是通过实验的方式来验证系统在稳定下下它的不稳定性，从而通过混沌工程实验的方式来模拟这种情况并给出合理的解决方案，所以它最重要的不是混沌实验，而是实验背后的解决方案。业内最早实践混沌工程的公司是Netfix，混沌工程具体它的定义为：“混沌工程是一门在系统上进行实验的科学，目的是建立系统抵御生产环境中失控情况的能力以及信心”。比如在生产环境中数据库的实例突然瘫痪，云服务器的实例突然消失以及底层服务出现雪崩等等一系列的故障情况下，这个时候整个系统层面需要考虑的是出现这种极端以及很平常的故障下，如何使用技术的手段来保障系统依然能够给客户提供价值从而保障系统的可用性，特别是在分布式架构下服务复杂的调用链以及涉及众多中间件，更加需要考虑在异常的情况下系统的伸缩性和高可用性。
本文部分是我曾经的手稿，今天在草稿箱里面发现，居然没发出去。。。。。 部分是别的大佬的（下面那些实践方案）。
说起性能测试，大家会想到哪些词？录制脚本、模拟高并发？性能需求分析、业务流程梳理？监控资源耗用、性能瓶颈定位？优化代码处理逻辑、提升服务器配置？但这真的是性能测试的本质和最终目的么？这篇文章，聊聊我对软件性能的一些看法和思考。。。
非功能性需求是需求的一个重要组成部分，它影响系统的架构设计，决定软件项目成本的重要依据，在软件项目评估过程中需要重点关注。
（下面很多指标术语在不同的语境下可能会有不同的含义，在评价性能指标时，通常是指他们能够达到的最优值。比如吞吐量是指服务能承受的最大吞吐量。）
前段时间将博客从阿里云迁移到腾讯云，运行一段时间都是正常的，近段时间也没升级和更新wordpress，我发现评论文章后博客卡顿响应时间很长且不跳转刷新页面。
指请求全程所耗的时间，是用户最直观的感受，引起响应慢的问题原因非常多。但不同的功能用户能接受的延迟也是不同的，比如某漫画app的登录功能，用户可以忍受3-5秒，但是漫画翻页如果也3-5秒那么用户多半忍受不了。
原文链接：https://www.adfpm.com/adf-performance-monitor-monitoring-with-percentiles/ 一、前言 在性能监控中什么是最好的度量—
服务器性能监控是监控系统资源的过程，例如 CPU 使用率、内存消耗、存储容量、I/O 性能、网络正常运行时间等。
Redis是一种流行的NoSQL内存数据库，广泛应用于数据缓存、消息队列、实时数据处理等场景。
在保障服务性能的时候，发现除了传统的通过压测发现后台接口性能问题，确保足够的容量供服务使用以外，还需要做许多事情，才能来确保服务的性能达标万无一失。
- 场景：（性能测试）场景是若干个基于 HTTP/HTTPS 的 URL/API 的组合。URL/API 可能关联了数据文件表示不同用户。不同的 URL/API 表示不同的业务含义（比如登录、加入购物车），最终组合成一个接近用户各种真实行为同时具备一定用户量级的压测模型。
系统应用概览是纯理论的部分虽然很简单，但是看完之后发现其实很多时候有一些术语在自己的观念里面是很狭隘的，作者在书中用了更加严谨的解释话语论述一些软件和系统设计中常见的问题。
上周，对性能测试系列专题，在公号内发表了第一篇介绍：【性能系列连载一】开篇：性能测试不可不知的“干货”，但反响貌似并不太好，但既然此前已答应了部分读者要连载分享性能这块的知识，含着泪也得继续写。
基于DNS解析的GSLB方案实际上就是把负载均衡设备部署在DNS系统中。在用户发出任何应用连接请求时，首先必须通过DNS系统来请求获得服务器的IP地址，基于DNS的GSLB正是在返回DNS解析结果的过程中进行智能决策，给用户返回一个最佳的服务器的IP地址。从用户的视角看，整个应用流程与没有GSLB参与时没有发生任何变化。
前面介绍了企业级监控概述及发展等相关的知识点，今天我将详细的为大家介绍 如何做好企业监控系统运维相关知识，希望大家能够从中收获多多！如有帮助，请点在看、转发朋友圈支持一波！！！
抱着一颗学徒的心，本篇就是学习来的。 如果有侵权，私信我也行，下方评论也行，我改成私密。 说实话，这里面随便一个知识点我都要去学。
目前许多的新型应用都属于「数据密集型」（data-intensive），而不是计算密集型（compute-intensive），对于这些应用，CPU 的处理能力并不是第一限制性因素，关键在于数据量、数据的复杂度及数据的快速多变性。
计算机：时钟频率（主频)、运算速度、运算精度、内存的存储容量、存储器的存取周期、 数据处理速率、吞吐率、 各种响应时间、各种利用 率、RASIS特性，即可靠性、可用性、 可维护性、完整性和安全性、平均故障响应时间、 兼容性、可扩充性、性能价格比。
对业务模型进行分析，选择日常请求量大且路径覆盖范围广的典型交易，建立测试业务模型，确定各接口请求量的对比。
轮循均衡（Round Robin）：每一次来自网络的请求轮流分配给内部中的服务器，从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。
业务价值->承载高并发->性能优化。 一切的前提是业务价值需要。如果没有足够价值，那可读性才是第一，性能在需要的地方是no.1，但不需要的地方可能就是倒数第一。当下技术框架出来的软件差不到哪去，没有这种及时响应诉求的地方，削峰下慢慢跑就是了。（但工作中常需要在缺少价值的地方着手性能优化。异步，并发编程，逻辑缓存，算法真的会加剧系统的复杂度，得不偿失。如果没那个价值，简单才是王道）。
高并发，几乎是每个程序员都想拥有的经验。原因很简单：随着流量变大，会遇到各种各样的技术问题，比如接口响应超时、CPU load升高、GC频繁、死锁、大数据量存储等等，这些问题能推动我们在技术深度上不断精进。
大多数测试人员在谈到性能测试时，往往会倍感压力。对于我来说更是如此，想做好性能测试需要庞大的知识体系，不断实践所总结的经验教训更是弥足珍贵。而且每个人对性能测试的理解都有独到的地方，此次逐步揭开性能测试得神秘面纱，结合课堂学习及自身消化理解后的，归纳了一些性能测试的基础知识，希望对大家理解性能测试有所帮助。
其基本原理是，当软件运行出现异常或故障时，将该软件的运行数据存储在一个缓存中，称为“桶”。当这个缓存满了之后，会将其中最老的一部分数据清除，并将最新的数据存入缓存中。
尤其redis这类敏感的纯内存、高并发和低延时的服务，一套完善的监控告警方案，是精细化运营的前提。
“Reaction宣言”文档在2013年发布，它聚焦于：如何在互联网场景中构建健壮可用的应用系统，如何在各种形式的外部访问（事件、关联调用、负载、错误异常）中保证系统的稳定性。
Skywalking发送告警的基本原理是每隔一段时间轮询skywalking-oap收集到的链路追踪的数据，再根据所配置的告警规则（如服务响应时间、服务响应时间百分比）等，如果达到阈值则发送响应的告警信息。 发送告警信息是以线程池异步的方式调用webhook接口完成的，具体的webhook接口可以由使用者自行定义，从而可以在指定的webhook接口中自行编写各种告警方式，比如钉钉告警、邮件告警等等。告警的信息也可以在RocketBot即ui中查看到。
墨菲定律暗示我们，如果担心某种情况会发生，那么它更有可能发生，久而久之就一定会发生。这警示我们，在互联网公司，对生成环境发生的任何怪异现象和问题都不要轻视，对其背后的原因一定要调查清楚。同样，海恩法则也强调任何严重的事故背后都是很多次小问题的积累，当到一定量级后会导致质变，严重的问题就会浮出水面。 那么，我们需要对线上服务产生任何现象，哪怕是小问题，都要刨根问底，对任何现象都要遵循下面问题
在微服务架构中，「雪崩效应」是指当系统中的一个服务由于某些原因（如资源耗尽、异常、延迟增加等）发生故障或性能下降时，这种不良影响会像雪崩一样迅速蔓延到整个系统中的其他服务，导致整个系统的稳定性和可用性急剧下降。
主张：IT组织认为服务器资源不足。服务器提供商说问题出再客户的网络上。双方都没有证据。
具体的指标定义，如：高并发方面要求QPS 大于10万；高性能方面要求请求延迟小于 100 ms；高可用方面要高于 99.99%。
策略规则 Ribbon 提供 IRule 接口，该接口定义了如何访问服务的策略，以下是该接口的实现类：
一般，我们做性能测试的目标是，在大用户量、数据量的超负荷下，获得服务器运行时的相关数据，从而分析出系统瓶颈，提高系统的稳定性。
WinMTR 是一个开源软件项目，在 Windows 中以可视化界面实现了 MTR（Matt's traceroute）。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
