用 Spinnaker 构建更安全,低风险的部署环境

Spinnaker 是 Netflix 开源的持续交付平台。Netflix 的服务运行在超过100000个 AWS 云实例上,Spinnaker 用于部署超过95%的 AWS 云实例。

Spinnaker 主要用于降低新部署带来的风险,Netflix 公司并不希望一个新的 Push 影响到主体服务的运作,建立一个新的微服务很简单,难点是不断升级和维护拥有数百万用户的微服务,当出现问题时,还需要快速的回滚,在这篇文章中,将重点介绍 Spinnaker 提供的一些技术和工具。

更加方便的回滚

Spinnaker 最简单的保护措施是在通过红黑(也称为蓝/绿)部署策略部署服务时启用简单回滚。

在 Spinnaker 中创建新的集群时,只需选择 “red/black”部署策略:

这个操作将保持 Spinnaker 中的最后一个集群可用,但是被禁用(即没有流量)。

如果上线时发生什么事情(事故)需要将代码回滚到上一个可用的版本,只需在侧栏中选择 Rollback 操作即可:

回滚对话框将询问你要回滚到哪个禁用的集群:

使用红/黑部署策略可以让回到最后一个已知的可用的版本,如果部署失败或出现问题是可以撤销的。

限制并发执行

Spinnaker 中另一个限制部署风险的策略是它能够限制 Pipeline 的执行。

默认的 Pipeline 一般会修改和部署相同的自动生成的备用的 Pipeline。

Spinnaker 可以配置一次只运行一个 Pipeline:

启用 NOT_STARTED 标志后,只要已经有一个正在运行的 Pipeline,任何新的 Pipeline 都将处于同一个状态,一旦这条 Pipeline 完成,等待的 Pipeline 将启动。

执行部署

我们可以限制 Spinnaker 中特定阶段的执行时间。

限制一个阶段的执行时间有两种可能的用途:

1)只有当有人能够手动干预时

2)在服务器不是采取高峰流量时。

Netflix 在一天中对流量的需求往往是周期性的。人们一般时在晚上下班后回家观看视频。Netflix 确保在流量高峰时间不会触发部署动作。为了让部署过程更加透明,Netflix 将一个名为 SPS(每秒部署,下面会介绍)的度量合并到部署报表中,并突出显示与此度量相关的部署窗口。

禁用Pipeline

如果给定的 Pipeline 产生不正确的输出,或者由于其他系统问题而不能运行,则可以禁用该 Pipeline。

禁用的 Pipeline 将不会自动触发,并且会导致触发它的任何父 Pipeline 失败。

禁用的 Pipeline 不能手动触发,直到再次启用的时候。

检查先决条件

Spinnaker 提供了一个名为 Check Preconditions 的阶段,如果不符合某些要求,将会停止 Pipeline。

第一种形式是检查一个集群的大小:

第二种形式允许指定一个灵活的程序化表达式,称为 Pipeline 表达式。

可以通过运行 Jenkins Job 或 Docker 容器来执行更复杂的检查(例如冒烟测试),这两个阶段在 Spinnaker 中都得到很好的支持。

任何 Spinnarker 阶段可以通过配置 Conditional On Expression 使其成为可选项。这允许添加可由 Pipeline 参数控制的可选阶段,并提供额外的自动质量关卡。

手动判断

Spinnaker 提供了一个 Manual Judgment 的选项,确保运维工程师或 QA 可以轻松完成需要人工的步骤。

当一个 Pipeline 到达人工判断阶段时,它会停下来等待负责人进来并点击 Continue。这可以在需要时进行额外的验证。

手动判断阶段使用 Spinnaker 内置的现有通知机制,因此可以向需要批准流水线的用户发送电子邮件,SMS 或 Slack 通知。

我们也可以指定判断条件。判断条件可以用来决定管道的下一个步骤。在上面的例子中,如果用户选择了输入 Continue,那么后面的步骤将会运行。

通过流水线触发器自动清理

Spinnaker 允许用一条 Pipeline 的结果调用另外的 Pipeline,这样做的一个用途是自动将应用程序的状态恢复到已知的良好状态。

这可以通过设置 Pipeline 自动触发器来完成,该触发器只会运行另一个失败或被取消的 Pipeline。

流量监控

如果不小心摧毁了最后一个好的集群,导致流量中断。流量监控来确保总是提供可用的集群。

在应用程序的配置中设置了一个流量监控。它会告诉你哪些集群将被保护。

