DevOps是一系列软件开发实践,强调开发人员和运维人员之间的沟通合作,通过自动化流程,使得软件构建、测试、发布更加快捷、频繁和可靠。

转载自:

https://www.zhihu.com/question/24413538?sort=created

DevOps Handbook企业级实施指南(1)–续

正如我们所知,DevOps最近几年很风靡,很多企业正在如火如荼的推行它。然而,你可曾想过,从传统到敏捷、再到DevOps,开发模式的不断革新对测试提出了怎样的挑战?

DevOps这个新理念的出现,是为了应对IT环境中普遍面临的一些挑战。开发团队要求的不断满足新的客户需求,并快速实现新的功能。而运营最关心的是“稳定压倒一切”,任何差错都有可能对生产环境中的用户造成直接影响。本文分享了DevOps从理念到实施的工具和方法。

CH12 低风险自动化发布

最近我们项目在实施DevOps,因此想趁热打铁,就DevOps模式下如何做测试,谈一谈自己的认知。

 

kent beck
XP方法的创始人,facebook的技术教练,提到“貌似facebook每次发布处理的变更数是固定的,如果想要更多变更,得多发布”。之前的发布是人工的,耗时的,高风险的,因此尽可能减少发布,这导致每次发布的变更很多,出问题的风险更大,于是形成向下循环。

DevOps有什么特征

为什么会有DevOps的出现?

自动化部署过程

DevOps是一系列软件开发实践,强调开发人员和运维人员之间的沟通合作,通过自动化流程,使得软件构建、测试、发布更加快捷、频繁和可靠。

DevOps这个新理念的出现,是为了应对IT环境中普遍面临的一些挑战。

在自动化前,我们就有发布过程文档,我们需要将发布过程尽可能多地自动化。可自动化的内容包括:

1. DevOps强调一种文化

图片 1

用便于部署的方式打包代码

在很多企业中,开发和运维人员通常隶属于不同部门,有着不同的工作环境,采用不同的沟通方式,使用不同的开发或运维工具,并且有着不同的业务目标,这使得他们之间形成一道参不透的墙。

敏捷的出现缩小了上图所示的第一个隔阂,也就是商业需求和开发之间的隔阂,有效的加快了产品开发的周期和效率。那么这无疑为运营团队增加了很多压力。

创建预先配置好的虚拟机镜像或容器

图片 2

于是上图中第二个隔阂,也就是开发和运维之间的隔阂需要解决,于是DevOps的理念应运而生。

自动化部署和配置中间件

DevOps实际是一种文化上的变迁,强调开发、运维、测试等环节之间的沟通合作。意在帮助这些人向着一个共同的目标努力:尽可能为公司提供更多价值。为了支持这种合作的发生,需要在团队内部文化和企业组织文化两个层面做出努力。

如何解决开发和运维的隔阂呢?

将包和文件拷贝到生产服务器

图片 3

首先要明白隔阂产生的原因。开发人员和运维人员认识的方法,以及各自所处的角色,都存在根本性的差别。

重启服务器、应用、服务

2. DevOps是一种实践

开发团队要求的不断满足新的客户需求,并快速实现新的功能。而运营最关心的是“稳定压倒一切”,任何差错都有可能对生产环境中的用户造成直接影响。有些服务提供商都和客户签署Service
Level
Agreement。服务中断意味着直接的财政损失。衡量指标不同,自然工作的重点不同。

从模板中创建配置文件

所谓DevOps,就是将敏捷方法延伸到Production!

那么我们首先要从文化上着手。

运行自动化冒烟测试,确认系统在工作且配置正确

DevOps主要是为了将敏捷开发实践扩展到运维阶段,进一步完善软件构建、验证、部署、交付等流程,使得跨职能团队能够完成从设计到生产支持等各环节的工作。

根本上要从文化上着手。文化的改变是第一位。了解自己的工作队全局的影响。

运行测试过程

图片 4

