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

运行维护篇

一、版本发布
二、DevOps工程师
- [1、什么是 DevOps](#1、什么是 DevOps)
三、线上故障
- 1、遇到线上故障，新手和高手的差距在哪里
- 2、大厂都是怎么处理线上故障的
四、日志管理
五、项目总结

一、版本发布

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 去搭建一套日志管理系统。

五、项目总结

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

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

如何做好项目复盘

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

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

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