现在,当 Pipeline 或人为销毁或禁用受保护群集中的最后一个集群时,他们将看到下面的错误消息或其 Pipeline 执行失败:

自动金丝雀分析

Netflix 采用的先进技术之一是自动金丝雀分析(ACA)。在 ACA 中,实时流量被发送到基线和金丝雀集群对,以查看它们发出的指标是否满足可接受的偏差。ACA 非常擅长捕捉传统单元测试或集成测试无法跟踪的问题。

在 Spinnaker 中建立 Canary 分析阶段非常简单:

首先,定义基线(当前)群集和金丝雀(新代码)群集。

然后选择金丝雀分析的细节并定义可接受的分数,然后运行 Pipeline:

Spinnaker 将启动每个基线和金丝雀集群的一个新实例,并将每 x 分钟产生一个 Canary 得分(在例子中为15)。

成功的金丝雀

金丝雀得分

在 Spinnaker 添加金丝雀分析之前,不同的团队会以不同的方式做金丝雀。 有些会启动新的集群,其他则会重新利用其生产集群中的现有指标。通过 Spinnaker 处理 ACA 的部署,Spinnaker 的用户能够专注于他们需要捕获的分析和指标。还可以确保基线/金丝雀集群提供了最佳的一组可比较的指标。

Canary Analysis 只是一个简单的阶段,可以插入到 Pipeline 中,Spinnaker 鼓励使用这种技术,代码失败的 ACA 是不会进一步部署的。

自动的“Chaos”测试

Chaos 实验

Netflix 的“Chaos Engineering”工程是一个相对较新的实践。这个想法是运行自动控制的实验,确保能够达到预期的回退行为。

Spinnaker 与“Chaos”自动化平台(ChAP)集成,以确保使用“Chaos Engineering”工程实践创建的测试案例作为部署和验证 Pipeline 的一部分运行:

在 Spinnaker 中运行 ChAP 就是要确保”失败转移”行为作为部署过程的一部分进行测试。这种持续不断的测试对于那些本来就处于休眠状态的系统性弱点是至关重要的。

Chaos Monkey

Chaos Monkey V2 与 Spinnaker 深度整合,并支持使用 Spinnaker API。

Spinnaker 还通过托管它的配置来帮助 Chaos Monkey,如果用户没有做好准备,用户可以选择退出这个野蛮的状态。

通过启用 Chaos Monkey,可以确保代码对实例的故障转移具有适应性。其中插入在 Netflix 中做更大规模的故障转移测试,以确保 Netflix 可以生存在 Chaos Monkey 中。

Scrum中story point的预估

一、什么是story point

Story point,翻译成中文即为故事点。
故事点是Scrum团队使用的一种随机度量方式,用来度量实现一个故事需要付出的工作量”,还可能是“故事点数的估算混合了对于开发特性所要付出的努力、开发复杂度、个中风险以及类似东西。
我们也可以理解为可以用story point来衡量一个issue的难度或工作量。

二、story point的预估

估计story point常用的两个标准如下,在这里我主要以Fibonacci为例讲解。

  • Fibonacci: 0, ½, 1, 2, 3, 5, 8, 13, 21,34, 55, 89
  • Power of 2: 0, 1, 2, 4, 8, 16, 32, 64,128

story point虽然可以分为12个等级,但我们在现实中一般只采用0、1、2、3、5、8、13这七个等级。如果在预估中发现超过13的,我们一般把任务进行分割,分割为两部分,循环该步骤,直至所有point都小于等于13。

一开始我们选取之前预估为3的Issue来跟要预估的Issue进行比较,如果两个工作量差不多,设置该Issue的story point为3,如果工作量略少,则为2,更少的话则设置为1,如果该Issue不需要完成的则设置为0,该情况一般不会出现。
同理可得,如果工作量较大,相应的设置为5/8/13。

基于JIRA的Scrum敏捷开发的项目管理

Scrum敏捷开发的关键字就是增量、迭代,他更重视项目团队之间的现场沟通,不向传统瀑布式开发那样需要万事具备,才开始开发,Scrum在大方向和小故事点确认好了后,团队就可以开动了。

Scrum的团队一般都不大,一Scrum团队人数一般在10人左右,主要角色有:

product owner(产品负责人)、scrum master(团队负责人)、scrum team(开发/测试团队)。

  • Product owner :需求方,提出需求,能对功能流程、业务流程拍板的人。
  • Scrum master :团队负责人,负责解决团队各类问题,领导项目的人。
  • Scrum team :项目执行人员,一般指项目具体开发和测试的人员。