运维团队必须明确的认识到,如果不能快速把开发成果推倒生产环境,企业就很可能被其他竞争对手超越。长久以来就很有可能被市场淘汰。覆巢之下,焉有完卵?那么运维团队也就没有存在的意义了。但不是说稳定不重要,我们需要实施一系列手段来实现即快又稳。

脚本化和自动化数据库迁移

3. DevOps包含一系列工具链

开发团队必须明确认识到开发代码或者更改设置时,可能会对整个系统稳定性和性能的影响。

如可能,我们要重构以去掉一些步骤,尤其是耗时很长的操作。我也也希望不仅仅减少lead
time,也包括减少交接此事,以减少错误和知识的损失。

DevOps是一种融合了一系列基本原则和实践的方法论,并从这些实践中派生出了各种工具。这些工具体现在软件开发和交付过程的不同阶段:

其次要从组织结构上着手,考虑开发团队和运维团队的直接领导是同一个人,尽量避免部门直接互相指责和扯皮。

对部署流水线的需求包括:

编码:代码开发和审阅,版本控制工具、代码合并工具

第三要实施一些工具及方法。

所有环境都用同样的方式部署:通过在所有环境使用同样的部署机制,在生产的部署成功率大大提高。因为同样的操作在流水线上已经成功执行很多次。

构建:持续集成工具、构建状态统计工具

如何具体实施?

对部署进行冒烟测试:在部署过程中,我们应该测试是否能够连接到支持系统(如数据库、总线、外部服务),并运行一个交易确保系统能正常运行。如果前述测试失败,部署就失败。

测试:通过测试和结果确定绩效的工具

正如很多企业采用敏捷开发一样,这需要一个准备,尝试和逐步实施的过程。其实DevOps仅仅是一个理念,而且这个理念在不断变化和发展中。无论公司大小,IT环境面临的有很多挑战是共通的。大公司组织结构相对发杂,人员理念和文化的形成非一夕一朝之功。在实施DevOps反面,反而小公司有很多的优势。

维护一致的环境:通过一键创建环境,开发、测试、生产环境有了一致的创建过程,以后得时刻保持环境的同步。

打包:成品仓库、应用程序部署前暂存

除了IT企业外,DevOps对于传统的行业(金融,电信等等)也同样有借鉴意义。因为在不久的将来,每一个公司都是数字化的公司。没必要强调你的企业是不是采用DevOps,应该开始深入了解你的环境中需要解决的问题是什么,再看DevOps中的一些方法是不是会帮到你,然后再具体实施一些措施和借用一些工具来帮助你。比如我所关注的虚拟化平台的运维,就可以借鉴DevOps的很多思想。

将自服务部署自动化

发布:变更管理、发布审批、发布自动化

标准化和自动化:

因为需要控制和监管,以及安全和合规(compliance)需求,开发人员已经很久没有自己发布将代码部署到生产,快速看到因能用新特性而开心的客户,能够快速修复任何问题而不需要运维先进行登记。

配置:基础架构配置和部署,基础架构即代码工具

尽量采用模板和指定好的流程来更新Master
Image,采用Puppet,Chef等工具来实现系统管理自动化,尽量减少人为干预。同时也避免了不必要的人为失误。

通常的做法是运维来部署代码,这既是因为分工的概念深入人心,也是为了减少事故和欺诈(怕监守自盗?)。然后为了获得devops的效率,我们需要采用其他控制机制来获得同样甚至更好的缓解上述风险的效果,包括自动化测试、自动化部署、对变更进行同行评审等。

监视:应用程序性能监视、最终用户体验

像管理代码一样管理系统配置:

2013的devops报告发现,由开发部署代码比由运维部署代码的成功率在统计上有显著的差别。

DevOps对测试提出了哪些挑战

很多应用的配置,因为需求变化而更改。但文档往往没有同步更新。需要有工具来记录系统的配置参数。也就是说借鉴软件开发中管理Code的方式,来对系统环境的设置进行版本控制和同一的管理。从而保证环境的一致性和稳定性。

