对于技术价值的思考和建议

这是学习笔记的第 1798篇文章

今天晚上在客厅里来回走了几十圈，最后把最近碰到的一些问题思绪理了下。

最近的一次技术讨论，领导的一个问题一下子点拨了我。我们聊的是一个元数据交互的场景，我提出了目前数据同步的一些问题，也列举了目前在同步过程中双方存在的一些问题和建议，以及改进措施，整体来说，思路还是比较清晰的。领导很认真的问了一句：为什么数据库需要系统层面的元数据？这个问题看起来很好回答，其实需要解释的是，在数据库中关注的系统层面信息除了CPU,内存和磁盘这几个硬性指标（这些信息其实数据库层面也完全可以自己采集到），在这个基础之上的一个深层次需求其实是数据库层面要做高可用，需要让系统同学不要把主从部署在一个宿主机上，但问题又来了，系统同学也不知道主从是不是在一个宿主机上，问题绕了一圈又折回来了。所以问题转变为数据库需要系统层面的元数据，但是希望抽取的元数据是增量的，而不是全量的。

这类的问题和需求在工作中经常会碰到，如果说解决方案，其实有很多种或者在流程中都可以做到取舍。但是通过这么一个看起来很简单的问题折射出了我们还有很多细节的工作需要去补充完善。

这个问题再更深一个层次，那就是系统同学应该不需要去关注主从服务部署在一个宿主机上，有了这个基础背书，那么数据库其实也就不需要强依赖系统层面的元数据信息了。但是这个问题光靠背书没法保证，怎么解决呢，其实可以通过标签系统来完美解决。

所以一个看起来很简单的一个问题，在解决方式和方法上有很多需要考量的地方，我想这也是我们讨论的价值所在，也是后续要开展的工作的价值所在。

故事有点长，其实主要想表达的就是一个看起来很简单的问题，从表面情况来说，发现的问题很多，解决方法可以解决现状，但是我们需要反思，这个问题本身的目的是什么，如果能从根因的角度来出发，找到问题的本源，那么对于这个问题的分析就上升了一个层面，同时对于问题的边界能够划分清楚，这样其实后续的对接中，就不需要过度的强关联依赖。

所以对于我们从事技术工作来说，我有以下的几个建议，供参考。

1. 做技术更要做技术价值变现 首先做技术项目，要落地一个方案，做好技术的同时，其实最好能够明确业务目标，如果只是做好了技术层面，但是业务层面没法对标，在技术输出和对接上就是一个问题，很容易成为瓶颈，这也可以理解是一类业务目标性极强的技术价值变现。简单来说，就是让业务觉得有技术价值再去做，和做好了得到业务的肯定，这是两种差别相对较大的境遇。
2. 什么时候才能证明是想明白了 有时候我们规划项目，安排项目计划等，总是会产出一些文档，希望我们是把这个项目想明白了，整体有一个把控，但是在实施的过程中，一来保证进度，在有限的时间内完成，二来要保证质量，怎么做，怎么设计要比别人想得更多。其实从目前落地的项目情况来说，一次性想明白是不可能的，很多时候都是在项目进展的过程中不断的迭代，有些勉强达到目标，有些却能有额外的收获。所以不光光是纸面功夫，想明白60%以上其实做起来就基本成型了。
3. 对于技术的敏感度 技术方案就是用来解决问题，但是很多问题的解决方法会比较保守，以至于看起来不大合理，却大量存在，在有些时候黑白思维还是很适合我们的，比如对于一个元数据的定位，对还是不对，如果存在模糊状态在后续的业务模型里面就会出现很多模糊的情况。失去了清晰定位的边界数据，其实会给我们带来很多的束缚。 明确了改进之后，其实对我们来说很大的一个挑战就是对于技术的敏感度，技术存在哪些潜在问题，是不是可控，有没有更好更便捷的方式，这些都是需要我们深度思考的。
4. 你的实施步调 对于技术落地来说，我们的实施步调是很关键的，这个一个更实在的过程，通过开发，集成，对接能够把数据对接起来，实施步调的一个思路就是不是所有的事情都需要自己亲力亲为，我们在有一些基础的铺垫之上，就可以明确一些分工和角色，共同来建设，共同来实现目标。
5. 设计，还是设计 其实主导了一些运维开发项目之后，我深深觉得对于产品和功能的设计尤为重要，通过产品的设计能够直观的感受到我们对于问题的理解，一个繁琐的操作基本能够说明问题我们其实就没想明白。大多数情况下，我们不应该追求一下子想明白，最基本的目标是这么做至少不会比现状更差，我们不应该做到某一步了才发现当初竟然没有想到这个，对架构和功能大改，微调是不可避免也是欢迎的，但是大刀阔斧的改动频繁的话就很成问题了。这种情况下我们就是技术的瓶颈了。