软件工程学习笔记12——运行维护篇

一、版本发布

1、关于软件版本

对软件版本来说，包含两部分含义，一部分代表特定功能集合，一部分代表某一次特定的代码构建结果。

为了明确标识软件版本，需要对版本进行编号。目前业界在软件版本的命名上，通常会采用以下方式：

• 主版本号 . 子版本号.[. 修正版本号.[构建版本号]]
  比如说：1.2.1、2.0、3.0.1 build-123。

其中主版本号和子版本号用来标识功能变化，小的功能变化增加子版本号，大的功能变化增加主版本号。修正版本号则表示功能不变化的情况下修复 Bug，而构建版本号表示一次新的构建，这个通常由编译程序自动生成。

2、版本发布前，做好版本发布的规划

这里的关键在于，要在用户（或客户）的心理预期和你软件的实际情况之间，达到一种平衡，让软件的功能和质量，满足好用户的预期。

要合理管理好用户的预期，达到好的发布效果，就需要在版本发布前先做好版本发布的规划。

版本的发布规划，主要是指是：

规划好要发布的功能
对于必须要有的功能，那么要保证软件中有这个功能才能发布，对于不是必需的功能，可以以后再逐步完善。

设计好发布的策略
考虑好是直接发布给所有用户？还是先让一部分用户试用？让一部分用户使用 Beta 版也是一个好的发布策略；还有就是采用灰度测试的发布策略，让一小部分用户先用新功能，如果没发现什么问题，再继续扩大使用的用户规模。

综合性的版本发布计划
在确定了要发布的功能、定义好了质量标准、设计好了发布策略，就可以制定一个综合性的版本发布计划了，确定好发布的时间点。
这个发布计划，不止是项目内部成员，还需要和项目之外利益相关方，比如客户、市场运营人员，大家一起确定最终的发布计划。

3、规范好发布流程，保障发布质量

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

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

我们也可以制定合理的流程，来应用这些好的实践，保证发布的质量：

• 在发布之前要做代码冻结
  代码冻结的原则就是尽可能减少代码的修改，避免引起不稳定。
• 对代码冻结后发现的 Bug 要分级
  在代码冻结后，可能还存在一些 Bug，对于这些 Bug，要有一个简单的分级：是否在发布前修改，还是留在发布后再修改。
• 每次修复 Bug 后，发布新的候选版本
  进入代码冻结后还需要对一些 Bug 进行修复，每一次修复完 Bug 后，就要生成一个新的候选发布版本，比如说 1.1 RC1、1.1 RC2。
• 每次部署新的候选发布版本后，要做回归测试
• 申请上线发布
  在正式上线发布前，通常还需要有一个申请和审批的流程，避免上线过于随意导致问题，避免和其他部门的上线冲突。
• 部署发布
• 上线后的测试

二、DevOps工程师

1、什么是 DevOps

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

DevOps 并不意味着开发一定要懂运维技术，运维要懂开发技术，而是说两个工种要更紧密的协作，有共同的目标：更快更可靠的构建、测试和发布软件。

DevOps 的主要原则就是自动化、信息透明可测量、构建协作文化。团队采用 DevOps 的方式工作的话，会带来哪些好处呢：

• 整个软件的构建、测试和发布过程高度自动化
  DevOps 一个很重要的基础就是自动化，通过对自动化的应用，是最简单有效的打破开发和运维之间壁垒的方式。
• 信息更加透明和易于测量
• 培养跨职能协作的文化

DevOps 工程师，要做的事情就是帮助团队来实践 DevOps 的工作方式。具体可以帮助团队：

• 建立基于持续集成和持续交付工作流程；
• 建立基于日志的监控报警的系统，以及故障响应的流程；
• 构建基于云计算和虚拟化技术的基础设施；
• 形成 DevOps 的文化。

DevOps 工程师做的事情，就是帮助团队基于 DevOps 原则来做事，让团队形成紧密协作的工作方式，更快更可靠的构建、测试和发布软件。

三、线上故障

在软件上线后，发生线上故障是一个常见的问题，但怎样对线上的故障进行处理，却很能反映出新手和高手程序员的差距。对于团队来说，如何应对线上故障，也同样能反映出线上运维水平的高低。

