精华内容
下载资源
问答
  • 反馈系统稳定性与系统转换方程的特征方程的根的位置,以及状态变量形式下系统矩阵的特征值的位置,有着直接的关系。我们将会介绍Routh-Hurwitz稳定判据,这是一个判断系统是否稳定很常用的方法。该方法能帮助我们...

    前言
    闭环系统的稳定性是控制系统设计的核心问题。一个稳定的系统在受到一个有界的输入激励的时候必然有一个有界的输出,这种有界输入——有界输出稳定性是本章主要讨论的问题。反馈系统的稳定性与系统转换方程的特征方程的根的位置,以及状态变量形式下系统矩阵的特征值的位置,有着直接的关系。我们将会介绍Routh-Hurwitz稳定判据,这是一个判断系统是否稳定很常用的方法。该方法能帮助我们给系统设计相关的参数以满足闭环稳定性。对于一些稳定系统,我们将会介绍相对稳定的概念,这能帮助我们定义系统稳定的程度。最后本章通过对光盘驱动系统的控制器的设计,讲解如何基于RH稳定判据设计一个让系统稳定的控制器

    本章目标:
    1.了解动态系统稳定的概念
    2.知道一些绝对和相对稳定性的关键概念
    3.熟悉有界输入——有界输出稳定性的表达
    4.理解s域极点的位置以及状态变量模型特征值的位置与系统稳定性的关系
    5.知道如何构建一个Routh array,并且使用RH稳定判据判断系统是否稳定

    6.1 什么是稳定
    当考虑反馈控制系统的设计与分析问题时,稳定性永远是重中之重。从实际的角度来看,不稳定的闭环系统几乎没有什么价值。但是也有例外,(比如核弹爆炸就不需要稳定性,越不稳定越好。。。)但是没做特殊说明的话我们默认我们的研究对象是稳定的闭环系统。很多物理系统天生的开环不稳定,一些系统甚至被设计成开环不稳定。大多数现代战斗机被被设计成开环不稳定,没有主动控制系统去协助飞行员,飞机是飞不了的。工程师设计了主动控制来使不稳定系统稳定也就是我们刚刚这里所说的飞机,系统稳定之后,一些瞬时响应才可以开始研究讨论。通过使用反馈,我们可以使不稳定系统稳定,然后再通过控制参数的调整使我们的系统最终满足一定的瞬时响应或者稳态响应的性能。而对于开环稳定系统,我们任然使用反馈来调整闭环稳定性能来满足我们对整个系统的控制要求。这些控制要求就包括有:稳态跟踪误差,稳定时间,峰值时间,以及一些4&5章里面讨论的其他性能指标。

    我们可以把闭环反馈系统分成不稳定和稳定两大类,这里面说的稳定我们称之为绝对稳定。一个稳定的系统就可以被称为绝对稳定系统,通常省去“绝对“两个字。但是对于稳定系统里面,我们可以进一步根据稳定的程度进行进一步分类,这种稳定就叫做相对稳定。研究飞行器设计的一线工程师就很熟悉这种分类法——一个飞机越稳定,那么该飞机就越难操控。对于战斗机我们希望它能做一些高难度的机动,就需要其灵活易操控;而商业客机要尽可能的稳,让乘客感到舒适,所以论相对稳定性,战斗机的相对稳定性就要比商业客机低,或者说差一点。正如我们本章即将讨论的,只要满足所有的转换方程极点都在s域的左边,也就是系统举证A的所有特征值都在s域左边,那么我们可以断定一个系统是稳定的。如果所有的极点都在左边,我们再通过研究极点间的相对位置来判断一个系统的相对稳定性。

    下面是稳定系统的定义:如果一个动态系统收到一个有界输入的激励只能得到有界的输出,那么该系统为稳定系统

    稳定的概念可以用一个三角锥来掩饰,如果一个三角锥低朝下摆放,那么一开始它就能处于初始平衡位置,这个就叫做稳定。如果侧过来放,不受外力的情况下,该三角锥也不会动,但是一受外力它就会滚动,这种情况我们称之为中性稳定或者临界稳定。但如果倒着放头朝下,那么一松手三角锥就会倒下,这就叫做不稳定。
    在这里插入图片描述

    动态系统的稳定性也可以这么解释:对于受到一个阶跃或者初始状态的影响,可能会导致一个减少的输出,或者不变的输出,亦或者增加的输出,它们各对应了稳定,中性稳定,不稳定系统的特征。

    系统极点在s域的位置在某种程度上能表明系统的瞬时响应。s域左边的极点引入的是向下的输出,在s域右边或者坐标轴上的极点会导致不变以及向上的输出。下图显示了极点位置与输出的关系
    在这里插入图片描述
    有一个很常见的由反馈带来不稳定的例子,那就是扬声器系统。当一个人对着话筒讲话,它的声音会被话筒放大然后通过扬声器播放出来,如果扬声器和话筒距离很近的话,那么放大后的声音会再次进入话筒被放大,由此往复声音会越来越大。这就是一个正反馈引起的不稳定系统的例子。

    另一个例子如下图
    在这里插入图片描述
    图a是Puget Sound大桥刚通车的图片,人们发现风会很容易的引起大桥摆动,果然四个月之后大桥被大风引起的摆动给摇塌了,图b是坍塌的图片。

    对于线性系统,我们发现稳定条件或许可能与闭环转换方程的极点位置有关。一个闭环系统转换方程如下所示:
    在这里插入图片描述
    此时
    在这里插入图片描述
    方程的根是闭环系统的极点,该系统的冲激响应为
    在这里插入图片描述
    这里的Ak和Bm是由
    在这里插入图片描述
    组成的常量。为了获得一个有界的响应,闭环系统的极点必须都在s域的左半边。因此一个反馈系统稳定的充要条件是系统转换方程的所有极点都在s域左边如果有极点在虚轴上,其他极点都在s域左边,那么稳态输出将会是一个有界的正弦震动,除非输入是一个频率等于虚轴极点根的长度,此时,系统的输出会变得无界。鉴于只有部分信号会导致系统不稳定,因此这样的系统就被称为部分稳定。对于不稳定系统,至少有一个极点在s域的右边,这种情况下,对于任何输入系统输出都会变得无界。

    举个例子,如果一个闭环系统的特征方程为:
    在这里插入图片描述
    这个系统就是部分稳定,如果用一个频率=4的正弦信号激励这个系统,该系统会变不稳定。

    为了搞清楚反馈控制系统的稳定性,我们可以求出特征多项式的根。但是,有没有一种方法可以直观的判断系统是否稳定,而不是通过求出特征多项式的根来求证?有几个方法可以快速回答系统是否稳定的问题:

    1. s域法
    2. 频域法
    3. 时域法
      频域法第九章会讲到,时域法将在6.4节称述。

    如今市场上面的机器人数不胜数,随着机器人能够胜任的工作越来越多,未来机器人的数目也会快速增长,尤其是可以行走的人形机器人。很多通过串联的制动器构成的机器人在1990年代被发明出来,下图所示的M2机器人可以消耗更少的能量,但是相对于其他消耗更多能量的设计更难以保持稳定。
    在这里插入图片描述
    从上图我们可以想象到这个结构在行走的时候本身存在固有的不稳定性。下面我们将会讲解如何通过使用Routh-Hurwitz判据不计算特征方程的根就能判断系统的稳定性。

    展开全文
  • 系统稳定

    千次阅读 2017-03-13 21:28:58
    系统稳定稳定性衡量标准 系统的各项指标相对平稳,不会有很高的突刺。 响应时间 load GC等 IO 系统的错误可以及时发现 平时出现的小问题都能及时发现并及时修复,防止极少成多,集中爆发 依赖梳理 外部系统依赖...

    系统稳定性

    稳定性衡量标准

    • 系统的各项指标相对平稳,不会有很高的突刺。
      • 响应时间
      • load
      • GC等
      • IO
    • 系统的错误可以及时发现
      • 平时出现的小问题都能及时发现并及时修复,防止极少成多,集中爆发

    依赖梳理

    • 外部系统依赖图整理

      • 依赖哪些系统
      • 系统间的交互图
      • 系统稳定性=自身可用率 * 依赖系统1可用率 * 依赖系统2可用率 …. 依赖系统n可用率
    • 对各个依赖进行分析梳理:强弱依赖

      • 依赖的方式: http,tcp等
      • 超时时间: 设置合理的超时时间
      • 强依赖:
        • 失败率&平均响应时间报警配置
      • 弱依赖
        • 失败率&平均响应时间报警配置
        • 降级配置:把该功能关闭
    • 内部依赖
      • 减少循环依赖
      • 系统启动内存初始化依赖
      • 内部的各个调用层依赖梳理: service -> manager -> dao

    代码层次结构梳理

    • 各个主要部件调用都能有较好的抽象,方便统一监控和后续的替换
      • 外部缓存(memcache)
      • 数据库调用
      • 应用内部cache
      • 依赖系统调用
    • 每个请求都生成一串唯一识别码(放入threadlocal中),然后可以在各个适配层打印出调用的上下文
      • 可以方便统计到一个请求对外的调用次数
      • 可以设置开关,方便开启和关闭

    系统主要链路梳理

    • 系统主要逻辑梳理
      • 数据接口
      • 页面
      • 定时任务
    • 然后统计这些业务的调用链路,看能否有优化的空间
      • 会调用几次外部系统请求(数据库,缓存,外部系统等)
    • 核心接口业务配置失败率、响应时间等相关报表和报警

    合理的日志,方便后续线上排查

    • 主要节点地方都需要追加日志,方便后续分析
    • 合理的设置日志级别
    • 设置后门可以动态调节日志级别
    • 可以局部打开日志: 例如特定用户才可以看到等等

    系统的GC分析

    • 分析young gc, full gc的频率
    • 可以分析单词请求大概使用的内存量,并针对性进行优化

    报警机制

    • 增加一些监控报警,可以及时收到相关错误信息
      • 外部依赖报警:失败率高,响应时间长等
      • 主要接口报警:主要接口的响应事情,失败率
      • 定时任务报警:执行失败等
      • 特定关键字报警:例如Exception, 特定的业务打印的严重错误等

    合理的容量预估

    • 单台服务器的qps,总的服务器的总qps

      • 注意有时候 系统总处理能力 != 单台服务器处理能力 * 服务器台数
      • 需要梳理系统的外部依赖,看外部依赖能否抗住
        • 数据库,缓存,外部系统等
    • 分析系统qps的波峰波谷

    • 最好能提前知道系统的流量激增的场景。 例如业务推广等。合理估算外部新增流量

    限流

    • 当流量过大的时候,可以开启并发线程数限制,保证部分请求可用.
    展开全文
  • 坚信 Debian是比Ubuntu更稳定的操作系统   自己用的操作系统是 ubuntu 。现在开始 将系统 弄 到 debian 上面。   觉得 debian 更 好。更稳定。 虽然有 很多的工作要做 但是 还是可以学到不少的东西的。   ...

    坚信 Debian是比Ubuntu更稳定的操作系统

     

    自己用的操作系统是 ubuntu 。现在开始 将系统 弄 到 debian 上面。

     

    觉得 debian 更 好。更稳定。 虽然有 很多的工作要做 但是 还是可以学到不少的东西的。

     

    debian 没有像 ubuntu 一样 把好多的东西都 用图形界面弄好。但是 从 debian 真的是可以学到不少东西。

     

    debian 下面 安装 nginx mysql php 的脚本。

     

    http://code.google.com/p/dnpm/

     

    名字叫 dnpm

     

     

    D- Debian , 最稳定的server版linux系统

    N- Nginx , 最快,最效率的Web Server端软件

    P- PHP , 最广泛的动态语言

    M- Mysql, PHP的黄金搭档,最好的开源数据库之一

    现在用的系统 是 debian + xface 启动 关闭都很快。

     

    展开全文
  • 稳定性全系列(一)——如何做好系统稳定性建设

    千次阅读 多人点赞 2019-12-24 00:49:37
    三、稳定性建设四要素 第一要素:人 第二要素:工具 第三要素:预案 第四要素:目标 四、稳定性建设四个方向 第一个方向:根基要抓牢(45%) 第二个方向:工作在日常(30%) 第三个方向:预案是关键(15%) ...

    目录

    一、背景介绍

    二、故障源的分类

    三、稳定性建设四要素

    第一要素:人

    第二要素:工具

    第三要素:预案

    第四要素:目标

    四、稳定性建设四个方向

    第一个方向:根基要抓牢(45%)

    第二个方向:工作在日常(30%)

    第三个方向:预案是关键(15%)

    第四个方向:容量是核心(10%)

    五、稳定性建设本质

    六、总结


    一、背景介绍

    在移动互联网时代,用户群的积累比之前更容易,但同样,也会因为糟糕的用户体验,而快速流失用户,哪怕是号称独一无二的12306网站,也在不断优化系统来提升用户体验;而在后移动互联网的物联网时代,软件工程师需要和硬件工程师配合,来保证提供的服务稳定和可靠。对,我们的产品就是为了实现用户价值,并提供非凡用户体验!

    如果说良好用户体验是增长的基础,那么良好的操作性、稳定的使用体验就是用户体验的基础,排除掉软件可操作性(这一块需要依靠专业的设计师),剩下的就是客户端(这里的客户端包括各种小程序、WebApp、H5页面等)和服务端,这一切都基于我们软件工程师来构建可靠、稳定的软件系统。 然而,随着我们服务的用户量越来越多,服务复杂度也越来越高,我们的系统为了可维护性,也会在业务架构和系统架构上进行调整,现在流行的微服务架构也因此应运而生。然而微服务架构也并不是没有副作用,例如它会增加维护成本和系统稳定性建设的成本。

    那么,什么是系统稳定性?这里我们引用百度百科的定义:系统稳定性是指系统要素在外界影响下表现出的某种稳定状态。为了方便,本文阐述的系统主要指软件系统。那么如何衡量系统稳定性的高与低呢?一个常用的指标就是服务可用时长占比,占比越高说明系统稳定性也越高,如果我们拿一整年的数据来看,常见的4个9(99.99%)意味着我们系统提供的服务全年的不可用时长只有52分钟! 它其实是一个综合指标,为什么这么说?因为我们在服务可用的定义上会有一些差别,常见的服务可用包括:服务无异常服务响应时间低服务有效(逻辑正确)服务能正常触发等。

    二、故障源的分类

    系统的故障源一般可以分为两大类,一类是人为因素,另一类是自然因素

    常见人为因素导致的故障如下:

    人为因素我们要尽可能的事前(故障发生前)避免,因为这些原因引发的事故很可能会导致数据丢失或错乱、资金受损等较严重后果,而且除了重启或修复后重新上线外没有过多有效的止损手段。人为因素导致的故障往往会导致软件工程师的内心受到严重打击,工作和专业能力受到质疑,造成“人财两空”的后果,“我拼了老命来产出,结果却给自己挖了个坑”是故障责任人内心的真实写照。

    我们再来说说自然因素,自然因素受很多客观因素的影响,往往不受控制,无法避免。

    常见的自然因素导致的故障如下:

    自然原因导致的故障可大可小,虽然无法避免,但由于没有第一责任人,避免了“人性拷问”,软件工程师可以和运维部、安全部的同学协作起来处理故障。

    三、稳定性建设四要素

    “如果事情有变坏的可能,不管这种可能性有多小,它总会发生。”,残酷的墨菲定律预示着我们对自己系统提供的服务不要太乐观,接下来,我们说说如何建设系统稳定性,人为因素的根源一方面是专业能力不足,经验不足,另一方面很多都是无心之失,所以需要通过流程、规范来保住“底线”,减少人为因素导致的故障,而自然因素导致的故障往往具有突发性,需要联合多个团队协作来解决故障。

    稳定性建设四要素工具预案和目标

    第一要素:人

    我们先来说“人”这一要素,它需要回答如下5个问题:

    • 谁应该参与稳定性建设?

    • 如何降低犯错的概率?

    • 如何提高稳定性意识?

    • 如何定责?

    • 如何激励?

    稳定性建设工作需要老板支持,它的实施一般需要开发测试运维安全还有产品等同学参与,而且主导方应该是开发、测试和运维。确定了参与方后,就可以做关键的一步:“参与稳定性建设的每个团队都需要在OKR中背负一部分稳定性指标”,这也是为什么说稳定性建设工作需要老板支持,因为和绩效考核相关。

    稳定性工作,规范先行。OKR的部分只是让各参与方在稳定性方面工作的投入变成合规化,平时如何去参与稳定性建设还得“有迹可循”,对于开发和测试来说就是要根据公司的当前技术体系去建设开发规范提测规范测试规范上线规范、复盘规范等。我们拿和软件开发最相关的开发规范来说,开发规范是对开发人员的要求,让开发人员知道什么是必须要做的、什么是推荐的、什么是应该避免的。通常开发规范至少应该包括如下几个部分:

    编码规范:对外接口命名方式、统一异常父类、业务异常码规范、对外提供服务不可用是抛异常还是返回错误码、统一第三方库的版本、哪些场景必须使用内部公共库、埋点日志怎么打、提供统一的日志、监控切面实现等,编码规范除了能规范开发的编码行为、避免犯一些低级错误和踩一些重复的坑外,另一个好处是让新入职的同学能快速了解公司的编码原则,这点对编码快速上手很重要。这里再重点说一下为什么要统一异常父类和业务异常码,例如虽然不同模块(这里的模块指的是能独立部署的项目)可能有不同的异常父类,比如订单模块的异常父类是OrderException、交易支付模块的异常父类是TradeException,而OrderException和TradeException的父类是BizException(当然BizException是定义在一个通用共公共库中的),而我们也需要去统一异常码,比如200代表正确的返回码,异常的返回码是6位数字(前3位代表模块,后3位代表异常类型),有了统一的异常父类和异常码后,很多切面就都可以由公共库来做了,比如统一的监控、统一的出入口日志打印,统一的异常拦截,压测标识透传、特殊的字段埋点等,千万别小看这些,这些能在未来持续提升研发效率,降低稳定性工作成本。

    公共库使用规范:为了能对通用功能进行定制化改造和封装,公司内部肯定会有一些公共库,例如日志库、HTTP库、线程池库、监控埋点库等,这些库都“久经考验”,已经被证实是有效且可靠的,这些就应该强制使用,当然为了适应业务的发展,这些公共库也应该进行迭代和升级。

    项目结构规范:为了贯彻标准的项目结构,一方面我们需要为各种类型项目通过“项目脚手架”来创建标准的项目结构原型,然后基于这个项目原型来进行开发,统一的项目结构一个最显著的好处是让开发能快速接手和了解项目,这种对于团队内维护多个项目很重要,人员能进行快速补位。

    数据库规范:数据库连接资源堪比CPU资源,现在的应用都离不开数据库,而且通常数据库都属于核心资源,一旦数据库不可用,应用都没有太有效的止损手段,所以在数据库规范里,库名、表名、索引、字段、分库分表的一些规范都必须明确,这里特别提一点,就是分表数量不要用2的幂(比如1024张表,很多人认为使用2的幂分表数在计算分表时用位运算会更快,但这个开销相比数据库操作其实可以忽略),而应该用质数(比如最接近1024的质数应该是1019),采用质数分表数能让数据分的更均匀

    这会引发另一个问题,那就是我们有这些规范,那么如何让开发来知晓和遵守?一方面是设定合理的奖惩机制(例如由于没有遵守规范而引发的线上事故要严惩),另一方面就是——考试!没错,就是考试,将这些规范和历史的线上事故整理成试题,让新老开发定期去考试,考试是一种传统的考核机制,我们可以把规范和公共库的更新部分,也及时加入到考试试题中,来督促大伙及时学习。

    有了OKR、规范和考核机制,加上我们定期宣导,相信各成员的稳定性意识会有显著提高。

    事故定责一般是比较复杂的过程,除非事故原因非常简单明了,但实际上事故原因常常涉及多个团队,如果责任分摊不合理,难免会引发跨团队的争吵,合理的做法是引入第三方稳定性团队来干预,例如滴滴的星辰花团队,星辰花会撰写定责指南,并制定一些相关流程机制。

    当然,如果达成稳定性年度目标,也应该对这些团队进行适当表彰。

    第二要素:工具

    工具意味着手段,要做好稳定性建设,强大的支持工具和平台是不可缺少的,常见的工具和平台包括:日志采集分析检索平台(例如滴滴的Arius)、监控告警平台(例如滴滴的Odin Metrics)、分布式追踪系统(例如Google的Dapper、滴滴的把脉平台)、自动化打包部署平台(例如滴滴的One Experience)、服务降级系统(例如滴滴的SDS)、预案平台(例如滴滴的911预案平台)、根因定位平台(记录所有故障发生前所有系统变更事件)、放火平台等。

    强大的工具能回答如下3个关键问题:

    • 我们能做什么?

    • 我们能做到什么程度?

    • 如何降低稳定性工作成本?

    工具本质上是手段,它能降低我们在稳定性工作上投入的成本,例如有了监控告警平台,我们就不需要专人时刻盯着日志或大盘,有了分布式追踪系统,问题定位会更有效率,有了降级系统,一些故障能自动控制和恢复,不用我们再上线一次。要想做好稳定性工作,工具必不可少,没有工具,稳定性建设总是低效的。

    其实公司内建的公共库也属于工具的一种,像滴滴内部的公共库,业务系统接入Odin Metrics和把脉几乎不要做额外的工作(当然接入把脉需要提日志采集工单,头疼),千万不要吝啬在工具方面的投入,很多开源框架可以拿来用或拿来参考,工具和平台可以内部进行互通和联动,这样可以建成一站式的稳定性工作平台。

    第三要素:预案

    紧急预案是我们在故障发生时的行动指南,这在故障可能涉及到多个团队、故障进展需要周知到多个团队时特别有用。

    完善的紧急预案能回答如下4个问题:

    • 故障发生时我们该做什么?

    • 谁来指挥?

    • 谁来决策?

    • 我们如何善后?

    当一个不那么容易定位的故障发生时,你应该做的第一件事应该是什么?这在不同公司、同一个公司同一个团队的不同成员恐怕都会给出一个不同的答案,而在滴滴内部,我们大多会第一时间通知团队内其他成员、Leader(寻求帮助)和客服、上游业务开发等可能的影响方 (问题周知)。当这一步做完以后,一般就会有一部分同学加入问题排查和止损,然而介入的人多了,排查和止损的效率不一定会成比例的提升,这时候协调者很重要,协调者要避免介入的同学在做重复工作,协调者还需要持续和客服、上游业务开发等影响方沟通(我们曾经就经历过由于问题排查问题进度没有及时有效和业务方沟通,业务方将故障升级的case)。对于排查问题和止损的同学来说,要操作某个开关,有可能还要去查代码看开关的名字是什么,还有可能关掉一个功能需要操作多个开关,这些在紧急时刻都有可能由于慌乱而出错。而且什么条件下才能操作开关,谁能决定应不应该操作开关,恐怕在当时很难去做最正确的事情,而这一切,没错,都应该提前写到预案中!!!

    紧急预案一般要包含如下内容:

    1. 故障发生时应该通知哪些人或团队。

    2. 如何选出协调者,什么情况下该选出协调者。

    3. 协调者的职责有哪些。

    4. 需要操作开关时,谁有权利决策。

    5. 常见故障以及对应的止损方式。

    6. 止损的原则是什么,什么是最重要的。

    7. 善后方案谁来拍板。

    预案很重要,完备的预案能降低故障定位和止损的时间,提升协作效率。

    第四要素:目标

    如何衡量稳定性建设工作是有价值的?如何考核稳定性建设工作达没达标、做的好不好?这些都能在稳定性建设的目标中找到答案。

    稳定性建设的目标主要用来回答如下2个问题:

    • 稳定性工作的价值是什么?
    • 稳定性工作如何考核?

    稳定性建设工作的价值不仅需要团队所有成员认可,更重要的是需要老板的认可,没有老板的认可,稳定性建设工作只是团队内部的“小打小闹”,难以去跨团队来体系化运作。

    稳定性建设工作的年度目标可以拿服务可用时长占比来定,也可以拿全年故障等级和次数来定,像滴滴这边,星辰花将故障等级分成了P0至P5六个等级,P0、P1、P2属于重大事故,是需要消耗服务不可用时长的(根据全年定的服务可用时长占比指标来计算出某个部门的全年服务不可用总时长),一旦年底某个部门的全年服务不可用时长超过年初设定的阈值,就会有一定的处罚,并影响部门绩效(之前达标也有奖励,但后来奖励取消了)。

    这里做一个汇总:

    四、稳定性建设四个方向

    前面我们提到的稳定性建设工作的四个关键点,但对如何落地阐述的并不多,这里结合作者多年的稳定性建设工作经验,谈谈稳定性建设工作的四个方向。

    第一个方向:根基要抓牢(45%)

    稳定性建设工作重在预防,根据作者多年的工作经验,至少6成线上故障都可以在预防工作中消除,我们需要投入45%的精力来做根基建设,所谓根基建设,就是把开发测试上线这三大流程做透!!下面列了几个关键点:

    Code Review:CR其实是一个很重要的环节,当一个开发整个编码和提测都可以自己闭环搞定时,时间一长就容易产生懈怠,这时候写隐患代码的几率会大大提高,CR的过程并不是diss的过程,这个一定要在团队内拉齐,相反,CR是一次很好的团队沟通和塑造自己影响力的机会。我就很佩服那些代码写得质量高并且能把整个流程讲顺的人。我们团队的项目都接入了全流程(例如滴滴的鲲鹏),分支合master必须要其他人Review,但这是“离线”的,没有代码作者讲的过程,效果没有几个人坐在小黑屋讲的好,只是更快而已。我们团队规定,大于等于4人日的项目需要进行小黑屋CR。CR还可以让其他成员来检测该代码实现是否遵循了开发规范,毕竟“先污染后治理”的成本太高,记住,CR一定是一个相互学习的过程

    设计评审:再也没有比糟糕的设计更有破坏力的东西了,设计评审和CR可以放在一起做,先评审设计再进行CR,有人就会说,都编码完了才进行设计评审是不是晚了?其实这要看情况而定,如果团队内部经常产出“糟糕设计”,那么我觉得设计评审就应该编码之前来做,但如果团队成员专业能力和经验都还不错,那么我们允许你再编码之后再做设计评审,而且编码的过程其实也是设计的过程,可以规避提前设计而导致后续编码和设计不一致的问题。设计评审的原则是,既要讲最终的设计方案,也要讲你淘汰的设计方案!

    提测标准:写完代码就可以提测了?当然不是,至少得完成补充单元测试、完成自测、完成开发侧的联调、通过测试用例(如果QA提前给了测试用例的话)、补充改动点和影响点(便于QA评估测试范围)、补充设计文档(对,现在滴滴的QA养成了读代码、看设计的习惯)这些步骤才能说可以提测了。当然,提测标准理论上是QA同学来定义的。

    测试流程:测试的全流程覆盖最好能做到全自动化,很多测试用例可以沉淀下来,用来做全流程回归,当然这需要系统支持。我也见过太多犹豫QA没精力进行全流程回归而导致问题没有提前发现而产生的事故,所以测试的原则是尽可能自动化和全流程覆盖,让宝贵的人力资源投入到只能人工测试的环节。

    上线流程:上线也是一个风险很高的操作,我们简单统计了19年的上线次数,光我们团队负责的系统就上线了五百多次。部署平台需要支持灰度发布、小流量发布,强制让开发在发布时观察线上大盘和日志,一旦有问题,能做到快速回滚(当然要关注回滚条件)。我们这边的做法是先小流量集群灰度(我们把单量少的城市单独做了一套小流量集群),再线上灰度,确保哪怕出问题也能控制影响。

    第二个方向:工作在日常(30%)

    俗话说养兵一日,用兵一时,平日的养兵其实也非常重要,这一方向我们需要投入30%的精力,需要我们做到如下几点:

    人人参与:团队内人人都需要参与稳定性建设工作,稳定性工作不是某个人的事情,所以我会要求所有人的OKR中都有稳定性建设的部分。做toC研发的同学,都养成了带电脑回家的习惯,哪怕是加班到晚上12点,当然在外旅游也带着电脑,手机24小时保持畅通;稳定性已经成为了生活本身。

    持续完善监控告警:监控告警就是我们发现故障的“眼睛”和“耳朵”,然而大多数监控告警都需要我们手动一个个配置,随着业务的不断迭代,会有很多新接口需要添加监控,一些老的监控的阈值也需要不断调整(否则大量告警会让人麻木),所以监控告警是一个持续优化的过程。

    及时消灭线上小隐患:平日发现的一些问题要及时消灭,很多线上事故在事前都有一定预兆,放任平时的一些小问题不管,到后面只会给未来埋上隐患。

    跨团队联动:稳定性肯定不是一个团队的事情,一些降级方案可能涉及多个团队的工作,所以定期的跨团队的沟通会议是很有必要的,要大伙一起使劲才能把事情做好。

    复盘机制:对出过的线上事故一定要及时的进行复盘,通过复盘来发现我们现有流程、机制是否有问题,让大伙不要踩重复的坑,并不断完善我们的紧急预案。复盘虽然属于事后的行为,但很重要,我们需要通过复盘来看下次是否能预防此故障,或者是否能更快的定位和止损。

    会议机制:稳定性周会、稳定性月会,我们通过各种定期的会议来总结一些阶段性进展和成果,拉齐大家认知,这也是大伙日常稳定性工作露出的一个机会,所以非常重要。

    第三个方向:预案是关键(15%)

    我们通常都会忽视预案的作用,因为预案整理起来确实比较麻烦,预案也需要随着功能的迭代而不断更新,否则将很容易过时,而且预案在平日非故障期间也确实没有发挥作用的机会。但我们不得不承认紧急预案相当重要,特别是当我们去定位和止损一个比较复杂的线上问题时。

    我们需要在预案的制定和演练上投入15%的精力,可以从如下三个方面着手:

    分场景制定和完善紧急预案:如果我们还没有紧急预案,那第一步就是分类分场景整理下历史上经常发生的线上事故,例如MySQL故障预案、MQ故障预案、发单接口故障预案等。而且预案有可能会被多人查看,一定要清晰易懂,如果某些预案是有损的,需要把副作用也描述清楚。

    通过放火平台来验证预案:借助放火平台和服务降级系统,我们可以通过主动给主流程服务的非核心依赖注入故障,来验证系统在遇到非核心依赖发生故障时,核心服务是否仍旧有效,如果某些预案无法做成系统自动的(比如某些预案有一定的风险或副作用),也可以在预发环境来验证该预案是否能达到预期效果,防止真正故障发生时“手生”。预案就是在这种不断演练过程中来优化和完善的,这样的预案才是动态的,才是活生生有效可靠的!

    第四个方向:容量是核心(10%)

    我们知道木桶效应,一个木桶能装多少水取决于最短的那块板,在分布式系统中也是如此,我们需要摸到分布式系统中的这块“短木板”才能知道整个系统的吞吐量(容量),如果我们没有这个值,老板问你明年单量要Double,问你要预算,要规划你凭什么给?最准确的容量预估方案就是——线上全链路压测。至于滴滴是如何做线上全链路压测,后续我会有专门的文章来阐述。

    我们继续探讨容量这个话题,我们应该投入10%的精力来摸容量、扩容量、水位预警等。容量也相当重要,根据我的经验,线上有大约10%的故障和容量有关,当遇到这种问题,最有效的解决方案就是扩容!关于容量,我们在日常需要做到如下三点:

    常态化的全链路压测:线上全链路压测必须定期举行,特别的在有大促活动时,也需要提前进行一次。因为随着业务的快速迭代,系统老的瓶颈可能消失,新的瓶颈可能出现,所以之前的全链路压测的结果将失效,我们需要定期去摸这个线上环境的这个阈值。

    定期进行扩容演练:在滴滴内部,我们会定期进行弹性云扩容演练,这在紧急情况下很有用,我们就曾经遇到过弹性云扩容比修改阈值重新上线更快解决问题的case。

    多活建设:我们知道多活主要是为了容灾,但其实多活实际上也从整体上增加了系统容量,所以也属于容量扩充的范畴,一旦某个机房遇到瓶颈,我们可以分流到其他机房。当然多活建设需要一定成本,业务量大到一定程度才需要投入。

    说了这么多,我们也放张图来进行总结:

     

    五、稳定性建设本质

    就像我们做项目要“面向风险”编程一样,系统稳定性建设的目的其实就是为了应对未来的风险,和未来风险做对抗(哪怕我们有些手段将未来的风险变小)。如果非让我们探究稳定性建设的本质,我觉得稳定性建设的本质是将系统和系统间未来不可控的因素逐渐变为可预见,可控的因素,并着手去一一解决的一个过程。

    六、总结

    做稳定性建设一定要结合公司或组织的实际情况,量入为出,最合适的方案才是最好的方案。结合咱们上述讨论的几点,我们可以画出稳定性建设的房子,如下:

    希望我们能像建筑师一样,给业务构建一套稳定、可扩展、性价比高的房子!!!

     

     

    其他稳定性全系列文章:

    稳定性全系列(二)——如何做线上全链路压测 https://blog.csdn.net/manzhizhen/article/details/104439629

    展开全文
  • 一方面以淘宝为例子,传统的 IDC 的时候,我们稳定性是怎么做的,另外在云计算背景下,有很多创业公司是基于阿里云这样的公有云基础设施做研发,在公有云的环境下怎么做好我们系统的高可用。 我的花名叫沐剑,2011 ...
  • 根据bode图判断系统稳定

    千次阅读 2020-02-05 23:51:40
    1、中频段一般是比较关键的,涉及到系统能否稳定等问题。比如如果中频段是-20dB衰减,那么我们希望中频段能够有较大带宽,以保证系统稳定性。 2、截止频率或被称之为剪切频率,wc越高,则系统快速性越好。 3、低频段...
  • 基于系统负载的动态限流组件 dynamic-limiter 背景 动态限流原理 测试效果 总结 基于系统负载的动态限流组件 dynamic-limiter 最早发在了:Qunar 技术沙龙 背景 一个系统的处理能力是有限的,当请求量...
  • 控制系统动态性能分析

    千次阅读 2012-04-01 20:37:36
    控制系统动态性能分析   控制系统动态性能分析   控制系统稳态性能分析   控制系统稳态性能分析     频率特性的基本概念   频率特性的基本概念...
  • 控制系统极点和稳定性之间的关系

    千次阅读 2020-05-03 10:37:40
    理解控制系统稳定性,我们需要深刻理解极点和微分方程的关系。 解微分方程本质上为了得到某个变量随时间的变化量。 微分方程的解往往和指数函数有关系,而指数函数又和周期变化联系在一起,因为欧拉告诉我们,在复...
  • 周期系统及自治系统下关于渐进稳定性的Lyapunov逆定理
  • 动态系统开发方法DSDM

    千次阅读 2019-02-22 09:39:31
    动态系统开发方法(DSDM)倡导以业务为核心,快速而有效地进行系统开发。可以把DSDM看成一种控制框架,其重点在于快速交付并补充如何应用这些控制的指导原则。 DSDM是一整套的方法论,不仅仅包括软件开发内容和实践...
  • 如何保障高并发系统稳定性与高可用 文章来源:企鹅号 - 品质出行技术 要论如何搞垮一家互联网公司,速度最快的不是产品经理的胡乱决策,运营的无休止的烧钱,客服人员对客户的冷漠,一定是系统核心功能持续不可用...
  • 【操作系统 - 4】动态分区分配算法

    万次阅读 多人点赞 2017-03-18 19:58:23
    【操作系统 - 4】动态分区分配算法:学习至此,发现很多学了但很久没用的知识,久而久之,慢慢遗忘。等哪天还需要的话,却发现已经忘得差不多了,即使整理了文档(word等),还是得从头再学一遍。读研第一学期,发现...
  • 稳定系统的充要条件3. 稳定判据(代数判据)(1) Hurwitz稳定判据(2) LIENARD-CHIPARD稳定判据 动态性能介绍 上升时间trt_{r}tr​ 指响应从终值的10%上升到终值的90%所需的时间(亦可定义为响应从0第一次上升到终值...
  • 浅谈系统实现层面稳定性保障

    千次阅读 2021-02-23 16:20:00
    我个人加入阿里之初是在国际支付宝核心团队长期负责金融系统稳定性保障,其后扎根淘系技术三年有余,参与了多种不同类型系统设计与稳定性建设,以及大促稳定性保障工作。对比总结下来无论电商、金融、物流、ERP型...
  • 高性能高并发系统稳定性保障

    千次阅读 2016-12-21 15:50:02
    作者:肖飞,于2011年8月份加入京东,曾亲身参与到京东的应用性能监控、统一日志、流式计算、内存缓存、四层防攻击等一些基础技术平台的研发和搭建工作,经历了京东的技术系统从简单... 性能、并发、稳定性三者关系
  • Web应用架构演进 WEB应用架构演进过程,系统对于性能和稳定性方面需要解决的问题
  • 付钱拉连接30多个通道,有可能A通道支付不成功,这个时候就需要动态重路由到B或者C通道,这样就可以通过系统重路由避免用户支付失败,实现支付容错。 还有针对OOM做容错,像Tomcat一样。系统内存总有发生用尽...
  • 1 引言 机器视觉的研究始于20世纪50年代二维图像的模式识别[1],它起初被设计用来代替人眼从事检测识别的工作,可以大大提高检测的工作效率以及降低人眼疲劳带来的检测结果的不一致性...但机器视觉系统设计的难点在...
  • 马尔科夫跳变系统是一种具有多个模态的随机系统系统在各个模态之间的跳变转移是由一组马尔科夫链来决定的。...然而,这类动态系统可以由马尔科夫跳变系统来精确地描述,所以引起了学者们的广泛研究。
  • 城市遥感动态监测管理系统

    千次阅读 2014-12-08 23:45:46
    1.系统概述  随着全国各城市数字化进程的发展,高分辨率遥感影像和数字航空影像为“数字城市”的建设提供了丰富的数据源。近年来,遥感影像的空间分辨率和光谱分辨率的明显提高,使得高分辨率遥感影像和数字航空...
  • 3. 组织架构与流程是不稳定的,在不停的变化。 无论哪种情况,如果要做企业架构,首先要做的是业务咨询,帮助用户一起做业务架构。有的企业跳过业务架构,直接做IT架构,无源之水,丧失了企业架构的基本目的。 ...
  • 控制系统伯德图 伯德图可分为幅值图和相位图,它们都是以频率为横坐标的,说明系统的幅值和相位由输入信号的幅值和相位决定。在任一w1频率下,系统幅值a大于0。换句话说就是当输入信号频率为w1时,系统对输入信号的...
  • 到综商品系统为了满足不同类目个性化的商品需求、同时保证接入的高效,我们搭建了商品配置中心,在不同层次大量采用了配置化的技术去解决这些问题。 一般而言,软件的配置,包含几个层面:包括数据,功能,流程,...
  •   本文主要介绍如何利用MATLAB解特征方程,并将特征根的分布画在坐标轴上,便于分析系统稳定性    我们知道,一旦求出系统的闭环特征根就很容易判定系统稳定性,但是对于高阶系统,闭环特征根求起来是很...
  • asterisk 呼叫中心软件系统最新动态

    千次阅读 2011-05-19 22:44:00
    经过1年多的努力,不断的优化,基于asterisk 的自动外呼应用系统已经比较成熟和稳定。运行速度也提高了很多。功能不但实现外呼功能,还实现了大部分的PBX 系统配置功能可以通过web 来定制。组网方式灵活。服务器可以...
  • 第一章:1.2.2系统分类(一)

    千次阅读 2017-08-14 20:32:03
    下面对于动态系统举几个例子稳定与不稳定系统首先我们先看一下稳定系统和不稳定系统的定义时变与非时变系统如何判断一个系统是时变系统还是时不变系统?方法很简单, 就是对于自变量进行平移操作,之后看
  • 什么是真正的实时操作系统

    万次阅读 多人点赞 2018-07-19 14:40:34
    做嵌入式系统开发有一段时间了,做过用于手机平台的嵌入式Linux,也接触过用于交换机、媒体网关平台的VxWorks,实际应用后回过头来看理论,才发现自己理解的肤浅,也发现CSDN上好多同学们都对实时、嵌入式这些概念...
  • 千万级的注册用户,千万级的帖子,nTB级的附件,还有巨大的日访问量,大型网站采用什么系统架构保证性能和稳定性? 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理:负载量不大的情况下select、...
  • 1、二阶系统传递函数的标准形式 典型结构的二阶系统如下图: 其开环传函: 闭环传函: Φ(s)\Phi_{(s)}Φ(s)​为典型二阶系统传递函数的标准形式。ξ\xiξ 为阻尼系数,ωn\omega _{n}ωn​ 为无阻尼震荡自然频率...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 277,157
精华内容 110,862
关键字:

动态稳定系统是什么