前言
本周正式回归正常的办公场所，关于远程办公和公司办公我只能说各有各的好坏，说实话我会更偏向在公司办公，后面有机会写篇文章分享下。本周继续专栏学习计划，目前已经进展到专栏的尾声了，正篇内容基本可以在这周可以搞定，这周的主题是运行维护篇，以下内容是我的总结：
35 | 版本发布：软件上线只是新的开始
业界通用版本编号
主版本号 . 子版本号.[. 修正版本号.[构建版本号]] 比如：1.2.1.1 主版本和子版本分别在大功能和小功能编号时累加，修正版本标识Bug修复，而构建版本号基于每一次构建，自动累加。
版本的发布规划
- 首先要规划要发布的功能
- 定义好发布的质量标准
- 设计好发布的策略（比如：Beta策略，让小部分用户先体验新功能）
- 最后有一个综合性的版本发布计划
业界好的发布规范流程
- 在发布之前要做代码冻结（封版，不允许新的功能增加）
- 对代码冻结后发现的Bug要分级（是否在发布前修改，还是发布后修改）
- 每次修复Bug后，发布新的候选版本
- 每次部署新的候选发布版本，要做回归测试（确认Bug已经修复并且无引入新的Bug）
- 申请上线发布（正规的审批流程）
- 部署发布（确保线上运行正常）
- 上线后的测试（发现问题采取回滚策略）
上线后要做的事情
- 提供用户反馈的渠道
- 针对版本进行监控，收集必要的信息；比如：App Crash的Log、服务器资源占用情况、API出错比例、网页响应速度等
- 回顾项目过程，总结复盘，将经验变成能力
这一节讲的内容讲的是软件项目上线之后要关注的事情，上线仅仅只是开始，一个产品的好坏除了更新迭代，也得靠日常运营，营造好的品牌口碑，提高曝光度。作为一个软件工程师，能够负责一款受人喜爱的产品研发，自己也能从中收获到成就感。
36 | DevOps工程师到底要做什么事情？
什么是DevOps?
先来回答DevOps解决什么问题，现代运维模式存在两个挑战：
- 服务器的规模快速增长和虚拟化技术的快速发展
- 高频的部署发布
DevOps的出现是为了解决开发和运维之间的协作问题，提升运维开发和自动化能力。
DevOps是开发（Development）和运维（Operations）一切紧密协作的工作方式，从而可以更快更可靠的构建、测试和发布软件。
DevOps带来的好处
- 软件的构建、测试和发布过程高度自动化
- 信息更加透明和易于策略
- 培养跨职能协作的文化
DevOps工程师要做什么？
- 帮助团队建立基于持续集成和持续交付工作流程
- 建立一套基于日志的监控报警的系统，以及故障响应的流程
- 构建基于云计算和虚拟化技术的基础设施
- 帮助团队构建协作文化
关于这一节的内容，我最大的感受就是不仅仅只是运维工程师需要学习DevOps，而是所有开发都应该学习DevOps，开发和运维本身就分不开，构建协作的文化，提升研发效能，不管对产品还是团队都是非常好的实践。
扩展阅读： DevOps 前世今生 | mPaaS 线上直播 CodeHub #1 回顾 孙宇聪：来自Google的DevOps理念及实践 关于 DevOps ，咱们聊的可能不是一回事
37 | 遇到线上故障，你和高手的差距在哪里？
新手处理线上故障
- 遇到复杂的线上故障，不知道怎么下手
- 遇到线上故障，会想着马上修复Bug，匆忙打补丁，可能会引入新的Bug，造成更严重的损失
- 不知道如何快速定位Bug
- 解决完线上故障，可能还会重犯
高手处理线上故障
- 会有一套解决问题的步骤
- 第一步，评估影响范围
- 第二步，试图重现问题
- 第三步，临时方案和终极方案
- 第四步，风险评估及持续优化
- 遇到故障，会先评级、评估影响范围，优先保证业务可用，恢复生产，再考虑修复Bug
- 通过有效手段重现Bug，逐步缩小问题范围，定位具体的错误位置
- 会仔细分析Bug产生的原因，从根本上解决，避免类似的故障再次发生
大厂处理线上故障值得借鉴的地方
大厂其实是把高手解决故障的方式，变成故障处理的流程和操作手册，并且通过反复地故障演习。不断练习和强化对故障处理的流程，让系统更健壮，让新手也可以快速上手，做到高效处理线上故障。
- 故障报警和轮值机制
- 找对故障服务最熟悉的人
- 轮值on call，报警响应
- 实战演习（混沌工程）
- 日志记录和分析工具（搭建ELK或Splunk这样的日志分析系统）
- 其他好的实践
- 灰度发布策略
- 开关控制灰度
这节课让我更深刻的了解处理线上故障的实践，前后端解决具体问题的方法可能会有所不同，但总体解决策略和思路是类似的。关于工程师解决问题的和分析问题的能力其实也是我们的核心竞争力，如何更好的解决问题，提升业务价值，是我们在整个成长过程中需要不停去思考并践行的。
38 | 日志管理：如何借助工具快速发现和定位产品问题 ？
这节课宝玉老师主要分享了怎么通过搭建日志管理系统来帮助我们快速发现和定位产品问题。更多是偏后端的内容，这里我就基于文章内容进行以下总结：
什么是日志管理？
日志就是操作系统和应用软件自动生成的事件说明或者消息记录，包含了时间、日志信息。 日志管理就是指对系统和应用程序产生的日志进行处理的方法，包括对日志进行统一收集，对日志数据进行筛选和解析，统一存储，还要让它们可以方便被检索。
日志管理系统解决的肉眼检索困难，服务架构复杂，无法统一记录和检索的问题
如何快速发现和定位问题？
- 集中式管理，统一检索
- 统一收集和实时统计，生成可视化图表
- 根据日志数值设置规则自动报警
业内大厂的最佳实践
- 日志采集和解析
- 解析成结构化数据，方便检索
- 存储和搜索
- 索引和分析，快速检索出结果
- 结果可视化
- 观察数据走势曲线
- 监控和报警
- 设定触发报警规则，通知值班人员处理
39 | 项目总结：做好项目复盘，把经验变成能力
复盘的常见问题
- 总结不出来有效的结论（过流水账）
- 没做好是客观原因导致的（没有想清楚）
- 知道什么原因，但不知道该怎么办（没有解决思路）
复盘的四个基本步骤
1. 回顾项目目标
- 清晰描述当初定的项目目标
- 里程碑是什么，能否做到准确客观（可量化）
2. 评估项目结果
- 列出好的差异和坏的差异，就是做得好的部分和不好的部分
3. 分析原因
分析导致项目结果好跟坏的原因，好的比如改进了研发流程，工具的使用，规范了项目流程；坏的比如老板过多干预产品需求，周期过长，频繁变更导致延期等
4. 总结规律，落实行动
基于原因总结规律，保持好的实践，停止不好的实践或寻求改变
这节课能给我们的启发是很多的，当时也发了个朋友圈：
定期回顾项目进展和目标，让团队小伙伴知道劲往哪里使，避免无意义的抱怨，解决问题为主，让写代码变得更加美好。
最后
运行维护篇作为软件工程当中最后的环节，让我们知道软件上线仅仅只是第一步，后续的运行维护才是我们让产品生命力继续发光的手段，只有产品成功，我们研发的价值才能体现。在软件研发过程中，自然会有做的好的和不好的，阶段性复盘是我们能够将经验转化成能力的好实践，经过这段时间的学习，我也很想将这里面学习到的内容推广到我们的团队当中，借助好的方法论一定能够让我们团队研发实力更上一层楼。