1、遇到线上故障，新手和高手的差距在哪里

新手遇到复杂的线上故障，不知道该怎么下手

对于线上故障，有的很简单，从界面或者错误日志上可以直观地看到问题在哪，从而也好找到方法去解决。但有的故障，却没办法直观地看出原因，比如说内存一直在涨，CPU 居高不下，遇到这种复杂的故障，通常新手就不知道该怎么下手了。

而对高手来说，会在实践中总结一套自己解决问题的步骤，遇到问题，会按照解决问题的步骤有条不紊地去分析和解决。
比如：

• 第一步，评估影响范围；
• 第二步，试图重现问题；
• 第三步，临时方案和终极方案；
• 第四步，风险评估及持续优化。

新手遇到线上故障，会想着马上修复 Bug
匆忙之间打补丁，如果没有经过充分的测试，可能会引入新的 Bug，甚至是更严重的 Bug。如果要充分测试，那么意味着时间会比较长，而线上故障的时间越长，可能意味着损失也越大。

而对于高手来说，会首先对故障进行评级，看对用户的影响范围，如果是核心业务，大面积影响用户，那么当务之急是恢复生产，然后再考虑如何去修复 Bug。

新手遇到线上故障，不知道如何快速定位到 Bug 在哪
对于比较复杂的线上故障，新手通常不知道从哪里下手，看日志看代码都看不出所以然，而高手却总能快速地定位到 Bug 在哪。

高手快速定位 Bug 在哪，关键在于通过有效的手段，逐步缩小问题范围，直到找到 Bug 在哪里。比如重现bug、分析错误日志等。

新手解决完线上故障后，下次可能还会发生类似故障
新手在遇到线上故障后，采用一些临时解决方案，比如说重启服务，发现恢复了，然后就把这事忘记了。对于线上的故障，如果不找到产生的原因，那么下一次还会发生类似的故障，甚至比以前还更严重。

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

2、大厂都是怎么处理线上故障的

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

至于具体的处理流程，其实大同小异：

• 对故障进行评级。
• 马上恢复生产，避免进一步损失。
• 要分析故障原因，修复故障。
• 记录故障发生处理全过程，分析故障原因，提出后续改进方案。

大厂处理线上故障处理机制有哪些值得借鉴的地方

• 故障报警和轮值机制
  要做到最快速度处理线上故障，关键就是要让正确人的第一时间就可以去响应。正确的人就是对故障服务最熟悉的人，通常就是这个服务的开发人员。
• 实战演习
  实战演习就是频繁地对故障进行演练，来测试平时做的这些方案是不是真的可行，这样遇到真正的故障，才不至于手忙脚乱不知道如何应对。
• 日志记录和分析工具

四、日志管理

1、什么是日志管理

日志就是操作系统和应用软件自动生成的事件说明或者消息记录，包含了时间、日志信息。举例来说，下面就是一个典型的 Web 请求日志：

10.0.1.22 – – [15/Oct/2018:13:46:46 -0700] “GET /favicon.ico HTTP/1.1” 404
10.0.1.22 – – [15/Oct/2018:13:46:58 -0700] “GET / HTTP/1.1” 200

从上面的日志中，可以看出来，日志包含两次 http 请求，它们发生的时间、请求的 URL、请求的 IP 地址、最后返回的状态码等信息。

现在的应用程序越来越复杂了，尤其是像微服务这样的架构，一个系统需要由若干微服务组成，每个微服务可能还会部署在若干容器上，那么意味着如果你要根据日志去排查故障的话，需要从几十、上百个地方去收集日志，再逐个去分析。

要解决这样的问题，就需要对日志进行统一管理。现在已经有很多成熟的日志管理工具可以帮助你对日志进行管理，只要去了解这些工具可以帮助你做什么，以及如何基于它们来搭建适合你项目的日志管理系统即可。

2、如何快速发现和定位问题

• 日志集中式管理后，就可以方便地对所有日志进行统一的检索。
  同时在检索的方式上，可以用类似于 Sql 语句的方式来检索，高效地对结果进行查询和归类。
