精华内容
下载资源
问答
  • 信息分类的基本原则与方法

    万次阅读 2013-09-30 13:47:29
    1. 科学 :在分类时,应选准信息的最稳定的本质属性,作为分类的基础和依据,确保一个稳定分类体系。 2. 系统: 在分类时,将选定信息的属性或特征按一定的排列顺序予以系统化,形成一个科学合理的分类体系...

    信息分类应根据信息内容的属性或特征,按照一定的规范和标准直,为了方便信息的交流与共享,应遵循以下原则:

    1.  科学性 :在分类时,应选准信息的最稳定的本质属性,作为分类的基础和依据,确保一个稳定的分类体系。

    2.  系统性: 在分类时,将选定信息的属性或特征按一定的排列顺序予以系统化,形成一个科学合理的分类体系。

    3.  可扩展性: 在分类时,分类应满足事物的不断发展和变化的需要。

    4.  兼容性: 在分类时,分类应兼容国际、国家相关标准及要求。

    5.  实用性: 在分类时,分类应考虑良好的可操作性,满足管理和应用的实际需求[1]。

    信息分类是企业资产管理的基础性工作, 同时又是一项系统性工程。因此, 在信息分类的过程中, 一定要以企业的具体需求为基础, 以实用为出发点, 采取正确的工作思路, 多样化的手段。信息分类常见的分类方法有两种:

    线分类法

    线分类法又称层级分类法,是指将分类对象按所选定的若干分类标志,逐次地分成相应的若干层级类目,并排列成一个有层次逐级展开的分类体系。分类体系的一般表现形式是大类、中类、小类等级别不同的类目逐级展开,体系中各层级所选用的标志不同,同位类构成并列关系,上下位类构成隶属关系。由一个类目直接划分出来的下一级各类目之间存在着并列关系,不重复,不交叉。具体示例如下:

    大类

    中类

    小类

    家具

    木制家具

    金属家具

    塑料家具

    竹滕家具

    床、椅、凳、桌、箱、架、橱窗

    线分类法应遵循的基本原则:

    1.   在线分类法中,由某一上位类类目划分出的下位类类目的总范围应与上位类类目范围相同(都属于家具)。

    2.   当一个上位类类目划分成若干个下位类类目时,应选择一个划分标志(按照制作原料)。

    3.   同位类类目之间不交叉、不重复,并只对应于一个上位类(木椅、木凳、木桌、木箱、木架)。

    4.   分类要依次进行,不应有空层或加层。

    线分类法的优缺点:

    Ø  优点:层次性好,能较好地反映类目之间的逻辑关系,使用方便,既适合于手工处理信息的传统习惯,又便于计算机处理信息。

    Ø  缺点:线分类体系存在着分类结构弹性差(分类结构一经确定,不易改动)、效率较低(当分类层次较多时,代码位数较长,影响数据处理的速度)。

    面分类法

    面分类法又称平行分类法,它是将拟分类的商品集合总体,根据其本身的属性或特征,分成相互之间没有隶属关系的面,每个面都包含一组类目。将每个面中的一种类目与另一个面中的一种类目组合在一起,即组成一个复合类目。

    服装的分类就是按照面分类法组配的。把服装用的面料、款式、穿着用途分为三个互相之间没有隶属关系的“面”,每个“面”又分成若干个类目。使用时,将有关类目组配起来。如:纯毛男式西装,纯棉女式连衣裙等。具体示例如下:

    第一面 面料

    第二面 式样

    第三面 款式

    纯棉

    纯毛

    化纤

    混纺

    男式

    女式

    西服

    衬衫

    套装

    休闲服

    面分类法应遵循的基本原则:

    1.   根据需要,应将分类对象的本质属性作为分类对象的标志。

    2.   不同面的类目之间不能相互交叉,也不能重复出现。

    3.   每个面有严格的固定位置。

    4.   面的选择以及位置的确定应根据实际需要而定。

    面分类法的优缺点:

    Ø 优点:具有较大的弹性,可以较大量地扩充新类目,不必预先确定好最后的分组,适用于计算机管理。

    Ø 缺点:组配结构太复杂,不便于手工处理,其容量也不能充分利用。

    信息编码是将某一类信息赋予一定的符号,为了满足实际业务应用,编码需要具备以下基本原则:

    1.  唯一性:编码必须保证每一个编码对象对应仅有一个代码。

    2.  可扩展性: 代码结构必须能够适应编码对象不断增加的需要

    3.  简单性:在不影响代码的容量和可扩展性的情况下, 代码尽量简短明确,以减少差错, 方便阅读、抄录

    4.  一贯性: 同一级代码类型、结构以及编写格式必须统一, 一直沿用代码格式,不要中途变化格式。

    5.  可操作性: 代码应尽可能反映编码对象的特点, 有助记忆,便于填写。少使用其他符号,如‘#’、‘-’、‘*’等。

    6.  稳定性: 代码不宜频繁变动,应考虑其变化的可能性,尽可能保持代码系统的相对稳定。

    在当前的企业应用中,编码的方式主要有以下几种:

    1    英文字母法:英文字母法是指将某项物资用特定的一个字母或一组字母来表示。

    2    数字法:指将某项物资用特定的一个数字或一组数字来表示的方法。数字法还可考虑以下几种编码方法。   

    a)   连续数字法,首先要求将所有物资进行分类,并按一定的规律先后排列,然后自1号起依顺序编排流水号,此方法优点是代号连贯,但未来新增类别时,不能在中间穿插,只能在后面添加。   

    b)   阶梯式数字法,首先要求将所有物资分成若干大类,其次再将各大类按其次级类别分成若干中类。

    c)   区段数字法,是介于连续数字法与阶梯式数字法之间的一种表示方法。

    d)   国际十进制分类法,是指将所有物资分为十大类,分别以0-9之间的数字代表;然后每大类再划分为十个中类,并分别再以0-9之间的数字代表,如此进行下去。 

    3    暗示法:是指根据物资的特性,采用特定的数字或符号使之能代表物资特性的方法,又可分为数字暗示和符号暗示法。 

    4    混合法:是指将英文字母和数字结合起来使用的方法。

    根据以上编码原则与方法,下面将根据企业资产管理过程中需要进行编码的内容进行举例说明,简单直观的了解编码过程中的关键因素。

    1.客户管理信息(混合法)

    X    X    XXXX    XXXXXX

                               第四层:邮政编码

                             第三层:客户代码

                          第二层:客户类别

                        第一层:客户信息类目: 

    编码:110BSF200137

    1-客户管理,1-直接客户,0BSF-巴斯夫公司,200137-邮政编码

    2.物料分类信息(国际十进制分类法)

    6                       应用科学

    62.                    工业技术

    621.                   机械的工业技术

    621.8                  动力传动

    621.88                 挟具

    621.882.              螺丝、螺帽

    621.882.2             各种小螺丝

    621.882.21            金属用小螺丝

    621.882.215           丸螺丝

    621.682.215.3         平螺丝

        信息编码是企业资产管理的基础性工作, 是实现企业信息共享和交互的前提和基础,总结信息编码的作用可以归结如下:

    1.  实现信息的交换与共享

    实现信息交换与共享的前提和基础是各交换和共享信息应具有一致性, 即当使用一个代码或术语时, 所指的是同一信息内容。这种一致性是建立在信息分类与编码对各信息系统的对每一信息的名称、描述、分类和代码共同约定的基础上, 就是说对同一数据应具有同一格式、同一含义。

    2.  改善数据质量, 降低冗余度

    信息分类与编码的实施将形成数据标准统一, 最大程度地消除因对信息的命名、描述、分类和编码不一致所造成的误解和分歧。减少一名多物、一物多名, 对同一名称的分类和描述的不同, 以及同一信息内容具有不同代码等现象。做到事物或概念的名称和术语统一化、规范化,并确立代码与事物或概念之间的一一对应, 以改善数据的准确性和相容性, 消除定义的冗余和不一致现象。

    3.  指导信息化建设

    通过信息分类与编码的实施,用户可了解信息资源的基本内容, 发现和定位信息资源, 实现公共信息资源的增值利用。通过信息分类与编码的实施, 将为构建稳健、集成的数据模型奠定坚实的基础。 通过信息分类与编码的实施, 能推动数据仓库建设、决策与支持系统、信息系统集成和信息化建设的发展, 为新一代信息系统建设奠定基础。


    展开全文
  • 《中文新闻信息分类标准》编制原则 2006-06-09 11:51:38 《中文新闻信息分类标准》编制原则 1 范围 《分类》规定了中文新闻信息分类体系和分类代码。 《分类》规定了中文新闻信息分类方法的一般原则。 《分类》适用...
    《中文新闻信息分类标准》编制原则 
    
    2006-06-09 11:51:38 



    《中文新闻信息分类标准》编制原则

    1 范围
    《分类》规定了中文新闻信息分类体系和分类代码。
    《分类》规定了中文新闻信息分类方法的一般原则。
    《分类》适用于通讯社(新闻社)、报社、期刊社、广播电台、电视台、网络媒体,以及各种资讯机构对中文新闻信息进行分类标引和编制分类目录。
    2 规范性引用文件
    《分类》采用下列国家标准,其随后所有的修改或最新版本适用于本《分类》。
    GB/T 2659-2000 《世界各国和地区名称代码》
    GB/T 2260-2002 《中华人民共和国行政区划代码》
    GB 3304-91 《中国各民族名称的罗马字母拼写法和代码》
    3 术语和定义
    《分类》采用下列定义。
    3.1 中文新闻信息 Chinese news
    指通讯社、报纸、刊物、广播电台、电视台和网络媒体等,用中文对新近或正在发生的、对公众具有知悉意义的事实的报道,包括文字形式和数值、图形、图片、图表、图像和声音等非文字形式。
    3.2 网络媒体
    指利用互联网(Internet)发布或传播新闻信息的网站。和报刊、广播、电视等传统媒体比较,网络媒体在广泛性、即时性、开放性、共享性和互动性等方面更具优势。
    3.3新闻信息分类News classification
    指按照新闻信息的主题内容或其它特征,依据特定的分类标引工具(分类表),将它们分门别类地组织成科学体系的过程。
    3.4 分类表
    是对新闻信息进行分类标引和检索的工具,是分类法的表现形式。一般是将同一主题从大类到小类,按照逻辑系统逐级展开。内容包括类表(基本大类、简表、详表、复分表)、类目注释、编制说明及使用说明等。
    3.5 类
    指一组具有共同属性的事物的集合,又称类目。
    3.6 基本大类
    又称分类大纲。指分类表中列出的第一级类目。
    3.7 简表
    又称基本类目表。指由基本大类直接展开而形成的一、二级类目表,是分类表的骨架。
    3.8 详表
    又称主表。指在简表的基础上,将类目逐级扩展而成,是新闻信息分类标引的主要依据。
    3.9复分表
    又称附表、辅助表。指将详表中出现的共性子类目抽取出来,单独编列成表,供详表有关类目进一步细分时使用。目的是为了缩小类目表的篇幅和细分方便。复分表包括通用复分表和专用复分表。
    使用复分表进行分类标引时需遵守各表有关规定和总的组配规则,以保证标引的一致性。
    3.9.1 通用复分表
    指适用于整个主表的复分表,供对主表有关类目进一步细分用。附在主表之后。
    《分类》有如下通用复分表:总类复分表、人物复分表、企业复分表、世界国家(地区)代码表、中国行政地区代码表、中国各民族名称代码表和新闻信息体裁表。
    3.9.2 专用复分表
    指适用于主表中某一类的复分表,供对该类有关类目进一步细分用。附在主表某类中。
    《分类》有体育比赛专用复分表,农产品专用复分表等。
    3.11 仿分
    又称仿照复分。指后面的类目仿照前面类目所列出的下位类进行细分的方法。对具有共同分类标准的临近类目,常常采用此种方法。例如“政治”中的“民主党派”
    3.12 类目注释
    是对类目的补充说明,它帮助分类标引人员理解类目,准确归类。《分类》类目的注释主要有:
    指出类名含义。例如“科学技术”的“火炬计划”类目下注“中国高新技术产业的指导性计划”。
    指明类目内容。例如“信息产业”的“电子政务”类目下注“政府部门办公自动化、网络化、电子化以及全面信息共享入此”。
    指明类目间的关系和范围。例如“政治”的国家“地理概况”类下注“领土、领海、领空、专属经济区及渔业区、深海和外层空间资源享有、领属等入此。领土纠纷或边境冲突入‘外交、国际关系’”。
    指出细分方法。例如“政治”的“地方人民代表大会”类下注“可依中国行政区划表”分。又例如“政治”的“全国政协常委会”类下注“仿全国人大常委会分”。
    4编制原则
    《分类》根据新闻包罗万象、时间性强、综合性强,既容易形成专题,又相互交叉渗透的特点,以政治、经济和文化等社会领域为分类体系的基础,以新闻主题为主要立类原则,同时注意吸收图书、档案等各种分类中适合新闻信息分类的元素,力求使《分类》既能反映新闻信息的特点,又能做到实用性和科学性、稳定性、可扩展性相统一。
    4.1科学性原则
    《分类》采用主题与学科相结合的立类方法,使分类体系具有主题的直接性和学科的系统性。
    《分类》各基本大类都采取从总到分、从一般到具体的等级分类方法。
    《分类》由主表和复分表共同构成完整的体系。
    4.2 实用性原则
    随着社会的发展,新闻信息内容变得日益广泛,内容重点发生重大变化,用户检索需求也日趋多样化。《分类》在保证类目体系科学性、逻辑性的同时,把一些新闻信息量大、用户比较关注的内容跨越逻辑层次,作为基本大类列出,以期达到重点突出,降低分类难度和类目设置相对平衡的目的。例如,按照学科分类法处于“经济”二级类目的农业、工业、金融、能源、交通运输、信息产业、贸易、服务业等在本《分类》中均成为一级大类。
    4.3 稳定性原则
    《分类》在一、二级类目的设置上,充分考虑与国计民生、社会发展息息相关的各个重要领域,总结和继承我国主要新闻媒体数十年分类工作中积累的经验,吸收和借鉴国内外一些著名的分类标准,力求使其具有稳定性和兼容性。
    4.4可扩展性原则
    《分类》的可扩展性原则体现在两方面:
    1, 随着社会的发展,新事物、新学科、新技术不断涌现,《分类》在类目扩展上预留充
    足的空间。
    2, 《分类》是为了适应各种传媒机构对中文新闻信息进行分类的共同需要而编制的。但考虑
    到每个传媒机构在新闻信息的收集重点、分类粗细、数据库规模等方面存在许多差异。为此,允许各传媒机构在不破坏《分类》类目体系和标记规则的前提下,可以制定适合自己单位执行《分类》的使用本或分类细则。
    4.5 《分类》在工业类目的设置上借鉴了GB/T 4754-2002《国民经济行业分类与代码》,在科学技术类目的设置上借鉴了 GB/T 13745-92 《学科分类与代码》。但根据新闻报道的特点对其中一些类作了调整,例如“工业”中增加了“家用电器及非电力器具” 类,将家用视听设备、家用摄录设备、家用制冷电器、家用空调器、家用通风电器、家用厨房电器、家用清洁、卫生电器、家用美容、保健电器以及燃气器具、太阳能器具等非电力家用器具相对集中。又例如,将“法学”、“军事学”、“新闻学与传播学”、“计算机科学技术”、“纺织科学技术”、“食品科学技术”、“交通运输工程”等分别合并到“法制”、“军事”、“传媒业”、“纺织业”、“食品、饮料”、“交通运输”等类中。
    4.6《分类》根据新闻信息大多综合性强、内容层次较浅的特点,在农业、工业等经济门类的类目设置上,一般将科学研究、技术开发、产品制造(生产)、市场销售等汇集在一起。
    4.7 《分类》将交叉或具有双重属性的新闻信息两处列类,但其中一处只起参见的作用,其代码用[ ]表示,类目下加注说明。例如,“工业”的“[09001400600003]航天器”类目下注“宜入‘航空、航天科学技术’”,意思是把09工业中的航天器制造方面的新闻信息集中到“航空、航天科学技术”类。这样做的目的是使航天方面的信息从发展规划、科学研究、技术发展、航天器制造、发射等都相对集中。
    4.8 《分类》中各类出现的分类层次和数量分布不均衡现象,是事物发展不平衡在新闻报道中的体现,是客观实际所决定的。

    5编码方法和代码结构
    5.1类目层次设置
    主表的类目层次最多到5级。
    复分表中,世界各国和地区、中国行政区划、中国民族名称的类目设置分别按GB/T 2659-2000 《世界各国和地区名称代码》、GB/T 2260-2002 《中华人民共和国行政区划代码》、GB 3304-91 《中国各民族名称的罗马字母拼写法和代码》执行;其它复分表最多设2级。
    5.2 类目代码
    主表类目代码用阿拉伯数字表示。
    主表采用十进分类法,每一级类目用2位阿拉伯数字表示(01-99)。二级及其以下类目代码由上位类代码加顺序码组成,顺序码前面加“0”,作为类目之间的分隔符号。
    复分表中,世界各国和地区、中国行政区划、中国民族名称的类目代码分别按GB/T 2659-2000 《世界各国和地区名称代码》、GB/T 2260-2002 《中华人民共和国行政区划代码》、GB 3304-91 《中国各民族名称的罗马字母拼写法和代码》执行;其它复分表的类目代码设置与主表的作法相同。
    5.3 类目代码结构图
    本标准主表的代码结构图如下:
    依次类推
    (数字)一级类目代码
    ××
    (数字)二级类目代码
    ×××
    (数字)三级类目代码
    ×××
    (数字)四级类目代码
    ×××
    ……














    5.4标识符号
    - 为总类标识符号。
    < > 为国家(地区)标识符号。
    ( )为中国行政区划标识符号。
    “ ”为民族标识符号。
    ‘ ’为人物标识符号。
    { } 为企业标识符号。
    [ ] 为类目交替符号。


    6使用指南
    6.1 各单位对《分类》的使用
    每个新闻媒体单位都有自己的特点和新闻信息收集重点。所以,对《分类》的使用要求也不尽一致。为此,可在统一的分类标准下,制定本单位所需的分类细则,制定合适的使用本。一般可以包括以下几个方面:
    6.1.1根据本单位的实际需要,选择《分类》主表中的一部分类目制订本单位的使用本。
    6.1.2根据本单位的需要,对主表一些下位类目进行扩充。
    6.1.3规定出适合本单位分类需要的类目仿分、复分的范围和办法。包括哪一些类目需要仿分、复分,对连续仿分、复分的注释规定出是部分采用,还是只仿分、复分到某一层次。
    6.1.4对复分表的使用作出选择。选择时要确定使用哪些复分表,不使用哪些;哪些复分表的子目是全部使用,还是使用到哪一级;哪一级类目使用复分表,哪一级类目不再使用复分表;复分表子目中的再细分注释,是采用还是不采用,等等。
    6.1.5对交替类目的使用作出选择。
    但是,在制定本单位使用本时需要遵循两个原则,一是实用,符合本单位的实际需要;二是不破坏本分类法类目体系和标记制度,一、二级类目必须照用。
    另外,要将本单位的使用本报送《分类》的管理单位备案。
    6.2 分类标引基本规则
    6.2.1以新闻信息内容为分类标引的主要依据。切忌单凭新闻标题作为分类的依据。
    6.2.2正确处理多主题新闻信息的分类。对此,应首先要对内容进行分析,找出其中最能代表报道内容本质或内容中起主导作用的主题。
    6.2.3保持同类信息的集中。内容相近的新闻信息应选取同一个类号。对某新闻信息进行改编、翻译、评论,一般要同被改编、翻译或评论的新闻信息的类号一致,连载的新闻信息要同初载的类号一致。
    6.2.4正确处理不同类型和不同载体新闻信息的分类。不同类型(图书、报刊、内部资料、论文、会议报告等)和不同载体(声像、图片、缩微等)的信息都应按照其内容进行分类,只有这样,才能方便用户按主题检索到全部信息。
    6.3 复分表的使用
    6.2.1总类复分表的使用。该表适用于任何一级类目,使用时,只需将复分号加在主表分类号之后,并用标识符号 “-”连接。
    《分类》主表中,某些基本大类因有特殊需要,设置了与总类复分表相同的下位类目。在进行新闻信息分类标引时,如果遇到这种情况,则不再按照总类复分表进行分类。
    6.2.2其它复分表的使用。使用世界国家(地区)表、中华人民共和国行政区划表、中国民族名称和代码表、新闻体裁表、人物表、企业表时,只需将复分号加在主表分类号之后,并用复分标识符号连接。



























    附录A
    (规范性附录)
    总类复分表

    1 使用说明
    ——本表适用于主表中任何一级类目复分组配。
    ——使用本表复分时,复分号均须连同专用标识符号“”一起加在主类号之后。
    ——凡主表中已列有专类者,不再用本表相关类目复分。
    2 类目
    01 综合(含历史沿革、概况和综合性新闻信息)
    02 体制
    03 理论
    04 政策
    05 法规
    06 规划
    07 管理
    08 机构
    09 交流
    11 统计
    12 趣闻
    13 常识



    附录B
    (规范性附录)
    人物复分表
    01 生平(包括年表、年谱、大事记)、简历
    02 诞辰纪念
    03 逝世纪念
    04 故乡、故居
    05 亲属
    06 公务活动(国内接见入此)
    07 国内视察、考察
    08 出席会议(国内会议、国际会议)
    09 出国访问(国外会见入此)
    11 著作、作品
    12 讲话
    13 署名文章
    14 题词、题名、作序
    15 信件、日记
    16 批示、手迹
    17 图片
    18 影视记录片
    19 荣誉称号
    21 兴趣、爱好


    附录 C
    (规范性附录)
    企业复分表
    企业管理
    企业人事
    企业财务
    企业上市
    企业投融资
    企业评级
    企业改革
    企业改制
    企业并购
    企业破产
    企业垄断行为
    企业报告
    企业文化
    附录D
    (规范性附录)
    世界国家(地区)代码表

    GB/T 2659-2000 《世界各国和地区名称代码》







































    附录E
    (规范性附录)
    中国行政地区代码表
    GB/T 2260-2002 《中华人民共和国行政区划代码》


















    附录F
    (规范性附录)
    中国各民族名称代码表
    GB 3304-91 《中国各民族名称的罗马字母拼写法和代码》




















    附录G
    (规范性附录)
    新闻信息体裁表
    1 使用说明
    ——本表适用于主表中任何一级类目复分组配。
    ——使用本表复分时,复分号均须连同专用标识符号“”一起加在主类号之后。
    2 类目


    01 消息
    02 特写
    03 评论(言论、编辑部文章)
    04 社论
    05 通讯
    06 专访
    07 新闻调查
    08 专题
    09 大事记
    10 访谈
    11 速写
    12 散记
    13 侧记
    14 札记、手记
    15 年终报道
    16 特别报道/典型报道
    17 热线
    18 简讯(标题新闻)
    19 背景资料
    20统计数据(移到总类复分)
    21 公报、公告
    22 市场行情
    23 图片
    24 图表
    25 排行榜
    26 分析报告
    27 讲话稿
    28 白皮书
    29 来信
    30 民意测验
    31 译文
    32 广告
    33 更正
    34 其它

    本文转自
    http://xxj.liuzhou.gov.cn/tblm/ztbd/t20060609_26087.htm
    展开全文
  • 稳定性全系列(一)——如何做好系统稳定性建设

    千次阅读 多人点赞 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

    展开全文
  • 稳定性(Reliability)、可用性(Availability)、可维护性(Maintainability),是三个有关联的概念、合称RAM,较为容易混淆,因此本需要特别说明一下。依据《ISO IEC 25010-2011 SQuaRE》标准,可将稳定性理解为”...

    1、领域名词解释

    稳定性(Reliability)、可用性(Availability)、可维护性(Maintainability),是三个有关联的概念、合称RAM,较为容易混淆,因此本需要特别说明一下。依据《ISO IEC 25010-2011 SQuaRE》标准,可将稳定性理解为”应对故障(faults)的能力、对用户而言是可用的,被性能、可用性、可维护性等因素影响。“ 稳定性并不纯粹、搞混淆RAM是很正常的,但治理故障这一点很清淅。

    本文对高可用的定义是:能应对大流量的稳定性。因此实施方案当中也涉及SLA等指标的运营。

     

    2、稳定性治理的三种思想

    什么是交易长期坚持的高可用方向?故障涉及方方面面,高可用的方法也是种类繁多,我们需要几条基本方法去指导高可用长期的治理方向,我们有三种视角去看待高可用这件事:可用性计算公式、复杂系统理论、交易技术事故定级规范。从不同的视角看待事情,会导致不同的分析路径。

     

    1.可用性计算公式—亚马逊

    第一种理解可以从可用性计算公式(Availability Estimate)入手,涉及两个变量:故障概率、故障时长,增大MTBF、减小MTTR。主要包含减少故障发生概率、减少故障恢复时间、制造故障发生概率(可控的)三个方法。为什么会需要人为制造故障发生概率?因为故障发生相应频次较低,没有办法很好地提前发现故障,而制造故障本质则能帮助解决。减少故障发生概率是know unnkown的做事, 制造故障发生概率是unkown unkown的做事。

    AvailabilityEstimate=MTBF/(MTBF+MTTR)。MTBF:theMeanTimeBetweenFailure,MTTR:MeanTimetoRecover

    从这三个策略推导的一些主要方法如下图示,参考了亚马逊《AWS Reliability Pillar 2019》。

    可用性公式拆解的稳定性原则(灰色部分源自《AWS Reliability Pillar 2019》)

     

    2.复杂系统理论—Netflix

    分布式系统具备复杂系统的一般特征,可以复杂系统理论来研究与指导分布式系统,该想法来自Netflix《Mastering Chaos—A Netflix Guide to Microservices》的启发。Netflix在业内有一系列产生重大影响的稳定性开源产品,包含Hystrix、Chaos Monkey、Zuul、aws-autoscaling等。

    依据《What is a Complex System(James Ladyman etc.)》论文对复杂系统定义的研究,复杂系统的特征之一是系统主要维护 “无序性(disorder) vs. 鲁棒性(robust order)”这对矛盾的平衡稳定。当系统突破临界值、就会产生更大的disorder。从这对矛盾出发、有两个思路:既可以通过模拟环境增加无序性、激化矛盾,也可以增加稳定性能力鲁棒性、减少矛盾。

    复杂理论的原则可概括为:随机、依赖和规模是影响系统稳定性的三大因素,分治、自治、反馈是守正之法,无序是出奇之法。从该原则推导的主要方法如下图所示。

    复杂系统理论拆解的稳定性方法(灰色部分源自《Mastering Chaos—A Netflix Guide to Microservices》)

     

    3.交易技术事故障驱动—蚂蚁金服

    影响事故定级的因素主要是两大类:资金损失、体验损失。

    从避免资金损失、体验损失这两个策略归纳的一些主要方法,如下图所示。鉴于蚂蚁金服在金融领域的行业影响力,主要参考了蚂蚁金服TRaaS技术风险防控平台、将高可用与资金安全相结合。资金安全也是影响系统稳定性的一个重要因素。

    交易事故拆解的稳定性方法(灰色部分源自《蚂蚁金服 TRaaS 技术风险防控平台》)

     

    3、稳定性的方法设计

    3.1、设计挑战

    什么构成了交易可用性的挑战?归纳成四点:故障的随机性(软硬件、网络故障等),系统规模(交易链路长、外部依赖关系多),系统变化(节假日流量、功能迭代发布),以及交易故障产生的重大影响。前三点是引发系统故障的重要因素,如下图所示。

    影响稳定性的三个因素(依据复杂系统理论)

    这三个因素也决定了稳定性需要长期运营、没办法一劳永逸(更本质的说法是系统的熵增所决定)。这意味着像Amazon、阿里等这样的大公司,即使有了专业的SRE团队、稳定的技术产品体系,体系化地做稳定性这件事,也无法说 "it's enough!" 只要有业务需求迭代、只要有变化、只要系统存在,就需长期去做运营。

     

    3.2、系统全景图

    交易可用性方向如下图,主要思路如下:

    1)用分治与隔离的思路、将复杂系统变成N个相对简单的子系统,简化系统的规模、降低模块间的依赖关系、降低长链条比例。这点在系统架构阶段要重点关注。

    2)每个子系统,需要具备健康反馈能力、能够时实感知故障,并且实现对故障的自愈,以应对故障的随机性。

    3)为了减轻故障频次低难以验证稳定性的问题,也为了防止系统处于临界状态(一个小问题,引发大故障),需要随时的随机的在生产环境做故障演习,以及压测。对于故障演习,以前大家不够重视,这是一个很强的演进驱动力,在系统越早期做、成本及风险越低。

    4)不同故障对业务的影响不一样,我们可以通过柔性可用等方式减少影响、保障用户核心体验。针对交易业务重点关注全域的资金链条。

    5)我们不仅需要构建系统的稳定性能力,同时也要把控好整个研发流程,包括成本收益、架构设计、持续交付、组织保障、故障处理机制等。有一个源自阿里运维的数据,有60%~80%的故障源自发布变更。

     

    4、稳定性子项交付成熟度—衡量标准。

    对交易高可用结果的定量,以各团队对技术故障数量为考核标准。对交易高可用建设过程的定量,主要涉及两方面:具体要做什么事、这些事又怎么定量。本文参考阿里运维参考汽车自动化的分类方法,从功能完善度、自动化程度两个维度定义了交易高可用成熟度等级,见下表。本文的自适应容量、自适应故障参考自《企业级 AIOps 实施建议》,混沌工程参考自《AWS混沌工程成熟度分级标准》,监控告警参考自《stack state监控成熟度模型》。

    2019年Q3Q4主要实现绿色表示的目标,2020年实现全覆盖。

    分类

    工作内容

    L0(无自动驾驶)

    L1(具有特定功能的自动驾驶)

    L2(具有复合功能的自动驾驶)

    L3(具有限制条件的无人驾驶)

    L4(全工况无人驾驶)

    健康反馈

    监控告警

    全人工

    独立组件监控

    分层监控

    全链路监控

    智能分析、预测、自愈

    分治单元

    业务隔离

    无隔离

    独立组件隔离

    基础设施隔离(网络、机房、容器、组件、数据库等)。含:Set化、泳道等。

    业务隔离

    环境隔离

    单元自愈

    自适应容量

    数据收集和分析工具

    流量调度平台、扩缩容平台。

    含:限流、扩缩容等。

    基于规则的自动调度和扩缩容

    可自主规划成本和容量方案的智能调度&伸缩

    支持服务完整生命周期的全部基础运维工作,由智能系统接管,统自主做到可用性、成本、效率撮优化

     

    自适应故障

    按需开发的追查、处理脚本

    预案平台

    基于预案的自动止损;自适应可测;

    例:依赖关系、核心链路等。

    可自动规划止损方案的智能故障ONCALL;自适应可测;

    支持服务完整生命周期的全部基础运维工作,由智能系统接管,统自主做到可用性、成本、效率撮优化

    攻防演练

    全链路压测

    全人工

    单机压测

    交易全链路压测

    交易全链路压测;自动生成报告;周期自动执行

    交易全链路压测;自动生成报告;周期自动执行;智能设置阈值

     

    混沌工程

    全人工

    在预生产环境中运行实验;有工具

    生产环境运行;周期人工;手动监控和停止实验;若干故障场景(应用容器)

    生产环境运行;周期人工;自动分析;自动终止实验;丰富故障场景(应用容器/网络环境/数据库等)

    生产环境运行;周期自动化;丰富故障场景

    研发工程

    发布变更

     

     

     

     

     

     


    =>更多文章请参考《中国互联网业务研发体系架构指南》

    =>更多行业权威架构案例及领域标准、技术趋势请关注微信公众号:

     

    公众号:关注更多实时动态
    更多权威内容关注公众号:软件真理与光
    展开全文
  • 稳定性检验

    千次阅读 2019-09-15 11:13:42
    2. 从变量出发,根据其它不同指标对样本进行分类后,检查分类后的样本是否对y特征的显著有影响; 3. 从计量方法出发, 用不同的工具或检验方法。。 可以用OLS, FIX EFFECT, GMM等来回归,看结果是否依然robust;...
  • 指导原则 高可用 事前 副本技术 隔离技术 配额技术 探知技术 预案 监控和报警 降级 回滚 failXXX系列 高并发 多线程 ...
  • 设计模式分类以及六大原则

    千次阅读 2016-06-26 23:38:52
    设计模式的分类总体来说设计模式分为三大类: 创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、...
  • 软件测试七大原则分类

    千次阅读 2015-09-20 10:30:50
    软件测试七大原则 一、测试显示缺陷的存在 测试可以显示缺陷的存在,但不能证明系统不存在缺陷。测试可以减少软件中存在缺陷的可能,但即使测试没有发现任何缺陷,也不能证明软件或系统是完全正确的,或者说是不...
  • 浅谈系统实现层面稳定性保障

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

    千次阅读 2020-05-02 09:51:22
    修订的主要方面与技术: ■在渐变中实现结构性变化(为确保分为类法相对的稳定性) ■类目体系的扩充(适用于该类的文献、信息有了较大增长,而原 来的类目明显不敷使用) ■增补新的主题 利用空号个别增加类目;...
  • 金蝶K/3产品性能稳定性优化指导手册  2011-08-15 11:43:05| 分类: ERP应用|字号 订阅  金蝶K/3产品性能稳定性优化指导手册(常见问题)(V3.0) ?金蝶软件(中国)有限公司研发中心K/3产品...
  • 【Java设计模式】软件设计七大原则

    万次阅读 多人点赞 2019-08-31 13:44:31
    文章目录软件设计原则分类开闭原则依赖倒置原则单一职责原则接口隔离原则迪米特法则(最少知道原则)里氏替换原则合成/复用原则(组合/复用原则) 软件设计原则分类 开闭原则 依赖倒置原则 单一职责原则 接口...
  • 面向对象六大原则

    万次阅读 多人点赞 2015-11-30 00:10:44
    1、优化代码的第一步——单一职责原则单一职责原则的英文名称是Single Responsibility Principle,简称SRP。它的定义是:就一个类而言,应该仅有一个引起它变化的原因。简单来说,一个类中应该是一组相关性很高的...
  • 信息分类编码技术研究及应用

    千次阅读 2008-01-07 10:27:00
    本文从烟草机械制造企业信息化过程入手,介绍信息分类编码在企业信息化中的重要, 对信息分类编码技术进行了较为详细的阐述,重点介绍烟草机械制造企业信息分类编码的方法、信息分类编码的原理与编码的内容。...
  • 设计模式之SOLID原则再回首

    千次阅读 2014-11-29 20:42:23
    这是一篇关于回顾设计模式SOLID五大原则的文章,我非常喜欢文章中的例子,每个例子都是我精选了描述模式的,通过Modom讲述了单一职责原则、通过加减法计算器讲述了开闭原则、通过企鹅动物讲述了里氏替换原则、通过...
  • 第五章 信息法与综合性信息检索 目录: 5.1 信息法概述 5.1.1 信息法的概念 从广义上讲,信息法是调整信息活动中产生的各种社会关系的法律规范的总称。 一般来说,信息法由信息资源管理法、政府信息公开法、信息...
  • 高扩展高可用网站的51条原则

    千次阅读 2013-04-24 12:07:38
    高扩展高可用网站的50条原则 A.化简方程 一.不要过度设计 目的:防止设计中出现复杂的解决方案。 适用情形:适用于任何项目,所有大型的或复杂的系统和项目都应该采用该原则。 应用方式:让同行来检查解决方案...
  • 面向对象设计的七大设计原则详解

    万次阅读 多人点赞 2018-10-03 12:32:21
    文章目录面向对象的七大设计原则简述七大原则之间的关系一、开闭原则(The Open-Closed Principle ,OCP)概念理解系统设计需要遵循开闭原则的原因开闭原则的实现方法一个符合开闭原则的设计开闭原则的相对二、 ...
  • 依赖倒转原则

    万次阅读 多人点赞 2014-07-21 13:11:20
    依赖倒转原则 依赖:  DIP(DependenceInversion Principal),再说这个原则之前,我们先说说什么是依赖吧。这里的依赖关系我们理解为UML关系中的依赖。简单的说就是A use a B,那么A对B产生了依赖。具体请看下面的...
  • 设计模式七大原则

    千次阅读 热门讨论 2018-05-29 11:24:33
    设计模式七大原则
  • 面向对象设计的六大原则 : 单一职责原则, 里氏替换原则, 依赖倒置原则, 接口隔离原则, 迪米特法则, 开闭原则
  • 公共技术点之面向对象六大原则

    千次阅读 多人点赞 2015-02-24 23:14:21
    采用依赖倒置原则可以减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。 第二章节中的BasicNetwork实现类依赖于HttpStack接口( 抽象 ),而不依赖于HttpClientStack与...
  • GRASP设计原则(职责分配原则

    千次阅读 2018-01-04 23:42:57
    GRASP设计原则(职责分配原则) GRASP(General responsibility assignment software Principle)设计原则是设计模式的基础,在GOF的23中设计模式中处处可以体现其中的一个或多个设计原则,所以在掌握设计模式之前...
  • 文本分类——常见分类模型

    万次阅读 多人点赞 2018-11-06 17:37:56
      文本分类方法模型主要分为两个大类,一类是基于规则的分类模型;另一类是基于概率统计的模型。 基于规则的模型   基于规则的分类模型相对简单,易于实现。它在特定领域的分类往往能够取得较好的效果。相对于...
  •  设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计 模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠。 毫无疑问,设计模式于己于他人于...
  • 设计模式原则

    千次阅读 2008-03-03 11:06:00
    设计模式原则对可维护性的支持:一、 "开放-封闭"原则(OCP)Open-Closed Principle原则讲的是:一个软件... 已有软件模块,特别是最重要的抽象层模块不能再修改,这使变化中的软件系统有一定的稳定性和延续性。例子
  • 设计模式--开闭原则

    千次阅读 2013-05-14 22:53:36
    开闭原则:指的是一个软件实体应对对扩展开发,对修改关闭(Software entities should be open for extension, but closed for modification)。 这个原则是说在设计一个模块的时候,应对使这个模块可以在不被修改...
  • 需求说明:Cadence基本知识 内容 :第一部分 PCB设计... 第二部分 PCB设计之3W原则与20H原则图示  第三部分 3W原则的实质详解 来自 :时间的诗 第一部分 PCB设计之3W原则 原文:http://www.mr-wu.cn/3w-rule-p
  •  无论如何,开放封闭原则(OCP,Open Closed Principle)都是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化、降低耦合,而开放封闭原则正是对这一目标的最直接体现。其他的设计原则,很多时候是为...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 48,569
精华内容 19,427
关键字:

信息分类的原则稳定性