Scrum开发的步骤:

步骤一:头脑风暴

如果product owner对产品需求非常清楚,就可以省略这个步骤;开发遵守“先紧后松”原则,必须先把需求了解清楚;这里product owner可以召集技术团队/用户群体对其需求进行公开征求意见,最后输出一个产品建议表。

步骤二:product owner对产品建议表进行筛选并做减法,提炼最核心的需求。

在确定了需求后,由scrum master进行输出prd(product requirement document),这里就和传统的瀑布模式一样了,该有的文档都必须有,必须由scrum master和product owner确定好需求,包括业务逻辑、功能流程等。

步骤三:工作量估算

把任务量化,包括原型、logo设计、ui设计、前端开发等,尽量把每个工作分解到最小任务量,最小任务量标准为工作小时不能超过16小时,然后估算总体项目时间。

把每个任务都贴在白板上面,白板上分三部分:

(1)to do-待完成(2)in progress-进展中(3)done-完成

步骤四:Sprint

经过讨论后,已经把任务量化到需要具体完成的时间,然后把n个任务按照开发的重要度,组合成n个sprint(冲刺),每次执行一个sprint。

  • Sprint:每个sprint都是独立的,一般先做主要功能,再到次要功能,再到小功能,最后的sprint一般是修复bugs。)
  • Sprint:因为任务都被量化了,每天工作了多少小时,完成了多少任务量,通过每天的例会scrum master就非常清楚,并且在time burn down chart(时间燃尽表)进行表示,我们就可以直观看到任务的进度了,而且是具体到多少小时。
  • Sprint:在burn down chart里面,不管任务是否按时完成都必须记录。
  • Bugs:每个sprint都必须测试,尽量大家一起测试,如果太多bugs就开一个sprint来修复bugs。
  • 站会:每天要做的是,要开standing meeting,因为大家的时间都是非常紧张的,一般是站着开的,时间不要长,10分钟左右为宜。会议必问开发团队每个人三个问题:(1)今天做了什么(2)明天打算做什么(3)遇到什么困难
  • scrum master要解决开发团队的困难,让项目快速进展下去;每周一次周会,product owner最好在场;每个月一次月会,product owner最好在场,指出产品开发是否在product owner期待范围内;如此重复下去,直到开发完成。

(时间燃尽表:scrum的精华,通过该表格可以可视化任务的时间进度,从图中可以看到,day1是整个任务的总共时间,每天按照任务完成度更新剩余时间,或者增加时间(例如发现一个技术难点、团队成员请假等要增加开发时间))。

步骤五:评估

product owner和其团队/用户会对产品进行评估,可能还会有各种不满意的地方,不过product owner要求需要改的地方还是要改的,建立一个bugs sprint,把产品做到product owner最想要为止。

补充说明

  • SCRUM也有其自身的先天缺点,就是对团队要求高,团队成员有能力且相互信任度高,不会相互推卸责任。
  • 新团队使用该方法,起初会有各种问题,需要多多磨合。

 

基于JIRA的Scrum的项目管理

准备工作:

1、在上面的第三步时需要做工作拆分及工作量估算,会得到一个类似下面的项目计划表,JIRA的Scrum项目管理也是基于此表

p_w_picpath

2、团队中所有成员必须已经在JIRA中建立用户,并可以正常登陆

p_w_picpath

正式JIRA中建立Scrum开发项目

一、建立一个Scrum的BoardsScrum的团队

p_w_picpath

p_w_picpath

p_w_picpath

p_w_picpath

p_w_picpath

这是新建好的Boards,同时也建好了项目。

p_w_picpath

p_w_picpath
二、开发项目常规管理

p_w_picpath

1、项目编辑

p_w_picpath

p_w_picpath

2、版本开发周期设置

p_w_picpath

3、添加软件开发的功能模块

p_w_picpath

4、修改工作流

p_w_picpath

p_w_picpath

默认工作流太简单,没有QA等功能,需要重新建立工作流,或者增加一个工作流:

p_w_picpath

p_w_picpath

