《软件工程之美》——运行维护

本来不痛不痒做着笔记，看到评论区的：我们公司的复盘大会，就是击鼓传国。
笑skr了，哈哈哈哈哈

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怎么办？

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

遇到线上故障，第一要务：恢复生产、降低损失。其次才是修复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的安装教程：ELK教程

工具：

• Splunk：商业日志管理系统
• Grafana：开源的数据监测和可视化工具，支持自动报警功能。
• Wavefront：图形化监测和分析工具，支持自动报警
• PagerDuty：报警服务，可以和手机、邮件、Slack方便集成，还可以和企业的轮值安排结合。

5、项目复盘

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

5.1、如何做好项目复盘

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

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

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

好的差异：

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

坏的差异：

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

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

评论区看到一个笑skr的评论。咋这么逗呢！

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

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

坏的原因：

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

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

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

参考：开会=浪费时间？阿里技术团队这样开项目复盘会