换句话说,随着开发和运维对部署共担责任,以及透明,职责和责任,谁来执行发布没什么关系。事实上,我们可以让其他角色,比如测试和项目经理来在相关环境进行部署,以便他们能快速完成他们的工作,比如部署UAT环境用于演示等。

刚参加工作时,我参与了某Audi系汽车电子的软件研发,采用的是传统瀑布开发模式。在整个项目生命周期中,前半部分设计和编码,后半部分用来测试。然而我在东家工作了两年,也没能等到产品交付到用户手上。直到去年,我们的软件才得以量产并投入市场。在这4年中,产品从未交到用户手上,因此无法验证它所带来的价值,也没有任何机会得到用户反馈从而适应变化。

这样可以捕捉到和规定配置不一致的情况,也可以快速的找到问题所在,提高排错的效率并缩短时间。

为了获得更快的流(flow),我们需要一个任何人都能执行的代码晋级过程(code
promotion process),最好是没有人工操作和交接的。这样会影响一下步骤:

后来,我又参与一个银行项目,我们采用敏捷的开发模式,全功能团队,开发测试并行,每2-3周就交付一个版本。但因为没有真正发布到生产环境,我们仍然无法及时得到有效的用户反馈。

要有独立Dev/Test环境

构建:我们部署流水线能够从版本库生成用于部署到任何环境甚至生产环境的包。

现在,我们采用DevOps的优秀实践,开发和运维协同工作。每个迭代完成,或者每修复一个线上缺陷就立即部署到生产环境。这样,我们就能够迅速从用户处获得反馈并且快速做出响应。

新的配置必须在独立的Dev环境中充分测试后,才能在生产环境中实施。

测试:任何人都能在自己的工作站或测试环境中运行任何或所有自动化测试。

通过参与传统、敏捷和DevOps的项目,我深深地感受到流程的改进对团队以及项目的产出和质量所带来的改变。

测试自动化

部署:通过执行也放在版本库中的脚本,任何人都能在他们访问到的任何环境中部署这些包

图片 5

采用一些工具和方法,自动测试系统改动后的各项功能和指标。大大减少测试需要的人力和时间。

这样,不管谁来执行部署,都能成功。

3. DevOps包含一系列工具链

开发人员能自己创建开发环境

将代码部署集成到部署流水线中

DevOps是一种融合了一系列基本原则和实践的方法论,并从这些实践中派生出了各种工具。这些工具体现在软件开发和交付过程的不同阶段:

vCloud
Director 可以很好的满足这个需求。系统管理员可以把运算、网络和存储的资源专门分配给开发团队,并授予适当权限。开发人员自己可以瞬间创建模板以及新的环境。

部署自动化后,这部分工作也能合并到部署流水中,这样,我们的部署自动化就能带来以下效果:

编码:代码开发和审阅,版本控制工具、代码合并工具

确保持续集成过程产生的包能被部署到生产

构建:持续集成工具、构建状态统计工具

show the readiness of production env at a glance

测试:通过测试和结果确定绩效的工具

提供一键自助将选择包部署到生产环境的方法

打包:成品仓库、应用程序部署前暂存

为审计和合规自动记录,包括在哪台机器执行的命令,谁授权的,结果是什么

发布:变更管理、发布审批、发布自动化

通过执行冒烟测试,确保能正常操作,配置数据库连接串是正确的

配置:基础架构配置和部署,基础架构即代码工具

给部署的人快速反馈,以便他们马上看到部署是不是成功的

监视:应用程序性能监视、最终用户体验

我们不想不得不等待数小时才知道部署是成功还是失败,然后再等数小时发布修复代码。现在有了容器等技术,复杂的部署也能在分钟和秒级完成。

DevOps对测试提出了哪些挑战

通过这些实践,我们有了一个“部署”按钮,依托部署流水线,我们可以快速安全地将代码变更发布到生产。

