光の技术屋

今天灵光一闪，决定调研一下自己的技术博客，可以怎样方便迁移到其它社媒平台。想要达到的效果是，把自己在掘金的专栏：从1到∞精通Python，迁移到知乎上面去。

简单花了两三小时时间，找到一个比较快捷的方法，就是结合python爬虫、clean-mark工具和zhihu-on-vscode插件，实现从掘金到知乎的文章搬运。

正直劳动节，翻了下2023年美团的技术年货，挑选了一些和变更风险防控和稳定性建设相关主题的文章做了下浅读。本文仅简单记一下阅读笔记。

总共选读了3篇文章，分别是《基于AI+数据驱动的慢查询索引推荐》、《代码变更风险可视化系统建设与实践》，以及《AIOps在美团的探索与实践——事件管理篇》。

前言

《软件研发效能权威指南》一书，对于软件研发效能DevOps领域做什么事情，解决什么问题，给出了非常全面详尽的说明。这本书的精华，基本全部都浓缩在一张附属的海报上，海报讲述了每个章节的精简摘要，可以说是现成的读书笔记。

2024年，相对于古早的纸质载体，用电子作为载体的文献在维护上成本更为低廉，并且也逐渐成为了最优的文献阅读方案。因此，顺带借着AI的东风，笔者决定用AI技术，将这份海报转化成一份电子版的读书笔记，通过OCR识别+GPT润色+人工校对，把这本书所有的精华给摘录下来。

以下，便是读书笔记的正文。

在基于Golang的后端开发中，channel是一个必须要掌握的并发编程概念。和python的queue一样，channel在不同的goroutine里承担着传递信息的作用，使得业务逻辑的状态上下文可以在不同的goroutine中共享。今天，我们就来看一下channel的用法还有一些使用上的基本原则。

首先，我们需要知道什么场景下会用到channel。一个简单的例子是，在主流程里，我们希望启动一个方便处理panic的goroutine，异步跑一个任务，然后主流程等待这个goroutine给join进来。解决这个问题，就可以用到channel，代码这样写：

在变更风险防控领域，对于线上变更元信息的分析是非常重要的一部分，这是因为，只有理解了变更元信息，结合自主定制的变更规范，才能够知道具体的变更风险在哪里。不同的变更风险防御能力，实现的思路可能是不同的，因此很有可能出现对于一次变更，在信息的理解上有所不一致，从而导致检测结果不够置信。基于此，我们需要一个独立的变更元信息分析框架，把所有的变更元信息分析过程和结果都归到一个独立的系统当中。这样，从变更风险防御能力的视角，变更分析的结果都是共享的、全局的、一致的，从而能最大限度提升变更风险防御能力可挖掘的潜力。

本文，就简单聊一下，变更元信息分析框架设计的部分重点。

在服务或者其它线上资源发布新版本的时候，我们都有必要为发布信息本身和上线的资源做风险检查，以确认发布内容不会对线上造成影响。通常来说，在检查能力铺垫时，一个主旨的思路是保证问题的召回率，即检查能力本身必须理论上可以拦截更多的风险，这样才能够基本限度保证发布过程的安全。但随着检查能力集合变得成熟，业务也肯定会有对检查能力优化的需求，需要提升检查的准确率，不至于出现太多无用的噪音，这也成为了风险检查提升可靠性的一项挑战。

因此，本文就浅谈一下，提升发布风险检查准确率的一些思路。

今天闲聊一下可持续性架构设计的秘诀，总共八个字：概念拆解，重组改造。

说到新开发一个技术工程，很多同学会引用需求拆解的思路，自顶向下拆解子需求，做对应的层次模块设计，然后直接按照拆解结果分模块编码。依照这样的思路，虽然最终架构形态比较符合预期，但不一定能够保障长线迭代。这是因为，技术实现始终是自底向上，而不是自顶向下的，如果说在拆解过程中，思考深度不够，没有触及到底层概念的粒度，那么技术实现的结果，必然是失去可扩展性——上层隐含的底层概念跟需求强绑定，导致底层功能无法拆分出来，不能适配更多场景，最终不断堆积，就产生了技术债。

这个问题需要如何解决？举一个游戏领域的例子。以客户端自动化测试为例，我们期望的一个效果，是要通过客户端自动化测试工具，可以代替人力做游戏场景遍历，解决遍历冒烟测试耗时的问题。为了解决这个问题，可以简单做子问题拆解：

技术风险，作为质量保障领域的重要的一环，主要研究如何通过解决方案和技术手段，解决企业内业务在基础运维、日常运营和变更上线过程中的稳定性问题，保证业务风险得到收敛。在国内，蚂蚁金服在这个方向上有沉淀很多方法论和实践经验。变更管控是技术风险地一个子领域，主要的目标是在变更过程中，通过对变更流程的管控介入，提前发现变更过程存在的事故风险，或者阻止变更过程的错误进一步扩大影响面。在这个子领域，蚂蚁开源了AlterShield变更管控平台，提供了一套变更风险防御的解决方案。今天，本文就浅析下AlterShield平台整体的设计，适用的场景以及局限性。

AlterShield的源码可以参考这个GitHub-Repo。整体的技术架构，主要包含几块部分：

在线上环境运维过程中，我们通常需要治理慢查询的风险。慢查询会引起DB性能问题，并且当线上环境流量较大的情况下，就会出现因大量慢查询堆积导致DB被打挂的情况。因此，本篇文章分享一下慢查询的风险治理思路。

首先，我们需要知道什么情况下会出现慢查询。通常对于大表，未正确引用索引导致全表扫描，就会出现慢查询。慢查询出现也会经历从无到有的过程，而为何从无到有，就涉及到业务变更。以下几种业务变更场景就有可能导致慢查询的产生：

数据同步或者迁移操作也算是线上数据变更的一种类型。由于涉及的数据量非常大，一旦发生故障，会直接影响线上业务，并且较难止损。从变更风险管控的角度考虑，数据同步或迁移操作也需要走合理的发布窗口，并且在操作前也需要做足够的影响分析。本文就来聊一下数据同步和迁移的变更期间注意事项。

数据同步按照持续状态的不同可以分为一次性同步跟持续性同步。从质量保障的角度，要降低持续性同步的风险，需要额外考虑数据跟组件性能的监控，其它方面的考虑两者没有太大的差别。数据同步的操作手法也有很多种，既可以通过搭建中间件，实现一个导入binlog到MQ然后再导到其它存储的通路，也可以通过自建业务服务，通过批量刷数的方式主动导入大量数据。对于后者，在以前的文章当中已经提到了一些通用的风险点，但如果考虑到数据同步的需要，还会有一些额外的考量。