上周一个做Java开发的朋友找我聊天，说他最近在面试，被问得有点懵。
他简历上写了“熟悉MySQL”，面试官问他：“你们项目里缓存怎么用的？Redis和MySQL的数据一致性怎么保证？”
他答得还算可以。
然后面试官又问：“你们日志类的数据存哪里？有没有用过Elasticsearch？如果日志量上来，查询变慢，你会怎么排查？”
他有点慌了，说日志那块是运维在管，自己没怎么接触过。
面试官没说什么，但最后反馈是：“技术广度不够。”
他跟我吐槽：“我一个写业务的，为什么要懂ES？”
我当时没直接回答他，而是跟他讲了我自己经历的一件事。
2018年那会儿，我们数据库组只负责Oracle和MySQL，别的一概不管。后来公司上了个新项目，业务那边说需要全文检索，开发自己搭了套ES，没用多久就开始出问题——数据写入延时大、查询超时、节点频繁OOM。
开发找到我们，说“数据库你们专业，这个ES也是存数据的，帮忙看看呗。”
我说我们也不会啊。对方也挺无奈：“那谁管呢？”
最后是我们组两个小伙子从零啃下来的。看文档、搭测试环境、研究索引优化和JVM参数，前前后后折腾了快一个月才稳住。
从那以后我就觉得，技术圈里那条“谁该管什么事”的边界线，越来越模糊了。
以前做DBA，管好关系型数据库就行。现在呢？缓存你得懂Redis，搜索你得懂ES，消息队列你得知道Kafka怎么保证不丢数据，时序库、图库、NewSQL……各种名词层出不穷。
你说这些跟DBA有关系吗？说没关系也真没关系，每个都是独立的技术栈。但说有关系也真有关系——数据最终都是存在这些系统里的，出了问题别人第一反应就是“找搞数据库的”。
这不是贩卖焦虑，是我自己真实的感受。
现在市场上对技术人的要求，正在从“T型人才”往“π型人才”转。一横还不够，最好有两竖——一竖是你吃饭的深度技能，另一竖是你能够横向连接的那个领域。
比如DBA懂点开发思维，知道SQL在业务代码里怎么被拼接、ORM框架怎么生成执行计划，排查问题的时候就不用反复找开发要上下文。开发懂点数据库原理，知道索引是怎么工作的、事务隔离级别对并发有什么影响，写出来的代码质量会高一大截。
这种“跨半步”的能力，平时可能显不出来，但到了排查线上事故的时候，差距就拉得特别明显。
现在团队里我比较看重这种特质——不是让你什么都精通，那不现实，但你得对自己专业边界外的领域保持好奇心。遇到跨技术栈的问题，第一反应不是“这不归我管”，而是“我能不能试着搞懂它”。
这种心态，我感觉比背几个框架源码重要得多。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70048457/viewspace-3117252/ ，如需转载，请注明出处，否则将追究法律责任。