刚参加工作时,我参与了某Audi系汽车电子的软件研发,采用的是传统瀑布开发模式。在整个项目生命周期中,前半部分设计和编码,后半部分用来测试。然而我在东家工作了两年,也没能等到产品交付到用户手上。直到去年,我们的软件才得以量产并投入市场。在这4年中,产品从未交到用户手上,因此无法验证它所带来的价值,也没有任何机会得到用户反馈从而适应变化。

案例研究

后来,我又参与一个银行项目,我们采用敏捷的开发模式,全功能团队,开发测试并行,每2-3周就交付一个版本。但因为没有真正发布到生产环境,我们仍然无法及时得到有效的用户反馈。

略(后面再看)

现在,我们采用DevOps的优秀实践,开发和运维协同工作。每个迭代完成,或者每修复一个线上缺陷就立即部署到生产环境。这样,我们就能够迅速从用户处获得反馈并且快速做出响应。

将部署和发布解耦(decouple deployment from release)

通过参与传统、敏捷和DevOps的项目,我深深地感受到流程的改进对团队以及项目的产出和质量所带来的改变。

软件项目发布版本的传统的做法是根据市场确定的日期,提前一天晚上部署到生产系统中,次日开放。然后宣布新的能力开放,开始接受订单,给客户交付新的功能等。

图片 6

然后计划总是跟不上变化。我们可能会遇到超出我们测试或设计的负载,导致服务大量失败。更糟糕的是,因为要对生产系统做变更,回滚和修复(fix
forward)的风险一样大。等到所有问题解决,大家松了口气,祈祷着千万不要经常部署和发布。

Laurent提出一个测试左移和右移的概念:

当然,我们知道为了获得平滑和快速的流,我们需要频繁发布。当我们能够按需发布,那么将新特性开放给客户就成了市场决策,而不是技术决策。我们有两类发布模式:

测试左移,就是指在开发阶段之前定义测试。

基于环境的发布模式:我们有两至多套环境,但只有一套环境接受客户流量(比如通过负载均衡)。新的代码部署到non-live
环境,然后通过流量迁移逐渐发布。蓝绿部署、金丝雀发布、cluster immune
system都属于这一类。

测试右移,就是直接在生产环境中监控,并且实时获取用户反馈。

基于应用的发布模式:通过修改应用,使得应用支持修改配置来选择性发布和开放功能。比如采用feature
flag,在生产环境渐进地将功能开发给开发团队、内部雇员和部分客户,直到有信心开发给所有客户。这样我们就实现了dark
launching。

在敏捷开发的生命周期中,我们通过每一次迭代来丰富和更新产品,以使其最大限度地符合客户对系统的需求。当时测试的关注点基本停留在开发阶段,以保证产品达到上线标准。引入DevOps之后,我们不仅要关注产品的质量是否达标,还需要使价值假设得到及时的验证。因此,我们不仅要将测试左移,在开发环境验证功能的可用性,还要进行测试右移,通过监控产品在生产环境的运作情况,来验证其价值并获得反馈,从而持续改进。基于这些理解,我在项目上做了初步的尝试并取得良好的效果。我将这些尝试和实践总结为以下几点:

==即在生产发布不实部署代码,而是切换流量或打开开关==

1.如何保证新功能得以实现?

基于环境的发布模式

在开发环境,我们开发新功能,并且通过测试保证其达到产品验收标准。

蓝绿部署模式

首先,使用BDD(Behavior Driven
Development,BDD)的方式定义用户需求
,这样用特定的语言来描述用户行为,能够使各个角色(测试、开发、产品负责人、市场等)对业务价值达成一致的理解,从而使其从需求到最后的测试验证,进行高度的协作和沟通,最后交付最有价值的功能。同时,QA能够提前Review故事卡,补充验收标准。除此之外,BDD方式的用户需求可以直接指导测试,后续我会写到。

处理数据库变更

其次,采用单元测试来验证最基本的代码逻辑。在编写单元测试时,建议Dev和QA
Pair工作。单元测试可以认为是编码的一部分,要对系统的代码逻辑有深入的了解,因此,Dev是最合适的人选,而QA可以帮助测试覆盖的更全面。

