1、版本发布

1.1、软件版本的定义

软件版本包含两部分含义：

特定功能的集合某一次特定代码的构建结果

为明确标识版本，通常采用以下方式进行版本命名：

主版本号.子版本号[.修正版本号[.构建版本号]]
如：1.2.1 build-123

其中， 主版本号和子版本号：用来标识功能变化。小的功能变化增加子版本号，大的功能变化增加主版本号。

修正版本号：功能不变的情况下修复bug。

构建版本号：表示一次新的构建，通常由编译程序自动生成。

1.2、版本发布规划

并不是所有功能都要完成，或者是没有任何bug的版本才能上线。关键在于，要在用户的心理预期和软件的实际情况之间，达到一种平衡，让软件的功能和质量，满足好用户的预期。

要达到好的发布效果，就需要在版本发布前先做好版本发布的规划。版本的发布规划包含以下内容：

规划好要发布的功能：对用户需求进行细分。定义好发布的质量标准：用户对不同功能的质量的容忍度。设计好发布策略：beta版本测

试、灰度测试等。有一个综合性的版本发布计划：和所有项目成员及项目利益相关方共同参与制定项目的发布计划。

1.3、规范发布流程

流程和规范能将好的实践标准化流程化，让大家可以共享经验。

发布版本需要注意的几个问题：

必须保证要编译部署的是正确的版本。要保证版本稳定可靠。在发布失败后能回滚。

制定合理流程，来应用好的实践，保证发布质量。一个参考流程如下：

在发布之前做代码冻结：在源码管理工具中创建一个release分支，对于这个分支的代码，冻结功能修改，不接受新功能的增加，只修复

重要的bug。对代码冻结后发现的bug要分级：确认是在发布前还是发布后修改。每次修复bug后，发布新的候选版本每次部署新的候选

发布版本后，要做回归测试：手动了解自动化构建的方案申请上线发布部署发布上线后的测试

2、DevOps是什么

DevOps可以理解为一种开发和运维紧密协作的工作方式，从而可以更快更可靠的构建、测试和发布软件。 DevOps方式的好处：

整个软件的构建、测试和发布过程高度自动化信息更加透明和易于测量：信息更加透明，通过日志和工具，数据也可以被更好测量。培养

跨职能协作的文化：在日常工作中包容错误，对事不对人，能对项目的开发流程持续改进，鼓励创新。

DevOps的原则：自动化、信息透明可测量、构建协作文化

2.1、DevOps工程师的职能

从实践的角度来看看做什么事情，可以帮助团队实践DevOps的工作方式。

要帮助团队建立基于持续集成和持续交付工作流程。建立一套基于日志的监控报警系统，以及故障响应的流程。构建基于云计算和虚拟化

技术的基础设施：基础设施即代码要形成DevOps文化

3、线上故障解决

对于高手来说，会在实践中总结一套自己解决问题的步骤，遇到问题，会按照解决问题的步骤有条不紊地去分析和解决。 通常通过下面的步骤：
评估影响范围试图重现问题临时方案和终极方案风险评估及持续优化
参考阅读：

从新手到高手，可以从借鉴这样的方法开始，然后在实践中不断总结经验，形成一套自己分析问题、解决问题的方法。

遇到线上故障，第一要务：恢复生产、降低损失。其次才是修复bug。

3.1、快速定位bug

高手快速定位bug，关键在于通过有效的手段，逐步缩小问题范围，直到找到bug。常见的手段：

重现bug：通过重现的bug将问题的范围缩小。分析错误日志：平时要注意收集错误日志

对于线上故障，要仔细分析bug产生的原因，从根本上解决，避免类似的故障再次发生。

3.2、大厂处理线上故障的方法

把高手解决故障的方式，变成故障处理的流程和操作手册，并且通过反复地故障演习，不断练习和强化对故障处理的流程，让系统更健壮，让新手也可以快速上手。

具体的处理流程，大同小异，总结如下：

对故障进行评级：先评级，从而决定后续的处理方案马上恢复生产：避免进一步损失。可以采用部署回滚、服务降级等方式。分析故障原

因，恢复故障。记录故障：记录故障处理的全过程，分析故障原因，提出后续改进方案。

值得学习和借鉴的地方：

故障报警和轮值机制：要做到最快速度处理线上故障，关键就是要让正确的人第一时间就可以去响应。正确的人就是对故障服务最熟悉的

人，通常就是服务的开发人员。实战演习：在日常开发中就对应急方法进行实际测试。日志记录和分析工具：平时开发中，就注意对关键

日志信息的记录，同时搭建ELK这样的日志分析系统，方便查询日志。

4、日志管理

在日志数量不多的时候，凭借肉眼或借助文本编辑器，可以大概看出日志的内容，当日志的数量很多的时候，就需要借助日志管理系统对

日志进行统一管理。搭建日志管理系统的好处：

方便地对所有日志进行统一的检索。可以通过图表直观地看到应用运行情况。可以根据日志的数值设置规则自动报警。

4.1、日志管理系统的架构

很多大厂都是基于ELK搭建自己的日志管理系统，其基本架构是这样的。

有几个重要的模块：
日志采集和解析：Logstash可以帮助实现对日志的采集，将日志解析成结构化的数据才能方便地检索。存储和搜索：ElasticSearch是专业

的全文检索和数据存储系统。数据可视化：Kibana就是专门针对ElasticSearch的图形化操作工具。通过可视化图表，可以直观地看到数

据的走势，以及方便地和历史数据进行对比。监控和报警：可以安装Elast Alert这样的自动报警插件，实现报警功能。

4.2、工具推荐

ELK的安装教程：

工具：

Splunk：商业日志管理系统Grafana：开源的数据监测和可视化工具，支持自动报警功能。Wavefront：图形化监测和分析工具，支持自

动报警PagerDuty：报警服务，可以和手机、邮件、Slack方便集成，还可以和企业的轮值安排结合。

5、项目复盘

软件项目中的复盘，也是通过分析、讨论开发中出现的问题，进而总结成功经验，吸取失败教训，提升团队能力。

5.1、如何做好项目复盘

联想公司对于项目的复盘总结了四个步骤，可以借鉴。

第一步 回顾项目目标 需要描述清楚当初 定的项目目标是什么？ 项目计划中制定的里程碑式什么？ 关键在于：对目标的描述要尽可能准

确和客观。

第二步 评估项目结果 需要列出两方面的差异：好的差异和坏的差异。

好的差异：

上线后质量很稳定，严重bug很少没有出现需求遗漏，开发和测试能及时同步需求变更。

坏的差异：

功能发生了变化，中间有比较多的需求变更。项目发生了延期。

客观描述结果就行，不需要去分析原因，避免过早陷入对细节的讨论。

第三步 分析原因 导致差异的原因，也分为好的方面和坏的方面。如： 好的原因：

增加自动化测试代码的比例，改进了开发流程，增加代码审核增加了工具的使用改进了项目流程，及时跟踪

坏的原因：

老板对产品干预过多，导致需求频繁变更。项目周期过长，难以响应需求的变化设计时没有考虑到需求变更，导致变更发生后修改过多。

只有分析清楚原因，才能总结出规律

第四步 总结规律，落实行动