这个流程比较适合Scrum项目使用,大概流程如下:建立好每个故事或子任务后,它们都处于 TO DO状态,团队成员登陆JIRA,可以看到分配给自己的任务,团队成员选择一个优先要做的任务,并把当前任务更改为IN Progress,如果遇到难题进行不下去了,就把这个任务状态改为Blocked,当哪天又可以解决的时候,再把当前任务状态改为In Progress,如果任务顺利完成,就把当前任务改成Ready For QA状态,等待进行软件测试,如果测试通过没有问题,QA就把这个任务状态改为DONE,此时这个任务就完成了。如果测试中有问题,QA会重新把任务状态改为IN PROGRESS状态,并分配处理人为开发者,同时备注问题原因,由开发者处理问题后重新提交Ready For QA。当整个Sprint都测试通过没问题,这个SPrint就结束了,但如果后来集成测试中还有问题,或者任务有了小的要求修改,相关任务,需要REOPENED,重新开始TO DO去一个新的循环。

p_w_picpath

返回项目管理中

p_w_picpath

三、Scrum敏捷开发设置

1、基本设置完成后,返回可以看到功能已经全部具备,下面开始添加Story、Task了

p_w_picpath

2、建立大一些的用户故事——Epics

p_w_picpath

p_w_picpath

p_w_picpath

以下设置是需要先在第一个Sprint的Planning Meeting上已经确定了Story和细分的Story Point 。

p_w_picpath

p_w_picpath

3、建立第一个Sprint,并重命名,方便识别

p_w_picpath

p_w_picpath

4、建立story(即Scrum开发中所说的Story,如果还有子任务,这个story可以不指定经办人)

p_w_picpath

p_w_picpath

p_w_picpath

p_w_picpath

选择Stroy输入Estimate(预估天数)及子任务

p_w_picpath

p_w_picpath

 

录完了所有的story后,下面按照计划表录入子任务

p_w_picpath

指定每个子任务的经办人

p_w_picpath

如此方法,建立完成所有的子任务

p_w_picpath

5、开始Sprint

p_w_picpath

设置第一个Sprint的开始及结束时间

p_w_picpath

有了活动Sprint,Active Sprint项目才能有内容。

p_w_picpath

在Active Sprint项目中增加Ready For QA列,用于过程测试动作的显示。

p_w_picpath

p_w_picpath

p_w_picpath

p_w_picpath

p_w_picpath

6、设置管理面板(为了方便看到整个项目进度情况及分配 给我的任务,可以根据需要专门定制管理面板)

p_w_picpath

p_w_picpath

增加一个新面板,并应用给所有人

p_w_picpath

p_w_picpath

p_w_picpath

通过增加小工具来增加工具

p_w_picpath

p_w_picpath

修改及移动已有的小工具

p_w_picpath

p_w_picpath

创建完成的面板,在用户一登陆时就会看到这个

p_w_picpath

项目中的6大功能板块:

一、Backlog(查看Epics-大故事,Task-小故事,Sub-Tasks-故事点。)

p_w_picpath

二、Active Sprints(查看进行中的Sprint的进展情况:To Do/In Progress/Done)

p_w_picpath

三、Releases(版本发布情况)

p_w_picpath

四、报表(各类统计报表)

p_w_picpath

五、Issues(问题列表)

p_w_picpath

六、模块(每个模块中的问题数量)

p_w_picpath

 

————————————————————————————————————————————————————————————————————————————————

说明:JIRA中可以建立项目的类型(上例是建立Boards时系统自动建立的软件项目,是默认的第一个项目类型)

p_w_picpath

软件类:

1、Scrum软件开发

p_w_picpath

 

2、看板软件开发

p_w_picpath

3、基本软件开发

p_w_picpath

业务类:

4、任务管理

p_w_picpath

5、项目管理

p_w_picpath

6、过程管理

p_w_picpath

Centos 字体安装

第一步:查看安装了那些字体  命令:fc-list :lang=zh

安装方法:

1、先从你本机 C:\Windows\Fonts 拷贝或者网络上下载你想要安装的字体文件(*.ttf文件)(把*.ttc重命名为*.ttf)

到/usr/share/fonts/chinese/TrueType 目录下(如果系统中没有此目录,则自行mkdir创建,亦可重命名为自己喜欢的文件夹名)

2、修改字体文件的权限,使root用户以外的用户也可以使用

# cd /usr/share/fonts/chinese/TrueType
# chmod 755 *.ttf

3、建立字体缓存

# mkfontscale (如果提示 mkfontscale: command not found,需自行安装 # yum install mkfontscale )
# mkfontdir
# fc-cache -fv (如果提示 fc-cache: command not found,则需要安装# yum install fontconfig )
4、重启计算机(似乎必须重启才会有效)
# reboot