案例研究

最后,每一个功能都要严格按照故事卡的AC(Acceptance
Criteria)进行验收,并采用探索性测试方法来对新功能进行无死角测试。

2.怎样验证新功能的价值?

金丝雀和cluster immune system发布模式

我们将新功能部署到生产环境以后,接下来就应该衡量业务价值是否达到预期

基于应用的发布模式更安全

验证预期的一个好方法是衡量用户的行为变化。比如:在上传图片的功能后面添加了一个预览按钮,但用户却极少用它,很可能是因为用户根本不需要这个按钮,或者按钮放在了不恰当的位置导致用户不方便使用,亦或是按钮样式不够友好,导致用户没有欲望使用它。这时候,该按钮的业务价值就没有真正达到,是时候调整一下了。

实现feature flag

3.如何确保已有功能不被破坏?

实施dark launchies

在软件开发中,任何代码都不可能完全独立存在,一行代码的变更也有可能导致系统的全面崩溃。那么,如何保证在开发新功能的同时,已有功能不被破坏?换句话说,如何做到全面的回归测试?人力是最高成本,也有现实的局限性,比如,人手不够,重复做同样的事情人会变得烦躁,手不够快导致效率低下等。因此,自动化测试才是不二选择。

案例研究

将BDD需求直接转化为自动化测试用例。每个测试用例都应该讲一个关于应用程序的故事。当一个测试用例使用一致的业务术语定义时,它的可读性会比较高,且容易自动化。与此同时,上一个迭代的用例在下一个迭代就可以迅速转化为回归测试的基线。

支持BDD的工具有很多,比如:Cucumber。简单举个例子,如图:

持续交付和持续部署调研

图片 7

本章小结

BA用BDD方式定义用户需求,QA
Review并补充AC,然后将其编写为自动化测试脚本。如果QA的编码能力较弱,可以让Dev协助完成代码实现的部分。这也充分说明了协作的意义。

CH13 为低风险发布设计架构

最后,也是更重要的部分,测试应该集成在CI中。每一次Build或者每天都要去执行测试,验证已有功能是否完好。这样才会对没有预期到的变化产生的问题给出快速反馈。

第四部分反馈的技术实践

另外,做一些性能测试、兼容性测试、和安全性测试等等。

第三部分是创建从开发到运维快速流的实践,第四部分是描述怎样实现从运营到开发的持续和快速反馈的实践。以此缩短和放大反馈环,当问题发生时就会被看到并将信息发射(radiate)给价值流中的所有人。更进一步,我们要创建一个工作系统,将下游运维需要的知识集成到上游开发和产品管理中,我们将迅速获得提升和学习,不管这来自生产问题、部署问题,还是早期苗头和客户使用模式。

4.怎样验证产品的可靠性?

此外,我们将创建一个过程,让每个人在工作中学习,在信息可见并触动学习,推动快速测试产品假设和,帮助我们判断新的特性是不是有助于我们达成组织目标。

有时候,某些缺陷并不是源于代码的错误,而是一个不好的用户体验,或者只有当数据达到一定量时才会出现,测试人员是无法模拟这种类型的测试的,因此直接在生产环境监控变得高效又可靠。通常我们需要监控两种特性:性能和可用性。

CH14 通过遥测技术看到和解决问题

使用工具持续获取用户数据,或者使用log持续获取性能信息。这有助于监控产品部署到生产环境后是如何正确运作的。快速启用一个功能,在生产环境实时监控验证其业务价值,获取到有效且快速的用户反馈,加之拥有持续部署的能力,我们能够在出现问题的时候快速做出反应,从而使得我们的产品更加可靠。

运营中面临的情况是事情总是会出错–小的变更导致很多预料之外的结果,包括故障和影响客户的全面失败。这就是复杂系统的特点,没有一个人能看清系统整体并理解每一块合在一起时候的表现。

