狼人杀是一个抢轮次的游戏。
这句话和信通院评测有什么关联吗？当然有。狼人杀无论狼人还是好人，都需要在每一个轮次想办法抢到自己的有利结果，才能掌握主动权。信通院评测，摆在我这个产品经理面前的就是每个轮次做什么。既要确保每个轮次做的事情有一个合理的预期结果，又要确保产品整体的功能路线是正常的。一些狼人杀新手玩家会纠结某一次投票某一次发言，而忽略了整局游戏的走向。
前情提要《信通院HTAP数据库评测那些事——功能篇》
第一个坑：DDL
这里的DDL，特指ALTER TABLE。ALTER TABLE如果仅仅是rename还好，一旦涉及到类型变化或者加减列，就有可能和存储引擎打交道。不同的数据库因为底层的存储引擎有区别，修改的难度也各有不同。而之前我所在的团队，修改存储引擎来支持的难度，着实不小。
所以在这方面，计算组以及存储组的同事都做了好几轮的设计方案探讨，既要保证数据库功能的支持，又要确保不要对存储引擎的整体设计思路以及未来规划产生影响。
负责存储开发的同事，在一个迭代周期内，想要完成所有的设计和研发时间是来不及的，最终我们选择了在待开发的4个功能点中完成两个，剩下的两个放到下个迭代。确保这个轮次的功能是可用的，并且对于整个存储引擎的设计不会有偏差。
到了下一个迭代，原计划里要开发的剩下两个功能点，因为整个存储引擎开发计划的变更，使得存储组同事无法完全完成。实际上摆在我面前的有两个选择，一个是强行让他开发，但是未来可能会有对存储引擎带来不可预测的隐患；另一个是由计算组同事来从计算引擎角度做一些开发，用其他方式绕过存储引擎，缺点是性能不会太好。
权衡利弊之后，我选择了第二条路线，性能问题在信通院评测中不会有涉及，当然，带来的问题就是，未来存储组同事仍然需要开发，会有一定程度的人力重复投入。但是这也是无法避免的。
最终在两个迭代周期内，完成了这一项功能。
第二个坑：数据分布
按照信通院评测的内容，数据分布基本上可以等同于分区partition。但是partition也有好几种类型，而且我们都知道，partition同样是一个存储和计算协作才能完成的功能点。涉及到跨组开发的时候，先期的设计讨论，是一个很熬人的事情。
好在这个功能对当时的存储引擎来说，并不是一个需要改动特别多或者特别繁琐的事情。一周左右，两个组的同事就在代码设计上达成了一致，接下来就是各自开发。而且根据信通院的要求，至少支持一种分区，选择一个开发起来最容易的分区完成评测，积累一些经验，为后面分区开发铺垫，成为了当时我们的核心目标。
但是信通院评测里的另一个坑，需要分区支持执行计划，这个就很麻烦了，不仅仅涉及到引擎，还要去对执行计划部分做相当规模的开发。
当时和负责执行计划开发的同事沟通，这部分的难度超过了我的预期，要么让他放下手头其他开发任务全力支持，要么把这个子项目排到下个迭代完成。权衡利弊之后，还是选择了后者。因为他当前开发的内容，也是很多功能的先置条件，这关乎后面两个迭代的功能规划。这种情况之下，强行去抢轮次显然是不理智的行为。
最终这一项比预期延后了一个迭代完成，当然，也赶上了既定的评测时间，回想起来，没有留任何缓冲，也是挺危险的。
第三个坑：事务
评测中最大的一个坑——支持两个以上隔离级别。之前我们产品只支持乐观事务和快照隔离，因此在产品规划中，对于先支持一个隔离级别还是先支持悲观事务，本身也是一个艰难的选择。
最后产品和研发经过讨论，做出了一个当时大家认为可行，实际上开发难度严重超出预期的选择：读已提交级别和悲观事务模型都开发，然后在这基础上，支持两种事务模型和两个隔离级别的组合。结果这个事情不出意外地就出意外了。
首先就是过去的执行计划存在着很多地方无法适配悲观事务，再就是不同隔离级别组合事务模型带来的各种锁服务远远超过预期。这就使得从一个单一的事务开发，变成了先去重构执行计划，再去开发新的事务模型和隔离级别。涉及到的范围既有计算层又有存储层。
整个开发预期，最终是计划内的三四倍。这期间还出现过两三次看起来曙光乍现却又结果不符合预期的情况。那段时间里，我每天陪着重构plan的同事一起吃饭，不敢给他们压力，每个人绷得都很紧，却都在假装轻松。
直到开发到后半段，负责事务的同事跟我反馈，事务模型x隔离级别组合的设想难度过大，能不能放弃一部分，乐观+快照搭配悲观+RC，做过DBA的我了解，悲观+RC可以覆盖相当比例的应用，也十分认可他的提议。在那段时间里，我拉着负责文档的同事参加了几户所有事务相关的会议，每一次会议，她也给予我很多有用的反馈，也成为了我坚持做下去的一个动力来源。
最终这个功能得以平稳地完成测试，负责测试的同事不断地提出bug，相关的研发同事逐个解决，到了最后都有一种被脱了一层皮的感觉，他们内心曾经的焦灼，不言而喻。
第四个坑：权限
权限的坑，很大比例是在我们产品组内部。我是负责数据库内核，同组的同事负责公有云。对于权限到底怎么做，我俩是存在较大分歧的。
作为一直用Oracle和MySQL的我来说，严格的RBAC在这两个产品中都不存在，既有单独对用户的授权，也有对角色授权。公有云的同事希望的是，作为一个新产品，就要从一开始严格地执行RBAC。这是我俩最初的分歧，在整个迭代周期的前三分之一，我俩争辩了好几轮，最终还是CTO拍板，这事就按照RBAC来做了。
当然，我内心很清楚，严格的RBAC才是对数据库权限最合适的，但是长年的DBA生涯也告诉我，很多的应用程序开发人员或者业务场景下，严格的RBAC会带来很多潜在的风险，组合使用是规避的一条路。
后面则是基于RBAC这套体系下权限行为的具体设计。因为负责开发和测试的同事，对于这方面的了解都不是很多，所以整个迭代的第二个三分之一，我和之前争辩的同事，又携手给大家讲解这套体系。
在那一刻，我深知有一种，自己在这里拿了野孩子牌的错觉，整个人的阵营开始错乱。当然我仍然要说的是，我和跟我争辩的同事并没有因为这件事情初始的分歧影响个人关系或者工作上的协作。和而不同才是常态。
第五个坑：升级
写到这里，终于到了最后一个坑，这个坑终于把产品、分布式、存储、计算、测试，每一个组的同事都拉入坑里。
作为一个分布式产品，尤其是存算分离，升级这个动作就比集中式数据库复杂了很多。再加上公有云服务，这使得升级的硬性需求里，又多了一个不停服务滚动升级的必须项。
我记得那次会议，我还在一次会场里，前脚刚给参会的同行们做完分享，后脚就入会讨论。表面上来看，这是三个组各自完成自己部分的开发。但是涉及到诸多关键点之后，就不再是1+1+1=3，变成了1+1+1>>3。作为对分布式以及存储了解不算多的我来说，也有很多地方触及到了我的知识盲区。
怎么办？强行扔到一个迭代里开发，还是分拆成不同阶段，每个阶段完成一个目标，又摆在我的面前。我去调研了很多市面上架构接近的数据库产品的方案，但是无论哪种方案，与我当下面临的困境，都有较大的不同。而且更糟糕的是，时间就在一次次会议中流逝，留给实际开发的时间越来越少。
最终还是产品组负责公有云的同事救了场，他提出了自己在公有云能接受的底线，从这里出发，我们很快探出了当前迭代开发的最近目标。与测试的同事沟通之后，可行性也不错。最终依靠大家的集体智慧，趟过了这第一关。
在后面的版本中，继续沿着这个目标前进，也依靠测试同事们的经验和方法，成功完成了这个测试项目。
后记
回顾这几个点，死去的记忆又攻击了我一轮。当初的焦虑和无助又在脑海里走了一圈。最终还是靠着研发和测试同事们的帮助下，在我离职前夕完成了信通院的HTAP评测。心里那块石头终于落地了。
感谢你们，在每一次困境中，指引我陪伴我前行。