• 对日志进行集中式管理后，可以通过图表直观的看到应用运行情况。
  当所有的应用实时将日志传输到一起，日志管理系统就可以根据应用日志中记录的信息，动态地生成图表，实时看到应用运行的情况。
• 可以根据日志的数值设置规则自动报警。
  从日志中实时分析出来的数据结果，如果设置好相应的阈值，在超过阈值后，就会自动触发报警，通知相关的开发人员进行维护。

3、大厂的日志管理系统的架构是什么样子

对于像阿里、新浪这样的大厂来说，对日志管理系统的应用已经是标配了。很多大厂是基于 ELK 搭建的自己的日志管理系统，而 ELK 的架构也是一套经典的日志管理的架构，所以这里以 ELK 为例来说明日志管理系统的基本架构。

先解释一下 ELK：

ELK 是 Elasticsearch + Logstash + Kibana 的缩写。
ElasticSearch 是一套搜索框架，提供了方便的接口，可以方便地做全文检索，可以用来对日志进行检索。
Logstash 是一个数据收集工具，可以用来收集日志数据。
Kibana 是一套可以和 ElasticSearch 交互的界面，通过 Kibana 可以方便的检索 ElasticSearch 内的
所有数据，还可以用图形化的方式展示数据结果。

基于 ELK 搭建的日志管理系统基本架构是这样的：
这套架构有几个重要的模块：

• 日志采集和解析
  Logstash 不仅可以对日志数据进行收集，还能对日志数据进行过滤和解析，解析完成后再将解析好的数据发送给 ElasticSearch。
• 存储和搜索
  ElasticSearch 就是一套专业的全文检索和数据存储系统，同时还有一套类似于 SQL 的查询语句，这样你就可以基于它，方便对收集好的日志数据进行检索了。但 ElasticSearch 本身类似于数据库，没有图形化界面。
• 结果可视化
  像 Kibana 就是一套专门针对 ElasticSearch 的图形化操作工具，可以方便对 ElasticSearch 数据进行检索，也可以对结果用图表的方式展现。
• 监控和报警
  ELK 可以通过插件的方式，安装像 ElastAlert 或Watcher这样的自动报警插件，实现自动报警功能。
  
  在了解了整个日志管理系统的基础架构后，再要去搭建这样一套日志管理系统，就可以做到心中有数了。你可以基于这套架构去寻找合适的工具，或者直接基于 ELK 去搭建一套日志管理系统。

五、项目总结

一些常见的存在问题的项目复盘情形：

• 总结不出来有效的结论
  流水账的回顾了一遍项目过程，感觉似乎有做的不好的地方，但说不上是什么地方做不好，所以也无法进一步的总结。
• 没做好是客观原因导致的
  有些团队在复盘后，将结论归结为是客观原因导致的，比如：客户不靠谱。
• 知道什么原因，但不知道该怎么办
  有些经过分析总结，能找到原因，但不知道如何应对。比如说发现主要原因是客户老变需求导致项目延迟，但是不知道如何应对需求变更。

如何做好项目复盘
对比一下你当初制定的项目目标和最终的项目结果，就可以发现差异，通过这些差异，就可以清楚地知道哪些地方是变好了、哪些地方变糟了，还需要思考背后的原因。

联想公司对于项目的复盘总结了四个步骤，同样适用于软件项目：

• 回顾项目目标；
  其中的关键就在于，对目标的描述要尽可能准确和客观。因为只有做到准确和客观，在后续你才能对目标的完成情况进行准确地评估。
• 评估项目结果；
  这里需要列出两方面的差异：好的差异和坏的差异。
• 分析原因；
  主要从两方面着手：是什么原因导致了好的差异，什么原因导致了坏的差异。只有分析清楚原因，才能总结出规律。
• 总结规律，落实行动。
  分析出原因后还不够，最重要的是，还需要去总结背后的规律，才能真正把成功或失败的经验变成个人和团队的能力。
  总结出来规律后，还需要落实成行动，才能真正做出有效的改变，帮助你在以后的项目中做的更好。落实行动的关键就是：对于好的实践，继续保持；对于不好的实践，停止并寻求改变。