这里实际上融入了《QA in
Production》的理念。现如今,已经有很多工具和方法支持在生产环境做测试了。篇幅太长,这里就不做详细阐述了,请参考原文。

日常工作中我们常遇到一个情况,即故障发生时,没有得到需要解决问题的信息。比如不知道故障是因为代码缺陷,还是环境问题,或者是外部服务导致。

到这里,再来回顾一下,我们的实践是否真的卓有成效。

遥测(telemetry),宽泛的定义是“通过在远端度量和收集数据并传输到监控接收设备实现一种自动化的沟通过程”

用BDD的方式定义用户需求、编写测试,有益于不同角色之间的一致理解和共同协作。

2015年的devops报告中,最利于MTTR指标的两项实践分别是运营使用版本控制和对生产进行遥测和主动监控。

自动化测试解决了频繁部署所带来的挑战,同时保证产品的整体功能持续得到回归和验证。

创建中心化的遥测基础架构

在线监控能有效地验证不确定需求,通过生产数据分析和预警问题的发生,并且快速获取用户反馈从而及时调整。除此之外,这一点也充分体现了Dev、QA和Ops的协作,像监控等原本只能Ops做的事,现在Dev或QA一样可以做。

对生产环境监控不是什么新玩意,将日志和遥测数据分析结果用于应用开发也不是新鲜事。但两者经常是割裂的,开发记录开发人员关心的日志,而运维只监控环境是启动的还是挂掉了。这样当事情发生时,就很难明白到底为啥系统整体运行不符合设计,和不知道具体哪个组件出问题了。

写在最后

为了在所有问题在出现时就被看到,我们得设计应用和环境以产生足够的遥测(能力),这样我们能看到系统作为一个整体的行为是怎样的。随着应用栈所有层次的监控和日志,我们其他方面的能力也会挖掘出来,比如图形化和可视化度量数据,异常检测,主动告警和弹性扩展。

测试是一种活动,曾经我们通过它来验证产品是否达到上线标准。现在DevOps模式下,我们需要在各个阶段不断地执行测试活动,以达到产品质量的持续改进。

在“The Art of
Mornitoring”(==有这本书吗?得找找==)中定义了现代监控体系结构,这个结构有以下组件:

而QA仅仅是一种较多进行测试活动的角色。敏捷一直强调“团队为质量负责”,测试不再是QA的专属。DevOps模式更是对测试、尤其是自动化测试提出了更高的要求,也对QA的编码能力提出了极大的挑战。作为团队成员,每个人都有责任了解开发流程、提高测试技能,把好测试这一关。但是,测试活动作为QA的主要职责之一,提高自动化测试技能,就是当下每个QA最为紧急且重要的事情了。

在业务逻辑、应用和环境层收集数据:在每一层,我们基于事件、日志和度量创建遥测。

如果需要相关学习资料的朋友可以加我的qq群:747981058,里面有小伙伴为大家整理好的自动化,接口,性能等等的学习资料,也可一起交流学习,人生如同逆水行舟,不进则退,咱们一起加油努力吧!

用于存储和度量事件的方法(router):这样我们就具备可视化、分析趋势、告警、异常检测等能力。通过收集、存储和聚合所有“遥测”,我们能更好地进行深入分析和健康检查。这通常也是我们存储服务配置的地方,也是进行基于阈值的告警和健康检查的地方。

图片 8

通过集中化的日志,我们可以在整个系统对事件级(同类事件,比如core)进行求和以形成度量;通过将日志转化成度量,我们可以进行统计分析,比如异常检测,这样可以发现早期问题。

除了对生产服务和环境进行遥测,我们还得对部署流水线的重要事件进行遥测,比如在任何环境部署后的自动化测试成功和失败。还要收集构建和测试执行的时间等,这样我们可以检测潜在的问题,比如性能测试或构建比往常慢了一倍。

图片 9

image.png

更进一步,我们需要容易地从遥测结构中获取信息,最好是自服务的API,而不是要提个单子然后等待报告。

