最近，合规的要求逐渐渗透到技术层面。最近的一段时间，总有产品来找，说要实现这样那样的合规需求。或者是，做一些什么合规的调查问卷。我感觉，合规也主要就是说对于用户信息的存储、访问需要规范化，然后用户能够逐渐开始掌控自己的数据。然后还有一些人事上、组织架构上的变动对于技术层面造成的冲击，比如说一个业务被调度到其他部门去了，然后我们还在一直和这个业务共享数据库等资源。这个时候费用问题就突出了，就是说钱该算在那边。虽然是一个公司、一个事业群，但感觉可能是由于公司内部的核算机制问题，对于这些成本问题还是比较较真的，总会掰扯什么：他们用了我们的数据库，钱还在我们这边什么的。有时候感觉，这些都是属于内部消耗，并不是出于发展的眼光看待问题。另外，别的业务可能由于什么需求调整，需要修改一些公用的数据库结构或者接口，就比较麻烦了。因为这个时候，我们为他们花费工时来做这些事情，并不能得到任何肯定。但是，又会被那边的人催着，天天轰炸。自己夹在中间，感觉就比较难受。
然后，我上个周报提到的PHP网关迁移的问题，其实前一两个月就开始在做了。其实也早就写好了，但是在后续切换流量到新服务的时候，总是会遇到这样那样的问题。具体表现就是，测试环境流量切换很久了没有人来找，一切正式环境这样那样的人就来找了。所这个接口突然用不了，那个接口突然报错什么的。这种情况下，由于问题发生在线上，只能先把流量切回去再分析问题。一来二回，一个星期就过去了。有时候，切换了4、5天才会有人来找。这样一个流程下来久更久了。leader一直说这件事情做了很久如何，但实际的情况就是这样。虽然这个服务的后续具体的代码编写和维护工作并非我来做了，但是我也知道一个新的服务要能够完全替代就有的服务必须有一个这样的流程。因为在缺乏文档和测试用例的情况下，你不知道一个接口有什么暗藏的机制，也无法完全清楚我写的代码是否和原来的等效。所以执行层面，很多事情没有明确汇报，但是我感觉管理上也要能体会到。虽然过程比较反复、艰难，但最终这个服务的重构工作在本周还是完成了，所有的流量都迁移到新的服务上了。也就是代表，这个老PHP网关的生命周期终结了。
我接手主要的后台业务也快半年了，现在发现刚接手的时候由于缺乏经验，总感觉别人的技术高深莫测。但是，自己接触久了才知道里面有这样那样不完善的地方。还存在一些设计缺陷，非常严重的缺陷都有。比如说把Redis当作数据库使用，说白了就是没有设置缓存过期时间，然后Redis里面的数据又很重要不能丢失。这对服务里面还存在着一些缺乏文档、维护人员早已离职的老旧服务，这些老旧服务基本上平时无法来仔细研究。但这些服务中总有那么一两个依然在被访问，或者早就不能访问了，客户这几天突然发现然后急着催我们解决。很多安全问题也需要整改，某几个API账号有一些高位的权限需要收敛，但是我并不知道这个几个账号具体是做什么的。这些问题，就是日常频繁遇到的，很难避免。
