在基于Golang的后端开发中，channel是一个必须要掌握的并发编程概念。和python的queue一样，channel在不同的goroutine里承担着传递信息的作用，使得业务逻辑的状态上下文可以在不同的goroutine中共享。今天，我们就来看一下channel的用法还有一些使用上的基本原则。
首先，我们需要知道什么场景下会用到channel。一个简单的例子是，在主流程里，我们希望启动一个方便处理panic的goroutine，异步跑一个任务，然后主流程等待这个goroutine给join进来。解决这个问题，就可以用到channel，代码这样写：
在变更风险防控领域，对于线上变更元信息的分析是非常重要的一部分，这是因为，只有理解了变更元信息，结合自主定制的变更规范，才能够知道具体的变更风险在哪里。不同的变更风险防御能力，实现的思路可能是不同的，因此很有可能出现对于一次变更，在信息的理解上有所不一致，从而导致检测结果不够置信。基于此，我们需要一个独立的变更元信息分析框架，把所有的变更元信息分析过程和结果都归到一个独立的系统当中。这样，从变更风险防御能力的视角，变更分析的结果都是共享的、全局的、一致的，从而能最大限度提升变更风险防御能力可挖掘的潜力。
本文，就简单聊一下，变更元信息分析框架设计的部分重点。
在服务或者其它线上资源发布新版本的时候，我们都有必要为发布信息本身和上线的资源做风险检查，以确认发布内容不会对线上造成影响。通常来说，在检查能力铺垫时，一个主旨的思路是保证问题的召回率，即检查能力本身必须理论上可以拦截更多的风险，这样才能够基本限度保证发布过程的安全。但随着检查能力集合变得成熟，业务也肯定会有对检查能力优化的需求，需要提升检查的准确率，不至于出现太多无用的噪音，这也成为了风险检查提升可靠性的一项挑战。
因此，本文就浅谈一下，提升发布风险检查准确率的一些思路。
今天闲聊一下可持续性架构设计的秘诀，总共八个字：概念拆解，重组改造。
说到新开发一个技术工程，很多同学会引用需求拆解的思路，自顶向下拆解子需求，做对应的层次模块设计，然后直接按照拆解结果分模块编码。依照这样的思路，虽然最终架构形态比较符合预期，但不一定能够保障长线迭代。这是因为，技术实现始终是自底向上，而不是自顶向下的，如果说在拆解过程中，思考深度不够，没有触及到底层概念的粒度，那么技术实现的结果，必然是失去可扩展性——上层隐含的底层概念跟需求强绑定，导致底层功能无法拆分出来，不能适配更多场景，最终不断堆积，就产生了技术债。
这个问题需要如何解决？举一个游戏领域的例子。以客户端自动化测试为例，我们期望的一个效果，是要通过客户端自动化测试工具，可以代替人力做游戏场景遍历，解决遍历冒烟测试耗时的问题。为了解决这个问题，可以简单做子问题拆解：
技术风险，作为质量保障领域的重要的一环，主要研究如何通过解决方案和技术手段，解决企业内业务在基础运维、日常运营和变更上线过程中的稳定性问题，保证业务风险得到收敛。在国内，蚂蚁金服在这个方向上有沉淀很多方法论和实践经验。变更管控是技术风险地一个子领域，主要的目标是在变更过程中，通过对变更流程的管控介入，提前发现变更过程存在的事故风险，或者阻止变更过程的错误进一步扩大影响面。在这个子领域，蚂蚁开源了AlterShield变更管控平台，提供了一套变更风险防御的解决方案。今天，本文就浅析下AlterShield平台整体的设计，适用的场景以及局限性。
AlterShield的源码可以参考这个GitHub-Repo。整体的技术架构，主要包含几块部分：
在线上环境运维过程中，我们通常需要治理慢查询的风险。慢查询会引起DB性能问题，并且当线上环境流量较大的情况下，就会出现因大量慢查询堆积导致DB被打挂的情况。因此，本篇文章分享一下慢查询的风险治理思路。
首先，我们需要知道什么情况下会出现慢查询。通常对于大表，未正确引用索引导致全表扫描，就会出现慢查询。慢查询出现也会经历从无到有的过程，而为何从无到有，就涉及到业务变更。以下几种业务变更场景就有可能导致慢查询的产生：
数据同步或者迁移操作也算是线上数据变更的一种类型。由于涉及的数据量非常大，一旦发生故障，会直接影响线上业务，并且较难止损。从变更风险管控的角度考虑，数据同步或迁移操作也需要走合理的发布窗口，并且在操作前也需要做足够的影响分析。本文就来聊一下数据同步和迁移的变更期间注意事项。
数据同步按照持续状态的不同可以分为一次性同步跟持续性同步。从质量保障的角度，要降低持续性同步的风险，需要额外考虑数据跟组件性能的监控，其它方面的考虑两者没有太大的差别。数据同步的操作手法也有很多种，既可以通过搭建中间件，实现一个导入binlog到MQ然后再导到其它存储的通路，也可以通过自建业务服务，通过批量刷数的方式主动导入大量数据。对于后者，在以前的文章当中已经提到了一些通用的风险点，但如果考虑到数据同步的需要，还会有一些额外的考量。
在接手以前的项目做开发的过程中，我们经常会遇到因为既有代码理解困难，导致代码难以删改，问题难以排查的情况。一份富含技术债的代码，不论对于当下的问题解决，还是未来的需求开发，都会形成累赘。因此，本文就分享一些通用的代码优化和治理经验。
首先我们需要从工作的角度去看待代码优化这件事情。需要捋清楚几件事情：
比起为技术而技术地去做代码重构甚至重写，锚定当前的目标，按需优化才是最好的选择。如果历史代码存在比较严重的问题，影响了核心的业务，那么必须强行去做修复，不论代码实现是否符合自己的审美。如果历史代码写的不那么美观，但线上跑的还比较稳定，那么也不建议直接做优化，更多的优先级应该放在新研发的内容上面。
精准测试在互联网领域有广泛的应用。以变更为出发点，通过对变更内容进行分析，可以确定单次变更具体涉及到哪些模块和功能点，以及是否存在夹带风险，从而从QA的视角，可以知道哪些功能模块需要做测试，以及哪些变更内容不符合预期。相比于互联网QA，游戏QA接入业务项目研发过程并没有那么深入，比如项目代码权限基本上游戏QA不会拥有，但即便如此，要在游戏测试领域应用精准测试专项技术，还是有一定思路可循。
因此，本篇文章，笔者以自身经验为出发点，讲述一下在游戏业务测试落地精准测试专项的一些思路。