上周四周五两天参与了一次“救火”行动，叫行动顿时感觉使命感和急迫感扑面而来。不过这次行动确实也让人从中感知到不少东西。常言道任何纸上谈兵，都比不上一次实战学到的东西多，也更让人印象深刻。因为过程中参与的感官，不只有脑力还有体力。
这次的主要原因是core api改动，导致依赖的产品线的CICD停工2天。影响了国内国外7，8个team。当然救火期间还遇到了github issue，vsphere server 拒绝访问，也是一段丰富多彩的体验。
虽然我们对于这次变更是有预案，约定了一系列的流程步骤。此处也是有个疑惑：我们一直推崇Agile，agile的宗旨是小步快走，方案全面具体不是它的风格。就好比造辆车来说，agile主导先走两步，看看情况怎么样，然后反复迭代。那么我们的变更方案可能也是有着部分因素在里面：对整个大产品团队是存在雾里看花，有些产品之间的关联并不是很清楚。我也相信没有人能够完整的说出里面的方方面面，毕竟各有精专。但是需要我们从整体考虑的时候，我们就应该整合各部分的知识，主导者（SM）尤为重要，他需要清晰的知道每个阶段做什么，以及谁在做，怎么做。SM可以是任何一个人，但是他一定是最了解所有干系人的人。
这里提到了所有干系人，那么什么样的人是这类人呢？首先是对这次变更结果关心的人，其次是需要参与到这次变更操作的人，还有受这次变更影响的人。我们这次变更显然没有做到通知所有干系人，前期预案评估的时候，也漏掉了其他产品线对其的依赖。写到这不禁让我想起了zabbix监控vm的模式，zabbix server提供服务，zabbix agent抓取各个vm的信息，并推送到server中。但是对于server来说并不知道下面有多少个agent。那么作为一个core api，也存在这种情况。圆圈内部的involve进来，圆圈外面的，盲区。或许你想到版本管理，我变更自己的api版本，向前兼容，对其他依赖的人无感知，等到他们使用的时候让他们手动更改版本，相信这种影响挺小，至少block的也是自己的产品线。或者可以做成蓝绿部署那种模式，先自己内部升级修改一部分，然后切换流量，再修改另一部分。但是这次情况有些不同，整个domain结构有改动，也就是说不能兼容。不能兼容的话，那么我们可以保持两部分（老的和新的）共存一段时间，等一段时间稳定后，再废掉老得，这种也是可以规避一些风险。如果考虑经济的话，会浪费一部分资源。
这次由于前期吃亏在丢了部分干系人，core api直接更新了image，老得api不能work，而且依赖的产品线对这个core api还有特殊定制。按照我的想法是先直接revert，首先保证产品线都work。然后做测试，等依赖的产品线也测通了，再合并。但是core api team觉得这次改动很大，revert回去会导致严重delay，而且这部分feature是必须要做的。介于此，我们只能牺牲SLA了。期间有位同学的话也触动了我下：pipeline红了没关系，说明有变更，我们修复变绿就行。回退虽然变绿，但是也是“假绿”，pipeline应当正确反应当下产品的情况。
于是受影响的team都进场了，大家一起动手。core api又做了针对性的4次commit，pipeline这边也立即修改了对应的ansible脚本，国外同事也开始修改对应的automation cases。然后合并，连测...变更结束后，也做了深刻的复盘，总结经验教训。当然其中让我最为感触的也是同学们提到的就是无论多晚，teams上面都是有呼必应，国内国外不同时差，传递接力棒，沟通效率很高，特别是在疫情期间，难能可贵。
IMG_4626.JPG
网友评论