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

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


文章目录

      • 1、版本发布
        • 1.1、软件版本的定义
        • 1.2、版本发布规划
        • 1.3、规范发布流程
      • 2、DevOps是什么
        • 2.1、DevOps工程师的职能
      • 3、线上故障解决
        • 3.1、快速定位bug
        • 3.2、大厂处理线上故障的方法
      • 4、日志管理
        • 4.1、日志管理系统的架构
        • 4.2、工具推荐
      • 5、项目复盘
        • 5.1、如何做好项目复盘

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搭建自己的日志管理系统,其基本架构是这样的。

《软件工程之美》——运行维护_第1张图片

有几个重要的模块:

  • 日志采集和解析:Logstash可以帮助实现对日志的采集,将日志解析成结构化的数据才能方便地检索。
  • 存储和搜索:ElasticSearch是专业的全文检索和数据存储系统。
  • 数据可视化:Kibana就是专门针对ElasticSearch的图形化操作工具。通过可视化图表,可以直观地看到数据的走势,以及方便地和历史数据进行对比。
  • 监控和报警:可以安装Elast Alert这样的自动报警插件,实现报警功能。
《软件工程之美》——运行维护_第2张图片

4.2、工具推荐

ELK的安装教程:ELK教程

工具:

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

5、项目复盘

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

5.1、如何做好项目复盘

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

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

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

好的差异:

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

坏的差异:

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

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

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

《软件工程之美》——运行维护_第3张图片

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

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

坏的原因:

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

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

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

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

你可能感兴趣的:(05_极客时间阅读笔记,08_软件工程)