理想情况下,我们的遥测能报告所有感兴趣的事发生时的准确情况,以及发生在哪里和怎样发生的。要能够在没有应用的情况下做人工和自动的分析。某种程度上说,监控系统要比被监控的系统要求更高,要有更好的可用性和可扩展性。

下文遥测和度量是一个意思,包括生产环境、预生产环境、部署流水线所有应用栈所有层次产生的事件日志和度量数据。

创建帮助生产的应用日志遥测

有了集中化的遥测基础设施,我们得确保应用产生足够的遥测。我们通过让开发测试未新增和存量服务创建生产遥测作为日常工作来达到这个目的。

如同NASA发生火箭需要有数以百万计的传感器每时每刻报告状态一样,我们为软件创建的遥测也是我们所做最有价值的事(投资回报最高的事情)。

应用中每个特性都必须仪表化–如果足够重要的话,事实上如果不重要,就不会去实现。

价值流中的不同成员会用不同的方式使用遥测。比如开发需要用于分析开发环境BUG的遥测,而运维需要诊断生产问题,信息安全和审计要review必须的控制,产品经理要跟踪业务产出,特性使用或转化率。

为了支持不同的使用模型,需要对日志分级记录:

DEBUG Level:

INFO Level:

WARN Level:

ERROR Level:

FETAL Level:

选择日志级别很重要。ThoutWorks的顾问发现,“当确定要用ERROR还是WARN时,就看是不是会被凌晨4点被叫起来,低于这个就不是ERROR”。(==可能组织级要规范下定义==)

为了确保我们有足够的有关可靠性和安全的信息,重要的应用事件必须有记录下来:

认证/授权决策(包括下线)

系统和数据访问

系统和应用变更(尤其是权限)

数据变更,例如增加、编辑或删除数据

非法输入(可能的恶意注入和威胁)

资源(RAM、磁盘、CPU、带宽,及其他有或硬或软限制的资源)

健康和可用性

启动和停止

故障和错误(faults or errors)

断路器跳闸(circuit breaker trips,是不是指流控、服务降级等?)

延迟

备份成功和失败

为了让日志项好理解和有意义,我们需要创建日志分级分类,比如非功能属性(性能、安全等)和功能属性(搜索、排列等)

用遥测指导解决问题

本章开头有讲高绩效的人用严格的方法解决问题。与此相反的更寻常的实践是利用谣言和道听途说,这导致可悲的度量“自证清白平均时间”。

这一般发生在会因故障和问题被指责的文化中,为了避免被指责/定责,就不会不充分充分展示遥测,于是问题解决很困难。

科学的方法会用遥测确定导致问题和哪些问题需要解决的假设。解决问题时我们可以问的问题包括:

从监控中我们能够得到什么证据说明问题真的发生了?

有哪些应用和环境的变更和这个问题相关?

我们能形成什么假设来建立因果关系?

我们怎样才能证明哪个假设是正确的,可用于解决问题?

基于事实的问题解决不仅和MTTR密切相关,而且有利于在开发、运维之间建立双赢观念。

==注:本节描述的问题我们不应该出现,我们的开发和运维之间的沟通是基于事实和坦诚的==

将创建生产遥测作为日常工作

创建遥测和信息发射器的自服务访问方法

发现和填满任何遥测空白(fill gaps)

应用和业务度量

基础设施度量

将其他有关信息填补到我们的度量中

本章小结

CH15 分析遥测数据分析问题,达到目标

CH16 通过快速反馈让开发和运维安全地发布代码

CH17 在日常工作中集成假设驱动和AB测试

CH18 通过审视与写作流程提高当前工作质量

第五部分 持续学习和体验的技术实践

CH19 让学习成为每天的工作

CH20 将局部发现转化成全局提升

CH21 为组织学习(organiztion learning)和提升预留时间

第六部分 集成信息安全、变更管理、合规的技术实践

CH22 信息安全是每个人日常工作

CH23 保护部署流水线

來源:简书

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图